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]
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


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ