On Fri, Dec 15, 2023 at 07:56:35PM +0800, Peng Fan (OSS) wrote: > From: Peng Fan <peng.fan@xxxxxxx> > > i.MX95 System Manager FW supports SCMI PINCTRL protocol, but uses > OEM Pin Configuration type, so need i.MX specific dt_node_to_map. > This does not even compile for me, as of now, when configuring the Pinctrl SCMI driver as a module with your IMX custom additions. (I think the Makefile with the additional pinctrl-imx is wrong in how describes the objects composing the pinctrl-scmi module with IMX addons...) ERROR: modpost: "pinctrl_scmi_imx_dt_node_to_map" [drivers/pinctrl/pinctrl-scmi.ko] undefined! make[3]: *** [dev/src/linux/scripts/Makefile.modpost:145: Module.symvers] Error 1 make[2]: *** [dev/src/linux/Makefile:1863: modpost] Error 2 make[1]: *** [dev/src/linux/Makefile:234: __sub-make] Error 2 make[1]: Leaving directory dev/out_linux make: *** [Makefile:234: __sub-make] Error 2 More in general, I think that this NXP OEM specific additions, which are in general welcome (and indeed as you know part of the spec was modified to allow for OEM specific needs), do NOT belong to this generic SCMI Pinctrl driver, because the driver from Oleksii/EPAM was born as a generic SCMI driver and it fits perfectly with the Generic Pinctrl Linux subsystem and related generic bindings parsing: now with this you are trying to stick a custom OEM slight varied behaviour (and related binding) on top of a generic thing. And this choice leads to a number of additional changes in the SCMI core to support an even more complex handling of SCMI devices, which is already too complex IMO.. IOW...I dont think that the whole idea of the per-protocol optional compatible to be able to select slightly different behaviours/parsing would have a great chance to fly sincerely... I know there is an issue with having a completely distinct SCMI IMX pinctrl driver that uses the same protocol node @19 (without the need for the compatible trick) due to the way in which the Pinctrl subsystem searches for devices (by of_node)...I'll think about an alternative way to allow this but I am not sure (as you saw) that would be so easily doable... Also, I am wondering if this is really a problem in reality since I would NOT expect you to load/ship both the OEM/NXP custom specific SCMI pinctrl driver AND the generic one on the same platform (after having made them distinct I mean...) am I wrong ? (so you could even made them exclude each other at compile time...far from being the best option I agree...) Thanks, Cristian
