linux-kernel - Re: [PATCH v2 2/4] firmware: arm_scmi: Add machine_allowlist and machine

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250206110508.GB22527@localhost.localdomain>
Date: Thu, 6 Feb 2025 19:05:08 +0800
From: Peng Fan <peng.fan@....nxp.com>
To: Dan Carpenter <dan.carpenter@...aro.org>
Cc: Sudeep Holla <sudeep.holla@....com>,
	Cristian Marussi <cristian.marussi@....com>,
	Saravana Kannan <saravanak@...gle.com>,
	Linus Walleij <linus.walleij@...aro.org>,
	Dong Aisheng <aisheng.dong@....com>,
	Fabio Estevam <festevam@...il.com>, Shawn Guo <shawnguo@...nel.org>,
	Jacky Bai <ping.bai@....com>,
	Pengutronix Kernel Team <kernel@...gutronix.de>,
	Sascha Hauer <s.hauer@...gutronix.de>, arm-scmi@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	linux-gpio@...r.kernel.org, imx@...ts.linux.dev,
	Peng Fan <peng.fan@....com>
Subject: Re: [PATCH v2 2/4] firmware: arm_scmi: Add machine_allowlist and
 machine_blocklist

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@....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
>