Message ID | 20240109213812.558492-1-krzysztof.kozlowski@linaro.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-21426-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:2411:b0:101:2151:f287 with SMTP id m17csp423762dyi; Tue, 9 Jan 2024 13:38:40 -0800 (PST) X-Google-Smtp-Source: AGHT+IGrz1NZmXGGgwpowAhf5bcYXSaK7CcrQ1cFokMCzk3pJW/zuVX5c1CbqBNagS7Lmze0oYm7 X-Received: by 2002:a17:90a:bb10:b0:28b:fe14:d25c with SMTP id u16-20020a17090abb1000b0028bfe14d25cmr3008795pjr.6.1704836320555; Tue, 09 Jan 2024 13:38:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1704836320; cv=none; d=google.com; s=arc-20160816; b=IUsyvW0TrHQLMHTEfTxeszlaV6zC2daZjbctIdGWg1TOwn0DOCcGmuTxIW9irNVnyz eL1/qhaq+u6MVdHns5//akXp9x9HbhMtiOoQrF0ouodElqHd6e+3aOCBYQyIbjvJErin Lg0WUJdvM+T4AGMu3dlQ40/91vpk3Kwp/u6I9HzpMmMfR440YTt3P+4y2qCrq5B8T/Hh XP+Ne2B+/33s7WPhgOd2yYjFLUsk3QIZ8Sq6xF8pxXC+KmtBO/DM7rSharVdET5151od 8L/+VibNKzlvqEJF04KzoxihaTAESeVLVwUWPTTLXKucAm/Ma9VYJgx2YxE95snhRw3D F1oQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from:dkim-signature; bh=A5G3kOVOJ3YPkVZuV6/moOWckQ3gnsEMdzz/Vic7oRo=; fh=IiBOHzvJhLkWFFK1AYmqhtGrjARhnUjho+HxkENoP3M=; b=tuICznLwTdLXS5dxiBMzOHqE3F9bK4SZbHyHmaODy7E0M2V9hTHw6aEdsYhBV9ywRj E8o9biToKLncRoZwuTXWl6fGMqMuojudgFf/HG8YMbTCDT03Xund9Eyug3pwkG45p8A/ ft7WVuYJzTX0r2XnSGUznjaWr1N0X95ZkfcOyiendOvllpmk1yObR2CytrVSNy00CArM xTcbBe88+ztOzTbk31dZxVMtDsZhPt5c8247d9sVNKcTCWk27L1xksQIn4GmLD2P9Ff7 5FWe9hWCHQHtYyU187UHdm3r/anV6HCWyoTker4E7YZb2Nz94zZZeUDAvzWYvlvxC8jB c8rA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=b27uJhjV; spf=pass (google.com: domain of linux-kernel+bounces-21426-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-21426-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [2604:1380:45e3:2400::1]) by mx.google.com with ESMTPS id gv3-20020a17090b11c300b0028c1df2464asi2129624pjb.127.2024.01.09.13.38.40 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 09 Jan 2024 13:38:40 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-21426-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=b27uJhjV; spf=pass (google.com: domain of linux-kernel+bounces-21426-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-21426-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 4FA6A285980 for <ouuuleilei@gmail.com>; Tue, 9 Jan 2024 21:38:40 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 7F8293DBB7; Tue, 9 Jan 2024 21:38:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="b27uJhjV" Received: from mail-ej1-f46.google.com (mail-ej1-f46.google.com [209.85.218.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 729143DB84 for <linux-kernel@vger.kernel.org>; Tue, 9 Jan 2024 21:38:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org Received: by mail-ej1-f46.google.com with SMTP id a640c23a62f3a-a294295dda3so394760366b.0 for <linux-kernel@vger.kernel.org>; Tue, 09 Jan 2024 13:38:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1704836296; x=1705441096; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=A5G3kOVOJ3YPkVZuV6/moOWckQ3gnsEMdzz/Vic7oRo=; b=b27uJhjVnSbkpq4sw6ycBiWAcU0t46PWMGyqUm/FqJKSOZfSU0JFN5h4zdh+enaWWj cvegy78/gqpr3LeQSq5KUp1ft+NgZn+Vf/0NUltrIz5meV4cITIFqrMiaCJn6M4rokUZ W5vvISyaWjfwkb65pbobiwi/yD52IlQZfVg8c0SSurQ0a25IBhT46rAhaHNIA8pJQfed ACrLjYWoL7Mxe2UVTDOFQVionzBD3XFwAHqNMosx77s7WWYDgI511j2x+4IHE1j3zYRx jWfJo0yqYNOgjcAjWkVAwYlSVLzZhT0GbfGK8udHYmzeJdcmWK2jHXRQ0NV2EPdFI9KQ r8Uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704836296; x=1705441096; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=A5G3kOVOJ3YPkVZuV6/moOWckQ3gnsEMdzz/Vic7oRo=; b=pbH1KsUCcv3bn38hWUUciJ4ed7O0pblHaJxpIF03e/ydP1XBcIesFNfiq72k6vgqam LQrX/gF39deSDelwoAtSy5mM/6gboNParGRsOfsq4ylyFsFWCWe5xZcPo7+xzQuutd5k u7gT9lNnlUVXj/ywWPtzIp9naLANMbi1Ou7wEmU3l24WbjTOxMkenhzXYuqsTPFhF6Jl OszLYSqnq0ratJYV2srYUZi2XQwIasiT+5pXbgWhxibkcLKOzzeI5la3XuG9Tkj4pPVf /4ya5gm03p/P/4onwnti42FqQ0rsCxkKQCPo7fUPlFX4en/I20yNeKEsl8qWmX1bUNA0 Uzcw== X-Gm-Message-State: AOJu0YzWDtTpxBwhu/hw7lgbchzTdq8gPDVAwtZlBMF4lSyg95lZKU5p 9nl4gcI1FKWNmlTUmVw5zdyoESaqtbOQRw== X-Received: by 2002:a17:906:39c1:b0:a28:c06d:2e12 with SMTP id i1-20020a17090639c100b00a28c06d2e12mr28962eje.21.1704836295878; Tue, 09 Jan 2024 13:38:15 -0800 (PST) Received: from krzk-bin.. ([178.197.223.112]) by smtp.gmail.com with ESMTPSA id lf11-20020a170907174b00b00a26ac5e3683sm1420197ejc.100.2024.01.09.13.38.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 09 Jan 2024 13:38:15 -0800 (PST) From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> To: Liam Girdwood <lgirdwood@gmail.com>, Mark Brown <broonie@kernel.org>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Conor Dooley <conor+dt@kernel.org>, Jerome Brunet <jbrunet@baylibre.com>, linux-sound@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Subject: [PATCH] ASoC: dt-bindings: dai-common: Narrow possible sound-dai-cells Date: Tue, 9 Jan 2024 22:38:12 +0100 Message-Id: <20240109213812.558492-1-krzysztof.kozlowski@linaro.org> X-Mailer: git-send-email 2.34.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1787650449591607799 X-GMAIL-MSGID: 1787650449591607799 |
Series |
ASoC: dt-bindings: dai-common: Narrow possible sound-dai-cells
|
|
Commit Message
Krzysztof Kozlowski
Jan. 9, 2024, 9:38 p.m. UTC
Instead of accepting any value for sound-dai-cells, the common DAI
properties schema should narrow them to sane choice.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
Mostly sound-dai-cells are 0 or 1, but
Documentation/devicetree/bindings/sound/amlogic,aiu.yaml has value of 2.
---
Documentation/devicetree/bindings/sound/dai-common.yaml | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Comments
On Tue 09 Jan 2024 at 22:38, Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote: > Instead of accepting any value for sound-dai-cells, the common DAI > properties schema should narrow them to sane choice. > > Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> > Adding a constraint solely based on current usage feels wrong. 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. It is up to the device specific bindings to define that value. 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' > --- > > Mostly sound-dai-cells are 0 or 1, but > Documentation/devicetree/bindings/sound/amlogic,aiu.yaml has value of 2. > --- > Documentation/devicetree/bindings/sound/dai-common.yaml | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/sound/dai-common.yaml b/Documentation/devicetree/bindings/sound/dai-common.yaml > index 1aed2f0f1775..6db35887cbe6 100644 > --- a/Documentation/devicetree/bindings/sound/dai-common.yaml > +++ b/Documentation/devicetree/bindings/sound/dai-common.yaml > @@ -13,6 +13,7 @@ allOf: > - $ref: component-common.yaml# > > properties: > - '#sound-dai-cells': true > + '#sound-dai-cells': > + enum: [0, 1, 2] > > additionalProperties: true
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@linaro.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. > 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. > It is up to the device specific bindings to define that value. > 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' I tend to agree.
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@linaro.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
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 override limit to 0 and have all the devices that need 1 override as well.
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. Best regards, Krzysztof
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. I agree allowing 0, 1, 2 is a reasonable choice, for now. However it is not correct and has not technical justification. Trying to list every possibly value for something that is not limited is bound to be wrong. The commit description says you don't want to accept any value. A default value is an alternate way to do that. It does not require a justification because it is just convenience. If someone fail to it document properly, it will be picked up by the checking scripts. > Best regards, > Krzysztof
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
diff --git a/Documentation/devicetree/bindings/sound/dai-common.yaml b/Documentation/devicetree/bindings/sound/dai-common.yaml index 1aed2f0f1775..6db35887cbe6 100644 --- a/Documentation/devicetree/bindings/sound/dai-common.yaml +++ b/Documentation/devicetree/bindings/sound/dai-common.yaml @@ -13,6 +13,7 @@ allOf: - $ref: component-common.yaml# properties: - '#sound-dai-cells': true + '#sound-dai-cells': + enum: [0, 1, 2] additionalProperties: true