Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 31 1月, 2018 3 次提交
  3. 02 11月, 2017 1 次提交
    • G
      License cleanup: add SPDX GPL-2.0 license identifier to files with no license · b2441318
      由 Greg Kroah-Hartman 提交于 
      Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.

By default all files without license information are under the default
license of the kernel, which is GPL version 2.

Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier.  The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.

This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.

How this work was done:

Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
 - file had no licensing information it it.
 - file was a */uapi/* one with no licensing information in it,
 - file was a */uapi/* one with existing licensing information,

Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.

The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne.  Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.

The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed.  Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.

Criteria used to select files for SPDX license identifier tagging was:
 - Files considered eligible had to be source code files.
 - Make and config files were included as candidates if they contained >5
   lines of source
 - File already had some variant of a license header in it (even if <5
   lines).

All documentation files were explicitly excluded.

The following heuristics were used to determine which SPDX license
identifiers to apply.

 - when both scanners couldn't find any license traces, file was
   considered to have no license information in it, and the top level
   COPYING file license applied.

   For non */uapi/* files that summary was:

   SPDX license identifier                            # files
   ---------------------------------------------------|-------
   GPL-2.0                                              11139

   and resulted in the first patch in this series.

   If that file was a */uapi/* path one, it was "GPL-2.0 WITH
   Linux-syscall-note" otherwise it was "GPL-2.0".  Results of that was:

   SPDX license identifier                            # files
   ---------------------------------------------------|-------
   GPL-2.0 WITH Linux-syscall-note                        930

   and resulted in the second patch in this series.

 - if a file had some form of licensing information in it, and was one
   of the */uapi/* ones, it was denoted with the Linux-syscall-note if
   any GPL family license was found in the file or had no licensing in
   it (per prior point).  Results summary:

   SPDX license identifier                            # files
   ---------------------------------------------------|------
   GPL-2.0 WITH Linux-syscall-note                       270
   GPL-2.0+ WITH Linux-syscall-note                      169
   ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause)    21
   ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)    17
   LGPL-2.1+ WITH Linux-syscall-note                      15
   GPL-1.0+ WITH Linux-syscall-note                       14
   ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause)    5
   LGPL-2.0+ WITH Linux-syscall-note                       4
   LGPL-2.1 WITH Linux-syscall-note                        3
   ((GPL-2.0 WITH Linux-syscall-note) OR MIT)              3
   ((GPL-2.0 WITH Linux-syscall-note) AND MIT)             1

   and that resulted in the third patch in this series.

 - when the two scanners agreed on the detected license(s), that became
   the concluded license(s).

 - when there was disagreement between the two scanners (one detected a
   license but the other didn't, or they both detected different
   licenses) a manual inspection of the file occurred.

 - In most cases a manual inspection of the information in the file
   resulted in a clear resolution of the license that should apply (and
   which scanner probably needed to revisit its heuristics).

 - When it was not immediately clear, the license identifier was
   confirmed with lawyers working with the Linux Foundation.

 - If there was any question as to the appropriate license identifier,
   the file was flagged for further research and to be revisited later
   in time.

In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.

Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights.  The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.

Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.

In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.

Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
 - a full scancode scan run, collecting the matched texts, detected
   license ids and scores
 - reviewing anything where there was a license detected (about 500+
   files) to ensure that the applied SPDX license was correct
 - reviewing anything where there was no detection but the patch license
   was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
   SPDX license was correct

This produced a worksheet with 20 files needing minor correction.  This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.

These .csv files were then reviewed by Greg.  Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected.  This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.)  Finally Greg ran the script using the .csv files to
generate the patches.
Reviewed-by: NKate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: NPhilippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b2441318
  5. 06 10月, 2017 1 次提交
    • L
      PCI: v3-semi: Add V3 Semiconductor PCI host driver · 68a15eb7
      由 Linus Walleij 提交于 
      This PCI host bridge from V3 Semiconductor needs no further
introduction. An ancient driver for it has been sitting in
arch/arm/mach-integrator/pci_v3.* since before v2.6.12 and the
initial migration to git.

But we need to get the drivers out of arch/arm/* and get proper handling of
the old drivers, rewrite and clean up so the PCI maintainer can control the
mass of drivers without having to run all over the kernel. We also switch
swiftly to all the new infrastructure found in the PCI hosts as of late.

Some code is preserved so I have added an extensive list of authors in the
top comment section.

This driver probes with the following result:

  OF: PCI: host bridge /pciv3@62000000 ranges:
  OF: PCI:   No bus range found for /pciv3@62000000, using [bus 00-ff]
  OF: PCI:    IO 0x60000000..0x6000ffff -> 0x00000000
  OF: PCI:   MEM 0x40000000..0x4fffffff -> 0x40000000
  OF: PCI:   MEM 0x50000000..0x5fffffff -> 0x50000000
  pci-v3-semi 62000000.pciv3: initialized PCI V3 Integrator/AP integration
  pci-v3-semi 62000000.pciv3: PCI host bridge to bus 0000:00
  pci_bus 0000:00: root bus resource [bus 00-ff]
  pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
  pci_bus 0000:00: root bus resource [mem 0x40000000-0x4fffffff]
  pci_bus 0000:00: root bus resource [mem 0x50000000-0x5fffffff pref]
  pci-v3-semi 62000000.pciv3: parity error interrupt
  pci-v3-semi 62000000.pciv3: master abort error interrupt
  pci-v3-semi 62000000.pciv3: PCI target LB->PCI READ abort interrupt
  pci-v3-semi 62000000.pciv3: master abort error interrupt
  (repeats a few times)
  pci 0000:00:09.0: [1011:0024] type 01 class 0x060400
  pci-v3-semi 62000000.pciv3: master abort error interrupt
  pci-v3-semi 62000000.pciv3: PCI target LB->PCI READ abort interrupt
  pci 0000:00:0b.0: [8086:1229] type 00 class 0x020000
  pci 0000:00:0b.0: reg 0x10: [mem 0x00000000-0x00000fff pref]
  pci 0000:00:0b.0: reg 0x14: [io  0x0000-0x001f]
  pci 0000:00:0b.0: reg 0x18: [mem 0x00000000-0x000fffff]
  pci 0000:00:0b.0: reg 0x30: [mem 0x00000000-0x000fffff pref]
  pci 0000:00:0b.0: supports D1 D2
  pci 0000:00:0b.0: PME# supported from D0 D1 D2 D3hot
  pci 0000:00:0c.0: [5333:8811] type 00 class 0x030000
  pci 0000:00:0c.0: reg 0x10: [mem 0x00000000-0x03ffffff]
  pci 0000:00:0c.0: reg 0x30: [mem 0x00000000-0x0000ffff pref]
  pci 0000:00:0c.0: vgaarb: VGA device added: decodes=io+mem,owns=io,locks=none
  PCI: bus0: Fast back to back transfers disabled
  PCI: bus1: Fast back to back transfers enabled
  pci 0000:00:0c.0: BAR 0: assigned [mem 0x40000000-0x43ffffff]
  pci 0000:00:0b.0: BAR 2: assigned [mem 0x44000000-0x440fffff]
  pci 0000:00:0b.0: BAR 6: assigned [mem 0x50000000-0x500fffff pref]
  pci 0000:00:0c.0: BAR 6: assigned [mem 0x50100000-0x5010ffff pref]
  pci 0000:00:0b.0: BAR 0: assigned [mem 0x50110000-0x50110fff pref]
  pci 0000:00:0b.0: BAR 1: assigned [io  0x1000-0x101f]
  pci 0000:00:09.0: PCI bridge to [bus 01]
  pci 0000:00:0b.0: Firmware left e100 interrupts enabled; disabling
  (...)
  e100: Intel(R) PRO/100 Network Driver, 3.5.24-k2-NAPI
  e100: Copyright(c) 1999-2006 Intel Corporation
  e100 0000:00:0b.0: enabling device (0146 -> 0147)
  e100 0000:00:0b.0 eth0: addr 0x50110000, irq 31, MAC addr 00:08:c7:99:d2:57

> lspci
  00:0b.0 Class 0200: 8086:1229
  00:09.0 Class 0604: 1011:0024
  00:0c.0 Class 0300: 5333:8811

> cat /proc/iomem
  40000000-4fffffff : V3 PCI NON-PRE-MEM
    40000000-43ffffff : 0000:00:0c.0
    44000000-440fffff : 0000:00:0b.0
      44000000-440fffff : e100
  50000000-5fffffff : V3 PCI PRE-MEM
    50000000-500fffff : 0000:00:0b.0
    50100000-5010ffff : 0000:00:0c.0
    50110000-50110fff : 0000:00:0b.0
      50110000-50110fff : e100
  61000000-61ffffff : /pciv3@62000000
  62000000-6200ffff : /pciv3@62000000
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
[bhelgaas: fold in %pR fixes from Arnd Bergmann <arnd@arndb.de>:
http://lkml.kernel.org/r/20171011140224.3770968-1-arnd@arndb.de]
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: Marc Gonzalez <marc_gonzalez@sigmadesigns.com>
      68a15eb7
  7. 08 7月, 2017 1 次提交
  9. 03 7月, 2017 1 次提交
  11. 24 3月, 2017 1 次提交
    • L
      PCI: faraday: Add Faraday Technology FTPCI100 PCI Host Bridge driver · d3c68e0a
      由 Linus Walleij 提交于 
      Add a host bridge driver for the Faraday Technology FPPCI100 host bridge,
used for Cortina Systems Gemini SoC (SL3516) PCI Host Bridge.

This code is inspired by the out-of-tree OpenWRT patch and then extensively
rewritten for device tree and using the modern helpers to cut down and
modernize the code to all new PCI frameworks.  A driver exists in U-Boot as
well.

Tested on the ITian Square One SQ201 NAS with the following result in the
boot log (trimmed to relevant parts):

  OF: PCI: host bridge /soc/pci@50000000 ranges:
  OF: PCI:    IO 0x50000000..0x500fffff -> 0x00000000
  OF: PCI:   MEM 0x58000000..0x5fffffff -> 0x58000000
  ftpci100 50000000.pci: PCI host bridge to bus 0000:00
  pci_bus 0000:00: root bus resource [bus 00-ff]
  pci_bus 0000:00: root bus resource [io  0x0000-0xfffff]
  pci_bus 0000:00: root bus resource [mem 0x58000000-0x5fffffff]
  ftpci100 50000000.pci:
    DMA MEM1 BASE: 0x0000000000000000 -> 0x0000000007ffffff config 00070000
  ftpci100 50000000.pci:
    DMA MEM2 BASE: 0x0000000000000000 -> 0x0000000003ffffff config 00060000
  ftpci100 50000000.pci:
    DMA MEM3 BASE: 0x0000000000000000 -> 0x0000000003ffffff config 00060000
  PCI: bus0: Fast back to back transfers disabled
  pci 0000:00:00.0: of_irq_parse_pci() failed with rc=-22
  pci 0000:00:0c.0: BAR 0: assigned [mem 0x58000000-0x58007fff]
  pci 0000:00:09.2: BAR 0: assigned [mem 0x58008000-0x580080ff]
  pci 0000:00:09.0: BAR 4: assigned [io  0x1000-0x101f]
  pci 0000:00:09.1: BAR 4: assigned [io  0x1020-0x103f]
  pci 0000:00:09.0: enabling device (0140 -> 0141)
  pci 0000:00:09.0: HCRESET not completed yet!
  pci 0000:00:09.1: enabling device (0140 -> 0141)
  pci 0000:00:09.1: HCRESET not completed yet!
  pci 0000:00:09.2: enabling device (0140 -> 0142)
  rt61pci 0000:00:0c.0: enabling device (0140 -> 0142)
  ieee80211 phy0: rt2x00_set_chip: Info - Chipset detected -
     rt: 2561, rf: 0003, rev: 000c
  ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
  ehci-pci: EHCI PCI platform driver
  ehci-pci 0000:00:09.2: EHCI Host Controller
  ehci-pci 0000:00:09.2: new USB bus registered, assigned bus number 1
  ehci-pci 0000:00:09.2: irq 125, io mem 0x58008000
  ehci-pci 0000:00:09.2: USB 2.0 started, EHCI 1.00
  hub 1-0:1.0: USB hub found
  hub 1-0:1.0: 4 ports detected
  uhci_hcd: USB Universal Host Controller Interface driver
  uhci_hcd 0000:00:09.0: UHCI Host Controller
  uhci_hcd 0000:00:09.0: new USB bus registered, assigned bus number 2
  uhci_hcd 0000:00:09.0: HCRESET not completed yet!
  uhci_hcd 0000:00:09.0: irq 123, io base 0x00001000
  hub 2-0:1.0: USB hub found
  hub 2-0:1.0: config failed, hub doesn't have any ports! (err -19)
  uhci_hcd 0000:00:09.1: UHCI Host Controller
  uhci_hcd 0000:00:09.1: new USB bus registered, assigned bus number 3
  uhci_hcd 0000:00:09.1: HCRESET not completed yet!
  uhci_hcd 0000:00:09.1: irq 124, io base 0x00001020
  hub 3-0:1.0: USB hub found
  hub 3-0:1.0: config failed, hub doesn't have any ports! (err -19)
  scsi 0:0:0:0: Direct-Access     USB      Flash Disk       1.00 PQ: 0 ANSI: 2
  sd 0:0:0:0: [sda] 7900336 512-byte logical blocks: (4.04 GB/3.77 GiB)
  sd 0:0:0:0: [sda] Write Protect is off
  sd 0:0:0:0: [sda] No Caching mode page found
  sd 0:0:0:0: [sda] Assuming drive cache: write through
   sda: sda1 sda2 sda3
  sd 0:0:0:0: [sda] Attached SCSI removable disk
  ieee80211 phy0: rt2x00lib_request_firmware: Info -
     Loading firmware file 'rt2561s.bin'
  ieee80211 phy0: rt2x00lib_request_firmware: Info -
     Firmware detected - version: 0.8
  IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready

  $ lspci
  00:00.0 Class 0600: 159b:4321
  00:09.2 Class 0c03: 1106:3104
  00:09.0 Class 0c03: 1106:3038
  00:09.1 Class 0c03: 1106:3038
  00:0c.0 Class 0280: 1814:0301

  $ cat /proc/interrupts
	     CPU0
  123:          0       PCI   0 Edge      uhci_hcd:usb2
  124:          0       PCI   1 Edge      uhci_hcd:usb3
  125:        159       PCI   2 Edge      ehci_hcd:usb1
  126:       1082       PCI   3 Edge      rt61pci

  $ cat /proc/iomem
  50000000-500000ff : /soc/pci@50000000
  58000000-5fffffff : Gemini PCI MEM
    58000000-58007fff : 0000:00:0c.0
      58000000-58007fff : 0000:00:0c.0
    58008000-580080ff : 0000:00:09.2
      58008000-580080ff : ehci_hcd

The EHCI USB hub works fine; I can mount and manage files and the IRQs just
keep ticking up.  I can issue iwlist wlan0 scanning and see all the WLANs
here.  I don't have wpa_supplicant so have not tried connecting to them.

[bhelgaas: fold in %pap change from Arnd Bergmann <arnd@arndb.de>]
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
CC: Janos Laube <janos.dev@gmail.com>
CC: Paulius Zaleckas <paulius.zaleckas@gmail.com>
CC: Hans Ulli Kroll <ulli.kroll@googlemail.com>
CC: Florian Fainelli <f.fainelli@gmail.com>
CC: Feng-Hsin Chiang <john453@faraday-tech.com>
CC: Greentime Hu <green.hu@gmail.com>
      d3c68e0a
  13. 22 2月, 2017 1 次提交
    • K
      PCI: Move DesignWare IP support to new drivers/pci/dwc/ directory · 950bf638
      由 Kishon Vijay Abraham I 提交于 
      Group all the PCI drivers that use DesignWare core in dwc directory.
dwc IP is capable of operating in both host mode and device mode and
keeping it inside the *host* directory is misleading.
Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NJingoo Han <jingoohan1@gmail.com>
Acked-By: NJoao Pinto <jpinto@synopsys.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Minghuan Lian <minghuan.Lian@freescale.com>
Cc: Mingkai Hu <mingkai.hu@freescale.com>
Cc: Roy Zang <tie-fei.zang@freescale.com>
Cc: Richard Zhu <hongxing.zhu@nxp.com>
Cc: Lucas Stach <l.stach@pengutronix.de>
Cc: Murali Karicheri <m-karicheri2@ti.com>
Cc: Pratyush Anand <pratyush.anand@gmail.com>
Cc: Niklas Cassel <niklas.cassel@axis.com>
Cc: Jesper Nilsson <jesper.nilsson@axis.com>
Cc: Zhou Wang <wangzhou1@hisilicon.com>
Cc: Gabriele Paoloni <gabriele.paoloni@huawei.com>
Cc: Stanimir Varbanov <svarbanov@mm-sol.com>
      950bf638
  15. 08 12月, 2016 1 次提交
  17. 07 12月, 2016 4 次提交
    • D
      PCI: Add MCFG quirks for X-Gene host controller · c5d46039
      由 Duc Dang 提交于 
      PCIe controllers in X-Gene SoCs are not ECAM compliant: software needs to
configure additional controller's register to address device at
bus:dev:function.

Add a quirk to discover controller MMIO register space and configure
controller registers to select and address the target secondary device.

The quirk will only be applied for X-Gene PCIe MCFG table with
OEM revison 1, 2, 3 or 4 (PCIe controller v1 and v2 on X-Gene SoCs).
Tested-by: NJon Masters <jcm@redhat.com>
Signed-off-by: NDuc Dang <dhdang@apm.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      c5d46039
    • T
      PCI: Add MCFG quirks for Cavium ThunderX pass1.x host controller · 648d93fc
      由 Tomasz Nowicki 提交于 
      ThunderX pass1.x requires to emulate the EA headers for on-chip devices
hence it has to use custom pci_thunder_ecam_ops for accessing PCI config
space (pci-thunder-ecam.c). Add new entries to MCFG quirk array where it
can be applied while probing ACPI based PCI host controller.

ThunderX pass1.x is using the same way for accessing off-chip devices
(so-called PEM) as silicon pass-2.x so we need to add PEM quirk entries
too.

Quirk is considered for ThunderX silicon pass1.x only which is identified
via MCFG revision 2.

ThunderX pass 1.x requires the following accessors:

  NUMA node 0 PCI segments  0- 3: pci_thunder_ecam_ops (MCFG quirk)
  NUMA node 0 PCI segments  4- 9: thunder_pem_ecam_ops (MCFG quirk)
  NUMA node 1 PCI segments 10-13: pci_thunder_ecam_ops (MCFG quirk)
  NUMA node 1 PCI segments 14-19: thunder_pem_ecam_ops (MCFG quirk)

[bhelgaas: change Makefile/ifdefs so quirk doesn't depend on
CONFIG_PCI_HOST_THUNDER_ECAM]
Signed-off-by: NTomasz Nowicki <tn@semihalf.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      648d93fc
    • T
      PCI: Add MCFG quirks for Cavium ThunderX pass2.x host controller · 44f22bd9
      由 Tomasz Nowicki 提交于 
      ThunderX PCIe controller to off-chip devices (so-called PEM) is not fully
compliant with ECAM standard. It uses non-standard configuration space
accessors (see thunder_pem_ecam_ops) and custom configuration space
granulation (see bus_shift = 24). In order to access configuration space
and probe PEM as ACPI-based PCI host controller we need to add MCFG quirk
infrastructure. This involves:
1. A new thunder_pem_acpi_init() init function to locate PEM-specific
   register ranges using ACPI.
2. Export PEM thunder_pem_ecam_ops structure so it is visible to MCFG quirk
   code.
3. New quirk entries for each PEM segment. Each contains platform IDs,
   mentioned thunder_pem_ecam_ops and CFG resources.

Quirk is considered for ThunderX silicon pass2.x only which is identified
via MCFG revision 1.

ThunderX pass 2.x requires the following accessors:

  NUMA Node 0 PCI segments  0- 3: pci_generic_ecam_ops (ECAM-compliant)
  NUMA Node 0 PCI segments  4- 9: thunder_pem_ecam_ops (MCFG quirk)
  NUMA Node 1 PCI segments 10-13: pci_generic_ecam_ops (ECAM-compliant)
  NUMA Node 1 PCI segments 14-19: thunder_pem_ecam_ops (MCFG quirk)

[bhelgaas: adapt to use acpi_get_rc_resources(), update Makefile/ifdefs so
quirk doesn't depend on CONFIG_PCI_HOST_THUNDER_PEM]
Signed-off-by: NTomasz Nowicki <tn@semihalf.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      44f22bd9
    • D
      PCI: Add MCFG quirks for HiSilicon Hip05/06/07 host controllers · 5f00f1a0
      由 Dongdong Liu 提交于 
      The PCIe controller in Hip05/Hip06/Hip07 SoCs is not completely
ECAM-compliant.  It is non-ECAM only for the RC bus config space; for any
other bus underneath the root bus it does support ECAM access.

Add specific quirks for PCI config space accessors.  This involves:
1. New initialization call hisi_pcie_init() to obtain RC base
addresses from PNP0C02 at the root of the ACPI namespace (under \_SB).
2. New entry in common quirk array.

[bhelgaas: move to pcie-hisi.c and change Makefile/ifdefs so quirk doesn't
depend on CONFIG_PCI_HISI]
Signed-off-by: NDongdong Liu <liudongdong3@huawei.com>
Signed-off-by: NGabriele Paoloni <gabriele.paoloni@huawei.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      5f00f1a0
  19. 05 10月, 2016 1 次提交
  21. 04 9月, 2016 1 次提交
  23. 27 7月, 2016 1 次提交
  25. 12 6月, 2016 1 次提交
  27. 27 4月, 2016 1 次提交
  29. 22 4月, 2016 1 次提交
  31. 15 3月, 2016 1 次提交
  33. 12 3月, 2016 4 次提交
  35. 17 2月, 2016 1 次提交
  37. 07 1月, 2016 1 次提交
    • R
      PCI: iproc: Add iProc PCIe MSI support · 3bc2b234
      由 Ray Jui 提交于 
      Add PCIe MSI support for both PAXB and PAXC interfaces on all iProc-based
platforms.

The iProc PCIe MSI support deploys an event queue-based implementation.
Each event queue is serviced by a GIC interrupt and can support up to 64
MSI vectors.  Host memory is allocated for the event queues, and each event
queue consists of 64 word-sized entries.  MSI data is written to the lower
16-bit of each entry, whereas the upper 16-bit of the entry is reserved for
the controller for internal processing.

Each event queue is tracked by a head pointer and tail pointer.  Head
pointer indicates the next entry in the event queue to be processed by
the driver and is updated by the driver after processing is done.
The controller uses the tail pointer as the next MSI data insertion
point.  The controller ensures MSI data is flushed to host memory before
updating the tail pointer and then triggering the interrupt.

MSI IRQ affinity is supported by evenly distributing the interrupts to each
CPU core.  MSI vector is moved from one GIC interrupt to another in order
to steer to the target CPU.

Therefore, the actual number of supported MSI vectors is:

  M * 64 / N

where M denotes the number of GIC interrupts (event queues), and N denotes
the number of CPU cores.

This iProc event queue-based MSI support should not be used with newer
platforms with integrated MSI support in the GIC (e.g., giv2m or
gicv3-its).

[bhelgaas: fold in Kconfig fixes from Arnd Bergmann <arnd@arndb.de>]
Signed-off-by: NRay Jui <rjui@broadcom.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NAnup Patel <anup.patel@broadcom.com>
Reviewed-by: NVikram Prakash <vikramp@broadcom.com>
Reviewed-by: NScott Branden <sbranden@broadcom.com>
Reviewed-by: NMarc Zyngier <marc.zyngier@arm.com>
      3bc2b234
  39. 06 1月, 2016 1 次提交
  41. 03 11月, 2015 2 次提交
  43. 24 10月, 2015 1 次提交
  45. 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
  47. 20 5月, 2015 1 次提交
    • H
      PCI: iproc: Add BCMA PCIe driver · 4785ffbd
      由 Hauke Mehrtens 提交于 
      This driver adds support for the PCIe 2.0 controller found on the BCMA bus.
This controller can be found on (mostly) all Broadcom BCM470X / BCM5301X
ARM SoCs.

The driver found in the Broadcom SDK does some more stuff, like setting up
some DMA memory areas, chaining MPS and MRRS to 512 and also some PHY
changes like "improving" the PCIe jitter and doing some special
initialization for the 3rd PCIe port.

This was tested on a bcm4708 board with 2 PCIe ports and wireless cards
connected to them.

PCI_DOMAINS is needed by this driver, because normally there is more than
one PCIe controller and without PCI_DOMAINS only the first controller gets
registered.  This controller gets 6 IRQs; the last one is trigged by all
IRQ events.

[bhelgaas: fix "GPLv2" MODULE_LICENSE typo]
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NRafał Miłecki <zajec5@gmail.com>
Acked-by: NRay Jui <rjui@broadcom.com.com>
      4785ffbd
  49. 09 4月, 2015 1 次提交
  51. 29 1月, 2015 1 次提交
  53. 14 11月, 2014 1 次提交
  55. 02 10月, 2014 1 次提交
  57. 05 9月, 2014 1 次提交
    • M
      PCI: keystone: Add TI Keystone PCIe driver · 0c4ffcfe
      由 Murali Karicheri 提交于 
      The Keystone PCIe controller is based on v3.65 version of the Designware
h/w.  Main differences are:

    1. No ATU support
    2. Legacy and MSI IRQ functions are implemented in application register
       space
    3. MSI interrupts are multiplexed over 8 IRQ lines to the Host side.

All of the application register space handing code is organized into
pci-keystone-dw.c and the functions are called from pci-keystone.c to
implement PCI controller driver.  Also add necessary DT documentation and
update the MAINTAINERS file for the driver.

[bhelgaas: spelling and whitespace fixes]
Signed-off-by: NMurali Karicheri <m-karicheri2@ti.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
CC: Russell King <linux@arm.linux.org.uk>
CC: Grant Likely <grant.likely@linaro.org>
CC: Rob Herring <robh+dt@kernel.org>
CC: Mohit Kumar <mohit.kumar@st.com>
CC: Pratyush Anand <pratyush.anand@st.com>
CC: Jingoo Han <jg1.han@samsung.com>
CC: Richard Zhu <r65037@freescale.com>
CC: Kishon Vijay Abraham I <kishon@ti.com>
CC: Marek Vasut <marex@denx.de>
CC: Arnd Bergmann <arnd@arndb.de>
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>
CC: Randy Dunlap <rdunlap@infradead.org>
CC: Grant Likely <grant.likely@linaro.org>
      0c4ffcfe
  59. 04 9月, 2014 1 次提交
  61. 23 7月, 2014 1 次提交