Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 21 8月, 2015 4 次提交
  3. 26 6月, 2015 2 次提交
  5. 25 6月, 2015 1 次提交
    • T
      PCI/keystone: Fix race in installing chained IRQ handler · 2cf5a03c
      由 Thomas Gleixner 提交于 
      Fix a race where a pending interrupt could be received and the handler
called before the handler's data has been setup, by converting to
irq_set_chained_handler_and_data().

Search and conversion was done with coccinelle:

@@
expression E1, E2, E3;
@@
(
-if (irq_set_chained_handler(E1, E3) != 0)
-   BUG();
|
-irq_set_chained_handler(E1, E3);
)
-irq_set_handler_data(E1, E2);
+irq_set_chained_handler_and_data(E1, E3, E2);

@@
expression E1, E2, E3;
@@
(
-if (irq_set_chained_handler(E1, E3) != 0)
-   BUG();
...
|
-irq_set_chained_handler(E1, E3);
...
)
-irq_set_handler_data(E1, E2);
+irq_set_chained_handler_and_data(E1, E3, E2);
Reported-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Cc: Julia Lawall <Julia.Lawall@lip6.fr>
Cc: Murali Karicheri <m-karicheri2@ti.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: linux-pci@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
      2cf5a03c
  7. 19 6月, 2015 5 次提交
  9. 18 6月, 2015 1 次提交
    • B
      PCI: pciehp: Clean up debug logging · 3784e0c6
      由 Bjorn Helgaas 提交于 
      The pciehp debug logging is overly verbose and often redundant.  Almost all
of the information printed by dbg_ctrl() is also printed by the normal PCI
core enumeration code and by pcie_init().

Remove the redundant debug info.

When claiming a pciehp bridge, we print the slot characteristics, e.g.,

  Slot #6 AttnBtn- AttnInd- PwrInd- PwrCtrl- MRL- Interlock- NoCompl+ LLActRep+

Add the Hot-Plug Capable and Hot-Plug Surprise bits to this information,
and print it all in the same order as lspci does.

No functional change except the message text changes.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NRajat Jain <rajatja@google.com>
Acked-by: NYinghai Lu <yinghai@kernel.org>
      3784e0c6
  11. 16 6月, 2015 2 次提交
  13. 13 6月, 2015 3 次提交
  15. 11 6月, 2015 5 次提交
  17. 09 6月, 2015 1 次提交
    • A
      PCI: pciehp: Wait for hotplug command completion where necessary · a5dd4b4b
      由 Alex Williamson 提交于 
      The commit referenced below deferred waiting for command completion until
the start of the next command, allowing hardware to do the latching
asynchronously.  Unfortunately, being ready to accept a new command is the
only indication we have that the previous command is completed.  In cases
where we need that state change to be enabled, we must still wait for
completion.  For instance, pciehp_reset_slot() attempts to disable anything
that might generate a surprise hotplug on slots that support presence
detection.  If we don't wait for those settings to latch before the
secondary bus reset, we negate any value in attempting to prevent the
spurious hotplug.

Create a base function with optional wait and helper functions so that
pcie_write_cmd() turns back into the "safe" interface which waits before
and after issuing a command and add pcie_write_cmd_nowait(), which
eliminates the trailing wait for asynchronous completion.  The following
functions are returned to their previous behavior:

  pciehp_power_on_slot
  pciehp_power_off_slot
  pcie_disable_notification
  pciehp_reset_slot

The rationale is that pciehp_power_on_slot() enables the link and therefore
relies on completion of power-on.  pciehp_power_off_slot() and
pcie_disable_notification() need a wait because data structures may be
freed after these calls and continued signaling from the device would be
unexpected.  And, of course, pciehp_reset_slot() needs to wait for the
scenario outlined above.

Fixes: 3461a068 ("PCI: pciehp: Wait for hotplug command completion lazily")
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org	# v3.17+
      a5dd4b4b
  19. 08 6月, 2015 1 次提交
  21. 06 6月, 2015 1 次提交
    • D
      PCI: xgene: Add APM X-Gene v1 PCIe MSI/MSIX termination driver · dcd19de3
      由 Duc Dang 提交于 
      APM X-Gene v1 SoC supports its own implementation of MSI, which is not
compliant to GIC V2M specification for MSI Termination.

There is a single MSI block in X-Gene v1 SOC which serves all 5 PCIe ports.
This MSI block supports 2048 MSI termination ports coalesced into 16
physical HW IRQ lines and shared across all 5 PCIe ports.

As there are only 16 HW IRQs to serve 2048 MSI vectors, to support
set_affinity correctly for each MSI vectors, the 16 HW IRQs are statically
allocated to 8 X-Gene v1 cores (2 HW IRQs for each cores).  To steer MSI
interrupt to target CPU, MSI vector is moved around these HW IRQs lines.
With this approach, the total MSI vectors this driver supports is reduced
to 256.

[bhelgaas: squash doc, driver, maintainer update]
Signed-off-by: NDuc Dang <dhdang@apm.com>
Signed-off-by: NTanmay Inamdar <tinamdar@apm.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NMarc Zyngier <marc.zyngier@arm.com>
      dcd19de3
  23. 03 6月, 2015 1 次提交
  25. 02 6月, 2015 1 次提交
    • Y
      PCI: Preserve resource size during alignment reordering · 552bc94e
      由 Yinghai Lu 提交于 
      In d74b9027 ("PCI: Consider additional PF's IOV BAR alignment in sizing
and assigning"), we store additional alignment in realloc_head and take
this into consideration for assignment.

In __assign_resources_sorted(), we changed dev_res->res->start, then used
resource_start() (which depends on res->start), so the recomputed res->end
was completely bogus.  Even if we'd had the correct size, the end would
have been off by one.

Preserve the resource size when we adjust its alignment.

[bhelgaas: changelog]
Fixes: d74b9027 ("PCI: Consider additional PF's IOV BAR alignment in sizing and assigning")
Signed-off-by: NYinghai Lu <yinghai@kernel.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NWei Yang <weiyang@linux.vnet.ibm.com>
CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      552bc94e
  27. 30 5月, 2015 3 次提交
  29. 28 5月, 2015 5 次提交
  31. 27 5月, 2015 2 次提交
    • Y
      PCI: mvebu: Remove mvebu_pcie_scan_bus() · 2dead00b
      由 Yijing Wang 提交于 
      After b97ea289 ("PCI: Assign resources before drivers claim devices
(pci_scan_root_bus())"), pci_scan_root_bus() no longer adds the devices, so
it is equivalent to mvebu_pcie_scan_bus().

Remove mvebu_pcie_scan_bus() (the hw.scan method), so we use the generic
pci_scan_root_bus() path.  We also need to use pci_common_init_dev()
instead of pci_common_init() so we can supply the host bridge device
pointer.

[bhelgaas: changelog]
Tested-by: NGregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: NYijing Wang <wangyijing@huawei.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NGregory CLEMENT <gregory.clement@free-electrons.com>
CC: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
CC: Jason Cooper <jason@lakedaemon.net>
      2dead00b
    • Y
      PCI/ASPM: Use dev->has_secondary_link to find downstream links · c8fc9339
      由 Yijing Wang 提交于 
      We allocate pcie_link_state for the component at the upstream end of a
Link.  Previously we did this by allocating pcie_link_state for Root Ports
and Downstream Ports.  This works fine for the typical topology:

  00:1c.0 Root Port       [bridge to bus 02]
  02:00.0 Upstream Port   [bridge to bus 03]
  03:00.0 Downstream Port [bridge to bus 04]
  04:00.0 Endpoint or Switch Port

However, it is possible to have a Root Port connected to a Downstream Port
instead of an Upstream Port, as in Robert White's ATCA system:

  00:1c.0 Root Port       [bridge to bus 02]
  02:00.0 Downstream Port [bridge to bus 03]
  03:01.0 Downstream Port [bridge to bus 04]
  04:00.0 Endpoint or Switch Port

In this topology, we wrongly allocated pcie_link_state for the 02:00.0
Downstream Port, which is actually the *downstream* end of a link.  This
led to the following NULL pointer dereference when we tried to connect this
link into the tree of links starting at the 00:1c.0 Root Port:

  BUG: unable to handle kernel NULL pointer dereference at 0000000000000088
  IP: [<ffffffff81550324>] pcie_aspm_init_link_state+0x744/0x850
  Hardware name: Kontron B3001/B3001, BIOS 4.6.3 08/07/2012
  Call Trace:
   [<ffffffff8153b865>] pci_scan_slot+0xd5/0x120
   [<ffffffff8153ca1d>] pci_scan_child_bus+0x2d/0xd0
   ...

Instead of relying on the component type to identify the upstream end of a
link, use the "dev->has_secondary_link" field.

This means it's now possible for an Upstream Port to have a link on its
secondary side, so alloc_pcie_link_state() needs to connect links
originating from both Upstream and Downstream Ports into the tree.

[bhelgaas: changelog, add comment]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=94361
Link: http://lkml.kernel.org/r/54EB81B2.4050904@pobox.comReported-by: NRobert White <rwhite@pobox.com>
Signed-off-by: NYijing Wang <wangyijing@huawei.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      c8fc9339
  33. 23 5月, 2015 2 次提交