Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 27 12月, 2012 1 次提交
    • B
      PCI: Add PCIe Link Capability link speed and width names · 130f1b8f
      由 Bjorn Helgaas 提交于 
      Add standard #defines for the Supported Link Speeds field in the PCIe
Link Capabilities register.

Note that prior to PCIe spec r3.0, these encodings were defined:

    0001b  2.5GT/s Link speed supported
    0010b  5.0GT/s and 2.5GT/s Link speed supported

Starting with spec r3.0, these encodings refer to bits 0 and 1 in the
Supported Link Speeds Vector in the Link Capabilities 2 register, and bits
0 and 1 there mean 2.5 GT/s and 5.0 GT/s, respectively.  Therefore, code
that followed r2.0 and interpreted 0x1 as 2.5GT/s and 0x2 as 5.0GT/s will
continue to work, and we can identify a device using the new encodings
because it will have a non-zero Link Capabilities 2 register.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      130f1b8f
  3. 08 12月, 2012 1 次提交
  5. 06 12月, 2012 1 次提交
  7. 10 11月, 2012 1 次提交
  9. 13 10月, 2012 1 次提交
  11. 23 8月, 2012 2 次提交
    • J
      PCI: Add accessors for PCI Express Capability · 8c0d3a02
      由 Jiang Liu 提交于 
      The PCI Express Capability (PCIe spec r3.0, sec 7.8) comes in two
versions, v1 and v2.  In v1 Capability structures (PCIe spec r1.0 and
r1.1), some fields are optional, so the structure size depends on the
device type.

This patch adds functions to access this capability so drivers don't
have to be aware of the differences between v1 and v2.  Note that these
new functions apply only to the "PCI Express Capability," not to any of
the other "PCI Express Extended Capabilities" (AER, VC, ACS, MFVC, etc.)

Function pcie_capability_read_word/dword() reads the PCIe Capabilities
register and returns the value in the reference parameter "val".  If
the PCIe Capabilities register is not implemented on the PCIe device,
"val" is set to 0.

Function pcie_capability_write_word/dword() writes the value to the
specified PCIe Capability register.

Function pcie_capability_clear_and_set_word/dword() sets and/or clears bits
of a PCIe Capability register.

[bhelgaas: changelog, drop "pci_" prefixes, don't export
pcie_capability_reg_implemented()]
Signed-off-by: NJiang Liu <jiang.liu@huawei.com>
Signed-off-by: NYijing Wang <wangyijing@huawei.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      8c0d3a02
    • B
      PCI: Add Vendor-Specific Extended Capability header info · defb9446
      由 Bjorn Helgaas 提交于 
      This adds the fields in the Vendor-Specific Header: ID, Rev, and Length.
There may be multiple Vendor-Specific capabilities, so drivers should use
the VSEC ID to identify the one of interest.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      defb9446
  13. 20 7月, 2012 1 次提交
  15. 10 7月, 2012 1 次提交
    • B
      PCI: reimplement P2P bridge 1K I/O windows (Intel P64H2) · 2b28ae19
      由 Bjorn Helgaas 提交于 
      9d265124 and 15a260d5 added quirks for P2P bridges that support
I/O windows that start/end at 1K boundaries, not just the 4K boundaries
defined by the PCI spec.  For details, see the IOBL_ADR register and the
EN1K bit in the CNF register in the Intel 82870P2 (P64H2).

These quirks complicate the code that reads P2P bridge windows
(pci_read_bridge_io() and pci_cfg_fake_ranges()) because the bridge
I/O resource is updated in the HEADER quirk, in pci_read_bridge_io(),
in pci_setup_bridge(), and again in the FINAL quirk.  This is confusing
and makes it impossible to reassign the bridge windows after FINAL
quirks are run.

This patch adds support for 1K windows in the generic paths, so the
HEADER quirk only has to enable this support.  The FINAL quirk, which
used to undo damage done by pci_setup_bridge(), is no longer needed.

This removes "if (!res->start) res->start = ..." from pci_read_bridge_io();
that was part of 9d265124 to avoid overwriting the resource filled in
by the quirk.  Since pci_read_bridge_io() itself now knows about
granularity, the quirk no longer updates the resource and this test is no
longer needed.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      2b28ae19
  17. 12 6月, 2012 2 次提交
    • A
      PCI: misc pci_reg additions · a0dee2ed
      由 Alex Williamson 提交于 
      Fill in many missing definitions and add sizeof fields for many
sections allowing for more extensive config parsing.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      a0dee2ed
    • M
      PCI: add pci_pcie_cap2() check for PCIe feature capabilities >= v2 · c463b8cb
      由 Myron Stowe 提交于 
      This patch resolves potential issues when accessing PCI Express
Capability structures.  The makeup of the capability varies
substantially between v1 and v2:

    Version 1 of the PCI Express Capability (defined by PCI Express
    1.0 and 1.1 base) neither requires the endpoint to implement the
    entire PCIe capability structure nor specifies default values of
    registers that are not implemented by the device.

    Version 2 of the PCI Express Capability (defined by PCIe 1.1
    Capability Structure Expansion ECN, PCIe 2.0, 2.1, and 3.0) added
    additional registers to the structure and requires all registers
    to be either implemented or hardwired to 0.

Due to the differences in the capability structures, code dealing with
capability features must be careful not to access the additional
registers introduced with v2 unless the device is specifically known to
be a v2 capable device.  Otherwise, attempts to access non-existant
registers will occur.  This is a subtle issue that is hard to track down
when it occurs (and it has - see commit 864d296c).

To try and help mitigate such occurrences, this patch introduces
pci_pcie_cap2() which is similar to pci_pcie_cap() but also checks
that the PCIe capability version is >= 2.  pci_pcie_cap2() should be
used for qualifying PCIe capability features introduced after v1.

Suggested by Don Dutile.
Acked-by: NDonald Dutile <ddutile@redhat.com>
Signed-off-by: NMyron Stowe <myron.stowe@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      c463b8cb
  19. 24 2月, 2012 1 次提交
  21. 07 1月, 2012 2 次提交
  23. 06 12月, 2011 2 次提交
  25. 15 10月, 2011 2 次提交
  27. 12 5月, 2011 3 次提交
  29. 31 3月, 2011 1 次提交
  31. 24 12月, 2010 3 次提交
  33. 18 10月, 2010 1 次提交
  35. 12 5月, 2010 1 次提交
  37. 28 4月, 2010 1 次提交
  39. 24 2月, 2010 1 次提交
    • J
      x86/PCI: Moorestown PCI support · a712ffbc
      由 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>
      a712ffbc
  41. 05 11月, 2009 2 次提交
    • G
      PCI: populate subsystem vendor and device IDs for PCI bridges · bc577d2b
      由 Gabe Black 提交于 
      Change to populate the subsystem vendor and subsytem device IDs for
PCI-PCI bridges that implement the PCI Subsystem Vendor ID capability.
Previously bridges left subsystem vendor IDs unpopulated.
Signed-off-by: NGabe Black <gabe.black@ni.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      bc577d2b
    • A
      PCI: acs p2p upsteram forwarding enabling · ae21ee65
      由 Allen Kay 提交于 
      Note: dom0 checking in v4 has been separated out into 2/2.

This patch enables P2P upstream forwarding in ACS capable PCIe switches.
It solves two potential problems in virtualization environment where a PCIe
device is assigned to a guest domain using a HW iommu such as VT-d:

1) Unintentional failure caused by guest physical address programmed
   into the device's DMA that happens to match the memory address range
   of other downstream ports in the same PCIe switch.  This causes the PCI
   transaction to go to the matching downstream port instead of go to the
   root complex to get translated by VT-d as it should be.

2) Malicious guest software intentionally attacks another downstream
   PCIe device by programming the DMA address into the assigned device
   that matches memory address range of the downstream PCIe port.

We are in process of implementing device filtering software in KVM/XEN
management software to allow device assignment of PCIe devices behind a PCIe
switch only if it has ACS capability and with the P2P upstream forwarding bits
enabled.  This patch is intended to work for both KVM and Xen environments.
Signed-off-by: NAllen Kay <allen.m.kay@intel.com>
Reviewed-by: NMathew Wilcox <willy@linux.intel.com>
Reviewed-by: NChris Wright <chris@sous-sol.org>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      ae21ee65
  43. 16 9月, 2009 1 次提交
  45. 12 6月, 2009 2 次提交
  47. 18 5月, 2009 1 次提交
  49. 23 4月, 2009 1 次提交
    • Y
      PCI: only save/restore existent registers in the PCIe capability · 1b6b8ce2
      由 Yu Zhao 提交于 
      PCIe 1.1 base neither requires the endpoint to implement the entire
PCIe capability structure nor specifies default values of registers
that are not implemented by the device. So we only save and restore
registers that must be implemented by different device types if the
device PCIe capability version is 1.

PCIe 1.1 Capability Structure Expansion ECN and PCIe 2.0 requires
all registers in the PCIe capability to be either implemented or
hardwired to 0. Their PCIe capability version is 2.
Signed-off-by: NYu Zhao <yu.zhao@intel.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      1b6b8ce2
  51. 27 3月, 2009 1 次提交
  53. 21 3月, 2009 2 次提交
  55. 08 1月, 2009 1 次提交