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

[Sudeep Holla]

On Thu, Jan 19, 2023 at 09:54:29AM -0700, Simon Glass wrote:
> Hi Sudeep,
> 
> On Thu, 19 Jan 2023 at 09:46, Sudeep Holla <sudeep.holla at arm.com> wrote:
> >
> > Thanks for the details. But IIRC this discussion is not about the FF-A bus
> > and device(partitions) discovery, but the support for FF-A itself. The
> > discussion is about where to have a device node to represent the existence of
> > FF-A support on a platform. If we are talking about individual partitions
> > (devices) in the device tree, then that is pure stupidity as it goes out
> > of since with the firmware the moment a partition is added or removed in
> > the firmware.
> >
> > IIUC, the whole discussion was around whether to use FFA_VERSION as the
> > discovery mechanism for existence of FF-A support on a platform or you
> > have a device node to specify the same.
> 
> No, with respect, that is not quite the situation here.
>

Hmm, not sure what you mean by that. Based on your earlier response, I
thought we are in agreement but you sound to differ here. Am I missing
something ?

> >
> > Just to be clear, even if it is decided to add a device node, the
> > FFA_VERSION must be used to detect the presence of FF-A support and
> > return error otherwise. DT node presence is just to satisfy the design
> > and must be treated as no auto-confirmation for the presence of FF-A
> > support. We are just arguing the device node presence is just redundant,
> > but as mentioned before it is up to U-Boot community to make a call on
> > what is best.
> 
> U-Boot driver model design already supports this. You can have a
> device that binds (from DT) but will not probe because it is not
> present / wrong version. Perhaps this was missed in the conversion to
> Linux:
> 
> https://u-boot.readthedocs.io/en/latest/develop/driver-model/design.html#driver-lifecycle
> 
> So there is nothing clever needed here at all and anything you do just
> adds confusion and bad precedent.
>

OK, I will give that a read.

-- 
Regards,
Sudeep