linux-kernel - Re: [PATCH] ASoC: dt-bindings: dai-common: Narrow possible sound-dai-cells

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <f9f5df54-dbeb-4246-b30f-52f3db7d94b3@linaro.org>
Date: Wed, 10 Jan 2024 13:51:03 +0100
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Mark Brown <broonie@...nel.org>, Jerome Brunet <jbrunet@...libre.com>
Cc: Liam Girdwood <lgirdwood@...il.com>, Rob Herring <robh+dt@...nel.org>,
 Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
 Conor Dooley <conor+dt@...nel.org>, linux-sound@...r.kernel.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ASoC: dt-bindings: dai-common: Narrow possible
 sound-dai-cells

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@...aro.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