From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: "Ni, Ruiyu" <ruiyu.ni@intel.com>
Cc: "Yao, Jiewen" <jiewen.yao@intel.com>,
"edk2-devel@lists.01.org" <edk2-devel@lists.01.org>,
"Gao, Liming" <liming.gao@intel.com>,
"Zeng, Star" <star.zeng@intel.com>,
"Tian, Feng" <feng.tian@intel.com>,
"lersek@redhat.com" <lersek@redhat.com>,
"leif.lindholm@linaro.org" <leif.lindholm@linaro.org>
Subject: Re: [PATCH] MdeModulePkg/PciBusDxe: make BAR degradation dependent on OPROM presence
Date: Mon, 12 Sep 2016 14:46:59 +0100 [thread overview]
Message-ID: <CAKv+Gu8PPZ4Xm7wgyK3g_BjzAPbzuct9ami2SAyv+p0+urn2Vw@mail.gmail.com> (raw)
In-Reply-To: <31C8ACEA-1414-4C18-8CBC-F39B58489529@intel.com>
On 12 September 2016 at 14:41, Ni, Ruiyu <ruiyu.ni@intel.com> wrote:
> You could use IncompatiblePciDevice protocol. If you have no clue I will
> give you more information my tomorrow.
>
That works around the problem, but does not solve it. MdeModulePkg is
supposed to be generic/universal, and still, it contains a Intel/CSM
specific hack to degrade 64-bit BARs of any device that has an option
ROM. This is platform specific policy that does not belong in generic
code, and by the same reasoning that Jiewen argues that MdeModulePkg
should not depend on IntelFrameworkModulePkg, it should not implement
legacy BIOS hacks.
So what would you propose to factor out this functionality? Perhaps a
PciPolicyLib, whose Null implementation does not contain the hack. Or
a feature PCD that can be set to disable this behavior?
In any case, the requirement to implement the IncompatiblePciDevice
protocol to get normal resource allocation behavior is not the best
way to deal with this IMO
Thanks,
Ard.
next prev parent reply other threads:[~2016-09-12 13:47 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-12 13:06 [PATCH] MdeModulePkg/PciBusDxe: make BAR degradation dependent on OPROM presence Ard Biesheuvel
2016-09-12 13:15 ` Yao, Jiewen
2016-09-12 13:16 ` Ard Biesheuvel
2016-09-12 13:41 ` Ni, Ruiyu
2016-09-12 13:46 ` Ard Biesheuvel [this message]
2016-09-12 13:48 ` Laszlo Ersek
2016-09-13 5:46 ` Ni, Ruiyu
2016-09-13 7:43 ` Ard Biesheuvel
2016-09-13 14:56 ` Leif Lindholm
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+Gu8PPZ4Xm7wgyK3g_BjzAPbzuct9ami2SAyv+p0+urn2Vw@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