Florian Fainelli | 5 May 21:14 2016
Picon

[PATCH v2 0/2] pci: host: Broadcom STB PCIE RC controller support

Hi all,

This patch series adds support for Broadcom STB SoC's PCIe root complex driver.

This was primarily tested on BCM7445 (ARM) and BCM7435 (MIPS).

Jim is the original author, and I picked up our downstream 4.1 driver and
updated it to utilize the non-ARM hw_pci functions as well as made some
stylistic changes.

Thanks!

Jim Quinlan (2):
  Documentation: DT: bindings: Add Broadcom STB PCIe bindings
  pci: host: Add Broadcom STB PCIE RC controller

 .../devicetree/bindings/pci/brcm,brcmstb-pcie.txt  |  98 +++
 MAINTAINERS                                        |   1 +
 drivers/pci/host/Kconfig                           |  17 +
 drivers/pci/host/Makefile                          |   2 +
 drivers/pci/host/pcie-brcmstb-msi.c                | 305 ++++++++
 drivers/pci/host/pcie-brcmstb.c                    | 772 +++++++++++++++++++++
 drivers/pci/host/pcie-brcmstb.h                    | 169 +++++
 7 files changed, 1364 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pci/brcm,brcmstb-pcie.txt
 create mode 100644 drivers/pci/host/pcie-brcmstb-msi.c
 create mode 100644 drivers/pci/host/pcie-brcmstb.c
 create mode 100644 drivers/pci/host/pcie-brcmstb.h

--

-- 
(Continue reading)

Christoph Hellwig | 5 May 16:04 2016
Picon

PCI: Provide sensible irq vector alloc/free routines

Hi Bjorn,

find my revisted patch for the MSI-X allocator API.  There has been
some rework to use lower level APIs now that it has been moved to
msi.c.  The second patch converts nvme over to it.  If Keith and Jens
are fine with merging it through the PCI tree I'd be all for it,
if not we'll either need a common branch for it, or just defer it
until the next merge window.

Lukas Wunner | 4 May 15:05 2016
Picon

[PATCH] PCI/portdrv: Use cached copy of PCI_EXP_SLTCAP_HPC bit

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: Lukas Wunner <lukas <at> wunner.de>
---
 drivers/pci/pcie/portdrv_core.c | 23 +++++++++--------------
 1 file changed, 9 insertions(+), 14 deletions(-)

diff --git a/drivers/pci/pcie/portdrv_core.c b/drivers/pci/pcie/portdrv_core.c
index 050069f..af7796d 100644
--- a/drivers/pci/pcie/portdrv_core.c
+++ b/drivers/pci/pcie/portdrv_core.c
 <at>  <at>  -254,7 +254,6  <at>  <at>  static void cleanup_service_irqs(struct pci_dev *dev)
 static int get_port_device_capability(struct pci_dev *dev)
 {
 	int services = 0;
-	u32 reg32;
 	int cap_mask = 0;

 	if (pcie_ports_disabled)
 <at>  <at>  -269,19 +268,15  <at>  <at>  static int get_port_device_capability(struct pci_dev *dev)
 		pcie_port_platform_notify(dev, &cap_mask);

 	/* Hot-Plug Capable */
-	if ((cap_mask & PCIE_PORT_SERVICE_HP) &&
-	    pcie_caps_reg(dev) & PCI_EXP_FLAGS_SLOT) {
-		pcie_capability_read_dword(dev, PCI_EXP_SLTCAP, &reg32);
(Continue reading)

Niklas Cassel | 4 May 14:00 2016
Picon

[PATCH 2/2] pci: host: new driver for Axis ARTPEC-6 PCIe controller

From: Niklas Cassel <niklas.cassel <at> axis.com>

The Axis ARTPEC-6 SoC integrates a PCIe controller from Synopsys.
This commit adds a new driver that provides the small glue
needed to use the existing Designware driver to make it work on
the Axis ARTPEC-6 SoC.

Signed-off-by: Niklas Cassel <niklas.cassel <at> axis.com>
---
 MAINTAINERS                     |   9 ++
 drivers/pci/host/Kconfig        |   6 +
 drivers/pci/host/Makefile       |   1 +
 drivers/pci/host/pcie-artpec6.c | 297 ++++++++++++++++++++++++++++++++++++++++
 4 files changed, 313 insertions(+)
 create mode 100644 drivers/pci/host/pcie-artpec6.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 456978d..ac43fb3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
 <at>  <at>  -8755,6 +8755,15  <at>  <at>  S:	Maintained
 F:	Documentation/devicetree/bindings/pci/xgene-pci-msi.txt
 F:	drivers/pci/host/pci-xgene-msi.c

+PCIE DRIVER FOR AXIS ARTPEC
+M:	Niklas Cassel <niklas.cassel <at> axis.com>
+M:	Jesper Nilsson <jesper.nilsson <at> axis.com>
+L:	linux-arm-kernel <at> axis.com
+L:	linux-pci <at> vger.kernel.org
+S:	Maintained
(Continue reading)

Yinghai Lu | 4 May 00:52 2016

Re: [PATCH v11 04/60] sparc/PCI: Use correct offset for bus address to resource

On Fri, Apr 29, 2016 at 12:19 AM, Yinghai Lu <yinghai <at> kernel.org> wrote:
> On Thu, Apr 28, 2016 at 6:56 AM, Bjorn Helgaas <helgaas <at> kernel.org> wrote:
>>
>> 1) The sysfs path uses offsets between 0 and BAR size.  This path
>> should work identically on all arches.  "User" addresses are not
>> involved, so it doesn't make sense that this path calls
>> pci_resource_to_user() from pci_mmap_resource().
>>
>> 2) The procfs path uses offsets of resource values (CPU physical
>> addresses) on most architectures.  If some arches use something else,
>> e.g., "user" addresses, the grunge of dealing with them should be in
>> this path, i.e., in proc_bus_pci_mmap().  This implies that
>> pci_mmap_page_range() should deal with CPU physical addresses, not bus
>> addresses, and proc_bus_pci_mmap() should perform any necessary
>> translation.

Please check if following is what you want.

BenH and DavidM,
Are you ok to let /proc/bus/pci/devices to expose resource value instead of
BAR value?
powerpc already expose MMIO as resource value, but still keep IO as BAR value?

Or can we just dump /proc/bus/pci support from now?

Thanks

Yinghai

Subject: [RFC PATCH] PCI: Expose resource value in /proc/bus/pci/devices
(Continue reading)

Gavin Shan | 3 May 15:22 2016
Picon

[PATCH v9 00/22] powerpc/powernv: PCI hotplug support

The series is split from "[PATCH v8 00/45] powerpc/powernv: PCI hotplug
support". Another series (A) sent to linux-ppc-dev maillist as it's only
related to PowerPC. Besides, this series needs the firmware patches (B)
to work. Without the firmware patches, the PCI hotplug driver won't detect
and populate any PCI slots. So this series is working on old firmware.

 (A): https://patchwork.ozlabs.org/patch/617768/
 (B): https://patchwork.ozlabs.org/patch/617749/

The series of patches is highlighted as below:

   * In order to create PE during PCI hot plugging, pcibios_setup_bridge()
     which is called to update bridge's window populates the PE, together
     with the associated resources like IO/M32/M64 segments, DMA windows etc.
   * One refcount is maintained by each PE to track the number of PCI devices
     that are associated with the PE. The refcount is increased by one when
     a new PCI device joins the PE. It is decreased by one when a PCI device
     is released (pcibios_release_device()). The PE together with the used
     resources will be destroyed when refcount reaches to 0, meaning no PCI
     device needs the PE any more.
   * If the firmware has capability to support PCI slot and reset functionality,
     the reset required by EEH recovery is routed to firmware. Otherwise, it
     is done in kernel as before.
   * Changes to drivers/of/fdt.c in order to use OF changeset in hotplug driver.
   * PCI hotplug driver for PowerNV platform. The PCI slots are identified by
     firmware and exposed to kernel through device tree. Firmware provides APIs
     to get presence/power state or set power state from/to PCI slot. The PCI
     slot hotplug state is sychronized with its power state. When user changes
     PCI slot power state from off to on through sysfs file, the PCI devices
     behind the PCI slot will be brought into online. Otherwise, the PCI slot's
(Continue reading)

Yong, Jonathan | 3 May 11:02 2016
Picon

Re: [RFC v4] PCI: PTM Driver

On 04/29/2016 22:17, Bjorn Helgaas wrote:
> On Tue, Apr 19, 2016 at 06:29:17AM +0000, Yong, Jonathan wrote:
>> Hello LKML,
>>
>> This is a preliminary implementation of the PTM[1] support driver. This driver
>> has only been tested against a virtual PCI bus since there are no known
>> endpoints utilizing it yet.
>
> What sort of testing is this, exactly?  Is this using a software model
> of devices that support PTM?
>

We wrote another driver to fake the PCI config space with pci_scan_bus, 
with fake switches and fake devices. Convenient since the driver only 
deals with the config space.

> When will hardware that supports PTM be available to you for testing?
> When will it be available on the market?
>

I don't have any dates for when consumer endpoints will hit the market. 
PTM aware FPGA device models might come around Q3/Q4 this year, with 
exercisers around 2017.

> I'm trying to figure out whether there's any benefit to merging
> something before it is useful to anybody.
>

True it won't be useful to anybody until such a device is available. 
What is the general policy for future hardware standards?
(Continue reading)

Bjorn Helgaas | 2 May 22:43 2016

Re: [PATCH] PCI: hv: report resources release after stopping the bus

On Fri, Apr 29, 2016 at 11:39:10AM +0200, Vitaly Kuznetsov wrote:
> Kernel hang is observed when pci-hyperv module is release with device
> drivers still attached. E.g. when I do 'rmmod pci_hyperv' with BCM5720
> device pass-through-ed (tg3 module) I see the following:
> 
>  NMI watchdog: BUG: soft lockup - CPU#1 stuck for 22s! [rmmod:2104]
>  ...
>  Call Trace:
>   [<ffffffffa0641487>] tg3_read_mem+0x87/0x100 [tg3]
>   [<ffffffffa063f000>] ? 0xffffffffa063f000
>   [<ffffffffa0644375>] tg3_poll_fw+0x85/0x150 [tg3]
>   [<ffffffffa0649877>] tg3_chip_reset+0x357/0x8c0 [tg3]
>   [<ffffffffa064ca8b>] tg3_halt+0x3b/0x190 [tg3]
>   [<ffffffffa0657611>] tg3_stop+0x171/0x230 [tg3]
>   ...
>   [<ffffffffa064c550>] tg3_remove_one+0x90/0x140 [tg3]
>   [<ffffffff813bee59>] pci_device_remove+0x39/0xc0
>   [<ffffffff814a3201>] __device_release_driver+0xa1/0x160
>   [<ffffffff814a32e3>] device_release_driver+0x23/0x30
>   [<ffffffff813b794a>] pci_stop_bus_device+0x8a/0xa0
>   [<ffffffff813b7ab6>] pci_stop_root_bus+0x36/0x60
>   [<ffffffffa02c3f38>] hv_pci_remove+0x238/0x260 [pci_hyperv]
> 
> The problem seems to be that we report local resources release before
> stopping the bus and removing devices from it and device drivers may
> try to perform some operations with these resources on shutdown. Move
> resources release report after we do pci_stop_root_bus().
> 
> Signed-off-by: Vitaly Kuznetsov <vkuznets <at> redhat.com>

(Continue reading)

Bjorn Helgaas | 2 May 22:25 2016

Re: [PATCHv4] pcie: Add driver for Downstream Port Containment

On Thu, Apr 28, 2016 at 04:24:48PM -0600, Keith Busch wrote:
> This adds driver support for root and downstream ports that implement
> the PCI-Express Downstream Port Containment extended capability. DPC is
> an optional capability to contain uncorrectable errors below a port.
> 
> For more information on DPC, please see PCI Express Base Specification
> Revision 4, section 7.31, or view the PCI-SIG DPC ECN here:
> 
>   https://pcisig.com/sites/default/files/specification_documents/ECN_DPC_2012-02-09_finalized.pdf
> 
> When a DPC event is triggered, the h/w disables downstream links, so
> the DPC driver schedules removal for all devices below this port. This
> may happen concurrently with a PCI-e hotplug driver if enabled. When all
> downstream devices are removed and the link state transitions to disabled,
> the DPC driver clears the DPC status and interrupt bits so the link may
> retrain for a newly connected device.
> 
> The pcie device naming is updated to accomodate the additional service
> driver. From Lukas Wunner <lukas <at> wunner.de>:
> 
> The names of port service devices previously used one nibble to encode
> the port type and another nibble to encode the service type. Since this
> commit introduces a fifth service type, it changes device names to use
> one *byte* to encode the service type. E.g. a hotplug port service on a
> downstream bridge was previously called pcie24 and is now called pcie204.
> 
> Signed-off-by: Keith Busch <keith.busch <at> intel.com>
> Cc: Lukas Wunner <lukas <at> wunner.de>

Applied to pci/dpc for v4.7, thanks, Keith.
(Continue reading)

Niklas Cassel | 2 May 16:54 2016
Picon

[PATCH] PCI: dra7xx: program outbound atu with correct address

From: Niklas Cassel <niklas.cassel <at> axis.com>

commit 1488aefa37a4 ("PCI: designware: Move Root Complex
setup code to dw_pcie_setup_rc()") broke dra7xx
by moving code from dw_pcie_host_init to dw_pcie_setup_rc.

Fix this by doing the cpu to bus calculation before calling
dw_pcie_setup_rc.

Fixes: 1488aefa37a4 ("PCI: designware: Move Root Complex setup code to dw_pcie_setup_rc()")
Signed-off-by: Niklas Cassel <niklas.cassel <at> axis.com>
---
 drivers/pci/host/pci-dra7xx.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-dra7xx.c
index 2ca3a1f..f441130 100644
--- a/drivers/pci/host/pci-dra7xx.c
+++ b/drivers/pci/host/pci-dra7xx.c
 <at>  <at>  -142,13 +142,13  <at>  <at>  static void dra7xx_pcie_enable_interrupts(struct pcie_port *pp)

 static void dra7xx_pcie_host_init(struct pcie_port *pp)
 {
-	dw_pcie_setup_rc(pp);
-
 	pp->io_base &= DRA7XX_CPU_TO_BUS_ADDR;
 	pp->mem_base &= DRA7XX_CPU_TO_BUS_ADDR;
 	pp->cfg0_base &= DRA7XX_CPU_TO_BUS_ADDR;
 	pp->cfg1_base &= DRA7XX_CPU_TO_BUS_ADDR;

(Continue reading)

Arpit Patel | 1 May 20:49 2016
Picon

Hello linux

Greetings linux

http://tenikgrup.com/somewhere.php?control=1phs45ev5nzabe5

Arpit Patel

Gmane