On 3/3/25 9:04 AM, Alice Guo (OSS) wrote:
[...]
In Linux Kernel, there are two drivers, pinctrl-scmi.c and pinctrl-imx-scmi.c.
Both follows ARM SCMI 3.2, but pinctrl-imx-scmi has some special
settings to align with i.mx iomuxc array based settings, mux,input,pad and etc.
In gerneral, imx part could be merged with pinctrl-scmi.c but that
will make code not clean.
In that case, why does U-Boot not have pinctrl-imx-scmi.c to contain the iMX
customization too ? If this protocol is IMX specific, it shouldn't be ifdeffed
in
common code.
Is it acceptable to rename " drivers/pinctrl/nxp/pinctrl-scmi.c" to
"drivers/pinctrl/nxp/ pinctrl-imx-scmi.c"? SCMI_PROTOCOL_ID_PINCTRL = 0x19 is not i.MX
specific.
Look at this commit, which allows drivers placed in some driver.c file
insert their driver entry into a linker list, and then some common code
can iterate over this linker list and match drivers against some properties.
In this case, it is a PHY driver which does list supported PHY IDs in
each U_BOOT_PHY_DRIVER, and the common code checks whether the PHY IDs
match when a new PHY gets registered:
7940a93eb977 ("net: phy: Iterate over both registered PHYs and struct
phy_driver linker list")
This is the driver side conversion example:
20bd8e4fcbb5 ("net: phy: gen10g: Convert to U_BOOT_PHY_DRIVER()")
What you could do is the same:
- Basically duplicate the mechanism in 7940a93eb977 ("net: phy: Iterate
over both registered PHYs and struct phy_driver linker list"), call it
e.g. U_BOOT_SCMI_DRIVER()
- Switch SCMI drivers to use U_BOOT_SCMI_DRIVER , have each one list a
protocol ID (instead of the PHY IDs), and then use the
scmi_agent-uclass.c to iterate over all the linker lists
About the MX95 specifics and handling those, it is possible to have two
drivers which support the same hardware compiled into U-Boot and have
them decide at bind time which driver should bind and which not, look at
drivers/mtd/renesas_rpc_hf.c rpc_hf_probe() and
drivers/spi/renesas_rpc_spi.c rpc_spi_bind() for example of doing this.
I hope this helps untangle the SCMI implementation.