linux-kernel - Re: [PATCH 5/6] arm64: dts: ls1028a-qds: make the QIXIS CPLD use the simple-mfd-i2c.c driver

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: <a66eb6b7-3121-4383-b604-949090fc08d9@kernel.org>
Date: Fri, 16 May 2025 21:44:10 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Vladimir Oltean <vladimir.oltean@....com>
Cc: Ioana Ciornei <ioana.ciornei@....com>, Lee Jones <lee@...nel.org>,
 Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>, Shawn Guo <shawnguo@...nel.org>,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 5/6] arm64: dts: ls1028a-qds: make the QIXIS CPLD use the
 simple-mfd-i2c.c driver

On 07/05/2025 17:38, Vladimir Oltean wrote:
>> This sounds reasonable, thanks for providing context. Most of this (so a
>> summary) should be in the commit msg as the rationale for changing the
>> ABI, so please grow a bit the commit msg part:
>> "The MDIO mux on the LS1028A-QDS never worked in mainline because ...".
>>
>> With all this I still do not get why do you need to affect the
>> compatibles. What is wrong with the actual compatibles?
>>
>> Best regards,
>> Krzysztof
> 
> I really care about not breaking compatibility with device trees too,
> and that's why I occasionally report issues such as
> https://lore.kernel.org/all/20250412001703.qbbfhtb6koofvner@skbuf/,
> but in this case the compatibility breakage is not something to worry
> about.
> 
> The QDS (QorIQ Development System) boards are not made to deploy any
> production software on them, they are more fully-featured variants of
> our RDB (Reference Design Boards) which sit in labs and are used
> exclusively by engineers to test/prototype SoC features in order to
> develop for other (production) platforms. Most if not all engineers use
> TFTP to load the kernel and device tree at the same time. I think it's
> going to be a case of a tree falling in a forest with no one to hear it.

OK, this has to be clearly documented so the platform maintainer can
understand the impact.

> 
> In terms of other projects using the Linux device tree bindings - in
> this case that would be U-Boot, which unfortunately has yet another
> schema for the QIXIS CPLD:
> https://github.com/u-boot/u-boot/blob/master/arch/arm/dts/fsl-ls1028a-qds.dtsi#L134
> So not really a concern right now, but we will take it as an action item
> to resync U-Boot with the upstream device trees for the LS1028A-QDS too,
> like was done for the LS1028A-RDB.
> 
> In this case, why would changing the compatible string be preferable to
> using the node as is? It would be nice for the QIXIS CPLD to have child
> nodes with "reg". The current format lacks that, so we thought it would
> be a cleaner break if we just introduced a new compatible string, to

So change the current form. I do not see any point in changing
compatibles. Whatever your drivers are doing is not really relevant
here, because you can change the implementation behind the ABI.

> make it easier to distinguish:
> - "fsl,ls1028aqds-fpga", "fsl,fpga-qixis-i2c", "simple-mfd" doesn't
>   expect children with "reg"
> - "fsl,ls1028a-qds-qixis-i2c" does.

Sorry but no, we are not going to have two different compatibles for the
same device.


Best regards,
Krzysztof