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

Krzysztof Kozlowski krzk at kernel.org
Wed May 7 06:56:20 PDT 2025


On 07/05/2025 14:28, Ioana Ciornei wrote:
> On Wed, May 07, 2025 at 06:54:38AM +0200, Krzysztof Kozlowski wrote:
>> On 06/05/2025 16:21, Ioana Ciornei wrote:
>>> On Fri, May 02, 2025 at 09:04:03AM +0200, Krzysztof Kozlowski wrote:
>>>> On Wed, Apr 30, 2025 at 06:36:33PM GMT, Ioana Ciornei wrote:
>>>>> From: Vladimir Oltean <vladimir.oltean at nxp.com>
>>>>>
>>>>> The MDIO mux on the LS1028A-QDS never worked in mainline. The device
>>>>> tree was submitted as-is, and there is a downstream driver for the QIXIS
>>>>> FPGA:
>>>>>
>>>>> https://github.com/nxp-qoriq/linux/blob/lf-6.12.y/drivers/soc/fsl/qixis_ctrl.c
>>>>>
>>>>> That driver is very similar to the already existing drivers/mfd/simple-mfd-i2c.c,
>>>>> and the hardware works with the simple-mfd-i2c driver, so there isn't
>>>>> any reason to upstream the other one.
>>>>>
>>>>> Adapt the compatible string and child node format of the FPGA node, so
>>>>> that the simple-mfd-i2c driver accepts it.
>>>>
>>>> Why do you break the users based on some driver differences? Fix the
>>>> drivers, not the DTS.
>>>>
>>>>>
>>>>> Signed-off-by: Vladimir Oltean <vladimir.oltean at nxp.com>
>>>>> Signed-off-by: Ioana Ciornei <ioana.ciornei at nxp.com>
>>>>> ---
>>>>>  arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts | 9 +++++----
>>>>>  1 file changed, 5 insertions(+), 4 deletions(-)
>>>>>
>>>>> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts b/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
>>>>> index 0bb2f28a0441..58b54d521d75 100644
>>>>> --- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
>>>>> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
>>>>> @@ -338,17 +338,18 @@ sgtl5000: audio-codec at a {
>>>>>  	};
>>>>>  
>>>>>  	fpga at 66 {
>>>>> -		compatible = "fsl,ls1028aqds-fpga", "fsl,fpga-qixis-i2c",
>>>>> -			     "simple-mfd";
>>>>> +		compatible = "fsl,ls1028a-qds-qixis-i2c";
>>>>
>>>> This breaks all the existing users. NAK.
>>>
>>> Using a mainline kernel, this DT node was never used or probed by a
>>> driver since that driver was never submitted. I am not breaking any user
>>> of the mainline kernel.
>> 1. Users of DTS is plural, so what about all other projects and out of
>> tree users?

You still can have users in all possible projects. Dropping simple-mfd,
even though it is Linux thingy, is affecting users, potentially breaking
them. Exactly what we talked on last plumbers - don't do such changes.

I recall even warning from Rob for people adding simple-mfd: be careful
adding it, because dropping it creates compatibility issue.

This is not a fresh platform, where you do not care about users. It is
published to all users since ~2019.


>> 2. Did you remove simple-mfd from kernel or what? How can you claim
>> there is no driver for simple-mfd?
> 
> No, I did not remove simple-mfd from the kernel.
> 


...

> If, as you say, this works just by having the simple-mfd, I should have
> been able to see the enetc_port1 functional and the RGMII PHY be
> accesible on the MDIO bus which is behind the reg-mux. But this is not
> happening.
> 
> Instead, I get this:
> 
> 	[   17.635216] platform mdio-mux: deferred probe pending: mdio-mux-multiplexer: Failed to get mux
> 
> 	root at localhost:~# ip link set dev eno1 up
> 	[ 1155.190391] net eno1: could not attach to PHY
> 	root at localhost:~# uname -a
> 	Linux localhost 6.15.0-rc5-next-20250507 #112 SMP PREEMPT Wed May  7 15:21:14 EEST 2025 aarch64 aarch64 aarch64 GNU/Linux
> 
> From what I understand, even though the fpga at 66 has the simple-mfd
> compatible, no entity initializes an I2C regmap (since this is an I2C
> device) for it so that it can be used by any child device.
> 
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



More information about the linux-arm-kernel mailing list