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: <20251113-irritable-unfold-da619d52026c@spud>
Date: Thu, 13 Nov 2025 19:44:52 +0000
From: Conor Dooley <conor@...nel.org>
To: Icenowy Zheng <uwu@...nowy.me>
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

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.

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)