Hi Etienne, On Sun, 23 Aug 2020 at 11:07, Etienne Carriere <etienne.carri...@linaro.org> wrote: > > Hello Simon, > > > > This change introduces SCMI agent driver in U-Boot in the firmware > > > U-class. > > > (...) > > > Changes in v2: > > > (...) > > > > > > Note: review comments on defining a uclass and sandbox for SCMI > > > transport drivers are NOT addressed in this v2. Main issue is that > > > there is no driver/device defined for SCMI transport layer as well as > > > and no defined compatible ID in the SCMI DT bindings documentation. > > > > I'd still like to see this. You can define an API with a header file. > > It is certainly easier if the DT binding can cover the transport type > > with a separate subnode. > > The bindings are already defined for scmi (ref is the Linux kernel > source tree) and there is no sub-node currently defined for the > scmi driver transport configuration. It's done through the > compatible property and dedicated optional properties. > I think changing the scmi DT binding is a bit out of the scope > of my patch series :)
Fair enough. The bindings are pretty linux-specific of course, since that is the only user. In general it seems hard to change them for U-Boot although I haven't tried in years. > > > But that doesn't stop you creating a uclass > > for the transport. It will also allow you to create a sandbox impl so > > you can add a test for this code. > > Ok, thanks, I understand. > > > > > Also the two interfaces should really be in separate files rather than > > using #ifdefs, I think. > > I'll send a v3 with the implementation over several source files and > the requested uclass/sandbox. > I think I'll create sub-directory drivers/firmware/scmi/ for the source files. I think that's a good idea. > > Thanks again for the feedback on this v2. You're welcome. Regards, Simon