From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2a00:1450:4864:20::442; helo=mail-wr1-x442.google.com; envelope-from=leif.lindholm@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-wr1-x442.google.com (mail-wr1-x442.google.com [IPv6:2a00:1450:4864:20::442]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 4FE0E21194897 for ; Wed, 12 Dec 2018 10:48:50 -0800 (PST) Received: by mail-wr1-x442.google.com with SMTP id u3so18777152wrs.3 for ; Wed, 12 Dec 2018 10:48:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=g4G22bMY615h4PpkdsWToYdLVvhK2f1uT8OM31D0CQU=; b=Kso9WoJVhXGr1RofR8pljvNsAsOKkOqTp/zMrDM8dJAK4L3F3OsNVltYapQreacHoX qqD3BosKe/x4bk80TFKUfhxK+Sb+mptTjPzRxPDlp7ofxFd+Xn9hp5nu2IQLNaZ92q4m LpiiD6MrRzqKHCymq0DvEMUCrBIWLukFolH2A= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=g4G22bMY615h4PpkdsWToYdLVvhK2f1uT8OM31D0CQU=; b=klUkdXMaB5o4svymEcMmnIJAjoZZezzHngVI+qL8/qjowxXIToyFtmhMoNLk69IkSq yypJJ6wpFM6comFbs8aaiCUI/79GBV0tgBKVenKy3la2G29SQpioTAqlkMX9IGiWIWOZ ZzFVSuYVLlOCOF0YJpMz19t35KHLJndCFvXHNIROwJFyup7GQUMDzcE2LbQyaVA+t7lC 7hJUS2cTU+eaJ1MTg+t8rsKYBUweC+nDl9P8eLhIgDAoqO9YOcbRFVHhvn1l3VBxWFSO t8uRaCD7rHVnNt73OWpx17tk+vSouGvqvbQ/cfKT2M5iktHRT2s8oQ1k/gj7iEwYp7pc mGQg== X-Gm-Message-State: AA+aEWZXsosOcxRdNvnvxldKoaWs30yKOGukmek4+ciCI2gR+sPDSMu+ 6AfMOsnEajVGSgX++/beFztrqQ== X-Google-Smtp-Source: AFSGD/UMJygwoGX33BU/E92XyVy9hdC8UZrYXbK+TDRyoBOlWTeLiqMDz2Irr2f1wfuXccgdGkqlpA== X-Received: by 2002:adf:b6a1:: with SMTP id j33mr18381432wre.55.1544640529258; Wed, 12 Dec 2018 10:48:49 -0800 (PST) Received: from bivouac.eciton.net (bivouac.eciton.net. [2a00:1098:0:86:1000:23:0:2]) by smtp.gmail.com with ESMTPSA id l20sm44816296wrb.93.2018.12.12.10.48.48 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 12 Dec 2018 10:48:48 -0800 (PST) Date: Wed, 12 Dec 2018 18:48:46 +0000 From: Leif Lindholm To: Ard Biesheuvel Cc: Jeff Brasen , "edk2-devel@lists.01.org" , Girish Pathak Message-ID: <20181212184846.6e7tortqtl2lxnvc@bivouac.eciton.net> References: <51b70aa08f34e31ac4e19bebdc96d5298691e9ba.1543437347.git.jbrasen@nvidia.com> MIME-Version: 1.0 In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Subject: Re: [PATCH v2] ArmPkg/ArmScmiDxe: Add clock enable function X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2018 18:48:51 -0000 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Dec 06, 2018 at 06:09:26PM +0100, Ard Biesheuvel wrote: > > -----Original Message----- > > From: Ard Biesheuvel > > Sent: Thursday, December 6, 2018 9:54 AM > > To: Jeff Brasen > > Cc: edk2-devel@lists.01.org; Leif Lindholm ; Girish Pathak > > Subject: Re: [PATCH v2] ArmPkg/ArmScmiDxe: Add clock enable function > > > > On Thu, 6 Dec 2018 at 01:37, Jeff Brasen 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