linux-kernel - Re: [PATCH 7/7] pinctrl: scmi: implement pinctrl_scmi_imx_dt_node_to

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: <ZYXK2YVJ1nnETSuI@pluto>
Date: Fri, 22 Dec 2023 17:43:53 +0000
From: Cristian Marussi <cristian.marussi@....com>
To: "Peng Fan (OSS)" <peng.fan@....nxp.com>
Cc: Sudeep Holla <sudeep.holla@....com>, Rob Herring <robh+dt@...nel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Oleksii Moisieiev <oleksii_moisieiev@...m.com>,
	Linus Walleij <linus.walleij@...aro.org>,
	Shawn Guo <shawnguo@...nel.org>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	Pengutronix Kernel Team <kernel@...gutronix.de>,
	Fabio Estevam <festevam@...il.com>,
	NXP Linux Team <linux-imx@....com>,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	devicetree@...r.kernel.org, linux-gpio@...r.kernel.org,
	Peng Fan <peng.fan@....com>
Subject: Re: [PATCH 7/7] pinctrl: scmi: implement
 pinctrl_scmi_imx_dt_node_to_map

On Fri, Dec 15, 2023 at 07:56:35PM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan <peng.fan@....com>
> 
> 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