Re: [PATCH] ASoC: meson: axg-tdm-formatter: Use guard() for mutex locks

Bui Duc Phuc <[email protected]>
Newsgroups org.infradead.lists.linux-amlogic,org.infradead.lists.linux-arm-kernel,org.kernel.vger.linux-kernel,org.kernel.vger.linux-sound
Message-ID <CAABR9nGQt0zsH2McjOFO91tS-CHsudzioxCkPvbkgmTyfKVo=Q@mail.gmail.com>
Hi Jerome,

Thank you for the review and for the Reviewed-by tag.

>
> The code is not better or worse with the change but you went through the
> trouble of doing so, if Mark is fine with it, let's have it
>
> Reviewed-by: Jerome Brunet <[email protected]>
>

Regarding the point about whether the change makes the code better or worse,
I have sent an additional patch to address related cleanup in the same area:

https://lore.kernel.org/all/[email protected]/

Would appreciate your review on that as well.

While looking into the Meson ASoC probe paths,
I noticed a few consistency issues that seem to appear across multiple drivers:

1. Mixed usage of dev_err_probe() and dev_err() in probe error paths.

2. Inconsistent error message formatting: some messages start with lowercase
   ("failed to init..."), while others start with uppercase ("Failed
to register...").

3. In aiu_probe(), error paths for IRQ retrieval do not provide
additional context,
    making it harder to identify which resource failed:

   aiu->i2s.irq = platform_get_irq_byname(pdev, "i2s");
   if (aiu->i2s.irq < 0)
           return aiu->i2s.irq;

   aiu->spdif.irq = platform_get_irq_byname(pdev, "spdif");
   if (aiu->spdif.irq < 0)
           return aiu->spdif.irq;

4 ......

Do you think addressing these issues would improve readability and
maintainability of the Meson codebase over time?
Or is it generally preferred to leave these kinds of consistency
improvements untouched unless a functional bug is being fixed?

Best regards,
Phuc

_______________________________________________
linux-amlogic mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-amlogic
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.