linux-kernel - Re: [PATCH v3 0/6] firmware: arm_scmi: Add SCMI v3.2 pincontrol protocol basic support

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 for Android: free password hash cracker in your pocket

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

Message-ID: <Zbt-QkWhz5d9P-v6@pluto>
Date: Thu, 1 Feb 2024 11:19:30 +0000
From: Cristian Marussi <cristian.marussi@....com>
To: Peng Fan <peng.fan@....com>
Cc: Linus Walleij <linus.walleij@...aro.org>,
	"Peng Fan (OSS)" <peng.fan@....nxp.com>,
	"souvik.chakravarty@....com" <Souvik.Chakravarty@....com>,
	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>,
	Shawn Guo <shawnguo@...nel.org>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	Pengutronix Kernel Team <kernel@...gutronix.de>,
	Fabio Estevam <festevam@...il.com>,
	dl-linux-imx <linux-imx@....com>,
	"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
	AKASHI Takahiro <takahiro.akashi@...aro.org>,
	Rob Herring <robh@...nel.org>
Subject: Re: [PATCH v3 0/6] firmware: arm_scmi: Add SCMI v3.2 pincontrol
 protocol basic support

On Thu, Feb 01, 2024 at 07:14:17AM +0000, Peng Fan wrote:
> > Subject: Re: [PATCH v3 0/6] firmware: arm_scmi: Add SCMI v3.2 pincontrol
> > protocol basic support
> > 

Hi Peng,

> > On Mon, Jan 29, 2024 at 1:37 PM Peng Fan <peng.fan@....nxp.com> wrote:
> > 
> > > And for i.MX95 OEM extenstion, do you have any suggestions?
> > > I have two points:
> > > 1. use vendor compatible. This would also benefit when supporting
> > > vendor protocol.
> > > 2. Introduce a property saying supporting-generic-pinconf
> > >
> > > How do you think?
> > 
> > While I don't know how OEM extensions to SCMI were designed, the pin
> > control subsystem has the philosophy that extensions are for minor fringe
> > stuff, such as a pin config option that no other silicon is using and thus have
> > no use for anyone else. Well that is actually all the custom extensions we
> > have.
> > (This notion is even carried over to SCMI pinctrl.)
> > 
> > The i.MX95 OEM extension is really odd to me, it looks like a
> > reimplementation of the core aspects of SCMI pin control, and looks much
> > more like the old i.MX drivers than like the SCMI driver.
> 
> i.MX SCMI pin protocol conf settings follows non-SCMI pin conf settings.
> 

It is not just a matter of using custom SCMI OEM types, it is the whole
layout/definitions of the i.MX pin/groups/funcs DT bindings that deviates from
the generic DT bindings layout as handled and expected by the Linux Pinctrl
subsystem (AFAIU), while the SCMI Pinctrl driver as it stands in this series,
was conceived, designed and implemented originally by Oleksii to just use the
generic existing Pinctrl DT bindings; as a consequence, in your i.MX extensions,
you had to add a dedicated i.MX DT parser to interpret the protocol@19 DT snippet
in a completely different way, to try to stick your custom solution on top of
the generic one.

Thanks,
Cristian

> > 
> > But I sure cannot speak of what is allowed in SCMI OEM extensions or not.
> 
> + SPEC owner, Souvik. Any comments?
> 
> Thanks,
> Peng.
> 
> > 
> > Yours,
> > Linus Walleij