linux-kernel - Re: [PATCH RFC 01/13] dt-bindings: soc: starfive: Add vout-subsystem IP block

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] [day] [month] [year] [list]

Message-ID: <0109a90fc464e3cc63dd6c11e699db0143906256.camel@icenowy.me>
Date: Fri, 14 Nov 2025 15:06:55 +0800
From: Icenowy Zheng <uwu@...nowy.me>
To: Conor Dooley <conor@...nel.org>
Cc: Michal Wilczynski <m.wilczynski@...sung.com>, Rob Herring
 <robh@...nel.org>,  Krzysztof Kozlowski <krzk+dt@...nel.org>, Emil Renner
 Berthing <kernel@...il.dk>, Hal Feng <hal.feng@...rfivetech.com>, Michael
 Turquette <mturquette@...libre.com>,  Stephen Boyd <sboyd@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>, Xingyu Wu <xingyu.wu@...rfivetech.com>,
  Vinod Koul <vkoul@...nel.org>, Kishon Vijay Abraham I <kishon@...nel.org>,
 Andrzej Hajda <andrzej.hajda@...el.com>, Neil Armstrong
 <neil.armstrong@...aro.org>,  Robert Foss <rfoss@...nel.org>, Laurent
 Pinchart <Laurent.pinchart@...asonboard.com>, Jonas Karlman
 <jonas@...boo.se>, Jernej Skrabec <jernej.skrabec@...il.com>, David Airlie
 <airlied@...il.com>, Simona Vetter <simona@...ll.ch>, Maarten Lankhorst
 <maarten.lankhorst@...ux.intel.com>, Maxime Ripard <mripard@...nel.org>, 
 Thomas Zimmermann <tzimmermann@...e.de>, Lee Jones <lee@...nel.org>,
 Philipp Zabel <p.zabel@...gutronix.de>, Paul Walmsley
 <paul.walmsley@...ive.com>, Palmer Dabbelt <palmer@...belt.com>, Albert Ou
 <aou@...s.berkeley.edu>, Alexandre Ghiti <alex@...ti.fr>, Marek Szyprowski
 <m.szyprowski@...sung.com>, Maud Spierings <maudspierings@...ontroll.com>, 
 Andy Yan <andyshrk@....com>, Heiko Stuebner <heiko@...ech.de>,
 devicetree@...r.kernel.org,  linux-kernel@...r.kernel.org,
 linux-clk@...r.kernel.org,  linux-phy@...ts.infradead.org,
 dri-devel@...ts.freedesktop.org,  linux-riscv@...ts.infradead.org
Subject: Re: [PATCH RFC 01/13] dt-bindings: soc: starfive: Add
 vout-subsystem IP block

在 2025-11-13星期四的 19:44 +0000，Conor Dooley写道：
> On Thu, Nov 13, 2025 at 08:48:33AM +0800, Icenowy Zheng wrote:
> > 在 2025-11-12星期三的 18:36 +0000，Conor Dooley写道：
> > > On Wed, Nov 12, 2025 at 02:34:39PM +0800, Icenowy Zheng wrote:
> > > > 在 2025-11-11星期二的 18:36 +0000，Conor Dooley写道：
> > > > > On Tue, Nov 11, 2025 at 06:18:16PM +0000, Conor Dooley wrote:
> > > > > > On Sat, Nov 08, 2025 at 02:04:35AM +0100, Michal Wilczynski
> > > > > > wrote:
> > > > > > > Add the dt-binding documentation for the StarFive JH7110
> > > > > > > Video
> > > 
> > > > > > > +patternProperties:
> > > > > > > +  "^display@[0-9a-f]+$":
> > > > > > 
> > > > > > Personally I'd like to see these being regular properties,
> > > > > > since
> > > > > > there's
> > > > > > exactly one possible setup for this.
> > > > > > 
> > > > > > > +    type: object
> > > > > > > +    description: Verisilicon DC8200 Display Controller
> > > > > > > node.
> > > > > > 
> > > > > > Can you add the relevant references here instead of
> > > > > > allowing
> > > > > > any
> > > > > > object?
> > > > > 
> > > > > I don't think that if you did, this would pass the binding
> > > > > checks,
> > > > > because there's no "verisilicon,dc" binding. I think I saw
> > > > > one in
> > > > > progress, but without the soc-specific compatible that I am
> > > > > going
> > > > > to
> > > > > require here - if for no reason other than making sure that
> > > > > the
> > > > > clocks
> > > > > etc are provided correctly for this device.
> > > > 
> > > > Well I didn't specify any soc-specific compatible because that
> > > > IP
> > > > has
> > > > its own identification registers.
> > > 
> > > I still require one because I want to make sure that clocks etc
> > > are
> > > handled correctly. You can ignore it in the driver if you wish,
> > > but
> > > when
> > > the next user comes along with one more or less clock, I want the
> > > jh7110 one to be forced to use the correct configuration.
> > 
> > I don't think for those generic IPs requiring a SoC-specific
> > compatible
> > is a good idea.
> 
> I disagree. If things are complex enough to end up with different
> numbers of clocks or power-domains etc on different platforms (which
> I
> believe GPUs are) then I want one for validation purposes on
> platforms I
> care about. What you do in the driver is up to you.

Well I think Vivante GPUs do have such case -- a "shader" clock that is
only present when 3D support is here. But that binding still contains
only "vivante,gc" and the maintainer of etnaviv rejects extra
compatible strings.

In addition, as the addition of SoC-specific compatible string and the
real DT are usually written by the same person at the same time, I
don't think this introduces any more validation (because when the
author gets things wrong they will just make it wrong at the two
places).