回复: 回复: 回复: 回复: [PATCH v4 04/20] firmware: scmi: add pin control protocol support to SCMI agent

[Alice Guo (OSS)]

> -----邮件原件-----
> 发件人: Marek Vasut <marex at denx.de>
> 发送时间: 2025年3月4日 4:53
> 收件人: Alice Guo (OSS) <alice.guo at oss.nxp.com>; Peng Fan (OSS)
> <peng.fan at oss.nxp.com>
> 抄送: Tom Rini <trini at konsulko.com>; Stefano Babic <sbabic at denx.de>; Fabio
> Estevam <festevam at gmail.com>; dl-uboot-imx <uboot-imx at nxp.com>; Lukasz
> Majewski <lukma at denx.de>; Sean Anderson <seanga2 at gmail.com>; Simon
> Glass <sjg at chromium.org>; Alper Nebi Yasak <alpernebiyasak at gmail.com>;
> u-boot at lists.denx.de; tharvey at gateworks.com; Alice Guo
> <alice.guo at nxp.com>
> 主题: Re: 回复: 回复: 回复: [PATCH v4 04/20] firmware: scmi: add pin
> control protocol support to SCMI agent
> 
> 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.

Thank you for providing the example. Please review my patch set.
https://patchwork.ozlabs.org/project/uboot/patch/20250305-imx95-v1-2-286d15acbb8a@oss.nxp.com/
https://patchwork.ozlabs.org/project/uboot/patch/20250305-imx95-v1-3-286d15acbb8a@oss.nxp.com/