linux-kernel - Re: [PATCH] firmware: arm_scmi: Add support for multiple vendors custom protocols

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: <ZdcR4Auf0zMgBE7P@pluto>
Date: Thu, 22 Feb 2024 09:20:32 +0000
From: Cristian Marussi <cristian.marussi@....com>
To: "Peng Fan (OSS)" <peng.fan@....nxp.com>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>,
	"sudeep.holla@....com" <sudeep.holla@....com>,
	"james.quinlan@...adcom.com" <james.quinlan@...adcom.com>,
	"f.fainelli@...il.com" <f.fainelli@...il.com>,
	"vincent.guittot@...aro.org" <vincent.guittot@...aro.org>,
	"michal.simek@....com" <michal.simek@....com>,
	"quic_sibis@...cinc.com" <quic_sibis@...cinc.com>,
	"quic_nkela@...cinc.com" <quic_nkela@...cinc.com>,
	"souvik.chakravarty@....com" <souvik.chakravarty@....com>
Subject: Re: [PATCH] firmware: arm_scmi: Add support for multiple vendors
 custom protocols

On Thu, Feb 22, 2024 at 08:32:05AM +0000, Peng Fan (OSS) wrote:
> Hi Cristian,
> 
> > Subject: [PATCH] firmware: arm_scmi: Add support for multiple vendors
> > custom protocols
> 
> Do you have an example how to test this? Could this be used for pinctrl imx?

Hi Peng,

as an example usecase for this, you can consider your upcoming series
which adds 2 NXP SCMI vendor protocol (which I hope to review today)
that you numbered as 0x81, 0x84: in order to avoid clashes with other
vendors potentially registering in the future their own vendor protocols
while using the same numbers as yours, you will have to add a vendor_id
string specification to your scmi_protocol definition, so that it matches
the vendor_id string reported by your SCMI server at runtime via the Base
protocol.

This mechanism basically allows a vendor to own the whole space of
vendor protocols numbers, since the numbers are really now referred to a
specific vendor namespace at runtime.

You can also optionally add a sub_vendor_id and implementation version
if you want to use different protocols of you own with the same number
but different capabilties on different platform of yours...but I am
doubtful about the opprtunity of this further customization...lets see 
what the review process bring up...

BUT, all of this stands true for custom vendor protocols, pinctrl-imx does
use the standard 0x19 Pinctrl protocol, and the clash is really on the
device node underlying the device which is created...re-implementing and
duplicating fully a std protocol as a vendor one, just with a different
number to workaround this issue it is not something can go upstream...
..so at this point you will be better off with just that couple of
downstream pinctrl-imx patches that you have, until we get creative and
found a better way to support your specific usecase...or you move to the
generic Linux Pinctrl subsystem that is supported by the pinctrl-scmi
driver originally by Oleksii (but I understand this is problematic for you
in other ways too...)

Thanks,
Cristian