public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: Marcin Wojtas <mw@semihalf.com>
Cc: edk2-devel-01 <edk2-devel@lists.01.org>,
	Leif Lindholm <leif.lindholm@linaro.org>,
	 Nadav Haklai <nadavh@marvell.com>,
	"jsd@semihalf.com" <jsd@semihalf.com>,
	 Grzegorz Jaszczyk <jaz@semihalf.com>,
	Tomasz Michalec <tm@semihalf.com>
Subject: Re: [platforms: PATCH 1/7] Silicon/SynQuacer/PlatformDxe: Modify initialization of SdMmcOverride
Date: Thu, 6 Sep 2018 16:31:22 +0200	[thread overview]
Message-ID: <CAKv+Gu8nfy3v8xR_onh78igvz=58hg5aYEBvS2bAfPJFxc_EkQ@mail.gmail.com> (raw)
In-Reply-To: <CAPv3WKdq_qqELe8qgBH=CxDvgOrF69CuO_rLGdVfSWd3wPPrmw@mail.gmail.com>

On 6 September 2018 at 16:26, Marcin Wojtas <mw@semihalf.com> wrote:
> czw., 6 wrz 2018 o 16:04 Ard Biesheuvel <ard.biesheuvel@linaro.org> napisał(a):
>>
>> On 3 September 2018 at 06:53, Marcin Wojtas <mw@semihalf.com> wrote:
>> > From: Tomasz Michalec <tm@semihalf.com>
>> >
>> > 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?

>>
>> This is the reason I added the version field. New hooks should only be
>> added after incrementing the version, and calling the new hooks should
>> 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.


  reply	other threads:[~2018-09-06 14:31 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-03  4:53 [platforms: PATCH 0/7] Armada7k8k Xenon driver rework Marcin Wojtas
2018-09-03  4:53 ` [platforms: PATCH 1/7] Silicon/SynQuacer/PlatformDxe: Modify initialization of SdMmcOverride Marcin Wojtas
2018-09-06 14:04   ` Ard Biesheuvel
2018-09-06 14:26     ` Marcin Wojtas
2018-09-06 14:31       ` Ard Biesheuvel [this message]
2018-09-06 14:38         ` Marcin Wojtas
2018-09-06 14:45           ` Ard Biesheuvel
2018-09-07 11:29             ` Ard Biesheuvel
2018-09-07 13:30               ` Marcin Wojtas
2018-09-03  4:53 ` [platforms: PATCH 2/7] Marvell/Library: ArmadaBoardDescLib: Extend SDMMC information Marcin Wojtas
2018-09-03  4:53 ` [platforms: PATCH 3/7] SolidRun/Armada80x0McBin: Introduce board description library Marcin Wojtas
2018-09-03  4:54 ` [platforms: PATCH 4/7] Marvell/Armada70x0Db: " Marcin Wojtas
2018-09-03  4:54 ` [platforms: PATCH 5/7] Marvell/Armada80x0Db: " Marcin Wojtas
2018-09-03  4:54 ` [platforms: PATCH 6/7] Marvell/Drivers: MvBoardDesc: Extend information for SdMmc Marcin Wojtas
2018-09-03  4:54 ` [platforms: PATCH 7/7] Marvell/Drivers: XenonDxe: Switch to use generic SdMmcPciHcDxe Marcin Wojtas

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='CAKv+Gu8nfy3v8xR_onh78igvz=58hg5aYEBvS2bAfPJFxc_EkQ@mail.gmail.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