Received: by 2002:a05:7412:e794:b0:fa:551:50a7 with SMTP id o20csp918004rdd; Wed, 10 Jan 2024 03:37:23 -0800 (PST) X-Google-Smtp-Source: AGHT+IEe3wA/na9Bp8ZMa/dEFlq334pHyoWbC0r5U+XtOMAbUzyZBZavXb0Fic5HM3gFm7WyA3jr X-Received: by 2002:a05:620a:45a8:b0:783:14d4:8ce5 with SMTP id bp40-20020a05620a45a800b0078314d48ce5mr1050743qkb.15.1704886642633; Wed, 10 Jan 2024 03:37:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1704886642; cv=none; d=google.com; s=arc-20160816; b=L62t7cwVDZjkYE7N4D6tEGD+AExSWtMTko/z/r/Y6kQOC7qMdcOLAA67OQnTj5xJrb lqialvlVvaP+Uxq/jZaYQHNANqPmhNj4lbrM1ErIitEZTaN6M6loEeDd8xOI5xqlFq6k /AVZrtqzF8F4i7VdeVU6GrEsgKZDzRl+8lEymtWjMsZT26JFSbigDHUnZvDvlnQWffs+ A0AywoUZDC92IOxYxNjBp47/3x7UFq96abpVgzNIakt4gA9M7UAeERL81ArsokuCIH3m ljPFBmqQAYY3mTax/6e0dHeFR734l0WKRjCYfweW02sUCLRoIvKmxj4YHH9Kfr3Hprkb l08Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-disposition:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:message-id:subject:cc :to:from:date:dkim-signature; bh=mwJrCpsKvuUCqcMvNxsHnQZmtYyfQD9QX3G8uiaffuQ=; fh=3UoOXbixN73CzE8a++YlHw2gb5S6+sbtjSFNBHi1nPs=; b=rfqlC+cmvFHBugreoCIwz0bQ5se6rvWlVf1dHdS5iMIY/1/759EdSkLepiijKWqyhD 8D2RNOuQpFC2pOvW+JJXt8/j1FukrMCqh93IxE/NyR+LcoODyDnJ8fi2qy8lwTOIhKCc GQKTSupcQ+cshVte8+8J+oMRKYXPj6uUfsLBCfMN1ykzmIDNEvNdjZ1PMe0lZbahA7pG 6W2RAeqqnG4BzvIhobRYkakjB6crU3ud5Vt3idpQQe4QNh0zfo+ZmdUMr/WfFRen3qqM w4ZXav82W8XSCX9Gtm0fMoNiXO5+6TXRNs/WfF8PbxqGRzZvmH7FE+Sztkt4UlYc6LLz xEXQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=TLl5KJoI; spf=pass (google.com: domain of linux-kernel+bounces-22101-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-22101-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [2604:1380:45d1:ec00::1]) by mx.google.com with ESMTPS id i3-20020a05620a0a0300b00781afb6db4esi3817362qka.190.2024.01.10.03.37.22 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 Jan 2024 03:37:22 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-22101-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=TLl5KJoI; spf=pass (google.com: domain of linux-kernel+bounces-22101-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-22101-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.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 ny.mirrors.kernel.org (Postfix) with ESMTPS id 61D5E1C24790 for ; Wed, 10 Jan 2024 11:37:22 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id E254A47A7C; Wed, 10 Jan 2024 11:37:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="TLl5KJoI" Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 150AC803; Wed, 10 Jan 2024 11:37:14 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 94CDAC433F1; Wed, 10 Jan 2024 11:37:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1704886634; bh=mwJrCpsKvuUCqcMvNxsHnQZmtYyfQD9QX3G8uiaffuQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=TLl5KJoIiS72N38mQw9egsP0cnZ89Kvj5RF5MUorG0cl7hSslxX8G7NxfXiwkdpyH SA+zfbuR12Cl/uUrInXED9S2i9I/2EdLGrpLU6rsPAV9eXK743H4NTqVBSONGyifJw 7ko/f8B/4v5OjJYiaDcRTMNtOTIixdRa+ATiEf9dqCYDrP1f3SxwnbrzfonaU1lzxE 0hQLPZArQDUy3izg6lsdcnMJnNhnUjHWH6NmBt1V1UfLaaS+9/h8jtJsm+60ZOetI5 hFZKvmBFbmER3Xr7M8JakP5barYxMTf9laImGOteBPBs//hJAOjrsZAD6/fTyHBD1f 3EtCKQ5rHeprA== Date: Wed, 10 Jan 2024 11:37:09 +0000 From: Mark Brown To: Jerome Brunet Cc: Krzysztof Kozlowski , Liam Girdwood , Rob Herring , Krzysztof Kozlowski , Conor Dooley , 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: <7e312b05-857f-40a6-a1a1-a954dfea7044@sirena.org.uk> References: <20240109213812.558492-1-krzysztof.kozlowski@linaro.org> <1ja5pdzb7k.fsf@starbuckisacylon.baylibre.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="uPIbnbsl4a7wx/f4" Content-Disposition: inline In-Reply-To: <1ja5pdzb7k.fsf@starbuckisacylon.baylibre.com> X-Cookie: Do you have lysdexia? --uPIbnbsl4a7wx/f4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 10, 2024 at 12:07:30PM +0100, Jerome Brunet wrote: > On Tue 09 Jan 2024 at 22:38, Krzysztof Kozlowski wrote: >=20 > > 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. --uPIbnbsl4a7wx/f4 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmWegWQACgkQJNaLcl1U h9Dc7wf+P2n83klonD5EiADHNArTPBrzWtVooyEDf3soqckt8MR+DtlIo0460+NS 2oTbfl6e2b1tYShEhraljnpAewMBnsexZWfnszWDt6aMtm1MBQxj0TnK0LTIp6lz CYr5voMqzQtQaJOO2XqdlExuT7oK34tf1JA8yg7699wqsdrrPrYq0cYZw3QOMCJx i0bTfY4dMNNmBahx9aNeoQdIOfu0272dk9Rj9d8U7TwN3vQSFnt0kz3/bswGhjCx gKs81/Kn/sChLbTOzZel4Ctw/AAFBUYpnVsm+JZwpp3ma77LTnmFWw1ogEXq4HZl yEfxszZgp4ylkHQ5WLPSFFkR9D5qHw== =W+Yk -----END PGP SIGNATURE----- --uPIbnbsl4a7wx/f4--