linux-kernel - Re: [PATCH v5 1/3] dt-bindings: clk: tenstorrent: Add tenstorrent,atlantis-prcm

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <6ebcb1a9-78ca-4734-8723-758f79e6819e@kernel.org>
Date: Sat, 7 Feb 2026 19:39:06 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Conor Dooley <conor@...nel.org>
Cc: Anirudh Srinivasan <asrinivasan@....tenstorrent.com>,
 Drew Fustini <dfustini@....tenstorrent.com>,
 Joel Stanley <jms@....tenstorrent.com>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Michael Turquette <mturquette@...libre.com>,
 Stephen Boyd <sboyd@...nel.org>, Philipp Zabel <p.zabel@...gutronix.de>,
 linux-riscv@...ts.infradead.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-clk@...r.kernel.org, joel@....id.au,
 fustini@...nel.org, mpe@...nel.org, mpe@....tenstorrent.com,
 npiggin@....tenstorrent.com, agross@...nel.org, agross@....tenstorrent.com,
 bmasney@...hat.com
Subject: Re: [PATCH v5 1/3] dt-bindings: clk: tenstorrent: Add
 tenstorrent,atlantis-prcm

On 07/02/2026 15:54, Conor Dooley wrote:
>>>>> suggests picking a more generic name in this case, so isn't
>>>>> "tenstorrent,atlantis-prcm" okay for that?
>>>>
>>>> No, because I don't want to keep guessing this. The docs clearly ask you
>>>> to post complete bindings, which now became less-complete, but fine.
> 
> I don't think it actually is "less complete" without the other
> compatibles. The non-rcpu prcms function differently to the rcpu prcm
> (they seem to be consumers of clocks that the rcpu produces) and are not
> supported by the drivers in this series. They're different devices and I
> think should only be documented when support for them comes along. v4
> had problems that were caused by trying to document them without
> actually having driver support figured out.

It's fine without them, but then let's just name the file after that
only sole compatible.

Best regards,
Krzysztof