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] [thread-next>] [day] [month] [year] [list]

Message-ID: <35667bd4-bfb4-4939-9fd7-328e2e8c228f@kernel.org>
Date: Tue, 9 Jul 2024 08:50:35 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Maxime Ripard <mripard@...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 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.

Best regards,
Krzysztof