BMC/Intel-BMC/linux.git/arch/ia64/pci, branch dev

PCI / ACPI: Do not set ACPI companions for host bridges with parents

2015-05-27T23:39:53+00:00

Commit 97badf873ab6 (device property: Make it possible to use secondary firmware nodes) uncovered a bug in the x86 (and ia64) PCI host bridge initialization code that assumes bridge->bus->sysdata to always point to a struct pci_sysdata object which need not be the case (in particular, the Xen PCI frontend driver sets it to point to a different data type). If it is not the case, an incorrect pointer (or a piece of data that is not a pointer at all) will be passed to ACPI_COMPANION_SET() and that may cause interesting breakage to happen going forward. To work around this problem use the observation that the ACPI host bridge initialization always passes NULL as parent to pci_create_root_bus(), so if pcibios_root_bridge_prepare() sees a non-NULL parent of the bridge, it should not attempt to set an ACPI companion for it, because that means that pci_create_root_bus() has been called by someone else. Fixes: 97badf873ab6 (device property: Make it possible to use secondary firmware nodes) Reported-and-tested-by: Sander Eikelenboom Signed-off-by: Rafael J. Wysocki Acked-by: Bjorn Helgaas

ia64/PCI: Treat all host bridge Address Space Descriptors (even consumers) as windows

2015-04-21T20:29:39+00:00

Prior to c770cb4cb505 ("PCI: Mark invalid BARs as unassigned"), if we tried to claim a PCI BAR but could not find an upstream bridge window that matched it, we complained but still allowed the device to be enabled. c770cb4cb505 broke devices that previously worked (mptsas and igb in the case Tony reported, but it could be any devices) because it marks those BARs as IORESOURCE_UNSET, which makes pci_enable_device() complain and return failure: igb 0000:81:00.0: can't enable device: BAR 0 [mem size 0x00020000] not assigned igb: probe of 0000:81:00.0 failed with error -22 The underlying cause is an ACPI Address Space Descriptor for a PCI host bridge window that is marked as "consumer". This is a firmware defect: resources that are produced on the downstream side of a bridge should be marked "producer". But rejecting these BARs that we previously allowed is a functionality regression, and firmware has not used the producer/consumer bit consistently, so we can't rely on it anyway. Stop checking the producer/consumer bit, and assume all bridge Address Space Descriptors are for bridge windows. Note that this change does not affect I/O Port or Fixed Location I/O Port Descriptors, which are commonly used for the [io 0x0cf8-0x0cff] config access range. That range is a "consumer" range and should not be treated as a window. Fixes: c770cb4cb505 ("PCI: Mark invalid BARs as unassigned") Link: https://bugzilla.kernel.org/show_bug.cgi?id=96961 Reported-and-tested-by: Tony Luck Signed-off-by: Bjorn Helgaas Acked-by: Rafael J. Wysocki

Merge branch 'acpica'

2015-02-10T14:58:57+00:00

* acpica: ACPICA: Events: Enable APIs to allow interrupt/polling adaptive request based GPE handling model ACPICA: Events: Introduce acpi_set_gpe()/acpi_finish_gpe() to reduce divergences ACPICA: Events: Introduce ACPI_GPE_DISPATCH_RAW_HANDLER to fix 2 issues for the current GPE APIs ACPICA: Update version to 20150204 ACPICA: Update Copyright headers to 2015 ACPICA: Hardware: Cast GPE enable_mask before storing ACPICA: Events: Cleanup GPE dispatcher type obtaining code ACPICA: Events: Cleanup to move acpi_gbl_global_event_handler invocation out of acpi_ev_gpe_dispatch() ACPICA: Events: Cleanup of resetting the GPE handler to NULL before removing ACPICA: Events: Fix uninitialized variable ACPICA: Events: Remove acpi_ev_valid_gpe_event() due to current restriction ACPICA: Events: Remove duplicated sanity check in acpi_ev_enable_gpe() ACPICA: Events: Back port "ACPICA: Save current masks of enabled GPEs after enable register writes" ACPICA: Resources: Provide common part for struct acpi_resource_address structures. ACPI: Introduce acpi_unload_parent_table() usages in Linux kernel ACPICA: take ACPI_MTX_INTERPRETER in acpi_unload_table_id()

ACPICA: Resources: Provide common part for struct acpi_resource_address structures.

2015-01-26T15:09:56+00:00

struct acpi_resource_address and struct acpi_resource_extended_address64 share substracts just at different offsets. To unify the parsing functions, OSPMs like Linux need a new ACPI_ADDRESS64_ATTRIBUTE as their substructs, so they can extract the shared data. This patch also synchronizes the structure changes to the Linux kernel. The usages are searched by matching the following keywords: 1. acpi_resource_address 2. acpi_resource_extended_address 3. ACPI_RESOURCE_TYPE_ADDRESS 4. ACPI_RESOURCE_TYPE_EXTENDED_ADDRESS And we found and fixed the usages in the following files: arch/ia64/kernel/acpi-ext.c arch/ia64/pci/pci.c arch/x86/pci/acpi.c arch/x86/pci/mmconfig-shared.c drivers/xen/xen-acpi-memhotplug.c drivers/acpi/acpi_memhotplug.c drivers/acpi/pci_root.c drivers/acpi/resource.c drivers/char/hpet.c drivers/pnp/pnpacpi/rsparser.c drivers/hv/vmbus_drv.c Build tests are passed with defconfig/allnoconfig/allyesconfig and defconfig+CONFIG_ACPI=n. Original-by: Thomas Gleixner Original-by: Jiang Liu Signed-off-by: Lv Zheng Signed-off-by: Rafael J. Wysocki

ia64/PCI: Clip bridge windows to fit in upstream windows

2015-01-16T16:04:42+00:00

Every PCI-PCI bridge window should fit inside an upstream bridge window because orphaned address space is unreachable from the primary side of the upstream bridge. If we inherit invalid bridge windows that overlap an upstream window from firmware, clip them to fit and update the bridge accordingly. [bhelgaas: changelog] Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491 Reported-by: Marek Kordik Fixes: 5b28541552ef ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources") Signed-off-by: Yinghai Lu Signed-off-by: Bjorn Helgaas CC: Tony Luck CC: Fenghua Yu CC: "Rafael J. Wysocki" CC: linux-ia64@vger.kernel.org

vgaarb: Don't default exclusively to first video device with mem+io

2014-09-16T19:06:18+00:00

Commit 20cde694027e ("x86, ia64: Move EFI_FB vga_default_device() initialization to pci_vga_fixup()") moved boot video device detection from efifb to x86 and ia64 pci/fixup.c. For dual-GPU Apple computers above change represents a regression as code in efifb did forcefully override vga_default_device while the merge did not (vgaarb happens prior to PCI fixup). To improve on initial device selection by vgaarb (it cannot know if PCI device not behind bridges see/decode legacy VGA I/O or not), move the screen_info based check from pci_video_fixup() to vgaarb's init function and use it to refine/override decision taken while adding the individual PCI VGA devices. This way PCI fixup has no reason to adjust vga_default_device anymore but can depend on its value for flagging shadowed VBIOS. This has the nice benefit of removing duplicated code but does introduce a #if defined() block in vgaarb. Not all architectures have screen_info and would cause compile to fail without it. Link: https://bugzilla.kernel.org/show_bug.cgi?id=84461 Reported-and-Tested-By: Andreas Noever Signed-off-by: Bruno Prémont Signed-off-by: Bjorn Helgaas CC: Matthew Garrett CC: stable@vger.kernel.org # v3.5+

x86, ia64: Move EFI_FB vga_default_device() initialization to pci_vga_fixup()

2014-07-10T22:48:48+00:00

Commit b4aa0163056b ("efifb: Implement vga_default_device() (v2)") added efifb vga_default_device() so EFI systems that do not load shadow VBIOS or setup VGA get proper value for boot_vga PCI sysfs attribute on the corresponding PCI device. Xorg doesn't detect devices when boot_vga=0, e.g., on some EFI systems such as MacBookAir2,1. Xorg detects the GPU and finds the DRI device but then bails out with "no devices detected". Note: When vga_default_device() is set boot_vga PCI sysfs attribute reflects its state. When unset this attribute is 1 whenever IORESOURCE_ROM_SHADOW flag is set. With introduction of sysfb/simplefb/simpledrm efifb is getting obsolete while having native drivers for the GPU also makes selecting sysfb/efifb optional. Remove the efifb implementation of vga_default_device() and initialize vgaarb's vga_default_device() with the PCI GPU that matches boot screen_info in pci_fixup_video(). [bhelgaas: remove unused "dev" in efifb_setup()] Fixes: b4aa0163056b ("efifb: Implement vga_default_device() (v2)") Tested-by: Anibal Francisco Martinez Cortina Signed-off-by: Bruno Prémont Signed-off-by: Bjorn Helgaas Acked-by: Matthew Garrett CC: stable@vger.kernel.org # v3.5+

ia64/PCI: Use pci_is_bridge() to simplify code

2014-05-27T20:57:16+00:00

Use pci_is_bridge() to simplify code. No functional change. Requires: 326c1cdae741 PCI: Rename pci_is_bridge() to pci_has_subordinate() Requires: 1c86438c9423 PCI: Add new pci_is_bridge() interface Signed-off-by: Yijing Wang Signed-off-by: Bjorn Helgaas

Merge branch 'pci/misc' into next

2014-02-19T00:02:04+00:00

* pci/misc: PCI: Enable INTx if BIOS left them disabled ia64/PCI: Set IORESOURCE_ROM_SHADOW only for the default VGA device x86/PCI: Set IORESOURCE_ROM_SHADOW only for the default VGA device PCI: Update outdated comment for pcibios_bus_report_status() PCI: Cleanup per-arch list of object files PCI: cpqphp: Fix hex vs decimal typo in cpqhpc_probe() x86/PCI: Fix function definition whitespace x86/PCI: Reword comments x86/PCI: Remove unnecessary local variable initialization PCI: Remove unnecessary list_empty(&pci_pme_list) check

ia64/PCI: Set IORESOURCE_ROM_SHADOW only for the default VGA device

2014-02-14T20:25:45+00:00

Setting the IORESOURCE_ROM_SHADOW flag on a VGA card other than the primary prevents it from reading its own ROM. It will get the content of the shadow ROM at C000 instead, which is of the primary VGA card and the driver of the secondary card will bail out. Fix this by checking if the arch code or vga-arbitration has already determined the vga_default_device, if so only apply the fix to this primary video device and let the comment reflect this. [bhelgaas: add subject, split x86 & ia64 into separate patches, include vgaarb.h] Signed-off-by: Sander Eikelenboom Signed-off-by: Bjorn Helgaas