linux-kernel - Re: [PATCH 02/10] dt-bindings: display: imx: Add i.MX8qxp Display Controller display engine

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: <20240718-watchful-macho-muskrat-dcda01@houat>
Date: Thu, 18 Jul 2024 17:53:00 +0200
From: Maxime Ripard <mripard@...nel.org>
To: Krzysztof Kozlowski <krzk@...nel.org>
Cc: Liu Ying <victor.liu@....com>, dri-devel@...ts.freedesktop.org, 
	devicetree@...r.kernel.org, imx@...ts.linux.dev, linux-arm-kernel@...ts.infradead.org, 
	linux-kernel@...r.kernel.org, p.zabel@...gutronix.de, airlied@...il.com, daniel@...ll.ch, 
	maarten.lankhorst@...ux.intel.com, tzimmermann@...e.de, robh@...nel.org, krzk+dt@...nel.org, 
	conor+dt@...nel.org, shawnguo@...nel.org, s.hauer@...gutronix.de, 
	kernel@...gutronix.de, festevam@...il.com, tglx@...utronix.de
Subject: Re: [PATCH 02/10] dt-bindings: display: imx: Add i.MX8qxp Display
 Controller display engine

On Tue, Jul 09, 2024 at 08:50:35AM GMT, Krzysztof Kozlowski wrote:
> On 08/07/2024 16:52, Maxime Ripard wrote:
> > On Mon, Jul 08, 2024 at 04:04:21PM GMT, Krzysztof Kozlowski wrote:
> >> On 08/07/2024 08:40, Liu Ying wrote:
> >>>>> +
> >>>>> +  "^framegen@[0-9a-f]+$":
> >>>>> +    type: object
> >>>>> +    additionalProperties: true
> >>>>> +
> >>>>> +    properties:
> >>>>> +      compatible:
> >>>>> +        const: fsl,imx8qxp-dc-framegen
> >>>>> +
> >>>>> +  "^gammacor@[0-9a-f]+$":
> >>>>
> >>>> This looks like you are organizing bindings per your driver architecture.
> >>>
> >>> As I mentioned in cover letter, this series addresses Maxime's
> >>> comment for the previous series - split the display controller
> >>> into multiple internal devices.  Maxime insisted on doing this.
> >>
> >> But these are not separate devices. Look:
> >> 1. parent DC:
> >> reg = <0x56180000 0x40000>;
> >>
> >> 2. child interrupt controller:
> >> reg = <0x56180040 0x60>;
> >>
> >> That address is within parent.
> >>
> >> 3. Then we go to things like:
> >> reg = <0x5618b400 0x14>, <0x5618b800 0x1c00>;
> >>
> >> Still within parent's range and just few words in address range. That's
> >> a clear indication that you choose few registers and call it a "device".
> > 
> > That's never really been a metric though?
> > 
> > If not, one could just create a "soc" device node covering the entire
> > register map, and since it would overlap despite clearly defined
> > features, you would claim it's a single device?
> 
> Since I do not create such one-address-soc devices, I claim I have
> separate devices in the SoC. Here is not the case: there is a device
> covering entire address space.
> 
> Soc is a good example, because components/blocks of the SoC are being
> re-used among different SoCs. Is the case here?
> 
> BTW, it could be that some of the sub-devices here are worth to be
> devices, I agree.

This was the binding of the previous version:
https://lore.kernel.org/dri-devel/20230822085949.816844-2-victor.liu@nxp.com/

To me, the duplication of interrupts, clocks and power domains with
different indices kind of proves that it's all separate devices

Maxime

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