[PATCH] firmware: arm_ffa: Handle compatibility with different firmware versions

Sudeep Holla sudeep.holla at arm.com
Fri Oct 15 04:23:53 PDT 2021


On Thu, Oct 14, 2021 at 10:55:01AM +0200, Jens Wiklander wrote:
> On Wed, Oct 13, 2021 at 6:08 PM Sudeep Holla <sudeep.holla at arm.com> wrote:
> >
> > On Wed, Oct 13, 2021 at 03:10:50PM +0200, Jens Wiklander wrote:
> > > On Wed, Oct 13, 2021 at 11:11 AM Sudeep Holla <sudeep.holla at arm.com> wrote:
> > > >
> > > > The driver currently just support v1.0 of Arm FFA specification. It also
> > > > expects the firmware implementation to match the same and bail out if it
> > > > doesn't match. This is causing issue when running with higher version of
> > > > firmware implementation(e.g. v1.1 which will released soon).
> > > >
> > > > In order to support compatibility with different firmware versions, let
> > > > us add additional checks and find the compatible version the driver can
> > > > work with.
> > > >
> > > > Signed-off-by: Sudeep Holla <sudeep.holla at arm.com>
> > > > ---
> > > >  drivers/firmware/arm_ffa/driver.c | 37 ++++++++++++++++++++++++++-----
> > > >  1 file changed, 32 insertions(+), 5 deletions(-)
> > > >

[...]

> > > > +static u32 ffa_compatible_version_find(u32 version)
> > > > +{
> > > > +       u32 compat_version;
> > > > +       u16 major = MAJOR_VERSION(version), minor = MINOR_VERSION(version);
> > > > +       u16 drv_major = MAJOR_VERSION(FFA_DRIVER_VERSION);
> > > > +       u16 drv_minor = MINOR_VERSION(FFA_DRIVER_VERSION);
> > > > +
> > > > +       if ((major < drv_major) || (major == drv_major && minor <= drv_minor))
> > > > +               return version;
> > >
> > > A mismatch in the major version number makes the versions
> > > incompatible. There's no recovery from this, an error code must be
> > > returned instead.
> > >
> >
> > The point is if the firmware can operate at reduced functionality, why just
> > return error. Most other specs operate with that assumption.
> > e.g. if we just add few extra functionality in say v2.0 vs v1.y, would
> > you not want the v1.y driver and firmware v2.0 work together ? Especially
> > if we give the flexibility for the firmware to decide that and return
> > the version as v2.0 in response to v1.y by the caller.
> >
> > If firmware is completely incompatible, it still has option top return
> > NOT_SUPPORTED.
>
> OK, how do you anticipate that this will work in practice? I mean how
> will the driver know which functions are compatible in a v2.0 api when
> the driver itself only is at v1.1? Which parts are available at
> reduced functionality?
>

Sorry I wasn't clear earlier. The driver is just aware of v1.1 and nothing
more. The firmware implementing FF-A has been upgraded to v2.0 for example
and must have knowledge that it implements everything mandatory(not
discoverable) functionality as per v1.1. If it does, it can advertise it
supports v2.0 in response to the caller specifying v1.1 which for the
caller means the firmware can operate well with v1.1 even though from
firmware perspective it is reduced functionality.

On the other hand, if v2.0 spec changes removed some of the mandatory
functionality in v1.1 or v1.x, then firmware can return NOT_SUPPORTED
to the caller with v1.x as argument or it may implement all the necessary
APIs and return its version to indicate that it is fine to interact and
provide functionality(though all functionality may not be used by the
caller as caller is unware in this case).

Hope I didn't add more confusions and this clarifies what is the intention
here.

--
Regards,
Sudeep



More information about the linux-arm-kernel mailing list