From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (NAM10-MW2-obe.outbound.protection.outlook.com [40.92.42.13]) by mx.groups.io with SMTP id smtpd.web11.1510.1600475182141295854 for ; Fri, 18 Sep 2020 17:26:22 -0700 Authentication-Results: mx.groups.io; dkim=fail reason="body hash did not verify" header.i=@outlook.com header.s=selector1 header.b=O76IHldB; spf=pass (domain: outlook.com, ip: 40.92.42.13, mailfrom: michael.kubacki@outlook.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UaeJ4u+OGdek+B3gNa8ZuyDotuZa02Sfs3ETF4UyrmOYYXLSX4Vs9svhE5O1KHBrJTLVvd3voTzj8h8tdw3T+dy9RjPgoKKPZDLdaovraq91BRZg/IZ08zKMihYR1f97XvDjlEWVjahcMawqhtfW1fRWQfVHoJagn9yvDE/aNkdogqojBbLhGxcQt01OK1v/FVAcTe7uHu9nqgl6NydhQ7VvFeQcewbQCDi0DJRq7zsFo6z8LZHDKlDdABkinox0O9a6HtcxOvzN1C1GUOxZ0xRpSlvqLJKPJwntfmwNhMSbVfuSq27WBb1W38EwGchtXuBwRSesOrJFyibmdptAjA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=otvvCG3xLYdbudkGaMWWP4M5Ahwog5LZ4Z9pRz/NwVU=; b=ldWRhmzuJx7APFvITApQWjjoUFlL+Sol5BCEq7yoW2GbDAWWUqWL9k5eYEA2s9ErerW4Tuv4Be0qt87w5acUAZbKVhB32h51cs/ksr2kvLCiKUVbNsLO8L5MNLBqgjCFoBEd7Xd9IS+DBP/fjFGEmQ/UpBJS6MToZ15PzT1ByRRkwdNU09o4UrP92z50C1Qvf0iI8LrIIv8ln1OFuSpbWBViuVfV71jVav/ubUXGoZE0wjnb2dwVbiw327yDDd51zFX06b+JI6OloFK/Bdr3eFCFV5up7MrwTqTIHG4iCmO75vjki2f4s8KMzqxGEORcFB3qTq7hmcoyREzB9bGv2g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=otvvCG3xLYdbudkGaMWWP4M5Ahwog5LZ4Z9pRz/NwVU=; b=O76IHldBDEx4w7hSB3q6Cy+vCq1If3REJD52LPoz3i99W6sn3d12qA/tAaykJgGziFPKWegIvGEYht58/rQijwCOD9p0uKe2GlLD5k/XcudV8N5lu5IzBeqbc9gqJwkTY9+x/A3KYBZey0lLQ1dkCoANEzBm787hNp6opEq6bqutP7CQ4qJBIW8Zmx/84k1bNKGpQcw2kxwEqZBlwdckmm5b6BkwxAjMLW1EOVef0bxxw5oGBKFQFTOfjQzXkKPXnG4I0+iy2kVP/CSgu0W4Z/Jhnx06XDilvdrHveTNU740ZDqSIgIPeetbAnNI/huwuhJfol8mLQz69ROSXBi88Q== Received: from DM6NAM10FT062.eop-nam10.prod.protection.outlook.com (2a01:111:e400:7e86::53) by DM6NAM10HT242.eop-nam10.prod.protection.outlook.com (2a01:111:e400:7e86::391) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3391.15; Sat, 19 Sep 2020 00:26:21 +0000 Received: from MWHPR07MB3440.namprd07.prod.outlook.com (2a01:111:e400:7e86::44) by DM6NAM10FT062.mail.protection.outlook.com (2a01:111:e400:7e86::444) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3391.15 via Frontend Transport; Sat, 19 Sep 2020 00:26:21 +0000 X-IncomingTopHeaderMarker: OriginalChecksum:C4440593833C063C53C23AA24C12B4FE5B4E3717E7DE311E701BA1381C10E070;UpperCasedChecksum:1BC3BAEC3AF89E2F53A1433563795EA5EC5FF09566537F9C9A43EE9B2A935D08;SizeAsReceived:9391;Count:49 Received: from MWHPR07MB3440.namprd07.prod.outlook.com ([fe80::eda9:ccc8:2ef:2471]) by MWHPR07MB3440.namprd07.prod.outlook.com ([fe80::eda9:ccc8:2ef:2471%7]) with mapi id 15.20.3370.019; Sat, 19 Sep 2020 00:26:21 +0000 Subject: Re: [edk2-devel] [PATCH v1 1/1] MdePkg: Correct EFI_BLOCK_IO_PROTOCOL_REVISION3 value To: "Ni, Ray" , "devel@edk2.groups.io" CC: "Kinney, Michael D" , Liming Gao , "Liu, Zhiguang" References: From: "Michael Kubacki" Message-ID: Date: Fri, 18 Sep 2020 17:26:19 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 In-Reply-To: X-ClientProxiedBy: MWHPR12CA0050.namprd12.prod.outlook.com (2603:10b6:300:103::12) To MWHPR07MB3440.namprd07.prod.outlook.com (2603:10b6:301:69::28) Return-Path: michael.kubacki@outlook.com X-Microsoft-Original-Message-ID: <88101b26-8b81-1d3b-3e20-fd1ff63e4519@outlook.com> MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [IPv6:2001:4898:d8:39:fd6e:2320:543b:65ed] (2001:4898:80e8:8:7d8f:2320:543b:65ed) by MWHPR12CA0050.namprd12.prod.outlook.com (2603:10b6:300:103::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3391.14 via Frontend Transport; Sat, 19 Sep 2020 00:26:19 +0000 X-Microsoft-Original-Message-ID: <88101b26-8b81-1d3b-3e20-fd1ff63e4519@outlook.com> X-TMN: [/WOU0kr4YIG4TS4XEv+7hSGxPCUzSUePBeR+eJoz2BH/sB1MUNPlD8gXzrIAtI9m] X-MS-PublicTrafficType: Email X-IncomingHeaderCount: 49 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-Correlation-Id: 95c96c9b-7cf2-45b5-efa1-08d85c32a152 X-MS-TrafficTypeDiagnostic: DM6NAM10HT242: X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: rX762oRsS8OqEAH4kzP0uI+0ay+zBMbgBsq+BnsGzSMoiWBa23A0xRPtL2w8XKRo5qizJQXziMOW6EwhU+TZlhOZdXQyHSPvTPAjxTkoAEAgXKWi70a5n8sR6FUXhpmZfyjdEUWQQu6ejUcPhkpkHnd1+srStcxUadcyyp+VKI25mpBPF3FucXvQGijrwKz8PSUMI3YlgDklgehPul4D/3ua6fXpwMcLkHsldNH4ZBpcJ22YTvbV77u8hU3jP2Yw X-MS-Exchange-AntiSpam-MessageData: fkUKsXNFao7BJpMDipwYQjmve3a+NXe4R+MFqtxDzxU3mKWxczeepeh0sy/hz+ZhQtxz4CWwRVfJiR+w5pI8iwBIsaxnAcI/rxZiPhxjTynz4ZyshkaAqsNUQ1uuCxT0+ZMdMm1WHczWRe0Une1vA2ztcHHNXH4wD2gmNXPRKeUMMmmouzND9v06rKDY1CpiX5ZP/voRbnLLAxCNA4YXEQ== X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 95c96c9b-7cf2-45b5-efa1-08d85c32a152 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Sep 2020 00:26:20.8516 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-AuthSource: DM6NAM10FT062.eop-nam10.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6NAM10HT242 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable What do you propose as an alternative? Can a new version of the tool be released with the correct value? Thanks, Michael On 9/18/2020 4:53 PM, Ni, Ray wrote: > As far as I know, EFI disk utility consumesthis new field for=20 > performance. The utility is in Intel website for external downloads. >=20 > ------------------------------------------------------------------------ > *=E5=8F=91=E4=BB=B6=E4=BA=BA:* devel@edk2.groups.io =E4=BB=A3=E8=A1=A8 Michael=20 > Kubacki > *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:* Saturday, September 19, 2020 2:5= 4:54 AM > *=E6=94=B6=E4=BB=B6=E4=BA=BA:* devel@edk2.groups.io ; Ni, Ray=20 > > *=E6=8A=84=E9=80=81:* Kinney, Michael D ; Li= ming Gao=20 > ; Liu, Zhiguang > *=E4=B8=BB=E9=A2=98:* Re: [edk2-devel] [PATCH v1 1/1] MdePkg: Correct=20 > EFI_BLOCK_IO_PROTOCOL_REVISION3 value > Hi Ray, >=20 > Rev3 adds the UINT32 field OptimalTransferLengthGranularity field to > EFI_BLOCK_IO_MEDIA. A preexisting binary Block I/O producer that uses > this field will set their revision to the higher value and the only > check I see in edk2 (PartitionDxe) on the revision to access this field > checks for >=3D EFI_BLOCK_IO_PROTOCOL_REVISION3. >=20 > If a binary Block I/O producer is built with the new value that is > consumed by a module built with the older value it might ignore the > OptimalTransferLengthGranularity field. I do not see where this is the > case in edk2 other than PartitionDxe which sets the > OptimalTransferLengthGranularity field to zero for Rev3. >=20 > You have contributed to this code in the past so feel free to provide > any further insight if needed. >=20 > That said, this change was made to fix a bug in the edk2 implementation > to remove a conflict with the UEFI Spec, the two should be in agreement. >=20 > I suggest the change be added to the next stable tag release notes so > authors of such modules are made aware they should release an update > with the new revision value. >=20 > Thanks, > Michael >=20 > On 9/17/2020 6:25 PM, Ni, Ray wrote: >> Mike, >> Have you evaluated the impact to the already-released module that relie= s on the macro value? >>=20 >> Basically, you changed to a smaller value that may cause a revision3 ch= eck fail: >> a released module expects the revision is bigger than 0x31, but the val= ue is 0x1f. >>=20 >> Thanks, >> Ray >>=20 >>> -----Original Message----- >>> From: devel@edk2.groups.io On Behalf Of Michael= Kubacki >>> Sent: Tuesday, September 15, 2020 2:11 AM >>> To: devel@edk2.groups.io >>> Cc: Kinney, Michael D ; Liming Gao ; Liu, Zhiguang >>> >>> Subject: [edk2-devel] [PATCH v1 1/1] MdePkg: Correct EFI_BLOCK_IO_PROT= OCOL_REVISION3 value >>> >>> From: Michael Kubacki >>> >>> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3D2961 >>> >>> The value of EFI_BLOCK_IO_PROTOCOL_REVISION3 is currently >>> 0x00020031. However, the value assigned in the UEFI Specification >>> 2.8B is ((2<<16) | (31)) which is 0x0002001F. >>> >>> Cc: Michael D Kinney >>> Cc: Liming Gao >>> Cc: Zhiguang Liu >>> Signed-off-by: Michael Kubacki >>> --- >>>=C2=A0=C2=A0 MdePkg/Include/Protocol/BlockIo.h | 2 +- >>>=C2=A0=C2=A0 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/MdePkg/Include/Protocol/BlockIo.h b/MdePkg/Include/Protoc= ol/BlockIo.h >>> index 7b332691ede3..3bd76885e11c 100644 >>> --- a/MdePkg/Include/Protocol/BlockIo.h >>> +++ b/MdePkg/Include/Protocol/BlockIo.h >>> @@ -201,7 +201,7 @@ typedef struct { >>> >>>=C2=A0=C2=A0 #define EFI_BLOCK_IO_PROTOCOL_REVISION=C2=A0 0x00010000 >>>=C2=A0=C2=A0 #define EFI_BLOCK_IO_PROTOCOL_REVISION2 0x00020001 >>> -#define EFI_BLOCK_IO_PROTOCOL_REVISION3 0x00020031 >>> +#define EFI_BLOCK_IO_PROTOCOL_REVISION3 0x0002001F >>> >>>=C2=A0=C2=A0 /// >>>=C2=A0=C2=A0 /// Revision defined in EFI1.1. >>> -- >>> 2.28.0.windows.1 >>> >>> >>> >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >=20 >=20 >=20 >=20 >=20