[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a0a34ac8-4b62-4e69-f16f-7a51132a3987@linaro.org>
Date: Fri, 19 Aug 2022 17:17:17 +0300
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Martin Povišer <povik+lin@...ebit.org>
Cc: Liam Girdwood <lgirdwood@...il.com>,
Mark Brown <broonie@...nel.org>,
Rob Herring <robh+dt@...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 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.
Best regards,
Krzysztof
Powered by blists - more mailing lists