Received-SPF: pass (google.com: domain of linux-kernel+bounces-27588-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Date: Tue, 16 Jan 2024 10:47:39 -0600
From: Rob Herring <robh@kernel.org>
To: Jerome Brunet <jbrunet@baylibre.com>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
	Mark Brown <broonie@kernel.org>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Conor Dooley <conor+dt@kernel.org>, linux-sound@vger.kernel.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ASoC: dt-bindings: dai-common: Narrow possible
 sound-dai-cells
Message-ID: <20240116164739.GA93647-robh@kernel.org>
References: <20240109213812.558492-1-krzysztof.kozlowski@linaro.org>
 <1ja5pdzb7k.fsf@starbuckisacylon.baylibre.com>
 <7e312b05-857f-40a6-a1a1-a954dfea7044@sirena.org.uk>
 <f9f5df54-dbeb-4246-b30f-52f3db7d94b3@linaro.org>
 <3b1b956b-985c-45f2-bda3-018aaf897295@sirena.org.uk>
 <445daac6-841a-4335-9b53-689e5bd2530c@linaro.org>
 <1jjzohxpl7.fsf@starbuckisacylon.baylibre.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1jjzohxpl7.fsf@starbuckisacylon.baylibre.com>

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