On Thu, Dec 06, 2018 at 06:09:26PM +0100, Ard Biesheuvel wrote:
> > -----Original Message-----
> > From: Ard Biesheuvel <[email protected]>
> > Sent: Thursday, December 6, 2018 9:54 AM
> > To: Jeff Brasen <[email protected]>
> > Cc: [email protected]; Leif Lindholm <[email protected]>;
> > Girish Pathak <[email protected]>
> > Subject: Re: [PATCH v2] ArmPkg/ArmScmiDxe: Add clock enable function
> >
> > On Thu, 6 Dec 2018 at 01:37, Jeff Brasen <[email protected]> wrote:
> > >
> > > Leif/Ard,
> > >
> > >
> > > Any comments on this v2 patch for this?
> > >
> > >
> >
> > Hi Jeff,
> >
> > I'm not sure what level of bikeshedding is justified when it comes
> > to a driver such as this one, which is very recent, and mostly for
> > platform internal use. However, I will note that the current
> > versioning approach permits a *client* of the old
> > SCMI_CLOCK_PROTOCOL to be built that invokes ->Enable(), which is
> > not defined for it. This somewhat defeats the purpose of the
> > versioning, since the whole point is to avoid invoking ->Enable()
> > on older implementations of the protocol.
> >
> > I'd be fine with just modifying the protocol, but if we decide we
> > need versioning, we should not modify the public interface of the
> > old one.
> > How the driver reuses one implementation to back the other is another
> > matter, of course.
> > [JMB] I can either just change without versioning (that was my
> > original approach but I also changed the guid which would
> > primarily catch new clients running on old platforms from calling
> > an undefined function), I am fine with either that (with maybe a
> > switch back to original guid if we are not concerned about that
> > issue) or a future update that creates a full v2 version of the
> > protocol in the header.
>
> Maybe Leif disagrees, but I am not too concerned about just changing
> it. This is not a protocol that 3rd party drivers would invoke, right?
It's a protocol that a 3rd party driver _could_ invoke.
Whether that is a likely thing to happen, I just don't know.
Or whether BIOS vendors cherry-picking things badly would cause
interesting things to happen.
On the one hand, I would prefer to see a complete version duplication
of the protocol, just so we _won't_ let existing apps/drivers call the
Enable function.
On the other hand, I don't think this would be the last protocol
update we would ever see, and moving to an internally versioned
interface may make more sense (i.e. adding Version and possibly Size
fields) would be more resilient for that. But that would still require
a full Protocol2 implementation.
At which point, if we don't want to add the Version field, we may just
change the original and see if we break anything?
/
Leif
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.01.org/mailman/listinfo/edk2-devel
