linux-kernel - Re: [PATCH v5 1/4] media: dt-bindings: nxp,imx8mq-mipi-csi2: Add i.MX8ULP compatible string

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: <20250902123524.GK13448@pendragon.ideasonboard.com>
Date: Tue, 2 Sep 2025 14:35:24 +0200
From: Laurent Pinchart <laurent.pinchart@...asonboard.com>
To: Krzysztof Kozlowski <krzk@...nel.org>
Cc: Frank Li <Frank.li@....com>, Guoniu Zhou <guoniu.zhou@....com>,
	Rui Miguel Silva <rmfrfs@...il.com>,
	Martin Kepplinger <martink@...teo.de>,
	Purism Kernel Team <kernel@...i.sm>,
	Mauro Carvalho Chehab <mchehab@...nel.org>,
	Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>, Shawn Guo <shawnguo@...nel.org>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	Pengutronix Kernel Team <kernel@...gutronix.de>,
	Fabio Estevam <festevam@...il.com>,
	Philipp Zabel <p.zabel@...gutronix.de>, linux-media@...r.kernel.org,
	devicetree@...r.kernel.org, imx@...ts.linux.dev,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 1/4] media: dt-bindings: nxp,imx8mq-mipi-csi2: Add
 i.MX8ULP compatible string

On Tue, Sep 02, 2025 at 02:26:53PM +0200, Krzysztof Kozlowski wrote:
> On 02/09/2025 10:35, Laurent Pinchart wrote:
> >>>>          compatible:
> >>>>            contains:
> >>>>              enum:
> >>>> -              - fsl,imx8qxp-mipi-csi2
> >>>> +              - fsl,imx8ulp-mipi-csi2
> >>>> +    then:
> >>>> +      properties:
> >>>> +        reg:
> >>>> +          minItems: 2
> >>>> +        resets:
> >>>> +          minItems: 2
> >>>> +          maxItems: 2
> >>>> +        clocks:
> >>>> +          minItems: 4
> >>>> +        clock-names:
> >>>> +          minItems: 4
> >>>
> >>> But according to this, the ULP version requires more clocks than the QXP
> >>> version.
> >>
> >> If only clock number difference, generally, it is still compatible and can
> >> be fallback, especialy driver use devm_bulk_clk_get_all().
> > 
> > That's a driver-specific implementation decision, so I don't think it
> > should be taken into account to decide on compatibility.
> 
> The clock inputs do not restrict compatibility. If Linux can use
> fallback to bind and operate properly, then it's a strong indication
> devices are compatible.
> 
> Imagine exactly the same registers, so same programming interface, but
> one device takes one more clock which just needs to be enabled through
> its lifetime. Such devices are fully compatible, even though clock
> inputs differ.

That's only the case if someone enables the clock, isn't it ? From a DT
binding point of view, how can we know that the extra clock will be
enabled by a component separate from the driver (in this case by the
fact that the devm_bulk_clk_get_all() function gets all clocks) ?

> I also wanted to express exactly that case on my slides from OSSE -
> slide 28:
> https://osseu2025.sched.com/event/25Vsl/dts-101-from-roots-to-trees-aka-devicetree-for-beginners-krzysztof-kozlowski-linaro

Quoting that slide, you wrote

"Two devices are compatible when the new device works with Linux drivers
bound via fallback (old) compatible".

That is clearly the case here for the existing *Linux* driver. But what
if the driver called devm_bulkd_clk_get() with a device-specific list of
clocks ? Or what if the same DT bindings are used on an OS that has no
clk_get_all() equivalent ? This is my concern with declaring those two
devices as compatible: they may be from the point of view of the current
implementation of the corresponding Linux kernel driver, but DT bindings
are not Linux-specific.

Or do DT bindings assume that drivers have to always enable all clocks
declared in DT, even if they don't know what those clocks are ? That
seems error-prone, in quite a few cases drivers need to handle separate
clocks in a device-specific way, with for instance a particular
ordering, preventing them from using devm_bulk_clk_get_all(). If all
drivers are required to manage all clocks declared in DT, this would get
messy quite quickly.

> (although I focused on reversed case when devices are not compatible,
> because that is decisive case).

-- 
Regards,

Laurent Pinchart