1. 08 11月, 2013 2 次提交
    • B
      PCI: Enable upstream bridges even for VFs on virtual buses · 79272138
      Bjorn Helgaas 提交于
      Previously we enabled the upstream PCI-to-PCI bridge only when
      "dev->bus->self != NULL".  In the case of a VF on a virtual bus, where
      "bus->self == NULL", we didn't enable the upstream bridge.
      
      This fixes that by enabling the upstream bridge of the PF corresponding to
      the VF.
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Acked-by: NYinghai Lu <yinghai@kernel.org>
      79272138
    • R
      ACPI / hotplug: Consolidate deferred execution of ACPI hotplug routines · 7b98118a
      Rafael J. Wysocki 提交于
      There are two different interfaces for queuing up work items on the
      ACPI hotplug workqueue, alloc_acpi_hp_work() used by PCI and PCI host
      bridge hotplug code and acpi_os_hotplug_execute() used by the common
      ACPI hotplug code and docking stations.  They both are somewhat
      cumbersome to use and work slightly differently.
      
      The users of alloc_acpi_hp_work() have to submit a work function that
      will extract the necessary data items from a struct acpi_hp_work
      object allocated by alloc_acpi_hp_work() and then will free that
      object, while it would be more straightforward to simply use a work
      function with one more argument and let the interface take care of
      the execution details.
      
      The users of acpi_os_hotplug_execute() also have to deal with the
      fact that it takes only one argument in addition to the work function
      pointer, although acpi_os_execute_deferred() actually takes care of
      the allocation and freeing of memory, so it would have been able to
      pass more arguments to the work function if it hadn't been
      constrained by the connection with acpi_os_execute().
      
      Moreover, while alloc_acpi_hp_work() makes GFP_KERNEL memory
      allocations, which is correct, because hotplug work items are
      always queued up from process context, acpi_os_hotplug_execute()
      uses GFP_ATOMIC, as that is needed by acpi_os_execute().  Also,
      acpi_os_execute_deferred() queued up by it waits for the ACPI event
      workqueues to flush before executing the work function, whereas
      alloc_acpi_hp_work() can't do anything similar.  That leads to
      somewhat arbitrary differences in behavior between various ACPI
      hotplug code paths and has to be straightened up.
      
      For this reason, replace both alloc_acpi_hp_work() and
      acpi_os_hotplug_execute() with a single interface,
      acpi_hotplug_execute(), combining their behavior and being more
      friendly to its users than any of the two.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      7b98118a
  2. 07 11月, 2013 2 次提交
    • K
      PCI: Add x86_msi.msi_mask_irq() and msix_mask_irq() · 0e4ccb15
      Konrad Rzeszutek Wilk 提交于
      Certain platforms do not allow writes in the MSI-X BARs to setup or tear
      down vector values.  To combat against the generic code trying to write to
      that and either silently being ignored or crashing due to the pagetables
      being marked R/O this patch introduces a platform override.
      
      Note that we keep two separate, non-weak, functions default_mask_msi_irqs()
      and default_mask_msix_irqs() for the behavior of the arch_mask_msi_irqs()
      and arch_mask_msix_irqs(), as the default behavior is needed by x86 PCI
      code.
      
      For Xen, which does not allow the guest to write to MSI-X tables - as the
      hypervisor is solely responsible for setting the vector values - we
      implement two nops.
      
      This fixes a Xen guest crash when passing a PCI device with MSI-X to the
      guest.  See the bugzilla for more details.
      
      [bhelgaas: add bugzilla info]
      Reference: https://bugzilla.kernel.org/show_bug.cgi?id=64581Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      CC: Sucheta Chakraborty <sucheta.chakraborty@qlogic.com>
      CC: Zhenzhong Duan <zhenzhong.duan@oracle.com>
      0e4ccb15
    • S
      PCI: Warn on driver probe return value greater than zero · f92d74c1
      Stephen M. Cameron 提交于
      Ages ago, drivers could return values greater than zero from their probe
      function and this would be regarded as success.
      
      But after f3ec4f87 ("PCI: change device runtime PM settings for probe
      and remove") and 967577b0 ("PCI/PM: Keep runtime PM enabled for unbound
      PCI devices"), we set dev->driver to NULL if the driver's probe function
      returns a value greater than zero.
      
      __pci_device_probe() treats this as success, and drivers can still mostly
      work even with dev->driver == NULL, but PCI power management doesn't work,
      and we don't call the driver's remove function on rmmod.
      
      To help catch these driver problems, issue a warning in this case.
      
      [bhelgaas: changelog]
      Signed-off-by: NStephen M. Cameron <scameron@beardog.cce.hp.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      f92d74c1
  3. 06 11月, 2013 2 次提交
    • B
      PCI: Drop warning about drivers that don't use pci_set_master() · fbeeb822
      Bjorn Helgaas 提交于
      f41f064c ("PCI: Workaround missing pci_set_master in pci drivers") made
      pci_enable_bridge() turn on bus mastering if the driver hadn't done so
      already.  It also added a warning in this case.  But there's no reason to
      warn about it unless it's actually a problem to enable bus mastering here.
      
      This patch drops the warning because I'm not aware of any such problem.
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      CC: Paul Bolle <pebolle@tiscali.nl>
      fbeeb822
    • Y
      PCI: Workaround missing pci_set_master in pci drivers · cf3e1feb
      Yinghai Lu 提交于
      Ben Herrenschmidt found that commit 928bea96 ("PCI: Delay enabling
      bridges until they're needed") breaks PCI in some powerpc environments.
      
      The reason is that the PCIe port driver will call pci_enable_device() on
      the bridge, so the device is enabled, but skips pci_set_master because
      pcie_port_auto and no acpi on powerpc.
      
      Because of that, pci_enable_bridge() later on (called as a result of the
      child device driver doing pci_enable_device) will see the bridge as
      already enabled and will not call pci_set_master() on it.
      
      Fixed by add checking in pci_enable_bridge, and call pci_set_master
      if driver skip that.
      
      That will make the code more robot and wade off problem for missing
      pci_set_master in drivers.
      Reported-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      cf3e1feb
  4. 01 11月, 2013 2 次提交
    • A
      PCI: Update pcie_ports 'auto' behavior for non-ACPI platforms · 6b87e700
      Andrew Murray 提交于
      The pcie_ports parameter, which defaults to 'auto', allows a user
      to specify if PCIe port services are disabled ('compat'), always
      enabled ('native'), or only used when allowed by the BIOS
      ('auto').
      
      Where CONFIG_ACPI isn't enabled, as is often the case for non
      x86/ia64 platforms, the 'auto' behavior results in that of
      'compat'. Thus in order to use port services on these platforms
      'pcie_ports=native' must be added to the kernel command line.
      
      This patch results in the 'native' behavior being followed where
      'auto' is selected and ACPI is not enabled.
      Signed-off-by: NAndrew Murray <amurray@embedded-bits.co.uk>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      6b87e700
    • M
      PCI: imx6: Probe the PCIe in fs_initcall() · f216f57f
      Marek Vasut 提交于
      Probe the PCIe driver in fs_initcall() instead of module_init()
      to assure that pci_assign_unassigned_resources() will be called
      early.  This function is called in dw_pcie_host_init(), which is
      in turn called from imx6_add_pcie_port(), which is called from
      imx6_pcie_probe().  If this is not called early, we will hit
      resource collisions since pcieport driver is then probed way too
      late.
      Signed-off-by: NMarek Vasut <marex@denx.de>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Acked-by: NShawn Guo <shawn.guo@linaro.org>
      Cc: Frank Li <lznuaa@gmail.com>
      Cc: Jingoo Han <jg1.han@samsung.com>
      Cc: Mohit KUMAR <Mohit.KUMAR@st.com>
      Cc: Pratyush Anand <pratyush.anand@st.com>
      Cc: Richard Zhu <r65037@freescale.com>
      Cc: Sascha Hauer <s.hauer@pengutronix.de>
      Cc: Sean Cross <xobs@kosagi.com>
      Cc: Siva Reddy Kallam <siva.kallam@samsung.com>
      Cc: Srikanth T Shivanand <ts.srikanth@samsung.com>
      Cc: Tim Harvey <tharvey@gateworks.com>
      Cc: Troy Kisky <troy.kisky@boundarydevices.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      f216f57f
  5. 31 10月, 2013 2 次提交
  6. 30 10月, 2013 7 次提交
  7. 24 10月, 2013 5 次提交
  8. 12 10月, 2013 2 次提交
  9. 09 10月, 2013 6 次提交
  10. 08 10月, 2013 7 次提交
  11. 05 10月, 2013 1 次提交
  12. 30 9月, 2013 2 次提交