public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Leif Lindholm <leif.lindholm@linaro.org>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jeff Brasen <jbrasen@nvidia.com>,
	"edk2-devel@lists.01.org" <edk2-devel@lists.01.org>,
	Girish Pathak <girish.pathak@arm.com>
Subject: Re: [PATCH v2] ArmPkg/ArmScmiDxe: Add clock enable function
Date: Wed, 12 Dec 2018 18:48:46 +0000	[thread overview]
Message-ID: <20181212184846.6e7tortqtl2lxnvc@bivouac.eciton.net> (raw)
In-Reply-To: <CAKv+Gu_YWy19C6_J0U2a_xzCBPv7=B0EFf1t0v-uHftZddg0eA@mail.gmail.com>

On Thu, Dec 06, 2018 at 06:09:26PM +0100, Ard Biesheuvel wrote:
> > -----Original Message-----
> > From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> > Sent: Thursday, December 6, 2018 9:54 AM
> > To: Jeff Brasen <jbrasen@nvidia.com>
> > Cc: edk2-devel@lists.01.org; Leif Lindholm <leif.lindholm@linaro.org>; Girish Pathak <girish.pathak@arm.com>
> > Subject: Re: [PATCH v2] ArmPkg/ArmScmiDxe: Add clock enable function
> >
> > On Thu, 6 Dec 2018 at 01:37, Jeff Brasen <jbrasen@nvidia.com> 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


  reply	other threads:[~2018-12-12 18:48 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-28 20:36 [PATCH v2] ArmPkg/ArmScmiDxe: Add clock enable function Jeff Brasen
2018-12-06  0:37 ` Jeff Brasen
2018-12-06 16:53   ` Ard Biesheuvel
2018-12-06 17:01     ` Jeff Brasen
2018-12-06 17:09       ` Ard Biesheuvel
2018-12-12 18:48         ` Leif Lindholm [this message]
2018-12-13 19:14           ` Jeff Brasen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181212184846.6e7tortqtl2lxnvc@bivouac.eciton.net \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox