> -----邮件原件----- > 发件人: Marek Vasut <[email protected]> > 发送时间: 2025年3月4日 4:53 > 收件人: Alice Guo (OSS) <[email protected]>; Peng Fan (OSS) > <[email protected]> > 抄送: Tom Rini <[email protected]>; Stefano Babic <[email protected]>; Fabio > Estevam <[email protected]>; dl-uboot-imx <[email protected]>; Lukasz > Majewski <[email protected]>; Sean Anderson <[email protected]>; Simon > Glass <[email protected]>; Alper Nebi Yasak <[email protected]>; > [email protected]; [email protected]; Alice Guo > <[email protected]> > 主题: 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/[email protected]/ https://patchwork.ozlabs.org/project/uboot/patch/[email protected]/
