linux-kernel - Re: [PATCH v2 7/8] ASoC: dt-bindings: mediatek,mt8188-mt6359: Add DMIC backend to dai-link

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <bed0195c-8691-4269-9d29-7fb820087f03@kernel.org>
Date: Wed, 26 Feb 2025 16:00:35 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Nícolas F. R. A. Prado <nfraprado@...labora.com>
Cc: Liam Girdwood <lgirdwood@...il.com>, Mark Brown <broonie@...nel.org>,
 Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.com>,
 Matthias Brugger <matthias.bgg@...il.com>,
 AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
 Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>, Trevor Wu <trevor.wu@...iatek.com>,
 kernel@...labora.com, linux-sound@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
 linux-mediatek@...ts.infradead.org, devicetree@...r.kernel.org
Subject: Re: [PATCH v2 7/8] ASoC: dt-bindings: mediatek,mt8188-mt6359: Add
 DMIC backend to dai-link

On 26/02/2025 14:30, Nícolas F. R. A. Prado wrote:
> On Wed, Feb 26, 2025 at 09:22:29AM +0100, Krzysztof Kozlowski wrote:
>> On Tue, Feb 25, 2025 at 11:33:53AM -0300, Nícolas F. R. A. Prado wrote:
>>> MT8188 platforms also have DMIC DAIs, which were previously undescribed.
>>> Add DMIC_BE as a possible backend for the dai-link property.
>>>
>>> Signed-off-by: Nícolas F. R. A. Prado <nfraprado@...labora.com>
>>> ---
>>>  Documentation/devicetree/bindings/sound/mediatek,mt8188-mt6359.yaml | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/sound/mediatek,mt8188-mt6359.yaml b/Documentation/devicetree/bindings/sound/mediatek,mt8188-mt6359.yaml
>>> index 362e729b51b43ec16716aee70ad736420def81f3..8c77e7f68ad7b6f5b88b53cedccb291139a2eeea 100644
>>> --- a/Documentation/devicetree/bindings/sound/mediatek,mt8188-mt6359.yaml
>>> +++ b/Documentation/devicetree/bindings/sound/mediatek,mt8188-mt6359.yaml
>>> @@ -62,6 +62,7 @@ patternProperties:
>>>              - PCM1_BE
>>>              - DL_SRC_BE
>>>              - UL_SRC_BE
>>> +            - DMIC_BE
>>
>> Any reason why you keep adding to the end of the lists but not
>> alphabetically sorted? It's enum, so it's expected to be sorted which
>> reduces conflicts between edits. Last commit already broke sorting :/
> 
> Well, I wasn't aware enums were supposed to be sorted. That doesn't seem to be

If the code is sorted, which was the case here, why there has to be an
explicit rule telling you must sort it? Just keep existing style.

> documented anywhere. In fact, in example-schema.yaml the enum is not sorted [1].

Way of avoiding conflicts in some sort of lists is valid more or less
everywhere.

> So it'd be great to update that example to follow that rule as well as
> explicitly document it. Maybe even a dt-binding check that checks for this?
> That'll make it much easier to learn about and follow this rule :).

That would lead to numerous exceptions, because some places choose to
sort not alphanumerically and that's fine as well.

If checkpatch was no written in Perl, I would be happy to grow the tool,
but from all cryptic languages to re-learn again Rust is much higher
than Perl.

> 
> I don't think it'd be worth it to send another patch just to fix sorting in
> this case as it's already been merged, but I'll keep this in mind whenever I
> send future dt-binding patches.

Indeed, I found only later that Mark applied.

> 
> Thanks,
> Nícolas
> 
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/example-schema.yaml#n52

Best regards,
Krzysztof