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] [day] [month] [year] [list]

Message-ID: <20240116164739.GA93647-robh@kernel.org>
Date: Tue, 16 Jan 2024 10:47:39 -0600
From: Rob Herring <robh@...nel.org>
To: Jerome Brunet <jbrunet@...libre.com>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
	Mark Brown <broonie@...nel.org>,
	Liam Girdwood <lgirdwood@...il.com>,
	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 Wed, Jan 10, 2024 at 02:36:01PM +0100, Jerome Brunet wrote:
> 
> On Wed 10 Jan 2024 at 14:24, Krzysztof Kozlowski <krzysztof.kozlowski@...aro.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.

Why not? If someone comes up with a use for N cells, I'd like to know 
about it which would be more easily seen here than hidden in some device 
specific binding.

That being said, there's a global max of 8 in dtschema already, so 
limiting here doesn't add that much.

Rob