linux-kernel - RE: [PATCH 0/2] firmware: arm_scmi: create scmi devices for protocols that not have of

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] [day] [month] [year] [list]

Date: Thu, 27 Jun 2024 02:05:24 +0000
From: Peng Fan <peng.fan@....com>
To: Cristian Marussi <cristian.marussi@....com>, "Peng Fan (OSS)"
	<peng.fan@....nxp.com>
CC: Sudeep Holla <sudeep.holla@....com>, "arm-scmi@...r.kernel.org"
	<arm-scmi@...r.kernel.org>, "linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 0/2] firmware: arm_scmi: create scmi devices for protocols
 that not have of_node

> Subject: Re: [PATCH 0/2] firmware: arm_scmi: create scmi devices for
> protocols that not have of_node
> 
> On Wed, Jun 26, 2024 at 02:58:38PM +0800, Peng Fan (OSS) wrote:
> > Per
> 
> Hi,
> 

...
> > rved=0 If a node has its own channel, the of_node is still needed.
> >
> > i.MX95 SCMI firmware not have dedicated channel for 0x12, and no
> need
> > of_node. This patchset is to support protocol 0x12 without the
> > procotol node in device tree.
> >
> 
> With this patch you change a bit of the core logic to allow for protocols
> not explicitly described in the DT to be instantiated, and you use a
> static builtin array to list such protocols...so any future change or any
> downstream vendor protocols that want to use this, we will have to
> patch and extend such protocols[] array.

Just recheck this again, we might address with iterate
rdev->id_table->protocol_id, just as scmi_device_create.

Regards,
Peng.

> 
> Moreover, if anyone DO want to use a per-protocol channel in the
> future on some of these protocols, it will work fine with your solution
> on the code side, BUT you will still have anyway a DT binding check
> error when you try to add that 0x12 node to contain a channel
> description, right ?
> ... because in that case you will have re-added a (supposedly) empty
> protocol node in order to containn the channels definitions and that
> wont be yaml-compliant, am I right ?
> 
> IOW this solves your issue in the immediate, while adding complexity
> to the core code and changing the core behaviour around protocols,
> but it wont stand any future addition or different usage.
> 
> For these reasons, I still think that the cleanest solution is to just let
> protocol nodes to exist even if not referenced anywhere from the DT
> (your original patch to add protocol0x12 I think) simply because we
> allow per-protocol channel definitions and so any empty unreferenced
> protocol node could be needed in the future for this reason.
> 
> In this way we'll also keep treating protocols in an uniform way.
> 
> Just my opinion, though, I'll settle with what is finally decided anyway.
> 
> Thank
> Cristian