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: Windows password security audit tool. GUI, reports in PDF.

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

Date: Wed, 10 Jan 2024 14:24:26 +0100
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Mark Brown <broonie@...nel.org>
Cc: Jerome Brunet <jbrunet@...libre.com>, 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 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.

Best regards,
Krzysztof