March 2022 - Alsa-devel - mailman.alsa-project.org

[PATCH] ALSA: n64: Use platform_get_irq() to get the interrupt
by Zhen Ni 01 Mar '22

01 Mar '22

platform_get_resource(pdev, IORESOURCE_IRQ, ..) relies on static allocation of IRQ resources in DT core code, this causes an issue when using hierarchical interrupt domains using "interrupts" property in the node as this bypassed the hierarchical setup and messed up the irq chaining. In preparation for removal of static setup of IRQ resource from DT core code use platform_get_irq(). Signed-off-by: Zhen Ni <nizhen(a)uniontech.com> --- sound/mips/snd-n64.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/sound/mips/snd-n64.c b/sound/mips/snd-n64.c index 463a6fe589eb..19365aab15ba 100644 --- a/sound/mips/snd-n64.c +++ b/sound/mips/snd-n64.c @@ -289,7 +289,7 @@ static int __init n64audio_probe(struct platform_device *pdev) struct snd_card *card; struct snd_pcm *pcm; struct n64audio *priv; - struct resource *res; + int irq; int err; err = snd_card_new(&pdev->dev, SNDRV_DEFAULT_IDX1, @@ -337,12 +337,12 @@ static int __init n64audio_probe(struct platform_device *pdev) strcpy(card->shortname, "N64 Audio"); strcpy(card->longname, "N64 Audio"); - res = platform_get_resource(pdev, IORESOURCE_IRQ, 0); - if (!res) { + irq = platform_get_irq(pdev, 0); + if (irq < 0) { err = -EINVAL; goto fail_dma_alloc; } - if (devm_request_irq(&pdev->dev, res->start, n64audio_isr, + if (devm_request_irq(&pdev->dev, irq, n64audio_isr, IRQF_SHARED, "N64 Audio", priv)) { err = -EBUSY; goto fail_dma_alloc; -- 2.20.1

2 1

Issue in pcm_dsnoop.c in alsa-lib
by GitHub issues - opened 01 Mar '22

01 Mar '22

alsa-project/alsa-lib issue #213 was opened from TE-N-ShengjiuWang: Hi Takashi Iwai, Jaroslav Kysela We encountered an issue in the pcm_dsnoop use case, could you please help to have a look? Issue description: With two instances for dsnoop type device running in parallel, after suspend/resume, one of the instances will be hung in memcpy because the very large copy size is obtained. #3 0x0000ffffa78d5098 in snd_pcm_dsnoop_sync_ptr (pcm=0xaaab06563da0) at pcm_dsnoop.c:158 dsnoop = 0xaaab06563c20 slave_hw_ptr = 64 old_slave_hw_ptr = 533120 avail = 187651522444320 Reason analysis: The root cause that I analysis is that after suspend/resume, one instance will get the SND_PCM_STATE_SUSPENDED state from slave pcm device, then it will do snd_pcm_prepare() and snd_pcm_start(), which will reset the dsnoop->slave_hw_ptr and the hw_ptr of slave pcm device, then the state of this instance is correct. But another instance may not get the SND_PCM_STATE_SUSPENDED state from slave pcm device because slave device may have been recovered by first instance, so the dsnoop->slave_hw_ptr is not reset. but because hw_ptr of slave pcm device has been reset, so there will be a very large "avail" size. Solution: I didn't come up with a fix for this issue, seems there is no easy way to let another instance know this case and reset the dsnoop->slave_hw_ptr, could you please help? Issue URL : https://github.com/alsa-project/alsa-lib/issues/213 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

chancel.liu@nxp.com, shengjiu.wang@nxp.com
by Shengjiu Wang 01 Mar '22

01 Mar '22

Hi Takashi Iwai, Jaroslav Kysela We encountered an issue in the pcm_dsnoop use case, could you please help to have a look? *Issue description:* With two instances for dsnoop type device running in parallel, after suspend/resume, one of the instances will be hung in memcpy because the very large copy size is obtained. #3 0x0000ffffa78d5098 in snd_pcm_dsnoop_sync_ptr (pcm=0xaaab06563da0) at pcm_dsnoop.c:158 dsnoop = 0xaaab06563c20 slave_hw_ptr = 64 old_slave_hw_ptr = 533120 avail = *187651522444320* * Reason analysis: * The root cause that I analysis is that after suspend/resume, one instance will get the SND_PCM_STATE_SUSPENDED state from slave pcm device, then it will do snd_pcm_prepare() and snd_pcm_start(), which will reset the dsnoop->slave_hw_ptr and the hw_ptr of slave pcm device, then the state of this instance is correct. But another instance may not get the SND_PCM_STATE_SUSPENDED state from slave pcm device because slave device may have been recovered by first instance, so the dsnoop->slave_hw_ptr is not reset. but because hw_ptr of slave pcm device has been reset, so there will be a very large "avail" size. *Solution:* I didn't come up with a fix for this issue, seems there is no easy way to let another instance know this case and reset the dsnoop->slave_hw_ptr, could you please help? Best regards Wang shengjiu

1 0

RE: [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr
by David Laight 01 Mar '22

01 Mar '22

From: Linus Torvalds > Sent: 28 February 2022 19:56 > On Mon, Feb 28, 2022 at 4:19 AM Christian König > <christian.koenig(a)amd.com> wrote: > > > > I don't think that using the extra variable makes the code in any way > > more reliable or easier to read. > > So I think the next step is to do the attached patch (which requires > that "-std=gnu11" that was discussed in the original thread). > > That will guarantee that the 'pos' parameter of list_for_each_entry() > is only updated INSIDE the for_each_list_entry() loop, and can never > point to the (wrongly typed) head entry. > > And I would actually hope that it should actually cause compiler > warnings about possibly uninitialized variables if people then use the > 'pos' pointer outside the loop. Except > > (a) that code in sgx/encl.c currently initializes 'tmp' to NULL for > inexplicable reasons - possibly because it already expected this > behavior > > (b) when I remove that NULL initializer, I still don't get a warning, > because we've disabled -Wno-maybe-uninitialized since it results in so > many false positives. > > Oh well. > > Anyway, give this patch a look, and at least if it's expanded to do > "(pos) = NULL" in the entry statement for the for-loop, it will avoid > the HEAD type confusion that Jakob is working on. And I think in a > cleaner way than the horrid games he plays. > > (But it won't avoid possible CPU speculation of such type confusion. > That, in my opinion, is a completely different issue) > > I do wish we could actually poison the 'pos' value after the loop > somehow - but clearly the "might be uninitialized" I was hoping for > isn't the way to do it. > > Anybody have any ideas? > > Linus diff --git a/include/linux/list.h b/include/linux/list.h index dd6c2041d09c..bab995596aaa 100644 --- a/include/linux/list.h +++ b/include/linux/list.h @@ -634,10 +634,10 @@ static inline void list_splice_tail_init(struct list_head *list, * @head: the head for your list. * @member: the name of the list_head within the struct. */ -#define list_for_each_entry(pos, head, member) \ - for (pos = list_first_entry(head, typeof(*pos), member); \ - !list_entry_is_head(pos, head, member); \ - pos = list_next_entry(pos, member)) +#define list_for_each_entry(pos, head, member) \ + for (typeof(pos) __iter = list_first_entry(head, typeof(*pos), member); \ + !list_entry_is_head(__iter, head, member) && (((pos)=__iter),1); \ + __iter = list_next_entry(__iter, member)) /** * list_for_each_entry_reverse - iterate backwards over list of given type. I think you actually want: !list_entry_is_head(__iter, head, member) ? (((pos)=__iter),1) : (((pos) = NULL),0); Which can be done in the original by: !list_entry_is_head(pos, head, member) ? 1 : (((pos) = NULL), 0); Although it would be safer to have (without looking up the actual name): for (item *__item = head; \ __item ? (((pos) = list_item(__item, member)), 1) : (((pos) = NULL), 0); __item = (pos)->member) The local does need 'fixing' to avoid shadowing for nested loops. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)

1 0