From: Rob Herring <robh@kernel.org>
To: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc: devicetree@vger.kernel.org, alsa-devel@alsa-project.org,
"Philipp Zabel" <p.zabel@pengutronix.de>,
"Sven Peter" <sven@svenpeter.dev>,
"Hector Martin" <marcan@marcan.st>,
"Liam Girdwood" <lgirdwood@gmail.com>,
linux-kernel@vger.kernel.org, "Mark Brown" <broonie@kernel.org>,
asahi@lists.linux.dev,
"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
"Martin Povišer" <povik+lin@cutebit.org>,
"Alyssa Rosenzweig" <alyssa@rosenzweig.io>
Subject: Re: [PATCH v2 1/4] dt-bindings: sound: Add Apple MCA I2S transceiver
Date: Mon, 22 Aug 2022 13:59:26 -0500 [thread overview]
Message-ID: <20220822185926.GA146730-robh@kernel.org> (raw)
In-Reply-To: <a0a34ac8-4b62-4e69-f16f-7a51132a3987@linaro.org>
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
WARNING: multiple messages have this Message-ID (diff)
From: Rob Herring <robh@kernel.org>
To: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc: "Martin Povišer" <povik+lin@cutebit.org>,
"Liam Girdwood" <lgirdwood@gmail.com>,
"Mark Brown" <broonie@kernel.org>,
"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
"Hector Martin" <marcan@marcan.st>,
"Sven Peter" <sven@svenpeter.dev>,
"Philipp Zabel" <p.zabel@pengutronix.de>,
"Alyssa Rosenzweig" <alyssa@rosenzweig.io>,
asahi@lists.linux.dev, alsa-devel@alsa-project.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/4] dt-bindings: sound: Add Apple MCA I2S transceiver
Date: Mon, 22 Aug 2022 13:59:26 -0500 [thread overview]
Message-ID: <20220822185926.GA146730-robh@kernel.org> (raw)
In-Reply-To: <a0a34ac8-4b62-4e69-f16f-7a51132a3987@linaro.org>
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
next prev parent reply other threads:[~2022-08-22 19:00 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-19 12:54 [PATCH v2 0/4] ASoC platform driver for Apple MCA Martin Povišer
2022-08-19 12:54 ` Martin Povišer
2022-08-19 12:54 ` [PATCH v2 1/4] dt-bindings: sound: Add Apple MCA I2S transceiver Martin Povišer
2022-08-19 12:54 ` Martin Povišer
2022-08-19 12:58 ` Martin Povišer
2022-08-19 12:58 ` Martin Povišer
2022-08-19 13:08 ` Krzysztof Kozlowski
2022-08-19 13:08 ` Krzysztof Kozlowski
2022-08-19 13:09 ` Krzysztof Kozlowski
2022-08-19 13:09 ` Krzysztof Kozlowski
2022-08-19 14:14 ` Martin Povišer
2022-08-19 14:14 ` Martin Povišer
2022-08-19 14:17 ` Krzysztof Kozlowski
2022-08-19 14:17 ` Krzysztof Kozlowski
2022-08-22 18:59 ` Rob Herring [this message]
2022-08-22 18:59 ` Rob Herring
2022-08-19 12:54 ` [PATCH v2 2/4] arm64: dts: apple: t8103: Add MCA and its support Martin Povišer
2022-08-19 12:54 ` Martin Povišer
2022-08-19 13:12 ` Krzysztof Kozlowski
2022-08-19 13:12 ` Krzysztof Kozlowski
2022-08-19 14:24 ` Martin Povišer
2022-08-19 14:24 ` Martin Povišer
2022-08-23 11:02 ` Krzysztof Kozlowski
2022-08-23 11:02 ` Krzysztof Kozlowski
2022-08-19 12:54 ` [PATCH v2 3/4] ASoC: apple: mca: Start new platform driver Martin Povišer
2022-08-19 12:54 ` Martin Povišer
2022-08-22 17:39 ` Mark Brown
2022-08-22 17:39 ` Mark Brown
2022-08-23 7:33 ` Martin Povišer
2022-08-23 7:33 ` Martin Povišer
2022-08-23 11:31 ` Mark Brown
2022-08-23 11:31 ` Mark Brown
2022-08-23 11:51 ` Martin Povišer
2022-08-23 11:51 ` Martin Povišer
2022-08-23 11:53 ` Martin Povišer
2022-08-23 11:53 ` Martin Povišer
2022-08-19 12:54 ` [PATCH v2 4/4] ASoC: apple: mca: Add locks on foreign cluster access Martin Povišer
2022-08-19 12:54 ` Martin Povišer
2022-08-22 17:45 ` Mark Brown
2022-08-22 17:45 ` Mark Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220822185926.GA146730-robh@kernel.org \
--to=robh@kernel.org \
--cc=alsa-devel@alsa-project.org \
--cc=alyssa@rosenzweig.io \
--cc=asahi@lists.linux.dev \
--cc=broonie@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=krzysztof.kozlowski@linaro.org \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=marcan@marcan.st \
--cc=p.zabel@pengutronix.de \
--cc=povik+lin@cutebit.org \
--cc=sven@svenpeter.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.