From mboxrd@z Thu Jan 1 00:00:00 1970 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 45E1E37888; Mon, 18 Dec 2023 14:59:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="mSbBcYtI" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 30277C433C8; Mon, 18 Dec 2023 14:59:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1702911568; bh=+s1PxLoBbDNRFaBMX1KOfgXL4tbGv/n20FEjafyPq/w=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=mSbBcYtIEC/E7RqBQIzkCxec5TKgazZsWXYPY9+enwlKZ6OrEtXBMl8SgdPgJxfni krjGAU88aSHxxRA9x2MosUdLH2JQEF3QyLCBsR4LT//axdCB2DPmzwqsq8FQ9OuVrQ 9FLgC5B75iasJpQCBSSE/PM26xfwWhdbZy81d6LhGHghtD+3r8iDWC07xhx6g+gh4p h1ttAeppZzSTCNU8XIlDlD1c8K//wMRQYcfd1poIbVGlHSBJGByodmP+Xa7zynYPx7 dKgH4hQkK0Ik3hIiPZyIbjUigosGJhLSxyisitYnEJ+EFf1Yf/bmYq+R7HPmtThshI dXPcLYPG7K52A== Date: Mon, 18 Dec 2023 14:59:20 +0000 From: Conor Dooley To: Cristian Ciocaltea Cc: Samuel Holland , Jessica Clarke , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Emil Renner Berthing , Samin Guo , Paul Walmsley , Palmer Dabbelt , Albert Ou , Hal Feng , Michael Turquette , Stephen Boyd , Alexandre Torgue , Jose Abreu , Maxime Coquelin , Richard Cochran , Giuseppe Cavallaro , netdev@vger.kernel.org, "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , LKML , linux-riscv , linux-clk@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, kernel@collabora.com Subject: Re: [PATCH v3 2/9] dt-bindings: net: starfive,jh7110-dwmac: Add JH7100 SoC compatible Message-ID: <20231218-snowcap-charter-f8c75312eaa9@spud> References: <20231215204050.2296404-1-cristian.ciocaltea@collabora.com> <20231215204050.2296404-3-cristian.ciocaltea@collabora.com> <65fd52f1-6861-42b0-9148-266766d054b1@sifive.com> <6c62e3b2-acde-4580-9b67-56683289e45e@collabora.com> <20231217-spray-livestock-a59d630b751e@spud> Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="xehaJyWNZIrFr2oM" Content-Disposition: inline In-Reply-To: --xehaJyWNZIrFr2oM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > > Won't this also relax the naming for all devices that allow a single > > reset, but expect the stmmaceth one? I'm not sure that that actually > > matters, I think the consumer bindings have constraints themselves. >=20 > Before commit 843f603762a5 ("dt-bindings: net: snps,dwmac: Add 'ahb' > reset/reset-name"), the 'stmmaceth' was the only possible option, hence > there was no need for any constraints on the consumer bindings. But > afterwards it was allowed to use both resets, hence I think the bindings > should have been updated at that time by adding 'maxItems: 1' to prevent > using the 2nd reset. >=20 > I could fix this in a separate series, if it's not something mandatory > to be handled here. If it is not introduced by this series, I don't see why it could not be handled separately if needed. --xehaJyWNZIrFr2oM Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRh246EGq/8RLhDjO14tDGHoIJi0gUCZYBeSAAKCRB4tDGHoIJi 0kaHAQDOEcbXi7+qAEGh2DmnasVoZMuRlaf7aM8UbL0TedMfrAEAz4ujNDzOgg49 iA4wb0r9fYms/C/CCKtbwb34l7U9Wg8= =8B0i -----END PGP SIGNATURE----- --xehaJyWNZIrFr2oM--