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

[Rob Herring <robh@xxxxxxxxxx>]

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@xxxxxxxxxx> 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