From: Jeff Brasen <jbrasen@nvidia.com>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: "edk2-devel@lists.01.org" <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
Date: Thu, 6 Dec 2018 17:01:57 +0000 [thread overview]
Message-ID: <DM5PR12MB2439194C64ED34340E6157BBCBA90@DM5PR12MB2439.namprd12.prod.outlook.com> (raw)
In-Reply-To: <CAKv+Gu8Ww_F3JFsHh+XpcO7dJSz955QPAuJyK8G70oX1AhF9og@mail.gmail.com>
-----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.
-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information. Any unauthorized review, use, disclosure or distribution
is prohibited. If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
next prev parent reply other threads:[~2018-12-06 17:02 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 [this message]
2018-12-06 17:09 ` Ard Biesheuvel
2018-12-12 18:48 ` Leif Lindholm
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=DM5PR12MB2439194C64ED34340E6157BBCBA90@DM5PR12MB2439.namprd12.prod.outlook.com \
--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