linux-kernel - Re: [PATCH RFC 01/10] dt-bindings: gpu: Add PowerVR Series5 SGX GPUs

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: <22cny5aumc5wafsrjd3j55zcjbjf2viip64kfbjiqis2grtd6t@wg5dxeuzil6l>
Date: Mon, 18 Dec 2023 11:14:24 +0100
From: Maxime Ripard <mripard@...nel.org>
To: "H. Nikolaus Schaller" <hns@...delico.com>
Cc: Andrew Davis <afd@...com>, Frank Binns <frank.binns@...tec.com>, 
	Donald Robson <donald.robson@...tec.com>, Matt Coster <matt.coster@...tec.com>, 
	Adam Ford <aford173@...il.com>, Ivaylo Dimitrov <ivo.g.dimitrov.75@...il.com>, 
	Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, Thomas Zimmermann <tzimmermann@...e.de>, 
	Rob Herring <robh+dt@...nel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>, 
	Conor Dooley <conor+dt@...nel.org>, Chen-Yu Tsai <wens@...e.org>, 
	Jernej Skrabec <jernej.skrabec@...il.com>, Samuel Holland <samuel@...lland.org>, 
	Benoît Cousson <bcousson@...libre.com>, Tony Lindgren <tony@...mide.com>, Nishanth Menon <nm@...com>, 
	Vignesh Raghavendra <vigneshr@...com>, Tero Kristo <kristo@...nel.org>, 
	Paul Cercueil <paul@...pouillou.net>, dri-devel@...ts.freedesktop.org, devicetree@...r.kernel.org, 
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, 
	linux-sunxi@...ts.linux.dev, linux-omap@...r.kernel.org, linux-mips@...r.kernel.org
Subject: Re: [PATCH RFC 01/10] dt-bindings: gpu: Add PowerVR Series5 SGX GPUs

On Mon, Dec 18, 2023 at 10:28:09AM +0100, H. Nikolaus Schaller wrote:
> Hi Maxime,
> 
> > Am 15.12.2023 um 14:33 schrieb Maxime Ripard <mripard@...nel.org>:
> > 
> >>> 
> >>> It's for a separate architecture, with a separate driver, maintained out
> >>> of tree by a separate community, with a separate set of requirements as
> >>> evidenced by the other thread. And that's all fine in itself, but
> >>> there's very little reason to put these two bindings in the same file.
> >>> 
> >>> We could also turn this around, why is it important that it's in the
> >>> same file?
> >> 
> >> Same vendor. And enough similarity in architectures, even a logical sequence
> >> of development of versions (SGX = Version 5, Rogue = Version 6+) behind.
> >> (SGX and Rogue seem to be just trade names for their architecture development).
> > 
> > Again, none of that matters for *where* the binding is stored.
> 
> So what then speaks against extending the existing bindings file as proposed
> here?

I mean, apart from everything you quoted, then sure, nothing speaks
against it.

> >> AFAIK bindings should describe hardware and not communities or drivers
> >> or who is currently maintaining it. The latter can change, the first not.
> > 
> > Bindings are supposed to describe hardware indeed. Nothing was ever said
> > about where those bindings are supposed to be located.
> > 
> > There's hundreds of other YAML bindings describing devices of the same
> > vendors and different devices from the same generation.
> 
> Usually SoC seem to be split over multiple files by subsystem. Not by versions
> or generations. If the subsystems are similar enough they share the same bindings
> doc instead of having one for each generation duplicating a lot of code.
> 
> Here is a comparable example that combines multiple vendors and generations:
> 
> Documentation/devicetree/bindings/usb/generic-ehci.yaml

EHCI is a single interface for USB2.0 controllers. It's a standard API,
and is made of a single driver that requires minor modifications to deal
with multiple devices.

We're very far from the same situation here.

> > If anything it'll make it easier for you. I'm really not sure why it is
> > controversial and you're fighting this so hard.
> 
> Well, you made it controversial by proposing to split what IMHO belongs together.

No, reviews aren't controversial. The controversy started when you chose
to oppose it while you could have just rolled with it.

> I feel that the original patch is good enough for its purpose and follows
> some design pattern that can be deduced from other binding docs.

[citation needed]

Maxime

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