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.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
drivers/firmware/arm_scmi/bus.c | 14 ++++++++++++++
include/linux/scmi_protocol.h | 3 +++
2 files changed, 17 insertions(+)
diff --git a/drivers/firmware/arm_scmi/bus.c b/drivers/firmware/arm_scmi/bus.c
index 7850eb7710f499888d32aebf5d99df63db8bfa26..76a5d946de7a8e16f5d940abc4f542aac5bb2b92 100644
--- a/drivers/firmware/arm_scmi/bus.c
+++ b/drivers/firmware/arm_scmi/bus.c
@@ -55,6 +55,20 @@ static int scmi_protocol_device_request(const struct scmi_device_id *id_table)
unsigned int id = 0;
struct list_head *head, *phead = NULL;
struct scmi_requested_dev *rdev;
+ const char * const *allowlist = id_table->machine_allowlist;
+ const char * const *blocklist = id_table->machine_blocklist;
+
+ if (blocklist && of_machine_compatible_match(blocklist)) {
+ pr_debug("block SCMI device (%s) for protocol %x\n",
+ id_table->name, id_table->protocol_id);
+ return 0;
+ }
+
+ if (allowlist && !of_machine_compatible_match(allowlist)) {
+ pr_debug("block SCMI device (%s) for protocol %x\n",
+ id_table->name, id_table->protocol_id);
+ return 0;
+ }
pr_debug("Requesting SCMI device (%s) for protocol %x\n",
id_table->name, id_table->protocol_id);
diff --git a/include/linux/scmi_protocol.h b/include/linux/scmi_protocol.h
index 688466a0e816247d24704f7ba109667a14226b67..e1b822d3522ff25168f895a4b1ed4c4e9a35bfff 100644
--- a/include/linux/scmi_protocol.h
+++ b/include/linux/scmi_protocol.h
@@ -950,6 +950,9 @@ struct scmi_device {
struct scmi_device_id {
u8 protocol_id;
const char *name;
+ /* Optional */
+ const char * const *machine_blocklist;
+ const char * const *machine_allowlist;
};
struct scmi_driver {
--
2.37.1On Mon, Jan 20, 2025 at 03:13:30PM +0800, Peng Fan (OSS) wrote: > From: Peng Fan <peng.fan@nxp.com> > Hi, > 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. > The pinctrl-imx case is an unfortunate exception because you have a custom Vendor SCMI driver using a STANDARD protocol: this was never meant to be an allowed normal practice: the idea of SCMI Vendor extensions is to allow Vendors to write their own Vendor protocols (>0x80) and their own SCMI drivers on top of their custom vendor protocols. This list-based generalization seems to me dangerous because allows the spreading of such bad practice of loading custom Vendor drivers on top of standard protocols using the same protocol to do the same thing in a slightly different manner, with all the rfelated issues of fragmentation ...also I feel it could lead to an umaintainable mess of tables of compatibles....what happens if I write a 3rd pinctrl-cristian driver on top of it...both the new allowlist and the general pinctrl blocklist will need to be updated. The issue as we know is the interaction with devlink given that all of these same-protocol devices are created with the same device_node, since there is only one of them per-protocol in the DT.... ...not sure what Sudeep thinks..just my opinion... > 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. > That's definitely an issue much worse than fw_devlink above....we indeed take care to pick the right vendor-protocol at runtime BUT no check is peformed against the SCMI drivers so you could end up picking up a completely unrelated protocol operations...damn... I think this is more esily solvable though....by adding a Vendor tag in the device_table (like the protocols do) you could skip device creation based on a mismatching Vendor, instead of using compatibles that are doomed to grow indefinitely as a list.... So at this point you would have an optional Vendor and an optional flags (as mentioned in the other thread) in the device_table... I wonder if we can use the same logic for the above pinctrl case, without using compatibles ? I have not really thougth this through properly.... In general, most of these issues are somehow Vendor-dependent, so I was also wondering if it was not the case to frame all of this in some sort of general vendor-quirks framework that could be used also when there are evident and NOT fixable issues on deployed FW SCMI server, so that we will have to flex a bit the kernel tolerance to cope with existing deployed HW that cannot be fixed fw-wise.... ...BUT I thought about this even less thoroughly :P...so it could be just a bad idea of mine... Thanks, Cristian
On Thu, Feb 06, 2025 at 12:06:03PM +0000, Cristian Marussi wrote: >On Mon, Jan 20, 2025 at 03:13:30PM +0800, Peng Fan (OSS) wrote: >> From: Peng Fan <peng.fan@nxp.com> >> > >Hi, > >> 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. >> > >The pinctrl-imx case is an unfortunate exception because you have a >custom Vendor SCMI driver using a STANDARD protocol: this was never >meant to be an allowed normal practice: the idea of SCMI Vendor extensions >is to allow Vendors to write their own Vendor protocols (>0x80) and their >own SCMI drivers on top of their custom vendor protocols. > >This list-based generalization seems to me dangerous because allows the >spreading of such bad practice of loading custom Vendor drivers on top of >standard protocols using the same protocol to do the same thing in a >slightly different manner, with all the rfelated issues of fragmentation > >...also I feel it could lead to an umaintainable mess of tables of >compatibles....what happens if I write a 3rd pinctrl-cristian driver on >top of it...both the new allowlist and the general pinctrl blocklist >will need to be updated. > >The issue as we know is the interaction with devlink given that all of >these same-protocol devices are created with the same device_node, since >there is only one of them per-protocol in the DT.... > >...not sure what Sudeep thinks..just my opinion... > >> 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. >> > >That's definitely an issue much worse than fw_devlink above....we indeed take >care to pick the right vendor-protocol at runtime BUT no check is peformed >against the SCMI drivers so you could end up picking up a completely unrelated >protocol operations...damn... > >I think this is more esily solvable though....by adding a Vendor tag in >the device_table (like the protocols do) you could skip device creation >based on a mismatching Vendor, instead of using compatibles that are >doomed to grow indefinitely as a list.... > >So at this point you would have an optional Vendor and an optional flags >(as mentioned in the other thread) in the device_table... This is indeed better. > >I wonder if we can use the same logic for the above pinctrl case, >without using compatibles ? >I have not really thougth this through properly.... Since i.MX pinctrl driver probe earlier than generic pinctrl scmi driver( compilation order or whatelse may change the order in future), so adding a vendor flag to i.MX pinctrl could work for now. But if order changes.. Anyway I will give a look, then back here. Thanks, Peng. > >In general, most of these issues are somehow Vendor-dependent, so I was >also wondering if it was not the case to frame all of this in some sort >of general vendor-quirks framework that could be used also when there >are evident and NOT fixable issues on deployed FW SCMI server, so that >we will have to flex a bit the kernel tolerance to cope with existing >deployed HW that cannot be fixed fw-wise.... > >...BUT I thought about this even less thoroughly :P...so it could be just a >bad idea of mine... > >Thanks, >Cristian
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
Hi Dan,
On Thu, Feb 06, 2025 at 11:02:04AM +0300, Dan Carpenter wrote:
>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
They are in different subsystems, so I separate them.
>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.
Sorry for not being clear.
The devlink framework will take i.MX as pinctrl provider, because the
fwnode is occupied by i.MX pinctrl scmi device which is created earlier
than generic pinctrl scmi device.
>
>> 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?
VendorA 0x80
VendorB 0x80
If both drivers runs into probe, VenderB 0x80 driver may crash VendorA firmware
if the firmware not designed well.
Not big issue. I just think we should block the probe.
For pure device tree compatible, if compatible not match, the driver will not
runs into probe. I think scmi driver is also good to follow.
>
>It should have a Fixes tag.
>Fixes: b755521fd6eb ("pinctrl: imx: support SCMI pinctrl protocol for i.MX95")
The issue only exists when devlink is forced.
I would like to wait Suddeep and Cristian's comments on merge 2-4 into one
and add Fixes tag.
>
>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.
Thanks for your patient on reviewing the patchset.
>
> Now both drivers will be probed but only one will be used?
No. with block/allow list, only one driver will be probed.
Thanks,
Peng.
>
>regards,
>dan carpenter
>
On Thu, Feb 06, 2025 at 07:05:08PM +0800, Peng Fan wrote: > Hi Dan, > > On Thu, Feb 06, 2025 at 11:02:04AM +0300, Dan Carpenter wrote: > >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 > > They are in different subsystems, so I separate them. > I mean if the i.MX driver prevents the generic driver from working then we need a Fixes tag. It really makes it simpler to understand and backport if they're sent as one patch. Normally we would collect Acks from the maintainers who're involved and but still do it as one patch. > >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. > > Sorry for not being clear. > > The devlink framework will take i.MX as pinctrl provider, because the > fwnode is occupied by i.MX pinctrl scmi device which is created earlier > than generic pinctrl scmi device. > Ah. Got it. Thanks. > > > >> 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? > > VendorA 0x80 > VendorB 0x80 > > If both drivers runs into probe, VenderB 0x80 driver may crash VendorA firmware > if the firmware not designed well. > > Not big issue. I just think we should block the probe. > This is a theoretical issue for now. I would just leave it out of the commit message because it's kind of confusing and it might not even happen in real life. regards, dan carpenter
On Thu, Feb 06, 2025 at 02:40:11PM +0300, Dan Carpenter wrote: > On Thu, Feb 06, 2025 at 07:05:08PM +0800, Peng Fan wrote: > > Hi Dan, > > > > On Thu, Feb 06, 2025 at 11:02:04AM +0300, Dan Carpenter wrote: > > >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 > > > > They are in different subsystems, so I separate them. > > > > I mean if the i.MX driver prevents the generic driver from working then > we need a Fixes tag. It really makes it simpler to understand and backport > if they're sent as one patch. Normally we would collect Acks from the > maintainers who're involved and but still do it as one patch. > Wait. Just to be clear. Does PATCH 1/4 fix that bug so that when both are built-in then the generic driver works? This is in some ways an alternative way to fix the same bug as well as being a cleanup? regards, dan carpenter
On Thu, Feb 06, 2025 at 02:46:27PM +0300, Dan Carpenter wrote: >On Thu, Feb 06, 2025 at 02:40:11PM +0300, Dan Carpenter wrote: >> On Thu, Feb 06, 2025 at 07:05:08PM +0800, Peng Fan wrote: >> > Hi Dan, >> > >> > On Thu, Feb 06, 2025 at 11:02:04AM +0300, Dan Carpenter wrote: >> > >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 >> > >> > They are in different subsystems, so I separate them. >> > >> >> I mean if the i.MX driver prevents the generic driver from working then >> we need a Fixes tag. It really makes it simpler to understand and backport >> if they're sent as one patch. Normally we would collect Acks from the >> maintainers who're involved and but still do it as one patch. >> > >Wait. Just to be clear. Does PATCH 1/4 fix that bug so that when both >are built-in then the generic driver works? This is in some ways an >alternative way to fix the same bug as well as being a cleanup? patch 1/4 is not related to the pinctrl stuff. It could be a standalone patch, I put it in this patchset, just because all are related to fwdevlink. Thanks, Peng > >regards, >dan carpenter >
© 2016 - 2026 Red Hat, Inc.