linux-kernel - Re: [PATCH 1/1] arm64: dts: lx2160a: Change PCIe compatible string to fsl,ls2088a-pcie

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: <ac41ac85-fdf5-4aa8-953d-6b3ab3c23f37@kernel.org>
Date: Sat, 10 Aug 2024 14:21:31 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Frank Li <Frank.li@....com>, Conor Dooley <conor@...nel.org>
Cc: Shawn Guo <shawnguo@...nel.org>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>,
 "moderated list:ARM/FREESCALE LAYERSCAPE ARM ARCHITECTURE"
 <linux-arm-kernel@...ts.infradead.org>,
 "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
 <devicetree@...r.kernel.org>, open list <linux-kernel@...r.kernel.org>,
 imx@...ts.linux.dev
Subject: Re: [PATCH 1/1] arm64: dts: lx2160a: Change PCIe compatible string to
 fsl,ls2088a-pcie

On 09/08/2024 19:11, Frank Li wrote:
> On Fri, Aug 09, 2024 at 04:07:25PM +0100, Conor Dooley wrote:
>> On Thu, Aug 08, 2024 at 12:15:03PM -0400, Frank Li wrote:
>>> On Thu, Aug 08, 2024 at 04:55:14PM +0100, Conor Dooley wrote:
>>>> On Thu, Aug 08, 2024 at 11:51:34AM -0400, Frank Li wrote:
>>>>> On Thu, Aug 08, 2024 at 04:34:32PM +0100, Conor Dooley wrote:
>>>>>> On Thu, Aug 08, 2024 at 11:31:20AM -0400, Frank Li wrote:
>>>>>>> The mass production lx2160 rev2 use designware PCIe Controller. Old Rev1
>>>>>>> which use mobivel PCIe controller was not supported. Although uboot
>>>>>>> fixup can change compatible string fsl,lx2160a-pcie to fsl,ls2088a-pcie
>>>>>>> since 2019, it is quite confused and should correctly reflect hardware
>>>>>>> status in fsl-lx2160a.dtsi.
>>>>>>
>>>>>> This does not begin to explain why removing the soc-specific compatible,
>>>>>> and instead putting the compatible for another soc is the right fix.
>>>>>> Come up with a new compatible for this device, that perhaps falls back
>>>>>> to the ls2088a, but this change doesn't seem right to me.
>>>>>
>>>>> It can't fallback to fsl,ls2088a-pcie if fsl,lx2160a-pcie exist, which are
>>>>> totally imcompatible between fsl,ls2088a-pcie and fsl,lx2160a-pcie.
>>>>>
>>>>> Previous dtb can work just because uboot dynamtic change fsl,lx2160a-pcie
>>>>> to fsl,ls2088a-pcie when boot kernel.
>>>>>
>>>>> fsl,lx2160a-pcie should be removed because Rev1 have not mass productioned.
>>>>
>>>> Please re-read what I wrote. I said to come up with a new compatible for
>>>> this device, not fall back from the existing fsl,lx2160a-pcie to
>>>> fsl,ls2088a-pcie.
>>>
>>> According to my understand, It needn't add new compatible string if nothing
>>> difference. for example, it use fsl,vf610-i2c for all i2c without add
>>> new soc-specific fsl,lx2160-i2c.
>>
>> No, you should have soc-specific compatibles regardless. Just because
>> you got away with it once, doesn't mean I'm not going to complain about
>> it here!
> 

Above... and here:
https://lore.kernel.org/all/20220817202538.21493-2-leoyang.li@nxp.com/

Uh, this is so confusing. You have fsl,lx2160a device with PCIe and
fsl,lx2160a-pcie compatible. You claim that these are wrong. Instead of
fixing driver, you use entirely different device's compatible?

Wow, that's confusing.

> Rob:
> 	What's current policy for this? Not only for this one. If new SOC
> appear such as iMX10 (maybe many derived chip i.MX101, i.MX102...), there
> are bunch of IPs, Do we need add fsl,imx10* for everyone, which most part
> is exactly the same as old one and bloat binding doc.


NXP since early days was following this approach of having specific
compatibles, so why changing it now?

In general you need specific front-compatibles, except for different
pinout or fused values.

But that's not the problem here. Earlier confusion is the problem. This
is very weird change.

> 
> 	I remember that I got a feedback that required provide the
> difference during I try to add new compatible string. I am sorry, I can't
> find origial dicussion thread.
> 


Best regards,
Krzysztof