From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) (using TLSv1 with cipher CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 276611A1E25 for ; Mon, 12 Sep 2016 22:46:51 -0700 (PDT) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga102.fm.intel.com with ESMTP; 12 Sep 2016 22:46:50 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.30,327,1470726000"; d="scan'208,217";a="1049467915" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by orsmga002.jf.intel.com with ESMTP; 12 Sep 2016 22:46:50 -0700 Received: from fmsmsx158.amr.corp.intel.com (10.18.116.75) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 12 Sep 2016 22:46:46 -0700 Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by fmsmsx158.amr.corp.intel.com (10.18.116.75) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 12 Sep 2016 22:46:46 -0700 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.102]) by SHSMSX104.ccr.corp.intel.com ([169.254.5.174]) with mapi id 14.03.0248.002; Tue, 13 Sep 2016 13:46:44 +0800 From: "Ni, Ruiyu" To: Laszlo Ersek , Ard Biesheuvel , "Yao, Jiewen" CC: "Tian, Feng" , "edk2-devel@lists.01.org" , "leif.lindholm@linaro.org" , "Gao, Liming" , "Zeng, Star" Thread-Topic: [edk2] [PATCH] MdeModulePkg/PciBusDxe: make BAR degradation dependent on OPROM presence Thread-Index: AQHSDPZ5xoa7+WYvNk608yyzG3UuyqB1T3WAgAAAQQCAAAkKgIABjqWA Date: Tue, 13 Sep 2016 05:46:43 +0000 Message-ID: <734D49CCEBEEF84792F5B80ED585239D58D54EC7@SHSMSX103.ccr.corp.intel.com> References: <1473685561-1418-1-git-send-email-ard.biesheuvel@linaro.org> <74D8A39837DF1E4DA445A8C0B3885C50385FCEB6@shsmsx102.ccr.corp.intel.com> <449c21bc-ddfc-697a-bc25-7daa05485b6c@redhat.com> In-Reply-To: <449c21bc-ddfc-697a-bc25-7daa05485b6c@redhat.com> Accept-Language: en-US, zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZWUzMWY1OWYtOTk0Zi00MmEyLWEwYmQtNjIwZjBjMDQzMDlhIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX1BVQkxJQyJ9XX1dfSwiU3ViamVjdExhYmVscyI6W10sIlRNQ1ZlcnNpb24iOiIxNS45LjYuNiIsIlRydXN0ZWRMYWJlbEhhc2giOiJZSTloYlFtSWdSaUY1OWZKN01YQWNSYld1WTFwbVREWjhoUDhNckVpb3NFPSJ9 x-ctpclassification: CTP_PUBLIC x-originating-ip: [10.239.127.40] MIME-Version: 1.0 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 Subject: Re: [PATCH] MdeModulePkg/PciBusDxe: make BAR degradation dependent on OPROM presence X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2016 05:46:51 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Regards, Ray >-----Original Message----- >From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Las= zlo Ersek >Sent: Monday, September 12, 2016 9:49 PM >To: Ard Biesheuvel ; Yao, Jiewen >Cc: Ni, Ruiyu ; Tian, Feng ; edk2= -devel@lists.01.org ; >leif.lindholm@linaro.org; Gao, Liming ; Zeng, Star <= star.zeng@intel.com> >Subject: Re: [edk2] [PATCH] MdeModulePkg/PciBusDxe: make BAR degradation d= ependent on OPROM presence > >On 09/12/16 15:16, Ard Biesheuvel wrote: >> On 12 September 2016 at 14:15, Yao, Jiewen wrote: >>> HI Ard >>> We should not let MdeModulePkg depend on IntelFrameworkPkg. >>> You patch violates the dependency rule. >>> I suggest we figure out other solution to resolve the problem. >>> >> >> Yes, please. And please keep us informed about any solutions you come up= with. > >* One idea is to parse the PCI expansion ROM in order to see what image >types are contained within. If there is no (Code type =3D=3D 0x00) image i= n >the oprom, then the oprom is useless for legacy boot anyway, so it >shouldn't trigger degradation. > >Unfortunately, this wouldn't help a lot in practice, since it's surely >going to be years before hw vendors migrate to pure UEFI oproms on their >graphics and network cards. :( Yes the first idea doesn't work because it cannot solve all the problems: s= ome cards may still contain legacy option ROM. The resource degrade happens before PciBus knows which option rom to run by platform. And we even met ca= se the card only contains legacy option rom but platform just don't want to di= spatch the legacy rom. >* Another idea is to check a dynamic PCD that the platform can set. New >PCDs are frowned upon in MdeModulePkg however, so I don't expect this to >be a popular fix. I agree with you. The requirement of dynamic PCD actually indicates we have a missing interfa= ce between platform and PciBus core driver. I personally don't like dynamic PCD very much. It's equivalent to protocol.= Then why should we use PCD instead of protocol? To avoid changing spec?? The usage of PciIncompatibleDevice protocol is the solution we came up. It's also the currently recommended way to solve this type of issue. ECR 1529 introduced in PI 1.4A was initiated by this issue. > >Thanks >Laszlo >_______________________________________________ >edk2-devel mailing list >edk2-devel@lists.01.org >https://lists.01.org/mailman/listinfo/edk2-devel