Messages in this thread | | | From | Sumit Garg <> | Date | Mon, 26 Dec 2022 19:24:11 +0530 | Subject | Re: [PATCH 0/9] Rework SCMI initialization and probing sequence |
| |
On Fri, 23 Dec 2022 at 17:07, Cristian Marussi <cristian.marussi@arm.com> wrote: > > On Fri, Dec 23, 2022 at 11:06:29AM +0530, Sumit Garg wrote: > > On Fri, 23 Dec 2022 at 00:22, Cristian Marussi <cristian.marussi@arm.com> wrote: > > > > > > Hi, > > > > > > under some configurations the SCMI core stack, which is now initialized > > > as a whole at the subsys_initcall level, can be dependent on some other > > > Kernel subsystems (like TEE) when some SCMI transport backend like optee > > > is used. > > > > Thanks Cristian for the rework, but this doesn't seem to address > > reluctance to carry forward the DT legacy (see [1]). > > > > TLDR, it has led to misrepresentation of OP-TEE transport as follows: > > > > First represented as a platform device via DT (compatible = > > "linaro,scmi-optee";) and then > > Migrated to being a TEE bus device (UUID: 0xa8cfe406, 0xd4f5, > > 0x4a2e, 0x9f, 0x8d, 0xa2, 0x5d, 0xc7, 0x54, 0xc0, 0x99) > > > > Do we really need to have a platform device for every SCMI transport? > > > > [1] https://lore.kernel.org/lkml/CAFA6WYPwku8d7EiJ8rF5pVh568oy+jXMXLdxSr6r476e0SD2nw@mail.gmail.com/ > > > > Hi Sumit, > > thanks for the feedback first of all. > > This series represents really a long standing point on my todo-list and it > is meant to start addressing/reviewing the whole SCMI stack init/probe > sequencing and transports setup while taking the chance/opportunity to > fix the issue reported by Ludvig. > > The natural next step in my (and Sudeep) view would be to split out the SCMI > transports too into proper full fledged drivers, that can be probed by their > own susbsys eventually (when possible) and that will then register with the > SCMI core as available transports; so that we can avoid some of the cruft > when multiple backend subsystems are involved... > > ...it is just that I have NOT dug deep into this further evolution and I did > NOT want to do it in this series, but just starting laying out some basic rework > toward this direction while fixing Ludvig issue. (... also because there are a > lot of bit and pieces to get right in SCMI around protocols/modules and DT > parsing and I was trying not to break too many things at a time :P...) > > Anyway, even in the perspective of the above possible evolution into full > fledged drivers, I doubt that we can get rid completely of the DT based > per-transport platform devices since their DT nodes can carry a bit of > transport related information (even for auto-discoverable transport I think) > > ...it will just be that such devices, bound to the compatibles, will be used > probably in a different way (also for backward compatibility with DT > bindings...)...indeed...such platform devices now DO carry some information > about the underlying transport to use BUT most of all they represent also > an SCMI platform instance, so that will not definitely go away completely, > it will just loose most of the transport related functionalities > > ..but... as said...I have not dived too much into this further evolution so > I maybe wrong here on the details... anyway the plan going further, as spoken > also with Sudeep offline, could/should be that depicted above. > > Not sure if this answers all of your questions but I'll keep you posted > on this series and next evolutions...
Thanks for the detailed clarification. I don't have the deep insights regarding how SCMI subsystem works but generally dealing with a device being probed on multiple buses is prone to system integration problems such as:
- Is the device present on the platform bus (in DT)? Is the device present on a discoverable bus (eg. TEE bus)? - Do both buses represent synchronised device views? IOW, version skew problems.
I hope we should be able to address those with the evolution you are planning.
-Sumit
> > Thanks, > Cristian
| |