From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: redhat.com, ip: 209.132.183.28, mailfrom: philmd@redhat.com) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by groups.io with SMTP; Mon, 23 Sep 2019 09:00:04 -0700 Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 4A0872A09D3 for ; Mon, 23 Sep 2019 16:00:03 +0000 (UTC) Received: by mail-wr1-f71.google.com with SMTP id t11so5041687wrq.19 for ; Mon, 23 Sep 2019 09:00:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=AEt9rm2As7SRMthiXWgX39P2vbm4oF+vl6AksuM85AM=; b=mLD6PxngSs9F11AoOoEuldU9v4rqsmOJ/pqzH0FnU4Wx71qgYsIBTtIdD/5vZtDyt+ kQGJVc/ZFxzl02lD3gX9jVnQsc91jSrsdvGo2ynpphNtXKGBObfONoMI4MdVk7ev05KE jyrd5xACMZy6Yj3VvBy62JcKCObqMGJKbG9gEXU1QTTb6woURlI+13GKZiH2Xbeaofqt avmuZWr6Pz2rKDwOaRjbgjPcmyYXYaW/mCLQl9pyWaSG9y/DAwWfMo5U6rg5GL4ue8q2 fkuZBPBbH72of2dw8DwZ3kFTkpNWeOhc9sXC8siIYkaw8Mr4XjVfVrpOHxvJWKLR2xmQ /IHQ== X-Gm-Message-State: APjAAAUT73ocWdi72QDsrTwl4AZHI6z+N6KzPDavFfuJPqqYQMPjvHnb iPAlBMueOl64D+wfae/4Ft/DF3mkZ5BznlYnqr0/mA52n6zNorXSUcyG6kLxVRpuiCJclgLRfGi eqt5vOsLABfrJIg== X-Received: by 2002:a1c:3b06:: with SMTP id i6mr311805wma.6.1569254401972; Mon, 23 Sep 2019 09:00:01 -0700 (PDT) X-Google-Smtp-Source: APXvYqxou9cfMTWh9hSSs/GK+6REYMxKpSO5pmtHLlicP5Yognygj9M/LDWRMwKaCEgqED1qYU1sJQ== X-Received: by 2002:a1c:3b06:: with SMTP id i6mr311792wma.6.1569254401791; Mon, 23 Sep 2019 09:00:01 -0700 (PDT) Received: from [192.168.1.115] (240.red-88-21-68.staticip.rima-tde.net. [88.21.68.240]) by smtp.gmail.com with ESMTPSA id q66sm16023616wme.39.2019.09.23.09.00.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 23 Sep 2019 09:00:00 -0700 (PDT) Subject: Re: [edk2-devel] [PATCH 25/35] OvmfPkg/VideoDxe: document EFI_EDID_OVERRIDE_PROTOCOL.GetEdid() call To: devel@edk2.groups.io, lersek@redhat.com Cc: Ard Biesheuvel , David Woodhouse , Jordan Justen References: <20190917194935.24322-1-lersek@redhat.com> <20190917194935.24322-26-lersek@redhat.com> From: =?UTF-8?B?UGhpbGlwcGUgTWF0aGlldS1EYXVkw6k=?= Openpgp: id=89C1E78F601EE86C867495CBA2A3FD6EDEADC0DE; url=http://pgp.mit.edu/pks/lookup?op=get&search=0xA2A3FD6EDEADC0DE Message-ID: Date: Mon, 23 Sep 2019 17:59:59 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <20190917194935.24322-26-lersek@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Hi Laszlo, On 9/17/19 9:49 PM, Laszlo Ersek wrote: > According to the UEFI spec -- and to the edk2 header > "MdePkg/Include/Protocol/EdidOverride.h" too --, > EFI_EDID_OVERRIDE_PROTOCOL_GET_EDID takes an (EFI_HANDLE*), and not an > EFI_HANDLE, as second parameter ("ChildHandle"). > > This is probably [*] a bug in the UEFI spec. Given that this CSM module > (VideoDxe) had been used for a long time on physical platforms before it > was moved to OvmfPkg, keep the current "ChildHandle" argument, just cast > it explicitly. > > [*] The edk2 tree contains no other GetEdid() call, and also no GetEdid() > implementation. > > The edk2-platforms tree contains two GetEdid() calls, at commit > 022c212167e0, in files > - "Drivers/DisplayLink/DisplayLinkPkg/DisplayLinkGop/Edid.c", > - "Drivers/OptionRomPkg/CirrusLogic5430Dxe/Edid.c". > > From these, the first passes an (EFI_HANDLE*) as "ChildHandle", the > second passes an EFI_HANDLE. It's difficult to draw a conclusion. :/ > > No functional changes. > > (I've also requested a non-normative (informative) clarification for the > UEFI spec: , in the > direction that matches this patch.) (EFI_HANDLE*) makes sense to me, but I'd rather wait for the spec clarification before Acking this patch, I don't want we silent a bug with this cast. > Cc: Ard Biesheuvel > Cc: David Woodhouse > Cc: Jordan Justen > Signed-off-by: Laszlo Ersek > --- > > Notes: > build-tested only > > OvmfPkg/Csm/BiosThunk/VideoDxe/BiosVideo.c | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/OvmfPkg/Csm/BiosThunk/VideoDxe/BiosVideo.c b/OvmfPkg/Csm/BiosThunk/VideoDxe/BiosVideo.c > index 0640656dba14..995136adee27 100644 > --- a/OvmfPkg/Csm/BiosThunk/VideoDxe/BiosVideo.c > +++ b/OvmfPkg/Csm/BiosThunk/VideoDxe/BiosVideo.c > @@ -1402,9 +1402,13 @@ BiosVideoCheckForVbe ( > goto Done; > } > > + // > + // Cast "ChildHandle" to (EFI_HANDLE*) in order to work around the spec bug > + // in UEFI v2.8, reported as Mantis#2018. > + // > Status = EdidOverride->GetEdid ( > EdidOverride, > - BiosVideoPrivate->Handle, > + (EFI_HANDLE *) BiosVideoPrivate->Handle, > &EdidAttributes, > &EdidOverrideDataSize, > (UINT8 **) &EdidOverrideDataBlock >