From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
To: Mark Brown <broonie@kernel.org>, Jerome Brunet <jbrunet@baylibre.com>
Cc: 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 13:51:03 +0100 [thread overview]
Message-ID: <f9f5df54-dbeb-4246-b30f-52f3db7d94b3@linaro.org> (raw)
In-Reply-To: <7e312b05-857f-40a6-a1a1-a954dfea7044@sirena.org.uk>
On 10/01/2024 12:37, Mark Brown wrote:
> On Wed, Jan 10, 2024 at 12:07:30PM +0100, Jerome Brunet wrote:
>> On Tue 09 Jan 2024 at 22:38, Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote:
>>
>>> Instead of accepting any value for sound-dai-cells, the common DAI
>>> properties schema should narrow them to sane choice.
>
>> Adding a constraint solely based on current usage feels wrong.
Current usage comes from current and past experience. There is no upper
limit in theory, but there is a limit which we found reasonable.
>
>> A DAI provider in its generic form must have the sound-dai-cells to
>> provide one. It says nothing about how many parameters an actual device
>> might need. That is the idea behind this binding.
Just like with every #cells. Why sound should be different?
>
>> It is up to the device specific bindings to define that value.
And device specific bindings define specific value applicable to the
device. From allowed choice of some reasonable values.
>
>> 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?
Best regards,
Krzysztof
next prev parent reply other threads:[~2024-01-10 12:51 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 [this message]
2024-01-10 12:57 ` Mark Brown
2024-01-10 13:24 ` Krzysztof Kozlowski
2024-01-10 13:36 ` Jerome Brunet
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=f9f5df54-dbeb-4246-b30f-52f3db7d94b3@linaro.org \
--to=krzysztof.kozlowski@linaro.org \
--cc=broonie@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=jbrunet@baylibre.com \
--cc=krzysztof.kozlowski+dt@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;
as well as URLs for NNTP newsgroup(s).