[PATCH v3 1/3] dt-bindings: clk: tenstorrent: Add tenstorrent,atlantis-prcm

[Conor Dooley]

On Wed, Jan 28, 2026 at 03:01:11PM -0600, Anirudh Srinivasan wrote:
> Hi Conor,
> 
> On Wed, Jan 28, 2026 at 11:32 AM Conor Dooley <conor at kernel.org> wrote:
> >
> > On Wed, Jan 28, 2026 at 09:42:42AM -0600, Anirudh Srinivasan wrote:
> > > Hi Conor,
> > >
> > > On Wed, Jan 28, 2026 at 9:02 AM Conor Dooley <conor at kernel.org> wrote:
> > > >
> > > > On Tue, Jan 27, 2026 at 05:39:33PM -0600, Anirudh Srinivasan wrote:
> > > > > Hi Conor,
> > > > >
> > > > > On Tue, Jan 27, 2026 at 1:58 PM Conor Dooley <conor at kernel.org> wrote:
> > > > > >
> > > > > > On Mon, Jan 26, 2026 at 03:07:14PM -0600, Anirudh Srinivasan wrote:
> > > > > > > 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 <asrinivasan at oss.tenstorrent.com>
> > > > > > > ---
> > > > > > This is pretty suspect sounding, if the PLLs for !rcpu are controlled in
> > > > > > the rcpu register region, why is it not a clock parent for the !rcpu
> > > > > > prcms?
> > > > >
> 
> > 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.
> 
> 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.de/
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-riscv/attachments/20260128/995eef4a/attachment.sig>