From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2607:f8b0:4001:c0b::242; helo=mail-it0-x242.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-it0-x242.google.com (mail-it0-x242.google.com [IPv6:2607:f8b0:4001:c0b::242]) (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 B85F821122939 for ; Thu, 6 Sep 2018 07:45:48 -0700 (PDT) Received: by mail-it0-x242.google.com with SMTP id j198-v6so19945441ita.0 for ; Thu, 06 Sep 2018 07:45:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=jthiAonXwkdciQ6vMxt5H0maOJrmNWV0r4zTwvmsmhM=; b=ETBGe9r3Q7MGfwtiztOF7sIOFgWgHQ5sP1xtwlYxFgoqqJcny81hnGE5F8kNXfWnYp dQox7I4sEMNfDPMxCvwo2Pwpy7asCdb8wLKzfoupMWYVFSCbBrt2UhPNL/kbZXvWfoXp u30iY/8wKnbfmdn8z8KD3V79YkuEGFYOCZXP4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=jthiAonXwkdciQ6vMxt5H0maOJrmNWV0r4zTwvmsmhM=; b=olcbfVDRN3mnm1L7qn7tKi+63q+ArccNj2CP73x4w1RojhSjP2kkXotd+ta2D6Fgr8 QmnF8LhrHJuWG+h3alVGzbhzmyEOn5yfL/OAFC/aja7aKyoHT3OhtJbQzXxntrVdGCFR Qpo5lovEbrkGRM+Vwadb3Q6m/A+lGA/NTITi4n9qxTEynL03Ue4Nmw62zD3LleKCyaB/ ZUl4DygAuqT4d3lrELhUKqDnogsXXL8kkzRW/ER+OR2+jBKxkvnNCRmS0XicC7bXiQjw ur0XGYjlJ6yY3RNk01EQnF9Yels2OjX/s+PB64P4LfEPg3sTrxhUJ2NVBHzzLBARMN39 NdoQ== X-Gm-Message-State: APzg51D4psQwt2Ctu4NsQaJHI13ZLqJMaMRFlIsg9urqwvmQc9bw6YmL 8O0ThO48OHHMfwM1DTGKMEPw22nQLLpFXxP5nykF2g== X-Google-Smtp-Source: ANB0VdbNPHxFy3ih76QeoINkI95WZpmrqezHFElopOHa75nDbxkX5mfTFzYQa79ToNhMqjWmfO+xwAwKyiLXuMxNu9U= X-Received: by 2002:a02:4d1b:: with SMTP id l27-v6mr2455150jab.86.1536245147617; Thu, 06 Sep 2018 07:45:47 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a6b:1c06:0:0:0:0:0 with HTTP; Thu, 6 Sep 2018 07:45:47 -0700 (PDT) In-Reply-To: References: <1535950443-27106-1-git-send-email-mw@semihalf.com> <1535950443-27106-2-git-send-email-mw@semihalf.com> From: Ard Biesheuvel Date: Thu, 6 Sep 2018 16:45:47 +0200 Message-ID: To: Marcin Wojtas Cc: edk2-devel-01 , Leif Lindholm , Nadav Haklai , "jsd@semihalf.com" , Grzegorz Jaszczyk , Tomasz Michalec Subject: Re: [platforms: PATCH 1/7] Silicon/SynQuacer/PlatformDxe: Modify initialization of SdMmcOverride 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 Sep 2018 14:45:49 -0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On 6 September 2018 at 16:38, Marcin Wojtas wrote: > czw., 6 wrz 2018 o 16:31 Ard Biesheuvel napis= a=C5=82(a): >> >> On 6 September 2018 at 16:26, Marcin Wojtas wrote: >> > czw., 6 wrz 2018 o 16:04 Ard Biesheuvel na= pisa=C5=82(a): >> >> >> >> On 3 September 2018 at 06:53, Marcin Wojtas wrote: >> >> > From: Tomasz Michalec >> >> > >> >> > This patch changes way the EDKII_SD_MMC_OVERRIDE protocol >> >> > sturcture is allocated. Using AllocateZeroPool and then >> >> > seting callbacks in the structure allow driver to be immune to >> >> > adding new callbacks in SdMmcOveride protocol in future. >> >> > >> >> >> >> What is the point of this patch? >> >> >> >> Statically allocating the structure will zero initialize the members >> >> that are not initialized explicitly, but only the members that are >> >> known to exist at compile time. >> >> >> > >> > In such case this patch is really not needed. >> > >> >> I guess the idea of this patch is to work around the latter >> >> limitation, but unfortunately, using sizeof(EDKII_SD_MMC_OVERRIDE) >> >> puts you in the exact same situation. >> > >> > If the newly added callback are zero-initialized, the situation is >> > fine as they won't be executed. >> > >> >> Yes, but this patch does not change that situation at all. >> >> So please, explain which problem is fixed by this patch? > > None, we only forgot, the static initializer will zero non-declared > fields by default. > >> >> >> >> >> This is the reason I added the version field. New hooks should only b= e >> >> added after incrementing the version, and calling the new hooks shoul= d >> >> only occur if the runtime version of the protocol implementation is >> >> greater than or equal to the version where those hooks were first >> >> introduced. >> >> >> > >> > So even if the given SdMmcOverride protocol callback will be NULL for >> > Synquacer controller, is there still a risk that anything could be >> > broken without the version check? >> > >> >> Yes. In EDK2, you can combine binary drivers with drivers build from >> source. If a binary driver was built against an older version of the >> SdMmcOverride header, it may have non-NULL values in the locations of >> the new methods. This patch does not help against that scenario. > > Indeed, this is why it will disappear from v2. So, when adding the new > callbacks, the version should be increased and checked in relevant > places of the main EDK2 driver, right? > > Because a couple of the new callbacks are introduced, would it be ok, > to increment the version only once, i.e. v2 of the SdMmcOverride will > support 4 new routines? > Yes, that is preferred in my opinion. Also, perhaps add some helper macros, e.g., #define EDKII_SD_MMC_OVERRIDE_HAVE_POST_CLOCK_FREQ_SWITCH(p) \ ((p)->Version >=3D 0x2 && (p)->SwitchClockFreqPost !=3D N= ULL) so that the version handling is completely contained in the header file.