From: Jerome Brunet <jbrunet@baylibre.com>
To: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc: Mark Brown <broonie@kernel.org>,
Jerome Brunet <jbrunet@baylibre.com>,
Liam Girdwood <lgirdwood@gmail.com>,
Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Conor Dooley <conor+dt@kernel.org>,
linux-sound@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ASoC: dt-bindings: dai-common: Narrow possible sound-dai-cells
Date: Wed, 10 Jan 2024 14:36:01 +0100 [thread overview]
Message-ID: <1jjzohxpl7.fsf@starbuckisacylon.baylibre.com> (raw)
In-Reply-To: <445daac6-841a-4335-9b53-689e5bd2530c@linaro.org>
On Wed 10 Jan 2024 at 14:24, Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote:
> On 10/01/2024 13:57, Mark Brown wrote:
>> On Wed, Jan 10, 2024 at 01:51:03PM +0100, Krzysztof Kozlowski wrote:
>>> On 10/01/2024 12:37, Mark Brown wrote:
>>>> On Wed, Jan 10, 2024 at 12:07:30PM +0100, Jerome Brunet wrote:
>>
>>>>> If restricting things here is really important, defaulting to 0 (with a
>>>>> comment explaining it) and letting actual devices then override the
>>>>> value would feel less 'made up'
>>
>>> Wait, what do you mean by "letting actual devices then override"? It's
>>> already like this. Nothing changed. What do you refer to?
>>
>> The suggestion is that instead of limiting to 1 and having one device
>
> Nothing limits here to 0. I limit from all technically possible values
> to reasonable subset.
>
>> override limit to 0 and have all the devices that need 1 override as
>> well.
>
> I don't think that actual default value for this should be provided.
> This should be conscious choice when writing bindings and driver.
> Similarly we do already for some other #cells:
> #io-channel-cells, address/size-cells (dtschema), #mux-control-cells and
> others.
>
> I agree we do not restrict all of them, though. However I do not see
> single reason to allow developers use 3 as #sound-dai-cells.
>
Similarly, I do not see a reason to forbid it.
Submitter should not have to update the generic bindings every time we
come up with something new.
I agree allowing 0, 1, 2 is a reasonable choice, for now. However it is
not correct and has not technical justification.
Trying to list every possibly value for something that is not limited
is bound to be wrong.
The commit description says you don't want to accept any value.
A default value is an alternate way to do that.
It does not require a justification because it is just convenience.
If someone fail to it document properly, it will be picked up by the
checking scripts.
> Best regards,
> Krzysztof
--
Jerome
next prev parent reply other threads:[~2024-01-10 13:52 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-09 21:38 [PATCH] ASoC: dt-bindings: dai-common: Narrow possible sound-dai-cells Krzysztof Kozlowski
2024-01-10 11:07 ` Jerome Brunet
2024-01-10 11:37 ` Mark Brown
2024-01-10 12:51 ` Krzysztof Kozlowski
2024-01-10 12:57 ` Mark Brown
2024-01-10 13:24 ` Krzysztof Kozlowski
2024-01-10 13:36 ` Jerome Brunet [this message]
2024-01-16 16:47 ` Rob Herring
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=1jjzohxpl7.fsf@starbuckisacylon.baylibre.com \
--to=jbrunet@baylibre.com \
--cc=broonie@kernel.org \
--cc=conor+dt@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=linux-sound@vger.kernel.org \
--cc=robh+dt@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox