All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v2 1/2] PCI: generic: remove dependency on hw_pci
@ 2015-05-05  2:02 ` Jayachandran C
  0 siblings, 0 replies; 42+ messages in thread
From: Jayachandran C @ 2015-05-05  2:02 UTC (permalink / raw)
  To: Will Deacon, Bjorn Helgaas, linux-pci, linux-arm-kernel,
	Arnd Bergmann, Lorenzo Pieralisi, Liviu Dudau
  Cc: Jayachandran C, Suravee Suthikulpanit, Ming Lei

The current code in pci-host-generic.c uses pci_common_init_dev()
from the arch/arm/ to do a part of the PCI initialization, and this
prevents it from being used on arm64.

The initialization done by pci_common_init_dev() that is really
needed by pci-host-generic.c can be done in the same file without
using the hw_pci API of ARM.

The ARM platform requires a pci_sys_data as sysdata for the PCI bus,
this is be handled by setting up 'struct gen_pci' to embed a
pci_sys_data variable as the first element on the ARM platform.

Signed-off-by: Jayachandran C <jchandra@broadcom.com>
---
Here's v2 of the patches, this enables use of pci-host-generic on
arm64.

This has been tested on both qemu and fast model for arm64, and on
qemu for arm32.

v1->v2
 - Address comments from Arnd Bergmann and Lorenzo Pieralisi
    - move contents of gen_pci_init to gen_pci_probe
    - assign resources only when !probe_only
 - tested on ARM32 with qemu option -M virt

Notes:
 - passing a zeroed out pci_sys_data for ARM looks ok, but I haven't
   tested it on ARM.
 - tested it on ARM64 fast model
 - Any information on how this can be tested on arm is welcome.
 - There is only one ifdef, and that can be removed when arm64 gets
   a sysdata, or when arm loses its sysdata.

 drivers/pci/host/pci-host-generic.c | 50 +++++++++++++++++++++++--------------
 1 file changed, 31 insertions(+), 19 deletions(-)

diff --git a/drivers/pci/host/pci-host-generic.c b/drivers/pci/host/pci-host-generic.c
index ba46e58..e9cc559 100644
--- a/drivers/pci/host/pci-host-generic.c
+++ b/drivers/pci/host/pci-host-generic.c
@@ -39,6 +39,9 @@ struct gen_pci_cfg_windows {
 };
 
 struct gen_pci {
+#ifdef CONFIG_ARM
+	struct pci_sys_data			sys;
+#endif
 	struct pci_host_bridge			host;
 	struct gen_pci_cfg_windows		cfg;
 	struct list_head			resources;
@@ -48,8 +51,7 @@ static void __iomem *gen_pci_map_cfg_bus_cam(struct pci_bus *bus,
 					     unsigned int devfn,
 					     int where)
 {
-	struct pci_sys_data *sys = bus->sysdata;
-	struct gen_pci *pci = sys->private_data;
+	struct gen_pci *pci = bus->sysdata;
 	resource_size_t idx = bus->number - pci->cfg.bus_range->start;
 
 	return pci->cfg.win[idx] + ((devfn << 8) | where);
@@ -64,8 +66,7 @@ static void __iomem *gen_pci_map_cfg_bus_ecam(struct pci_bus *bus,
 					      unsigned int devfn,
 					      int where)
 {
-	struct pci_sys_data *sys = bus->sysdata;
-	struct gen_pci *pci = sys->private_data;
+	struct gen_pci *pci = bus->sysdata;
 	resource_size_t idx = bus->number - pci->cfg.bus_range->start;
 
 	return pci->cfg.win[idx] + ((devfn << 12) | where);
@@ -198,13 +199,6 @@ static int gen_pci_parse_map_cfg_windows(struct gen_pci *pci)
 	return 0;
 }
 
-static int gen_pci_setup(int nr, struct pci_sys_data *sys)
-{
-	struct gen_pci *pci = sys->private_data;
-	list_splice_init(&pci->resources, &sys->resources);
-	return 1;
-}
-
 static int gen_pci_probe(struct platform_device *pdev)
 {
 	int err;
@@ -214,13 +208,7 @@ static int gen_pci_probe(struct platform_device *pdev)
 	struct device *dev = &pdev->dev;
 	struct device_node *np = dev->of_node;
 	struct gen_pci *pci = devm_kzalloc(dev, sizeof(*pci), GFP_KERNEL);
-	struct hw_pci hw = {
-		.nr_controllers	= 1,
-		.private_data	= (void **)&pci,
-		.setup		= gen_pci_setup,
-		.map_irq	= of_irq_parse_and_map_pci,
-		.ops		= &gen_pci_ops,
-	};
+	struct pci_bus *bus;
 
 	if (!pci)
 		return -ENOMEM;
@@ -258,7 +246,31 @@ static int gen_pci_probe(struct platform_device *pdev)
 		return err;
 	}
 
-	pci_common_init_dev(dev, &hw);
+	/* do not reassign resource if probe only */
+	if (!pci_has_flag(PCI_PROBE_ONLY))
+		pci_add_flags(PCI_REASSIGN_ALL_RSRC);
+
+	bus = pci_scan_root_bus(dev, 0, &gen_pci_ops, pci, &pci->resources);
+	if (!bus) {
+		dev_err(dev, "Scanning rootbus failed");
+		return -ENODEV;
+	}
+
+	pci_fixup_irqs(pci_common_swizzle, of_irq_parse_and_map_pci);
+
+	if (!pci_has_flag(PCI_PROBE_ONLY)) {
+		pci_bus_size_bridges(bus);
+		pci_bus_assign_resources(bus);
+	}
+	pci_bus_add_devices(bus);
+
+	/* Configure PCI Express settings */
+	if (pci_has_flag(PCI_PROBE_ONLY)) {
+		struct pci_bus *child;
+
+		list_for_each_entry(child, &bus->children, node)
+			pcie_bus_configure_settings(child);
+	}
 	return 0;
 }
 
-- 
1.9.1


^ permalink raw reply related	[flat|nested] 42+ messages in thread

* [PATCH v2 1/2] PCI: generic: remove dependency on hw_pci
@ 2015-05-05  2:02 ` Jayachandran C
  0 siblings, 0 replies; 42+ messages in thread
From: Jayachandran C @ 2015-05-05  2:02 UTC (permalink / raw)
  To: linux-arm-kernel

The current code in pci-host-generic.c uses pci_common_init_dev()
from the arch/arm/ to do a part of the PCI initialization, and this
prevents it from being used on arm64.

The initialization done by pci_common_init_dev() that is really
needed by pci-host-generic.c can be done in the same file without
using the hw_pci API of ARM.

The ARM platform requires a pci_sys_data as sysdata for the PCI bus,
this is be handled by setting up 'struct gen_pci' to embed a
pci_sys_data variable as the first element on the ARM platform.

Signed-off-by: Jayachandran C <jchandra@broadcom.com>
---
Here's v2 of the patches, this enables use of pci-host-generic on
arm64.

This has been tested on both qemu and fast model for arm64, and on
qemu for arm32.

v1->v2
 - Address comments from Arnd Bergmann and Lorenzo Pieralisi
    - move contents of gen_pci_init to gen_pci_probe
    - assign resources only when !probe_only
 - tested on ARM32 with qemu option -M virt

Notes:
 - passing a zeroed out pci_sys_data for ARM looks ok, but I haven't
   tested it on ARM.
 - tested it on ARM64 fast model
 - Any information on how this can be tested on arm is welcome.
 - There is only one ifdef, and that can be removed when arm64 gets
   a sysdata, or when arm loses its sysdata.

 drivers/pci/host/pci-host-generic.c | 50 +++++++++++++++++++++++--------------
 1 file changed, 31 insertions(+), 19 deletions(-)

diff --git a/drivers/pci/host/pci-host-generic.c b/drivers/pci/host/pci-host-generic.c
index ba46e58..e9cc559 100644
--- a/drivers/pci/host/pci-host-generic.c
+++ b/drivers/pci/host/pci-host-generic.c
@@ -39,6 +39,9 @@ struct gen_pci_cfg_windows {
 };
 
 struct gen_pci {
+#ifdef CONFIG_ARM
+	struct pci_sys_data			sys;
+#endif
 	struct pci_host_bridge			host;
 	struct gen_pci_cfg_windows		cfg;
 	struct list_head			resources;
@@ -48,8 +51,7 @@ static void __iomem *gen_pci_map_cfg_bus_cam(struct pci_bus *bus,
 					     unsigned int devfn,
 					     int where)
 {
-	struct pci_sys_data *sys = bus->sysdata;
-	struct gen_pci *pci = sys->private_data;
+	struct gen_pci *pci = bus->sysdata;
 	resource_size_t idx = bus->number - pci->cfg.bus_range->start;
 
 	return pci->cfg.win[idx] + ((devfn << 8) | where);
@@ -64,8 +66,7 @@ static void __iomem *gen_pci_map_cfg_bus_ecam(struct pci_bus *bus,
 					      unsigned int devfn,
 					      int where)
 {
-	struct pci_sys_data *sys = bus->sysdata;
-	struct gen_pci *pci = sys->private_data;
+	struct gen_pci *pci = bus->sysdata;
 	resource_size_t idx = bus->number - pci->cfg.bus_range->start;
 
 	return pci->cfg.win[idx] + ((devfn << 12) | where);
@@ -198,13 +199,6 @@ static int gen_pci_parse_map_cfg_windows(struct gen_pci *pci)
 	return 0;
 }
 
-static int gen_pci_setup(int nr, struct pci_sys_data *sys)
-{
-	struct gen_pci *pci = sys->private_data;
-	list_splice_init(&pci->resources, &sys->resources);
-	return 1;
-}
-
 static int gen_pci_probe(struct platform_device *pdev)
 {
 	int err;
@@ -214,13 +208,7 @@ static int gen_pci_probe(struct platform_device *pdev)
 	struct device *dev = &pdev->dev;
 	struct device_node *np = dev->of_node;
 	struct gen_pci *pci = devm_kzalloc(dev, sizeof(*pci), GFP_KERNEL);
-	struct hw_pci hw = {
-		.nr_controllers	= 1,
-		.private_data	= (void **)&pci,
-		.setup		= gen_pci_setup,
-		.map_irq	= of_irq_parse_and_map_pci,
-		.ops		= &gen_pci_ops,
-	};
+	struct pci_bus *bus;
 
 	if (!pci)
 		return -ENOMEM;
@@ -258,7 +246,31 @@ static int gen_pci_probe(struct platform_device *pdev)
 		return err;
 	}
 
-	pci_common_init_dev(dev, &hw);
+	/* do not reassign resource if probe only */
+	if (!pci_has_flag(PCI_PROBE_ONLY))
+		pci_add_flags(PCI_REASSIGN_ALL_RSRC);
+
+	bus = pci_scan_root_bus(dev, 0, &gen_pci_ops, pci, &pci->resources);
+	if (!bus) {
+		dev_err(dev, "Scanning rootbus failed");
+		return -ENODEV;
+	}
+
+	pci_fixup_irqs(pci_common_swizzle, of_irq_parse_and_map_pci);
+
+	if (!pci_has_flag(PCI_PROBE_ONLY)) {
+		pci_bus_size_bridges(bus);
+		pci_bus_assign_resources(bus);
+	}
+	pci_bus_add_devices(bus);
+
+	/* Configure PCI Express settings */
+	if (pci_has_flag(PCI_PROBE_ONLY)) {
+		struct pci_bus *child;
+
+		list_for_each_entry(child, &bus->children, node)
+			pcie_bus_configure_settings(child);
+	}
 	return 0;
 }
 
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 42+ messages in thread

* [PATCH v2 2/2] PCI: generic: add arm64 support
  2015-05-05  2:02 ` Jayachandran C
@ 2015-05-05  2:02   ` Jayachandran C
  -1 siblings, 0 replies; 42+ messages in thread
From: Jayachandran C @ 2015-05-05  2:02 UTC (permalink / raw)
  To: Will Deacon, Bjorn Helgaas, linux-pci, linux-arm-kernel,
	Arnd Bergmann, Lorenzo Pieralisi, Liviu Dudau
  Cc: Jayachandran C, Suravee Suthikulpanit, Ming Lei

Make pci-host-generic driver available on arm64. This needs
drivers/pci/setup-irq.o to be built for the arm64 as well.

Signed-off-by: Jayachandran C <jchandra@broadcom.com>
---
 drivers/pci/Makefile     | 1 +
 drivers/pci/host/Kconfig | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
index 73e4af4..be3f631 100644
--- a/drivers/pci/Makefile
+++ b/drivers/pci/Makefile
@@ -33,6 +33,7 @@ obj-$(CONFIG_PCI_IOV) += iov.o
 #
 obj-$(CONFIG_ALPHA) += setup-irq.o
 obj-$(CONFIG_ARM) += setup-irq.o
+obj-$(CONFIG_ARM64) += setup-irq.o
 obj-$(CONFIG_UNICORE32) += setup-irq.o
 obj-$(CONFIG_SUPERH) += setup-irq.o
 obj-$(CONFIG_MIPS) += setup-irq.o
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index 1dfb567..51741ad 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -53,7 +53,7 @@ config PCI_RCAR_GEN2_PCIE
 
 config PCI_HOST_GENERIC
 	bool "Generic PCI host controller"
-	depends on ARM && OF
+	depends on (ARM || ARM64) && OF
 	help
 	  Say Y here if you want to support a simple generic PCI host
 	  controller, such as the one emulated by kvmtool.
-- 
1.9.1


^ permalink raw reply related	[flat|nested] 42+ messages in thread

* [PATCH v2 2/2] PCI: generic: add arm64 support
@ 2015-05-05  2:02   ` Jayachandran C
  0 siblings, 0 replies; 42+ messages in thread
From: Jayachandran C @ 2015-05-05  2:02 UTC (permalink / raw)
  To: linux-arm-kernel

Make pci-host-generic driver available on arm64. This needs
drivers/pci/setup-irq.o to be built for the arm64 as well.

Signed-off-by: Jayachandran C <jchandra@broadcom.com>
---
 drivers/pci/Makefile     | 1 +
 drivers/pci/host/Kconfig | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
index 73e4af4..be3f631 100644
--- a/drivers/pci/Makefile
+++ b/drivers/pci/Makefile
@@ -33,6 +33,7 @@ obj-$(CONFIG_PCI_IOV) += iov.o
 #
 obj-$(CONFIG_ALPHA) += setup-irq.o
 obj-$(CONFIG_ARM) += setup-irq.o
+obj-$(CONFIG_ARM64) += setup-irq.o
 obj-$(CONFIG_UNICORE32) += setup-irq.o
 obj-$(CONFIG_SUPERH) += setup-irq.o
 obj-$(CONFIG_MIPS) += setup-irq.o
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index 1dfb567..51741ad 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -53,7 +53,7 @@ config PCI_RCAR_GEN2_PCIE
 
 config PCI_HOST_GENERIC
 	bool "Generic PCI host controller"
-	depends on ARM && OF
+	depends on (ARM || ARM64) && OF
 	help
 	  Say Y here if you want to support a simple generic PCI host
 	  controller, such as the one emulated by kvmtool.
-- 
1.9.1

^ permalink raw reply related	[flat|nested] 42+ messages in thread

* Re: [PATCH v2 1/2] PCI: generic: remove dependency on hw_pci
  2015-05-05  2:02 ` Jayachandran C
@ 2015-05-05 15:53   ` Will Deacon
  -1 siblings, 0 replies; 42+ messages in thread
From: Will Deacon @ 2015-05-05 15:53 UTC (permalink / raw)
  To: Jayachandran C
  Cc: Bjorn Helgaas, linux-pci, linux-arm-kernel, Arnd Bergmann,
	Lorenzo Pieralisi, Liviu Dudau, suravee.suthikulpanit, Ming Lei

On Tue, May 05, 2015 at 03:02:12AM +0100, Jayachandran C wrote:
> The current code in pci-host-generic.c uses pci_common_init_dev()
> from the arch/arm/ to do a part of the PCI initialization, and this
> prevents it from being used on arm64.
> 
> The initialization done by pci_common_init_dev() that is really
> needed by pci-host-generic.c can be done in the same file without
> using the hw_pci API of ARM.
> 
> The ARM platform requires a pci_sys_data as sysdata for the PCI bus,
> this is be handled by setting up 'struct gen_pci' to embed a
> pci_sys_data variable as the first element on the ARM platform.
> 
> Signed-off-by: Jayachandran C <jchandra@broadcom.com>
> ---
> Here's v2 of the patches, this enables use of pci-host-generic on
> arm64.
> 
> This has been tested on both qemu and fast model for arm64, and on
> qemu for arm32.
> 
> v1->v2
>  - Address comments from Arnd Bergmann and Lorenzo Pieralisi
>     - move contents of gen_pci_init to gen_pci_probe
>     - assign resources only when !probe_only
>  - tested on ARM32 with qemu option -M virt

I tried this with an arm64 kernel running under kvmtool, but I get the
following errors (a 32-bit ARM kernel does seem to work):

  PCI host bridge /pci ranges:
     IO 0x00000000..0x0000ffff -> 0x00000000
    MEM 0x41000000..0x7fffffff -> 0x41000000
  pci-host-generic 40000000.pci: PCI host bridge to bus 0000:00
  pci_bus 0000:00: root bus resource [bus 00-01]
  pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
  pci_bus 0000:00: root bus resource [mem 0x41000000-0x7fffffff]
  pci_bus 0000:00: scanning bus
  pci 0000:00:00.0: [1af4:1009] type 00 class 0xff0000
  pci 0000:00:00.0: reg 0x10: [mem 0x41000000-0x410003ff]
  pci 0000:00:00.0: reg 0x14: [io  0x6200-0x65ff]
  pci 0000:00:00.0: reg 0x18: [mem 0x41000400-0x410005ff]
  pci 0000:00:01.0: [1af4:1009] type 00 class 0xff0000
  pci 0000:00:01.0: reg 0x10: [mem 0x41000800-0x41000bff]
  pci 0000:00:01.0: reg 0x14: [io  0x6600-0x69ff]
  pci 0000:00:01.0: reg 0x18: [mem 0x41000c00-0x41000dff]
  pci_bus 0000:00: fixups for bus
  pci_bus 0000:00: bus scan returning with max=00
  pci 0000:00:00.0: fixup irq: got 10
  pci 0000:00:00.0: assigning IRQ 10
  pci 0000:00:01.0: fixup irq: got 11
  pci 0000:00:01.0: assigning IRQ 11
  virtio-pci 0000:00:00.0: can't enable device: BAR 0 [mem 0x41000000-0x410003ff] not claimed
  virtio-pci: probe of 0000:00:00.0 failed with error -22
  virtio-pci 0000:00:01.0: can't enable device: BAR 0 [mem 0x41000800-0x41000bff] not claimed
  virtio-pci: probe of 0000:00:01.0 failed with error -22

Will

^ permalink raw reply	[flat|nested] 42+ messages in thread

* [PATCH v2 1/2] PCI: generic: remove dependency on hw_pci
@ 2015-05-05 15:53   ` Will Deacon
  0 siblings, 0 replies; 42+ messages in thread
From: Will Deacon @ 2015-05-05 15:53 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, May 05, 2015 at 03:02:12AM +0100, Jayachandran C wrote:
> The current code in pci-host-generic.c uses pci_common_init_dev()
> from the arch/arm/ to do a part of the PCI initialization, and this
> prevents it from being used on arm64.
> 
> The initialization done by pci_common_init_dev() that is really
> needed by pci-host-generic.c can be done in the same file without
> using the hw_pci API of ARM.
> 
> The ARM platform requires a pci_sys_data as sysdata for the PCI bus,
> this is be handled by setting up 'struct gen_pci' to embed a
> pci_sys_data variable as the first element on the ARM platform.
> 
> Signed-off-by: Jayachandran C <jchandra@broadcom.com>
> ---
> Here's v2 of the patches, this enables use of pci-host-generic on
> arm64.
> 
> This has been tested on both qemu and fast model for arm64, and on
> qemu for arm32.
> 
> v1->v2
>  - Address comments from Arnd Bergmann and Lorenzo Pieralisi
>     - move contents of gen_pci_init to gen_pci_probe
>     - assign resources only when !probe_only
>  - tested on ARM32 with qemu option -M virt

I tried this with an arm64 kernel running under kvmtool, but I get the
following errors (a 32-bit ARM kernel does seem to work):

  PCI host bridge /pci ranges:
     IO 0x00000000..0x0000ffff -> 0x00000000
    MEM 0x41000000..0x7fffffff -> 0x41000000
  pci-host-generic 40000000.pci: PCI host bridge to bus 0000:00
  pci_bus 0000:00: root bus resource [bus 00-01]
  pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
  pci_bus 0000:00: root bus resource [mem 0x41000000-0x7fffffff]
  pci_bus 0000:00: scanning bus
  pci 0000:00:00.0: [1af4:1009] type 00 class 0xff0000
  pci 0000:00:00.0: reg 0x10: [mem 0x41000000-0x410003ff]
  pci 0000:00:00.0: reg 0x14: [io  0x6200-0x65ff]
  pci 0000:00:00.0: reg 0x18: [mem 0x41000400-0x410005ff]
  pci 0000:00:01.0: [1af4:1009] type 00 class 0xff0000
  pci 0000:00:01.0: reg 0x10: [mem 0x41000800-0x41000bff]
  pci 0000:00:01.0: reg 0x14: [io  0x6600-0x69ff]
  pci 0000:00:01.0: reg 0x18: [mem 0x41000c00-0x41000dff]
  pci_bus 0000:00: fixups for bus
  pci_bus 0000:00: bus scan returning with max=00
  pci 0000:00:00.0: fixup irq: got 10
  pci 0000:00:00.0: assigning IRQ 10
  pci 0000:00:01.0: fixup irq: got 11
  pci 0000:00:01.0: assigning IRQ 11
  virtio-pci 0000:00:00.0: can't enable device: BAR 0 [mem 0x41000000-0x410003ff] not claimed
  virtio-pci: probe of 0000:00:00.0 failed with error -22
  virtio-pci 0000:00:01.0: can't enable device: BAR 0 [mem 0x41000800-0x41000bff] not claimed
  virtio-pci: probe of 0000:00:01.0 failed with error -22

Will

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [PATCH v2 1/2] PCI: generic: remove dependency on hw_pci
  2015-05-05 15:53   ` Will Deacon
@ 2015-05-05 15:58     ` Arnd Bergmann
  -1 siblings, 0 replies; 42+ messages in thread
From: Arnd Bergmann @ 2015-05-05 15:58 UTC (permalink / raw)
  To: Will Deacon
  Cc: Jayachandran C, Bjorn Helgaas, linux-pci, linux-arm-kernel,
	Lorenzo Pieralisi, Liviu Dudau, suravee.suthikulpanit, Ming Lei

On Tuesday 05 May 2015 16:53:46 Will Deacon wrote:
> On Tue, May 05, 2015 at 03:02:12AM +0100, Jayachandran C wrote:
> > The current code in pci-host-generic.c uses pci_common_init_dev()
> > from the arch/arm/ to do a part of the PCI initialization, and this
> > prevents it from being used on arm64.
> > 
> > The initialization done by pci_common_init_dev() that is really
> > needed by pci-host-generic.c can be done in the same file without
> > using the hw_pci API of ARM.
> > 
> > The ARM platform requires a pci_sys_data as sysdata for the PCI bus,
> > this is be handled by setting up 'struct gen_pci' to embed a
> > pci_sys_data variable as the first element on the ARM platform.
> > 
> > Signed-off-by: Jayachandran C <jchandra@broadcom.com>
> > ---
> > Here's v2 of the patches, this enables use of pci-host-generic on
> > arm64.
> > 
> > This has been tested on both qemu and fast model for arm64, and on
> > qemu for arm32.
> > 
> > v1->v2
> >  - Address comments from Arnd Bergmann and Lorenzo Pieralisi
> >     - move contents of gen_pci_init to gen_pci_probe
> >     - assign resources only when !probe_only
> >  - tested on ARM32 with qemu option -M virt
> 
> I tried this with an arm64 kernel running under kvmtool, but I get the
> following errors (a 32-bit ARM kernel does seem to work):
> 
>   PCI host bridge /pci ranges:
>      IO 0x00000000..0x0000ffff -> 0x00000000
>     MEM 0x41000000..0x7fffffff -> 0x41000000
>   pci-host-generic 40000000.pci: PCI host bridge to bus 0000:00
>   pci_bus 0000:00: root bus resource [bus 00-01]
>   pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
>   pci_bus 0000:00: root bus resource [mem 0x41000000-0x7fffffff]
>   pci_bus 0000:00: scanning bus
>   pci 0000:00:00.0: [1af4:1009] type 00 class 0xff0000
>   pci 0000:00:00.0: reg 0x10: [mem 0x41000000-0x410003ff]
>   pci 0000:00:00.0: reg 0x14: [io  0x6200-0x65ff]
>   pci 0000:00:00.0: reg 0x18: [mem 0x41000400-0x410005ff]
>   pci 0000:00:01.0: [1af4:1009] type 00 class 0xff0000
>   pci 0000:00:01.0: reg 0x10: [mem 0x41000800-0x41000bff]
>   pci 0000:00:01.0: reg 0x14: [io  0x6600-0x69ff]
>   pci 0000:00:01.0: reg 0x18: [mem 0x41000c00-0x41000dff]
>   pci_bus 0000:00: fixups for bus
>   pci_bus 0000:00: bus scan returning with max=00
>   pci 0000:00:00.0: fixup irq: got 10
>   pci 0000:00:00.0: assigning IRQ 10
>   pci 0000:00:01.0: fixup irq: got 11
>   pci 0000:00:01.0: assigning IRQ 11
>   virtio-pci 0000:00:00.0: can't enable device: BAR 0 [mem 0x41000000-0x410003ff] not claimed
>   virtio-pci: probe of 0000:00:00.0 failed with error -22
>   virtio-pci 0000:00:01.0: can't enable device: BAR 0 [mem 0x41000800-0x41000bff] not claimed
>   virtio-pci: probe of 0000:00:01.0 failed with error -22

What do you see in /proc/ioport and /proc/iomem, respectively?

It sounds like the memory resource of the host did not get registered right.

	Arnd

^ permalink raw reply	[flat|nested] 42+ messages in thread

* [PATCH v2 1/2] PCI: generic: remove dependency on hw_pci
@ 2015-05-05 15:58     ` Arnd Bergmann
  0 siblings, 0 replies; 42+ messages in thread
From: Arnd Bergmann @ 2015-05-05 15:58 UTC (permalink / raw)
  To: linux-arm-kernel

On Tuesday 05 May 2015 16:53:46 Will Deacon wrote:
> On Tue, May 05, 2015 at 03:02:12AM +0100, Jayachandran C wrote:
> > The current code in pci-host-generic.c uses pci_common_init_dev()
> > from the arch/arm/ to do a part of the PCI initialization, and this
> > prevents it from being used on arm64.
> > 
> > The initialization done by pci_common_init_dev() that is really
> > needed by pci-host-generic.c can be done in the same file without
> > using the hw_pci API of ARM.
> > 
> > The ARM platform requires a pci_sys_data as sysdata for the PCI bus,
> > this is be handled by setting up 'struct gen_pci' to embed a
> > pci_sys_data variable as the first element on the ARM platform.
> > 
> > Signed-off-by: Jayachandran C <jchandra@broadcom.com>
> > ---
> > Here's v2 of the patches, this enables use of pci-host-generic on
> > arm64.
> > 
> > This has been tested on both qemu and fast model for arm64, and on
> > qemu for arm32.
> > 
> > v1->v2
> >  - Address comments from Arnd Bergmann and Lorenzo Pieralisi
> >     - move contents of gen_pci_init to gen_pci_probe
> >     - assign resources only when !probe_only
> >  - tested on ARM32 with qemu option -M virt
> 
> I tried this with an arm64 kernel running under kvmtool, but I get the
> following errors (a 32-bit ARM kernel does seem to work):
> 
>   PCI host bridge /pci ranges:
>      IO 0x00000000..0x0000ffff -> 0x00000000
>     MEM 0x41000000..0x7fffffff -> 0x41000000
>   pci-host-generic 40000000.pci: PCI host bridge to bus 0000:00
>   pci_bus 0000:00: root bus resource [bus 00-01]
>   pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
>   pci_bus 0000:00: root bus resource [mem 0x41000000-0x7fffffff]
>   pci_bus 0000:00: scanning bus
>   pci 0000:00:00.0: [1af4:1009] type 00 class 0xff0000
>   pci 0000:00:00.0: reg 0x10: [mem 0x41000000-0x410003ff]
>   pci 0000:00:00.0: reg 0x14: [io  0x6200-0x65ff]
>   pci 0000:00:00.0: reg 0x18: [mem 0x41000400-0x410005ff]
>   pci 0000:00:01.0: [1af4:1009] type 00 class 0xff0000
>   pci 0000:00:01.0: reg 0x10: [mem 0x41000800-0x41000bff]
>   pci 0000:00:01.0: reg 0x14: [io  0x6600-0x69ff]
>   pci 0000:00:01.0: reg 0x18: [mem 0x41000c00-0x41000dff]
>   pci_bus 0000:00: fixups for bus
>   pci_bus 0000:00: bus scan returning with max=00
>   pci 0000:00:00.0: fixup irq: got 10
>   pci 0000:00:00.0: assigning IRQ 10
>   pci 0000:00:01.0: fixup irq: got 11
>   pci 0000:00:01.0: assigning IRQ 11
>   virtio-pci 0000:00:00.0: can't enable device: BAR 0 [mem 0x41000000-0x410003ff] not claimed
>   virtio-pci: probe of 0000:00:00.0 failed with error -22
>   virtio-pci 0000:00:01.0: can't enable device: BAR 0 [mem 0x41000800-0x41000bff] not claimed
>   virtio-pci: probe of 0000:00:01.0 failed with error -22

What do you see in /proc/ioport and /proc/iomem, respectively?

It sounds like the memory resource of the host did not get registered right.

	Arnd

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [PATCH v2 1/2] PCI: generic: remove dependency on hw_pci
  2015-05-05 15:53   ` Will Deacon
@ 2015-05-05 16:03     ` Lorenzo Pieralisi
  -1 siblings, 0 replies; 42+ messages in thread
From: Lorenzo Pieralisi @ 2015-05-05 16:03 UTC (permalink / raw)
  To: Will Deacon
  Cc: Jayachandran C, Bjorn Helgaas, linux-pci, linux-arm-kernel,
	Arnd Bergmann, Liviu Dudau, suravee.suthikulpanit, Ming Lei

On Tue, May 05, 2015 at 04:53:46PM +0100, Will Deacon wrote:
> On Tue, May 05, 2015 at 03:02:12AM +0100, Jayachandran C wrote:
> > The current code in pci-host-generic.c uses pci_common_init_dev()
> > from the arch/arm/ to do a part of the PCI initialization, and this
> > prevents it from being used on arm64.
> > 
> > The initialization done by pci_common_init_dev() that is really
> > needed by pci-host-generic.c can be done in the same file without
> > using the hw_pci API of ARM.
> > 
> > The ARM platform requires a pci_sys_data as sysdata for the PCI bus,
> > this is be handled by setting up 'struct gen_pci' to embed a
> > pci_sys_data variable as the first element on the ARM platform.
> > 
> > Signed-off-by: Jayachandran C <jchandra@broadcom.com>
> > ---
> > Here's v2 of the patches, this enables use of pci-host-generic on
> > arm64.
> > 
> > This has been tested on both qemu and fast model for arm64, and on
> > qemu for arm32.
> > 
> > v1->v2
> >  - Address comments from Arnd Bergmann and Lorenzo Pieralisi
> >     - move contents of gen_pci_init to gen_pci_probe
> >     - assign resources only when !probe_only
> >  - tested on ARM32 with qemu option -M virt
> 
> I tried this with an arm64 kernel running under kvmtool, but I get the
> following errors (a 32-bit ARM kernel does seem to work):
> 
>   PCI host bridge /pci ranges:
>      IO 0x00000000..0x0000ffff -> 0x00000000
>     MEM 0x41000000..0x7fffffff -> 0x41000000
>   pci-host-generic 40000000.pci: PCI host bridge to bus 0000:00
>   pci_bus 0000:00: root bus resource [bus 00-01]
>   pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
>   pci_bus 0000:00: root bus resource [mem 0x41000000-0x7fffffff]
>   pci_bus 0000:00: scanning bus
>   pci 0000:00:00.0: [1af4:1009] type 00 class 0xff0000
>   pci 0000:00:00.0: reg 0x10: [mem 0x41000000-0x410003ff]
>   pci 0000:00:00.0: reg 0x14: [io  0x6200-0x65ff]
>   pci 0000:00:00.0: reg 0x18: [mem 0x41000400-0x410005ff]
>   pci 0000:00:01.0: [1af4:1009] type 00 class 0xff0000
>   pci 0000:00:01.0: reg 0x10: [mem 0x41000800-0x41000bff]
>   pci 0000:00:01.0: reg 0x14: [io  0x6600-0x69ff]
>   pci 0000:00:01.0: reg 0x18: [mem 0x41000c00-0x41000dff]
>   pci_bus 0000:00: fixups for bus
>   pci_bus 0000:00: bus scan returning with max=00
>   pci 0000:00:00.0: fixup irq: got 10
>   pci 0000:00:00.0: assigning IRQ 10
>   pci 0000:00:01.0: fixup irq: got 11
>   pci 0000:00:01.0: assigning IRQ 11
>   virtio-pci 0000:00:00.0: can't enable device: BAR 0 [mem 0x41000000-0x410003ff] not claimed
>   virtio-pci: probe of 0000:00:00.0 failed with error -22
>   virtio-pci 0000:00:01.0: can't enable device: BAR 0 [mem 0x41000800-0x41000bff] not claimed
>   virtio-pci: probe of 0000:00:01.0 failed with error -22

Yes, I already mentioned on v1 and comment was not taken into account,
at the moment when we enable devices on arm64 we rely on the generic

pcibios_enable_device()

function that by enabling resources trigger that error on PROBE_ONLY
systems.

We could do what arm does, by checking the PROBE_ONLY flag
and call pci_enable_resources only if !PROBE_ONLY (and do that in the
generic drivers/pci/pci.c pcibios_enable_device function) but IIRC Bjorn
did not like that much.

Lorenzo

^ permalink raw reply	[flat|nested] 42+ messages in thread

* [PATCH v2 1/2] PCI: generic: remove dependency on hw_pci
@ 2015-05-05 16:03     ` Lorenzo Pieralisi
  0 siblings, 0 replies; 42+ messages in thread
From: Lorenzo Pieralisi @ 2015-05-05 16:03 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, May 05, 2015 at 04:53:46PM +0100, Will Deacon wrote:
> On Tue, May 05, 2015 at 03:02:12AM +0100, Jayachandran C wrote:
> > The current code in pci-host-generic.c uses pci_common_init_dev()
> > from the arch/arm/ to do a part of the PCI initialization, and this
> > prevents it from being used on arm64.
> > 
> > The initialization done by pci_common_init_dev() that is really
> > needed by pci-host-generic.c can be done in the same file without
> > using the hw_pci API of ARM.
> > 
> > The ARM platform requires a pci_sys_data as sysdata for the PCI bus,
> > this is be handled by setting up 'struct gen_pci' to embed a
> > pci_sys_data variable as the first element on the ARM platform.
> > 
> > Signed-off-by: Jayachandran C <jchandra@broadcom.com>
> > ---
> > Here's v2 of the patches, this enables use of pci-host-generic on
> > arm64.
> > 
> > This has been tested on both qemu and fast model for arm64, and on
> > qemu for arm32.
> > 
> > v1->v2
> >  - Address comments from Arnd Bergmann and Lorenzo Pieralisi
> >     - move contents of gen_pci_init to gen_pci_probe
> >     - assign resources only when !probe_only
> >  - tested on ARM32 with qemu option -M virt
> 
> I tried this with an arm64 kernel running under kvmtool, but I get the
> following errors (a 32-bit ARM kernel does seem to work):
> 
>   PCI host bridge /pci ranges:
>      IO 0x00000000..0x0000ffff -> 0x00000000
>     MEM 0x41000000..0x7fffffff -> 0x41000000
>   pci-host-generic 40000000.pci: PCI host bridge to bus 0000:00
>   pci_bus 0000:00: root bus resource [bus 00-01]
>   pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
>   pci_bus 0000:00: root bus resource [mem 0x41000000-0x7fffffff]
>   pci_bus 0000:00: scanning bus
>   pci 0000:00:00.0: [1af4:1009] type 00 class 0xff0000
>   pci 0000:00:00.0: reg 0x10: [mem 0x41000000-0x410003ff]
>   pci 0000:00:00.0: reg 0x14: [io  0x6200-0x65ff]
>   pci 0000:00:00.0: reg 0x18: [mem 0x41000400-0x410005ff]
>   pci 0000:00:01.0: [1af4:1009] type 00 class 0xff0000
>   pci 0000:00:01.0: reg 0x10: [mem 0x41000800-0x41000bff]
>   pci 0000:00:01.0: reg 0x14: [io  0x6600-0x69ff]
>   pci 0000:00:01.0: reg 0x18: [mem 0x41000c00-0x41000dff]
>   pci_bus 0000:00: fixups for bus
>   pci_bus 0000:00: bus scan returning with max=00
>   pci 0000:00:00.0: fixup irq: got 10
>   pci 0000:00:00.0: assigning IRQ 10
>   pci 0000:00:01.0: fixup irq: got 11
>   pci 0000:00:01.0: assigning IRQ 11
>   virtio-pci 0000:00:00.0: can't enable device: BAR 0 [mem 0x41000000-0x410003ff] not claimed
>   virtio-pci: probe of 0000:00:00.0 failed with error -22
>   virtio-pci 0000:00:01.0: can't enable device: BAR 0 [mem 0x41000800-0x41000bff] not claimed
>   virtio-pci: probe of 0000:00:01.0 failed with error -22

Yes, I already mentioned on v1 and comment was not taken into account,
at the moment when we enable devices on arm64 we rely on the generic

pcibios_enable_device()

function that by enabling resources trigger that error on PROBE_ONLY
systems.

We could do what arm does, by checking the PROBE_ONLY flag
and call pci_enable_resources only if !PROBE_ONLY (and do that in the
generic drivers/pci/pci.c pcibios_enable_device function) but IIRC Bjorn
did not like that much.

Lorenzo

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [PATCH v2 1/2] PCI: generic: remove dependency on hw_pci
  2015-05-05 15:53   ` Will Deacon
@ 2015-05-06 14:18     ` Lorenzo Pieralisi
  -1 siblings, 0 replies; 42+ messages in thread
From: Lorenzo Pieralisi @ 2015-05-06 14:18 UTC (permalink / raw)
  To: Will Deacon
  Cc: Jayachandran C, Bjorn Helgaas, linux-pci, linux-arm-kernel,
	Arnd Bergmann, Liviu Dudau, suravee.suthikulpanit, Ming Lei

On Tue, May 05, 2015 at 04:53:46PM +0100, Will Deacon wrote:
> On Tue, May 05, 2015 at 03:02:12AM +0100, Jayachandran C wrote:
> > The current code in pci-host-generic.c uses pci_common_init_dev()
> > from the arch/arm/ to do a part of the PCI initialization, and this
> > prevents it from being used on arm64.
> > 
> > The initialization done by pci_common_init_dev() that is really
> > needed by pci-host-generic.c can be done in the same file without
> > using the hw_pci API of ARM.
> > 
> > The ARM platform requires a pci_sys_data as sysdata for the PCI bus,
> > this is be handled by setting up 'struct gen_pci' to embed a
> > pci_sys_data variable as the first element on the ARM platform.
> > 
> > Signed-off-by: Jayachandran C <jchandra@broadcom.com>
> > ---
> > Here's v2 of the patches, this enables use of pci-host-generic on
> > arm64.
> > 
> > This has been tested on both qemu and fast model for arm64, and on
> > qemu for arm32.
> > 
> > v1->v2
> >  - Address comments from Arnd Bergmann and Lorenzo Pieralisi
> >     - move contents of gen_pci_init to gen_pci_probe
> >     - assign resources only when !probe_only
> >  - tested on ARM32 with qemu option -M virt
> 
> I tried this with an arm64 kernel running under kvmtool, but I get the
> following errors (a 32-bit ARM kernel does seem to work):
> 
>   PCI host bridge /pci ranges:
>      IO 0x00000000..0x0000ffff -> 0x00000000
>     MEM 0x41000000..0x7fffffff -> 0x41000000
>   pci-host-generic 40000000.pci: PCI host bridge to bus 0000:00
>   pci_bus 0000:00: root bus resource [bus 00-01]
>   pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
>   pci_bus 0000:00: root bus resource [mem 0x41000000-0x7fffffff]
>   pci_bus 0000:00: scanning bus
>   pci 0000:00:00.0: [1af4:1009] type 00 class 0xff0000
>   pci 0000:00:00.0: reg 0x10: [mem 0x41000000-0x410003ff]
>   pci 0000:00:00.0: reg 0x14: [io  0x6200-0x65ff]
>   pci 0000:00:00.0: reg 0x18: [mem 0x41000400-0x410005ff]
>   pci 0000:00:01.0: [1af4:1009] type 00 class 0xff0000
>   pci 0000:00:01.0: reg 0x10: [mem 0x41000800-0x41000bff]
>   pci 0000:00:01.0: reg 0x14: [io  0x6600-0x69ff]
>   pci 0000:00:01.0: reg 0x18: [mem 0x41000c00-0x41000dff]
>   pci_bus 0000:00: fixups for bus
>   pci_bus 0000:00: bus scan returning with max=00
>   pci 0000:00:00.0: fixup irq: got 10
>   pci 0000:00:00.0: assigning IRQ 10
>   pci 0000:00:01.0: fixup irq: got 11
>   pci 0000:00:01.0: assigning IRQ 11
>   virtio-pci 0000:00:00.0: can't enable device: BAR 0 [mem 0x41000000-0x410003ff] not claimed
>   virtio-pci: probe of 0000:00:00.0 failed with error -22
>   virtio-pci 0000:00:01.0: can't enable device: BAR 0 [mem 0x41000800-0x41000bff] not claimed
>   virtio-pci: probe of 0000:00:01.0 failed with error -22

Ok, had a further look.

Referring to this thread:

https://lkml.org/lkml/2014/9/29/557

By looking at other architectures code, resources should be claimed
(ie requested) even when PCI_PROBE_ONLY is set. Alpha, Sparc and PowerPC
seem to do that, in slightly different fashions.

I do not think, as Bjorn mentioned, that PCI_PROBE_ONLY should be used
to prevent enabling resources through a PCI command, which is what
pci_enable_resources does.

What we can do, is providing a generic PCI layer API that allows claiming
resources for a specific PCI bus, something similar if not identical
to what is done on alpha:

arch/alpha/kernel/pci.c pcibios_claim_one_bus()

that is not alpha specific at all. That way, we can use the API to claim
bus resources instead of assigning them on PCI_PROBE_ONLY (I *think*
that alpha calls pci_assign_unassigned_resources() even if
PCI_PROBE_ONLY is set, it should be safe since resources are claimed
first so IIUC the PCI layer would revert to FW BAR configuration on
assignment failure).

Bjorn, any opinion on this ? Putting together a patch is easy when
we agree on the solution.

Lorenzo

^ permalink raw reply	[flat|nested] 42+ messages in thread

* [PATCH v2 1/2] PCI: generic: remove dependency on hw_pci
@ 2015-05-06 14:18     ` Lorenzo Pieralisi
  0 siblings, 0 replies; 42+ messages in thread
From: Lorenzo Pieralisi @ 2015-05-06 14:18 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, May 05, 2015 at 04:53:46PM +0100, Will Deacon wrote:
> On Tue, May 05, 2015 at 03:02:12AM +0100, Jayachandran C wrote:
> > The current code in pci-host-generic.c uses pci_common_init_dev()
> > from the arch/arm/ to do a part of the PCI initialization, and this
> > prevents it from being used on arm64.
> > 
> > The initialization done by pci_common_init_dev() that is really
> > needed by pci-host-generic.c can be done in the same file without
> > using the hw_pci API of ARM.
> > 
> > The ARM platform requires a pci_sys_data as sysdata for the PCI bus,
> > this is be handled by setting up 'struct gen_pci' to embed a
> > pci_sys_data variable as the first element on the ARM platform.
> > 
> > Signed-off-by: Jayachandran C <jchandra@broadcom.com>
> > ---
> > Here's v2 of the patches, this enables use of pci-host-generic on
> > arm64.
> > 
> > This has been tested on both qemu and fast model for arm64, and on
> > qemu for arm32.
> > 
> > v1->v2
> >  - Address comments from Arnd Bergmann and Lorenzo Pieralisi
> >     - move contents of gen_pci_init to gen_pci_probe
> >     - assign resources only when !probe_only
> >  - tested on ARM32 with qemu option -M virt
> 
> I tried this with an arm64 kernel running under kvmtool, but I get the
> following errors (a 32-bit ARM kernel does seem to work):
> 
>   PCI host bridge /pci ranges:
>      IO 0x00000000..0x0000ffff -> 0x00000000
>     MEM 0x41000000..0x7fffffff -> 0x41000000
>   pci-host-generic 40000000.pci: PCI host bridge to bus 0000:00
>   pci_bus 0000:00: root bus resource [bus 00-01]
>   pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
>   pci_bus 0000:00: root bus resource [mem 0x41000000-0x7fffffff]
>   pci_bus 0000:00: scanning bus
>   pci 0000:00:00.0: [1af4:1009] type 00 class 0xff0000
>   pci 0000:00:00.0: reg 0x10: [mem 0x41000000-0x410003ff]
>   pci 0000:00:00.0: reg 0x14: [io  0x6200-0x65ff]
>   pci 0000:00:00.0: reg 0x18: [mem 0x41000400-0x410005ff]
>   pci 0000:00:01.0: [1af4:1009] type 00 class 0xff0000
>   pci 0000:00:01.0: reg 0x10: [mem 0x41000800-0x41000bff]
>   pci 0000:00:01.0: reg 0x14: [io  0x6600-0x69ff]
>   pci 0000:00:01.0: reg 0x18: [mem 0x41000c00-0x41000dff]
>   pci_bus 0000:00: fixups for bus
>   pci_bus 0000:00: bus scan returning with max=00
>   pci 0000:00:00.0: fixup irq: got 10
>   pci 0000:00:00.0: assigning IRQ 10
>   pci 0000:00:01.0: fixup irq: got 11
>   pci 0000:00:01.0: assigning IRQ 11
>   virtio-pci 0000:00:00.0: can't enable device: BAR 0 [mem 0x41000000-0x410003ff] not claimed
>   virtio-pci: probe of 0000:00:00.0 failed with error -22
>   virtio-pci 0000:00:01.0: can't enable device: BAR 0 [mem 0x41000800-0x41000bff] not claimed
>   virtio-pci: probe of 0000:00:01.0 failed with error -22

Ok, had a further look.

Referring to this thread:

https://lkml.org/lkml/2014/9/29/557

By looking at other architectures code, resources should be claimed
(ie requested) even when PCI_PROBE_ONLY is set. Alpha, Sparc and PowerPC
seem to do that, in slightly different fashions.

I do not think, as Bjorn mentioned, that PCI_PROBE_ONLY should be used
to prevent enabling resources through a PCI command, which is what
pci_enable_resources does.

What we can do, is providing a generic PCI layer API that allows claiming
resources for a specific PCI bus, something similar if not identical
to what is done on alpha:

arch/alpha/kernel/pci.c pcibios_claim_one_bus()

that is not alpha specific at all. That way, we can use the API to claim
bus resources instead of assigning them on PCI_PROBE_ONLY (I *think*
that alpha calls pci_assign_unassigned_resources() even if
PCI_PROBE_ONLY is set, it should be safe since resources are claimed
first so IIUC the PCI layer would revert to FW BAR configuration on
assignment failure).

Bjorn, any opinion on this ? Putting together a patch is easy when
we agree on the solution.

Lorenzo

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [PATCH v2 1/2] PCI: generic: remove dependency on hw_pci
  2015-05-06 14:18     ` Lorenzo Pieralisi
@ 2015-05-06 15:18       ` Bjorn Helgaas
  -1 siblings, 0 replies; 42+ messages in thread
From: Bjorn Helgaas @ 2015-05-06 15:18 UTC (permalink / raw)
  To: Lorenzo Pieralisi
  Cc: Will Deacon, Jayachandran C, linux-pci, linux-arm-kernel,
	Arnd Bergmann, Liviu Dudau, suravee.suthikulpanit, Ming Lei

On Wed, May 6, 2015 at 9:18 AM, Lorenzo Pieralisi
<lorenzo.pieralisi@arm.com> wrote:
> On Tue, May 05, 2015 at 04:53:46PM +0100, Will Deacon wrote:
>> On Tue, May 05, 2015 at 03:02:12AM +0100, Jayachandran C wrote:
>> > The current code in pci-host-generic.c uses pci_common_init_dev()
>> > from the arch/arm/ to do a part of the PCI initialization, and this
>> > prevents it from being used on arm64.
>> >
>> > The initialization done by pci_common_init_dev() that is really
>> > needed by pci-host-generic.c can be done in the same file without
>> > using the hw_pci API of ARM.
>> >
>> > The ARM platform requires a pci_sys_data as sysdata for the PCI bus,
>> > this is be handled by setting up 'struct gen_pci' to embed a
>> > pci_sys_data variable as the first element on the ARM platform.
>> >
>> > Signed-off-by: Jayachandran C <jchandra@broadcom.com>
>> > ---
>> > Here's v2 of the patches, this enables use of pci-host-generic on
>> > arm64.
>> >
>> > This has been tested on both qemu and fast model for arm64, and on
>> > qemu for arm32.
>> >
>> > v1->v2
>> >  - Address comments from Arnd Bergmann and Lorenzo Pieralisi
>> >     - move contents of gen_pci_init to gen_pci_probe
>> >     - assign resources only when !probe_only
>> >  - tested on ARM32 with qemu option -M virt
>>
>> I tried this with an arm64 kernel running under kvmtool, but I get the
>> following errors (a 32-bit ARM kernel does seem to work):
>>
>>   PCI host bridge /pci ranges:
>>      IO 0x00000000..0x0000ffff -> 0x00000000
>>     MEM 0x41000000..0x7fffffff -> 0x41000000
>>   pci-host-generic 40000000.pci: PCI host bridge to bus 0000:00
>>   pci_bus 0000:00: root bus resource [bus 00-01]
>>   pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
>>   pci_bus 0000:00: root bus resource [mem 0x41000000-0x7fffffff]
>>   pci_bus 0000:00: scanning bus
>>   pci 0000:00:00.0: [1af4:1009] type 00 class 0xff0000
>>   pci 0000:00:00.0: reg 0x10: [mem 0x41000000-0x410003ff]
>>   pci 0000:00:00.0: reg 0x14: [io  0x6200-0x65ff]
>>   pci 0000:00:00.0: reg 0x18: [mem 0x41000400-0x410005ff]
>>   pci 0000:00:01.0: [1af4:1009] type 00 class 0xff0000
>>   pci 0000:00:01.0: reg 0x10: [mem 0x41000800-0x41000bff]
>>   pci 0000:00:01.0: reg 0x14: [io  0x6600-0x69ff]
>>   pci 0000:00:01.0: reg 0x18: [mem 0x41000c00-0x41000dff]
>>   pci_bus 0000:00: fixups for bus
>>   pci_bus 0000:00: bus scan returning with max=00
>>   pci 0000:00:00.0: fixup irq: got 10
>>   pci 0000:00:00.0: assigning IRQ 10
>>   pci 0000:00:01.0: fixup irq: got 11
>>   pci 0000:00:01.0: assigning IRQ 11
>>   virtio-pci 0000:00:00.0: can't enable device: BAR 0 [mem 0x41000000-0x410003ff] not claimed
>>   virtio-pci: probe of 0000:00:00.0 failed with error -22
>>   virtio-pci 0000:00:01.0: can't enable device: BAR 0 [mem 0x41000800-0x41000bff] not claimed
>>   virtio-pci: probe of 0000:00:01.0 failed with error -22
>
> Ok, had a further look.
>
> Referring to this thread:
>
> https://lkml.org/lkml/2014/9/29/557
>
> By looking at other architectures code, resources should be claimed
> (ie requested) even when PCI_PROBE_ONLY is set. Alpha, Sparc and PowerPC
> seem to do that, in slightly different fashions.
>
> I do not think, as Bjorn mentioned, that PCI_PROBE_ONLY should be used
> to prevent enabling resources through a PCI command, which is what
> pci_enable_resources does.
>
> What we can do, is providing a generic PCI layer API that allows claiming
> resources for a specific PCI bus, something similar if not identical
> to what is done on alpha:
>
> arch/alpha/kernel/pci.c pcibios_claim_one_bus()
>
> that is not alpha specific at all. That way, we can use the API to claim
> bus resources instead of assigning them on PCI_PROBE_ONLY (I *think*
> that alpha calls pci_assign_unassigned_resources() even if
> PCI_PROBE_ONLY is set, it should be safe since resources are claimed
> first so IIUC the PCI layer would revert to FW BAR configuration on
> assignment failure).
>
> Bjorn, any opinion on this ? Putting together a patch is easy when
> we agree on the solution.

I would like claiming resources, i.e., pci_claim_resource(), to happen
in the core instead of in arch code because it's not inherently
arch-specific.  I don't think it should depend on PCI_PROBE_ONLY.

Bjorn

^ permalink raw reply	[flat|nested] 42+ messages in thread

* [PATCH v2 1/2] PCI: generic: remove dependency on hw_pci
@ 2015-05-06 15:18       ` Bjorn Helgaas
  0 siblings, 0 replies; 42+ messages in thread
From: Bjorn Helgaas @ 2015-05-06 15:18 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, May 6, 2015 at 9:18 AM, Lorenzo Pieralisi
<lorenzo.pieralisi@arm.com> wrote:
> On Tue, May 05, 2015 at 04:53:46PM +0100, Will Deacon wrote:
>> On Tue, May 05, 2015 at 03:02:12AM +0100, Jayachandran C wrote:
>> > The current code in pci-host-generic.c uses pci_common_init_dev()
>> > from the arch/arm/ to do a part of the PCI initialization, and this
>> > prevents it from being used on arm64.
>> >
>> > The initialization done by pci_common_init_dev() that is really
>> > needed by pci-host-generic.c can be done in the same file without
>> > using the hw_pci API of ARM.
>> >
>> > The ARM platform requires a pci_sys_data as sysdata for the PCI bus,
>> > this is be handled by setting up 'struct gen_pci' to embed a
>> > pci_sys_data variable as the first element on the ARM platform.
>> >
>> > Signed-off-by: Jayachandran C <jchandra@broadcom.com>
>> > ---
>> > Here's v2 of the patches, this enables use of pci-host-generic on
>> > arm64.
>> >
>> > This has been tested on both qemu and fast model for arm64, and on
>> > qemu for arm32.
>> >
>> > v1->v2
>> >  - Address comments from Arnd Bergmann and Lorenzo Pieralisi
>> >     - move contents of gen_pci_init to gen_pci_probe
>> >     - assign resources only when !probe_only
>> >  - tested on ARM32 with qemu option -M virt
>>
>> I tried this with an arm64 kernel running under kvmtool, but I get the
>> following errors (a 32-bit ARM kernel does seem to work):
>>
>>   PCI host bridge /pci ranges:
>>      IO 0x00000000..0x0000ffff -> 0x00000000
>>     MEM 0x41000000..0x7fffffff -> 0x41000000
>>   pci-host-generic 40000000.pci: PCI host bridge to bus 0000:00
>>   pci_bus 0000:00: root bus resource [bus 00-01]
>>   pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
>>   pci_bus 0000:00: root bus resource [mem 0x41000000-0x7fffffff]
>>   pci_bus 0000:00: scanning bus
>>   pci 0000:00:00.0: [1af4:1009] type 00 class 0xff0000
>>   pci 0000:00:00.0: reg 0x10: [mem 0x41000000-0x410003ff]
>>   pci 0000:00:00.0: reg 0x14: [io  0x6200-0x65ff]
>>   pci 0000:00:00.0: reg 0x18: [mem 0x41000400-0x410005ff]
>>   pci 0000:00:01.0: [1af4:1009] type 00 class 0xff0000
>>   pci 0000:00:01.0: reg 0x10: [mem 0x41000800-0x41000bff]
>>   pci 0000:00:01.0: reg 0x14: [io  0x6600-0x69ff]
>>   pci 0000:00:01.0: reg 0x18: [mem 0x41000c00-0x41000dff]
>>   pci_bus 0000:00: fixups for bus
>>   pci_bus 0000:00: bus scan returning with max=00
>>   pci 0000:00:00.0: fixup irq: got 10
>>   pci 0000:00:00.0: assigning IRQ 10
>>   pci 0000:00:01.0: fixup irq: got 11
>>   pci 0000:00:01.0: assigning IRQ 11
>>   virtio-pci 0000:00:00.0: can't enable device: BAR 0 [mem 0x41000000-0x410003ff] not claimed
>>   virtio-pci: probe of 0000:00:00.0 failed with error -22
>>   virtio-pci 0000:00:01.0: can't enable device: BAR 0 [mem 0x41000800-0x41000bff] not claimed
>>   virtio-pci: probe of 0000:00:01.0 failed with error -22
>
> Ok, had a further look.
>
> Referring to this thread:
>
> https://lkml.org/lkml/2014/9/29/557
>
> By looking at other architectures code, resources should be claimed
> (ie requested) even when PCI_PROBE_ONLY is set. Alpha, Sparc and PowerPC
> seem to do that, in slightly different fashions.
>
> I do not think, as Bjorn mentioned, that PCI_PROBE_ONLY should be used
> to prevent enabling resources through a PCI command, which is what
> pci_enable_resources does.
>
> What we can do, is providing a generic PCI layer API that allows claiming
> resources for a specific PCI bus, something similar if not identical
> to what is done on alpha:
>
> arch/alpha/kernel/pci.c pcibios_claim_one_bus()
>
> that is not alpha specific at all. That way, we can use the API to claim
> bus resources instead of assigning them on PCI_PROBE_ONLY (I *think*
> that alpha calls pci_assign_unassigned_resources() even if
> PCI_PROBE_ONLY is set, it should be safe since resources are claimed
> first so IIUC the PCI layer would revert to FW BAR configuration on
> assignment failure).
>
> Bjorn, any opinion on this ? Putting together a patch is easy when
> we agree on the solution.

I would like claiming resources, i.e., pci_claim_resource(), to happen
in the core instead of in arch code because it's not inherently
arch-specific.  I don't think it should depend on PCI_PROBE_ONLY.

Bjorn

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [PATCH v2 1/2] PCI: generic: remove dependency on hw_pci
  2015-05-06 15:18       ` Bjorn Helgaas
@ 2015-05-07  3:32         ` Suravee Suthikulanit
  -1 siblings, 0 replies; 42+ messages in thread
From: Suravee Suthikulanit @ 2015-05-07  3:32 UTC (permalink / raw)
  To: Bjorn Helgaas, Lorenzo Pieralisi
  Cc: Will Deacon, Jayachandran C, linux-pci, linux-arm-kernel,
	Arnd Bergmann, Liviu Dudau, Ming Lei

On 5/6/2015 10:18 AM, Bjorn Helgaas wrote:
> On Wed, May 6, 2015 at 9:18 AM, Lorenzo Pieralisi
> <lorenzo.pieralisi@arm.com> wrote:
>> On Tue, May 05, 2015 at 04:53:46PM +0100, Will Deacon wrote:
>>> On Tue, May 05, 2015 at 03:02:12AM +0100, Jayachandran C wrote:
>>>> The current code in pci-host-generic.c uses pci_common_init_dev()
>>>> from the arch/arm/ to do a part of the PCI initialization, and this
>>>> prevents it from being used on arm64.
>>>>
>>>> The initialization done by pci_common_init_dev() that is really
>>>> needed by pci-host-generic.c can be done in the same file without
>>>> using the hw_pci API of ARM.
>>>>
>>>> The ARM platform requires a pci_sys_data as sysdata for the PCI bus,
>>>> this is be handled by setting up 'struct gen_pci' to embed a
>>>> pci_sys_data variable as the first element on the ARM platform.
>>>>
>>>> Signed-off-by: Jayachandran C <jchandra@broadcom.com>
>>>> ---
>>>> Here's v2 of the patches, this enables use of pci-host-generic on
>>>> arm64.
>>>>
>>>> This has been tested on both qemu and fast model for arm64, and on
>>>> qemu for arm32.
>>>>
>>>> v1->v2
>>>>   - Address comments from Arnd Bergmann and Lorenzo Pieralisi
>>>>      - move contents of gen_pci_init to gen_pci_probe
>>>>      - assign resources only when !probe_only
>>>>   - tested on ARM32 with qemu option -M virt
>>>
>>> I tried this with an arm64 kernel running under kvmtool, but I get the
>>> following errors (a 32-bit ARM kernel does seem to work):
>>>
>>>    PCI host bridge /pci ranges:
>>>       IO 0x00000000..0x0000ffff -> 0x00000000
>>>      MEM 0x41000000..0x7fffffff -> 0x41000000
>>>    pci-host-generic 40000000.pci: PCI host bridge to bus 0000:00
>>>    pci_bus 0000:00: root bus resource [bus 00-01]
>>>    pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
>>>    pci_bus 0000:00: root bus resource [mem 0x41000000-0x7fffffff]
>>>    pci_bus 0000:00: scanning bus
>>>    pci 0000:00:00.0: [1af4:1009] type 00 class 0xff0000
>>>    pci 0000:00:00.0: reg 0x10: [mem 0x41000000-0x410003ff]
>>>    pci 0000:00:00.0: reg 0x14: [io  0x6200-0x65ff]
>>>    pci 0000:00:00.0: reg 0x18: [mem 0x41000400-0x410005ff]
>>>    pci 0000:00:01.0: [1af4:1009] type 00 class 0xff0000
>>>    pci 0000:00:01.0: reg 0x10: [mem 0x41000800-0x41000bff]
>>>    pci 0000:00:01.0: reg 0x14: [io  0x6600-0x69ff]
>>>    pci 0000:00:01.0: reg 0x18: [mem 0x41000c00-0x41000dff]
>>>    pci_bus 0000:00: fixups for bus
>>>    pci_bus 0000:00: bus scan returning with max=00
>>>    pci 0000:00:00.0: fixup irq: got 10
>>>    pci 0000:00:00.0: assigning IRQ 10
>>>    pci 0000:00:01.0: fixup irq: got 11
>>>    pci 0000:00:01.0: assigning IRQ 11
>>>    virtio-pci 0000:00:00.0: can't enable device: BAR 0 [mem 0x41000000-0x410003ff] not claimed
>>>    virtio-pci: probe of 0000:00:00.0 failed with error -22
>>>    virtio-pci 0000:00:01.0: can't enable device: BAR 0 [mem 0x41000800-0x41000bff] not claimed
>>>    virtio-pci: probe of 0000:00:01.0 failed with error -22
>>
>> Ok, had a further look.
>>
>> Referring to this thread:
>>
>> https://lkml.org/lkml/2014/9/29/557
>>
>> By looking at other architectures code, resources should be claimed
>> (ie requested) even when PCI_PROBE_ONLY is set. Alpha, Sparc and PowerPC
>> seem to do that, in slightly different fashions.
>>
>> I do not think, as Bjorn mentioned, that PCI_PROBE_ONLY should be used
>> to prevent enabling resources through a PCI command, which is what
>> pci_enable_resources does.
>>
>> What we can do, is providing a generic PCI layer API that allows claiming
>> resources for a specific PCI bus, something similar if not identical
>> to what is done on alpha:
>>
>> arch/alpha/kernel/pci.c pcibios_claim_one_bus()
>>
>> that is not alpha specific at all. That way, we can use the API to claim
>> bus resources instead of assigning them on PCI_PROBE_ONLY (I *think*
>> that alpha calls pci_assign_unassigned_resources() even if
>> PCI_PROBE_ONLY is set, it should be safe since resources are claimed
>> first so IIUC the PCI layer would revert to FW BAR configuration on
>> assignment failure).
>>
>> Bjorn, any opinion on this ? Putting together a patch is easy when
>> we agree on the solution.
>
> I would like claiming resources, i.e., pci_claim_resource(), to happen
> in the core instead of in arch code because it's not inherently
> arch-specific.  I don't think it should depend on PCI_PROBE_ONLY.
>
> Bjorn
>

Hi All,

I tested this patch series on the AMD Seattle w/o PCI_PROBE_ONLY mode 
and that works fine. However, w/ PCI_PROBE_ONLY, I also run into the 
resource not claimed issue (no surprise here).

So, I tried porting the pcibios_claim_one_bus() from 
arch/alpha/kernel/pci.c as Lorenzo suggested, plus the a small change in 
pci_claim_resource(), and it seems to work w/ PCI_PROBE_ONLY. (Please 
see example patch below.)

The additional while loop is needed in the pci_claim_resource() since I 
need to reference back to the resource in the root bus, which are 
defined from the DT node. Does this sounds like a reasonable approach?

diff --git a/drivers/pci/host/pci-host-generic.c 
b/drivers/pci/host/pci-host-generic.c
index e9cc559..0dfa23d 100644
--- a/drivers/pci/host/pci-host-generic.c
+++ b/drivers/pci/host/pci-host-generic.c
@@ -261,7 +261,10 @@ static int gen_pci_probe(struct platform_device *pdev)
  	if (!pci_has_flag(PCI_PROBE_ONLY)) {
  		pci_bus_size_bridges(bus);
  		pci_bus_assign_resources(bus);
+	} else {
+		pci_claim_one_bus(bus);
  	}
+
  	pci_bus_add_devices(bus);

  	/* Configure PCI Express settings */
diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
index 232f925..d4b43b3 100644
--- a/drivers/pci/setup-res.c
+++ b/drivers/pci/setup-res.c
@@ -109,6 +109,7 @@ int pci_claim_resource(struct pci_dev *dev, int 
resource)
  {
  	struct resource *res = &dev->resource[resource];
  	struct resource *root, *conflict;
+	struct pci_dev *pdev = dev;

  	if (res->flags & IORESOURCE_UNSET) {
  		dev_info(&dev->dev, "can't claim BAR %d %pR: no address assigned\n",
@@ -116,7 +117,18 @@ int pci_claim_resource(struct pci_dev *dev, int 
resource)
  		return -EINVAL;
  	}

-	root = pci_find_parent_resource(dev, res);
+	while (pdev) {
+		root = pci_find_parent_resource(pdev, res);
+		if (root)
+			break;
+
+		if (pci_has_flag(PCI_PROBE_ONLY) &&
+		    !pci_is_root_bus(pdev->bus))
+			pdev = pdev->bus->self;
+		else
+			break;
+	}
+
  	if (!root) {
  		dev_info(&dev->dev, "can't claim BAR %d %pR: no compatible bridge 
window\n",
  			 resource, res);
@@ -136,6 +148,36 @@ int pci_claim_resource(struct pci_dev *dev, int 
resource)
  }
  EXPORT_SYMBOL(pci_claim_resource);

+void pci_claim_one_bus(struct pci_bus *b)
+{
+	struct pci_dev *pdev;
+	struct pci_bus *child_bus;
+
+	list_for_each_entry(pdev, &b->devices, bus_list) {
+		int i;
+
+		for (i = 0; i < PCI_NUM_RESOURCES; i++) {
+			struct resource *r = &pdev->resource[i];
+
+			if (r->parent || !r->start || !r->flags)
+				continue;
+
+			if (pci_has_flag(PCI_PROBE_ONLY) ||
+			    (r->flags & IORESOURCE_PCI_FIXED)) {
+				if (pci_claim_resource(pdev, i) == 0)
+					continue;
+
+				pci_claim_bridge_resource(pdev, i);
+			}
+		}
+	}
+
+	list_for_each_entry(child_bus, &b->children, node) {
+		pci_claim_one_bus(child_bus);
+	}
+}
+EXPORT_SYMBOL(pci_claim_one_bus);
+
  void pci_disable_bridge_window(struct pci_dev *dev)
  {
  	dev_info(&dev->dev, "disabling bridge mem windows\n");
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 353db8d..b59ad4b 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1085,6 +1085,7 @@ void pci_assign_unassigned_bridge_resources(struct 
pci_dev *bridge);
  void pci_assign_unassigned_bus_resources(struct pci_bus *bus);
  void pci_assign_unassigned_root_bus_resources(struct pci_bus *bus);
  void pdev_enable_device(struct pci_dev *);
+void pci_claim_one_bus(struct pci_bus *b);
  int pci_enable_resources(struct pci_dev *, int mask);
  void pci_fixup_irqs(u8 (*)(struct pci_dev *, u8 *),
  		    int (*)(const struct pci_dev *, u8, u8));
-------- END PATCH ----

Thanks,

Suravee


^ permalink raw reply related	[flat|nested] 42+ messages in thread

* [PATCH v2 1/2] PCI: generic: remove dependency on hw_pci
@ 2015-05-07  3:32         ` Suravee Suthikulanit
  0 siblings, 0 replies; 42+ messages in thread
From: Suravee Suthikulanit @ 2015-05-07  3:32 UTC (permalink / raw)
  To: linux-arm-kernel

On 5/6/2015 10:18 AM, Bjorn Helgaas wrote:
> On Wed, May 6, 2015 at 9:18 AM, Lorenzo Pieralisi
> <lorenzo.pieralisi@arm.com> wrote:
>> On Tue, May 05, 2015 at 04:53:46PM +0100, Will Deacon wrote:
>>> On Tue, May 05, 2015 at 03:02:12AM +0100, Jayachandran C wrote:
>>>> The current code in pci-host-generic.c uses pci_common_init_dev()
>>>> from the arch/arm/ to do a part of the PCI initialization, and this
>>>> prevents it from being used on arm64.
>>>>
>>>> The initialization done by pci_common_init_dev() that is really
>>>> needed by pci-host-generic.c can be done in the same file without
>>>> using the hw_pci API of ARM.
>>>>
>>>> The ARM platform requires a pci_sys_data as sysdata for the PCI bus,
>>>> this is be handled by setting up 'struct gen_pci' to embed a
>>>> pci_sys_data variable as the first element on the ARM platform.
>>>>
>>>> Signed-off-by: Jayachandran C <jchandra@broadcom.com>
>>>> ---
>>>> Here's v2 of the patches, this enables use of pci-host-generic on
>>>> arm64.
>>>>
>>>> This has been tested on both qemu and fast model for arm64, and on
>>>> qemu for arm32.
>>>>
>>>> v1->v2
>>>>   - Address comments from Arnd Bergmann and Lorenzo Pieralisi
>>>>      - move contents of gen_pci_init to gen_pci_probe
>>>>      - assign resources only when !probe_only
>>>>   - tested on ARM32 with qemu option -M virt
>>>
>>> I tried this with an arm64 kernel running under kvmtool, but I get the
>>> following errors (a 32-bit ARM kernel does seem to work):
>>>
>>>    PCI host bridge /pci ranges:
>>>       IO 0x00000000..0x0000ffff -> 0x00000000
>>>      MEM 0x41000000..0x7fffffff -> 0x41000000
>>>    pci-host-generic 40000000.pci: PCI host bridge to bus 0000:00
>>>    pci_bus 0000:00: root bus resource [bus 00-01]
>>>    pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
>>>    pci_bus 0000:00: root bus resource [mem 0x41000000-0x7fffffff]
>>>    pci_bus 0000:00: scanning bus
>>>    pci 0000:00:00.0: [1af4:1009] type 00 class 0xff0000
>>>    pci 0000:00:00.0: reg 0x10: [mem 0x41000000-0x410003ff]
>>>    pci 0000:00:00.0: reg 0x14: [io  0x6200-0x65ff]
>>>    pci 0000:00:00.0: reg 0x18: [mem 0x41000400-0x410005ff]
>>>    pci 0000:00:01.0: [1af4:1009] type 00 class 0xff0000
>>>    pci 0000:00:01.0: reg 0x10: [mem 0x41000800-0x41000bff]
>>>    pci 0000:00:01.0: reg 0x14: [io  0x6600-0x69ff]
>>>    pci 0000:00:01.0: reg 0x18: [mem 0x41000c00-0x41000dff]
>>>    pci_bus 0000:00: fixups for bus
>>>    pci_bus 0000:00: bus scan returning with max=00
>>>    pci 0000:00:00.0: fixup irq: got 10
>>>    pci 0000:00:00.0: assigning IRQ 10
>>>    pci 0000:00:01.0: fixup irq: got 11
>>>    pci 0000:00:01.0: assigning IRQ 11
>>>    virtio-pci 0000:00:00.0: can't enable device: BAR 0 [mem 0x41000000-0x410003ff] not claimed
>>>    virtio-pci: probe of 0000:00:00.0 failed with error -22
>>>    virtio-pci 0000:00:01.0: can't enable device: BAR 0 [mem 0x41000800-0x41000bff] not claimed
>>>    virtio-pci: probe of 0000:00:01.0 failed with error -22
>>
>> Ok, had a further look.
>>
>> Referring to this thread:
>>
>> https://lkml.org/lkml/2014/9/29/557
>>
>> By looking at other architectures code, resources should be claimed
>> (ie requested) even when PCI_PROBE_ONLY is set. Alpha, Sparc and PowerPC
>> seem to do that, in slightly different fashions.
>>
>> I do not think, as Bjorn mentioned, that PCI_PROBE_ONLY should be used
>> to prevent enabling resources through a PCI command, which is what
>> pci_enable_resources does.
>>
>> What we can do, is providing a generic PCI layer API that allows claiming
>> resources for a specific PCI bus, something similar if not identical
>> to what is done on alpha:
>>
>> arch/alpha/kernel/pci.c pcibios_claim_one_bus()
>>
>> that is not alpha specific at all. That way, we can use the API to claim
>> bus resources instead of assigning them on PCI_PROBE_ONLY (I *think*
>> that alpha calls pci_assign_unassigned_resources() even if
>> PCI_PROBE_ONLY is set, it should be safe since resources are claimed
>> first so IIUC the PCI layer would revert to FW BAR configuration on
>> assignment failure).
>>
>> Bjorn, any opinion on this ? Putting together a patch is easy when
>> we agree on the solution.
>
> I would like claiming resources, i.e., pci_claim_resource(), to happen
> in the core instead of in arch code because it's not inherently
> arch-specific.  I don't think it should depend on PCI_PROBE_ONLY.
>
> Bjorn
>

Hi All,

I tested this patch series on the AMD Seattle w/o PCI_PROBE_ONLY mode 
and that works fine. However, w/ PCI_PROBE_ONLY, I also run into the 
resource not claimed issue (no surprise here).

So, I tried porting the pcibios_claim_one_bus() from 
arch/alpha/kernel/pci.c as Lorenzo suggested, plus the a small change in 
pci_claim_resource(), and it seems to work w/ PCI_PROBE_ONLY. (Please 
see example patch below.)

The additional while loop is needed in the pci_claim_resource() since I 
need to reference back to the resource in the root bus, which are 
defined from the DT node. Does this sounds like a reasonable approach?

diff --git a/drivers/pci/host/pci-host-generic.c 
b/drivers/pci/host/pci-host-generic.c
index e9cc559..0dfa23d 100644
--- a/drivers/pci/host/pci-host-generic.c
+++ b/drivers/pci/host/pci-host-generic.c
@@ -261,7 +261,10 @@ static int gen_pci_probe(struct platform_device *pdev)
  	if (!pci_has_flag(PCI_PROBE_ONLY)) {
  		pci_bus_size_bridges(bus);
  		pci_bus_assign_resources(bus);
+	} else {
+		pci_claim_one_bus(bus);
  	}
+
  	pci_bus_add_devices(bus);

  	/* Configure PCI Express settings */
diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
index 232f925..d4b43b3 100644
--- a/drivers/pci/setup-res.c
+++ b/drivers/pci/setup-res.c
@@ -109,6 +109,7 @@ int pci_claim_resource(struct pci_dev *dev, int 
resource)
  {
  	struct resource *res = &dev->resource[resource];
  	struct resource *root, *conflict;
+	struct pci_dev *pdev = dev;

  	if (res->flags & IORESOURCE_UNSET) {
  		dev_info(&dev->dev, "can't claim BAR %d %pR: no address assigned\n",
@@ -116,7 +117,18 @@ int pci_claim_resource(struct pci_dev *dev, int 
resource)
  		return -EINVAL;
  	}

-	root = pci_find_parent_resource(dev, res);
+	while (pdev) {
+		root = pci_find_parent_resource(pdev, res);
+		if (root)
+			break;
+
+		if (pci_has_flag(PCI_PROBE_ONLY) &&
+		    !pci_is_root_bus(pdev->bus))
+			pdev = pdev->bus->self;
+		else
+			break;
+	}
+
  	if (!root) {
  		dev_info(&dev->dev, "can't claim BAR %d %pR: no compatible bridge 
window\n",
  			 resource, res);
@@ -136,6 +148,36 @@ int pci_claim_resource(struct pci_dev *dev, int 
resource)
  }
  EXPORT_SYMBOL(pci_claim_resource);

+void pci_claim_one_bus(struct pci_bus *b)
+{
+	struct pci_dev *pdev;
+	struct pci_bus *child_bus;
+
+	list_for_each_entry(pdev, &b->devices, bus_list) {
+		int i;
+
+		for (i = 0; i < PCI_NUM_RESOURCES; i++) {
+			struct resource *r = &pdev->resource[i];
+
+			if (r->parent || !r->start || !r->flags)
+				continue;
+
+			if (pci_has_flag(PCI_PROBE_ONLY) ||
+			    (r->flags & IORESOURCE_PCI_FIXED)) {
+				if (pci_claim_resource(pdev, i) == 0)
+					continue;
+
+				pci_claim_bridge_resource(pdev, i);
+			}
+		}
+	}
+
+	list_for_each_entry(child_bus, &b->children, node) {
+		pci_claim_one_bus(child_bus);
+	}
+}
+EXPORT_SYMBOL(pci_claim_one_bus);
+
  void pci_disable_bridge_window(struct pci_dev *dev)
  {
  	dev_info(&dev->dev, "disabling bridge mem windows\n");
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 353db8d..b59ad4b 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1085,6 +1085,7 @@ void pci_assign_unassigned_bridge_resources(struct 
pci_dev *bridge);
  void pci_assign_unassigned_bus_resources(struct pci_bus *bus);
  void pci_assign_unassigned_root_bus_resources(struct pci_bus *bus);
  void pdev_enable_device(struct pci_dev *);
+void pci_claim_one_bus(struct pci_bus *b);
  int pci_enable_resources(struct pci_dev *, int mask);
  void pci_fixup_irqs(u8 (*)(struct pci_dev *, u8 *),
  		    int (*)(const struct pci_dev *, u8, u8));
-------- END PATCH ----

Thanks,

Suravee

^ permalink raw reply related	[flat|nested] 42+ messages in thread

* [PATCH v2 1/2] PCI: generic: remove dependency on hw_pci
  2015-05-05 15:53   ` Will Deacon
                     ` (3 preceding siblings ...)
  (?)
@ 2015-05-12  0:07   ` Jayachandran C.
  2015-05-19 23:09       ` Bjorn Helgaas
  -1 siblings, 1 reply; 42+ messages in thread
From: Jayachandran C. @ 2015-05-12  0:07 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, May 05, 2015 at 04:53:46PM +0100, Will Deacon wrote:
> On Tue, May 05, 2015 at 03:02:12AM +0100, Jayachandran C wrote:
> > The current code in pci-host-generic.c uses pci_common_init_dev()
> > from the arch/arm/ to do a part of the PCI initialization, and this
> > prevents it from being used on arm64.
> > 
> > The initialization done by pci_common_init_dev() that is really
> > needed by pci-host-generic.c can be done in the same file without
> > using the hw_pci API of ARM.
> > 
> > The ARM platform requires a pci_sys_data as sysdata for the PCI bus,
> > this is be handled by setting up 'struct gen_pci' to embed a
> > pci_sys_data variable as the first element on the ARM platform.
> > 
> > Signed-off-by: Jayachandran C <jchandra@broadcom.com>
> > ---
> > Here's v2 of the patches, this enables use of pci-host-generic on
> > arm64.
> > 
> > This has been tested on both qemu and fast model for arm64, and on
> > qemu for arm32.
> > 
> > v1->v2
> >  - Address comments from Arnd Bergmann and Lorenzo Pieralisi
> >     - move contents of gen_pci_init to gen_pci_probe
> >     - assign resources only when !probe_only
> >  - tested on ARM32 with qemu option -M virt
> 
> I tried this with an arm64 kernel running under kvmtool, but I get the
> following errors (a 32-bit ARM kernel does seem to work):
> 
>   PCI host bridge /pci ranges:
>      IO 0x00000000..0x0000ffff -> 0x00000000
>     MEM 0x41000000..0x7fffffff -> 0x41000000
>   pci-host-generic 40000000.pci: PCI host bridge to bus 0000:00
>   pci_bus 0000:00: root bus resource [bus 00-01]
>   pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
>   pci_bus 0000:00: root bus resource [mem 0x41000000-0x7fffffff]
>   pci_bus 0000:00: scanning bus
>   pci 0000:00:00.0: [1af4:1009] type 00 class 0xff0000
>   pci 0000:00:00.0: reg 0x10: [mem 0x41000000-0x410003ff]
>   pci 0000:00:00.0: reg 0x14: [io  0x6200-0x65ff]
>   pci 0000:00:00.0: reg 0x18: [mem 0x41000400-0x410005ff]
>   pci 0000:00:01.0: [1af4:1009] type 00 class 0xff0000
>   pci 0000:00:01.0: reg 0x10: [mem 0x41000800-0x41000bff]
>   pci 0000:00:01.0: reg 0x14: [io  0x6600-0x69ff]
>   pci 0000:00:01.0: reg 0x18: [mem 0x41000c00-0x41000dff]
>   pci_bus 0000:00: fixups for bus
>   pci_bus 0000:00: bus scan returning with max=00
>   pci 0000:00:00.0: fixup irq: got 10
>   pci 0000:00:00.0: assigning IRQ 10
>   pci 0000:00:01.0: fixup irq: got 11
>   pci 0000:00:01.0: assigning IRQ 11
>   virtio-pci 0000:00:00.0: can't enable device: BAR 0 [mem 0x41000000-0x410003ff] not claimed
>   virtio-pci: probe of 0000:00:00.0 failed with error -22
>   virtio-pci 0000:00:01.0: can't enable device: BAR 0 [mem 0x41000800-0x41000bff] not claimed
>   virtio-pci: probe of 0000:00:01.0 failed with error -22

PCI_PROBE_ONLY does not work yet for arm64, this will need further changes
in either arm64 or pci as noted by Lorenzo. This is not due to a problem with
this patch per se.

More importantly, this does not change the current arm32 behavior and adds
support for arm64 for two very useful cases
 - we can use "pci-host-ecam-generic" for a host bridge controller that is
   initialized by firmware, without adding a custom driver.
 - qemu virt platform works on arm64

If you think there are any furhter changes needed in this patchset please
let me know.

Thanks,
JC.

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [PATCH v2 1/2] PCI: generic: remove dependency on hw_pci
  2015-05-07  3:32         ` Suravee Suthikulanit
@ 2015-05-12 13:34           ` Bjorn Helgaas
  -1 siblings, 0 replies; 42+ messages in thread
From: Bjorn Helgaas @ 2015-05-12 13:34 UTC (permalink / raw)
  To: Suravee Suthikulanit
  Cc: Lorenzo Pieralisi, Will Deacon, Jayachandran C, linux-pci,
	linux-arm-kernel, Arnd Bergmann, Liviu Dudau, Ming Lei

On Wed, May 06, 2015 at 10:32:48PM -0500, Suravee Suthikulanit wrote:
> ...
> I tested this patch series on the AMD Seattle w/o PCI_PROBE_ONLY
> mode and that works fine. However, w/ PCI_PROBE_ONLY, I also run
> into the resource not claimed issue (no surprise here).
> 
> So, I tried porting the pcibios_claim_one_bus() from
> arch/alpha/kernel/pci.c as Lorenzo suggested, plus the a small
> change in pci_claim_resource(), and it seems to work w/
> PCI_PROBE_ONLY. (Please see example patch below.)
> 
> The additional while loop is needed in the pci_claim_resource()
> since I need to reference back to the resource in the root bus,
> which are defined from the DT node. Does this sounds like a
> reasonable approach?
> 
> diff --git a/drivers/pci/host/pci-host-generic.c
> b/drivers/pci/host/pci-host-generic.c
> index e9cc559..0dfa23d 100644
> --- a/drivers/pci/host/pci-host-generic.c
> +++ b/drivers/pci/host/pci-host-generic.c
> @@ -261,7 +261,10 @@ static int gen_pci_probe(struct platform_device *pdev)
>  	if (!pci_has_flag(PCI_PROBE_ONLY)) {
>  		pci_bus_size_bridges(bus);
>  		pci_bus_assign_resources(bus);
> +	} else {
> +		pci_claim_one_bus(bus);
>  	}
> +
>  	pci_bus_add_devices(bus);
> 
>  	/* Configure PCI Express settings */
> diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
> index 232f925..d4b43b3 100644
> --- a/drivers/pci/setup-res.c
> +++ b/drivers/pci/setup-res.c
> @@ -109,6 +109,7 @@ int pci_claim_resource(struct pci_dev *dev, int
> resource)
>  {
>  	struct resource *res = &dev->resource[resource];
>  	struct resource *root, *conflict;
> +	struct pci_dev *pdev = dev;
> 
>  	if (res->flags & IORESOURCE_UNSET) {
>  		dev_info(&dev->dev, "can't claim BAR %d %pR: no address assigned\n",
> @@ -116,7 +117,18 @@ int pci_claim_resource(struct pci_dev *dev, int
> resource)
>  		return -EINVAL;
>  	}
> 
> -	root = pci_find_parent_resource(dev, res);
> +	while (pdev) {
> +		root = pci_find_parent_resource(pdev, res);
> +		if (root)
> +			break;
> +
> +		if (pci_has_flag(PCI_PROBE_ONLY) &&
> +		    !pci_is_root_bus(pdev->bus))
> +			pdev = pdev->bus->self;
> +		else
> +			break;
> +	}

I don't understand this new loop.  Apparently you have a device BAR, and
the upstream bridge doesn't have a window that contains the BAR?  That
sounds like a problem with the upstream bridge resources.

Do you have an example that would make this more concrete, e.g., a host
bridge, P2P bridge(s), and endpoint with their resources?

> +
>  	if (!root) {
>  		dev_info(&dev->dev, "can't claim BAR %d %pR: no compatible bridge
> window\n",
>  			 resource, res);
> @@ -136,6 +148,36 @@ int pci_claim_resource(struct pci_dev *dev, int
> resource)
>  }
>  EXPORT_SYMBOL(pci_claim_resource);
> 
> +void pci_claim_one_bus(struct pci_bus *b)
> +{
> +	struct pci_dev *pdev;
> +	struct pci_bus *child_bus;
> +
> +	list_for_each_entry(pdev, &b->devices, bus_list) {
> +		int i;
> +
> +		for (i = 0; i < PCI_NUM_RESOURCES; i++) {
> +			struct resource *r = &pdev->resource[i];
> +
> +			if (r->parent || !r->start || !r->flags)
> +				continue;
> +
> +			if (pci_has_flag(PCI_PROBE_ONLY) ||
> +			    (r->flags & IORESOURCE_PCI_FIXED)) {
> +				if (pci_claim_resource(pdev, i) == 0)
> +					continue;
> +
> +				pci_claim_bridge_resource(pdev, i);
> +			}
> +		}
> +	}
> +
> +	list_for_each_entry(child_bus, &b->children, node) {
> +		pci_claim_one_bus(child_bus);
> +	}
> +}
> +EXPORT_SYMBOL(pci_claim_one_bus);

I'm not a fan of pci_claim_one_bus(), on the philosophical grounds that
claiming resources is a per-device thing, and I don't want to encourage
people to do it on a per-bus level.

I'd rather claim them somewhere in the pci_device_add() path, as s390 does
in pcibios_add_device().  In fact, I'd *like* to do it even earlier, when
we read each BAR, so we could identify invalid or unassigned BARs
immediately.

> +
>  void pci_disable_bridge_window(struct pci_dev *dev)
>  {
>  	dev_info(&dev->dev, "disabling bridge mem windows\n");
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 353db8d..b59ad4b 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -1085,6 +1085,7 @@ void
> pci_assign_unassigned_bridge_resources(struct pci_dev *bridge);
>  void pci_assign_unassigned_bus_resources(struct pci_bus *bus);
>  void pci_assign_unassigned_root_bus_resources(struct pci_bus *bus);
>  void pdev_enable_device(struct pci_dev *);
> +void pci_claim_one_bus(struct pci_bus *b);
>  int pci_enable_resources(struct pci_dev *, int mask);
>  void pci_fixup_irqs(u8 (*)(struct pci_dev *, u8 *),
>  		    int (*)(const struct pci_dev *, u8, u8));
> -------- END PATCH ----
> 
> Thanks,
> 
> Suravee
> 

^ permalink raw reply	[flat|nested] 42+ messages in thread

* [PATCH v2 1/2] PCI: generic: remove dependency on hw_pci
@ 2015-05-12 13:34           ` Bjorn Helgaas
  0 siblings, 0 replies; 42+ messages in thread
From: Bjorn Helgaas @ 2015-05-12 13:34 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, May 06, 2015 at 10:32:48PM -0500, Suravee Suthikulanit wrote:
> ...
> I tested this patch series on the AMD Seattle w/o PCI_PROBE_ONLY
> mode and that works fine. However, w/ PCI_PROBE_ONLY, I also run
> into the resource not claimed issue (no surprise here).
> 
> So, I tried porting the pcibios_claim_one_bus() from
> arch/alpha/kernel/pci.c as Lorenzo suggested, plus the a small
> change in pci_claim_resource(), and it seems to work w/
> PCI_PROBE_ONLY. (Please see example patch below.)
> 
> The additional while loop is needed in the pci_claim_resource()
> since I need to reference back to the resource in the root bus,
> which are defined from the DT node. Does this sounds like a
> reasonable approach?
> 
> diff --git a/drivers/pci/host/pci-host-generic.c
> b/drivers/pci/host/pci-host-generic.c
> index e9cc559..0dfa23d 100644
> --- a/drivers/pci/host/pci-host-generic.c
> +++ b/drivers/pci/host/pci-host-generic.c
> @@ -261,7 +261,10 @@ static int gen_pci_probe(struct platform_device *pdev)
>  	if (!pci_has_flag(PCI_PROBE_ONLY)) {
>  		pci_bus_size_bridges(bus);
>  		pci_bus_assign_resources(bus);
> +	} else {
> +		pci_claim_one_bus(bus);
>  	}
> +
>  	pci_bus_add_devices(bus);
> 
>  	/* Configure PCI Express settings */
> diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
> index 232f925..d4b43b3 100644
> --- a/drivers/pci/setup-res.c
> +++ b/drivers/pci/setup-res.c
> @@ -109,6 +109,7 @@ int pci_claim_resource(struct pci_dev *dev, int
> resource)
>  {
>  	struct resource *res = &dev->resource[resource];
>  	struct resource *root, *conflict;
> +	struct pci_dev *pdev = dev;
> 
>  	if (res->flags & IORESOURCE_UNSET) {
>  		dev_info(&dev->dev, "can't claim BAR %d %pR: no address assigned\n",
> @@ -116,7 +117,18 @@ int pci_claim_resource(struct pci_dev *dev, int
> resource)
>  		return -EINVAL;
>  	}
> 
> -	root = pci_find_parent_resource(dev, res);
> +	while (pdev) {
> +		root = pci_find_parent_resource(pdev, res);
> +		if (root)
> +			break;
> +
> +		if (pci_has_flag(PCI_PROBE_ONLY) &&
> +		    !pci_is_root_bus(pdev->bus))
> +			pdev = pdev->bus->self;
> +		else
> +			break;
> +	}

I don't understand this new loop.  Apparently you have a device BAR, and
the upstream bridge doesn't have a window that contains the BAR?  That
sounds like a problem with the upstream bridge resources.

Do you have an example that would make this more concrete, e.g., a host
bridge, P2P bridge(s), and endpoint with their resources?

> +
>  	if (!root) {
>  		dev_info(&dev->dev, "can't claim BAR %d %pR: no compatible bridge
> window\n",
>  			 resource, res);
> @@ -136,6 +148,36 @@ int pci_claim_resource(struct pci_dev *dev, int
> resource)
>  }
>  EXPORT_SYMBOL(pci_claim_resource);
> 
> +void pci_claim_one_bus(struct pci_bus *b)
> +{
> +	struct pci_dev *pdev;
> +	struct pci_bus *child_bus;
> +
> +	list_for_each_entry(pdev, &b->devices, bus_list) {
> +		int i;
> +
> +		for (i = 0; i < PCI_NUM_RESOURCES; i++) {
> +			struct resource *r = &pdev->resource[i];
> +
> +			if (r->parent || !r->start || !r->flags)
> +				continue;
> +
> +			if (pci_has_flag(PCI_PROBE_ONLY) ||
> +			    (r->flags & IORESOURCE_PCI_FIXED)) {
> +				if (pci_claim_resource(pdev, i) == 0)
> +					continue;
> +
> +				pci_claim_bridge_resource(pdev, i);
> +			}
> +		}
> +	}
> +
> +	list_for_each_entry(child_bus, &b->children, node) {
> +		pci_claim_one_bus(child_bus);
> +	}
> +}
> +EXPORT_SYMBOL(pci_claim_one_bus);

I'm not a fan of pci_claim_one_bus(), on the philosophical grounds that
claiming resources is a per-device thing, and I don't want to encourage
people to do it on a per-bus level.

I'd rather claim them somewhere in the pci_device_add() path, as s390 does
in pcibios_add_device().  In fact, I'd *like* to do it even earlier, when
we read each BAR, so we could identify invalid or unassigned BARs
immediately.

> +
>  void pci_disable_bridge_window(struct pci_dev *dev)
>  {
>  	dev_info(&dev->dev, "disabling bridge mem windows\n");
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 353db8d..b59ad4b 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -1085,6 +1085,7 @@ void
> pci_assign_unassigned_bridge_resources(struct pci_dev *bridge);
>  void pci_assign_unassigned_bus_resources(struct pci_bus *bus);
>  void pci_assign_unassigned_root_bus_resources(struct pci_bus *bus);
>  void pdev_enable_device(struct pci_dev *);
> +void pci_claim_one_bus(struct pci_bus *b);
>  int pci_enable_resources(struct pci_dev *, int mask);
>  void pci_fixup_irqs(u8 (*)(struct pci_dev *, u8 *),
>  		    int (*)(const struct pci_dev *, u8, u8));
> -------- END PATCH ----
> 
> Thanks,
> 
> Suravee
> 

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [PATCH v2 1/2] PCI: generic: remove dependency on hw_pci
  2015-05-12 13:34           ` Bjorn Helgaas
@ 2015-05-12 16:34             ` Lorenzo Pieralisi
  -1 siblings, 0 replies; 42+ messages in thread
From: Lorenzo Pieralisi @ 2015-05-12 16:34 UTC (permalink / raw)
  To: Bjorn Helgaas
  Cc: suravee.suthikulpanit, Will Deacon, Jayachandran C, linux-pci,
	linux-arm-kernel, Arnd Bergmann, Liviu Dudau, Ming Lei

On Tue, May 12, 2015 at 02:34:31PM +0100, Bjorn Helgaas wrote:

[...]

> > +void pci_claim_one_bus(struct pci_bus *b)
> > +{
> > +	struct pci_dev *pdev;
> > +	struct pci_bus *child_bus;
> > +
> > +	list_for_each_entry(pdev, &b->devices, bus_list) {
> > +		int i;
> > +
> > +		for (i = 0; i < PCI_NUM_RESOURCES; i++) {
> > +			struct resource *r = &pdev->resource[i];
> > +
> > +			if (r->parent || !r->start || !r->flags)
> > +				continue;
> > +
> > +			if (pci_has_flag(PCI_PROBE_ONLY) ||
> > +			    (r->flags & IORESOURCE_PCI_FIXED)) {
> > +				if (pci_claim_resource(pdev, i) == 0)
> > +					continue;
> > +
> > +				pci_claim_bridge_resource(pdev, i);
> > +			}
> > +		}
> > +	}
> > +
> > +	list_for_each_entry(child_bus, &b->children, node) {
> > +		pci_claim_one_bus(child_bus);
> > +	}
> > +}
> > +EXPORT_SYMBOL(pci_claim_one_bus);
> 
> I'm not a fan of pci_claim_one_bus(), on the philosophical grounds that
> claiming resources is a per-device thing, and I don't want to encourage
> people to do it on a per-bus level.
> 
> I'd rather claim them somewhere in the pci_device_add() path, as s390 does
> in pcibios_add_device().  In fact, I'd *like* to do it even earlier, when
> we read each BAR, so we could identify invalid or unassigned BARs
> immediately.

You mean claiming the resources in __pci_read_base (and unset the resource
if claiming it fails ?) regardless of PCI_PROBE_ONLY ?

I will give it a go, I fear it might trigger regressions on other archs
though.

We could claim the resources in pcibios_add_device on arm64, but this
means arm code should be patched too since I am not happy at all to let
arm and arm64 diverge even more.

Lorenzo

^ permalink raw reply	[flat|nested] 42+ messages in thread

* [PATCH v2 1/2] PCI: generic: remove dependency on hw_pci
@ 2015-05-12 16:34             ` Lorenzo Pieralisi
  0 siblings, 0 replies; 42+ messages in thread
From: Lorenzo Pieralisi @ 2015-05-12 16:34 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, May 12, 2015 at 02:34:31PM +0100, Bjorn Helgaas wrote:

[...]

> > +void pci_claim_one_bus(struct pci_bus *b)
> > +{
> > +	struct pci_dev *pdev;
> > +	struct pci_bus *child_bus;
> > +
> > +	list_for_each_entry(pdev, &b->devices, bus_list) {
> > +		int i;
> > +
> > +		for (i = 0; i < PCI_NUM_RESOURCES; i++) {
> > +			struct resource *r = &pdev->resource[i];
> > +
> > +			if (r->parent || !r->start || !r->flags)
> > +				continue;
> > +
> > +			if (pci_has_flag(PCI_PROBE_ONLY) ||
> > +			    (r->flags & IORESOURCE_PCI_FIXED)) {
> > +				if (pci_claim_resource(pdev, i) == 0)
> > +					continue;
> > +
> > +				pci_claim_bridge_resource(pdev, i);
> > +			}
> > +		}
> > +	}
> > +
> > +	list_for_each_entry(child_bus, &b->children, node) {
> > +		pci_claim_one_bus(child_bus);
> > +	}
> > +}
> > +EXPORT_SYMBOL(pci_claim_one_bus);
> 
> I'm not a fan of pci_claim_one_bus(), on the philosophical grounds that
> claiming resources is a per-device thing, and I don't want to encourage
> people to do it on a per-bus level.
> 
> I'd rather claim them somewhere in the pci_device_add() path, as s390 does
> in pcibios_add_device().  In fact, I'd *like* to do it even earlier, when
> we read each BAR, so we could identify invalid or unassigned BARs
> immediately.

You mean claiming the resources in __pci_read_base (and unset the resource
if claiming it fails ?) regardless of PCI_PROBE_ONLY ?

I will give it a go, I fear it might trigger regressions on other archs
though.

We could claim the resources in pcibios_add_device on arm64, but this
means arm code should be patched too since I am not happy at all to let
arm and arm64 diverge even more.

Lorenzo

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [PATCH v2 1/2] PCI: generic: remove dependency on hw_pci
  2015-05-12 16:34             ` Lorenzo Pieralisi
@ 2015-05-12 19:20               ` Bjorn Helgaas
  -1 siblings, 0 replies; 42+ messages in thread
From: Bjorn Helgaas @ 2015-05-12 19:20 UTC (permalink / raw)
  To: Lorenzo Pieralisi
  Cc: suravee.suthikulpanit, Will Deacon, Jayachandran C, linux-pci,
	linux-arm-kernel, Arnd Bergmann, Liviu Dudau, Ming Lei

On Tue, May 12, 2015 at 11:34 AM, Lorenzo Pieralisi
<lorenzo.pieralisi@arm.com> wrote:
> On Tue, May 12, 2015 at 02:34:31PM +0100, Bjorn Helgaas wrote:
>
> [...]
>
>> > +void pci_claim_one_bus(struct pci_bus *b)
>> > +{
>> > +   struct pci_dev *pdev;
>> > +   struct pci_bus *child_bus;
>> > +
>> > +   list_for_each_entry(pdev, &b->devices, bus_list) {
>> > +           int i;
>> > +
>> > +           for (i = 0; i < PCI_NUM_RESOURCES; i++) {
>> > +                   struct resource *r = &pdev->resource[i];
>> > +
>> > +                   if (r->parent || !r->start || !r->flags)
>> > +                           continue;
>> > +
>> > +                   if (pci_has_flag(PCI_PROBE_ONLY) ||
>> > +                       (r->flags & IORESOURCE_PCI_FIXED)) {
>> > +                           if (pci_claim_resource(pdev, i) == 0)
>> > +                                   continue;
>> > +
>> > +                           pci_claim_bridge_resource(pdev, i);
>> > +                   }
>> > +           }
>> > +   }
>> > +
>> > +   list_for_each_entry(child_bus, &b->children, node) {
>> > +           pci_claim_one_bus(child_bus);
>> > +   }
>> > +}
>> > +EXPORT_SYMBOL(pci_claim_one_bus);
>>
>> I'm not a fan of pci_claim_one_bus(), on the philosophical grounds that
>> claiming resources is a per-device thing, and I don't want to encourage
>> people to do it on a per-bus level.
>>
>> I'd rather claim them somewhere in the pci_device_add() path, as s390 does
>> in pcibios_add_device().  In fact, I'd *like* to do it even earlier, when
>> we read each BAR, so we could identify invalid or unassigned BARs
>> immediately.
>
> You mean claiming the resources in __pci_read_base (and unset the resource
> if claiming it fails ?) regardless of PCI_PROBE_ONLY ?

That's what I'm thinking, but only in the long term.  I doubt we're
ready to go that far yet.  I was thinking more along the lines of just
getting it uniformly into the core first, maybe even incrementally,
and only after that moving it around inside the core.

I don't think it would work right now because I think we read device
BARs before we read the apertures of the upstream bridge.

> We could claim the resources in pcibios_add_device on arm64, but this
> means arm code should be patched too since I am not happy at all to let
> arm and arm64 diverge even more.

I agree, it'd be nice to have arm and arm64 be similar, but from my
point of view, they wouldn't have to be changed at the same time.  To
me, they just look like two different arches.

Bjorn

^ permalink raw reply	[flat|nested] 42+ messages in thread

* [PATCH v2 1/2] PCI: generic: remove dependency on hw_pci
@ 2015-05-12 19:20               ` Bjorn Helgaas
  0 siblings, 0 replies; 42+ messages in thread
From: Bjorn Helgaas @ 2015-05-12 19:20 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, May 12, 2015 at 11:34 AM, Lorenzo Pieralisi
<lorenzo.pieralisi@arm.com> wrote:
> On Tue, May 12, 2015 at 02:34:31PM +0100, Bjorn Helgaas wrote:
>
> [...]
>
>> > +void pci_claim_one_bus(struct pci_bus *b)
>> > +{
>> > +   struct pci_dev *pdev;
>> > +   struct pci_bus *child_bus;
>> > +
>> > +   list_for_each_entry(pdev, &b->devices, bus_list) {
>> > +           int i;
>> > +
>> > +           for (i = 0; i < PCI_NUM_RESOURCES; i++) {
>> > +                   struct resource *r = &pdev->resource[i];
>> > +
>> > +                   if (r->parent || !r->start || !r->flags)
>> > +                           continue;
>> > +
>> > +                   if (pci_has_flag(PCI_PROBE_ONLY) ||
>> > +                       (r->flags & IORESOURCE_PCI_FIXED)) {
>> > +                           if (pci_claim_resource(pdev, i) == 0)
>> > +                                   continue;
>> > +
>> > +                           pci_claim_bridge_resource(pdev, i);
>> > +                   }
>> > +           }
>> > +   }
>> > +
>> > +   list_for_each_entry(child_bus, &b->children, node) {
>> > +           pci_claim_one_bus(child_bus);
>> > +   }
>> > +}
>> > +EXPORT_SYMBOL(pci_claim_one_bus);
>>
>> I'm not a fan of pci_claim_one_bus(), on the philosophical grounds that
>> claiming resources is a per-device thing, and I don't want to encourage
>> people to do it on a per-bus level.
>>
>> I'd rather claim them somewhere in the pci_device_add() path, as s390 does
>> in pcibios_add_device().  In fact, I'd *like* to do it even earlier, when
>> we read each BAR, so we could identify invalid or unassigned BARs
>> immediately.
>
> You mean claiming the resources in __pci_read_base (and unset the resource
> if claiming it fails ?) regardless of PCI_PROBE_ONLY ?

That's what I'm thinking, but only in the long term.  I doubt we're
ready to go that far yet.  I was thinking more along the lines of just
getting it uniformly into the core first, maybe even incrementally,
and only after that moving it around inside the core.

I don't think it would work right now because I think we read device
BARs before we read the apertures of the upstream bridge.

> We could claim the resources in pcibios_add_device on arm64, but this
> means arm code should be patched too since I am not happy at all to let
> arm and arm64 diverge even more.

I agree, it'd be nice to have arm and arm64 be similar, but from my
point of view, they wouldn't have to be changed at the same time.  To
me, they just look like two different arches.

Bjorn

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [PATCH v2 1/2] PCI: generic: remove dependency on hw_pci
  2015-05-07  3:32         ` Suravee Suthikulanit
@ 2015-05-13 12:47           ` Suravee Suthikulanit
  -1 siblings, 0 replies; 42+ messages in thread
From: Suravee Suthikulanit @ 2015-05-13 12:47 UTC (permalink / raw)
  To: Bjorn Helgaas, Lorenzo Pieralisi
  Cc: Will Deacon, Jayachandran C, linux-pci, linux-arm-kernel,
	Arnd Bergmann, Liviu Dudau, Ming Lei

Hi Bjorn,

Somehow, I didn't get your reply email from the ML. So, I've captured 
your questions here, please see my reply below.

On 5/6/2015 10:32 PM, Suravee Suthikulanit wrote:
> Hi All,
>
> I tested this patch series on the AMD Seattle w/o PCI_PROBE_ONLY mode
> and that works fine. However, w/ PCI_PROBE_ONLY, I also run into the
> resource not claimed issue (no surprise here).
>
> So, I tried porting the pcibios_claim_one_bus() from
> arch/alpha/kernel/pci.c as Lorenzo suggested, plus the a small change in
> pci_claim_resource(), and it seems to work w/ PCI_PROBE_ONLY. (Please
> see example patch below.)
>
> The additional while loop is needed in the pci_claim_resource() since I
> need to reference back to the resource in the root bus, which are
> defined from the DT node. Does this sounds like a reasonable approach?
>
> diff --git a/drivers/pci/host/pci-host-generic.c
> b/drivers/pci/host/pci-host-generic.c
> index e9cc559..0dfa23d 100644
> --- a/drivers/pci/host/pci-host-generic.c
> +++ b/drivers/pci/host/pci-host-generic.c
> @@ -261,7 +261,10 @@ static int gen_pci_probe(struct platform_device *pdev)
>       if (!pci_has_flag(PCI_PROBE_ONLY)) {
>           pci_bus_size_bridges(bus);
>           pci_bus_assign_resources(bus);
> +    } else {
> +        pci_claim_one_bus(bus);
>       }
> +
>       pci_bus_add_devices(bus);
>
>       /* Configure PCI Express settings */
> diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
> index 232f925..d4b43b3 100644
> --- a/drivers/pci/setup-res.c
> +++ b/drivers/pci/setup-res.c
> @@ -109,6 +109,7 @@ int pci_claim_resource(struct pci_dev *dev, int
> resource)
>   {
>       struct resource *res = &dev->resource[resource];
>       struct resource *root, *conflict;
> +    struct pci_dev *pdev = dev;
>
>       if (res->flags & IORESOURCE_UNSET) {
>           dev_info(&dev->dev, "can't claim BAR %d %pR: no address
> assigned\n",
> @@ -116,7 +117,18 @@ int pci_claim_resource(struct pci_dev *dev, int
> resource)
>           return -EINVAL;
>       }
>
> -    root = pci_find_parent_resource(dev, res);
> +    while (pdev) {
> +        root = pci_find_parent_resource(pdev, res);
> +        if (root)
> +            break;
> +
> +        if (pci_has_flag(PCI_PROBE_ONLY) &&
> +            !pci_is_root_bus(pdev->bus))
> +            pdev = pdev->bus->self;
> +        else
> +            break;
> +    }
> +
>       if (!root) {
>           dev_info(&dev->dev, "can't claim BAR %d %pR: no compatible
> bridge window\n",
>                resource, res);


[From Bjorn]
I don't understand this new loop.  Apparently you have a device BAR, and
the upstream bridge doesn't have a window that contains the BAR?  That
sounds like a problem with the upstream bridge resources.

Do you have an example that would make this more concrete, e.g., a host
bridge, P2P bridge(s), and endpoint with their resources?

[Suravee]
Here is the information you were asking for. This information is setup 
from the FW. In the PCI bridge (00:02.1), I see the prefetchable memory 
behind bridge is already setup.

OUTPUT from lspci -tv:

-[0000:00]-+-00.0  Advanced Micro Devices, Inc. [AMD] Device 1a00
            +-02.0  Advanced Micro Devices, Inc. [AMD] Device 1a01
            \-02.1  PCI Bridge -[01]--+-00.0  Intel Corporation 82599ES 
10-Gigabit SFI/SFP+ Network Connection
                         \-00.1  Intel Corporation 82599ES 10-Gigabit 
SFI/SFP+ Network Connection

OUTPUT from lspci -vvv:

00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 1a00
	Subsystem: Advanced Micro Devices, Inc. [AMD] Device 1a00
	Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- 
<MAbort- >SERR- <PERR- INTx-
	Latency: 0

00:02.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 1a01
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- 
<MAbort- >SERR- <PERR- INTx-

00:02.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 1a02 
(prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- 
<MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
	I/O behind bridge: 00fff000-00000fff
	Memory behind bridge: fff00000-000fffff
	Prefetchable memory behind bridge: 0000007fffe00000-0000007fffffffff
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- 
<MAbort+ <SERR- <PERR-
	BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
.......

01:00.0 Ethernet controller: Intel Corporation 82599ES 10-Gigabit 
SFI/SFP+ Network Connection (rev 01)
	Subsystem: Intel Corporation Ethernet Server Adapter X520-2
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- 
<MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 46
	Region 0: Memory at 7fffe80000 (64-bit, prefetchable) [size=512K]
	Region 2: I/O ports at 0020 [size=32]
	Region 4: Memory at 7ffff04000 (64-bit, prefetchable) [size=16K]
.......

01:00.1 Ethernet controller: Intel Corporation 82599ES 10-Gigabit 
SFI/SFP+ Network Connection (rev 01)
	Subsystem: Intel Corporation Ethernet Server Adapter X520-2
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- 
<MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin B routed to IRQ 47
	Region 0: Memory at 7fffe00000 (64-bit, prefetchable) [size=512K]
	Region 2: I/O ports at 0000 [size=32]
	Region 4: Memory at 7ffff00000 (64-bit, prefetchable) [size=16K]
........

Thanks,
Suravee


^ permalink raw reply	[flat|nested] 42+ messages in thread

* [PATCH v2 1/2] PCI: generic: remove dependency on hw_pci
@ 2015-05-13 12:47           ` Suravee Suthikulanit
  0 siblings, 0 replies; 42+ messages in thread
From: Suravee Suthikulanit @ 2015-05-13 12:47 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Bjorn,

Somehow, I didn't get your reply email from the ML. So, I've captured 
your questions here, please see my reply below.

On 5/6/2015 10:32 PM, Suravee Suthikulanit wrote:
> Hi All,
>
> I tested this patch series on the AMD Seattle w/o PCI_PROBE_ONLY mode
> and that works fine. However, w/ PCI_PROBE_ONLY, I also run into the
> resource not claimed issue (no surprise here).
>
> So, I tried porting the pcibios_claim_one_bus() from
> arch/alpha/kernel/pci.c as Lorenzo suggested, plus the a small change in
> pci_claim_resource(), and it seems to work w/ PCI_PROBE_ONLY. (Please
> see example patch below.)
>
> The additional while loop is needed in the pci_claim_resource() since I
> need to reference back to the resource in the root bus, which are
> defined from the DT node. Does this sounds like a reasonable approach?
>
> diff --git a/drivers/pci/host/pci-host-generic.c
> b/drivers/pci/host/pci-host-generic.c
> index e9cc559..0dfa23d 100644
> --- a/drivers/pci/host/pci-host-generic.c
> +++ b/drivers/pci/host/pci-host-generic.c
> @@ -261,7 +261,10 @@ static int gen_pci_probe(struct platform_device *pdev)
>       if (!pci_has_flag(PCI_PROBE_ONLY)) {
>           pci_bus_size_bridges(bus);
>           pci_bus_assign_resources(bus);
> +    } else {
> +        pci_claim_one_bus(bus);
>       }
> +
>       pci_bus_add_devices(bus);
>
>       /* Configure PCI Express settings */
> diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
> index 232f925..d4b43b3 100644
> --- a/drivers/pci/setup-res.c
> +++ b/drivers/pci/setup-res.c
> @@ -109,6 +109,7 @@ int pci_claim_resource(struct pci_dev *dev, int
> resource)
>   {
>       struct resource *res = &dev->resource[resource];
>       struct resource *root, *conflict;
> +    struct pci_dev *pdev = dev;
>
>       if (res->flags & IORESOURCE_UNSET) {
>           dev_info(&dev->dev, "can't claim BAR %d %pR: no address
> assigned\n",
> @@ -116,7 +117,18 @@ int pci_claim_resource(struct pci_dev *dev, int
> resource)
>           return -EINVAL;
>       }
>
> -    root = pci_find_parent_resource(dev, res);
> +    while (pdev) {
> +        root = pci_find_parent_resource(pdev, res);
> +        if (root)
> +            break;
> +
> +        if (pci_has_flag(PCI_PROBE_ONLY) &&
> +            !pci_is_root_bus(pdev->bus))
> +            pdev = pdev->bus->self;
> +        else
> +            break;
> +    }
> +
>       if (!root) {
>           dev_info(&dev->dev, "can't claim BAR %d %pR: no compatible
> bridge window\n",
>                resource, res);


[From Bjorn]
I don't understand this new loop.  Apparently you have a device BAR, and
the upstream bridge doesn't have a window that contains the BAR?  That
sounds like a problem with the upstream bridge resources.

Do you have an example that would make this more concrete, e.g., a host
bridge, P2P bridge(s), and endpoint with their resources?

[Suravee]
Here is the information you were asking for. This information is setup 
from the FW. In the PCI bridge (00:02.1), I see the prefetchable memory 
behind bridge is already setup.

OUTPUT from lspci -tv:

-[0000:00]-+-00.0  Advanced Micro Devices, Inc. [AMD] Device 1a00
            +-02.0  Advanced Micro Devices, Inc. [AMD] Device 1a01
            \-02.1  PCI Bridge -[01]--+-00.0  Intel Corporation 82599ES 
10-Gigabit SFI/SFP+ Network Connection
                         \-00.1  Intel Corporation 82599ES 10-Gigabit 
SFI/SFP+ Network Connection

OUTPUT from lspci -vvv:

00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 1a00
	Subsystem: Advanced Micro Devices, Inc. [AMD] Device 1a00
	Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- 
<MAbort- >SERR- <PERR- INTx-
	Latency: 0

00:02.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 1a01
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- 
<MAbort- >SERR- <PERR- INTx-

00:02.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 1a02 
(prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- 
<MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
	I/O behind bridge: 00fff000-00000fff
	Memory behind bridge: fff00000-000fffff
	Prefetchable memory behind bridge: 0000007fffe00000-0000007fffffffff
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- 
<MAbort+ <SERR- <PERR-
	BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
.......

01:00.0 Ethernet controller: Intel Corporation 82599ES 10-Gigabit 
SFI/SFP+ Network Connection (rev 01)
	Subsystem: Intel Corporation Ethernet Server Adapter X520-2
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- 
<MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 46
	Region 0: Memory at 7fffe80000 (64-bit, prefetchable) [size=512K]
	Region 2: I/O ports at 0020 [size=32]
	Region 4: Memory@7ffff04000 (64-bit, prefetchable) [size=16K]
.......

01:00.1 Ethernet controller: Intel Corporation 82599ES 10-Gigabit 
SFI/SFP+ Network Connection (rev 01)
	Subsystem: Intel Corporation Ethernet Server Adapter X520-2
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- 
<MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin B routed to IRQ 47
	Region 0: Memory at 7fffe00000 (64-bit, prefetchable) [size=512K]
	Region 2: I/O ports at 0000 [size=32]
	Region 4: Memory@7ffff00000 (64-bit, prefetchable) [size=16K]
........

Thanks,
Suravee

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [PATCH v2 1/2] PCI: generic: remove dependency on hw_pci
  2015-05-13 12:47           ` Suravee Suthikulanit
@ 2015-05-13 13:54             ` Bjorn Helgaas
  -1 siblings, 0 replies; 42+ messages in thread
From: Bjorn Helgaas @ 2015-05-13 13:54 UTC (permalink / raw)
  To: Suravee Suthikulanit
  Cc: Lorenzo Pieralisi, Will Deacon, Jayachandran C, linux-pci,
	linux-arm-kernel, Arnd Bergmann, Liviu Dudau, Ming Lei

Hi Suravee,

On Wed, May 13, 2015 at 07:47:42AM -0500, Suravee Suthikulanit wrote:
> On 5/6/2015 10:32 PM, Suravee Suthikulanit wrote:
> >I tested this patch series on the AMD Seattle w/o PCI_PROBE_ONLY mode
> >and that works fine. However, w/ PCI_PROBE_ONLY, I also run into the
> >resource not claimed issue (no surprise here).
> >
> >So, I tried porting the pcibios_claim_one_bus() from
> >arch/alpha/kernel/pci.c as Lorenzo suggested, plus the a small change in
> >pci_claim_resource(), and it seems to work w/ PCI_PROBE_ONLY. (Please
> >see example patch below.)
> >
> >The additional while loop is needed in the pci_claim_resource() since I
> >need to reference back to the resource in the root bus, which are
> >defined from the DT node. Does this sounds like a reasonable approach?
> >
> >diff --git a/drivers/pci/host/pci-host-generic.c
> >b/drivers/pci/host/pci-host-generic.c
> >index e9cc559..0dfa23d 100644
> >--- a/drivers/pci/host/pci-host-generic.c
> >+++ b/drivers/pci/host/pci-host-generic.c
> >@@ -261,7 +261,10 @@ static int gen_pci_probe(struct platform_device *pdev)
> >      if (!pci_has_flag(PCI_PROBE_ONLY)) {
> >          pci_bus_size_bridges(bus);
> >          pci_bus_assign_resources(bus);
> >+    } else {
> >+        pci_claim_one_bus(bus);
> >      }
> >+
> >      pci_bus_add_devices(bus);
> >
> >      /* Configure PCI Express settings */
> >diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
> >index 232f925..d4b43b3 100644
> >--- a/drivers/pci/setup-res.c
> >+++ b/drivers/pci/setup-res.c
> >@@ -109,6 +109,7 @@ int pci_claim_resource(struct pci_dev *dev, int
> >resource)
> >  {
> >      struct resource *res = &dev->resource[resource];
> >      struct resource *root, *conflict;
> >+    struct pci_dev *pdev = dev;
> >
> >      if (res->flags & IORESOURCE_UNSET) {
> >          dev_info(&dev->dev, "can't claim BAR %d %pR: no address
> >assigned\n",
> >@@ -116,7 +117,18 @@ int pci_claim_resource(struct pci_dev *dev, int
> >resource)
> >          return -EINVAL;
> >      }
> >
> >-    root = pci_find_parent_resource(dev, res);
> >+    while (pdev) {
> >+        root = pci_find_parent_resource(pdev, res);
> >+        if (root)
> >+            break;
> >+
> >+        if (pci_has_flag(PCI_PROBE_ONLY) &&
> >+            !pci_is_root_bus(pdev->bus))
> >+            pdev = pdev->bus->self;
> >+        else
> >+            break;
> >+    }
> >+
> >      if (!root) {
> >          dev_info(&dev->dev, "can't claim BAR %d %pR: no compatible
> >bridge window\n",
> >               resource, res);
> 
> 
> [From Bjorn]
> I don't understand this new loop.  Apparently you have a device BAR, and
> the upstream bridge doesn't have a window that contains the BAR?  That
> sounds like a problem with the upstream bridge resources.
> 
> Do you have an example that would make this more concrete, e.g., a host
> bridge, P2P bridge(s), and endpoint with their resources?
> 
> [Suravee]
> Here is the information you were asking for. This information is
> setup from the FW. In the PCI bridge (00:02.1), I see the
> prefetchable memory behind bridge is already setup.

Here's a summary:

  00:02.1: PCI bridge to [bus 01]
  00:02.1:   [io window disabled]
  00:02.1:   [mem window disabled]
  00:02.1:   bridge window [mem 0x7f_ffe0_0000-0x7f_ffff_ffff 64bit pref]
  01:00.0: BAR 0: [mem 0x7f_ffe8_0000-0x... 64bit pref]
  01:00.0: BAR 2: [io  0x0020-0x3f]
  01:00.0: BAR 4: [mem 0x7f_fff0_4000-0x... 64bit pref]

So I guess the new loop would be for the I/O resource because the
00:02.1 I/O window is disabled?  This definitely seems like a problem --
we should enable that I/O window so we can claim the 01:00.0 I/O
resource with the 00:02.1 I/O window as the parent.  We don't want the
parent to be the host bridge window.  In fact, unless we enable that
I/O window, the 01:00.0 I/O BAR won't even work!

It may be that the driver for 01:00.0 doesn't need the I/O BAR.  We
can leave the bridge I/O window disabled and let pci_claim_resource()
fail, which means we'll treat the 01:00.0 I/O BAR as unassigned.
That's all fine; we'll never turn on PCI_COMMAND_IO, and as long as
the driver doesn't request I/O space, everything should just work.
Note that the driver would have to use pci_enable_device_mem() to
tell us that it doesn't need I/O space.

> OUTPUT from lspci -tv:
> 
> -[0000:00]-+-00.0  Advanced Micro Devices, Inc. [AMD] Device 1a00
>            +-02.0  Advanced Micro Devices, Inc. [AMD] Device 1a01
>            \-02.1  PCI Bridge -[01]--+-00.0  Intel Corporation
> 82599ES 10-Gigabit SFI/SFP+ Network Connection
>                         \-00.1  Intel Corporation 82599ES 10-Gigabit
> SFI/SFP+ Network Connection
> 
> OUTPUT from lspci -vvv:
> 
> 00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 1a00
> 	Subsystem: Advanced Micro Devices, Inc. [AMD] Device 1a00
> 	Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR- FastB2B- DisINTx-
> 	Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR- INTx-
> 	Latency: 0
> 
> 00:02.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 1a01
> 	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR- FastB2B- DisINTx-
> 	Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR- INTx-
> 
> 00:02.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 1a02
> (prog-if 00 [Normal decode])
> 	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR- FastB2B- DisINTx-
> 	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR- INTx-
> 	Latency: 0
> 	Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
> 	I/O behind bridge: 00fff000-00000fff
> 	Memory behind bridge: fff00000-000fffff
> 	Prefetchable memory behind bridge: 0000007fffe00000-0000007fffffffff
> 	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort+ <SERR- <PERR-
> 	BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
> 		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
> .......
> 
> 01:00.0 Ethernet controller: Intel Corporation 82599ES 10-Gigabit
> SFI/SFP+ Network Connection (rev 01)
> 	Subsystem: Intel Corporation Ethernet Server Adapter X520-2
> 	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR- FastB2B- DisINTx+
> 	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR- INTx-
> 	Latency: 0
> 	Interrupt: pin A routed to IRQ 46
> 	Region 0: Memory at 7fffe80000 (64-bit, prefetchable) [size=512K]
> 	Region 2: I/O ports at 0020 [size=32]
> 	Region 4: Memory at 7ffff04000 (64-bit, prefetchable) [size=16K]
> .......
> 
> 01:00.1 Ethernet controller: Intel Corporation 82599ES 10-Gigabit
> SFI/SFP+ Network Connection (rev 01)
> 	Subsystem: Intel Corporation Ethernet Server Adapter X520-2
> 	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR- FastB2B- DisINTx+
> 	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR- INTx-
> 	Latency: 0
> 	Interrupt: pin B routed to IRQ 47
> 	Region 0: Memory at 7fffe00000 (64-bit, prefetchable) [size=512K]
> 	Region 2: I/O ports at 0000 [size=32]
> 	Region 4: Memory at 7ffff00000 (64-bit, prefetchable) [size=16K]
> ........
> 
> Thanks,
> Suravee
> 

^ permalink raw reply	[flat|nested] 42+ messages in thread

* [PATCH v2 1/2] PCI: generic: remove dependency on hw_pci
@ 2015-05-13 13:54             ` Bjorn Helgaas
  0 siblings, 0 replies; 42+ messages in thread
From: Bjorn Helgaas @ 2015-05-13 13:54 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Suravee,

On Wed, May 13, 2015 at 07:47:42AM -0500, Suravee Suthikulanit wrote:
> On 5/6/2015 10:32 PM, Suravee Suthikulanit wrote:
> >I tested this patch series on the AMD Seattle w/o PCI_PROBE_ONLY mode
> >and that works fine. However, w/ PCI_PROBE_ONLY, I also run into the
> >resource not claimed issue (no surprise here).
> >
> >So, I tried porting the pcibios_claim_one_bus() from
> >arch/alpha/kernel/pci.c as Lorenzo suggested, plus the a small change in
> >pci_claim_resource(), and it seems to work w/ PCI_PROBE_ONLY. (Please
> >see example patch below.)
> >
> >The additional while loop is needed in the pci_claim_resource() since I
> >need to reference back to the resource in the root bus, which are
> >defined from the DT node. Does this sounds like a reasonable approach?
> >
> >diff --git a/drivers/pci/host/pci-host-generic.c
> >b/drivers/pci/host/pci-host-generic.c
> >index e9cc559..0dfa23d 100644
> >--- a/drivers/pci/host/pci-host-generic.c
> >+++ b/drivers/pci/host/pci-host-generic.c
> >@@ -261,7 +261,10 @@ static int gen_pci_probe(struct platform_device *pdev)
> >      if (!pci_has_flag(PCI_PROBE_ONLY)) {
> >          pci_bus_size_bridges(bus);
> >          pci_bus_assign_resources(bus);
> >+    } else {
> >+        pci_claim_one_bus(bus);
> >      }
> >+
> >      pci_bus_add_devices(bus);
> >
> >      /* Configure PCI Express settings */
> >diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
> >index 232f925..d4b43b3 100644
> >--- a/drivers/pci/setup-res.c
> >+++ b/drivers/pci/setup-res.c
> >@@ -109,6 +109,7 @@ int pci_claim_resource(struct pci_dev *dev, int
> >resource)
> >  {
> >      struct resource *res = &dev->resource[resource];
> >      struct resource *root, *conflict;
> >+    struct pci_dev *pdev = dev;
> >
> >      if (res->flags & IORESOURCE_UNSET) {
> >          dev_info(&dev->dev, "can't claim BAR %d %pR: no address
> >assigned\n",
> >@@ -116,7 +117,18 @@ int pci_claim_resource(struct pci_dev *dev, int
> >resource)
> >          return -EINVAL;
> >      }
> >
> >-    root = pci_find_parent_resource(dev, res);
> >+    while (pdev) {
> >+        root = pci_find_parent_resource(pdev, res);
> >+        if (root)
> >+            break;
> >+
> >+        if (pci_has_flag(PCI_PROBE_ONLY) &&
> >+            !pci_is_root_bus(pdev->bus))
> >+            pdev = pdev->bus->self;
> >+        else
> >+            break;
> >+    }
> >+
> >      if (!root) {
> >          dev_info(&dev->dev, "can't claim BAR %d %pR: no compatible
> >bridge window\n",
> >               resource, res);
> 
> 
> [From Bjorn]
> I don't understand this new loop.  Apparently you have a device BAR, and
> the upstream bridge doesn't have a window that contains the BAR?  That
> sounds like a problem with the upstream bridge resources.
> 
> Do you have an example that would make this more concrete, e.g., a host
> bridge, P2P bridge(s), and endpoint with their resources?
> 
> [Suravee]
> Here is the information you were asking for. This information is
> setup from the FW. In the PCI bridge (00:02.1), I see the
> prefetchable memory behind bridge is already setup.

Here's a summary:

  00:02.1: PCI bridge to [bus 01]
  00:02.1:   [io window disabled]
  00:02.1:   [mem window disabled]
  00:02.1:   bridge window [mem 0x7f_ffe0_0000-0x7f_ffff_ffff 64bit pref]
  01:00.0: BAR 0: [mem 0x7f_ffe8_0000-0x... 64bit pref]
  01:00.0: BAR 2: [io  0x0020-0x3f]
  01:00.0: BAR 4: [mem 0x7f_fff0_4000-0x... 64bit pref]

So I guess the new loop would be for the I/O resource because the
00:02.1 I/O window is disabled?  This definitely seems like a problem --
we should enable that I/O window so we can claim the 01:00.0 I/O
resource with the 00:02.1 I/O window as the parent.  We don't want the
parent to be the host bridge window.  In fact, unless we enable that
I/O window, the 01:00.0 I/O BAR won't even work!

It may be that the driver for 01:00.0 doesn't need the I/O BAR.  We
can leave the bridge I/O window disabled and let pci_claim_resource()
fail, which means we'll treat the 01:00.0 I/O BAR as unassigned.
That's all fine; we'll never turn on PCI_COMMAND_IO, and as long as
the driver doesn't request I/O space, everything should just work.
Note that the driver would have to use pci_enable_device_mem() to
tell us that it doesn't need I/O space.

> OUTPUT from lspci -tv:
> 
> -[0000:00]-+-00.0  Advanced Micro Devices, Inc. [AMD] Device 1a00
>            +-02.0  Advanced Micro Devices, Inc. [AMD] Device 1a01
>            \-02.1  PCI Bridge -[01]--+-00.0  Intel Corporation
> 82599ES 10-Gigabit SFI/SFP+ Network Connection
>                         \-00.1  Intel Corporation 82599ES 10-Gigabit
> SFI/SFP+ Network Connection
> 
> OUTPUT from lspci -vvv:
> 
> 00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 1a00
> 	Subsystem: Advanced Micro Devices, Inc. [AMD] Device 1a00
> 	Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR- FastB2B- DisINTx-
> 	Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR- INTx-
> 	Latency: 0
> 
> 00:02.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 1a01
> 	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR- FastB2B- DisINTx-
> 	Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR- INTx-
> 
> 00:02.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 1a02
> (prog-if 00 [Normal decode])
> 	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR- FastB2B- DisINTx-
> 	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR- INTx-
> 	Latency: 0
> 	Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
> 	I/O behind bridge: 00fff000-00000fff
> 	Memory behind bridge: fff00000-000fffff
> 	Prefetchable memory behind bridge: 0000007fffe00000-0000007fffffffff
> 	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort+ <SERR- <PERR-
> 	BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
> 		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
> .......
> 
> 01:00.0 Ethernet controller: Intel Corporation 82599ES 10-Gigabit
> SFI/SFP+ Network Connection (rev 01)
> 	Subsystem: Intel Corporation Ethernet Server Adapter X520-2
> 	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR- FastB2B- DisINTx+
> 	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR- INTx-
> 	Latency: 0
> 	Interrupt: pin A routed to IRQ 46
> 	Region 0: Memory at 7fffe80000 (64-bit, prefetchable) [size=512K]
> 	Region 2: I/O ports at 0020 [size=32]
> 	Region 4: Memory at 7ffff04000 (64-bit, prefetchable) [size=16K]
> .......
> 
> 01:00.1 Ethernet controller: Intel Corporation 82599ES 10-Gigabit
> SFI/SFP+ Network Connection (rev 01)
> 	Subsystem: Intel Corporation Ethernet Server Adapter X520-2
> 	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR- FastB2B- DisINTx+
> 	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
> <TAbort- <MAbort- >SERR- <PERR- INTx-
> 	Latency: 0
> 	Interrupt: pin B routed to IRQ 47
> 	Region 0: Memory at 7fffe00000 (64-bit, prefetchable) [size=512K]
> 	Region 2: I/O ports at 0000 [size=32]
> 	Region 4: Memory at 7ffff00000 (64-bit, prefetchable) [size=16K]
> ........
> 
> Thanks,
> Suravee
> 

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [PATCH v2 1/2] PCI: generic: remove dependency on hw_pci
  2015-05-13 13:54             ` Bjorn Helgaas
@ 2015-05-13 15:05               ` Suravee Suthikulanit
  -1 siblings, 0 replies; 42+ messages in thread
From: Suravee Suthikulanit @ 2015-05-13 15:05 UTC (permalink / raw)
  To: Bjorn Helgaas
  Cc: Lorenzo Pieralisi, Will Deacon, Jayachandran C, linux-pci,
	linux-arm-kernel, Arnd Bergmann, Liviu Dudau, Ming Lei

On 5/13/2015 8:54 AM, Bjorn Helgaas wrote:
> Hi Suravee,
>
> On Wed, May 13, 2015 at 07:47:42AM -0500, Suravee Suthikulanit wrote:
>> On 5/6/2015 10:32 PM, Suravee Suthikulanit wrote:
>>> I tested this patch series on the AMD Seattle w/o PCI_PROBE_ONLY mode
>>> and that works fine. However, w/ PCI_PROBE_ONLY, I also run into the
>>> resource not claimed issue (no surprise here).
>>>
>>> So, I tried porting the pcibios_claim_one_bus() from
>>> arch/alpha/kernel/pci.c as Lorenzo suggested, plus the a small change in
>>> pci_claim_resource(), and it seems to work w/ PCI_PROBE_ONLY. (Please
>>> see example patch below.)
>>>
>>> The additional while loop is needed in the pci_claim_resource() since I
>>> need to reference back to the resource in the root bus, which are
>>> defined from the DT node. Does this sounds like a reasonable approach?
>>>
>>> diff --git a/drivers/pci/host/pci-host-generic.c
>>> b/drivers/pci/host/pci-host-generic.c
>>> index e9cc559..0dfa23d 100644
>>> --- a/drivers/pci/host/pci-host-generic.c
>>> +++ b/drivers/pci/host/pci-host-generic.c
>>> @@ -261,7 +261,10 @@ static int gen_pci_probe(struct platform_device *pdev)
>>>       if (!pci_has_flag(PCI_PROBE_ONLY)) {
>>>           pci_bus_size_bridges(bus);
>>>           pci_bus_assign_resources(bus);
>>> +    } else {
>>> +        pci_claim_one_bus(bus);
>>>       }
>>> +
>>>       pci_bus_add_devices(bus);
>>>
>>>       /* Configure PCI Express settings */
>>> diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
>>> index 232f925..d4b43b3 100644
>>> --- a/drivers/pci/setup-res.c
>>> +++ b/drivers/pci/setup-res.c
>>> @@ -109,6 +109,7 @@ int pci_claim_resource(struct pci_dev *dev, int
>>> resource)
>>>   {
>>>       struct resource *res = &dev->resource[resource];
>>>       struct resource *root, *conflict;
>>> +    struct pci_dev *pdev = dev;
>>>
>>>       if (res->flags & IORESOURCE_UNSET) {
>>>           dev_info(&dev->dev, "can't claim BAR %d %pR: no address
>>> assigned\n",
>>> @@ -116,7 +117,18 @@ int pci_claim_resource(struct pci_dev *dev, int
>>> resource)
>>>           return -EINVAL;
>>>       }
>>>
>>> -    root = pci_find_parent_resource(dev, res);
>>> +    while (pdev) {
>>> +        root = pci_find_parent_resource(pdev, res);
>>> +        if (root)
>>> +            break;
>>> +
>>> +        if (pci_has_flag(PCI_PROBE_ONLY) &&
>>> +            !pci_is_root_bus(pdev->bus))
>>> +            pdev = pdev->bus->self;
>>> +        else
>>> +            break;
>>> +    }
>>> +
>>>       if (!root) {
>>>           dev_info(&dev->dev, "can't claim BAR %d %pR: no compatible
>>> bridge window\n",
>>>                resource, res);
>>
>>
>> [From Bjorn]
>> I don't understand this new loop.  Apparently you have a device BAR, and
>> the upstream bridge doesn't have a window that contains the BAR?  That
>> sounds like a problem with the upstream bridge resources.
>>
>> Do you have an example that would make this more concrete, e.g., a host
>> bridge, P2P bridge(s), and endpoint with their resources?
>>
>> [Suravee]
>> Here is the information you were asking for. This information is
>> setup from the FW. In the PCI bridge (00:02.1), I see the
>> prefetchable memory behind bridge is already setup.
>
> Here's a summary:
>
>    00:02.1: PCI bridge to [bus 01]
>    00:02.1:   [io window disabled]
>    00:02.1:   [mem window disabled]
>    00:02.1:   bridge window [mem 0x7f_ffe0_0000-0x7f_ffff_ffff 64bit pref]
>    01:00.0: BAR 0: [mem 0x7f_ffe8_0000-0x... 64bit pref]
>    01:00.0: BAR 2: [io  0x0020-0x3f]
>    01:00.0: BAR 4: [mem 0x7f_fff0_4000-0x... 64bit pref]
>
> So I guess the new loop would be for the I/O resource because the
> 00:02.1 I/O window is disabled?  This definitely seems like a problem --
> we should enable that I/O window so we can claim the 01:00.0 I/O
> resource with the 00:02.1 I/O window as the parent.  We don't want the
> parent to be the host bridge window.  In fact, unless we enable that
> I/O window, the 01:00.0 I/O BAR won't even work!
>
> It may be that the driver for 01:00.0 doesn't need the I/O BAR.  We
> can leave the bridge I/O window disabled and let pci_claim_resource()
> fail, which means we'll treat the 01:00.0 I/O BAR as unassigned.
> That's all fine; we'll never turn on PCI_COMMAND_IO, and as long as
> the driver doesn't request I/O space, everything should just work.
> Note that the driver would have to use pci_enable_device_mem() to
> tell us that it doesn't need I/O space.
>

I see your point on the I/O window. Let me double check the FW why this 
is getting setup this way. My guess is that the I/O windows are not used 
by ARM64 systems, therefore the FW disabled it at the bridge.

However, the loop is mainly to recursively search for parent resource 
for the 64bit pref resource of device 1:00.0 when calling 
pci_claim_one_bus() on PROBE_ONLY. It doesn't seem to find compatible 
bridge windows in the parent bridge (0:2.1), and I was not sure if that 
is where the device is supposed to be claiming from.

Since you mentioned in a separate reply in this thread that we might not 
want to be using pci_claim_one_bus(), I guess we probably should drop 
this approach for now.

Thanks,
Suravee


^ permalink raw reply	[flat|nested] 42+ messages in thread

* [PATCH v2 1/2] PCI: generic: remove dependency on hw_pci
@ 2015-05-13 15:05               ` Suravee Suthikulanit
  0 siblings, 0 replies; 42+ messages in thread
From: Suravee Suthikulanit @ 2015-05-13 15:05 UTC (permalink / raw)
  To: linux-arm-kernel

On 5/13/2015 8:54 AM, Bjorn Helgaas wrote:
> Hi Suravee,
>
> On Wed, May 13, 2015 at 07:47:42AM -0500, Suravee Suthikulanit wrote:
>> On 5/6/2015 10:32 PM, Suravee Suthikulanit wrote:
>>> I tested this patch series on the AMD Seattle w/o PCI_PROBE_ONLY mode
>>> and that works fine. However, w/ PCI_PROBE_ONLY, I also run into the
>>> resource not claimed issue (no surprise here).
>>>
>>> So, I tried porting the pcibios_claim_one_bus() from
>>> arch/alpha/kernel/pci.c as Lorenzo suggested, plus the a small change in
>>> pci_claim_resource(), and it seems to work w/ PCI_PROBE_ONLY. (Please
>>> see example patch below.)
>>>
>>> The additional while loop is needed in the pci_claim_resource() since I
>>> need to reference back to the resource in the root bus, which are
>>> defined from the DT node. Does this sounds like a reasonable approach?
>>>
>>> diff --git a/drivers/pci/host/pci-host-generic.c
>>> b/drivers/pci/host/pci-host-generic.c
>>> index e9cc559..0dfa23d 100644
>>> --- a/drivers/pci/host/pci-host-generic.c
>>> +++ b/drivers/pci/host/pci-host-generic.c
>>> @@ -261,7 +261,10 @@ static int gen_pci_probe(struct platform_device *pdev)
>>>       if (!pci_has_flag(PCI_PROBE_ONLY)) {
>>>           pci_bus_size_bridges(bus);
>>>           pci_bus_assign_resources(bus);
>>> +    } else {
>>> +        pci_claim_one_bus(bus);
>>>       }
>>> +
>>>       pci_bus_add_devices(bus);
>>>
>>>       /* Configure PCI Express settings */
>>> diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
>>> index 232f925..d4b43b3 100644
>>> --- a/drivers/pci/setup-res.c
>>> +++ b/drivers/pci/setup-res.c
>>> @@ -109,6 +109,7 @@ int pci_claim_resource(struct pci_dev *dev, int
>>> resource)
>>>   {
>>>       struct resource *res = &dev->resource[resource];
>>>       struct resource *root, *conflict;
>>> +    struct pci_dev *pdev = dev;
>>>
>>>       if (res->flags & IORESOURCE_UNSET) {
>>>           dev_info(&dev->dev, "can't claim BAR %d %pR: no address
>>> assigned\n",
>>> @@ -116,7 +117,18 @@ int pci_claim_resource(struct pci_dev *dev, int
>>> resource)
>>>           return -EINVAL;
>>>       }
>>>
>>> -    root = pci_find_parent_resource(dev, res);
>>> +    while (pdev) {
>>> +        root = pci_find_parent_resource(pdev, res);
>>> +        if (root)
>>> +            break;
>>> +
>>> +        if (pci_has_flag(PCI_PROBE_ONLY) &&
>>> +            !pci_is_root_bus(pdev->bus))
>>> +            pdev = pdev->bus->self;
>>> +        else
>>> +            break;
>>> +    }
>>> +
>>>       if (!root) {
>>>           dev_info(&dev->dev, "can't claim BAR %d %pR: no compatible
>>> bridge window\n",
>>>                resource, res);
>>
>>
>> [From Bjorn]
>> I don't understand this new loop.  Apparently you have a device BAR, and
>> the upstream bridge doesn't have a window that contains the BAR?  That
>> sounds like a problem with the upstream bridge resources.
>>
>> Do you have an example that would make this more concrete, e.g., a host
>> bridge, P2P bridge(s), and endpoint with their resources?
>>
>> [Suravee]
>> Here is the information you were asking for. This information is
>> setup from the FW. In the PCI bridge (00:02.1), I see the
>> prefetchable memory behind bridge is already setup.
>
> Here's a summary:
>
>    00:02.1: PCI bridge to [bus 01]
>    00:02.1:   [io window disabled]
>    00:02.1:   [mem window disabled]
>    00:02.1:   bridge window [mem 0x7f_ffe0_0000-0x7f_ffff_ffff 64bit pref]
>    01:00.0: BAR 0: [mem 0x7f_ffe8_0000-0x... 64bit pref]
>    01:00.0: BAR 2: [io  0x0020-0x3f]
>    01:00.0: BAR 4: [mem 0x7f_fff0_4000-0x... 64bit pref]
>
> So I guess the new loop would be for the I/O resource because the
> 00:02.1 I/O window is disabled?  This definitely seems like a problem --
> we should enable that I/O window so we can claim the 01:00.0 I/O
> resource with the 00:02.1 I/O window as the parent.  We don't want the
> parent to be the host bridge window.  In fact, unless we enable that
> I/O window, the 01:00.0 I/O BAR won't even work!
>
> It may be that the driver for 01:00.0 doesn't need the I/O BAR.  We
> can leave the bridge I/O window disabled and let pci_claim_resource()
> fail, which means we'll treat the 01:00.0 I/O BAR as unassigned.
> That's all fine; we'll never turn on PCI_COMMAND_IO, and as long as
> the driver doesn't request I/O space, everything should just work.
> Note that the driver would have to use pci_enable_device_mem() to
> tell us that it doesn't need I/O space.
>

I see your point on the I/O window. Let me double check the FW why this 
is getting setup this way. My guess is that the I/O windows are not used 
by ARM64 systems, therefore the FW disabled it at the bridge.

However, the loop is mainly to recursively search for parent resource 
for the 64bit pref resource of device 1:00.0 when calling 
pci_claim_one_bus() on PROBE_ONLY. It doesn't seem to find compatible 
bridge windows in the parent bridge (0:2.1), and I was not sure if that 
is where the device is supposed to be claiming from.

Since you mentioned in a separate reply in this thread that we might not 
want to be using pci_claim_one_bus(), I guess we probably should drop 
this approach for now.

Thanks,
Suravee

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [PATCH v2 1/2] PCI: generic: remove dependency on hw_pci
  2015-05-13 15:05               ` Suravee Suthikulanit
@ 2015-05-13 15:11                 ` Bjorn Helgaas
  -1 siblings, 0 replies; 42+ messages in thread
From: Bjorn Helgaas @ 2015-05-13 15:11 UTC (permalink / raw)
  To: Suravee Suthikulanit
  Cc: Lorenzo Pieralisi, Will Deacon, Jayachandran C, linux-pci,
	linux-arm-kernel, Arnd Bergmann, Liviu Dudau, Ming Lei

On Wed, May 13, 2015 at 10:05:23AM -0500, Suravee Suthikulanit wrote:
> On 5/13/2015 8:54 AM, Bjorn Helgaas wrote:
> >Hi Suravee,
> >
> >On Wed, May 13, 2015 at 07:47:42AM -0500, Suravee Suthikulanit wrote:
> >>On 5/6/2015 10:32 PM, Suravee Suthikulanit wrote:
> >>>I tested this patch series on the AMD Seattle w/o PCI_PROBE_ONLY mode
> >>>and that works fine. However, w/ PCI_PROBE_ONLY, I also run into the
> >>>resource not claimed issue (no surprise here).
> >>>
> >>>So, I tried porting the pcibios_claim_one_bus() from
> >>>arch/alpha/kernel/pci.c as Lorenzo suggested, plus the a small change in
> >>>pci_claim_resource(), and it seems to work w/ PCI_PROBE_ONLY. (Please
> >>>see example patch below.)
> >>>
> >>>The additional while loop is needed in the pci_claim_resource() since I
> >>>need to reference back to the resource in the root bus, which are
> >>>defined from the DT node. Does this sounds like a reasonable approach?
> >>>
> >>>diff --git a/drivers/pci/host/pci-host-generic.c
> >>>b/drivers/pci/host/pci-host-generic.c
> >>>index e9cc559..0dfa23d 100644
> >>>--- a/drivers/pci/host/pci-host-generic.c
> >>>+++ b/drivers/pci/host/pci-host-generic.c
> >>>@@ -261,7 +261,10 @@ static int gen_pci_probe(struct platform_device *pdev)
> >>>      if (!pci_has_flag(PCI_PROBE_ONLY)) {
> >>>          pci_bus_size_bridges(bus);
> >>>          pci_bus_assign_resources(bus);
> >>>+    } else {
> >>>+        pci_claim_one_bus(bus);
> >>>      }
> >>>+
> >>>      pci_bus_add_devices(bus);
> >>>
> >>>      /* Configure PCI Express settings */
> >>>diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
> >>>index 232f925..d4b43b3 100644
> >>>--- a/drivers/pci/setup-res.c
> >>>+++ b/drivers/pci/setup-res.c
> >>>@@ -109,6 +109,7 @@ int pci_claim_resource(struct pci_dev *dev, int
> >>>resource)
> >>>  {
> >>>      struct resource *res = &dev->resource[resource];
> >>>      struct resource *root, *conflict;
> >>>+    struct pci_dev *pdev = dev;
> >>>
> >>>      if (res->flags & IORESOURCE_UNSET) {
> >>>          dev_info(&dev->dev, "can't claim BAR %d %pR: no address
> >>>assigned\n",
> >>>@@ -116,7 +117,18 @@ int pci_claim_resource(struct pci_dev *dev, int
> >>>resource)
> >>>          return -EINVAL;
> >>>      }
> >>>
> >>>-    root = pci_find_parent_resource(dev, res);
> >>>+    while (pdev) {
> >>>+        root = pci_find_parent_resource(pdev, res);
> >>>+        if (root)
> >>>+            break;
> >>>+
> >>>+        if (pci_has_flag(PCI_PROBE_ONLY) &&
> >>>+            !pci_is_root_bus(pdev->bus))
> >>>+            pdev = pdev->bus->self;
> >>>+        else
> >>>+            break;
> >>>+    }
> >>>+
> >>>      if (!root) {
> >>>          dev_info(&dev->dev, "can't claim BAR %d %pR: no compatible
> >>>bridge window\n",
> >>>               resource, res);
> >>
> >>
> >>[From Bjorn]
> >>I don't understand this new loop.  Apparently you have a device BAR, and
> >>the upstream bridge doesn't have a window that contains the BAR?  That
> >>sounds like a problem with the upstream bridge resources.
> >>
> >>Do you have an example that would make this more concrete, e.g., a host
> >>bridge, P2P bridge(s), and endpoint with their resources?
> >>
> >>[Suravee]
> >>Here is the information you were asking for. This information is
> >>setup from the FW. In the PCI bridge (00:02.1), I see the
> >>prefetchable memory behind bridge is already setup.
> >
> >Here's a summary:
> >
> >   00:02.1: PCI bridge to [bus 01]
> >   00:02.1:   [io window disabled]
> >   00:02.1:   [mem window disabled]
> >   00:02.1:   bridge window [mem 0x7f_ffe0_0000-0x7f_ffff_ffff 64bit pref]
> >   01:00.0: BAR 0: [mem 0x7f_ffe8_0000-0x... 64bit pref]
> >   01:00.0: BAR 2: [io  0x0020-0x3f]
> >   01:00.0: BAR 4: [mem 0x7f_fff0_4000-0x... 64bit pref]
> >
> >So I guess the new loop would be for the I/O resource because the
> >00:02.1 I/O window is disabled?  This definitely seems like a problem --
> >we should enable that I/O window so we can claim the 01:00.0 I/O
> >resource with the 00:02.1 I/O window as the parent.  We don't want the
> >parent to be the host bridge window.  In fact, unless we enable that
> >I/O window, the 01:00.0 I/O BAR won't even work!
> >
> >It may be that the driver for 01:00.0 doesn't need the I/O BAR.  We
> >can leave the bridge I/O window disabled and let pci_claim_resource()
> >fail, which means we'll treat the 01:00.0 I/O BAR as unassigned.
> >That's all fine; we'll never turn on PCI_COMMAND_IO, and as long as
> >the driver doesn't request I/O space, everything should just work.
> >Note that the driver would have to use pci_enable_device_mem() to
> >tell us that it doesn't need I/O space.
> >
> 
> I see your point on the I/O window. Let me double check the FW why
> this is getting setup this way. My guess is that the I/O windows are
> not used by ARM64 systems, therefore the FW disabled it at the
> bridge.
> 
> However, the loop is mainly to recursively search for parent
> resource for the 64bit pref resource of device 1:00.0 when calling
> pci_claim_one_bus() on PROBE_ONLY. It doesn't seem to find
> compatible bridge windows in the parent bridge (0:2.1), and I was
> not sure if that is where the device is supposed to be claiming
> from.

An endpoint should claim resources from its immediate upstream bridge.
There's no point in claiming a resource from the top-level bridge if a
bridge in the middle doesn't forward that resource down the the endpoint.

Bjorn

^ permalink raw reply	[flat|nested] 42+ messages in thread

* [PATCH v2 1/2] PCI: generic: remove dependency on hw_pci
@ 2015-05-13 15:11                 ` Bjorn Helgaas
  0 siblings, 0 replies; 42+ messages in thread
From: Bjorn Helgaas @ 2015-05-13 15:11 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, May 13, 2015 at 10:05:23AM -0500, Suravee Suthikulanit wrote:
> On 5/13/2015 8:54 AM, Bjorn Helgaas wrote:
> >Hi Suravee,
> >
> >On Wed, May 13, 2015 at 07:47:42AM -0500, Suravee Suthikulanit wrote:
> >>On 5/6/2015 10:32 PM, Suravee Suthikulanit wrote:
> >>>I tested this patch series on the AMD Seattle w/o PCI_PROBE_ONLY mode
> >>>and that works fine. However, w/ PCI_PROBE_ONLY, I also run into the
> >>>resource not claimed issue (no surprise here).
> >>>
> >>>So, I tried porting the pcibios_claim_one_bus() from
> >>>arch/alpha/kernel/pci.c as Lorenzo suggested, plus the a small change in
> >>>pci_claim_resource(), and it seems to work w/ PCI_PROBE_ONLY. (Please
> >>>see example patch below.)
> >>>
> >>>The additional while loop is needed in the pci_claim_resource() since I
> >>>need to reference back to the resource in the root bus, which are
> >>>defined from the DT node. Does this sounds like a reasonable approach?
> >>>
> >>>diff --git a/drivers/pci/host/pci-host-generic.c
> >>>b/drivers/pci/host/pci-host-generic.c
> >>>index e9cc559..0dfa23d 100644
> >>>--- a/drivers/pci/host/pci-host-generic.c
> >>>+++ b/drivers/pci/host/pci-host-generic.c
> >>>@@ -261,7 +261,10 @@ static int gen_pci_probe(struct platform_device *pdev)
> >>>      if (!pci_has_flag(PCI_PROBE_ONLY)) {
> >>>          pci_bus_size_bridges(bus);
> >>>          pci_bus_assign_resources(bus);
> >>>+    } else {
> >>>+        pci_claim_one_bus(bus);
> >>>      }
> >>>+
> >>>      pci_bus_add_devices(bus);
> >>>
> >>>      /* Configure PCI Express settings */
> >>>diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
> >>>index 232f925..d4b43b3 100644
> >>>--- a/drivers/pci/setup-res.c
> >>>+++ b/drivers/pci/setup-res.c
> >>>@@ -109,6 +109,7 @@ int pci_claim_resource(struct pci_dev *dev, int
> >>>resource)
> >>>  {
> >>>      struct resource *res = &dev->resource[resource];
> >>>      struct resource *root, *conflict;
> >>>+    struct pci_dev *pdev = dev;
> >>>
> >>>      if (res->flags & IORESOURCE_UNSET) {
> >>>          dev_info(&dev->dev, "can't claim BAR %d %pR: no address
> >>>assigned\n",
> >>>@@ -116,7 +117,18 @@ int pci_claim_resource(struct pci_dev *dev, int
> >>>resource)
> >>>          return -EINVAL;
> >>>      }
> >>>
> >>>-    root = pci_find_parent_resource(dev, res);
> >>>+    while (pdev) {
> >>>+        root = pci_find_parent_resource(pdev, res);
> >>>+        if (root)
> >>>+            break;
> >>>+
> >>>+        if (pci_has_flag(PCI_PROBE_ONLY) &&
> >>>+            !pci_is_root_bus(pdev->bus))
> >>>+            pdev = pdev->bus->self;
> >>>+        else
> >>>+            break;
> >>>+    }
> >>>+
> >>>      if (!root) {
> >>>          dev_info(&dev->dev, "can't claim BAR %d %pR: no compatible
> >>>bridge window\n",
> >>>               resource, res);
> >>
> >>
> >>[From Bjorn]
> >>I don't understand this new loop.  Apparently you have a device BAR, and
> >>the upstream bridge doesn't have a window that contains the BAR?  That
> >>sounds like a problem with the upstream bridge resources.
> >>
> >>Do you have an example that would make this more concrete, e.g., a host
> >>bridge, P2P bridge(s), and endpoint with their resources?
> >>
> >>[Suravee]
> >>Here is the information you were asking for. This information is
> >>setup from the FW. In the PCI bridge (00:02.1), I see the
> >>prefetchable memory behind bridge is already setup.
> >
> >Here's a summary:
> >
> >   00:02.1: PCI bridge to [bus 01]
> >   00:02.1:   [io window disabled]
> >   00:02.1:   [mem window disabled]
> >   00:02.1:   bridge window [mem 0x7f_ffe0_0000-0x7f_ffff_ffff 64bit pref]
> >   01:00.0: BAR 0: [mem 0x7f_ffe8_0000-0x... 64bit pref]
> >   01:00.0: BAR 2: [io  0x0020-0x3f]
> >   01:00.0: BAR 4: [mem 0x7f_fff0_4000-0x... 64bit pref]
> >
> >So I guess the new loop would be for the I/O resource because the
> >00:02.1 I/O window is disabled?  This definitely seems like a problem --
> >we should enable that I/O window so we can claim the 01:00.0 I/O
> >resource with the 00:02.1 I/O window as the parent.  We don't want the
> >parent to be the host bridge window.  In fact, unless we enable that
> >I/O window, the 01:00.0 I/O BAR won't even work!
> >
> >It may be that the driver for 01:00.0 doesn't need the I/O BAR.  We
> >can leave the bridge I/O window disabled and let pci_claim_resource()
> >fail, which means we'll treat the 01:00.0 I/O BAR as unassigned.
> >That's all fine; we'll never turn on PCI_COMMAND_IO, and as long as
> >the driver doesn't request I/O space, everything should just work.
> >Note that the driver would have to use pci_enable_device_mem() to
> >tell us that it doesn't need I/O space.
> >
> 
> I see your point on the I/O window. Let me double check the FW why
> this is getting setup this way. My guess is that the I/O windows are
> not used by ARM64 systems, therefore the FW disabled it at the
> bridge.
> 
> However, the loop is mainly to recursively search for parent
> resource for the 64bit pref resource of device 1:00.0 when calling
> pci_claim_one_bus() on PROBE_ONLY. It doesn't seem to find
> compatible bridge windows in the parent bridge (0:2.1), and I was
> not sure if that is where the device is supposed to be claiming
> from.

An endpoint should claim resources from its immediate upstream bridge.
There's no point in claiming a resource from the top-level bridge if a
bridge in the middle doesn't forward that resource down the the endpoint.

Bjorn

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [PATCH v2 1/2] PCI: generic: remove dependency on hw_pci
  2015-05-12  0:07   ` Jayachandran C.
@ 2015-05-19 23:09       ` Bjorn Helgaas
  0 siblings, 0 replies; 42+ messages in thread
From: Bjorn Helgaas @ 2015-05-19 23:09 UTC (permalink / raw)
  To: Jayachandran C.
  Cc: Will Deacon, linux-pci, linux-arm-kernel, Arnd Bergmann,
	Lorenzo Pieralisi, Liviu Dudau, suravee.suthikulpanit, Ming Lei

On Tue, May 12, 2015 at 05:37:47AM +0530, Jayachandran C. wrote:
> On Tue, May 05, 2015 at 04:53:46PM +0100, Will Deacon wrote:
> > On Tue, May 05, 2015 at 03:02:12AM +0100, Jayachandran C wrote:
> > > The current code in pci-host-generic.c uses pci_common_init_dev()
> > > from the arch/arm/ to do a part of the PCI initialization, and this
> > > prevents it from being used on arm64.
> > > 
> > > The initialization done by pci_common_init_dev() that is really
> > > needed by pci-host-generic.c can be done in the same file without
> > > using the hw_pci API of ARM.
> > > 
> > > The ARM platform requires a pci_sys_data as sysdata for the PCI bus,
> > > this is be handled by setting up 'struct gen_pci' to embed a
> > > pci_sys_data variable as the first element on the ARM platform.
> > > 
> > > Signed-off-by: Jayachandran C <jchandra@broadcom.com>
> > > ---
> > > Here's v2 of the patches, this enables use of pci-host-generic on
> > > arm64.
> > > 
> > > This has been tested on both qemu and fast model for arm64, and on
> > > qemu for arm32.
> > > 
> > > v1->v2
> > >  - Address comments from Arnd Bergmann and Lorenzo Pieralisi
> > >     - move contents of gen_pci_init to gen_pci_probe
> > >     - assign resources only when !probe_only
> > >  - tested on ARM32 with qemu option -M virt
> > 
> > I tried this with an arm64 kernel running under kvmtool, but I get the
> > following errors (a 32-bit ARM kernel does seem to work):
> > 
> >   PCI host bridge /pci ranges:
> >      IO 0x00000000..0x0000ffff -> 0x00000000
> >     MEM 0x41000000..0x7fffffff -> 0x41000000
> >   pci-host-generic 40000000.pci: PCI host bridge to bus 0000:00
> >   pci_bus 0000:00: root bus resource [bus 00-01]
> >   pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
> >   pci_bus 0000:00: root bus resource [mem 0x41000000-0x7fffffff]
> >   pci_bus 0000:00: scanning bus
> >   pci 0000:00:00.0: [1af4:1009] type 00 class 0xff0000
> >   pci 0000:00:00.0: reg 0x10: [mem 0x41000000-0x410003ff]
> >   pci 0000:00:00.0: reg 0x14: [io  0x6200-0x65ff]
> >   pci 0000:00:00.0: reg 0x18: [mem 0x41000400-0x410005ff]
> >   pci 0000:00:01.0: [1af4:1009] type 00 class 0xff0000
> >   pci 0000:00:01.0: reg 0x10: [mem 0x41000800-0x41000bff]
> >   pci 0000:00:01.0: reg 0x14: [io  0x6600-0x69ff]
> >   pci 0000:00:01.0: reg 0x18: [mem 0x41000c00-0x41000dff]
> >   pci_bus 0000:00: fixups for bus
> >   pci_bus 0000:00: bus scan returning with max=00
> >   pci 0000:00:00.0: fixup irq: got 10
> >   pci 0000:00:00.0: assigning IRQ 10
> >   pci 0000:00:01.0: fixup irq: got 11
> >   pci 0000:00:01.0: assigning IRQ 11
> >   virtio-pci 0000:00:00.0: can't enable device: BAR 0 [mem 0x41000000-0x410003ff] not claimed
> >   virtio-pci: probe of 0000:00:00.0 failed with error -22
> >   virtio-pci 0000:00:01.0: can't enable device: BAR 0 [mem 0x41000800-0x41000bff] not claimed
> >   virtio-pci: probe of 0000:00:01.0 failed with error -22
> 
> PCI_PROBE_ONLY does not work yet for arm64, this will need further changes
> in either arm64 or pci as noted by Lorenzo. This is not due to a problem with
> this patch per se.
> 
> More importantly, this does not change the current arm32 behavior and adds
> support for arm64 for two very useful cases
>  - we can use "pci-host-ecam-generic" for a host bridge controller that is
>    initialized by firmware, without adding a custom driver.
>  - qemu virt platform works on arm64
> 
> If you think there are any furhter changes needed in this patchset please
> let me know.

I'm waiting for at least an ack from Will.

Bjorn

^ permalink raw reply	[flat|nested] 42+ messages in thread

* [PATCH v2 1/2] PCI: generic: remove dependency on hw_pci
@ 2015-05-19 23:09       ` Bjorn Helgaas
  0 siblings, 0 replies; 42+ messages in thread
From: Bjorn Helgaas @ 2015-05-19 23:09 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, May 12, 2015 at 05:37:47AM +0530, Jayachandran C. wrote:
> On Tue, May 05, 2015 at 04:53:46PM +0100, Will Deacon wrote:
> > On Tue, May 05, 2015 at 03:02:12AM +0100, Jayachandran C wrote:
> > > The current code in pci-host-generic.c uses pci_common_init_dev()
> > > from the arch/arm/ to do a part of the PCI initialization, and this
> > > prevents it from being used on arm64.
> > > 
> > > The initialization done by pci_common_init_dev() that is really
> > > needed by pci-host-generic.c can be done in the same file without
> > > using the hw_pci API of ARM.
> > > 
> > > The ARM platform requires a pci_sys_data as sysdata for the PCI bus,
> > > this is be handled by setting up 'struct gen_pci' to embed a
> > > pci_sys_data variable as the first element on the ARM platform.
> > > 
> > > Signed-off-by: Jayachandran C <jchandra@broadcom.com>
> > > ---
> > > Here's v2 of the patches, this enables use of pci-host-generic on
> > > arm64.
> > > 
> > > This has been tested on both qemu and fast model for arm64, and on
> > > qemu for arm32.
> > > 
> > > v1->v2
> > >  - Address comments from Arnd Bergmann and Lorenzo Pieralisi
> > >     - move contents of gen_pci_init to gen_pci_probe
> > >     - assign resources only when !probe_only
> > >  - tested on ARM32 with qemu option -M virt
> > 
> > I tried this with an arm64 kernel running under kvmtool, but I get the
> > following errors (a 32-bit ARM kernel does seem to work):
> > 
> >   PCI host bridge /pci ranges:
> >      IO 0x00000000..0x0000ffff -> 0x00000000
> >     MEM 0x41000000..0x7fffffff -> 0x41000000
> >   pci-host-generic 40000000.pci: PCI host bridge to bus 0000:00
> >   pci_bus 0000:00: root bus resource [bus 00-01]
> >   pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
> >   pci_bus 0000:00: root bus resource [mem 0x41000000-0x7fffffff]
> >   pci_bus 0000:00: scanning bus
> >   pci 0000:00:00.0: [1af4:1009] type 00 class 0xff0000
> >   pci 0000:00:00.0: reg 0x10: [mem 0x41000000-0x410003ff]
> >   pci 0000:00:00.0: reg 0x14: [io  0x6200-0x65ff]
> >   pci 0000:00:00.0: reg 0x18: [mem 0x41000400-0x410005ff]
> >   pci 0000:00:01.0: [1af4:1009] type 00 class 0xff0000
> >   pci 0000:00:01.0: reg 0x10: [mem 0x41000800-0x41000bff]
> >   pci 0000:00:01.0: reg 0x14: [io  0x6600-0x69ff]
> >   pci 0000:00:01.0: reg 0x18: [mem 0x41000c00-0x41000dff]
> >   pci_bus 0000:00: fixups for bus
> >   pci_bus 0000:00: bus scan returning with max=00
> >   pci 0000:00:00.0: fixup irq: got 10
> >   pci 0000:00:00.0: assigning IRQ 10
> >   pci 0000:00:01.0: fixup irq: got 11
> >   pci 0000:00:01.0: assigning IRQ 11
> >   virtio-pci 0000:00:00.0: can't enable device: BAR 0 [mem 0x41000000-0x410003ff] not claimed
> >   virtio-pci: probe of 0000:00:00.0 failed with error -22
> >   virtio-pci 0000:00:01.0: can't enable device: BAR 0 [mem 0x41000800-0x41000bff] not claimed
> >   virtio-pci: probe of 0000:00:01.0 failed with error -22
> 
> PCI_PROBE_ONLY does not work yet for arm64, this will need further changes
> in either arm64 or pci as noted by Lorenzo. This is not due to a problem with
> this patch per se.
> 
> More importantly, this does not change the current arm32 behavior and adds
> support for arm64 for two very useful cases
>  - we can use "pci-host-ecam-generic" for a host bridge controller that is
>    initialized by firmware, without adding a custom driver.
>  - qemu virt platform works on arm64
> 
> If you think there are any furhter changes needed in this patchset please
> let me know.

I'm waiting for at least an ack from Will.

Bjorn

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [PATCH v2 1/2] PCI: generic: remove dependency on hw_pci
  2015-05-19 23:09       ` Bjorn Helgaas
@ 2015-05-20 17:29         ` Will Deacon
  -1 siblings, 0 replies; 42+ messages in thread
From: Will Deacon @ 2015-05-20 17:29 UTC (permalink / raw)
  To: Bjorn Helgaas
  Cc: Jayachandran C.,
	linux-pci, linux-arm-kernel, Arnd Bergmann, Lorenzo Pieralisi,
	Liviu Dudau, suravee.suthikulpanit, Ming Lei

On Wed, May 20, 2015 at 12:09:18AM +0100, Bjorn Helgaas wrote:
> On Tue, May 12, 2015 at 05:37:47AM +0530, Jayachandran C. wrote:
> > On Tue, May 05, 2015 at 04:53:46PM +0100, Will Deacon wrote:
> > > On Tue, May 05, 2015 at 03:02:12AM +0100, Jayachandran C wrote:
> > > > The current code in pci-host-generic.c uses pci_common_init_dev()
> > > > from the arch/arm/ to do a part of the PCI initialization, and this
> > > > prevents it from being used on arm64.
> > > > 
> > > > The initialization done by pci_common_init_dev() that is really
> > > > needed by pci-host-generic.c can be done in the same file without
> > > > using the hw_pci API of ARM.
> > > > 
> > > > The ARM platform requires a pci_sys_data as sysdata for the PCI bus,
> > > > this is be handled by setting up 'struct gen_pci' to embed a
> > > > pci_sys_data variable as the first element on the ARM platform.
> > > > 
> > > > Signed-off-by: Jayachandran C <jchandra@broadcom.com>
> > > > ---
> > > > Here's v2 of the patches, this enables use of pci-host-generic on
> > > > arm64.
> > > > 
> > > > This has been tested on both qemu and fast model for arm64, and on
> > > > qemu for arm32.
> > > > 
> > > > v1->v2
> > > >  - Address comments from Arnd Bergmann and Lorenzo Pieralisi
> > > >     - move contents of gen_pci_init to gen_pci_probe
> > > >     - assign resources only when !probe_only
> > > >  - tested on ARM32 with qemu option -M virt
> > > 
> > > I tried this with an arm64 kernel running under kvmtool, but I get the
> > > following errors (a 32-bit ARM kernel does seem to work):
> > > 
> > >   PCI host bridge /pci ranges:
> > >      IO 0x00000000..0x0000ffff -> 0x00000000
> > >     MEM 0x41000000..0x7fffffff -> 0x41000000
> > >   pci-host-generic 40000000.pci: PCI host bridge to bus 0000:00
> > >   pci_bus 0000:00: root bus resource [bus 00-01]
> > >   pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
> > >   pci_bus 0000:00: root bus resource [mem 0x41000000-0x7fffffff]
> > >   pci_bus 0000:00: scanning bus
> > >   pci 0000:00:00.0: [1af4:1009] type 00 class 0xff0000
> > >   pci 0000:00:00.0: reg 0x10: [mem 0x41000000-0x410003ff]
> > >   pci 0000:00:00.0: reg 0x14: [io  0x6200-0x65ff]
> > >   pci 0000:00:00.0: reg 0x18: [mem 0x41000400-0x410005ff]
> > >   pci 0000:00:01.0: [1af4:1009] type 00 class 0xff0000
> > >   pci 0000:00:01.0: reg 0x10: [mem 0x41000800-0x41000bff]
> > >   pci 0000:00:01.0: reg 0x14: [io  0x6600-0x69ff]
> > >   pci 0000:00:01.0: reg 0x18: [mem 0x41000c00-0x41000dff]
> > >   pci_bus 0000:00: fixups for bus
> > >   pci_bus 0000:00: bus scan returning with max=00
> > >   pci 0000:00:00.0: fixup irq: got 10
> > >   pci 0000:00:00.0: assigning IRQ 10
> > >   pci 0000:00:01.0: fixup irq: got 11
> > >   pci 0000:00:01.0: assigning IRQ 11
> > >   virtio-pci 0000:00:00.0: can't enable device: BAR 0 [mem 0x41000000-0x410003ff] not claimed
> > >   virtio-pci: probe of 0000:00:00.0 failed with error -22
> > >   virtio-pci 0000:00:01.0: can't enable device: BAR 0 [mem 0x41000800-0x41000bff] not claimed
> > >   virtio-pci: probe of 0000:00:01.0 failed with error -22
> > 
> > PCI_PROBE_ONLY does not work yet for arm64, this will need further changes
> > in either arm64 or pci as noted by Lorenzo. This is not due to a problem with
> > this patch per se.
> > 
> > More importantly, this does not change the current arm32 behavior and adds
> > support for arm64 for two very useful cases
> >  - we can use "pci-host-ecam-generic" for a host bridge controller that is
> >    initialized by firmware, without adding a custom driver.
> >  - qemu virt platform works on arm64
> > 
> > If you think there are any furhter changes needed in this patchset please
> > let me know.
> 
> I'm waiting for at least an ack from Will.

I'm not too keen on the current state of this patch. Firstly, I'd really
like to see the PROBE_ONLY case addressed at the same time as this port
(Lorenzo and Suravee are working on this). Secondly, the hack to put
pci_sys_data as the first member of gen_pci is ugly at best and probably
makes it difficult to support MSIs on ARM.

Will

^ permalink raw reply	[flat|nested] 42+ messages in thread

* [PATCH v2 1/2] PCI: generic: remove dependency on hw_pci
@ 2015-05-20 17:29         ` Will Deacon
  0 siblings, 0 replies; 42+ messages in thread
From: Will Deacon @ 2015-05-20 17:29 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, May 20, 2015 at 12:09:18AM +0100, Bjorn Helgaas wrote:
> On Tue, May 12, 2015 at 05:37:47AM +0530, Jayachandran C. wrote:
> > On Tue, May 05, 2015 at 04:53:46PM +0100, Will Deacon wrote:
> > > On Tue, May 05, 2015 at 03:02:12AM +0100, Jayachandran C wrote:
> > > > The current code in pci-host-generic.c uses pci_common_init_dev()
> > > > from the arch/arm/ to do a part of the PCI initialization, and this
> > > > prevents it from being used on arm64.
> > > > 
> > > > The initialization done by pci_common_init_dev() that is really
> > > > needed by pci-host-generic.c can be done in the same file without
> > > > using the hw_pci API of ARM.
> > > > 
> > > > The ARM platform requires a pci_sys_data as sysdata for the PCI bus,
> > > > this is be handled by setting up 'struct gen_pci' to embed a
> > > > pci_sys_data variable as the first element on the ARM platform.
> > > > 
> > > > Signed-off-by: Jayachandran C <jchandra@broadcom.com>
> > > > ---
> > > > Here's v2 of the patches, this enables use of pci-host-generic on
> > > > arm64.
> > > > 
> > > > This has been tested on both qemu and fast model for arm64, and on
> > > > qemu for arm32.
> > > > 
> > > > v1->v2
> > > >  - Address comments from Arnd Bergmann and Lorenzo Pieralisi
> > > >     - move contents of gen_pci_init to gen_pci_probe
> > > >     - assign resources only when !probe_only
> > > >  - tested on ARM32 with qemu option -M virt
> > > 
> > > I tried this with an arm64 kernel running under kvmtool, but I get the
> > > following errors (a 32-bit ARM kernel does seem to work):
> > > 
> > >   PCI host bridge /pci ranges:
> > >      IO 0x00000000..0x0000ffff -> 0x00000000
> > >     MEM 0x41000000..0x7fffffff -> 0x41000000
> > >   pci-host-generic 40000000.pci: PCI host bridge to bus 0000:00
> > >   pci_bus 0000:00: root bus resource [bus 00-01]
> > >   pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
> > >   pci_bus 0000:00: root bus resource [mem 0x41000000-0x7fffffff]
> > >   pci_bus 0000:00: scanning bus
> > >   pci 0000:00:00.0: [1af4:1009] type 00 class 0xff0000
> > >   pci 0000:00:00.0: reg 0x10: [mem 0x41000000-0x410003ff]
> > >   pci 0000:00:00.0: reg 0x14: [io  0x6200-0x65ff]
> > >   pci 0000:00:00.0: reg 0x18: [mem 0x41000400-0x410005ff]
> > >   pci 0000:00:01.0: [1af4:1009] type 00 class 0xff0000
> > >   pci 0000:00:01.0: reg 0x10: [mem 0x41000800-0x41000bff]
> > >   pci 0000:00:01.0: reg 0x14: [io  0x6600-0x69ff]
> > >   pci 0000:00:01.0: reg 0x18: [mem 0x41000c00-0x41000dff]
> > >   pci_bus 0000:00: fixups for bus
> > >   pci_bus 0000:00: bus scan returning with max=00
> > >   pci 0000:00:00.0: fixup irq: got 10
> > >   pci 0000:00:00.0: assigning IRQ 10
> > >   pci 0000:00:01.0: fixup irq: got 11
> > >   pci 0000:00:01.0: assigning IRQ 11
> > >   virtio-pci 0000:00:00.0: can't enable device: BAR 0 [mem 0x41000000-0x410003ff] not claimed
> > >   virtio-pci: probe of 0000:00:00.0 failed with error -22
> > >   virtio-pci 0000:00:01.0: can't enable device: BAR 0 [mem 0x41000800-0x41000bff] not claimed
> > >   virtio-pci: probe of 0000:00:01.0 failed with error -22
> > 
> > PCI_PROBE_ONLY does not work yet for arm64, this will need further changes
> > in either arm64 or pci as noted by Lorenzo. This is not due to a problem with
> > this patch per se.
> > 
> > More importantly, this does not change the current arm32 behavior and adds
> > support for arm64 for two very useful cases
> >  - we can use "pci-host-ecam-generic" for a host bridge controller that is
> >    initialized by firmware, without adding a custom driver.
> >  - qemu virt platform works on arm64
> > 
> > If you think there are any furhter changes needed in this patchset please
> > let me know.
> 
> I'm waiting for at least an ack from Will.

I'm not too keen on the current state of this patch. Firstly, I'd really
like to see the PROBE_ONLY case addressed at the same time as this port
(Lorenzo and Suravee are working on this). Secondly, the hack to put
pci_sys_data as the first member of gen_pci is ugly at best and probably
makes it difficult to support MSIs on ARM.

Will

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [PATCH v2 1/2] PCI: generic: remove dependency on hw_pci
  2015-05-20 17:29         ` Will Deacon
@ 2015-05-20 20:46           ` Bjorn Helgaas
  -1 siblings, 0 replies; 42+ messages in thread
From: Bjorn Helgaas @ 2015-05-20 20:46 UTC (permalink / raw)
  To: Will Deacon
  Cc: Jayachandran C.,
	linux-pci, linux-arm-kernel, Arnd Bergmann, Lorenzo Pieralisi,
	Liviu Dudau, suravee.suthikulpanit, Ming Lei

On Wed, May 20, 2015 at 12:29 PM, Will Deacon <will.deacon@arm.com> wrote:
> On Wed, May 20, 2015 at 12:09:18AM +0100, Bjorn Helgaas wrote:
>> On Tue, May 12, 2015 at 05:37:47AM +0530, Jayachandran C. wrote:
>> > On Tue, May 05, 2015 at 04:53:46PM +0100, Will Deacon wrote:
>> > > On Tue, May 05, 2015 at 03:02:12AM +0100, Jayachandran C wrote:
>> > > > The current code in pci-host-generic.c uses pci_common_init_dev()
>> > > > from the arch/arm/ to do a part of the PCI initialization, and this
>> > > > prevents it from being used on arm64.
>> > > >
>> > > > The initialization done by pci_common_init_dev() that is really
>> > > > needed by pci-host-generic.c can be done in the same file without
>> > > > using the hw_pci API of ARM.
>> > > >
>> > > > The ARM platform requires a pci_sys_data as sysdata for the PCI bus,
>> > > > this is be handled by setting up 'struct gen_pci' to embed a
>> > > > pci_sys_data variable as the first element on the ARM platform.
>> > > >
>> > > > Signed-off-by: Jayachandran C <jchandra@broadcom.com>
>> > > > ---
>> > > > Here's v2 of the patches, this enables use of pci-host-generic on
>> > > > arm64.
>> > > >
>> > > > This has been tested on both qemu and fast model for arm64, and on
>> > > > qemu for arm32.
>> > > >
>> > > > v1->v2
>> > > >  - Address comments from Arnd Bergmann and Lorenzo Pieralisi
>> > > >     - move contents of gen_pci_init to gen_pci_probe
>> > > >     - assign resources only when !probe_only
>> > > >  - tested on ARM32 with qemu option -M virt
>> > >
>> > > I tried this with an arm64 kernel running under kvmtool, but I get the
>> > > following errors (a 32-bit ARM kernel does seem to work):
>> > >
>> > >   PCI host bridge /pci ranges:
>> > >      IO 0x00000000..0x0000ffff -> 0x00000000
>> > >     MEM 0x41000000..0x7fffffff -> 0x41000000
>> > >   pci-host-generic 40000000.pci: PCI host bridge to bus 0000:00
>> > >   pci_bus 0000:00: root bus resource [bus 00-01]
>> > >   pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
>> > >   pci_bus 0000:00: root bus resource [mem 0x41000000-0x7fffffff]
>> > >   pci_bus 0000:00: scanning bus
>> > >   pci 0000:00:00.0: [1af4:1009] type 00 class 0xff0000
>> > >   pci 0000:00:00.0: reg 0x10: [mem 0x41000000-0x410003ff]
>> > >   pci 0000:00:00.0: reg 0x14: [io  0x6200-0x65ff]
>> > >   pci 0000:00:00.0: reg 0x18: [mem 0x41000400-0x410005ff]
>> > >   pci 0000:00:01.0: [1af4:1009] type 00 class 0xff0000
>> > >   pci 0000:00:01.0: reg 0x10: [mem 0x41000800-0x41000bff]
>> > >   pci 0000:00:01.0: reg 0x14: [io  0x6600-0x69ff]
>> > >   pci 0000:00:01.0: reg 0x18: [mem 0x41000c00-0x41000dff]
>> > >   pci_bus 0000:00: fixups for bus
>> > >   pci_bus 0000:00: bus scan returning with max=00
>> > >   pci 0000:00:00.0: fixup irq: got 10
>> > >   pci 0000:00:00.0: assigning IRQ 10
>> > >   pci 0000:00:01.0: fixup irq: got 11
>> > >   pci 0000:00:01.0: assigning IRQ 11
>> > >   virtio-pci 0000:00:00.0: can't enable device: BAR 0 [mem 0x41000000-0x410003ff] not claimed
>> > >   virtio-pci: probe of 0000:00:00.0 failed with error -22
>> > >   virtio-pci 0000:00:01.0: can't enable device: BAR 0 [mem 0x41000800-0x41000bff] not claimed
>> > >   virtio-pci: probe of 0000:00:01.0 failed with error -22
>> >
>> > PCI_PROBE_ONLY does not work yet for arm64, this will need further changes
>> > in either arm64 or pci as noted by Lorenzo. This is not due to a problem with
>> > this patch per se.
>> >
>> > More importantly, this does not change the current arm32 behavior and adds
>> > support for arm64 for two very useful cases
>> >  - we can use "pci-host-ecam-generic" for a host bridge controller that is
>> >    initialized by firmware, without adding a custom driver.
>> >  - qemu virt platform works on arm64
>> >
>> > If you think there are any furhter changes needed in this patchset please
>> > let me know.
>>
>> I'm waiting for at least an ack from Will.
>
> I'm not too keen on the current state of this patch. Firstly, I'd really
> like to see the PROBE_ONLY case addressed at the same time as this port
> (Lorenzo and Suravee are working on this). Secondly, the hack to put
> pci_sys_data as the first member of gen_pci is ugly at best and probably
> makes it difficult to support MSIs on ARM.

Thanks, Will.  I'll wait for another iteration that addresses these.

Bjorn

^ permalink raw reply	[flat|nested] 42+ messages in thread

* [PATCH v2 1/2] PCI: generic: remove dependency on hw_pci
@ 2015-05-20 20:46           ` Bjorn Helgaas
  0 siblings, 0 replies; 42+ messages in thread
From: Bjorn Helgaas @ 2015-05-20 20:46 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, May 20, 2015 at 12:29 PM, Will Deacon <will.deacon@arm.com> wrote:
> On Wed, May 20, 2015 at 12:09:18AM +0100, Bjorn Helgaas wrote:
>> On Tue, May 12, 2015 at 05:37:47AM +0530, Jayachandran C. wrote:
>> > On Tue, May 05, 2015 at 04:53:46PM +0100, Will Deacon wrote:
>> > > On Tue, May 05, 2015 at 03:02:12AM +0100, Jayachandran C wrote:
>> > > > The current code in pci-host-generic.c uses pci_common_init_dev()
>> > > > from the arch/arm/ to do a part of the PCI initialization, and this
>> > > > prevents it from being used on arm64.
>> > > >
>> > > > The initialization done by pci_common_init_dev() that is really
>> > > > needed by pci-host-generic.c can be done in the same file without
>> > > > using the hw_pci API of ARM.
>> > > >
>> > > > The ARM platform requires a pci_sys_data as sysdata for the PCI bus,
>> > > > this is be handled by setting up 'struct gen_pci' to embed a
>> > > > pci_sys_data variable as the first element on the ARM platform.
>> > > >
>> > > > Signed-off-by: Jayachandran C <jchandra@broadcom.com>
>> > > > ---
>> > > > Here's v2 of the patches, this enables use of pci-host-generic on
>> > > > arm64.
>> > > >
>> > > > This has been tested on both qemu and fast model for arm64, and on
>> > > > qemu for arm32.
>> > > >
>> > > > v1->v2
>> > > >  - Address comments from Arnd Bergmann and Lorenzo Pieralisi
>> > > >     - move contents of gen_pci_init to gen_pci_probe
>> > > >     - assign resources only when !probe_only
>> > > >  - tested on ARM32 with qemu option -M virt
>> > >
>> > > I tried this with an arm64 kernel running under kvmtool, but I get the
>> > > following errors (a 32-bit ARM kernel does seem to work):
>> > >
>> > >   PCI host bridge /pci ranges:
>> > >      IO 0x00000000..0x0000ffff -> 0x00000000
>> > >     MEM 0x41000000..0x7fffffff -> 0x41000000
>> > >   pci-host-generic 40000000.pci: PCI host bridge to bus 0000:00
>> > >   pci_bus 0000:00: root bus resource [bus 00-01]
>> > >   pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
>> > >   pci_bus 0000:00: root bus resource [mem 0x41000000-0x7fffffff]
>> > >   pci_bus 0000:00: scanning bus
>> > >   pci 0000:00:00.0: [1af4:1009] type 00 class 0xff0000
>> > >   pci 0000:00:00.0: reg 0x10: [mem 0x41000000-0x410003ff]
>> > >   pci 0000:00:00.0: reg 0x14: [io  0x6200-0x65ff]
>> > >   pci 0000:00:00.0: reg 0x18: [mem 0x41000400-0x410005ff]
>> > >   pci 0000:00:01.0: [1af4:1009] type 00 class 0xff0000
>> > >   pci 0000:00:01.0: reg 0x10: [mem 0x41000800-0x41000bff]
>> > >   pci 0000:00:01.0: reg 0x14: [io  0x6600-0x69ff]
>> > >   pci 0000:00:01.0: reg 0x18: [mem 0x41000c00-0x41000dff]
>> > >   pci_bus 0000:00: fixups for bus
>> > >   pci_bus 0000:00: bus scan returning with max=00
>> > >   pci 0000:00:00.0: fixup irq: got 10
>> > >   pci 0000:00:00.0: assigning IRQ 10
>> > >   pci 0000:00:01.0: fixup irq: got 11
>> > >   pci 0000:00:01.0: assigning IRQ 11
>> > >   virtio-pci 0000:00:00.0: can't enable device: BAR 0 [mem 0x41000000-0x410003ff] not claimed
>> > >   virtio-pci: probe of 0000:00:00.0 failed with error -22
>> > >   virtio-pci 0000:00:01.0: can't enable device: BAR 0 [mem 0x41000800-0x41000bff] not claimed
>> > >   virtio-pci: probe of 0000:00:01.0 failed with error -22
>> >
>> > PCI_PROBE_ONLY does not work yet for arm64, this will need further changes
>> > in either arm64 or pci as noted by Lorenzo. This is not due to a problem with
>> > this patch per se.
>> >
>> > More importantly, this does not change the current arm32 behavior and adds
>> > support for arm64 for two very useful cases
>> >  - we can use "pci-host-ecam-generic" for a host bridge controller that is
>> >    initialized by firmware, without adding a custom driver.
>> >  - qemu virt platform works on arm64
>> >
>> > If you think there are any furhter changes needed in this patchset please
>> > let me know.
>>
>> I'm waiting for at least an ack from Will.
>
> I'm not too keen on the current state of this patch. Firstly, I'd really
> like to see the PROBE_ONLY case addressed at the same time as this port
> (Lorenzo and Suravee are working on this). Secondly, the hack to put
> pci_sys_data as the first member of gen_pci is ugly at best and probably
> makes it difficult to support MSIs on ARM.

Thanks, Will.  I'll wait for another iteration that addresses these.

Bjorn

^ permalink raw reply	[flat|nested] 42+ messages in thread

* [PATCH v2 1/2] PCI: generic: remove dependency on hw_pci
  2015-05-20 17:29         ` Will Deacon
  (?)
  (?)
@ 2015-05-21  6:37         ` Jayachandran C.
  2015-05-26  9:59             ` Will Deacon
  -1 siblings, 1 reply; 42+ messages in thread
From: Jayachandran C. @ 2015-05-21  6:37 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, May 20, 2015 at 06:29:03PM +0100, Will Deacon wrote:
> On Wed, May 20, 2015 at 12:09:18AM +0100, Bjorn Helgaas wrote:
> > On Tue, May 12, 2015 at 05:37:47AM +0530, Jayachandran C. wrote:
> > > On Tue, May 05, 2015 at 04:53:46PM +0100, Will Deacon wrote:
> > > > On Tue, May 05, 2015 at 03:02:12AM +0100, Jayachandran C wrote:
> > > > > The current code in pci-host-generic.c uses pci_common_init_dev()
> > > > > from the arch/arm/ to do a part of the PCI initialization, and this
> > > > > prevents it from being used on arm64.
> > > > > 
> > > > > The initialization done by pci_common_init_dev() that is really
> > > > > needed by pci-host-generic.c can be done in the same file without
> > > > > using the hw_pci API of ARM.
> > > > > 
> > > > > The ARM platform requires a pci_sys_data as sysdata for the PCI bus,
> > > > > this is be handled by setting up 'struct gen_pci' to embed a
> > > > > pci_sys_data variable as the first element on the ARM platform.
> > > > > 
> > > > > Signed-off-by: Jayachandran C <jchandra@broadcom.com>
> > > > > ---
> > > > > Here's v2 of the patches, this enables use of pci-host-generic on
> > > > > arm64.
> > > > > 
> > > > > This has been tested on both qemu and fast model for arm64, and on
> > > > > qemu for arm32.
> > > > > 
> > > > > v1->v2
> > > > >  - Address comments from Arnd Bergmann and Lorenzo Pieralisi
> > > > >     - move contents of gen_pci_init to gen_pci_probe
> > > > >     - assign resources only when !probe_only
> > > > >  - tested on ARM32 with qemu option -M virt
> > > > 
> > > > I tried this with an arm64 kernel running under kvmtool, but I get the
> > > > following errors (a 32-bit ARM kernel does seem to work):
> > > > 
> > > >   PCI host bridge /pci ranges:
> > > >      IO 0x00000000..0x0000ffff -> 0x00000000
> > > >     MEM 0x41000000..0x7fffffff -> 0x41000000
> > > >   pci-host-generic 40000000.pci: PCI host bridge to bus 0000:00
> > > >   pci_bus 0000:00: root bus resource [bus 00-01]
> > > >   pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
> > > >   pci_bus 0000:00: root bus resource [mem 0x41000000-0x7fffffff]
> > > >   pci_bus 0000:00: scanning bus
> > > >   pci 0000:00:00.0: [1af4:1009] type 00 class 0xff0000
> > > >   pci 0000:00:00.0: reg 0x10: [mem 0x41000000-0x410003ff]
> > > >   pci 0000:00:00.0: reg 0x14: [io  0x6200-0x65ff]
> > > >   pci 0000:00:00.0: reg 0x18: [mem 0x41000400-0x410005ff]
> > > >   pci 0000:00:01.0: [1af4:1009] type 00 class 0xff0000
> > > >   pci 0000:00:01.0: reg 0x10: [mem 0x41000800-0x41000bff]
> > > >   pci 0000:00:01.0: reg 0x14: [io  0x6600-0x69ff]
> > > >   pci 0000:00:01.0: reg 0x18: [mem 0x41000c00-0x41000dff]
> > > >   pci_bus 0000:00: fixups for bus
> > > >   pci_bus 0000:00: bus scan returning with max=00
> > > >   pci 0000:00:00.0: fixup irq: got 10
> > > >   pci 0000:00:00.0: assigning IRQ 10
> > > >   pci 0000:00:01.0: fixup irq: got 11
> > > >   pci 0000:00:01.0: assigning IRQ 11
> > > >   virtio-pci 0000:00:00.0: can't enable device: BAR 0 [mem 0x41000000-0x410003ff] not claimed
> > > >   virtio-pci: probe of 0000:00:00.0 failed with error -22
> > > >   virtio-pci 0000:00:01.0: can't enable device: BAR 0 [mem 0x41000800-0x41000bff] not claimed
> > > >   virtio-pci: probe of 0000:00:01.0 failed with error -22
> > > 
> > > PCI_PROBE_ONLY does not work yet for arm64, this will need further changes
> > > in either arm64 or pci as noted by Lorenzo. This is not due to a problem with
> > > this patch per se.
> > > 
> > > More importantly, this does not change the current arm32 behavior and adds
> > > support for arm64 for two very useful cases
> > >  - we can use "pci-host-ecam-generic" for a host bridge controller that is
> > >    initialized by firmware, without adding a custom driver.
> > >  - qemu virt platform works on arm64
> > > 
> > > If you think there are any furhter changes needed in this patchset please
> > > let me know.
> > 
> > I'm waiting for at least an ack from Will.
> 
> I'm not too keen on the current state of this patch. Firstly, I'd really
> like to see the PROBE_ONLY case addressed at the same time as this port
> (Lorenzo and Suravee are working on this).

Fixing the PROBE-ONLY for arm64 is probably unrelated to the scope of this
patch - so I would hope that we don't NACK this patch due to that issue. This
patch is very useful without PROBE-ONLY like I noted above.

> Secondly, the hack to put pci_sys_data as the first member of gen_pci is ugly
> at best

On balance, it removes the problem of using hw_pci interface which has its own
ugliness (Arnd's mail on this http://www.spinics.net/lists/linux-pci/msg40703.html)

> and probably makes it difficult to support MSIs on ARM.

Adding parsing of msi-parent and setting it up for arm32 and arm64 can be
added fairly easily to the current code, I can post an RFC patch for this.

JC.

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [PATCH v2 1/2] PCI: generic: remove dependency on hw_pci
  2015-05-21  6:37         ` Jayachandran C.
@ 2015-05-26  9:59             ` Will Deacon
  0 siblings, 0 replies; 42+ messages in thread
From: Will Deacon @ 2015-05-26  9:59 UTC (permalink / raw)
  To: Jayachandran C.
  Cc: Bjorn Helgaas, linux-pci, linux-arm-kernel, Arnd Bergmann,
	Lorenzo Pieralisi, Liviu Dudau, suravee.suthikulpanit, Ming Lei

On Thu, May 21, 2015 at 07:37:30AM +0100, Jayachandran C. wrote:
> On Wed, May 20, 2015 at 06:29:03PM +0100, Will Deacon wrote:
> > On Wed, May 20, 2015 at 12:09:18AM +0100, Bjorn Helgaas wrote:
> > > On Tue, May 12, 2015 at 05:37:47AM +0530, Jayachandran C. wrote:
> > > > On Tue, May 05, 2015 at 04:53:46PM +0100, Will Deacon wrote:
> > > > > On Tue, May 05, 2015 at 03:02:12AM +0100, Jayachandran C wrote:
> > > > > > The current code in pci-host-generic.c uses pci_common_init_dev()
> > > > > > from the arch/arm/ to do a part of the PCI initialization, and this
> > > > > > prevents it from being used on arm64.
> > > > > > 
> > > > > > The initialization done by pci_common_init_dev() that is really
> > > > > > needed by pci-host-generic.c can be done in the same file without
> > > > > > using the hw_pci API of ARM.
> > > > > > 
> > > > > > The ARM platform requires a pci_sys_data as sysdata for the PCI bus,
> > > > > > this is be handled by setting up 'struct gen_pci' to embed a
> > > > > > pci_sys_data variable as the first element on the ARM platform.
> > > > > > 
> > > > > > Signed-off-by: Jayachandran C <jchandra@broadcom.com>
> > > > > > ---
> > > > > > Here's v2 of the patches, this enables use of pci-host-generic on
> > > > > > arm64.
> > > > > > 
> > > > > > This has been tested on both qemu and fast model for arm64, and on
> > > > > > qemu for arm32.
> > > > > > 
> > > > > > v1->v2
> > > > > >  - Address comments from Arnd Bergmann and Lorenzo Pieralisi
> > > > > >     - move contents of gen_pci_init to gen_pci_probe
> > > > > >     - assign resources only when !probe_only
> > > > > >  - tested on ARM32 with qemu option -M virt
> > > > > 
> > > > > I tried this with an arm64 kernel running under kvmtool, but I get the
> > > > > following errors (a 32-bit ARM kernel does seem to work):
> > > > > 
> > > > >   PCI host bridge /pci ranges:
> > > > >      IO 0x00000000..0x0000ffff -> 0x00000000
> > > > >     MEM 0x41000000..0x7fffffff -> 0x41000000
> > > > >   pci-host-generic 40000000.pci: PCI host bridge to bus 0000:00
> > > > >   pci_bus 0000:00: root bus resource [bus 00-01]
> > > > >   pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
> > > > >   pci_bus 0000:00: root bus resource [mem 0x41000000-0x7fffffff]
> > > > >   pci_bus 0000:00: scanning bus
> > > > >   pci 0000:00:00.0: [1af4:1009] type 00 class 0xff0000
> > > > >   pci 0000:00:00.0: reg 0x10: [mem 0x41000000-0x410003ff]
> > > > >   pci 0000:00:00.0: reg 0x14: [io  0x6200-0x65ff]
> > > > >   pci 0000:00:00.0: reg 0x18: [mem 0x41000400-0x410005ff]
> > > > >   pci 0000:00:01.0: [1af4:1009] type 00 class 0xff0000
> > > > >   pci 0000:00:01.0: reg 0x10: [mem 0x41000800-0x41000bff]
> > > > >   pci 0000:00:01.0: reg 0x14: [io  0x6600-0x69ff]
> > > > >   pci 0000:00:01.0: reg 0x18: [mem 0x41000c00-0x41000dff]
> > > > >   pci_bus 0000:00: fixups for bus
> > > > >   pci_bus 0000:00: bus scan returning with max=00
> > > > >   pci 0000:00:00.0: fixup irq: got 10
> > > > >   pci 0000:00:00.0: assigning IRQ 10
> > > > >   pci 0000:00:01.0: fixup irq: got 11
> > > > >   pci 0000:00:01.0: assigning IRQ 11
> > > > >   virtio-pci 0000:00:00.0: can't enable device: BAR 0 [mem 0x41000000-0x410003ff] not claimed
> > > > >   virtio-pci: probe of 0000:00:00.0 failed with error -22
> > > > >   virtio-pci 0000:00:01.0: can't enable device: BAR 0 [mem 0x41000800-0x41000bff] not claimed
> > > > >   virtio-pci: probe of 0000:00:01.0 failed with error -22
> > > > 
> > > > PCI_PROBE_ONLY does not work yet for arm64, this will need further changes
> > > > in either arm64 or pci as noted by Lorenzo. This is not due to a problem with
> > > > this patch per se.
> > > > 
> > > > More importantly, this does not change the current arm32 behavior and adds
> > > > support for arm64 for two very useful cases
> > > >  - we can use "pci-host-ecam-generic" for a host bridge controller that is
> > > >    initialized by firmware, without adding a custom driver.
> > > >  - qemu virt platform works on arm64
> > > > 
> > > > If you think there are any furhter changes needed in this patchset please
> > > > let me know.
> > > 
> > > I'm waiting for at least an ack from Will.
> > 
> > I'm not too keen on the current state of this patch. Firstly, I'd really
> > like to see the PROBE_ONLY case addressed at the same time as this port
> > (Lorenzo and Suravee are working on this).
> 
> Fixing the PROBE-ONLY for arm64 is probably unrelated to the scope of this
> patch - so I would hope that we don't NACK this patch due to that issue. This
> patch is very useful without PROBE-ONLY like I noted above.

I'm not NACKing anything, I just don't see the benefit of merging half a
solution when the other half is in active development. Perhaps you could
review Lorenzo's patches to help things along?

> > Secondly, the hack to put pci_sys_data as the first member of gen_pci is ugly
> > at best
> 
> On balance, it removes the problem of using hw_pci interface which has its own
> ugliness (Arnd's mail on this http://www.spinics.net/lists/linux-pci/msg40703.html)

To me, that sounds like we should be disposing of the hw_pci interface
altogether and moving arch/arm/ over to the new architecture-independent
interface.

> > and probably makes it difficult to support MSIs on ARM.
> 
> Adding parsing of msi-parent and setting it up for arm32 and arm64 can be
> added fairly easily to the current code, I can post an RFC patch for this.

I think that would be a good addition to the series.

Will

^ permalink raw reply	[flat|nested] 42+ messages in thread

* [PATCH v2 1/2] PCI: generic: remove dependency on hw_pci
@ 2015-05-26  9:59             ` Will Deacon
  0 siblings, 0 replies; 42+ messages in thread
From: Will Deacon @ 2015-05-26  9:59 UTC (permalink / raw)
  To: linux-arm-kernel

On Thu, May 21, 2015 at 07:37:30AM +0100, Jayachandran C. wrote:
> On Wed, May 20, 2015 at 06:29:03PM +0100, Will Deacon wrote:
> > On Wed, May 20, 2015 at 12:09:18AM +0100, Bjorn Helgaas wrote:
> > > On Tue, May 12, 2015 at 05:37:47AM +0530, Jayachandran C. wrote:
> > > > On Tue, May 05, 2015 at 04:53:46PM +0100, Will Deacon wrote:
> > > > > On Tue, May 05, 2015 at 03:02:12AM +0100, Jayachandran C wrote:
> > > > > > The current code in pci-host-generic.c uses pci_common_init_dev()
> > > > > > from the arch/arm/ to do a part of the PCI initialization, and this
> > > > > > prevents it from being used on arm64.
> > > > > > 
> > > > > > The initialization done by pci_common_init_dev() that is really
> > > > > > needed by pci-host-generic.c can be done in the same file without
> > > > > > using the hw_pci API of ARM.
> > > > > > 
> > > > > > The ARM platform requires a pci_sys_data as sysdata for the PCI bus,
> > > > > > this is be handled by setting up 'struct gen_pci' to embed a
> > > > > > pci_sys_data variable as the first element on the ARM platform.
> > > > > > 
> > > > > > Signed-off-by: Jayachandran C <jchandra@broadcom.com>
> > > > > > ---
> > > > > > Here's v2 of the patches, this enables use of pci-host-generic on
> > > > > > arm64.
> > > > > > 
> > > > > > This has been tested on both qemu and fast model for arm64, and on
> > > > > > qemu for arm32.
> > > > > > 
> > > > > > v1->v2
> > > > > >  - Address comments from Arnd Bergmann and Lorenzo Pieralisi
> > > > > >     - move contents of gen_pci_init to gen_pci_probe
> > > > > >     - assign resources only when !probe_only
> > > > > >  - tested on ARM32 with qemu option -M virt
> > > > > 
> > > > > I tried this with an arm64 kernel running under kvmtool, but I get the
> > > > > following errors (a 32-bit ARM kernel does seem to work):
> > > > > 
> > > > >   PCI host bridge /pci ranges:
> > > > >      IO 0x00000000..0x0000ffff -> 0x00000000
> > > > >     MEM 0x41000000..0x7fffffff -> 0x41000000
> > > > >   pci-host-generic 40000000.pci: PCI host bridge to bus 0000:00
> > > > >   pci_bus 0000:00: root bus resource [bus 00-01]
> > > > >   pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
> > > > >   pci_bus 0000:00: root bus resource [mem 0x41000000-0x7fffffff]
> > > > >   pci_bus 0000:00: scanning bus
> > > > >   pci 0000:00:00.0: [1af4:1009] type 00 class 0xff0000
> > > > >   pci 0000:00:00.0: reg 0x10: [mem 0x41000000-0x410003ff]
> > > > >   pci 0000:00:00.0: reg 0x14: [io  0x6200-0x65ff]
> > > > >   pci 0000:00:00.0: reg 0x18: [mem 0x41000400-0x410005ff]
> > > > >   pci 0000:00:01.0: [1af4:1009] type 00 class 0xff0000
> > > > >   pci 0000:00:01.0: reg 0x10: [mem 0x41000800-0x41000bff]
> > > > >   pci 0000:00:01.0: reg 0x14: [io  0x6600-0x69ff]
> > > > >   pci 0000:00:01.0: reg 0x18: [mem 0x41000c00-0x41000dff]
> > > > >   pci_bus 0000:00: fixups for bus
> > > > >   pci_bus 0000:00: bus scan returning with max=00
> > > > >   pci 0000:00:00.0: fixup irq: got 10
> > > > >   pci 0000:00:00.0: assigning IRQ 10
> > > > >   pci 0000:00:01.0: fixup irq: got 11
> > > > >   pci 0000:00:01.0: assigning IRQ 11
> > > > >   virtio-pci 0000:00:00.0: can't enable device: BAR 0 [mem 0x41000000-0x410003ff] not claimed
> > > > >   virtio-pci: probe of 0000:00:00.0 failed with error -22
> > > > >   virtio-pci 0000:00:01.0: can't enable device: BAR 0 [mem 0x41000800-0x41000bff] not claimed
> > > > >   virtio-pci: probe of 0000:00:01.0 failed with error -22
> > > > 
> > > > PCI_PROBE_ONLY does not work yet for arm64, this will need further changes
> > > > in either arm64 or pci as noted by Lorenzo. This is not due to a problem with
> > > > this patch per se.
> > > > 
> > > > More importantly, this does not change the current arm32 behavior and adds
> > > > support for arm64 for two very useful cases
> > > >  - we can use "pci-host-ecam-generic" for a host bridge controller that is
> > > >    initialized by firmware, without adding a custom driver.
> > > >  - qemu virt platform works on arm64
> > > > 
> > > > If you think there are any furhter changes needed in this patchset please
> > > > let me know.
> > > 
> > > I'm waiting for at least an ack from Will.
> > 
> > I'm not too keen on the current state of this patch. Firstly, I'd really
> > like to see the PROBE_ONLY case addressed at the same time as this port
> > (Lorenzo and Suravee are working on this).
> 
> Fixing the PROBE-ONLY for arm64 is probably unrelated to the scope of this
> patch - so I would hope that we don't NACK this patch due to that issue. This
> patch is very useful without PROBE-ONLY like I noted above.

I'm not NACKing anything, I just don't see the benefit of merging half a
solution when the other half is in active development. Perhaps you could
review Lorenzo's patches to help things along?

> > Secondly, the hack to put pci_sys_data as the first member of gen_pci is ugly
> > at best
> 
> On balance, it removes the problem of using hw_pci interface which has its own
> ugliness (Arnd's mail on this http://www.spinics.net/lists/linux-pci/msg40703.html)

To me, that sounds like we should be disposing of the hw_pci interface
altogether and moving arch/arm/ over to the new architecture-independent
interface.

> > and probably makes it difficult to support MSIs on ARM.
> 
> Adding parsing of msi-parent and setting it up for arm32 and arm64 can be
> added fairly easily to the current code, I can post an RFC patch for this.

I think that would be a good addition to the series.

Will

^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [PATCH v2 1/2] PCI: generic: remove dependency on hw_pci
  2015-05-26  9:59             ` Will Deacon
@ 2015-05-26 10:38               ` Arnd Bergmann
  -1 siblings, 0 replies; 42+ messages in thread
From: Arnd Bergmann @ 2015-05-26 10:38 UTC (permalink / raw)
  To: Will Deacon
  Cc: Jayachandran C.,
	Bjorn Helgaas, linux-pci, linux-arm-kernel, Lorenzo Pieralisi,
	Liviu Dudau, suravee.suthikulpanit, Ming Lei

On Tuesday 26 May 2015 10:59:24 Will Deacon wrote:
> > > Secondly, the hack to put pci_sys_data as the first member of gen_pci is ugly
> > > at best
> > 
> > On balance, it removes the problem of using hw_pci interface which has its own
> > ugliness (Arnd's mail on this http://www.spinics.net/lists/linux-pci/msg40703.html)
> 
> To me, that sounds like we should be disposing of the hw_pci interface
> altogether and moving arch/arm/ over to the new architecture-independent
> interface.

I'd like to do that for all drivers in drivers/pci/host, but leave the
ones for the legacy platforms in arch/arm alone, in particular the ones
that use nr_controllers != 1.

We should be able to remove pci_common_init_dev() and directly probe
all devices that are using that, while we keep pci_common_init()
around for the legacy case that also does not have a parent device.

	Arnd

^ permalink raw reply	[flat|nested] 42+ messages in thread

* [PATCH v2 1/2] PCI: generic: remove dependency on hw_pci
@ 2015-05-26 10:38               ` Arnd Bergmann
  0 siblings, 0 replies; 42+ messages in thread
From: Arnd Bergmann @ 2015-05-26 10:38 UTC (permalink / raw)
  To: linux-arm-kernel

On Tuesday 26 May 2015 10:59:24 Will Deacon wrote:
> > > Secondly, the hack to put pci_sys_data as the first member of gen_pci is ugly
> > > at best
> > 
> > On balance, it removes the problem of using hw_pci interface which has its own
> > ugliness (Arnd's mail on this http://www.spinics.net/lists/linux-pci/msg40703.html)
> 
> To me, that sounds like we should be disposing of the hw_pci interface
> altogether and moving arch/arm/ over to the new architecture-independent
> interface.

I'd like to do that for all drivers in drivers/pci/host, but leave the
ones for the legacy platforms in arch/arm alone, in particular the ones
that use nr_controllers != 1.

We should be able to remove pci_common_init_dev() and directly probe
all devices that are using that, while we keep pci_common_init()
around for the legacy case that also does not have a parent device.

	Arnd

^ permalink raw reply	[flat|nested] 42+ messages in thread

end of thread, other threads:[~2015-05-26 14:14 UTC | newest]

Thread overview: 42+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-05-05  2:02 [PATCH v2 1/2] PCI: generic: remove dependency on hw_pci Jayachandran C
2015-05-05  2:02 ` Jayachandran C
2015-05-05  2:02 ` [PATCH v2 2/2] PCI: generic: add arm64 support Jayachandran C
2015-05-05  2:02   ` Jayachandran C
2015-05-05 15:53 ` [PATCH v2 1/2] PCI: generic: remove dependency on hw_pci Will Deacon
2015-05-05 15:53   ` Will Deacon
2015-05-05 15:58   ` Arnd Bergmann
2015-05-05 15:58     ` Arnd Bergmann
2015-05-05 16:03   ` Lorenzo Pieralisi
2015-05-05 16:03     ` Lorenzo Pieralisi
2015-05-06 14:18   ` Lorenzo Pieralisi
2015-05-06 14:18     ` Lorenzo Pieralisi
2015-05-06 15:18     ` Bjorn Helgaas
2015-05-06 15:18       ` Bjorn Helgaas
2015-05-07  3:32       ` Suravee Suthikulanit
2015-05-07  3:32         ` Suravee Suthikulanit
2015-05-12 13:34         ` Bjorn Helgaas
2015-05-12 13:34           ` Bjorn Helgaas
2015-05-12 16:34           ` Lorenzo Pieralisi
2015-05-12 16:34             ` Lorenzo Pieralisi
2015-05-12 19:20             ` Bjorn Helgaas
2015-05-12 19:20               ` Bjorn Helgaas
2015-05-13 12:47         ` Suravee Suthikulanit
2015-05-13 12:47           ` Suravee Suthikulanit
2015-05-13 13:54           ` Bjorn Helgaas
2015-05-13 13:54             ` Bjorn Helgaas
2015-05-13 15:05             ` Suravee Suthikulanit
2015-05-13 15:05               ` Suravee Suthikulanit
2015-05-13 15:11               ` Bjorn Helgaas
2015-05-13 15:11                 ` Bjorn Helgaas
2015-05-12  0:07   ` Jayachandran C.
2015-05-19 23:09     ` Bjorn Helgaas
2015-05-19 23:09       ` Bjorn Helgaas
2015-05-20 17:29       ` Will Deacon
2015-05-20 17:29         ` Will Deacon
2015-05-20 20:46         ` Bjorn Helgaas
2015-05-20 20:46           ` Bjorn Helgaas
2015-05-21  6:37         ` Jayachandran C.
2015-05-26  9:59           ` Will Deacon
2015-05-26  9:59             ` Will Deacon
2015-05-26 10:38             ` Arnd Bergmann
2015-05-26 10:38               ` Arnd Bergmann

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.