Arnd Bergmann | 30 Jan 22:59 2015
Picon

[PATCH] ARM: integrator: remove unused variable

The patch to add the new generic config space accessors removed
a useless spinlock, but left the flags variable in place, which
now causes a build warning:

arch/arm/mach-integrator/pci_v3.c: In function 'pci_v3_preinit':
arch/arm/mach-integrator/pci_v3.c:614:16: warning: unused variable 'flags' [-Wunused-variable]

This removes it.

Signed-off-by: Arnd Bergmann <arnd <at> arndb.de>
Fixes: 1ba525109219 ("ARM: integrator: Convert PCI to use generic config accessors")

diff --git a/arch/arm/mach-integrator/pci_v3.c b/arch/arm/mach-integrator/pci_v3.c
index dc7782f26cbb..2565f0e7b5cf 100644
--- a/arch/arm/mach-integrator/pci_v3.c
+++ b/arch/arm/mach-integrator/pci_v3.c
 <at>  <at>  -611,7 +611,6  <at>  <at>  static int __init pci_v3_setup(int nr, struct pci_sys_data *sys)
  */
 static void __init pci_v3_preinit(void)
 {
-	unsigned long flags;
 	unsigned int temp;
 	phys_addr_t io_address = pci_pio_to_address(io_mem.start);

Bjorn Helgaas | 30 Jan 14:50 2015
Picon

Re: [Bug 92321] New: Mapping CompactPCI device through sysfs-pci driver

[+cc linux-pci for visibility]

Hi Georgiy,

Thanks a lot for your problem report.  A few questions below ...

On Fri, Jan 30, 2015 at 2:52 AM,  <bugzilla-daemon <at> bugzilla.kernel.org> wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=92321
>
>             Bug ID: 92321
>            Summary: Mapping CompactPCI device through sysfs-pci driver
>            Product: Drivers
>            Version: 2.5
>     Kernel Version: 3.16.0-4-586
>           Hardware: All
>                 OS: Linux
>               Tree: Mainline
>             Status: NEW
>           Severity: high
>           Priority: P1
>          Component: PCI
>           Assignee: drivers_pci <at> kernel-bugs.osdl.org
>           Reporter: jediknight.93 <at> mail.ru
>         Regression: No
>
> So, the problem can be described as follows:
>
> 1. We got 11 completely equal PCI devices, connected through two CompactPCI
> buses, 6 on one, and 5 on the other.
>
(Continue reading)

Mark Hounschell | 30 Jan 14:04 2015
Picon

dma_alloc_coherent - cma - and IOMMU question

Sorry for the noise. I've read everything DMA in the kernel Doc dir and 
searched the web to no avail. So I thought I might get some useful info 
here.

I'm currently using a 3.18.3 (x86_64) kernel on an AMD platform. I am 
currently doing 8MB DMAs to and from our device using the in kernel CMA 
"cma=64M <at> 0-4G" with no problems. This device is not DAC or 
scatter/gather capable so the in kernel CMA has been great and replaced 
our old bigphysarea usage.

We simply use dma_alloc_coherent and pass the dma_addr_t *dma_handle 
returned from the dma_alloc_coherent function to our device as the 
"bus/pci" address to use.
We also use remap_pfn_range on that dma_addr_t *dma_handle returned from 
  the dma_alloc_coherent function to mmap userland to the buffer. All is 
good until I enable the IOMMU. I then either get IO_PAGE_FAULTs, the DMA 
just quietly never completes or the system gets borked.

[  106.115725] AMD-Vi: Event logged [IO_PAGE_FAULT device=03:00.0 
domain=0x001b address=0x00000000aa500000 flags=0x0010]
[  106.115729] AMD-Vi: Event logged [IO_PAGE_FAULT device=03:00.0 
domain=0x001b address=0x00000000aa500040 flags=0x0010]

Here are the IOMMU settings in my kernel config:

#grep IOMMU .config
# CONFIG_GART_IOMMU is not set
# CONFIG_CALGARY_IOMMU is not set
CONFIG_IOMMU_HELPER=y
CONFIG_VFIO_IOMMU_TYPE1=m
(Continue reading)

Chunhe Lan | 30 Jan 10:48 2015

[PATCH] powerpc/pci: Fix the initial value of hose->first_busno

When use "Intel PRO/1000 PT Quad Port Low Profile Server Adapter"
card on P5040DS and T1040RDB, 32-bit kernel does not identify this
card. This card has the four RJ-45 ports.

The bus range of every pci is "bus-range = <0 0xff>" in dts file.
So the first bus number of every pci should start from 0, and it
does not start from next_busno. The next_busno is used to count
the bus sum of all pci devices. So the value of next_busno is
accumulated.

This patch fixes this issue, and "Intel PRO/1000 PT Quad Port Low
Profile Server Adapter" card can work rightly.

Signed-off-by: Chunhe Lan <Chunhe.Lan <at> freescale.com>
---
 arch/powerpc/kernel/pci_32.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/kernel/pci_32.c b/arch/powerpc/kernel/pci_32.c
index 432459c..a194685 100644
--- a/arch/powerpc/kernel/pci_32.c
+++ b/arch/powerpc/kernel/pci_32.c
 <at>  <at>  -236,13 +236,13  <at>  <at>  static int __init pcibios_init(void)

 	/* Scan all of the recorded PCI controllers.  */
 	list_for_each_entry_safe(hose, tmp, &hose_list, list_node) {
-		if (pci_assign_all_buses)
-			hose->first_busno = next_busno;
+		hose->first_busno = 0;
 		hose->last_busno = 0xff;
(Continue reading)

Israel Brewster | 29 Jan 20:46 2015
Picon

CentOS/Kernel 3.18.4/Thunderbolt2

My company recently purchased and installed a new SuperMicro server with a Thunderbolt 2 (Falcon Ridge)
card installed, specifically an AOC-TBT-DSL5320. I then installed CentOS 6, and, since to my
understanding thunderbolt support is only in more recent kernels, I went ahead and upgraded the kernel to
version 3.18.4 from ElRepo. However, I have not seen any indication yet that Thunderbolt is working -
although I may just not be looking in the right place. Over on Google+ Greg Kroah-Hartman indicated that I
need the PCI hot plug controller driver enabled, and Matthew Garrett indicated that I specifically need
the ACPI PCI hotplug driver rather than the native PCIe hotplug driver. To check, I ran the following command:

egrep -i HOTPLUG /boot/config-3.18.4-1.el6.elrepo.x86_64

Which returned the following potentially relevant results:

CONFIG_ACPI_HOTPLUG_CPU=y
CONFIG_ACPI_HOTPLUG_MEMORY=y
CONFIG_HOTPLUG_PCI_PCIE=y
CONFIG_HOTPLUG_PCI=y

but also the following:

# CONFIG_HOTPLUG_PCI_ACPI is not set
# CONFIG_HOTPLUG_PCI_CPCI is not set 

So perhaps that's the entire problem - that CONFIG_HOTPLUG_PCI_ACPI is not set? If so, what's going to be
the easiest solution? I'm willing to try recompiling the kernel, if someone could point me to a good guide,
but I haven't done so before (at least, not on Linux. I've re-compiled the kernel on OpenBSD many times).

-----------------------------------------------
Israel Brewster
Systems Analyst II
Ravn Alaska
(Continue reading)

Yijing Wang | 29 Jan 04:54 2015

[PATCH v3] PCI: Add guard to avoid mapping a invalid msix base address

Sometimes, a pci bridge device BAR was not assigned
properly. After we call pci_bus_assign_resources(), the
resource of the BAR would be reseted. So if we try to
enable msix for this device, it will map a invalid
resource as the msix base address, and a warning call trace
will report.

pci_bus_assign_resources()
	__pci_bus_assign_resources()
		pbus_assign_resources_sorted()
			__assign_resources_sorted()
				assign_requested_resources_sorted()
					pci_assign_resource() -->fail
					reset_resource()	-->res->start/end/flags = 0

pcie_port_device_register()
	init_service_irqs()
		pcie_port_enable_msix()
			...
				msix_capability_init()
					msix_map_region()
						phys_addr = pci_resource_start(dev, bir) + table_offset;
If BAR(index=bir) was not assign properly, pci_resource_start(dev, bir)
here would return 0, so phys_addr is a invalid physical
address of msix.

[   43.094087] ------------[ cut here ]------------
[   43.097418] WARNING: CPU: 1 PID: 1800 at arch/arm64/mm/ioremap.c:58 __ioremap_caller+0xd4/0xe8()
...
[   43.121694] CPU: 1 PID: 1800 Comm: insmod Tainted: G           O  3.16.0 #5
(Continue reading)

Rob Herring | 28 Jan 17:16 2015

[PATCH v2 0/3] Versatile PCI host DT support

I'm not going to get the rest of the Versatile series wrapped up for
3.20, but I think the PCI support is ready and would like to get it in.

I have not fixed the resource registration for /proc/iomem and irq
fixup as those issues are being worked on for a common fix.

Bjorn, Can you please take the whole series unless you prefer arm-soc
to.

v2:
- Added MAINTAINERS entry
- Based on generic PCI config accessors
- Module license fix
- Comment whitespace fix

Rob

Rob Herring (3):
  dt/bindings: add versatile PCI binding
  dts: versatile: add PCI controller binding
  PCI: add DT based ARM Versatile PCI host driver

 .../devicetree/bindings/pci/versatile.txt          |  59 +++++
 MAINTAINERS                                        |   8 +
 arch/arm/boot/dts/versatile-pb.dts                 |  37 ++++
 drivers/pci/host/Kconfig                           |   4 +
 drivers/pci/host/Makefile                          |   1 +
 drivers/pci/host/pci-versatile.c                   | 237 +++++++++++++++++++++
 6 files changed, 346 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pci/versatile.txt
(Continue reading)

Yijing Wang | 28 Jan 02:52 2015

[PATCH v2] PCI: Add guard to avoid mapping a invalid msix base address

Sometimes, a pci bridge device BAR was not assigned
properly. After we call pci_bus_assign_resources(), the
resource of the BAR would be reseted. So if we try to
enable msix for this device, it will map a invalid
resource as the msix base address, and a warning call trace
will report.

pci_bus_assign_resources()
	__pci_bus_assign_resources()
		pbus_assign_resources_sorted()
			__assign_resources_sorted()
				assign_requested_resources_sorted()
					pci_assign_resource() -->fail
					reset_resource()	-->res->start/end/flags = 0

pcie_port_device_register()
	init_service_irqs()
		pcie_port_enable_msix()
			...
				msix_capability_init()
					msix_map_region()
						phys_addr = pci_resource_start(dev, bir) + table_offset;
If BAR(index=bir) was not assign properly, pci_resource_start(dev, bir)
here would return 0, so phys_addr is a invalid physical
address of msix.

[   43.094087] ------------[ cut here ]------------
[   43.097418] WARNING: CPU: 1 PID: 1800 at arch/arm64/mm/ioremap.c:58 __ioremap_caller+0xd4/0xe8()
...
[   43.121694] CPU: 1 PID: 1800 Comm: insmod Tainted: G           O  3.16.0 #5
(Continue reading)

Paul Johnson | 28 Jan 00:12 2015

[problem] mpt2sas load fails with LSISAS2008

Hi -
In 3.19 rc6, the LSISAS2008 card is found but mpt2sas fails to load 
correctly. If pci=realloc=off is added to the startup command line, 
mpt2sas is correctly loaded.
- Paul Johnson

section of dmesg when it fails--
[    1.131580] mpt2sas0: diag reset: FAILED
[    1.132577] mpt2sas0: _base_get_ioc_facts: failed getting to correct 
state
[    1.134167] mpt2sas0: failure at 
/home/kernel/COD/linux/drivers/scsi/mpt2sas/mpt2sas_scsih.c:8192/_scsih_probe()!

section of dmesg with pci=realloc=off in command line--
[    0.976615] mpt2sas version 18.100.00.00 loaded
[    0.976875] mpt2sas0: 64 BIT PCI BUS DMA ADDRESSING SUPPORTED, total 
mem (16424512 kB)
[    0.987346] ahci 0000:00:1f.2: AHCI 0001.0300 32 slots 6 ports 3 Gbps 
0x3f impl SATA mode
[    0.987351] ahci 0000:00:1f.2: flags: 64bit ncq sntf stag pm led clo 
pmp pio slum part ems apst
[    1.028403] scsi host3: ahci
[    1.028777] scsi host4: ahci
[    1.029191] scsi host5: ahci
[    1.029706] scsi host6: ahci
[    1.030195] scsi host7: ahci
[    1.030719] scsi host8: ahci
[    1.030842] ata3: SATA max UDMA/133 abar m2048 <at> 0xfbffd000 port 
0xfbffd100 irq 29
[    1.030848] ata4: SATA max UDMA/133 abar m2048 <at> 0xfbffd000 port 
(Continue reading)

Lorenzo Pieralisi | 27 Jan 19:01 2015

[PATCH] drivers: of: fix resources freeing in of_pci_get_host_bridge_resources()

In the function of_pci_get_host_bridge_resources() if the parsing of
ranges fails, previously allocated resources inclusive of bus_range
are not freed and are not expected to be freed by the function caller
on error return.

This patch fixes the issues by adding code that properly frees resources
and bus_range before exiting the function with an error return value.

Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi <at> arm.com>
Acked-by: Liviu Dudau <liviu.dudau <at> arm.com>
Cc: Arnd Bergmann <arnd <at> arndb.de>
Cc: Bjorn Helgaas <bhelgaas <at> google.com>
Cc: Rob Herring <robh+dt <at> kernel.org>
---
 drivers/of/of_pci.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 88471d3..60dc36c 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
 <at>  <at>  -140,6 +140,7  <at>  <at>  int of_pci_get_host_bridge_resources(struct device_node *dev,
 			unsigned char busno, unsigned char bus_max,
 			struct list_head *resources, resource_size_t *io_base)
 {
+	struct pci_host_bridge_window *window;
 	struct resource *res;
 	struct resource *bus_range;
 	struct of_pci_range range;
 <at>  <at>  -225,7 +226,10  <at>  <at>  int of_pci_get_host_bridge_resources(struct device_node *dev,
(Continue reading)

Greg Kroah-Hartman | 27 Jan 18:11 2015

Re: Hot add a PCIe device driver upon hotplug event

On Tue, Jan 27, 2015 at 05:06:33PM +0000, Paulo Fortuna Carvalho wrote:
> >Is it possible to cancel somehow the remove procedure if the device is
> >in use?
> 
> >Nope, you could have physically removed the device, so we can't cancel
> >that :)
> 
> ok.
> 
> >When we are using the device and remove occurs the kernel crashes.
> >Then we need to fix the kernel, what driver is crashing, and where?
> 
> The driver of the ATCA acquisition card crashes in a read data function
> through DMA accesses.

Do you have an oops callback?  All read functions need to be able to
handle a 0xff read when the device is removed and react properly.

thanks,

greg k-h

Gmane