Re: [PATCH] ArmPkg/ArmScmiDxe: Add clock enable function

[Sami Mujawar <Sami.Mujawar@arm.com>]

-----Original Message-----
From: Leif Lindholm <leif.lindholm@linaro.org> 
Sent: 09 November 2018 06:49 PM
To: Jeff Brasen <jbrasen@nvidia.com>
Cc: edk2-devel@lists.01.org; Ard Biesheuvel <ard.biesheuvel@linaro.org>; Girish Pathak <Girish.Pathak@arm.com>; Sami Mujawar <Sami.Mujawar@arm.com>
Subject: Re: [PATCH] ArmPkg/ArmScmiDxe: Add clock enable function

On Fri, Nov 09, 2018 at 06:35:02PM +0000, Jeff Brasen wrote:
> >   1.  Add new ArmScmiClock2Protocol.h + guid
> >   2.  Add new guid and document that you have to use that guid for the enable function
> >   3.  Add new guid under old name and have the old guid installed on
> >       the handle as well, this would keep things fairly clean but
> >       would have a guid that wouldn't map to a protocol in header
> >       form.
> >   4.  Just change the protocol without changing the guid, this has
> >       the reverse issue of the change I made (except errors can
> >       result in a crash) (don't really like this option)
> 
> I think my (quite puritan) preference would be 5. Add another guid, 
> describe it in the same .h file.
> 
> For example, see (among several others) 
> EFI_FIRMWARE_VOLUME_BLOCK_PROTOCOL/EFI_FIRMWARE_VOLUME_BLOCK2_PROTOCOL
> in MdePkg/Include/Protocol/FirmwareVolumeBlock.h.
> (This may be what you mean by 2?)
> 
> [JB] Yes this was what I was thinking with #2

OK, cool, then we're on the same page.

[SAMI] I think this would be the right approach.

> It's a bit of a sledgehammer, but it is a well known and common 
> pattern in edk2.
> 
> However, if we do this, I would prefer to take the opportunity to add 
> any new functions not already implemented at the same time. Do you 
> know if we have other missing calls?
> 
> Now, this _isn't_ a protocol described by any external specification, 
> so we don't need to be quite as rigid as for public interfaces.
> Basically, there shouldn't be (non-debug/non-devtool) dynamic 
> applications making use of this protocol in the first place. (If we 
> think there should be, we need to document this GUID and protocol in a 
> spec somewhere.) So in reality, I think 4 would also be a valid thing 
> to do.
> 
> But I do want feedback from the original author.
> 
> [JB] Sounds good, I think Girish is out of office until 11/21

Yeah. I'd take feedback from Sami as well :) But both me and Ard will be at plumbers next week, and we are expecting the stable tag to happen then as well - so that is basically lost anyway.

Regards,

Leif