linux-kernel - Re: [PATCH v2 1/4] dt-bindings: sound: Add Apple MCA I2S transceiver

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] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 22 Aug 2022 13:59:26 -0500
From:   Rob Herring <robh@...nel.org>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc:     Martin Povišer <povik+lin@...ebit.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        Mark Brown <broonie@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Hector Martin <marcan@...can.st>,
        Sven Peter <sven@...npeter.dev>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        Alyssa Rosenzweig <alyssa@...enzweig.io>,
        asahi@...ts.linux.dev, alsa-devel@...a-project.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/4] dt-bindings: sound: Add Apple MCA I2S transceiver

On Fri, Aug 19, 2022 at 05:17:17PM +0300, Krzysztof Kozlowski wrote:
> On 19/08/2022 17:14, Martin Povišer wrote:
> >>> Since it was brought up last time but I didn’t respond: the
> >>> nonalphabetical order is as the chips were introduced (and
> >>> matches other schemas).
> >>
> >> Sure, just keep that order for future compatibles as well - so always
> >> put them according to verifiable time of market introduction...
> >>
> >> This is very poor reason, instead of alphabetical order. Even worse
> >> reason is repeating wrong pattern just because someone else did it.
> >>
> >> Best regards,
> >> Krzysztof
> >>
> > 
> > I don’t see it nearly as clear-cut. Adding to the end seems pretty
> > foolproof too, but OK, next submission will have it alphabet. ordered.
> 
> The concept is the same everywhere, be it Kconfig, Makefile or other
> lists. If everyone adds at the end, you increase the chances of
> conflicts. Having alphabetical order usually means simultaneous edits
> will happen in different places.

The difference for those cases is there is 0 control of when things are 
added with the source being all independent (different companies). For 
these, it's all one platform family and there's limits as to when one 
source can produce new entries.

I'd kind of like to know timeline order, but alphabetical is the only 
thing we can ever check easily and possibly automate (hint). 

Rob