Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 11 6月, 2016 4 次提交
  3. 17 5月, 2016 2 次提交
  5. 12 5月, 2016 3 次提交
    • T
      PCI, of: Move PCI I/O space management to PCI core code · c5076cfe
      由 Tomasz Nowicki 提交于 
      No functional changes in this patch.

PCI I/O space mapping code does not depend on OF; therefore it can be moved
to PCI core code.  This way we will be able to use it, e.g., in ACPI PCI
code.
Suggested-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: NTomasz Nowicki <tn@semihalf.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: Arnd Bergmann <arnd@arndb.de>
CC: Liviu Dudau <Liviu.Dudau@arm.com>
      c5076cfe
    • J
      PCI: generic, thunder: Use generic ECAM API · 1958e717
      由 Jayachandran C 提交于 
      Use functions provided by drivers/pci/ecam.h for mapping the config space
in drivers/pci/host/pci-host-common.c, and update its users to use 'struct
pci_config_window' and 'struct pci_ecam_ops'.

The changes are mostly to use 'struct pci_config_window' in place of
'struct gen_pci'.  Some of the fields of gen_pci were only used temporarily
and can be eliminated by using local variables or function arguments, these
are not carried over to struct pci_config_window.

pci-thunder-ecam.c and pci-thunder-pem.c are the only users of the
pci_host_common_probe function and the gen_pci structure; these have been
updated to use the new API as well.

The patch does not introduce any functional changes other than a very minor
one: with the new code, on 64-bit platforms, we do just a single ioremap
for the whole config space.
Signed-off-by: NJayachandran C <jchandra@broadcom.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      1958e717
    • J
      PCI: Provide common functions for ECAM mapping · 35ff9477
      由 Jayachandran C 提交于 
      Add config option PCI_ECAM and file drivers/pci/ecam.c to provide generic
functions for accessing memory-mapped PCI config space.

The API is defined in drivers/pci/ecam.h and is written to replace the API
in drivers/pci/host/pci-host-common.h.  The file defines a new 'struct
pci_config_window' to hold the information related to a PCI config area and
its mapping.  This structure is expected to be used as sysdata for
controllers that have ECAM based mapping.

Helper functions are provided to setup the mapping, free the mapping and to
implement the map_bus method in 'struct pci_ops'
Signed-off-by: NJayachandran C <jchandra@broadcom.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      35ff9477
  7. 11 5月, 2016 2 次提交
  9. 05 5月, 2016 2 次提交
    • V
      PCI: hv: Add explicit barriers to config space access · bdd74440
      由 Vitaly Kuznetsov 提交于 
      I'm trying to pass-through Broadcom BCM5720 NIC (Dell device 1f5b) on a
Dell R720 server.  Everything works fine when the target VM has only one
CPU, but SMP guests reboot when the NIC driver accesses PCI config space
with hv_pcifront_read_config()/hv_pcifront_write_config().  The reboot
appears to be induced by the hypervisor and no crash is observed.  Windows
event logs are not helpful at all ('Virtual machine ... has quit
unexpectedly').  The particular access point is always different and
putting debug between them (printk/mdelay/...) moves the issue further
away.  The server model affects the issue as well: on Dell R420 I'm able to
pass-through BCM5720 NIC to SMP guests without issues.

While I'm obviously failing to reveal the essence of the issue I was able
to come up with a (possible) solution: if explicit barriers are added to
hv_pcifront_read_config()/hv_pcifront_write_config() the issue goes away.
The essential minimum is rmb() at the end on _hv_pcifront_read_config() and
wmb() at the end of _hv_pcifront_write_config() but I'm not confident it
will be sufficient for all hardware.  I suggest the following barriers:

1) wmb()/mb() between choosing the function and writing to its space.
2) mb() before releasing the spinlock in both _hv_pcifront_read_config()/
   _hv_pcifront_write_config() to ensure that consecutive reads/writes to
  the space won't get re-ordered as drivers may count on that.

Config space access is not supposed to be performance-critical so these
explicit barriers should not cause any slowdown.

[bhelgaas: use Linux "barriers" terminology]
Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NJake Oshins <jakeo@microsoft.com>
      bdd74440
    • L
      PCI: Use cached copy of PCI_EXP_SLTCAP_HPC bit · f8415222
      由 Lukas Wunner 提交于 
      We cache the PCI_EXP_SLTCAP_HPC bit in pci_dev->is_hotplug_bridge on device
probe, so there's no need to read it again on allocation of port service
devices.

No functional change intended.
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      f8415222
  11. 03 5月, 2016 11 次提交
  13. 01 5月, 2016 1 次提交
  15. 29 4月, 2016 1 次提交
  17. 27 4月, 2016 1 次提交
  19. 26 4月, 2016 2 次提交
    • B
      PCI: Supply CPU physical address (not bus address) to iomem_is_exclusive() · ca620723
      由 Bjorn Helgaas 提交于 
      iomem_is_exclusive() requires a CPU physical address, but on some arches we
supplied a PCI bus address instead.

On most arches, pci_resource_to_user(res) returns "res->start", which is a
CPU physical address.  But on microblaze, mips, powerpc, and sparc, it
returns the PCI bus address corresponding to "res->start".

The result is that pci_mmap_resource() may fail when it shouldn't (if the
bus address happens to match an existing resource), or it may succeed when
it should fail (if the resource is exclusive but the bus address doesn't
match it).

Call iomem_is_exclusive() with "res->start", which is always a CPU physical
address, not the result of pci_resource_to_user().

Fixes: e8de1481 ("resource: allow MMIO exclusivity for device drivers")
Suggested-by: NYinghai Lu <yinghai@kernel.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: Arjan van de Ven <arjan@linux.intel.com>
      ca620723
    • M
      PCI: keystone: Remove unnecessary goto statement · 1e9f8dcf
      由 Murali Karicheri 提交于 
      Fix the misuse of goto statement in ks_pcie_get_irq_controller_info() as
simple return is more appropriate for this function.  While at it add an
error log for absence of interrupt controller node.

[bhelgaas: drop "ret" altogether since we always know the return value]
Signed-off-by: NMurali Karicheri <m-karicheri2@ti.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: Rob Herring <robh+dt@kernel.org>
CC: Pawel Moll <pawel.moll@arm.com>
CC: Mark Rutland <mark.rutland@arm.com>
CC: Ian Campbell <ijc+devicetree@hellion.org.uk>
CC: Kumar Gala <galak@codeaurora.org>
      1e9f8dcf
  21. 22 4月, 2016 1 次提交
  23. 20 4月, 2016 7 次提交
    • T
      PCI: imx6: Add DT property for link gen, default to Gen1 · a5fcec48
      由 Tim Harvey 提交于 
      Freescale has stated [1] that the LVDS clock source of the IMX6 does not
pass the PCI Gen2 clock jitter test, therefore unless an external Gen2
compliant external clock source is present and supplied back to the IMX6
PCIe core via LVDS CLK1/CLK2 you can not claim Gen2 compliance.

Add a DT property to specify Gen1 vs Gen2 and check this before allowing a
Gen2 link.

We default to Gen1 if the property is not present because at this time
there are no IMX6 boards in mainline that 'input' a clock on LVDS
CLK1/CLK2.

In order to be Gen2 compliant on IMX6 you need to:

 - Have a Gen2 compliant external clock generator and route that clock back
   to either LVDS CLK1 or LVDS CLK2 as an input (see IMX6SX-SabreSD
   reference design).

 - Specify this clock in the PCIe node in the DT (i.e.,
   IMX6QDL_CLK_LVDS1_IN or IMX6QDL_CLK_LVDS2_IN instead of
   IMX6QDL_CLK_LVDS1_GATE which configures it as a CLK output).

[1] https://community.freescale.com/message/453209Signed-off-by: NTim Harvey <tharvey@gateworks.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NLucas Stach <l.stach@pengutronix.de>
CC: Fabio Estevam <fabio.estevam@freescale.com>
CC: Zhu Richard <Richard.Zhu@freescale.com>
CC: Akshay Bhat <akshay.bhat@timesys.com>
CC: Rob Herring <robh+dt@kernel.org>
CC: Shawn Guo <shawnguo@kernel.org>
      a5fcec48
    • P
      PCI: imx6: Add reset-gpio-active-high boolean property to DT · 3ea8529a
      由 Petr Štetiar 提交于 
      Currently the reset-gpio DT property which controls the PCI bus device
reset signal defaults to active-low reset sequence (L=reset state,
H=operation state) plus the code in reset function isn't GPIO polarity
aware - it doesn't matter if the defined reset-gpio is active-low or
active-high, it will always result into active-low reset sequence.

I've tried to fix it properly and change the reset-gpio reset sequence to
be polarity-aware, but this patch has been accepted and then reverted as it
has introduced few backward incompatible issues:

1. Some DTBs, for example, imx6qdl-sabresd, don't define reset-gpio
polarity correctly:

  reset-gpio = <&gpio7 12 0>;

which means that it's defined as active-high, but in reality it's
active-low; thus it wouldn't work without a DTS fix.

2. The logic in the reset function is inverted:

	gpio_set_value_cansleep(imx6_pcie->reset_gpio, 0)
	msleep(100);
	gpio_set_value_cansleep(imx6_pcie->reset_gpio, 1);

so even if some of the i.MX6 boards had reset-gpio polarity defined
correctly in their DTSes, they would stop working.

As we can't break old DTBs, we can't fix them, so we need to introduce this
new DT reset-gpio-active-high boolean property so we can support boards
with active-high reset sequence.

This active-high reset sequence is for example needed on Apalis SoMs, where
GPIO1_IO28, used to PCIe reset is not connected directly to PERST# PCIe
signal, but it's ORed with RESETBMCU coming off the PMIC, and thus is
inverted, active-high.

Tested-by: Tim Harvey <tharvey@gateworks.com>	# Gateworks Ventana boards (which have active-low PERST#)
Signed-off-by: NPetr Štetiar <ynezz@true.cz>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NLucas Stach <l.stach@pengutronix.de>
Acked-by: NRob Herring <robh@kernel.org>
      3ea8529a
    • C
      PCI: imx6: Add initial imx6sx support · e3c06cd0
      由 Christoph Fritz 提交于 
      Add initial PCIe support for the imx6 SoC derivate imx6sx.  PCI MSI support
is untested as the necessary suspend/resume quirk is not included in this
patch.

This patch is heavily based on patches by Richard Zhu.

[bhelgaas: factor out refclk enable, fix adjacent typos in imx6q-pcie.txt]
Signed-off-by: NChristoph Fritz <chf.fritz@googlemail.com>
Acked-by: NRichard Zhu <Richard.Zhu@freescale.com>
Acked-by: NLucas Stach <l.stach@pengutronix.de>
      e3c06cd0
    • B
      PCI: imx6: Factor out ref clock enable · 4d1821e7
      由 Bjorn Helgaas 提交于 
      Factor out ref clock enable to make it cleaner to add imx6sx support.  No
functional change intended.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Tested-by: NChristoph Fritz <chf.fritz@googlemail.com>
      4d1821e7
    • A
      PCI: Work around Intel Sunrise Point PCH incorrect ACS capability · 1bf2bf22
      由 Alex Williamson 提交于 
      Intel Sunrise Point root ports implement ACS but use dwords for the
capability and control registers, putting the control register at the wrong
offset.

Use quirks to enable and test ACS for these devices, which match the
standard functions modulo the broken control register offset.

Note that lspci assumes devices implement ACS per spec, so it shows invalid
ACS data for these devices.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      1bf2bf22
    • A
      PCI: Reverse standard ACS vs device-specific ACS enabling · c1d61c9b
      由 Alex Williamson 提交于 
      The original thought was that if a device implemented ACS, then surely
we want to use that... well, it turns out that devices can make an ACS
capability so broken that we still need to fall back to quirks.

Reverse the order of ACS enabling to give quirks first shot at it.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      c1d61c9b
    • A
      PCI: Mark Intel i40e NIC INTx masking as broken · 8bcf4525
      由 Alex Williamson 提交于 
      All of the i40e (XL710/X710) 10/20/40GbE NICs lack support for indicating
INTx is asserted via the interrupt bit in the PCI status register.  The
DisINTx bit in the command register is functional, causing these devices to
be incorrectly detected as supporting INTx masking.  Quirk them to properly
indicate no INTx masking support.

Device IDs copied from i40e_devids.h.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: John Ronciak <john.ronciak@intel.com>
CC: Jesse Brandeburg <jesse.brandeburg@intel.com>
      8bcf4525
  25. 16 4月, 2016 1 次提交
  27. 15 4月, 2016 2 次提交