[PATCH v2 1/4] firmware: add new driver for SCMI firmwares

[Simon Glass]

Hi Etienne,

On Sun, 23 Aug 2020 at 11:07, Etienne Carriere
<etienne.carriere at 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