[PATCH v8 03/10] arm_ffa: introduce Arm FF-A low-level driver

[Rob Herring]

On Fri, Nov 25, 2022 at 3:18 PM Simon Glass <sjg at chromium.org> wrote:
>
> Hi Abdellatif,
>
> On Thu, 24 Nov 2022 at 06:21, Abdellatif El Khlifi <abdellatif.elkhlifi at arm.com> wrote:
> >
> > On Tue, Nov 22, 2022 at 07:09:16PM -0700, Simon Glass wrote:
> > >  should be called 'priov' and should beHi Abdellatif,
> > >
>
> [..]
>
> > > > +/**
> > > > + * ffa_device_get - create, bind and probe the arm_ffa device
> > > > + * @pdev: the address of a device pointer (to be filled when the arm_ffa bus device is created
> > > > + *       successfully)
> > > > + *
> > > > + * This function makes sure the arm_ffa device is
> > > > + * created, bound to this driver, probed and ready to use.
> > > > + * Arm FF-A transport is implemented through a single U-Boot
> > > > + * device managing the FF-A bus (arm_ffa).
> > > > + *
> > > > + * Return:
> > > > + *
> > > > + * 0 on success. Otherwise, failure
> > > > + */
> > > > +int ffa_device_get(struct udevice **pdev)
> > > > +{
> > > > +       int ret;
> > > > +       struct udevice *dev = NULL;
> > > > +
> > > > +       ret = device_bind(dm_root(), DM_DRIVER_GET(arm_ffa), FFA_DRV_NAME, NULL, ofnode_null(),
> > > > +                         &dev);
> > >
> > > Please add a DT binding. Even if only temporary, we need something for this.
> >
> > Thanks for the feedback. I'm happy to address all the comments.
> >
> > Regarding DT binding and FF-A discovery. We agreed with Linaro and Rob Herring
> > about the following:
> >
> > - DT is only for what we failed to make discoverable. For hardware, we're stuck
> >   with it. We shouldn't repeat that for software interfaces. This approach is
> >   already applied in the FF-A kernel driver which comes with no DT support and
> >   discovers the bus with bus_register() API [1].
>
> This may be the UEFI view, but it is not how U-Boot works. This is not something we are 'stuck' with. It is how we define what is present on a device. This is how the PCI bus works in U-Boot. It is best practice in U-Boot to use the device tree to make this things visible and configurable. Unlike with Linux there is no other way to provide configuration needed by these devices.

Where do you get UEFI out of this?

It is the discoverability of hardware that is fixed (and we are stuck
with). We can't change hardware. The disoverability may be PCI
VID/PID, USB device descriptors, or nothing. We only use DT when those
are not sufficient. For a software interface, there is no reason to
make them non-discoverable as the interface can be fixed (at least for
new things like FF-A).

Rob