- 17 7月, 2010 1 次提交
-
-
由 Jacob Pan 提交于
The fixed bar capability structure is searched in PCI extended configuration space. We need to make sure there is a valid capability ID to begin with otherwise, the search code may stuck in a infinite loop which results in boot hang. This patch adds additional check for cap ID 0, which is also invalid, and indicates end of chain. End of chain is supposed to have all fields zero, but that doesn't seem to always be the case in the field. Suggested-by: N"H. Peter Anvin" <hpa@zytor.com> Signed-off-by: NJacob Pan <jacob.jun.pan@linux.intel.com> Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org> LKML-Reference: <1279306706-27087-1-git-send-email-jacob.jun.pan@linux.intel.com> Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
-
- 17 5月, 2010 1 次提交
-
-
由 Jacob Pan 提交于
Moorestown PCI code has special handling of devices with fixed BARs. In case of BAR sizing writes, we need to update the fake PCI MMCFG space with real size decode value. When a BAR is not present, we need to return 0 instead of ~0. ~0 will be treated as device error per bugzilla 12006. Signed-off-by: NJacob Pan <jacob.jun.pan@linux.intel.com> LKML-Reference: <1273873281-17489-2-git-send-email-jacob.jun.pan@linux.intel.com> Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org> Acked-by: NThomas Gleixner <tglx@linutronix.de> Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
-
- 15 5月, 2010 1 次提交
-
-
由 H. Peter Anvin 提交于
Do not blindly access extended configuration space unless we actively know we're on a Moorestown platform. The fixed-size BAR capability lives in the extended configuration space, and thus is not applicable if the configuration space isn't appropriately sized. This fixes booting certain VMware configurations with CONFIG_MRST=y. Moorestown will add a fake PCI-X 266 capability to advertise the presence of extended configuration space. Reported-and-tested-by: NPetr Vandrovec <petr@vandrovec.name> Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com> Acked-by: NJacob Pan <jacob.jun.pan@intel.com> Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org> LKML-Reference: <AANLkTiltKUa3TrKR1M51eGw8FLNoQJSLT0k0_K5X3-OJ@mail.gmail.com>
-
- 25 2月, 2010 1 次提交
-
-
由 Jacob Pan 提交于
While probing for the PCI fixed BAR capability in the extended PCI configuration space we need to make sure raw_pci_ext_ops is actually initialized. Signed-off-by: NJacob Pan <jacob.jun.pan@intel.com> LKML-Reference: <43F901BD926A4E43B106BF17856F0755A321E8F7@orsmsx508.amr.corp.intel.com> Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
-
- 24 2月, 2010 1 次提交
-
-
由 Jesse Barnes 提交于
The Moorestown platform only has a few devices that actually support PCI config cycles. The rest of the devices use an in-RAM MCFG space for the purposes of device enumeration and initialization. There are a few uglies in the fake support, like BAR sizes that aren't a power of two, sizing detection, and writes to the real devices, but other than that it's pretty straightforward. Another way to think of this is not really as PCI at all, but just a table in RAM describing which devices are present, their capabilities and their offsets in MMIO space. This could have been done with a special new firmware table on this platform, but given that we do have some real PCI devices too, simply describing things in an MCFG type space was pretty simple. Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> LKML-Reference: <43F901BD926A4E43B106BF17856F07559FB80D08@orsmsx508.amr.corp.intel.com> Signed-off-by: NJacob Pan <jacob.jun.pan@intel.com> Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
-