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
