[PATCH] gpio/ls1043a: Correct ls1043a gpio nodes compatible in dts file

Gang Liu gang.liu at nxp.com
Tue Mar 22 07:03:22 PDT 2016


Hi, Scott,

I think you mean that GPIO node needs two compatibles, one for general GPIO IP block ("fsl,qoriq-gpio")
and another for chip-specific ("fsl,ls1043a-gpio").
The driver can just include general GPIO IP block compatible, and if there is a errata for ls1043 GPIO, the
chip-specific compatible can be used to fix the errata, right?

If it's right, do you think the "fsl,ls1043a-gpio" and "fsl,qoriq-gpio" are ok for our Layerscape platforms?
So maybe I need to create more patches for ls1021, ls2085 platform supported in opensource.

Best Regards,
Liu Gang

-----Original Message-----
From: Scott Wood 
Sent: Saturday, March 19, 2016 2:49 AM
To: Gang Liu <gang.liu at nxp.com>; linus.walleij at linaro.org; linux-gpio at vger.kernel.org; linux-arm-kernel at lists.infradead.org; khilman at linaro.org
Cc: robh+dt at kernel.org; Leo Li <leo.li at nxp.com>; Mingkai Hu <mingkai.hu at nxp.com>
Subject: Re: [PATCH] gpio/ls1043a: Correct ls1043a gpio nodes compatible in dts file

> Hi, Scott,
> Currently all QorIQ platform's GPIO IP blocks are same, they are all 
> no version register, and have same registers, offset address and other 
> features, so the code can cover all of them.

So?  We have no idea what the hardware people will do in the future.

> There is just one exceptional ls2080, it has the little-endian GPIO 
> registers, and we added a "little-endian" property in the GPIO nodes.
> 
> Add in addition, we have deeply discussed about the GPIO compatible 
> name before, you suggested using "fsl,qoriq-gpio" for all the QorIQ 
> platforms. Please find some excerpt from former mail context.

It's in established use so I won't suggest that we get rid of it.  But ideally the chip-specific compatible should be in the device tree (not the driver until/unless necessary) as well, so it seemed odd to get rid of it.

If we were starting from scratch, then instead of "fsl,qoriq-gpio" it should have been a chip-based compatible for some arbitrary chip that contains this exact logic (in addition to the chip-specific compatible for the actual chip).  Neither case requires adding every chip name to the driver.

-Scott




More information about the linux-arm-kernel mailing list