From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2607:f8b0:4864:20::143; helo=mail-it1-x143.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-it1-x143.google.com (mail-it1-x143.google.com [IPv6:2607:f8b0:4864:20::143]) (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 946E821197051 for ; Thu, 6 Dec 2018 09:09:39 -0800 (PST) Received: by mail-it1-x143.google.com with SMTP id o19so2474337itg.5 for ; Thu, 06 Dec 2018 09:09:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=yKiEPGU+zD18HVIGTruJDKq7jw7IeIYLvge0jzEzKJs=; b=duwhDzIHzDW8wGge8uZI60ND7CTu8xX0VgI+EVDtcpk8FOMqM2jCP5/Ljs3AmyJ9FD jksij3S2PG3QE+v05nNXZKIqUYbgYq4ygFtaJloClyrSiNVfDBnE2twgbinywzOxUZ99 Fd8HHVBBuNVl6nxoDPBecRj6hfAqQs0OCXeQE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=yKiEPGU+zD18HVIGTruJDKq7jw7IeIYLvge0jzEzKJs=; b=UhLdwiLSZkjNjGIg7Fnpi1007vDPwmnTeA2rbP69G02q8TVlmWCrlcqYJdA1XXqL1K IFlIi2+JKVc6Im6yleLJEH3somL+LIhIOLWHznaFGfTWCvYgUoGuMzqodcNNzWRx86Ql ay9SSvUHzizfD7qMYESwaLv1km1okP/INupZ9KnbSU7zdM7KpkdvDGuy9FBTGZV2shaT rnqjHw3XXS4rYUZbYRiPr7uCNBUU3wimVmRAahMAA2xTenN2saYNfI14akFaOIwuG2nT dtWXgntsl9j7yMjA1xGNX45AhmD98LVe7jjKoWzjTUtnA9dMljme/H45yBQ7ehZKImA/ h0Og== X-Gm-Message-State: AA+aEWaMBktSmoUsMh83ZfqPNvU5DBnkJk8IKbML9zy8D20K7r67bQn6 V2mbqMFPvnr2UjBI9AMLF7JO/0lhsrh13YoHrgz6aw== X-Google-Smtp-Source: AFSGD/X8dav4Mpvcax8o3r061wKVd4Y0T1OE9bMyFUfPfsr30wE/zIe6/BBuZnAi3dVXyRo3Yr7XyGZ8rn+KhSI2WVQ= X-Received: by 2002:a05:660c:4b:: with SMTP id p11mr20303382itk.71.1544116178776; Thu, 06 Dec 2018 09:09:38 -0800 (PST) MIME-Version: 1.0 References: <51b70aa08f34e31ac4e19bebdc96d5298691e9ba.1543437347.git.jbrasen@nvidia.com> In-Reply-To: From: Ard Biesheuvel Date: Thu, 6 Dec 2018 18:09:26 +0100 Message-ID: To: Jeff Brasen Cc: "edk2-devel@lists.01.org" , Leif Lindholm , Girish Pathak 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: Thu, 06 Dec 2018 17:09:39 -0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 6 Dec 2018 at 18:02, Jeff Brasen 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 ; Gi= rish 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 d= river such as this one, which is very recent, and mostly for platform inter= nal 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 v= ersioning, since the whole point is to avoid invoking ->Enable() on older i= mplementations of the protocol. > > I'd be fine with just modifying the protocol, but if we decide we need ve= rsioning, we should not modify the public interface of the old one. > How the driver reuses one implementation to back the other is another mat= ter, of course. > [JMB] I can either just change without versioning (that was my original a= pproach but I also changed the guid which would primarily catch new clients= running on old platforms from calling an undefined function), I am fine wi= th either that (with maybe a switch back to original guid if we are not con= cerned 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?