[PATCH 0/2] firmware: arm_scmi: create scmi devices for protocols that not have of_node

[Peng Fan]

> 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