On Mon, Jan 20, 2025 at 03:13:30PM +0800, Peng Fan (OSS) wrote: > From: Peng Fan <peng.fan@xxxxxxx> > > There are two cases: > pinctrl-scmi.c and pinctrl-imx-scmi.c, both use SCMI_PROTOCOL_PINCTRL. > If both drivers are built in, and the scmi device with name "pinctrl-imx" > is created earlier, and the fwnode device points to the scmi device, > non-i.MX platforms will never have the pinctrl supplier ready. > > Vendor A use 0x80 for feature X, Vendor B use 0x80 for feature Y. > With both drivers built in, two scmi devices will be created, and both > drivers will be probed. On A's patform, feature Y probe may fail, vice > verus. > > Introduce machine_allowlist and machine_blocklist to allow or block > the creation of scmi devices to address above issues. > > machine_blocklist is non-vendor protocols, but vendor has its own > implementation. Saying need to block pinctrl-scmi.c on i.MX95. > machine_allowlist is for vendor protocols. Saying vendor A drivers only > allow vendor A machine, vendor B machines only allow vendor B machine. > I think patches 2-4 should be combined into one patch. This commit message is a bit confusing. I don't really understand how the "fwnode device points to the scmi device". I understand vaguely what that means but in terms of code, I couldn't point to it. > Vendor A use 0x80 for feature X, Vendor B use 0x80 for feature Y. > With both drivers built in, two scmi devices will be created, and both > drivers will be probed. On A's patform, feature Y probe may fail, vice > verus. You're describing the code before. Is it a problem that only one driver is probed successfully? I thought that would be fine. What's the problem? It should have a Fixes tag. Fixes: b755521fd6eb ("pinctrl: imx: support SCMI pinctrl protocol for i.MX95") Here is my suggestion for a commit message: We have two drivers, pinctrl-scmi.c which is generic and pinctrl-imx-scmi.c which is for IMX hardware. They do the same thing. Both provide support for the SCMI_PROTOCOL_PINCTRL protocol. If you have a kernel with both modules built in then they way it was designed to work is that the probe() functions would only allow the appropriate driver to probe. Unfortunately, what happens is that <vague>there is an issue earlier in the process so the fwnode device points to the wrong driver.</vague> This means that even though the correct driver is probed it still wants to use whichever driver was loaded first so if the driver you want came second then it won't work. To fix this, move the checking for which driver to use into the scmi_protocol_device_request() function. Now both drivers will be probed but only one will be used? regards, dan carpenter