On Wed, Jan 25, 2023 at 02:11:13PM +0000, Sudeep Holla wrote: > On Wed, Jan 25, 2023 at 01:43:48PM +0000, Cristian Marussi wrote: > > so now that the catch-all protocol@ patternProperty is gone in favour > > of the 'protocol-node' definition and $refs, does that mean that any > > current and future SCMI officially published protocol <N> has to be > > added to the above explicit protocol list, even though it does not > > have any special additional required property beside reg ? > > (like protocol@18 above...) > > > > If there are no consumers, should we just not add and deal with it > entirely within the kernel. I know we rely today on presence of node > before we initialise, but hey we have exception for system power protocol > for other reasons, why not add this one too. > > In short we shouldn't have to add a node if there are no consumers. It > was one of the topic of discussion initially when SCMI binding was added > and they exist only for the consumers otherwise we don't need it as > everything is discoverable from the interface. It is fine for me the no-consumers/no-node argument (which anyway would require a few changes in the core init logic anyway to work this way...), BUT is it not that ANY protocol (even future-ones) does have, potentially, consumers indeed, since each protocol-node can potentially have a dedicated channel and related DT channel-descriptor ? (when multiple channels are allowed by the transport) I mean, as an example, you dont strictly need protos 0x18/0x12 nodes for anything (if we patch the core init as said) UNLESS you want to dedicate a channel to those protocols; so I'm just checking here if these kind of scenarios will still be allowed with this binding change, or if I am missing something. Thanks, Cristian
