Re: [PATCH v2 2/4] firmware: arm_scmi: Add machine_allowlist and machine_blocklist

Dan Carpenter
2025-02-06T08:09:20Z

On Mon, Jan 20, 2025 at 03:13:30PM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan <peng.fan@nxp.com>
>
> 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