From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 943C5D46BFA for ; Wed, 28 Jan 2026 21:15:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: In-Reply-To:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Reply-To:Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date :Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=FLkoljDaus6hpalVhKQYw332sSWmf1/rmLwWJCTHHjQ=; b=a5AQAozA3GubzshTLgVUhG+bYs LiSKBpu/rLm54mZJErQcJHgyVX6VawQVH4Hi7Js4ehvQBexHxJ6bC4n8E/HT8vGzCLICfAGTkOb7/ 09IzVqenXwLLRgkPp+vPHfa+dG3vD+N5R2uZPoX8Vf43DfiFy0awFMEoefbmrMkWrJlYzq2/IxMUR 5tnaYFjPeucEgqZ9cdJQsY0VCA1v/3Y1xTw3BCXiOiLzC5yfqUiH4TaUHYf7IxCA/KvtwnNho+A1G Un6Jz8QqDuBDVZL+akIuv6UdZIpHLyMVocXq3Y62xoQnIPvjvtlziHTbNIUTHO2WPuPHM2fRrf6AD xu/atplg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1vlCsc-0000000GpD4-38H1; Wed, 28 Jan 2026 21:15:14 +0000 Received: from sea.source.kernel.org ([2600:3c0a:e001:78e:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1vlCsa-0000000GpCg-2VC7 for linux-riscv@lists.infradead.org; Wed, 28 Jan 2026 21:15:13 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id AE61F44359; Wed, 28 Jan 2026 21:15:11 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B8469C4CEF7; Wed, 28 Jan 2026 21:15:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1769634911; bh=OQDAe7kHqwluS4hvEjYu/+eXBFZjq8g2bIaji/mTcx8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Fb50FeRisHcFDRsGBhTQLrWYZFufTLrCL96ygW0yYMhG9zuixvQaD69oz/1ET+5m2 OCUEjozwYGW20GO/bf607/mnKqah0HLfLMZUNBXHFppXCLaJ5DqvTWmA7vQtlFH/YO vS72NOqYPyOLuNaIc7TwFD9F1gzi+GhLJDqIMSHtS2WqwT8lsKhAsKqJb0qBlGWJkF PnjXYS1hJeEy8576+XYo0OvhLubDAXEwMvoGsvvuN31Cg1JuIw8eJusfgrGe+fWRzq QupRDPXL1ZH66+AUudiLVUGsFyMcAsKTEvzm+T7dt4an4MmLsFRDsS3O4FT0jKbkab xKp1ghfH4tzoA== Date: Wed, 28 Jan 2026 21:15:05 +0000 From: Conor Dooley To: Anirudh Srinivasan Cc: Drew Fustini , Joel Stanley , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Michael Turquette , Stephen Boyd , Philipp Zabel , linux-riscv@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-clk@vger.kernel.org, joel@jms.id.au, fustini@kernel.org, mpe@kernel.org, mpe@oss.tenstorrent.com, npiggin@oss.tenstorrent.com, agross@kernel.org, agross@oss.tenstorrent.com, bmasney@redhat.com Subject: Re: [PATCH v3 1/3] dt-bindings: clk: tenstorrent: Add tenstorrent,atlantis-prcm Message-ID: <20260128-whomever-account-2edbfd9fa227@spud> References: <20260126-atlantis-clocks-v3-0-b016135551b7@oss.tenstorrent.com> <20260126-atlantis-clocks-v3-1-b016135551b7@oss.tenstorrent.com> <20260127-mystify-carmaker-150aa3fcd6c6@spud> <20260128-duckling-confess-88e64fabe752@spud> <20260128-nappy-repaint-e464d9964134@spud> MIME-Version: 1.0 In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20260128_131512_677797_D67FD921 X-CRM114-Status: GOOD ( 30.17 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6675152081899038691==" Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org --===============6675152081899038691== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="PyF6LdaTjELP3nym" Content-Disposition: inline --PyF6LdaTjELP3nym Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 28, 2026 at 03:01:11PM -0600, Anirudh Srinivasan wrote: > Hi Conor, >=20 > On Wed, Jan 28, 2026 at 11:32=E2=80=AFAM Conor Dooley = wrote: > > > > On Wed, Jan 28, 2026 at 09:42:42AM -0600, Anirudh Srinivasan wrote: > > > Hi Conor, > > > > > > On Wed, Jan 28, 2026 at 9:02=E2=80=AFAM Conor Dooley wrote: > > > > > > > > On Tue, Jan 27, 2026 at 05:39:33PM -0600, Anirudh Srinivasan wrote: > > > > > Hi Conor, > > > > > > > > > > On Tue, Jan 27, 2026 at 1:58=E2=80=AFPM Conor Dooley wrote: > > > > > > > > > > > > On Mon, Jan 26, 2026 at 03:07:14PM -0600, Anirudh Srinivasan wr= ote: > > > > > > > Document bindings for Tenstorrent Atlantis PRCM that manages = clocks > > > > > > > and resets. This block is instantiated 4 times in the SoC. > > > > > > > This commit documents the clocks from the RCPU PRCM block. > > > > > > > > > > > > > > Signed-off-by: Anirudh Srinivasan > > > > > > > --- > > > > > > This is pretty suspect sounding, if the PLLs for !rcpu are cont= rolled in > > > > > > the rcpu register region, why is it not a clock parent for the = !rcpu > > > > > > prcms? > > > > > >=20 > > Right. Looking at the mail from Krzysztof, I suspect he meant to > > completely document and explain the rcpu prcm, not all of the prcms (he > > couldn't really know they existed, based on your v1, right?). > > I'd suggest you drop the !rcpu stuff for now, and submit it when you > > have the driver for them ready to go. That's typically what's done to > > avoid introducing bindings that need to be changed once the driver > > actually turns up, since as you say you've not actually tested the > > driver for those prcms. >=20 > Okay, thank you for clarifying that. I think I interpreted the > original comments as "once you add bindings, you cannot change them > later". I guess the changes I have wouldn't break backward > compatibility, so they'd probably be fine. I will do this the way you > suggest. Adding new compatibles is okay, they can have new properties and new behaviours as long as the existing devices keeps working the way they used to. It's also okay to change the way existing devices work, by adding new *optional* properties after the binding was written, but of course we'd rather all these optional properties are documented from the get-go. When we ask people to make the binding complete, we generally are talking about optional features (though usually things like SoC clock controllers don't have them) or for syscon/multi-function devices to document all of the peripherals that they contain. It happens a lot that someone comes along claiming a memory region is a clock controller, or pinctrl and it turns out that there's also a temperature sensor or a reset controller in there too which causes problems down the line if the binding isn't written to account for that. Obviously there are exceptions, and new required properties can be introduced, by there needs to be a good reason to do so. Here's an example from the last few days where the new property was required for the driver to discover the full-scale range of the device, without which it could not function correctly: https://lore.kernel.org/all/20260128153824.3679187-6-o.rempel@pengutronix.d= e/ New required properties for an existing compatible usually have to meet a threshold somewhere around "the driver doesn't work properly without it" to be accepted. --PyF6LdaTjELP3nym Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQRh246EGq/8RLhDjO14tDGHoIJi0gUCaXp8WQAKCRB4tDGHoIJi 0h4/AQCNjvlASS6wam49jvnLt3yAjSlQmrxVmglFbUwZ2EbzJwD+Ps0lZDGSRrF1 nq9OfRkHkEeG19rt5092c5ye4U8hBQk= =oISf -----END PGP SIGNATURE----- --PyF6LdaTjELP3nym-- --===============6675152081899038691== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv --===============6675152081899038691==--