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 <mrip...@kernel.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
signature.asc
Description: PGP signature
