[PATCH v9 00/12] Support for creating generic PCI host bridges from DT

[PATCH v9 00/12] Support for creating generic PCI host bridges from DT

[Liviu Dudau]

This is my updated attempt at adding support for generic PCI host
bridge controllers that make use of device tree information to
configure themselves. This version incorporates Catalin's proposal
for managing domain numbers that got Bjorn's approval. I am now requesting
ACKs from the relevant maintainers as I would like to get the upstream ball
rolling.

Of the more important changes vs v8, this version has an altered implementation
of of_create_pci_host_bridge() that allows for easier conversion of architectures
that use pci_scan_root_bus() in their code rather than pci_create_root_bus().
With my v8 version of the patchset it would've meant adding back the code
from pci_scan_root_bus() into architectural code. v9 fixes that and adds
a callback parameter to of_create_pci_host_bridge() that permits the host
controller driver to finish the driver setup before the bus is being scanned.

To repeat for the benefit of people writing host bridge drivers on top of
my patchset: the API for of_create_pci_host_bridge() has changed and it will now
do all the child bus and device scanning for you, so you only need to provide a
setup function that will be called before scanning start. I will post a patch
that Lorenzo has kindly constructed for converting pci-host-generic.c to my API.

Changes from v8:
  - Introduce a new helper function pci_pio_to_address() to translate between
    I/O port numbers and CPU addresses. This is a temporary band aid
    for drivers that rely on the old behaviour of of_pci_range_to_resource()
    until they are converted to the new framework. ARM's Integrator AP
    pci_v3.c makes use of that.
  - Patch pci_v3.c against changes in of_pci_range_to_resource(). This is the
    only driver that made use of the fact that the function was returning
    CPU addresses rather than I/O port numbers.
  - Added a warning when parsing more that one I/O range as this will discard
    previous information regarding the CPU address of the range.
  - Add support for generic domain number handling. The domain number is now
    stored in the struct bus if CONFIG_PCI_DOMAINS_GENERIC is defined. This
    is a cleanup of the patch that Catalin has proposed and Bjorn has ACKed,
    but I've added it here without the ACK as I have slightly modified the
    proposed API.
  - Create a new function to managing domain numbers that will query the DT
    for pci-domain information.
  - Introduce an updated version of of_create_pci_host_bridge() that takes
    a function pointer for a setup function that can be used by the host bridge
    driver to finish the setup after the DT has been parsed and host bridge
    created but before the scanning of the root bus has been initiated.
    This makes of_create_pci_host_bridge() an easy swap for architectures that
    do manual DT parsing and use pci_scan_root_bus()
  - Added arguments to of_create_pci_host_bridge() to be able to pass the
    bus number for the root bus and the maximum bus number to be used in
    the bus range resource. Changed the return value from a pointer to
    the pci_host_bridge into an int with the error code as the host bridge
    is not needed now given that of_create_pci_host_bridge() does all the
    scanning work.
  - Introduce a new pgprot_device() for remapping I/O space. For architectures
    that don't support it defaults to pgprot_noncached.
  - Fix the generic function for remaping I/O space by using
    pgprot_device(PAGE_KERNEL) as the parameter for ioremap_page_range()
  - Header include fixes, initialisation fixes and misc cleanup

Changes from v7:
  - Reordered the patches so that fixes and non-controversial patches
    from v7 can be accepted more easily. If agreed I can split the
    series again into patches that can be upstreamed easily and ones
    that still need discussion.
  - Moved the of_create_host_bridge() function to drivers/of/of_pci.c
    to better reflect its target use.
  - Added the function to remap the bus I/O resources that used to be
    provided in my arm64 patch series and (re)named it pci_remap_iospace()
  - Removed error code checking from parsing and mapping of IRQ from DT
    in recognition that some PCI devices will not have legacy IRQ mappings.

v8 thread here: https://lkml.org/lkml/2014/7/1/450
v7 thread here with all the historic information: https://lkml.org/lkml/2014/3/14/279

Best regards,
Liviu

Liviu Dudau (12):
  Fix ioport_map() for !CONFIG_GENERIC_IOMAP cases.
  PCI: OF: Parse and map the IRQ when adding the PCI device.
  PCI: Introduce helper functions to deal with PCI I/O ranges.
  PCI: OF: Fix the conversion of IO ranges into IO resources.
  ARM: Define PCI_IOBASE as the base of virtual PCI IO space.
  ARM: integrator: Correct usage of of_pci_range_to_resource()
  PCI: Create pci_host_bridge before its associated bus in pci_create_root_bus.
  PCI: Introduce generic domain handling for PCI busses.
  OF: Introduce helper function for getting PCI domain_nr
  OF: PCI: Add support for creating a generic host_bridge from DT
  arm64: Add pgprot_device() interface for device mappings.
  PCI: Introduce pci_remap_iospace() for remapping PCI I/O bus resources into CPU space

 arch/arm/include/asm/io.h         |   1 +
 arch/arm/mach-integrator/pci_v3.c |  24 ++---
 arch/arm64/include/asm/pgtable.h  |   2 +
 drivers/of/address.c              | 141 ++++++++++++++++++++++++++++
 drivers/of/of_pci.c               | 193 ++++++++++++++++++++++++++++++++++++++
 drivers/pci/host-bridge.c         |  15 +++
 drivers/pci/pci.c                 |  36 +++++++
 drivers/pci/probe.c               |  43 +++++----
 include/asm-generic/io.h          |   2 +-
 include/asm-generic/pgtable.h     |   4 +
 include/linux/of_address.h        |  15 +--
 include/linux/of_pci.h            |  20 ++++
 include/linux/pci.h               |  30 ++++++
 13 files changed, 485 insertions(+), 41 deletions(-)

-- 
2.0.4

[PATCH v9 00/12] Support for creating generic PCI host bridges from DT

[Liviu Dudau]

This is my updated attempt at adding support for generic PCI host
bridge controllers that make use of device tree information to
configure themselves. This version incorporates Catalin's proposal
for managing domain numbers that got Bjorn's approval. I am now requesting
ACKs from the relevant maintainers as I would like to get the upstream ball
rolling.

Of the more important changes vs v8, this version has an altered implementation
of of_create_pci_host_bridge() that allows for easier conversion of architectures
that use pci_scan_root_bus() in their code rather than pci_create_root_bus().
With my v8 version of the patchset it would've meant adding back the code
from pci_scan_root_bus() into architectural code. v9 fixes that and adds
a callback parameter to of_create_pci_host_bridge() that permits the host
controller driver to finish the driver setup before the bus is being scanned.

To repeat for the benefit of people writing host bridge drivers on top of
my patchset: the API for of_create_pci_host_bridge() has changed and it will now
do all the child bus and device scanning for you, so you only need to provide a
setup function that will be called before scanning start. I will post a patch
that Lorenzo has kindly constructed for converting pci-host-generic.c to my API.

Changes from v8:
  - Introduce a new helper function pci_pio_to_address() to translate between
    I/O port numbers and CPU addresses. This is a temporary band aid
    for drivers that rely on the old behaviour of of_pci_range_to_resource()
    until they are converted to the new framework. ARM's Integrator AP
    pci_v3.c makes use of that.
  - Patch pci_v3.c against changes in of_pci_range_to_resource(). This is the
    only driver that made use of the fact that the function was returning
    CPU addresses rather than I/O port numbers.
  - Added a warning when parsing more that one I/O range as this will discard
    previous information regarding the CPU address of the range.
  - Add support for generic domain number handling. The domain number is now
    stored in the struct bus if CONFIG_PCI_DOMAINS_GENERIC is defined. This
    is a cleanup of the patch that Catalin has proposed and Bjorn has ACKed,
    but I've added it here without the ACK as I have slightly modified the
    proposed API.
  - Create a new function to managing domain numbers that will query the DT
    for pci-domain information.
  - Introduce an updated version of of_create_pci_host_bridge() that takes
    a function pointer for a setup function that can be used by the host bridge
    driver to finish the setup after the DT has been parsed and host bridge
    created but before the scanning of the root bus has been initiated.
    This makes of_create_pci_host_bridge() an easy swap for architectures that
    do manual DT parsing and use pci_scan_root_bus()
  - Added arguments to of_create_pci_host_bridge() to be able to pass the
    bus number for the root bus and the maximum bus number to be used in
    the bus range resource. Changed the return value from a pointer to
    the pci_host_bridge into an int with the error code as the host bridge
    is not needed now given that of_create_pci_host_bridge() does all the
    scanning work.
  - Introduce a new pgprot_device() for remapping I/O space. For architectures
    that don't support it defaults to pgprot_noncached.
  - Fix the generic function for remaping I/O space by using
    pgprot_device(PAGE_KERNEL) as the parameter for ioremap_page_range()
  - Header include fixes, initialisation fixes and misc cleanup

Changes from v7:
  - Reordered the patches so that fixes and non-controversial patches
    from v7 can be accepted more easily. If agreed I can split the
    series again into patches that can be upstreamed easily and ones
    that still need discussion.
  - Moved the of_create_host_bridge() function to drivers/of/of_pci.c
    to better reflect its target use.
  - Added the function to remap the bus I/O resources that used to be
    provided in my arm64 patch series and (re)named it pci_remap_iospace()
  - Removed error code checking from parsing and mapping of IRQ from DT
    in recognition that some PCI devices will not have legacy IRQ mappings.

v8 thread here: https://lkml.org/lkml/2014/7/1/450
v7 thread here with all the historic information: https://lkml.org/lkml/2014/3/14/279

Best regards,
Liviu

Liviu Dudau (12):
  Fix ioport_map() for !CONFIG_GENERIC_IOMAP cases.
  PCI: OF: Parse and map the IRQ when adding the PCI device.
  PCI: Introduce helper functions to deal with PCI I/O ranges.
  PCI: OF: Fix the conversion of IO ranges into IO resources.
  ARM: Define PCI_IOBASE as the base of virtual PCI IO space.
  ARM: integrator: Correct usage of of_pci_range_to_resource()
  PCI: Create pci_host_bridge before its associated bus in pci_create_root_bus.
  PCI: Introduce generic domain handling for PCI busses.
  OF: Introduce helper function for getting PCI domain_nr
  OF: PCI: Add support for creating a generic host_bridge from DT
  arm64: Add pgprot_device() interface for device mappings.
  PCI: Introduce pci_remap_iospace() for remapping PCI I/O bus resources into CPU space

 arch/arm/include/asm/io.h         |   1 +
 arch/arm/mach-integrator/pci_v3.c |  24 ++---
 arch/arm64/include/asm/pgtable.h  |   2 +
 drivers/of/address.c              | 141 ++++++++++++++++++++++++++++
 drivers/of/of_pci.c               | 193 ++++++++++++++++++++++++++++++++++++++
 drivers/pci/host-bridge.c         |  15 +++
 drivers/pci/pci.c                 |  36 +++++++
 drivers/pci/probe.c               |  43 +++++----
 include/asm-generic/io.h          |   2 +-
 include/asm-generic/pgtable.h     |   4 +
 include/linux/of_address.h        |  15 +--
 include/linux/of_pci.h            |  20 ++++
 include/linux/pci.h               |  30 ++++++
 13 files changed, 485 insertions(+), 41 deletions(-)

-- 
2.0.4

[PATCH v9 00/12] Support for creating generic PCI host bridges from DT

[Liviu Dudau]

This is my updated attempt at adding support for generic PCI host
bridge controllers that make use of device tree information to
configure themselves. This version incorporates Catalin's proposal
for managing domain numbers that got Bjorn's approval. I am now requesting
ACKs from the relevant maintainers as I would like to get the upstream ball
rolling.

Of the more important changes vs v8, this version has an altered implementation
of of_create_pci_host_bridge() that allows for easier conversion of architectures
that use pci_scan_root_bus() in their code rather than pci_create_root_bus().
With my v8 version of the patchset it would've meant adding back the code
from pci_scan_root_bus() into architectural code. v9 fixes that and adds
a callback parameter to of_create_pci_host_bridge() that permits the host
controller driver to finish the driver setup before the bus is being scanned.

To repeat for the benefit of people writing host bridge drivers on top of
my patchset: the API for of_create_pci_host_bridge() has changed and it will now
do all the child bus and device scanning for you, so you only need to provide a
setup function that will be called before scanning start. I will post a patch
that Lorenzo has kindly constructed for converting pci-host-generic.c to my API.

Changes from v8:
  - Introduce a new helper function pci_pio_to_address() to translate between
    I/O port numbers and CPU addresses. This is a temporary band aid
    for drivers that rely on the old behaviour of of_pci_range_to_resource()
    until they are converted to the new framework. ARM's Integrator AP
    pci_v3.c makes use of that.
  - Patch pci_v3.c against changes in of_pci_range_to_resource(). This is the
    only driver that made use of the fact that the function was returning
    CPU addresses rather than I/O port numbers.
  - Added a warning when parsing more that one I/O range as this will discard
    previous information regarding the CPU address of the range.
  - Add support for generic domain number handling. The domain number is now
    stored in the struct bus if CONFIG_PCI_DOMAINS_GENERIC is defined. This
    is a cleanup of the patch that Catalin has proposed and Bjorn has ACKed,
    but I've added it here without the ACK as I have slightly modified the
    proposed API.
  - Create a new function to managing domain numbers that will query the DT
    for pci-domain information.
  - Introduce an updated version of of_create_pci_host_bridge() that takes
    a function pointer for a setup function that can be used by the host bridge
    driver to finish the setup after the DT has been parsed and host bridge
    created but before the scanning of the root bus has been initiated.
    This makes of_create_pci_host_bridge() an easy swap for architectures that
    do manual DT parsing and use pci_scan_root_bus()
  - Added arguments to of_create_pci_host_bridge() to be able to pass the
    bus number for the root bus and the maximum bus number to be used in
    the bus range resource. Changed the return value from a pointer to
    the pci_host_bridge into an int with the error code as the host bridge
    is not needed now given that of_create_pci_host_bridge() does all the
    scanning work.
  - Introduce a new pgprot_device() for remapping I/O space. For architectures
    that don't support it defaults to pgprot_noncached.
  - Fix the generic function for remaping I/O space by using
    pgprot_device(PAGE_KERNEL) as the parameter for ioremap_page_range()
  - Header include fixes, initialisation fixes and misc cleanup

Changes from v7:
  - Reordered the patches so that fixes and non-controversial patches
    from v7 can be accepted more easily. If agreed I can split the
    series again into patches that can be upstreamed easily and ones
    that still need discussion.
  - Moved the of_create_host_bridge() function to drivers/of/of_pci.c
    to better reflect its target use.
  - Added the function to remap the bus I/O resources that used to be
    provided in my arm64 patch series and (re)named it pci_remap_iospace()
  - Removed error code checking from parsing and mapping of IRQ from DT
    in recognition that some PCI devices will not have legacy IRQ mappings.

v8 thread here: https://lkml.org/lkml/2014/7/1/450
v7 thread here with all the historic information: https://lkml.org/lkml/2014/3/14/279

Best regards,
Liviu

Liviu Dudau (12):
  Fix ioport_map() for !CONFIG_GENERIC_IOMAP cases.
  PCI: OF: Parse and map the IRQ when adding the PCI device.
  PCI: Introduce helper functions to deal with PCI I/O ranges.
  PCI: OF: Fix the conversion of IO ranges into IO resources.
  ARM: Define PCI_IOBASE as the base of virtual PCI IO space.
  ARM: integrator: Correct usage of of_pci_range_to_resource()
  PCI: Create pci_host_bridge before its associated bus in pci_create_root_bus.
  PCI: Introduce generic domain handling for PCI busses.
  OF: Introduce helper function for getting PCI domain_nr
  OF: PCI: Add support for creating a generic host_bridge from DT
  arm64: Add pgprot_device() interface for device mappings.
  PCI: Introduce pci_remap_iospace() for remapping PCI I/O bus resources into CPU space

 arch/arm/include/asm/io.h         |   1 +
 arch/arm/mach-integrator/pci_v3.c |  24 ++---
 arch/arm64/include/asm/pgtable.h  |   2 +
 drivers/of/address.c              | 141 ++++++++++++++++++++++++++++
 drivers/of/of_pci.c               | 193 ++++++++++++++++++++++++++++++++++++++
 drivers/pci/host-bridge.c         |  15 +++
 drivers/pci/pci.c                 |  36 +++++++
 drivers/pci/probe.c               |  43 +++++----
 include/asm-generic/io.h          |   2 +-
 include/asm-generic/pgtable.h     |   4 +
 include/linux/of_address.h        |  15 +--
 include/linux/of_pci.h            |  20 ++++
 include/linux/pci.h               |  30 ++++++
 13 files changed, 485 insertions(+), 41 deletions(-)

-- 
2.0.4

[PATCH v9 01/12] Fix ioport_map() for !CONFIG_GENERIC_IOMAP cases.

[Liviu Dudau]

The inline version of ioport_map() that gets used when !CONFIG_GENERIC_IOMAP
is wrong. It returns a mapped (i.e. virtual) address that can start from
zero and completely ignores the PCI_IOBASE and IO_SPACE_LIMIT that most
architectures that use !CONFIG_GENERIC_MAP define.

Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Tested-by: Tanmay Inamdar <tinamdar@apm.com>
---
 include/asm-generic/io.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
index 975e1cc..2e2161b 100644
--- a/include/asm-generic/io.h
+++ b/include/asm-generic/io.h
@@ -331,7 +331,7 @@ static inline void iounmap(void __iomem *addr)
 #ifndef CONFIG_GENERIC_IOMAP
 static inline void __iomem *ioport_map(unsigned long port, unsigned int nr)
 {
-	return (void __iomem *) port;
+	return (void __iomem *)(PCI_IOBASE + (port & IO_SPACE_LIMIT));
 }
 
 static inline void ioport_unmap(void __iomem *p)
-- 
2.0.4

[PATCH v9 01/12] Fix ioport_map() for !CONFIG_GENERIC_IOMAP cases.

[Liviu Dudau]

The inline version of ioport_map() that gets used when !CONFIG_GENERIC_IOMAP
is wrong. It returns a mapped (i.e. virtual) address that can start from
zero and completely ignores the PCI_IOBASE and IO_SPACE_LIMIT that most
architectures that use !CONFIG_GENERIC_MAP define.

Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Tested-by: Tanmay Inamdar <tinamdar@apm.com>
---
 include/asm-generic/io.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
index 975e1cc..2e2161b 100644
--- a/include/asm-generic/io.h
+++ b/include/asm-generic/io.h
@@ -331,7 +331,7 @@ static inline void iounmap(void __iomem *addr)
 #ifndef CONFIG_GENERIC_IOMAP
 static inline void __iomem *ioport_map(unsigned long port, unsigned int nr)
 {
-	return (void __iomem *) port;
+	return (void __iomem *)(PCI_IOBASE + (port & IO_SPACE_LIMIT));
 }
 
 static inline void ioport_unmap(void __iomem *p)
-- 
2.0.4

[PATCH v9 01/12] Fix ioport_map() for !CONFIG_GENERIC_IOMAP cases.

[Liviu Dudau]

The inline version of ioport_map() that gets used when !CONFIG_GENERIC_IOMAP
is wrong. It returns a mapped (i.e. virtual) address that can start from
zero and completely ignores the PCI_IOBASE and IO_SPACE_LIMIT that most
architectures that use !CONFIG_GENERIC_MAP define.

Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Tested-by: Tanmay Inamdar <tinamdar@apm.com>
---
 include/asm-generic/io.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
index 975e1cc..2e2161b 100644
--- a/include/asm-generic/io.h
+++ b/include/asm-generic/io.h
@@ -331,7 +331,7 @@ static inline void iounmap(void __iomem *addr)
 #ifndef CONFIG_GENERIC_IOMAP
 static inline void __iomem *ioport_map(unsigned long port, unsigned int nr)
 {
-	return (void __iomem *) port;
+	return (void __iomem *)(PCI_IOBASE + (port & IO_SPACE_LIMIT));
 }
 
 static inline void ioport_unmap(void __iomem *p)
-- 
2.0.4

[PATCH v9 02/12] PCI: OF: Parse and map the IRQ when adding the PCI device.

[Liviu Dudau]

Enhance the default implementation of pcibios_add_device() to
parse and map the IRQ of the device if a DT binding is available.

Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Rob Herring <robh+dt@kernel.org>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
---
 drivers/pci/pci.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 1c8592b..29d1775 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -17,6 +17,7 @@
 #include <linux/spinlock.h>
 #include <linux/string.h>
 #include <linux/log2.h>
+#include <linux/of_pci.h>
 #include <linux/pci-aspm.h>
 #include <linux/pm_wakeup.h>
 #include <linux/interrupt.h>
@@ -1453,6 +1454,8 @@ EXPORT_SYMBOL(pcim_pin_device);
  */
 int __weak pcibios_add_device(struct pci_dev *dev)
 {
+	dev->irq = of_irq_parse_and_map_pci(dev, 0, 0);
+
 	return 0;
 }
 
-- 
2.0.4

[PATCH v9 02/12] PCI: OF: Parse and map the IRQ when adding the PCI device.

[Liviu Dudau]

Enhance the default implementation of pcibios_add_device() to
parse and map the IRQ of the device if a DT binding is available.

Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Rob Herring <robh+dt@kernel.org>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
---
 drivers/pci/pci.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 1c8592b..29d1775 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -17,6 +17,7 @@
 #include <linux/spinlock.h>
 #include <linux/string.h>
 #include <linux/log2.h>
+#include <linux/of_pci.h>
 #include <linux/pci-aspm.h>
 #include <linux/pm_wakeup.h>
 #include <linux/interrupt.h>
@@ -1453,6 +1454,8 @@ EXPORT_SYMBOL(pcim_pin_device);
  */
 int __weak pcibios_add_device(struct pci_dev *dev)
 {
+	dev->irq = of_irq_parse_and_map_pci(dev, 0, 0);
+
 	return 0;
 }
 
-- 
2.0.4

[PATCH v9 02/12] PCI: OF: Parse and map the IRQ when adding the PCI device.

[Liviu Dudau]

Enhance the default implementation of pcibios_add_device() to
parse and map the IRQ of the device if a DT binding is available.

Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Rob Herring <robh+dt@kernel.org>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
---
 drivers/pci/pci.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 1c8592b..29d1775 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -17,6 +17,7 @@
 #include <linux/spinlock.h>
 #include <linux/string.h>
 #include <linux/log2.h>
+#include <linux/of_pci.h>
 #include <linux/pci-aspm.h>
 #include <linux/pm_wakeup.h>
 #include <linux/interrupt.h>
@@ -1453,6 +1454,8 @@ EXPORT_SYMBOL(pcim_pin_device);
  */
 int __weak pcibios_add_device(struct pci_dev *dev)
 {
+	dev->irq = of_irq_parse_and_map_pci(dev, 0, 0);
+
 	return 0;
 }
 
-- 
2.0.4

Re: [PATCH v9 02/12] PCI: OF: Parse and map the IRQ when adding the PCI device.

[Wei Yang]

On Tue, Aug 12, 2014 at 05:25:15PM +0100, Liviu Dudau wrote:
>Enhance the default implementation of pcibios_add_device() to
>parse and map the IRQ of the device if a DT binding is available.
>
>Cc: Bjorn Helgaas <bhelgaas@google.com>
>Cc: Grant Likely <grant.likely@linaro.org>
>Cc: Rob Herring <robh+dt@kernel.org>
>Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
>---
> drivers/pci/pci.c | 3 +++
> 1 file changed, 3 insertions(+)
>
>diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
>index 1c8592b..29d1775 100644
>--- a/drivers/pci/pci.c
>+++ b/drivers/pci/pci.c
>@@ -17,6 +17,7 @@
> #include <linux/spinlock.h>
> #include <linux/string.h>
> #include <linux/log2.h>
>+#include <linux/of_pci.h>
> #include <linux/pci-aspm.h>
> #include <linux/pm_wakeup.h>
> #include <linux/interrupt.h>
>@@ -1453,6 +1454,8 @@ EXPORT_SYMBOL(pcim_pin_device);
>  */
> int __weak pcibios_add_device(struct pci_dev *dev)
> {
>+	dev->irq = of_irq_parse_and_map_pci(dev, 0, 0);
>+
> 	return 0;
> }

Liviu,

For this, my suggestion is to add arch dependent function to setup the irq
line for pci devices. I can't find an obvious reason this won't work on other
archs, but maybe this will hurt some of them?

>
>-- 
>2.0.4
>
>--
>To unsubscribe from this list: send the line "unsubscribe linux-pci" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Richard Yang
Help you, Help me

[PATCH v9 02/12] PCI: OF: Parse and map the IRQ when adding the PCI device.

[Wei Yang]

On Tue, Aug 12, 2014 at 05:25:15PM +0100, Liviu Dudau wrote:
>Enhance the default implementation of pcibios_add_device() to
>parse and map the IRQ of the device if a DT binding is available.
>
>Cc: Bjorn Helgaas <bhelgaas@google.com>
>Cc: Grant Likely <grant.likely@linaro.org>
>Cc: Rob Herring <robh+dt@kernel.org>
>Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
>---
> drivers/pci/pci.c | 3 +++
> 1 file changed, 3 insertions(+)
>
>diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
>index 1c8592b..29d1775 100644
>--- a/drivers/pci/pci.c
>+++ b/drivers/pci/pci.c
>@@ -17,6 +17,7 @@
> #include <linux/spinlock.h>
> #include <linux/string.h>
> #include <linux/log2.h>
>+#include <linux/of_pci.h>
> #include <linux/pci-aspm.h>
> #include <linux/pm_wakeup.h>
> #include <linux/interrupt.h>
>@@ -1453,6 +1454,8 @@ EXPORT_SYMBOL(pcim_pin_device);
>  */
> int __weak pcibios_add_device(struct pci_dev *dev)
> {
>+	dev->irq = of_irq_parse_and_map_pci(dev, 0, 0);
>+
> 	return 0;
> }

Liviu,

For this, my suggestion is to add arch dependent function to setup the irq
line for pci devices. I can't find an obvious reason this won't work on other
archs, but maybe this will hurt some of them?

>
>-- 
>2.0.4
>
>--
>To unsubscribe from this list: send the line "unsubscribe linux-pci" in
>the body of a message to majordomo at vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Richard Yang
Help you, Help me

Re: [PATCH v9 02/12] PCI: OF: Parse and map the IRQ when adding the PCI device.

[Liviu Dudau]

On Thu, Aug 14, 2014 at 03:58:04PM +0100, Wei Yang wrote:
> On Tue, Aug 12, 2014 at 05:25:15PM +0100, Liviu Dudau wrote:
> >Enhance the default implementation of pcibios_add_device() to
> >parse and map the IRQ of the device if a DT binding is available.
> >
> >Cc: Bjorn Helgaas <bhelgaas@google.com>
> >Cc: Grant Likely <grant.likely@linaro.org>
> >Cc: Rob Herring <robh+dt@kernel.org>
> >Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
> >---
> > drivers/pci/pci.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> >diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> >index 1c8592b..29d1775 100644
> >--- a/drivers/pci/pci.c
> >+++ b/drivers/pci/pci.c
> >@@ -17,6 +17,7 @@
> > #include <linux/spinlock.h>
> > #include <linux/string.h>
> > #include <linux/log2.h>
> >+#include <linux/of_pci.h>
> > #include <linux/pci-aspm.h>
> > #include <linux/pm_wakeup.h>
> > #include <linux/interrupt.h>
> >@@ -1453,6 +1454,8 @@ EXPORT_SYMBOL(pcim_pin_device);
> >  */
> > int __weak pcibios_add_device(struct pci_dev *dev)
> > {
> >+	dev->irq = of_irq_parse_and_map_pci(dev, 0, 0);
> >+
> > 	return 0;
> > }
> 
> Liviu,
> 
> For this, my suggestion is to add arch dependent function to setup the irq
> line for pci devices. I can't find an obvious reason this won't work on other
> archs, but maybe this will hurt some of them?

Hi Wei,

I'm not sure I understand your point. Architectures that support OF will obviously
benefit from this common approach, and for the other ones the function is empty
so it will not change existing behaviour. If you are suggesting that I should
create a new API that each architecture could go and implement for setting up the
IRQ line then I would agree that it would be nice to have that, but the question
is how many architectures are outside OF that need this?

If I understood you correctly, it is a nice idea but slightly outside the scope
of my current patchset.

Best regards,
Liviu

> 
> >
> >-- 
> >2.0.4
> >
> >--
> >To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> >the body of a message to majordomo@vger.kernel.org
> >More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> -- 
> Richard Yang
> Help you, Help me
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯

[PATCH v9 02/12] PCI: OF: Parse and map the IRQ when adding the PCI device.

[Liviu Dudau]

On Thu, Aug 14, 2014 at 03:58:04PM +0100, Wei Yang wrote:
> On Tue, Aug 12, 2014 at 05:25:15PM +0100, Liviu Dudau wrote:
> >Enhance the default implementation of pcibios_add_device() to
> >parse and map the IRQ of the device if a DT binding is available.
> >
> >Cc: Bjorn Helgaas <bhelgaas@google.com>
> >Cc: Grant Likely <grant.likely@linaro.org>
> >Cc: Rob Herring <robh+dt@kernel.org>
> >Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
> >---
> > drivers/pci/pci.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> >diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> >index 1c8592b..29d1775 100644
> >--- a/drivers/pci/pci.c
> >+++ b/drivers/pci/pci.c
> >@@ -17,6 +17,7 @@
> > #include <linux/spinlock.h>
> > #include <linux/string.h>
> > #include <linux/log2.h>
> >+#include <linux/of_pci.h>
> > #include <linux/pci-aspm.h>
> > #include <linux/pm_wakeup.h>
> > #include <linux/interrupt.h>
> >@@ -1453,6 +1454,8 @@ EXPORT_SYMBOL(pcim_pin_device);
> >  */
> > int __weak pcibios_add_device(struct pci_dev *dev)
> > {
> >+	dev->irq = of_irq_parse_and_map_pci(dev, 0, 0);
> >+
> > 	return 0;
> > }
> 
> Liviu,
> 
> For this, my suggestion is to add arch dependent function to setup the irq
> line for pci devices. I can't find an obvious reason this won't work on other
> archs, but maybe this will hurt some of them?

Hi Wei,

I'm not sure I understand your point. Architectures that support OF will obviously
benefit from this common approach, and for the other ones the function is empty
so it will not change existing behaviour. If you are suggesting that I should
create a new API that each architecture could go and implement for setting up the
IRQ line then I would agree that it would be nice to have that, but the question
is how many architectures are outside OF that need this?

If I understood you correctly, it is a nice idea but slightly outside the scope
of my current patchset.

Best regards,
Liviu

> 
> >
> >-- 
> >2.0.4
> >
> >--
> >To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> >the body of a message to majordomo at vger.kernel.org
> >More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> -- 
> Richard Yang
> Help you, Help me
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ?\_(?)_/?

Re: [PATCH v9 02/12] PCI: OF: Parse and map the IRQ when adding the PCI device.

[Wei Yang]

On Thu, Aug 14, 2014 at 04:49:59PM +0100, Liviu Dudau wrote:
>On Thu, Aug 14, 2014 at 03:58:04PM +0100, Wei Yang wrote:
>> On Tue, Aug 12, 2014 at 05:25:15PM +0100, Liviu Dudau wrote:
>> >Enhance the default implementation of pcibios_add_device() to
>> >parse and map the IRQ of the device if a DT binding is available.
>> >
>> >Cc: Bjorn Helgaas <bhelgaas@google.com>
>> >Cc: Grant Likely <grant.likely@linaro.org>
>> >Cc: Rob Herring <robh+dt@kernel.org>
>> >Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
>> >---
>> > drivers/pci/pci.c | 3 +++
>> > 1 file changed, 3 insertions(+)
>> >
>> >diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
>> >index 1c8592b..29d1775 100644
>> >--- a/drivers/pci/pci.c
>> >+++ b/drivers/pci/pci.c
>> >@@ -17,6 +17,7 @@
>> > #include <linux/spinlock.h>
>> > #include <linux/string.h>
>> > #include <linux/log2.h>
>> >+#include <linux/of_pci.h>
>> > #include <linux/pci-aspm.h>
>> > #include <linux/pm_wakeup.h>
>> > #include <linux/interrupt.h>
>> >@@ -1453,6 +1454,8 @@ EXPORT_SYMBOL(pcim_pin_device);
>> >  */
>> > int __weak pcibios_add_device(struct pci_dev *dev)
>> > {
>> >+	dev->irq = of_irq_parse_and_map_pci(dev, 0, 0);
>> >+
>> > 	return 0;
>> > }
>> 
>> Liviu,
>> 
>> For this, my suggestion is to add arch dependent function to setup the irq
>> line for pci devices. I can't find an obvious reason this won't work on other
>> archs, but maybe this will hurt some of them?
>
>Hi Wei,
>
>I'm not sure I understand your point. Architectures that support OF will obviously
>benefit from this common approach, and for the other ones the function is empty
>so it will not change existing behaviour. If you are suggesting that I should
>create a new API that each architecture could go and implement for setting up the
>IRQ line then I would agree that it would be nice to have that, but the question
>is how many architectures are outside OF that need this?

My suggestion is to define the pcibios_add_device() for arm arch, like the one
in arch/powerpc/kernel/pci-common.c. If my understanding is correct, this
patch set address the pci bus setup mostly on arm arch.

For those archs not support OF, this function is empty and has no effect. I
agree on this one.

For those archs rely on OF, we still have two cases:
    1. they would have implement this function like powerpc
    2. have other way to fix it up,  otherwise how it works now?
If my assumption is correct, this change will either have no effect, or fix up
the irq line the second time. Not harmful, but not necessary.

I am not familiar with other arch, so the second case is my deduction. If this
is not correct, please let me know.

>
>If I understood you correctly, it is a nice idea but slightly outside the scope
>of my current patchset.
>
>Best regards,
>Liviu
>
>> 
>> >
>> >-- 
>> >2.0.4
>> >
>> >--
>> >To unsubscribe from this list: send the line "unsubscribe linux-pci" in
>> >the body of a message to majordomo@vger.kernel.org
>> >More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> 
>> -- 
>> Richard Yang
>> Help you, Help me
>> 
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> 
>
>-- 
>====================
>| I would like to |
>| fix the world,  |
>| but they're not |
>| giving me the   |
> \ source code!  /
>  ---------------
>    ¯\_(ツ)_/¯

-- 
Richard Yang
Help you, Help me

[PATCH v9 02/12] PCI: OF: Parse and map the IRQ when adding the PCI device.

[Wei Yang]

On Thu, Aug 14, 2014 at 04:49:59PM +0100, Liviu Dudau wrote:
>On Thu, Aug 14, 2014 at 03:58:04PM +0100, Wei Yang wrote:
>> On Tue, Aug 12, 2014 at 05:25:15PM +0100, Liviu Dudau wrote:
>> >Enhance the default implementation of pcibios_add_device() to
>> >parse and map the IRQ of the device if a DT binding is available.
>> >
>> >Cc: Bjorn Helgaas <bhelgaas@google.com>
>> >Cc: Grant Likely <grant.likely@linaro.org>
>> >Cc: Rob Herring <robh+dt@kernel.org>
>> >Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
>> >---
>> > drivers/pci/pci.c | 3 +++
>> > 1 file changed, 3 insertions(+)
>> >
>> >diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
>> >index 1c8592b..29d1775 100644
>> >--- a/drivers/pci/pci.c
>> >+++ b/drivers/pci/pci.c
>> >@@ -17,6 +17,7 @@
>> > #include <linux/spinlock.h>
>> > #include <linux/string.h>
>> > #include <linux/log2.h>
>> >+#include <linux/of_pci.h>
>> > #include <linux/pci-aspm.h>
>> > #include <linux/pm_wakeup.h>
>> > #include <linux/interrupt.h>
>> >@@ -1453,6 +1454,8 @@ EXPORT_SYMBOL(pcim_pin_device);
>> >  */
>> > int __weak pcibios_add_device(struct pci_dev *dev)
>> > {
>> >+	dev->irq = of_irq_parse_and_map_pci(dev, 0, 0);
>> >+
>> > 	return 0;
>> > }
>> 
>> Liviu,
>> 
>> For this, my suggestion is to add arch dependent function to setup the irq
>> line for pci devices. I can't find an obvious reason this won't work on other
>> archs, but maybe this will hurt some of them?
>
>Hi Wei,
>
>I'm not sure I understand your point. Architectures that support OF will obviously
>benefit from this common approach, and for the other ones the function is empty
>so it will not change existing behaviour. If you are suggesting that I should
>create a new API that each architecture could go and implement for setting up the
>IRQ line then I would agree that it would be nice to have that, but the question
>is how many architectures are outside OF that need this?

My suggestion is to define the pcibios_add_device() for arm arch, like the one
in arch/powerpc/kernel/pci-common.c. If my understanding is correct, this
patch set address the pci bus setup mostly on arm arch.

For those archs not support OF, this function is empty and has no effect. I
agree on this one.

For those archs rely on OF, we still have two cases:
    1. they would have implement this function like powerpc
    2. have other way to fix it up,  otherwise how it works now?
If my assumption is correct, this change will either have no effect, or fix up
the irq line the second time. Not harmful, but not necessary.

I am not familiar with other arch, so the second case is my deduction. If this
is not correct, please let me know.

>
>If I understood you correctly, it is a nice idea but slightly outside the scope
>of my current patchset.
>
>Best regards,
>Liviu
>
>> 
>> >
>> >-- 
>> >2.0.4
>> >
>> >--
>> >To unsubscribe from this list: send the line "unsubscribe linux-pci" in
>> >the body of a message to majordomo at vger.kernel.org
>> >More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> 
>> -- 
>> Richard Yang
>> Help you, Help me
>> 
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> 
>
>-- 
>====================
>| I would like to |
>| fix the world,  |
>| but they're not |
>| giving me the   |
> \ source code!  /
>  ---------------
>    ?\_(?)_/?

-- 
Richard Yang
Help you, Help me

Re: [PATCH v9 02/12] PCI: OF: Parse and map the IRQ when adding the PCI device.

[Liviu Dudau]

On Fri, Aug 15, 2014 at 09:56:32AM +0100, Wei Yang wrote:
> On Thu, Aug 14, 2014 at 04:49:59PM +0100, Liviu Dudau wrote:
> >On Thu, Aug 14, 2014 at 03:58:04PM +0100, Wei Yang wrote:
> >> On Tue, Aug 12, 2014 at 05:25:15PM +0100, Liviu Dudau wrote:
> >> >Enhance the default implementation of pcibios_add_device() to
> >> >parse and map the IRQ of the device if a DT binding is available.
> >> >
> >> >Cc: Bjorn Helgaas <bhelgaas@google.com>
> >> >Cc: Grant Likely <grant.likely@linaro.org>
> >> >Cc: Rob Herring <robh+dt@kernel.org>
> >> >Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
> >> >---
> >> > drivers/pci/pci.c | 3 +++
> >> > 1 file changed, 3 insertions(+)
> >> >
> >> >diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> >> >index 1c8592b..29d1775 100644
> >> >--- a/drivers/pci/pci.c
> >> >+++ b/drivers/pci/pci.c
> >> >@@ -17,6 +17,7 @@
> >> > #include <linux/spinlock.h>
> >> > #include <linux/string.h>
> >> > #include <linux/log2.h>
> >> >+#include <linux/of_pci.h>
> >> > #include <linux/pci-aspm.h>
> >> > #include <linux/pm_wakeup.h>
> >> > #include <linux/interrupt.h>
> >> >@@ -1453,6 +1454,8 @@ EXPORT_SYMBOL(pcim_pin_device);
> >> >  */
> >> > int __weak pcibios_add_device(struct pci_dev *dev)
> >> > {
> >> >+	dev->irq = of_irq_parse_and_map_pci(dev, 0, 0);
> >> >+
> >> > 	return 0;
> >> > }
> >> 
> >> Liviu,
> >> 
> >> For this, my suggestion is to add arch dependent function to setup the irq
> >> line for pci devices. I can't find an obvious reason this won't work on other
> >> archs, but maybe this will hurt some of them?
> >
> >Hi Wei,
> >
> >I'm not sure I understand your point. Architectures that support OF will obviously
> >benefit from this common approach, and for the other ones the function is empty
> >so it will not change existing behaviour. If you are suggesting that I should
> >create a new API that each architecture could go and implement for setting up the
> >IRQ line then I would agree that it would be nice to have that, but the question
> >is how many architectures are outside OF that need this?
> 
> My suggestion is to define the pcibios_add_device() for arm arch, like the one
> in arch/powerpc/kernel/pci-common.c. If my understanding is correct, this
> patch set address the pci bus setup mostly on arm arch.

And also arm64 at the least.

> 
> For those archs not support OF, this function is empty and has no effect. I
> agree on this one.
> 
> For those archs rely on OF, we still have two cases:
>     1. they would have implement this function like powerpc

Actually, powerpc seems to be the only OF platform reimplementing this function.
s390 and x86 are not OF platforms.

>     2. have other way to fix it up,  otherwise how it works now?

Don't forget that my patchset aims to replace existing house-made code with a more
generic version. When architectures and platforms switch to my code they will have
to add this back in their code if it's needed.

> If my assumption is correct, this change will either have no effect, or fix up
> the irq line the second time. Not harmful, but not necessary.

Well, it will become necessary as old code gets dismantled and converted towards
this patchset. To give you an example that I'm familiar with, for arch/arm the
host bridge drivers have moved into drivers/pci/host, but they still depend/use
the bios32 infrastructure that takes care of setting up the irq. When they switch
to my version they would have to go and debug the "irq not being assigned" issue
and it is quite likely that some of the people doing the conversion will complain
about my code rather than understanding the issue. What I'm trying to do is to
make switching to my patchset as painless as possible, with a cleanup to remove
redundant operations coming after the switchover.

Does that sound like a reasonable plan?

Best regards,
Liviu

> 
> I am not familiar with other arch, so the second case is my deduction. If this
> is not correct, please let me know.
> 
> >
> >If I understood you correctly, it is a nice idea but slightly outside the scope
> >of my current patchset.
> >
> >Best regards,
> >Liviu
> >
> >> 
> >> >
> >> >-- 
> >> >2.0.4
> >> >
> >> >--
> >> >To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> >> >the body of a message to majordomo@vger.kernel.org
> >> >More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >> 
> >> -- 
> >> Richard Yang
> >> Help you, Help me
> >> 
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> >> the body of a message to majordomo@vger.kernel.org
> >> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >> 
> >
> 
> -- 
> Richard Yang
> Help you, Help me
> 
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯

[PATCH v9 02/12] PCI: OF: Parse and map the IRQ when adding the PCI device.

[Liviu Dudau]

On Fri, Aug 15, 2014 at 09:56:32AM +0100, Wei Yang wrote:
> On Thu, Aug 14, 2014 at 04:49:59PM +0100, Liviu Dudau wrote:
> >On Thu, Aug 14, 2014 at 03:58:04PM +0100, Wei Yang wrote:
> >> On Tue, Aug 12, 2014 at 05:25:15PM +0100, Liviu Dudau wrote:
> >> >Enhance the default implementation of pcibios_add_device() to
> >> >parse and map the IRQ of the device if a DT binding is available.
> >> >
> >> >Cc: Bjorn Helgaas <bhelgaas@google.com>
> >> >Cc: Grant Likely <grant.likely@linaro.org>
> >> >Cc: Rob Herring <robh+dt@kernel.org>
> >> >Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
> >> >---
> >> > drivers/pci/pci.c | 3 +++
> >> > 1 file changed, 3 insertions(+)
> >> >
> >> >diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> >> >index 1c8592b..29d1775 100644
> >> >--- a/drivers/pci/pci.c
> >> >+++ b/drivers/pci/pci.c
> >> >@@ -17,6 +17,7 @@
> >> > #include <linux/spinlock.h>
> >> > #include <linux/string.h>
> >> > #include <linux/log2.h>
> >> >+#include <linux/of_pci.h>
> >> > #include <linux/pci-aspm.h>
> >> > #include <linux/pm_wakeup.h>
> >> > #include <linux/interrupt.h>
> >> >@@ -1453,6 +1454,8 @@ EXPORT_SYMBOL(pcim_pin_device);
> >> >  */
> >> > int __weak pcibios_add_device(struct pci_dev *dev)
> >> > {
> >> >+	dev->irq = of_irq_parse_and_map_pci(dev, 0, 0);
> >> >+
> >> > 	return 0;
> >> > }
> >> 
> >> Liviu,
> >> 
> >> For this, my suggestion is to add arch dependent function to setup the irq
> >> line for pci devices. I can't find an obvious reason this won't work on other
> >> archs, but maybe this will hurt some of them?
> >
> >Hi Wei,
> >
> >I'm not sure I understand your point. Architectures that support OF will obviously
> >benefit from this common approach, and for the other ones the function is empty
> >so it will not change existing behaviour. If you are suggesting that I should
> >create a new API that each architecture could go and implement for setting up the
> >IRQ line then I would agree that it would be nice to have that, but the question
> >is how many architectures are outside OF that need this?
> 
> My suggestion is to define the pcibios_add_device() for arm arch, like the one
> in arch/powerpc/kernel/pci-common.c. If my understanding is correct, this
> patch set address the pci bus setup mostly on arm arch.

And also arm64 at the least.

> 
> For those archs not support OF, this function is empty and has no effect. I
> agree on this one.
> 
> For those archs rely on OF, we still have two cases:
>     1. they would have implement this function like powerpc

Actually, powerpc seems to be the only OF platform reimplementing this function.
s390 and x86 are not OF platforms.

>     2. have other way to fix it up,  otherwise how it works now?

Don't forget that my patchset aims to replace existing house-made code with a more
generic version. When architectures and platforms switch to my code they will have
to add this back in their code if it's needed.

> If my assumption is correct, this change will either have no effect, or fix up
> the irq line the second time. Not harmful, but not necessary.

Well, it will become necessary as old code gets dismantled and converted towards
this patchset. To give you an example that I'm familiar with, for arch/arm the
host bridge drivers have moved into drivers/pci/host, but they still depend/use
the bios32 infrastructure that takes care of setting up the irq. When they switch
to my version they would have to go and debug the "irq not being assigned" issue
and it is quite likely that some of the people doing the conversion will complain
about my code rather than understanding the issue. What I'm trying to do is to
make switching to my patchset as painless as possible, with a cleanup to remove
redundant operations coming after the switchover.

Does that sound like a reasonable plan?

Best regards,
Liviu

> 
> I am not familiar with other arch, so the second case is my deduction. If this
> is not correct, please let me know.
> 
> >
> >If I understood you correctly, it is a nice idea but slightly outside the scope
> >of my current patchset.
> >
> >Best regards,
> >Liviu
> >
> >> 
> >> >
> >> >-- 
> >> >2.0.4
> >> >
> >> >--
> >> >To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> >> >the body of a message to majordomo at vger.kernel.org
> >> >More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >> 
> >> -- 
> >> Richard Yang
> >> Help you, Help me
> >> 
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> >> the body of a message to majordomo at vger.kernel.org
> >> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >> 
> >
> 
> -- 
> Richard Yang
> Help you, Help me
> 
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ?\_(?)_/?

Re: [PATCH v9 02/12] PCI: OF: Parse and map the IRQ when adding the PCI device.

[Liviu Dudau]

On Fri, Aug 15, 2014 at 09:56:32AM +0100, Wei Yang wrote:
> On Thu, Aug 14, 2014 at 04:49:59PM +0100, Liviu Dudau wrote:
> >On Thu, Aug 14, 2014 at 03:58:04PM +0100, Wei Yang wrote:
> >> On Tue, Aug 12, 2014 at 05:25:15PM +0100, Liviu Dudau wrote:
> >> >Enhance the default implementation of pcibios_add_device() to
> >> >parse and map the IRQ of the device if a DT binding is available.
> >> >
> >> >Cc: Bjorn Helgaas <bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
> >> >Cc: Grant Likely <grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> >> >Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> >> >Signed-off-by: Liviu Dudau <Liviu.Dudau-5wv7dgnIgG8@public.gmane.org>
> >> >---
> >> > drivers/pci/pci.c | 3 +++
> >> > 1 file changed, 3 insertions(+)
> >> >
> >> >diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> >> >index 1c8592b..29d1775 100644
> >> >--- a/drivers/pci/pci.c
> >> >+++ b/drivers/pci/pci.c
> >> >@@ -17,6 +17,7 @@
> >> > #include <linux/spinlock.h>
> >> > #include <linux/string.h>
> >> > #include <linux/log2.h>
> >> >+#include <linux/of_pci.h>
> >> > #include <linux/pci-aspm.h>
> >> > #include <linux/pm_wakeup.h>
> >> > #include <linux/interrupt.h>
> >> >@@ -1453,6 +1454,8 @@ EXPORT_SYMBOL(pcim_pin_device);
> >> >  */
> >> > int __weak pcibios_add_device(struct pci_dev *dev)
> >> > {
> >> >+	dev->irq = of_irq_parse_and_map_pci(dev, 0, 0);
> >> >+
> >> > 	return 0;
> >> > }
> >> 
> >> Liviu,
> >> 
> >> For this, my suggestion is to add arch dependent function to setup the irq
> >> line for pci devices. I can't find an obvious reason this won't work on other
> >> archs, but maybe this will hurt some of them?
> >
> >Hi Wei,
> >
> >I'm not sure I understand your point. Architectures that support OF will obviously
> >benefit from this common approach, and for the other ones the function is empty
> >so it will not change existing behaviour. If you are suggesting that I should
> >create a new API that each architecture could go and implement for setting up the
> >IRQ line then I would agree that it would be nice to have that, but the question
> >is how many architectures are outside OF that need this?
> 
> My suggestion is to define the pcibios_add_device() for arm arch, like the one
> in arch/powerpc/kernel/pci-common.c. If my understanding is correct, this
> patch set address the pci bus setup mostly on arm arch.

And also arm64 at the least.

> 
> For those archs not support OF, this function is empty and has no effect. I
> agree on this one.
> 
> For those archs rely on OF, we still have two cases:
>     1. they would have implement this function like powerpc

Actually, powerpc seems to be the only OF platform reimplementing this function.
s390 and x86 are not OF platforms.

>     2. have other way to fix it up,  otherwise how it works now?

Don't forget that my patchset aims to replace existing house-made code with a more
generic version. When architectures and platforms switch to my code they will have
to add this back in their code if it's needed.

> If my assumption is correct, this change will either have no effect, or fix up
> the irq line the second time. Not harmful, but not necessary.

Well, it will become necessary as old code gets dismantled and converted towards
this patchset. To give you an example that I'm familiar with, for arch/arm the
host bridge drivers have moved into drivers/pci/host, but they still depend/use
the bios32 infrastructure that takes care of setting up the irq. When they switch
to my version they would have to go and debug the "irq not being assigned" issue
and it is quite likely that some of the people doing the conversion will complain
about my code rather than understanding the issue. What I'm trying to do is to
make switching to my patchset as painless as possible, with a cleanup to remove
redundant operations coming after the switchover.

Does that sound like a reasonable plan?

Best regards,
Liviu

> 
> I am not familiar with other arch, so the second case is my deduction. If this
> is not correct, please let me know.
> 
> >
> >If I understood you correctly, it is a nice idea but slightly outside the scope
> >of my current patchset.
> >
> >Best regards,
> >Liviu
> >
> >> 
> >> >
> >> >-- 
> >> >2.0.4
> >> >
> >> >--
> >> >To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> >> >the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> >> >More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >> 
> >> -- 
> >> Richard Yang
> >> Help you, Help me
> >> 
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> >> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> >> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >> 
> >
> 
> -- 
> Richard Yang
> Help you, Help me
> 
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 02/12] PCI: OF: Parse and map the IRQ when adding the PCI device.

[Wei Yang]

On Fri, Aug 15, 2014 at 11:30:52AM +0100, Liviu Dudau wrote:
>On Fri, Aug 15, 2014 at 09:56:32AM +0100, Wei Yang wrote:
>> On Thu, Aug 14, 2014 at 04:49:59PM +0100, Liviu Dudau wrote:
>> >On Thu, Aug 14, 2014 at 03:58:04PM +0100, Wei Yang wrote:
>> >> On Tue, Aug 12, 2014 at 05:25:15PM +0100, Liviu Dudau wrote:
>> >> >Enhance the default implementation of pcibios_add_device() to
>> >> >parse and map the IRQ of the device if a DT binding is available.
>> >> >
>> >> >Cc: Bjorn Helgaas <bhelgaas@google.com>
>> >> >Cc: Grant Likely <grant.likely@linaro.org>
>> >> >Cc: Rob Herring <robh+dt@kernel.org>
>> >> >Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
>> >> >---
>> >> > drivers/pci/pci.c | 3 +++
>> >> > 1 file changed, 3 insertions(+)
>> >> >
>> >> >diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
>> >> >index 1c8592b..29d1775 100644
>> >> >--- a/drivers/pci/pci.c
>> >> >+++ b/drivers/pci/pci.c
>> >> >@@ -17,6 +17,7 @@
>> >> > #include <linux/spinlock.h>
>> >> > #include <linux/string.h>
>> >> > #include <linux/log2.h>
>> >> >+#include <linux/of_pci.h>
>> >> > #include <linux/pci-aspm.h>
>> >> > #include <linux/pm_wakeup.h>
>> >> > #include <linux/interrupt.h>
>> >> >@@ -1453,6 +1454,8 @@ EXPORT_SYMBOL(pcim_pin_device);
>> >> >  */
>> >> > int __weak pcibios_add_device(struct pci_dev *dev)
>> >> > {
>> >> >+	dev->irq = of_irq_parse_and_map_pci(dev, 0, 0);
>> >> >+
>> >> > 	return 0;
>> >> > }
>> >> 
>> >> Liviu,
>> >> 
>> >> For this, my suggestion is to add arch dependent function to setup the irq
>> >> line for pci devices. I can't find an obvious reason this won't work on other
>> >> archs, but maybe this will hurt some of them?
>> >
>> >Hi Wei,
>> >
>> >I'm not sure I understand your point. Architectures that support OF will obviously
>> >benefit from this common approach, and for the other ones the function is empty
>> >so it will not change existing behaviour. If you are suggesting that I should
>> >create a new API that each architecture could go and implement for setting up the
>> >IRQ line then I would agree that it would be nice to have that, but the question
>> >is how many architectures are outside OF that need this?
>> 
>> My suggestion is to define the pcibios_add_device() for arm arch, like the one
>> in arch/powerpc/kernel/pci-common.c. If my understanding is correct, this
>> patch set address the pci bus setup mostly on arm arch.
>
>And also arm64 at the least.
>
>> 
>> For those archs not support OF, this function is empty and has no effect. I
>> agree on this one.
>> 
>> For those archs rely on OF, we still have two cases:
>>     1. they would have implement this function like powerpc
>
>Actually, powerpc seems to be the only OF platform reimplementing this function.
>s390 and x86 are not OF platforms.
>
>>     2. have other way to fix it up,  otherwise how it works now?
>
>Don't forget that my patchset aims to replace existing house-made code with a more
>generic version. When architectures and platforms switch to my code they will have
>to add this back in their code if it's needed.
>
>> If my assumption is correct, this change will either have no effect, or fix up
>> the irq line the second time. Not harmful, but not necessary.
>
>Well, it will become necessary as old code gets dismantled and converted towards
>this patchset. To give you an example that I'm familiar with, for arch/arm the
>host bridge drivers have moved into drivers/pci/host, but they still depend/use
>the bios32 infrastructure that takes care of setting up the irq. When they switch
>to my version they would have to go and debug the "irq not being assigned" issue
>and it is quite likely that some of the people doing the conversion will complain
>about my code rather than understanding the issue. What I'm trying to do is to
>make switching to my patchset as painless as possible, with a cleanup to remove
>redundant operations coming after the switchover.
>

This means this is a temporary version for the switchover period and will be
reverted after switchover?

>Does that sound like a reasonable plan?
>
>Best regards,
>Liviu
>
>> 
>> I am not familiar with other arch, so the second case is my deduction. If this
>> is not correct, please let me know.
>> 
>> >
>> >If I understood you correctly, it is a nice idea but slightly outside the scope
>> >of my current patchset.
>> >
>> >Best regards,
>> >Liviu
>> >
>> >> 
>> >> >
>> >> >-- 
>> >> >2.0.4
>> >> >
>> >> >--
>> >> >To unsubscribe from this list: send the line "unsubscribe linux-pci" in
>> >> >the body of a message to majordomo@vger.kernel.org
>> >> >More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> >> 
>> >> -- 
>> >> Richard Yang
>> >> Help you, Help me
>> >> 
>> >> --
>> >> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
>> >> the body of a message to majordomo@vger.kernel.org
>> >> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> >> 
>> >
>> 
>> -- 
>> Richard Yang
>> Help you, Help me
>> 
>> 
>
>-- 
>====================
>| I would like to |
>| fix the world,  |
>| but they're not |
>| giving me the   |
> \ source code!  /
>  ---------------
>    ¯\_(ツ)_/¯

-- 
Richard Yang
Help you, Help me

[PATCH v9 02/12] PCI: OF: Parse and map the IRQ when adding the PCI device.

[Wei Yang]

On Fri, Aug 15, 2014 at 11:30:52AM +0100, Liviu Dudau wrote:
>On Fri, Aug 15, 2014 at 09:56:32AM +0100, Wei Yang wrote:
>> On Thu, Aug 14, 2014 at 04:49:59PM +0100, Liviu Dudau wrote:
>> >On Thu, Aug 14, 2014 at 03:58:04PM +0100, Wei Yang wrote:
>> >> On Tue, Aug 12, 2014 at 05:25:15PM +0100, Liviu Dudau wrote:
>> >> >Enhance the default implementation of pcibios_add_device() to
>> >> >parse and map the IRQ of the device if a DT binding is available.
>> >> >
>> >> >Cc: Bjorn Helgaas <bhelgaas@google.com>
>> >> >Cc: Grant Likely <grant.likely@linaro.org>
>> >> >Cc: Rob Herring <robh+dt@kernel.org>
>> >> >Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
>> >> >---
>> >> > drivers/pci/pci.c | 3 +++
>> >> > 1 file changed, 3 insertions(+)
>> >> >
>> >> >diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
>> >> >index 1c8592b..29d1775 100644
>> >> >--- a/drivers/pci/pci.c
>> >> >+++ b/drivers/pci/pci.c
>> >> >@@ -17,6 +17,7 @@
>> >> > #include <linux/spinlock.h>
>> >> > #include <linux/string.h>
>> >> > #include <linux/log2.h>
>> >> >+#include <linux/of_pci.h>
>> >> > #include <linux/pci-aspm.h>
>> >> > #include <linux/pm_wakeup.h>
>> >> > #include <linux/interrupt.h>
>> >> >@@ -1453,6 +1454,8 @@ EXPORT_SYMBOL(pcim_pin_device);
>> >> >  */
>> >> > int __weak pcibios_add_device(struct pci_dev *dev)
>> >> > {
>> >> >+	dev->irq = of_irq_parse_and_map_pci(dev, 0, 0);
>> >> >+
>> >> > 	return 0;
>> >> > }
>> >> 
>> >> Liviu,
>> >> 
>> >> For this, my suggestion is to add arch dependent function to setup the irq
>> >> line for pci devices. I can't find an obvious reason this won't work on other
>> >> archs, but maybe this will hurt some of them?
>> >
>> >Hi Wei,
>> >
>> >I'm not sure I understand your point. Architectures that support OF will obviously
>> >benefit from this common approach, and for the other ones the function is empty
>> >so it will not change existing behaviour. If you are suggesting that I should
>> >create a new API that each architecture could go and implement for setting up the
>> >IRQ line then I would agree that it would be nice to have that, but the question
>> >is how many architectures are outside OF that need this?
>> 
>> My suggestion is to define the pcibios_add_device() for arm arch, like the one
>> in arch/powerpc/kernel/pci-common.c. If my understanding is correct, this
>> patch set address the pci bus setup mostly on arm arch.
>
>And also arm64 at the least.
>
>> 
>> For those archs not support OF, this function is empty and has no effect. I
>> agree on this one.
>> 
>> For those archs rely on OF, we still have two cases:
>>     1. they would have implement this function like powerpc
>
>Actually, powerpc seems to be the only OF platform reimplementing this function.
>s390 and x86 are not OF platforms.
>
>>     2. have other way to fix it up,  otherwise how it works now?
>
>Don't forget that my patchset aims to replace existing house-made code with a more
>generic version. When architectures and platforms switch to my code they will have
>to add this back in their code if it's needed.
>
>> If my assumption is correct, this change will either have no effect, or fix up
>> the irq line the second time. Not harmful, but not necessary.
>
>Well, it will become necessary as old code gets dismantled and converted towards
>this patchset. To give you an example that I'm familiar with, for arch/arm the
>host bridge drivers have moved into drivers/pci/host, but they still depend/use
>the bios32 infrastructure that takes care of setting up the irq. When they switch
>to my version they would have to go and debug the "irq not being assigned" issue
>and it is quite likely that some of the people doing the conversion will complain
>about my code rather than understanding the issue. What I'm trying to do is to
>make switching to my patchset as painless as possible, with a cleanup to remove
>redundant operations coming after the switchover.
>

This means this is a temporary version for the switchover period and will be
reverted after switchover?

>Does that sound like a reasonable plan?
>
>Best regards,
>Liviu
>
>> 
>> I am not familiar with other arch, so the second case is my deduction. If this
>> is not correct, please let me know.
>> 
>> >
>> >If I understood you correctly, it is a nice idea but slightly outside the scope
>> >of my current patchset.
>> >
>> >Best regards,
>> >Liviu
>> >
>> >> 
>> >> >
>> >> >-- 
>> >> >2.0.4
>> >> >
>> >> >--
>> >> >To unsubscribe from this list: send the line "unsubscribe linux-pci" in
>> >> >the body of a message to majordomo at vger.kernel.org
>> >> >More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> >> 
>> >> -- 
>> >> Richard Yang
>> >> Help you, Help me
>> >> 
>> >> --
>> >> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
>> >> the body of a message to majordomo at vger.kernel.org
>> >> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> >> 
>> >
>> 
>> -- 
>> Richard Yang
>> Help you, Help me
>> 
>> 
>
>-- 
>====================
>| I would like to |
>| fix the world,  |
>| but they're not |
>| giving me the   |
> \ source code!  /
>  ---------------
>    ?\_(?)_/?

-- 
Richard Yang
Help you, Help me

Re: [PATCH v9 02/12] PCI: OF: Parse and map the IRQ when adding the PCI device.

[Liviu Dudau]

On Mon, Aug 18, 2014 at 09:44:04AM +0800, Wei Yang wrote:
> On Fri, Aug 15, 2014 at 11:30:52AM +0100, Liviu Dudau wrote:
> >On Fri, Aug 15, 2014 at 09:56:32AM +0100, Wei Yang wrote:
> >> On Thu, Aug 14, 2014 at 04:49:59PM +0100, Liviu Dudau wrote:
> >> >On Thu, Aug 14, 2014 at 03:58:04PM +0100, Wei Yang wrote:
> >> >> On Tue, Aug 12, 2014 at 05:25:15PM +0100, Liviu Dudau wrote:
> >> >> >Enhance the default implementation of pcibios_add_device() to
> >> >> >parse and map the IRQ of the device if a DT binding is available.
> >> >> >
> >> >> >Cc: Bjorn Helgaas <bhelgaas@google.com>
> >> >> >Cc: Grant Likely <grant.likely@linaro.org>
> >> >> >Cc: Rob Herring <robh+dt@kernel.org>
> >> >> >Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
> >> >> >---
> >> >> > drivers/pci/pci.c | 3 +++
> >> >> > 1 file changed, 3 insertions(+)
> >> >> >
> >> >> >diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> >> >> >index 1c8592b..29d1775 100644
> >> >> >--- a/drivers/pci/pci.c
> >> >> >+++ b/drivers/pci/pci.c
> >> >> >@@ -17,6 +17,7 @@
> >> >> > #include <linux/spinlock.h>
> >> >> > #include <linux/string.h>
> >> >> > #include <linux/log2.h>
> >> >> >+#include <linux/of_pci.h>
> >> >> > #include <linux/pci-aspm.h>
> >> >> > #include <linux/pm_wakeup.h>
> >> >> > #include <linux/interrupt.h>
> >> >> >@@ -1453,6 +1454,8 @@ EXPORT_SYMBOL(pcim_pin_device);
> >> >> >  */
> >> >> > int __weak pcibios_add_device(struct pci_dev *dev)
> >> >> > {
> >> >> >+	dev->irq = of_irq_parse_and_map_pci(dev, 0, 0);
> >> >> >+
> >> >> > 	return 0;
> >> >> > }
> >> >> 
> >> >> Liviu,
> >> >> 
> >> >> For this, my suggestion is to add arch dependent function to setup the irq
> >> >> line for pci devices. I can't find an obvious reason this won't work on other
> >> >> archs, but maybe this will hurt some of them?
> >> >
> >> >Hi Wei,
> >> >
> >> >I'm not sure I understand your point. Architectures that support OF will obviously
> >> >benefit from this common approach, and for the other ones the function is empty
> >> >so it will not change existing behaviour. If you are suggesting that I should
> >> >create a new API that each architecture could go and implement for setting up the
> >> >IRQ line then I would agree that it would be nice to have that, but the question
> >> >is how many architectures are outside OF that need this?
> >> 
> >> My suggestion is to define the pcibios_add_device() for arm arch, like the one
> >> in arch/powerpc/kernel/pci-common.c. If my understanding is correct, this
> >> patch set address the pci bus setup mostly on arm arch.
> >
> >And also arm64 at the least.
> >
> >> 
> >> For those archs not support OF, this function is empty and has no effect. I
> >> agree on this one.
> >> 
> >> For those archs rely on OF, we still have two cases:
> >>     1. they would have implement this function like powerpc
> >
> >Actually, powerpc seems to be the only OF platform reimplementing this function.
> >s390 and x86 are not OF platforms.
> >
> >>     2. have other way to fix it up,  otherwise how it works now?
> >
> >Don't forget that my patchset aims to replace existing house-made code with a more
> >generic version. When architectures and platforms switch to my code they will have
> >to add this back in their code if it's needed.
> >
> >> If my assumption is correct, this change will either have no effect, or fix up
> >> the irq line the second time. Not harmful, but not necessary.
> >
> >Well, it will become necessary as old code gets dismantled and converted towards
> >this patchset. To give you an example that I'm familiar with, for arch/arm the
> >host bridge drivers have moved into drivers/pci/host, but they still depend/use
> >the bios32 infrastructure that takes care of setting up the irq. When they switch
> >to my version they would have to go and debug the "irq not being assigned" issue
> >and it is quite likely that some of the people doing the conversion will complain
> >about my code rather than understanding the issue. What I'm trying to do is to
> >make switching to my patchset as painless as possible, with a cleanup to remove
> >redundant operations coming after the switchover.
> >
> 
> This means this is a temporary version for the switchover period and will be
> reverted after switchover?

At least one of the redundant operations will be removed. Most likely the one
in the arch code or in the driver. Do you have any concerns with that idea?

Best regards,
Liviu

> 
> >Does that sound like a reasonable plan?
> >
> >Best regards,
> >Liviu
> >
> >> 
> >> I am not familiar with other arch, so the second case is my deduction. If this
> >> is not correct, please let me know.
> >> 
> >> >
> >> >If I understood you correctly, it is a nice idea but slightly outside the scope
> >> >of my current patchset.
> >> >
> >> >Best regards,
> >> >Liviu
> >> >
> >> >> 
> >> >> >
> >> >> >-- 
> >> >> >2.0.4
> >> >> >
> >> >> >--
> >> >> >To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> >> >> >the body of a message to majordomo@vger.kernel.org
> >> >> >More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >> >> 
> >> >> -- 
> >> >> Richard Yang
> >> >> Help you, Help me
> >> >> 
> >> >> --
> >> >> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> >> >> the body of a message to majordomo@vger.kernel.org
> >> >> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >> >> 
> >> >
> >> 
> >> -- 
> >> Richard Yang
> >> Help you, Help me
> >> 
> >> 
> >
> >-- 
> >====================
> >| I would like to |
> >| fix the world,  |
> >| but they're not |
> >| giving me the   |
> > \ source code!  /
> >  ---------------
> >    ¯\_(ツ)_/¯
> 
> -- 
> Richard Yang
> Help you, Help me
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
-------------------
   .oooO
   (   )
    \ (  Oooo.
     \_) (   )
          ) /
         (_/

 One small step
   for me ...

[PATCH v9 02/12] PCI: OF: Parse and map the IRQ when adding the PCI device.

[Liviu Dudau]

On Mon, Aug 18, 2014 at 09:44:04AM +0800, Wei Yang wrote:
> On Fri, Aug 15, 2014 at 11:30:52AM +0100, Liviu Dudau wrote:
> >On Fri, Aug 15, 2014 at 09:56:32AM +0100, Wei Yang wrote:
> >> On Thu, Aug 14, 2014 at 04:49:59PM +0100, Liviu Dudau wrote:
> >> >On Thu, Aug 14, 2014 at 03:58:04PM +0100, Wei Yang wrote:
> >> >> On Tue, Aug 12, 2014 at 05:25:15PM +0100, Liviu Dudau wrote:
> >> >> >Enhance the default implementation of pcibios_add_device() to
> >> >> >parse and map the IRQ of the device if a DT binding is available.
> >> >> >
> >> >> >Cc: Bjorn Helgaas <bhelgaas@google.com>
> >> >> >Cc: Grant Likely <grant.likely@linaro.org>
> >> >> >Cc: Rob Herring <robh+dt@kernel.org>
> >> >> >Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
> >> >> >---
> >> >> > drivers/pci/pci.c | 3 +++
> >> >> > 1 file changed, 3 insertions(+)
> >> >> >
> >> >> >diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> >> >> >index 1c8592b..29d1775 100644
> >> >> >--- a/drivers/pci/pci.c
> >> >> >+++ b/drivers/pci/pci.c
> >> >> >@@ -17,6 +17,7 @@
> >> >> > #include <linux/spinlock.h>
> >> >> > #include <linux/string.h>
> >> >> > #include <linux/log2.h>
> >> >> >+#include <linux/of_pci.h>
> >> >> > #include <linux/pci-aspm.h>
> >> >> > #include <linux/pm_wakeup.h>
> >> >> > #include <linux/interrupt.h>
> >> >> >@@ -1453,6 +1454,8 @@ EXPORT_SYMBOL(pcim_pin_device);
> >> >> >  */
> >> >> > int __weak pcibios_add_device(struct pci_dev *dev)
> >> >> > {
> >> >> >+	dev->irq = of_irq_parse_and_map_pci(dev, 0, 0);
> >> >> >+
> >> >> > 	return 0;
> >> >> > }
> >> >> 
> >> >> Liviu,
> >> >> 
> >> >> For this, my suggestion is to add arch dependent function to setup the irq
> >> >> line for pci devices. I can't find an obvious reason this won't work on other
> >> >> archs, but maybe this will hurt some of them?
> >> >
> >> >Hi Wei,
> >> >
> >> >I'm not sure I understand your point. Architectures that support OF will obviously
> >> >benefit from this common approach, and for the other ones the function is empty
> >> >so it will not change existing behaviour. If you are suggesting that I should
> >> >create a new API that each architecture could go and implement for setting up the
> >> >IRQ line then I would agree that it would be nice to have that, but the question
> >> >is how many architectures are outside OF that need this?
> >> 
> >> My suggestion is to define the pcibios_add_device() for arm arch, like the one
> >> in arch/powerpc/kernel/pci-common.c. If my understanding is correct, this
> >> patch set address the pci bus setup mostly on arm arch.
> >
> >And also arm64 at the least.
> >
> >> 
> >> For those archs not support OF, this function is empty and has no effect. I
> >> agree on this one.
> >> 
> >> For those archs rely on OF, we still have two cases:
> >>     1. they would have implement this function like powerpc
> >
> >Actually, powerpc seems to be the only OF platform reimplementing this function.
> >s390 and x86 are not OF platforms.
> >
> >>     2. have other way to fix it up,  otherwise how it works now?
> >
> >Don't forget that my patchset aims to replace existing house-made code with a more
> >generic version. When architectures and platforms switch to my code they will have
> >to add this back in their code if it's needed.
> >
> >> If my assumption is correct, this change will either have no effect, or fix up
> >> the irq line the second time. Not harmful, but not necessary.
> >
> >Well, it will become necessary as old code gets dismantled and converted towards
> >this patchset. To give you an example that I'm familiar with, for arch/arm the
> >host bridge drivers have moved into drivers/pci/host, but they still depend/use
> >the bios32 infrastructure that takes care of setting up the irq. When they switch
> >to my version they would have to go and debug the "irq not being assigned" issue
> >and it is quite likely that some of the people doing the conversion will complain
> >about my code rather than understanding the issue. What I'm trying to do is to
> >make switching to my patchset as painless as possible, with a cleanup to remove
> >redundant operations coming after the switchover.
> >
> 
> This means this is a temporary version for the switchover period and will be
> reverted after switchover?

At least one of the redundant operations will be removed. Most likely the one
in the arch code or in the driver. Do you have any concerns with that idea?

Best regards,
Liviu

> 
> >Does that sound like a reasonable plan?
> >
> >Best regards,
> >Liviu
> >
> >> 
> >> I am not familiar with other arch, so the second case is my deduction. If this
> >> is not correct, please let me know.
> >> 
> >> >
> >> >If I understood you correctly, it is a nice idea but slightly outside the scope
> >> >of my current patchset.
> >> >
> >> >Best regards,
> >> >Liviu
> >> >
> >> >> 
> >> >> >
> >> >> >-- 
> >> >> >2.0.4
> >> >> >
> >> >> >--
> >> >> >To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> >> >> >the body of a message to majordomo at vger.kernel.org
> >> >> >More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >> >> 
> >> >> -- 
> >> >> Richard Yang
> >> >> Help you, Help me
> >> >> 
> >> >> --
> >> >> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> >> >> the body of a message to majordomo at vger.kernel.org
> >> >> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >> >> 
> >> >
> >> 
> >> -- 
> >> Richard Yang
> >> Help you, Help me
> >> 
> >> 
> >
> >-- 
> >====================
> >| I would like to |
> >| fix the world,  |
> >| but they're not |
> >| giving me the   |
> > \ source code!  /
> >  ---------------
> >    ?\_(?)_/?
> 
> -- 
> Richard Yang
> Help you, Help me
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
-------------------
   .oooO
   (   )
    \ (  Oooo.
     \_) (   )
          ) /
         (_/

 One small step
   for me ...

Re: [PATCH v9 02/12] PCI: OF: Parse and map the IRQ when adding the PCI device.

[Catalin Marinas]

On Fri, Aug 15, 2014 at 11:30:52AM +0100, Liviu Dudau wrote:
> On Fri, Aug 15, 2014 at 09:56:32AM +0100, Wei Yang wrote:
> > On Thu, Aug 14, 2014 at 04:49:59PM +0100, Liviu Dudau wrote:
> > >On Thu, Aug 14, 2014 at 03:58:04PM +0100, Wei Yang wrote:
> > >> On Tue, Aug 12, 2014 at 05:25:15PM +0100, Liviu Dudau wrote:
> > >> > int __weak pcibios_add_device(struct pci_dev *dev)
> > >> > {
> > >> >+	dev->irq = of_irq_parse_and_map_pci(dev, 0, 0);
> > >> >+
> > >> > 	return 0;
> > >> > }
> > >> 
> > >> For this, my suggestion is to add arch dependent function to setup the irq
> > >> line for pci devices. I can't find an obvious reason this won't work on other
> > >> archs, but maybe this will hurt some of them?
> > >
> > >I'm not sure I understand your point. Architectures that support OF will obviously
> > >benefit from this common approach, and for the other ones the function is empty
> > >so it will not change existing behaviour. If you are suggesting that I should
> > >create a new API that each architecture could go and implement for setting up the
> > >IRQ line then I would agree that it would be nice to have that, but the question
> > >is how many architectures are outside OF that need this?
> > 
> > My suggestion is to define the pcibios_add_device() for arm arch, like the one
> > in arch/powerpc/kernel/pci-common.c. If my understanding is correct, this
> > patch set address the pci bus setup mostly on arm arch.
> 
> And also arm64 at the least.
...
> Well, it will become necessary as old code gets dismantled and converted towards
> this patchset. To give you an example that I'm familiar with, for arch/arm the
> host bridge drivers have moved into drivers/pci/host, but they still depend/use
> the bios32 infrastructure that takes care of setting up the irq. When they switch
> to my version they would have to go and debug the "irq not being assigned" issue
> and it is quite likely that some of the people doing the conversion will complain
> about my code rather than understanding the issue. What I'm trying to do is to
> make switching to my patchset as painless as possible, with a cleanup to remove
> redundant operations coming after the switchover.

While the goal is fine, until we see a common pattern for what needs to
go into pcibios_add_device() I think we should have an arm64-specific
implementation (and probably an arm32 specific one as well). I can see
powerpc uses it for setting the DMA ops. Would we have a similar need on
arm64 to choose between coherent and non-coherent dma_ops?

Also at some point we'll get ACPI support, so I'm not sure what we do
with assigning the dev->irq here but definitely of_* functions won't
work.

-- 
Catalin

[PATCH v9 02/12] PCI: OF: Parse and map the IRQ when adding the PCI device.

[Catalin Marinas]

On Fri, Aug 15, 2014 at 11:30:52AM +0100, Liviu Dudau wrote:
> On Fri, Aug 15, 2014 at 09:56:32AM +0100, Wei Yang wrote:
> > On Thu, Aug 14, 2014 at 04:49:59PM +0100, Liviu Dudau wrote:
> > >On Thu, Aug 14, 2014 at 03:58:04PM +0100, Wei Yang wrote:
> > >> On Tue, Aug 12, 2014 at 05:25:15PM +0100, Liviu Dudau wrote:
> > >> > int __weak pcibios_add_device(struct pci_dev *dev)
> > >> > {
> > >> >+	dev->irq = of_irq_parse_and_map_pci(dev, 0, 0);
> > >> >+
> > >> > 	return 0;
> > >> > }
> > >> 
> > >> For this, my suggestion is to add arch dependent function to setup the irq
> > >> line for pci devices. I can't find an obvious reason this won't work on other
> > >> archs, but maybe this will hurt some of them?
> > >
> > >I'm not sure I understand your point. Architectures that support OF will obviously
> > >benefit from this common approach, and for the other ones the function is empty
> > >so it will not change existing behaviour. If you are suggesting that I should
> > >create a new API that each architecture could go and implement for setting up the
> > >IRQ line then I would agree that it would be nice to have that, but the question
> > >is how many architectures are outside OF that need this?
> > 
> > My suggestion is to define the pcibios_add_device() for arm arch, like the one
> > in arch/powerpc/kernel/pci-common.c. If my understanding is correct, this
> > patch set address the pci bus setup mostly on arm arch.
> 
> And also arm64 at the least.
...
> Well, it will become necessary as old code gets dismantled and converted towards
> this patchset. To give you an example that I'm familiar with, for arch/arm the
> host bridge drivers have moved into drivers/pci/host, but they still depend/use
> the bios32 infrastructure that takes care of setting up the irq. When they switch
> to my version they would have to go and debug the "irq not being assigned" issue
> and it is quite likely that some of the people doing the conversion will complain
> about my code rather than understanding the issue. What I'm trying to do is to
> make switching to my patchset as painless as possible, with a cleanup to remove
> redundant operations coming after the switchover.

While the goal is fine, until we see a common pattern for what needs to
go into pcibios_add_device() I think we should have an arm64-specific
implementation (and probably an arm32 specific one as well). I can see
powerpc uses it for setting the DMA ops. Would we have a similar need on
arm64 to choose between coherent and non-coherent dma_ops?

Also at some point we'll get ACPI support, so I'm not sure what we do
with assigning the dev->irq here but definitely of_* functions won't
work.

-- 
Catalin

Re: [PATCH v9 02/12] PCI: OF: Parse and map the IRQ when adding the PCI device.

[Liviu Dudau]

On Mon, Aug 18, 2014 at 03:25:50PM +0100, Catalin Marinas wrote:
> On Fri, Aug 15, 2014 at 11:30:52AM +0100, Liviu Dudau wrote:
> > On Fri, Aug 15, 2014 at 09:56:32AM +0100, Wei Yang wrote:
> > > On Thu, Aug 14, 2014 at 04:49:59PM +0100, Liviu Dudau wrote:
> > > >On Thu, Aug 14, 2014 at 03:58:04PM +0100, Wei Yang wrote:
> > > >> On Tue, Aug 12, 2014 at 05:25:15PM +0100, Liviu Dudau wrote:
> > > >> > int __weak pcibios_add_device(struct pci_dev *dev)
> > > >> > {
> > > >> >+	dev->irq = of_irq_parse_and_map_pci(dev, 0, 0);
> > > >> >+
> > > >> > 	return 0;
> > > >> > }
> > > >> 
> > > >> For this, my suggestion is to add arch dependent function to setup the irq
> > > >> line for pci devices. I can't find an obvious reason this won't work on other
> > > >> archs, but maybe this will hurt some of them?
> > > >
> > > >I'm not sure I understand your point. Architectures that support OF will obviously
> > > >benefit from this common approach, and for the other ones the function is empty
> > > >so it will not change existing behaviour. If you are suggesting that I should
> > > >create a new API that each architecture could go and implement for setting up the
> > > >IRQ line then I would agree that it would be nice to have that, but the question
> > > >is how many architectures are outside OF that need this?
> > > 
> > > My suggestion is to define the pcibios_add_device() for arm arch, like the one
> > > in arch/powerpc/kernel/pci-common.c. If my understanding is correct, this
> > > patch set address the pci bus setup mostly on arm arch.
> > 
> > And also arm64 at the least.
> ...
> > Well, it will become necessary as old code gets dismantled and converted towards
> > this patchset. To give you an example that I'm familiar with, for arch/arm the
> > host bridge drivers have moved into drivers/pci/host, but they still depend/use
> > the bios32 infrastructure that takes care of setting up the irq. When they switch
> > to my version they would have to go and debug the "irq not being assigned" issue
> > and it is quite likely that some of the people doing the conversion will complain
> > about my code rather than understanding the issue. What I'm trying to do is to
> > make switching to my patchset as painless as possible, with a cleanup to remove
> > redundant operations coming after the switchover.
> 
> While the goal is fine, until we see a common pattern for what needs to
> go into pcibios_add_device() I think we should have an arm64-specific
> implementation (and probably an arm32 specific one as well). I can see
> powerpc uses it for setting the DMA ops. Would we have a similar need on
> arm64 to choose between coherent and non-coherent dma_ops?

At this point I would like to hear more from people doing the conversion of
the drivers. I cannot answer fully for all arm or arm64 drivers.

> 
> Also at some point we'll get ACPI support, so I'm not sure what we do
> with assigning the dev->irq here but definitely of_* functions won't
> work.

Yes, maybe adding a check if the IRQ has not been assigned already?
I have no idea what the order will be between ACPI ops and of_* ones.

Best regards,
Liviu

> 
> -- 
> Catalin
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
-------------------
   .oooO
   (   )
    \ (  Oooo.
     \_) (   )
          ) /
         (_/

 One small step
   for me ...

[PATCH v9 02/12] PCI: OF: Parse and map the IRQ when adding the PCI device.

[Liviu Dudau]

On Mon, Aug 18, 2014 at 03:25:50PM +0100, Catalin Marinas wrote:
> On Fri, Aug 15, 2014 at 11:30:52AM +0100, Liviu Dudau wrote:
> > On Fri, Aug 15, 2014 at 09:56:32AM +0100, Wei Yang wrote:
> > > On Thu, Aug 14, 2014 at 04:49:59PM +0100, Liviu Dudau wrote:
> > > >On Thu, Aug 14, 2014 at 03:58:04PM +0100, Wei Yang wrote:
> > > >> On Tue, Aug 12, 2014 at 05:25:15PM +0100, Liviu Dudau wrote:
> > > >> > int __weak pcibios_add_device(struct pci_dev *dev)
> > > >> > {
> > > >> >+	dev->irq = of_irq_parse_and_map_pci(dev, 0, 0);
> > > >> >+
> > > >> > 	return 0;
> > > >> > }
> > > >> 
> > > >> For this, my suggestion is to add arch dependent function to setup the irq
> > > >> line for pci devices. I can't find an obvious reason this won't work on other
> > > >> archs, but maybe this will hurt some of them?
> > > >
> > > >I'm not sure I understand your point. Architectures that support OF will obviously
> > > >benefit from this common approach, and for the other ones the function is empty
> > > >so it will not change existing behaviour. If you are suggesting that I should
> > > >create a new API that each architecture could go and implement for setting up the
> > > >IRQ line then I would agree that it would be nice to have that, but the question
> > > >is how many architectures are outside OF that need this?
> > > 
> > > My suggestion is to define the pcibios_add_device() for arm arch, like the one
> > > in arch/powerpc/kernel/pci-common.c. If my understanding is correct, this
> > > patch set address the pci bus setup mostly on arm arch.
> > 
> > And also arm64 at the least.
> ...
> > Well, it will become necessary as old code gets dismantled and converted towards
> > this patchset. To give you an example that I'm familiar with, for arch/arm the
> > host bridge drivers have moved into drivers/pci/host, but they still depend/use
> > the bios32 infrastructure that takes care of setting up the irq. When they switch
> > to my version they would have to go and debug the "irq not being assigned" issue
> > and it is quite likely that some of the people doing the conversion will complain
> > about my code rather than understanding the issue. What I'm trying to do is to
> > make switching to my patchset as painless as possible, with a cleanup to remove
> > redundant operations coming after the switchover.
> 
> While the goal is fine, until we see a common pattern for what needs to
> go into pcibios_add_device() I think we should have an arm64-specific
> implementation (and probably an arm32 specific one as well). I can see
> powerpc uses it for setting the DMA ops. Would we have a similar need on
> arm64 to choose between coherent and non-coherent dma_ops?

At this point I would like to hear more from people doing the conversion of
the drivers. I cannot answer fully for all arm or arm64 drivers.

> 
> Also at some point we'll get ACPI support, so I'm not sure what we do
> with assigning the dev->irq here but definitely of_* functions won't
> work.

Yes, maybe adding a check if the IRQ has not been assigned already?
I have no idea what the order will be between ACPI ops and of_* ones.

Best regards,
Liviu

> 
> -- 
> Catalin
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
-------------------
   .oooO
   (   )
    \ (  Oooo.
     \_) (   )
          ) /
         (_/

 One small step
   for me ...

Re: [PATCH v9 02/12] PCI: OF: Parse and map the IRQ when adding the PCI device.

[Catalin Marinas]

On Mon, Aug 18, 2014 at 10:30:54PM +0100, Liviu Dudau wrote:
> On Mon, Aug 18, 2014 at 03:25:50PM +0100, Catalin Marinas wrote:
> > On Fri, Aug 15, 2014 at 11:30:52AM +0100, Liviu Dudau wrote:
> > > On Fri, Aug 15, 2014 at 09:56:32AM +0100, Wei Yang wrote:
> > > > On Thu, Aug 14, 2014 at 04:49:59PM +0100, Liviu Dudau wrote:
> > > > >On Thu, Aug 14, 2014 at 03:58:04PM +0100, Wei Yang wrote:
> > > > >> On Tue, Aug 12, 2014 at 05:25:15PM +0100, Liviu Dudau wrote:
> > > > >> > int __weak pcibios_add_device(struct pci_dev *dev)
> > > > >> > {
> > > > >> >+	dev->irq = of_irq_parse_and_map_pci(dev, 0, 0);
> > > > >> >+
> > > > >> > 	return 0;
> > > > >> > }
> > > > >> 
> > > > >> For this, my suggestion is to add arch dependent function to setup the irq
> > > > >> line for pci devices. I can't find an obvious reason this won't work on other
> > > > >> archs, but maybe this will hurt some of them?
> > > > >
> > > > >I'm not sure I understand your point. Architectures that support OF will obviously
> > > > >benefit from this common approach, and for the other ones the function is empty
> > > > >so it will not change existing behaviour. If you are suggesting that I should
> > > > >create a new API that each architecture could go and implement for setting up the
> > > > >IRQ line then I would agree that it would be nice to have that, but the question
> > > > >is how many architectures are outside OF that need this?
> > > > 
> > > > My suggestion is to define the pcibios_add_device() for arm arch, like the one
> > > > in arch/powerpc/kernel/pci-common.c. If my understanding is correct, this
> > > > patch set address the pci bus setup mostly on arm arch.
> > > 
> > > And also arm64 at the least.
> > ...
> > > Well, it will become necessary as old code gets dismantled and converted towards
> > > this patchset. To give you an example that I'm familiar with, for arch/arm the
> > > host bridge drivers have moved into drivers/pci/host, but they still depend/use
> > > the bios32 infrastructure that takes care of setting up the irq. When they switch
> > > to my version they would have to go and debug the "irq not being assigned" issue
> > > and it is quite likely that some of the people doing the conversion will complain
> > > about my code rather than understanding the issue. What I'm trying to do is to
> > > make switching to my patchset as painless as possible, with a cleanup to remove
> > > redundant operations coming after the switchover.
> > 
> > While the goal is fine, until we see a common pattern for what needs to
> > go into pcibios_add_device() I think we should have an arm64-specific
> > implementation (and probably an arm32 specific one as well). I can see
> > powerpc uses it for setting the DMA ops. Would we have a similar need on
> > arm64 to choose between coherent and non-coherent dma_ops?
> 
> At this point I would like to hear more from people doing the conversion of
> the drivers. I cannot answer fully for all arm or arm64 drivers.

As I read the description of pcibios_add_device(), it is meant as an
architecture hook. While it's nice to generalise this, I'm not sure we
we can find a common denominator. For example, we may want to call
set_dma_ops() as powerpc does but the ops would be arm64 specific (so
even the __weak implementation may not be used by any architecture).

-- 
Catalin

[PATCH v9 02/12] PCI: OF: Parse and map the IRQ when adding the PCI device.

[Catalin Marinas]

On Mon, Aug 18, 2014 at 10:30:54PM +0100, Liviu Dudau wrote:
> On Mon, Aug 18, 2014 at 03:25:50PM +0100, Catalin Marinas wrote:
> > On Fri, Aug 15, 2014 at 11:30:52AM +0100, Liviu Dudau wrote:
> > > On Fri, Aug 15, 2014 at 09:56:32AM +0100, Wei Yang wrote:
> > > > On Thu, Aug 14, 2014 at 04:49:59PM +0100, Liviu Dudau wrote:
> > > > >On Thu, Aug 14, 2014 at 03:58:04PM +0100, Wei Yang wrote:
> > > > >> On Tue, Aug 12, 2014 at 05:25:15PM +0100, Liviu Dudau wrote:
> > > > >> > int __weak pcibios_add_device(struct pci_dev *dev)
> > > > >> > {
> > > > >> >+	dev->irq = of_irq_parse_and_map_pci(dev, 0, 0);
> > > > >> >+
> > > > >> > 	return 0;
> > > > >> > }
> > > > >> 
> > > > >> For this, my suggestion is to add arch dependent function to setup the irq
> > > > >> line for pci devices. I can't find an obvious reason this won't work on other
> > > > >> archs, but maybe this will hurt some of them?
> > > > >
> > > > >I'm not sure I understand your point. Architectures that support OF will obviously
> > > > >benefit from this common approach, and for the other ones the function is empty
> > > > >so it will not change existing behaviour. If you are suggesting that I should
> > > > >create a new API that each architecture could go and implement for setting up the
> > > > >IRQ line then I would agree that it would be nice to have that, but the question
> > > > >is how many architectures are outside OF that need this?
> > > > 
> > > > My suggestion is to define the pcibios_add_device() for arm arch, like the one
> > > > in arch/powerpc/kernel/pci-common.c. If my understanding is correct, this
> > > > patch set address the pci bus setup mostly on arm arch.
> > > 
> > > And also arm64 at the least.
> > ...
> > > Well, it will become necessary as old code gets dismantled and converted towards
> > > this patchset. To give you an example that I'm familiar with, for arch/arm the
> > > host bridge drivers have moved into drivers/pci/host, but they still depend/use
> > > the bios32 infrastructure that takes care of setting up the irq. When they switch
> > > to my version they would have to go and debug the "irq not being assigned" issue
> > > and it is quite likely that some of the people doing the conversion will complain
> > > about my code rather than understanding the issue. What I'm trying to do is to
> > > make switching to my patchset as painless as possible, with a cleanup to remove
> > > redundant operations coming after the switchover.
> > 
> > While the goal is fine, until we see a common pattern for what needs to
> > go into pcibios_add_device() I think we should have an arm64-specific
> > implementation (and probably an arm32 specific one as well). I can see
> > powerpc uses it for setting the DMA ops. Would we have a similar need on
> > arm64 to choose between coherent and non-coherent dma_ops?
> 
> At this point I would like to hear more from people doing the conversion of
> the drivers. I cannot answer fully for all arm or arm64 drivers.

As I read the description of pcibios_add_device(), it is meant as an
architecture hook. While it's nice to generalise this, I'm not sure we
we can find a common denominator. For example, we may want to call
set_dma_ops() as powerpc does but the ops would be arm64 specific (so
even the __weak implementation may not be used by any architecture).

-- 
Catalin

Re: [PATCH v9 02/12] PCI: OF: Parse and map the IRQ when adding the PCI device.

[Arnd Bergmann]

On Tuesday 19 August 2014, Catalin Marinas wrote:
> On Mon, Aug 18, 2014 at 10:30:54PM +0100, Liviu Dudau wrote:
> > At this point I would like to hear more from people doing the conversion of
> > the drivers. I cannot answer fully for all arm or arm64 drivers.
> 
> As I read the description of pcibios_add_device(), it is meant as an
> architecture hook. While it's nice to generalise this, I'm not sure we
> we can find a common denominator. For example, we may want to call
> set_dma_ops() as powerpc does but the ops would be arm64 specific (so
> even the __weak implementation may not be used by any architecture).

Right. I'm a strong advocate of the idea of having no architecture specific
parts in the PCI support, but I can see the set_dma_ops() call as a
good reason to make an exception here.

We could add another layer of indirection for the purpose of API purity
here, to call an architecture specific DMA setup function, but it doesn't
really add that much benefits, in particular when the DMA setup is currently
in flux as well.

	Arnd

[PATCH v9 02/12] PCI: OF: Parse and map the IRQ when adding the PCI device.

[Arnd Bergmann]

On Tuesday 19 August 2014, Catalin Marinas wrote:
> On Mon, Aug 18, 2014 at 10:30:54PM +0100, Liviu Dudau wrote:
> > At this point I would like to hear more from people doing the conversion of
> > the drivers. I cannot answer fully for all arm or arm64 drivers.
> 
> As I read the description of pcibios_add_device(), it is meant as an
> architecture hook. While it's nice to generalise this, I'm not sure we
> we can find a common denominator. For example, we may want to call
> set_dma_ops() as powerpc does but the ops would be arm64 specific (so
> even the __weak implementation may not be used by any architecture).

Right. I'm a strong advocate of the idea of having no architecture specific
parts in the PCI support, but I can see the set_dma_ops() call as a
good reason to make an exception here.

We could add another layer of indirection for the purpose of API purity
here, to call an architecture specific DMA setup function, but it doesn't
really add that much benefits, in particular when the DMA setup is currently
in flux as well.

	Arnd

Re: [PATCH v9 02/12] PCI: OF: Parse and map the IRQ when adding the PCI device.

[Wei Yang]

On Mon, Aug 18, 2014 at 03:25:50PM +0100, Catalin Marinas wrote:
>...
>> Well, it will become necessary as old code gets dismantled and converted towards
>> this patchset. To give you an example that I'm familiar with, for arch/arm the
>> host bridge drivers have moved into drivers/pci/host, but they still depend/use
>> the bios32 infrastructure that takes care of setting up the irq. When they switch
>> to my version they would have to go and debug the "irq not being assigned" issue
>> and it is quite likely that some of the people doing the conversion will complain
>> about my code rather than understanding the issue. What I'm trying to do is to
>> make switching to my patchset as painless as possible, with a cleanup to remove
>> redundant operations coming after the switchover.
>
>While the goal is fine, until we see a common pattern for what needs to
>go into pcibios_add_device() I think we should have an arm64-specific
>implementation (and probably an arm32 specific one as well). I can see
>powerpc uses it for setting the DMA ops. Would we have a similar need on
>arm64 to choose between coherent and non-coherent dma_ops?

Liviu,

I have the same feeling with Catalin. An arm64-specific implementation of
pcibios_add_device() would be better.

No more other concerns from my side.

>
>Also at some point we'll get ACPI support, so I'm not sure what we do
>with assigning the dev->irq here but definitely of_* functions won't
>work.
>
>-- 
>Catalin

-- 
Richard Yang
Help you, Help me

[PATCH v9 02/12] PCI: OF: Parse and map the IRQ when adding the PCI device.

[Wei Yang]

On Mon, Aug 18, 2014 at 03:25:50PM +0100, Catalin Marinas wrote:
>...
>> Well, it will become necessary as old code gets dismantled and converted towards
>> this patchset. To give you an example that I'm familiar with, for arch/arm the
>> host bridge drivers have moved into drivers/pci/host, but they still depend/use
>> the bios32 infrastructure that takes care of setting up the irq. When they switch
>> to my version they would have to go and debug the "irq not being assigned" issue
>> and it is quite likely that some of the people doing the conversion will complain
>> about my code rather than understanding the issue. What I'm trying to do is to
>> make switching to my patchset as painless as possible, with a cleanup to remove
>> redundant operations coming after the switchover.
>
>While the goal is fine, until we see a common pattern for what needs to
>go into pcibios_add_device() I think we should have an arm64-specific
>implementation (and probably an arm32 specific one as well). I can see
>powerpc uses it for setting the DMA ops. Would we have a similar need on
>arm64 to choose between coherent and non-coherent dma_ops?

Liviu,

I have the same feeling with Catalin. An arm64-specific implementation of
pcibios_add_device() would be better.

No more other concerns from my side.

>
>Also at some point we'll get ACPI support, so I'm not sure what we do
>with assigning the dev->irq here but definitely of_* functions won't
>work.
>
>-- 
>Catalin

-- 
Richard Yang
Help you, Help me

Re: [PATCH v9 02/12] PCI: OF: Parse and map the IRQ when adding the PCI device.

[Liviu Dudau]

On Tue, Aug 19, 2014 at 09:44:01AM +0800, Wei Yang wrote:
> On Mon, Aug 18, 2014 at 03:25:50PM +0100, Catalin Marinas wrote:
> >...
> >> Well, it will become necessary as old code gets dismantled and converted towards
> >> this patchset. To give you an example that I'm familiar with, for arch/arm the
> >> host bridge drivers have moved into drivers/pci/host, but they still depend/use
> >> the bios32 infrastructure that takes care of setting up the irq. When they switch
> >> to my version they would have to go and debug the "irq not being assigned" issue
> >> and it is quite likely that some of the people doing the conversion will complain
> >> about my code rather than understanding the issue. What I'm trying to do is to
> >> make switching to my patchset as painless as possible, with a cleanup to remove
> >> redundant operations coming after the switchover.
> >
> >While the goal is fine, until we see a common pattern for what needs to
> >go into pcibios_add_device() I think we should have an arm64-specific
> >implementation (and probably an arm32 specific one as well). I can see
> >powerpc uses it for setting the DMA ops. Would we have a similar need on
> >arm64 to choose between coherent and non-coherent dma_ops?
> 
> Liviu,
> 
> I have the same feeling with Catalin. An arm64-specific implementation of
> pcibios_add_device() would be better.
> 
> No more other concerns from my side.

OK, I will make the change when returning from my holiday at the beginning of September,
when I plan to send v10.

Best regards,
Liviu

> 
> >
> >Also at some point we'll get ACPI support, so I'm not sure what we do
> >with assigning the dev->irq here but definitely of_* functions won't
> >work.
> >
> >-- 
> >Catalin
> 
> -- 
> Richard Yang
> Help you, Help me
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
-------------------
   .oooO
   (   )
    \ (  Oooo.
     \_) (   )
          ) /
         (_/

 One small step
   for me ...

[PATCH v9 02/12] PCI: OF: Parse and map the IRQ when adding the PCI device.

[Liviu Dudau]

On Tue, Aug 19, 2014 at 09:44:01AM +0800, Wei Yang wrote:
> On Mon, Aug 18, 2014 at 03:25:50PM +0100, Catalin Marinas wrote:
> >...
> >> Well, it will become necessary as old code gets dismantled and converted towards
> >> this patchset. To give you an example that I'm familiar with, for arch/arm the
> >> host bridge drivers have moved into drivers/pci/host, but they still depend/use
> >> the bios32 infrastructure that takes care of setting up the irq. When they switch
> >> to my version they would have to go and debug the "irq not being assigned" issue
> >> and it is quite likely that some of the people doing the conversion will complain
> >> about my code rather than understanding the issue. What I'm trying to do is to
> >> make switching to my patchset as painless as possible, with a cleanup to remove
> >> redundant operations coming after the switchover.
> >
> >While the goal is fine, until we see a common pattern for what needs to
> >go into pcibios_add_device() I think we should have an arm64-specific
> >implementation (and probably an arm32 specific one as well). I can see
> >powerpc uses it for setting the DMA ops. Would we have a similar need on
> >arm64 to choose between coherent and non-coherent dma_ops?
> 
> Liviu,
> 
> I have the same feeling with Catalin. An arm64-specific implementation of
> pcibios_add_device() would be better.
> 
> No more other concerns from my side.

OK, I will make the change when returning from my holiday at the beginning of September,
when I plan to send v10.

Best regards,
Liviu

> 
> >
> >Also at some point we'll get ACPI support, so I'm not sure what we do
> >with assigning the dev->irq here but definitely of_* functions won't
> >work.
> >
> >-- 
> >Catalin
> 
> -- 
> Richard Yang
> Help you, Help me
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
-------------------
   .oooO
   (   )
    \ (  Oooo.
     \_) (   )
          ) /
         (_/

 One small step
   for me ...

[PATCH v9 03/12] PCI: Introduce helper functions to deal with PCI I/O ranges.

[Liviu Dudau]

Some architectures do not have a simple view of the PCI I/O space
and instead use a range of CPU addresses that map to bus addresses.
For some architectures these ranges will be expressed by OF bindings
in a device tree file.

This patch introduces a pci_register_io_range() helper function with
a generic implementation that can be used by such architectures to
keep track of the I/O ranges described by the PCI bindings. If the
PCI_IOBASE macro is not defined that signals lack of support for PCI
and we return an error.

In order to retrieve the CPU address associated with an I/O port, a
new helper function pci_pio_to_address() is introduced. This will
search in the list of ranges registered with pci_register_io_range()
and return the CPU address that corresponds to the given port.

Cc: Grant Likely <grant.likely@linaro.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
---
 drivers/of/address.c       | 95 ++++++++++++++++++++++++++++++++++++++++++++++
 include/linux/of_address.h |  2 +
 2 files changed, 97 insertions(+)

diff --git a/drivers/of/address.c b/drivers/of/address.c
index 5edfcb0..4dab700 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -5,6 +5,7 @@
 #include <linux/module.h>
 #include <linux/of_address.h>
 #include <linux/pci_regs.h>
+#include <linux/slab.h>
 #include <linux/string.h>
 
 /* Max address size we deal with */
@@ -601,12 +602,106 @@ const __be32 *of_get_address(struct device_node *dev, int index, u64 *size,
 }
 EXPORT_SYMBOL(of_get_address);
 
+#ifdef PCI_IOBASE
+struct io_range {
+	struct list_head list;
+	phys_addr_t start;
+	resource_size_t size;
+};
+
+static LIST_HEAD(io_range_list);
+static DEFINE_SPINLOCK(io_range_lock);
+#endif
+
+/*
+ * Record the PCI IO range (expressed as CPU physical address + size).
+ * Return a negative value if an error has occured, zero otherwise
+ */
+int __weak pci_register_io_range(phys_addr_t addr, resource_size_t size)
+{
+#ifdef PCI_IOBASE
+	struct io_range *range;
+	resource_size_t allocated_size = 0;
+
+	/* check if the range hasn't been previously recorded */
+	spin_lock(&io_range_lock);
+	list_for_each_entry(range, &io_range_list, list) {
+		if (addr >= range->start && addr + size <= range->start + size)
+			return 0;
+		allocated_size += range->size;
+	}
+	spin_unlock(&io_range_lock);
+
+	/* range not registed yet, check for available space */
+	if (allocated_size + size - 1 > IO_SPACE_LIMIT) {
+		/* if it's too big check if 64K space can be reserved */
+		if (allocated_size + SZ_64K - 1 > IO_SPACE_LIMIT)
+			return -E2BIG;
+
+		size = SZ_64K;
+		pr_warn("Requested IO range too big, new size set to 64K\n");
+	}
+
+	/* add the range to the list */
+	range = kzalloc(sizeof(*range), GFP_KERNEL);
+	if (!range)
+		return -ENOMEM;
+
+	range->start = addr;
+	range->size = size;
+
+	list_add_tail(&range->list, &io_range_list);
+#endif
+
+	return 0;
+}
+
+phys_addr_t pci_pio_to_address(unsigned long pio)
+{
+	phys_addr_t address = (phys_addr_t)OF_BAD_ADDR;
+
+#ifdef PCI_IOBASE
+	struct io_range *range;
+	resource_size_t allocated_size = 0;
+
+	if (pio > IO_SPACE_LIMIT)
+		return address;
+
+	spin_lock(&io_range_lock);
+	list_for_each_entry(range, &io_range_list, list) {
+		if (pio >= allocated_size && pio < allocated_size + range->size) {
+			address = range->start + pio - allocated_size;
+			break;
+		}
+		allocated_size += range->size;
+	}
+	spin_unlock(&io_range_lock);
+#endif
+
+	return address;
+}
+
 unsigned long __weak pci_address_to_pio(phys_addr_t address)
 {
+#ifdef PCI_IOBASE
+	struct io_range *res;
+	resource_size_t offset = 0;
+
+	list_for_each_entry(res, &io_range_list, list) {
+		if (address >= res->start &&
+			address < res->start + res->size) {
+			return res->start - address + offset;
+		}
+		offset += res->size;
+	}
+
+	return (unsigned long)-1;
+#else
 	if (address > IO_SPACE_LIMIT)
 		return (unsigned long)-1;
 
 	return (unsigned long) address;
+#endif
 }
 
 static int __of_address_to_resource(struct device_node *dev,
diff --git a/include/linux/of_address.h b/include/linux/of_address.h
index c13b878..28e6836 100644
--- a/include/linux/of_address.h
+++ b/include/linux/of_address.h
@@ -55,7 +55,9 @@ extern void __iomem *of_iomap(struct device_node *device, int index);
 extern const __be32 *of_get_address(struct device_node *dev, int index,
 			   u64 *size, unsigned int *flags);
 
+extern int pci_register_io_range(phys_addr_t addr, resource_size_t size);
 extern unsigned long pci_address_to_pio(phys_addr_t addr);
+extern phys_addr_t pci_pio_to_address(unsigned long pio);
 
 extern int of_pci_range_parser_init(struct of_pci_range_parser *parser,
 			struct device_node *node);
-- 
2.0.4

[PATCH v9 03/12] PCI: Introduce helper functions to deal with PCI I/O ranges.

[Liviu Dudau]

Some architectures do not have a simple view of the PCI I/O space
and instead use a range of CPU addresses that map to bus addresses.
For some architectures these ranges will be expressed by OF bindings
in a device tree file.

This patch introduces a pci_register_io_range() helper function with
a generic implementation that can be used by such architectures to
keep track of the I/O ranges described by the PCI bindings. If the
PCI_IOBASE macro is not defined that signals lack of support for PCI
and we return an error.

In order to retrieve the CPU address associated with an I/O port, a
new helper function pci_pio_to_address() is introduced. This will
search in the list of ranges registered with pci_register_io_range()
and return the CPU address that corresponds to the given port.

Cc: Grant Likely <grant.likely@linaro.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
---
 drivers/of/address.c       | 95 ++++++++++++++++++++++++++++++++++++++++++++++
 include/linux/of_address.h |  2 +
 2 files changed, 97 insertions(+)

diff --git a/drivers/of/address.c b/drivers/of/address.c
index 5edfcb0..4dab700 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -5,6 +5,7 @@
 #include <linux/module.h>
 #include <linux/of_address.h>
 #include <linux/pci_regs.h>
+#include <linux/slab.h>
 #include <linux/string.h>
 
 /* Max address size we deal with */
@@ -601,12 +602,106 @@ const __be32 *of_get_address(struct device_node *dev, int index, u64 *size,
 }
 EXPORT_SYMBOL(of_get_address);
 
+#ifdef PCI_IOBASE
+struct io_range {
+	struct list_head list;
+	phys_addr_t start;
+	resource_size_t size;
+};
+
+static LIST_HEAD(io_range_list);
+static DEFINE_SPINLOCK(io_range_lock);
+#endif
+
+/*
+ * Record the PCI IO range (expressed as CPU physical address + size).
+ * Return a negative value if an error has occured, zero otherwise
+ */
+int __weak pci_register_io_range(phys_addr_t addr, resource_size_t size)
+{
+#ifdef PCI_IOBASE
+	struct io_range *range;
+	resource_size_t allocated_size = 0;
+
+	/* check if the range hasn't been previously recorded */
+	spin_lock(&io_range_lock);
+	list_for_each_entry(range, &io_range_list, list) {
+		if (addr >= range->start && addr + size <= range->start + size)
+			return 0;
+		allocated_size += range->size;
+	}
+	spin_unlock(&io_range_lock);
+
+	/* range not registed yet, check for available space */
+	if (allocated_size + size - 1 > IO_SPACE_LIMIT) {
+		/* if it's too big check if 64K space can be reserved */
+		if (allocated_size + SZ_64K - 1 > IO_SPACE_LIMIT)
+			return -E2BIG;
+
+		size = SZ_64K;
+		pr_warn("Requested IO range too big, new size set to 64K\n");
+	}
+
+	/* add the range to the list */
+	range = kzalloc(sizeof(*range), GFP_KERNEL);
+	if (!range)
+		return -ENOMEM;
+
+	range->start = addr;
+	range->size = size;
+
+	list_add_tail(&range->list, &io_range_list);
+#endif
+
+	return 0;
+}
+
+phys_addr_t pci_pio_to_address(unsigned long pio)
+{
+	phys_addr_t address = (phys_addr_t)OF_BAD_ADDR;
+
+#ifdef PCI_IOBASE
+	struct io_range *range;
+	resource_size_t allocated_size = 0;
+
+	if (pio > IO_SPACE_LIMIT)
+		return address;
+
+	spin_lock(&io_range_lock);
+	list_for_each_entry(range, &io_range_list, list) {
+		if (pio >= allocated_size && pio < allocated_size + range->size) {
+			address = range->start + pio - allocated_size;
+			break;
+		}
+		allocated_size += range->size;
+	}
+	spin_unlock(&io_range_lock);
+#endif
+
+	return address;
+}
+
 unsigned long __weak pci_address_to_pio(phys_addr_t address)
 {
+#ifdef PCI_IOBASE
+	struct io_range *res;
+	resource_size_t offset = 0;
+
+	list_for_each_entry(res, &io_range_list, list) {
+		if (address >= res->start &&
+			address < res->start + res->size) {
+			return res->start - address + offset;
+		}
+		offset += res->size;
+	}
+
+	return (unsigned long)-1;
+#else
 	if (address > IO_SPACE_LIMIT)
 		return (unsigned long)-1;
 
 	return (unsigned long) address;
+#endif
 }
 
 static int __of_address_to_resource(struct device_node *dev,
diff --git a/include/linux/of_address.h b/include/linux/of_address.h
index c13b878..28e6836 100644
--- a/include/linux/of_address.h
+++ b/include/linux/of_address.h
@@ -55,7 +55,9 @@ extern void __iomem *of_iomap(struct device_node *device, int index);
 extern const __be32 *of_get_address(struct device_node *dev, int index,
 			   u64 *size, unsigned int *flags);
 
+extern int pci_register_io_range(phys_addr_t addr, resource_size_t size);
 extern unsigned long pci_address_to_pio(phys_addr_t addr);
+extern phys_addr_t pci_pio_to_address(unsigned long pio);
 
 extern int of_pci_range_parser_init(struct of_pci_range_parser *parser,
 			struct device_node *node);
-- 
2.0.4

[PATCH v9 03/12] PCI: Introduce helper functions to deal with PCI I/O ranges.

[Liviu Dudau]

Some architectures do not have a simple view of the PCI I/O space
and instead use a range of CPU addresses that map to bus addresses.
For some architectures these ranges will be expressed by OF bindings
in a device tree file.

This patch introduces a pci_register_io_range() helper function with
a generic implementation that can be used by such architectures to
keep track of the I/O ranges described by the PCI bindings. If the
PCI_IOBASE macro is not defined that signals lack of support for PCI
and we return an error.

In order to retrieve the CPU address associated with an I/O port, a
new helper function pci_pio_to_address() is introduced. This will
search in the list of ranges registered with pci_register_io_range()
and return the CPU address that corresponds to the given port.

Cc: Grant Likely <grant.likely@linaro.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
---
 drivers/of/address.c       | 95 ++++++++++++++++++++++++++++++++++++++++++++++
 include/linux/of_address.h |  2 +
 2 files changed, 97 insertions(+)

diff --git a/drivers/of/address.c b/drivers/of/address.c
index 5edfcb0..4dab700 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -5,6 +5,7 @@
 #include <linux/module.h>
 #include <linux/of_address.h>
 #include <linux/pci_regs.h>
+#include <linux/slab.h>
 #include <linux/string.h>
 
 /* Max address size we deal with */
@@ -601,12 +602,106 @@ const __be32 *of_get_address(struct device_node *dev, int index, u64 *size,
 }
 EXPORT_SYMBOL(of_get_address);
 
+#ifdef PCI_IOBASE
+struct io_range {
+	struct list_head list;
+	phys_addr_t start;
+	resource_size_t size;
+};
+
+static LIST_HEAD(io_range_list);
+static DEFINE_SPINLOCK(io_range_lock);
+#endif
+
+/*
+ * Record the PCI IO range (expressed as CPU physical address + size).
+ * Return a negative value if an error has occured, zero otherwise
+ */
+int __weak pci_register_io_range(phys_addr_t addr, resource_size_t size)
+{
+#ifdef PCI_IOBASE
+	struct io_range *range;
+	resource_size_t allocated_size = 0;
+
+	/* check if the range hasn't been previously recorded */
+	spin_lock(&io_range_lock);
+	list_for_each_entry(range, &io_range_list, list) {
+		if (addr >= range->start && addr + size <= range->start + size)
+			return 0;
+		allocated_size += range->size;
+	}
+	spin_unlock(&io_range_lock);
+
+	/* range not registed yet, check for available space */
+	if (allocated_size + size - 1 > IO_SPACE_LIMIT) {
+		/* if it's too big check if 64K space can be reserved */
+		if (allocated_size + SZ_64K - 1 > IO_SPACE_LIMIT)
+			return -E2BIG;
+
+		size = SZ_64K;
+		pr_warn("Requested IO range too big, new size set to 64K\n");
+	}
+
+	/* add the range to the list */
+	range = kzalloc(sizeof(*range), GFP_KERNEL);
+	if (!range)
+		return -ENOMEM;
+
+	range->start = addr;
+	range->size = size;
+
+	list_add_tail(&range->list, &io_range_list);
+#endif
+
+	return 0;
+}
+
+phys_addr_t pci_pio_to_address(unsigned long pio)
+{
+	phys_addr_t address = (phys_addr_t)OF_BAD_ADDR;
+
+#ifdef PCI_IOBASE
+	struct io_range *range;
+	resource_size_t allocated_size = 0;
+
+	if (pio > IO_SPACE_LIMIT)
+		return address;
+
+	spin_lock(&io_range_lock);
+	list_for_each_entry(range, &io_range_list, list) {
+		if (pio >= allocated_size && pio < allocated_size + range->size) {
+			address = range->start + pio - allocated_size;
+			break;
+		}
+		allocated_size += range->size;
+	}
+	spin_unlock(&io_range_lock);
+#endif
+
+	return address;
+}
+
 unsigned long __weak pci_address_to_pio(phys_addr_t address)
 {
+#ifdef PCI_IOBASE
+	struct io_range *res;
+	resource_size_t offset = 0;
+
+	list_for_each_entry(res, &io_range_list, list) {
+		if (address >= res->start &&
+			address < res->start + res->size) {
+			return res->start - address + offset;
+		}
+		offset += res->size;
+	}
+
+	return (unsigned long)-1;
+#else
 	if (address > IO_SPACE_LIMIT)
 		return (unsigned long)-1;
 
 	return (unsigned long) address;
+#endif
 }
 
 static int __of_address_to_resource(struct device_node *dev,
diff --git a/include/linux/of_address.h b/include/linux/of_address.h
index c13b878..28e6836 100644
--- a/include/linux/of_address.h
+++ b/include/linux/of_address.h
@@ -55,7 +55,9 @@ extern void __iomem *of_iomap(struct device_node *device, int index);
 extern const __be32 *of_get_address(struct device_node *dev, int index,
 			   u64 *size, unsigned int *flags);
 
+extern int pci_register_io_range(phys_addr_t addr, resource_size_t size);
 extern unsigned long pci_address_to_pio(phys_addr_t addr);
+extern phys_addr_t pci_pio_to_address(unsigned long pio);
 
 extern int of_pci_range_parser_init(struct of_pci_range_parser *parser,
 			struct device_node *node);
-- 
2.0.4

Re: [PATCH v9 03/12] PCI: Introduce helper functions to deal with PCI I/O ranges.

[Catalin Marinas]

On Tue, Aug 12, 2014 at 05:25:16PM +0100, Liviu Dudau wrote:
> Some architectures do not have a simple view of the PCI I/O space
> and instead use a range of CPU addresses that map to bus addresses.
> For some architectures these ranges will be expressed by OF bindings
> in a device tree file.
> 
> This patch introduces a pci_register_io_range() helper function with
> a generic implementation that can be used by such architectures to
> keep track of the I/O ranges described by the PCI bindings. If the
> PCI_IOBASE macro is not defined that signals lack of support for PCI
> and we return an error.
> 
> In order to retrieve the CPU address associated with an I/O port, a
> new helper function pci_pio_to_address() is introduced. This will
> search in the list of ranges registered with pci_register_io_range()
> and return the CPU address that corresponds to the given port.
> 
> Cc: Grant Likely <grant.likely@linaro.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
> ---
>  drivers/of/address.c       | 95 ++++++++++++++++++++++++++++++++++++++++++++++
>  include/linux/of_address.h |  2 +
>  2 files changed, 97 insertions(+)

Actually, I think we moved too much code into drivers/of/. Is there
anything OF specific about this code to live here (apart from
OF_BAD_ADDR)? I think driver/pci/ more appropriate?

Otherwise it looks fine to me.

-- 
Catalin

[PATCH v9 03/12] PCI: Introduce helper functions to deal with PCI I/O ranges.

[Catalin Marinas]

On Tue, Aug 12, 2014 at 05:25:16PM +0100, Liviu Dudau wrote:
> Some architectures do not have a simple view of the PCI I/O space
> and instead use a range of CPU addresses that map to bus addresses.
> For some architectures these ranges will be expressed by OF bindings
> in a device tree file.
> 
> This patch introduces a pci_register_io_range() helper function with
> a generic implementation that can be used by such architectures to
> keep track of the I/O ranges described by the PCI bindings. If the
> PCI_IOBASE macro is not defined that signals lack of support for PCI
> and we return an error.
> 
> In order to retrieve the CPU address associated with an I/O port, a
> new helper function pci_pio_to_address() is introduced. This will
> search in the list of ranges registered with pci_register_io_range()
> and return the CPU address that corresponds to the given port.
> 
> Cc: Grant Likely <grant.likely@linaro.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
> ---
>  drivers/of/address.c       | 95 ++++++++++++++++++++++++++++++++++++++++++++++
>  include/linux/of_address.h |  2 +
>  2 files changed, 97 insertions(+)

Actually, I think we moved too much code into drivers/of/. Is there
anything OF specific about this code to live here (apart from
OF_BAD_ADDR)? I think driver/pci/ more appropriate?

Otherwise it looks fine to me.

-- 
Catalin

Re: [PATCH v9 03/12] PCI: Introduce helper functions to deal with PCI I/O ranges.

[Catalin Marinas]

On Tue, Aug 12, 2014 at 05:25:16PM +0100, Liviu Dudau wrote:
> Some architectures do not have a simple view of the PCI I/O space
> and instead use a range of CPU addresses that map to bus addresses.
> For some architectures these ranges will be expressed by OF bindings
> in a device tree file.
> 
> This patch introduces a pci_register_io_range() helper function with
> a generic implementation that can be used by such architectures to
> keep track of the I/O ranges described by the PCI bindings. If the
> PCI_IOBASE macro is not defined that signals lack of support for PCI
> and we return an error.
> 
> In order to retrieve the CPU address associated with an I/O port, a
> new helper function pci_pio_to_address() is introduced. This will
> search in the list of ranges registered with pci_register_io_range()
> and return the CPU address that corresponds to the given port.
> 
> Cc: Grant Likely <grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Cc: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
> Signed-off-by: Liviu Dudau <Liviu.Dudau-5wv7dgnIgG8@public.gmane.org>
> ---
>  drivers/of/address.c       | 95 ++++++++++++++++++++++++++++++++++++++++++++++
>  include/linux/of_address.h |  2 +
>  2 files changed, 97 insertions(+)

Actually, I think we moved too much code into drivers/of/. Is there
anything OF specific about this code to live here (apart from
OF_BAD_ADDR)? I think driver/pci/ more appropriate?

Otherwise it looks fine to me.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 03/12] PCI: Introduce helper functions to deal with PCI I/O ranges.

[Liviu Dudau]

On Mon, Aug 18, 2014 at 03:26:04PM +0100, Catalin Marinas wrote:
> On Tue, Aug 12, 2014 at 05:25:16PM +0100, Liviu Dudau wrote:
> > Some architectures do not have a simple view of the PCI I/O space
> > and instead use a range of CPU addresses that map to bus addresses.
> > For some architectures these ranges will be expressed by OF bindings
> > in a device tree file.
> > 
> > This patch introduces a pci_register_io_range() helper function with
> > a generic implementation that can be used by such architectures to
> > keep track of the I/O ranges described by the PCI bindings. If the
> > PCI_IOBASE macro is not defined that signals lack of support for PCI
> > and we return an error.
> > 
> > In order to retrieve the CPU address associated with an I/O port, a
> > new helper function pci_pio_to_address() is introduced. This will
> > search in the list of ranges registered with pci_register_io_range()
> > and return the CPU address that corresponds to the given port.
> > 
> > Cc: Grant Likely <grant.likely@linaro.org>
> > Cc: Rob Herring <robh+dt@kernel.org>
> > Cc: Arnd Bergmann <arnd@arndb.de>
> > Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
> > ---
> >  drivers/of/address.c       | 95 ++++++++++++++++++++++++++++++++++++++++++++++
> >  include/linux/of_address.h |  2 +
> >  2 files changed, 97 insertions(+)
> 
> Actually, I think we moved too much code into drivers/of/. Is there
> anything OF specific about this code to live here (apart from
> OF_BAD_ADDR)? I think driver/pci/ more appropriate?

I have no strong preference for one place vs the other. While this does
not use any OF specific code, it should be called only from OF enabled
code. So the relationship is not one of depending on of_* but on being
dependent on.

> 
> Otherwise it looks fine to me.

Thanks! Would be nice if you can prod at the kernel summit other maintainers
for ACKs.

Best regards,
Liviu

> 
> -- 
> Catalin
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
-------------------
   .oooO
   (   )
    \ (  Oooo.
     \_) (   )
          ) /
         (_/

 One small step
   for me ...

[PATCH v9 03/12] PCI: Introduce helper functions to deal with PCI I/O ranges.

[Liviu Dudau]

On Mon, Aug 18, 2014 at 03:26:04PM +0100, Catalin Marinas wrote:
> On Tue, Aug 12, 2014 at 05:25:16PM +0100, Liviu Dudau wrote:
> > Some architectures do not have a simple view of the PCI I/O space
> > and instead use a range of CPU addresses that map to bus addresses.
> > For some architectures these ranges will be expressed by OF bindings
> > in a device tree file.
> > 
> > This patch introduces a pci_register_io_range() helper function with
> > a generic implementation that can be used by such architectures to
> > keep track of the I/O ranges described by the PCI bindings. If the
> > PCI_IOBASE macro is not defined that signals lack of support for PCI
> > and we return an error.
> > 
> > In order to retrieve the CPU address associated with an I/O port, a
> > new helper function pci_pio_to_address() is introduced. This will
> > search in the list of ranges registered with pci_register_io_range()
> > and return the CPU address that corresponds to the given port.
> > 
> > Cc: Grant Likely <grant.likely@linaro.org>
> > Cc: Rob Herring <robh+dt@kernel.org>
> > Cc: Arnd Bergmann <arnd@arndb.de>
> > Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
> > ---
> >  drivers/of/address.c       | 95 ++++++++++++++++++++++++++++++++++++++++++++++
> >  include/linux/of_address.h |  2 +
> >  2 files changed, 97 insertions(+)
> 
> Actually, I think we moved too much code into drivers/of/. Is there
> anything OF specific about this code to live here (apart from
> OF_BAD_ADDR)? I think driver/pci/ more appropriate?

I have no strong preference for one place vs the other. While this does
not use any OF specific code, it should be called only from OF enabled
code. So the relationship is not one of depending on of_* but on being
dependent on.

> 
> Otherwise it looks fine to me.

Thanks! Would be nice if you can prod at the kernel summit other maintainers
for ACKs.

Best regards,
Liviu

> 
> -- 
> Catalin
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
-------------------
   .oooO
   (   )
    \ (  Oooo.
     \_) (   )
          ) /
         (_/

 One small step
   for me ...

Re: [PATCH v9 03/12] PCI: Introduce helper functions to deal with PCI I/O ranges.

[Catalin Marinas]

On Mon, Aug 18, 2014 at 10:34:46PM +0100, Liviu Dudau wrote:
> On Mon, Aug 18, 2014 at 03:26:04PM +0100, Catalin Marinas wrote:
> > On Tue, Aug 12, 2014 at 05:25:16PM +0100, Liviu Dudau wrote:
> > > Some architectures do not have a simple view of the PCI I/O space
> > > and instead use a range of CPU addresses that map to bus addresses.
> > > For some architectures these ranges will be expressed by OF bindings
> > > in a device tree file.
> > > 
> > > This patch introduces a pci_register_io_range() helper function with
> > > a generic implementation that can be used by such architectures to
> > > keep track of the I/O ranges described by the PCI bindings. If the
> > > PCI_IOBASE macro is not defined that signals lack of support for PCI
> > > and we return an error.
> > > 
> > > In order to retrieve the CPU address associated with an I/O port, a
> > > new helper function pci_pio_to_address() is introduced. This will
> > > search in the list of ranges registered with pci_register_io_range()
> > > and return the CPU address that corresponds to the given port.
> > > 
> > > Cc: Grant Likely <grant.likely@linaro.org>
> > > Cc: Rob Herring <robh+dt@kernel.org>
> > > Cc: Arnd Bergmann <arnd@arndb.de>
> > > Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
> > > ---
> > >  drivers/of/address.c       | 95 ++++++++++++++++++++++++++++++++++++++++++++++
> > >  include/linux/of_address.h |  2 +
> > >  2 files changed, 97 insertions(+)
> > 
> > Actually, I think we moved too much code into drivers/of/. Is there
> > anything OF specific about this code to live here (apart from
> > OF_BAD_ADDR)? I think driver/pci/ more appropriate?
> 
> I have no strong preference for one place vs the other. While this does
> not use any OF specific code, it should be called only from OF enabled
> code. So the relationship is not one of depending on of_* but on being
> dependent on.

In this case it's probably ok to keep them here for the time being.

I wonder whether it would also be useful for ACPI. But I have no idea
how ACPI would fit with the ACPI patches.

-- 
Catalin

[PATCH v9 03/12] PCI: Introduce helper functions to deal with PCI I/O ranges.

[Catalin Marinas]

On Mon, Aug 18, 2014 at 10:34:46PM +0100, Liviu Dudau wrote:
> On Mon, Aug 18, 2014 at 03:26:04PM +0100, Catalin Marinas wrote:
> > On Tue, Aug 12, 2014 at 05:25:16PM +0100, Liviu Dudau wrote:
> > > Some architectures do not have a simple view of the PCI I/O space
> > > and instead use a range of CPU addresses that map to bus addresses.
> > > For some architectures these ranges will be expressed by OF bindings
> > > in a device tree file.
> > > 
> > > This patch introduces a pci_register_io_range() helper function with
> > > a generic implementation that can be used by such architectures to
> > > keep track of the I/O ranges described by the PCI bindings. If the
> > > PCI_IOBASE macro is not defined that signals lack of support for PCI
> > > and we return an error.
> > > 
> > > In order to retrieve the CPU address associated with an I/O port, a
> > > new helper function pci_pio_to_address() is introduced. This will
> > > search in the list of ranges registered with pci_register_io_range()
> > > and return the CPU address that corresponds to the given port.
> > > 
> > > Cc: Grant Likely <grant.likely@linaro.org>
> > > Cc: Rob Herring <robh+dt@kernel.org>
> > > Cc: Arnd Bergmann <arnd@arndb.de>
> > > Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
> > > ---
> > >  drivers/of/address.c       | 95 ++++++++++++++++++++++++++++++++++++++++++++++
> > >  include/linux/of_address.h |  2 +
> > >  2 files changed, 97 insertions(+)
> > 
> > Actually, I think we moved too much code into drivers/of/. Is there
> > anything OF specific about this code to live here (apart from
> > OF_BAD_ADDR)? I think driver/pci/ more appropriate?
> 
> I have no strong preference for one place vs the other. While this does
> not use any OF specific code, it should be called only from OF enabled
> code. So the relationship is not one of depending on of_* but on being
> dependent on.

In this case it's probably ok to keep them here for the time being.

I wonder whether it would also be useful for ACPI. But I have no idea
how ACPI would fit with the ACPI patches.

-- 
Catalin

Re: [PATCH v9 03/12] PCI: Introduce helper functions to deal with PCI I/O ranges.

[Rob Herring]

On Tue, Aug 12, 2014 at 11:25 AM, Liviu Dudau <Liviu.Dudau@arm.com> wrote:
> Some architectures do not have a simple view of the PCI I/O space
> and instead use a range of CPU addresses that map to bus addresses.
> For some architectures these ranges will be expressed by OF bindings
> in a device tree file.
>
> This patch introduces a pci_register_io_range() helper function with
> a generic implementation that can be used by such architectures to
> keep track of the I/O ranges described by the PCI bindings. If the
> PCI_IOBASE macro is not defined that signals lack of support for PCI
> and we return an error.
>
> In order to retrieve the CPU address associated with an I/O port, a
> new helper function pci_pio_to_address() is introduced. This will
> search in the list of ranges registered with pci_register_io_range()
> and return the CPU address that corresponds to the given port.
>
> Cc: Grant Likely <grant.likely@linaro.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

Acked-by: Rob Herring <robh@kernel.org>


> ---
>  drivers/of/address.c       | 95 ++++++++++++++++++++++++++++++++++++++++++++++
>  include/linux/of_address.h |  2 +
>  2 files changed, 97 insertions(+)
>
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 5edfcb0..4dab700 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -5,6 +5,7 @@
>  #include <linux/module.h>
>  #include <linux/of_address.h>
>  #include <linux/pci_regs.h>
> +#include <linux/slab.h>
>  #include <linux/string.h>
>
>  /* Max address size we deal with */
> @@ -601,12 +602,106 @@ const __be32 *of_get_address(struct device_node *dev, int index, u64 *size,
>  }
>  EXPORT_SYMBOL(of_get_address);
>
> +#ifdef PCI_IOBASE
> +struct io_range {
> +       struct list_head list;
> +       phys_addr_t start;
> +       resource_size_t size;
> +};
> +
> +static LIST_HEAD(io_range_list);
> +static DEFINE_SPINLOCK(io_range_lock);
> +#endif
> +
> +/*
> + * Record the PCI IO range (expressed as CPU physical address + size).
> + * Return a negative value if an error has occured, zero otherwise
> + */
> +int __weak pci_register_io_range(phys_addr_t addr, resource_size_t size)
> +{
> +#ifdef PCI_IOBASE
> +       struct io_range *range;
> +       resource_size_t allocated_size = 0;
> +
> +       /* check if the range hasn't been previously recorded */
> +       spin_lock(&io_range_lock);
> +       list_for_each_entry(range, &io_range_list, list) {
> +               if (addr >= range->start && addr + size <= range->start + size)
> +                       return 0;
> +               allocated_size += range->size;
> +       }
> +       spin_unlock(&io_range_lock);
> +
> +       /* range not registed yet, check for available space */
> +       if (allocated_size + size - 1 > IO_SPACE_LIMIT) {
> +               /* if it's too big check if 64K space can be reserved */
> +               if (allocated_size + SZ_64K - 1 > IO_SPACE_LIMIT)
> +                       return -E2BIG;
> +
> +               size = SZ_64K;
> +               pr_warn("Requested IO range too big, new size set to 64K\n");
> +       }
> +
> +       /* add the range to the list */
> +       range = kzalloc(sizeof(*range), GFP_KERNEL);
> +       if (!range)
> +               return -ENOMEM;
> +
> +       range->start = addr;
> +       range->size = size;
> +
> +       list_add_tail(&range->list, &io_range_list);
> +#endif
> +
> +       return 0;
> +}
> +
> +phys_addr_t pci_pio_to_address(unsigned long pio)
> +{
> +       phys_addr_t address = (phys_addr_t)OF_BAD_ADDR;
> +
> +#ifdef PCI_IOBASE
> +       struct io_range *range;
> +       resource_size_t allocated_size = 0;
> +
> +       if (pio > IO_SPACE_LIMIT)
> +               return address;
> +
> +       spin_lock(&io_range_lock);
> +       list_for_each_entry(range, &io_range_list, list) {
> +               if (pio >= allocated_size && pio < allocated_size + range->size) {
> +                       address = range->start + pio - allocated_size;
> +                       break;
> +               }
> +               allocated_size += range->size;
> +       }
> +       spin_unlock(&io_range_lock);
> +#endif
> +
> +       return address;
> +}
> +
>  unsigned long __weak pci_address_to_pio(phys_addr_t address)
>  {
> +#ifdef PCI_IOBASE
> +       struct io_range *res;
> +       resource_size_t offset = 0;
> +
> +       list_for_each_entry(res, &io_range_list, list) {
> +               if (address >= res->start &&
> +                       address < res->start + res->size) {
> +                       return res->start - address + offset;
> +               }
> +               offset += res->size;
> +       }
> +
> +       return (unsigned long)-1;
> +#else
>         if (address > IO_SPACE_LIMIT)
>                 return (unsigned long)-1;
>
>         return (unsigned long) address;
> +#endif
>  }
>
>  static int __of_address_to_resource(struct device_node *dev,
> diff --git a/include/linux/of_address.h b/include/linux/of_address.h
> index c13b878..28e6836 100644
> --- a/include/linux/of_address.h
> +++ b/include/linux/of_address.h
> @@ -55,7 +55,9 @@ extern void __iomem *of_iomap(struct device_node *device, int index);
>  extern const __be32 *of_get_address(struct device_node *dev, int index,
>                            u64 *size, unsigned int *flags);
>
> +extern int pci_register_io_range(phys_addr_t addr, resource_size_t size);
>  extern unsigned long pci_address_to_pio(phys_addr_t addr);
> +extern phys_addr_t pci_pio_to_address(unsigned long pio);
>
>  extern int of_pci_range_parser_init(struct of_pci_range_parser *parser,
>                         struct device_node *node);
> --
> 2.0.4
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v9 03/12] PCI: Introduce helper functions to deal with PCI I/O ranges.

[Rob Herring]

On Tue, Aug 12, 2014 at 11:25 AM, Liviu Dudau <Liviu.Dudau@arm.com> wrote:
> Some architectures do not have a simple view of the PCI I/O space
> and instead use a range of CPU addresses that map to bus addresses.
> For some architectures these ranges will be expressed by OF bindings
> in a device tree file.
>
> This patch introduces a pci_register_io_range() helper function with
> a generic implementation that can be used by such architectures to
> keep track of the I/O ranges described by the PCI bindings. If the
> PCI_IOBASE macro is not defined that signals lack of support for PCI
> and we return an error.
>
> In order to retrieve the CPU address associated with an I/O port, a
> new helper function pci_pio_to_address() is introduced. This will
> search in the list of ranges registered with pci_register_io_range()
> and return the CPU address that corresponds to the given port.
>
> Cc: Grant Likely <grant.likely@linaro.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

Acked-by: Rob Herring <robh@kernel.org>


> ---
>  drivers/of/address.c       | 95 ++++++++++++++++++++++++++++++++++++++++++++++
>  include/linux/of_address.h |  2 +
>  2 files changed, 97 insertions(+)
>
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 5edfcb0..4dab700 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -5,6 +5,7 @@
>  #include <linux/module.h>
>  #include <linux/of_address.h>
>  #include <linux/pci_regs.h>
> +#include <linux/slab.h>
>  #include <linux/string.h>
>
>  /* Max address size we deal with */
> @@ -601,12 +602,106 @@ const __be32 *of_get_address(struct device_node *dev, int index, u64 *size,
>  }
>  EXPORT_SYMBOL(of_get_address);
>
> +#ifdef PCI_IOBASE
> +struct io_range {
> +       struct list_head list;
> +       phys_addr_t start;
> +       resource_size_t size;
> +};
> +
> +static LIST_HEAD(io_range_list);
> +static DEFINE_SPINLOCK(io_range_lock);
> +#endif
> +
> +/*
> + * Record the PCI IO range (expressed as CPU physical address + size).
> + * Return a negative value if an error has occured, zero otherwise
> + */
> +int __weak pci_register_io_range(phys_addr_t addr, resource_size_t size)
> +{
> +#ifdef PCI_IOBASE
> +       struct io_range *range;
> +       resource_size_t allocated_size = 0;
> +
> +       /* check if the range hasn't been previously recorded */
> +       spin_lock(&io_range_lock);
> +       list_for_each_entry(range, &io_range_list, list) {
> +               if (addr >= range->start && addr + size <= range->start + size)
> +                       return 0;
> +               allocated_size += range->size;
> +       }
> +       spin_unlock(&io_range_lock);
> +
> +       /* range not registed yet, check for available space */
> +       if (allocated_size + size - 1 > IO_SPACE_LIMIT) {
> +               /* if it's too big check if 64K space can be reserved */
> +               if (allocated_size + SZ_64K - 1 > IO_SPACE_LIMIT)
> +                       return -E2BIG;
> +
> +               size = SZ_64K;
> +               pr_warn("Requested IO range too big, new size set to 64K\n");
> +       }
> +
> +       /* add the range to the list */
> +       range = kzalloc(sizeof(*range), GFP_KERNEL);
> +       if (!range)
> +               return -ENOMEM;
> +
> +       range->start = addr;
> +       range->size = size;
> +
> +       list_add_tail(&range->list, &io_range_list);
> +#endif
> +
> +       return 0;
> +}
> +
> +phys_addr_t pci_pio_to_address(unsigned long pio)
> +{
> +       phys_addr_t address = (phys_addr_t)OF_BAD_ADDR;
> +
> +#ifdef PCI_IOBASE
> +       struct io_range *range;
> +       resource_size_t allocated_size = 0;
> +
> +       if (pio > IO_SPACE_LIMIT)
> +               return address;
> +
> +       spin_lock(&io_range_lock);
> +       list_for_each_entry(range, &io_range_list, list) {
> +               if (pio >= allocated_size && pio < allocated_size + range->size) {
> +                       address = range->start + pio - allocated_size;
> +                       break;
> +               }
> +               allocated_size += range->size;
> +       }
> +       spin_unlock(&io_range_lock);
> +#endif
> +
> +       return address;
> +}
> +
>  unsigned long __weak pci_address_to_pio(phys_addr_t address)
>  {
> +#ifdef PCI_IOBASE
> +       struct io_range *res;
> +       resource_size_t offset = 0;
> +
> +       list_for_each_entry(res, &io_range_list, list) {
> +               if (address >= res->start &&
> +                       address < res->start + res->size) {
> +                       return res->start - address + offset;
> +               }
> +               offset += res->size;
> +       }
> +
> +       return (unsigned long)-1;
> +#else
>         if (address > IO_SPACE_LIMIT)
>                 return (unsigned long)-1;
>
>         return (unsigned long) address;
> +#endif
>  }
>
>  static int __of_address_to_resource(struct device_node *dev,
> diff --git a/include/linux/of_address.h b/include/linux/of_address.h
> index c13b878..28e6836 100644
> --- a/include/linux/of_address.h
> +++ b/include/linux/of_address.h
> @@ -55,7 +55,9 @@ extern void __iomem *of_iomap(struct device_node *device, int index);
>  extern const __be32 *of_get_address(struct device_node *dev, int index,
>                            u64 *size, unsigned int *flags);
>
> +extern int pci_register_io_range(phys_addr_t addr, resource_size_t size);
>  extern unsigned long pci_address_to_pio(phys_addr_t addr);
> +extern phys_addr_t pci_pio_to_address(unsigned long pio);
>
>  extern int of_pci_range_parser_init(struct of_pci_range_parser *parser,
>                         struct device_node *node);
> --
> 2.0.4
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v9 03/12] PCI: Introduce helper functions to deal with PCI I/O ranges.

[Rob Herring]

On Tue, Aug 12, 2014 at 11:25 AM, Liviu Dudau <Liviu.Dudau-5wv7dgnIgG8@public.gmane.org> wrote:
> Some architectures do not have a simple view of the PCI I/O space
> and instead use a range of CPU addresses that map to bus addresses.
> For some architectures these ranges will be expressed by OF bindings
> in a device tree file.
>
> This patch introduces a pci_register_io_range() helper function with
> a generic implementation that can be used by such architectures to
> keep track of the I/O ranges described by the PCI bindings. If the
> PCI_IOBASE macro is not defined that signals lack of support for PCI
> and we return an error.
>
> In order to retrieve the CPU address associated with an I/O port, a
> new helper function pci_pio_to_address() is introduced. This will
> search in the list of ranges registered with pci_register_io_range()
> and return the CPU address that corresponds to the given port.
>
> Cc: Grant Likely <grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Cc: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
> Signed-off-by: Liviu Dudau <Liviu.Dudau-5wv7dgnIgG8@public.gmane.org>

Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>


> ---
>  drivers/of/address.c       | 95 ++++++++++++++++++++++++++++++++++++++++++++++
>  include/linux/of_address.h |  2 +
>  2 files changed, 97 insertions(+)
>
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 5edfcb0..4dab700 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -5,6 +5,7 @@
>  #include <linux/module.h>
>  #include <linux/of_address.h>
>  #include <linux/pci_regs.h>
> +#include <linux/slab.h>
>  #include <linux/string.h>
>
>  /* Max address size we deal with */
> @@ -601,12 +602,106 @@ const __be32 *of_get_address(struct device_node *dev, int index, u64 *size,
>  }
>  EXPORT_SYMBOL(of_get_address);
>
> +#ifdef PCI_IOBASE
> +struct io_range {
> +       struct list_head list;
> +       phys_addr_t start;
> +       resource_size_t size;
> +};
> +
> +static LIST_HEAD(io_range_list);
> +static DEFINE_SPINLOCK(io_range_lock);
> +#endif
> +
> +/*
> + * Record the PCI IO range (expressed as CPU physical address + size).
> + * Return a negative value if an error has occured, zero otherwise
> + */
> +int __weak pci_register_io_range(phys_addr_t addr, resource_size_t size)
> +{
> +#ifdef PCI_IOBASE
> +       struct io_range *range;
> +       resource_size_t allocated_size = 0;
> +
> +       /* check if the range hasn't been previously recorded */
> +       spin_lock(&io_range_lock);
> +       list_for_each_entry(range, &io_range_list, list) {
> +               if (addr >= range->start && addr + size <= range->start + size)
> +                       return 0;
> +               allocated_size += range->size;
> +       }
> +       spin_unlock(&io_range_lock);
> +
> +       /* range not registed yet, check for available space */
> +       if (allocated_size + size - 1 > IO_SPACE_LIMIT) {
> +               /* if it's too big check if 64K space can be reserved */
> +               if (allocated_size + SZ_64K - 1 > IO_SPACE_LIMIT)
> +                       return -E2BIG;
> +
> +               size = SZ_64K;
> +               pr_warn("Requested IO range too big, new size set to 64K\n");
> +       }
> +
> +       /* add the range to the list */
> +       range = kzalloc(sizeof(*range), GFP_KERNEL);
> +       if (!range)
> +               return -ENOMEM;
> +
> +       range->start = addr;
> +       range->size = size;
> +
> +       list_add_tail(&range->list, &io_range_list);
> +#endif
> +
> +       return 0;
> +}
> +
> +phys_addr_t pci_pio_to_address(unsigned long pio)
> +{
> +       phys_addr_t address = (phys_addr_t)OF_BAD_ADDR;
> +
> +#ifdef PCI_IOBASE
> +       struct io_range *range;
> +       resource_size_t allocated_size = 0;
> +
> +       if (pio > IO_SPACE_LIMIT)
> +               return address;
> +
> +       spin_lock(&io_range_lock);
> +       list_for_each_entry(range, &io_range_list, list) {
> +               if (pio >= allocated_size && pio < allocated_size + range->size) {
> +                       address = range->start + pio - allocated_size;
> +                       break;
> +               }
> +               allocated_size += range->size;
> +       }
> +       spin_unlock(&io_range_lock);
> +#endif
> +
> +       return address;
> +}
> +
>  unsigned long __weak pci_address_to_pio(phys_addr_t address)
>  {
> +#ifdef PCI_IOBASE
> +       struct io_range *res;
> +       resource_size_t offset = 0;
> +
> +       list_for_each_entry(res, &io_range_list, list) {
> +               if (address >= res->start &&
> +                       address < res->start + res->size) {
> +                       return res->start - address + offset;
> +               }
> +               offset += res->size;
> +       }
> +
> +       return (unsigned long)-1;
> +#else
>         if (address > IO_SPACE_LIMIT)
>                 return (unsigned long)-1;
>
>         return (unsigned long) address;
> +#endif
>  }
>
>  static int __of_address_to_resource(struct device_node *dev,
> diff --git a/include/linux/of_address.h b/include/linux/of_address.h
> index c13b878..28e6836 100644
> --- a/include/linux/of_address.h
> +++ b/include/linux/of_address.h
> @@ -55,7 +55,9 @@ extern void __iomem *of_iomap(struct device_node *device, int index);
>  extern const __be32 *of_get_address(struct device_node *dev, int index,
>                            u64 *size, unsigned int *flags);
>
> +extern int pci_register_io_range(phys_addr_t addr, resource_size_t size);
>  extern unsigned long pci_address_to_pio(phys_addr_t addr);
> +extern phys_addr_t pci_pio_to_address(unsigned long pio);
>
>  extern int of_pci_range_parser_init(struct of_pci_range_parser *parser,
>                         struct device_node *node);
> --
> 2.0.4
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 03/12] PCI: Introduce helper functions to deal with PCI I/O ranges.

[Yijing Wang]

On 2014/8/13 0:25, Liviu Dudau wrote:
> Some architectures do not have a simple view of the PCI I/O space
> and instead use a range of CPU addresses that map to bus addresses.
> For some architectures these ranges will be expressed by OF bindings
> in a device tree file.
> 
> This patch introduces a pci_register_io_range() helper function with
> a generic implementation that can be used by such architectures to
> keep track of the I/O ranges described by the PCI bindings. If the
> PCI_IOBASE macro is not defined that signals lack of support for PCI
> and we return an error.
> 
> In order to retrieve the CPU address associated with an I/O port, a
> new helper function pci_pio_to_address() is introduced. This will
> search in the list of ranges registered with pci_register_io_range()
> and return the CPU address that corresponds to the given port.
> 
> Cc: Grant Likely <grant.likely@linaro.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
> ---
>  drivers/of/address.c       | 95 ++++++++++++++++++++++++++++++++++++++++++++++
>  include/linux/of_address.h |  2 +
>  2 files changed, 97 insertions(+)
> 
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 5edfcb0..4dab700 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -5,6 +5,7 @@
>  #include <linux/module.h>
>  #include <linux/of_address.h>
>  #include <linux/pci_regs.h>
> +#include <linux/slab.h>
>  #include <linux/string.h>
>  
>  /* Max address size we deal with */
> @@ -601,12 +602,106 @@ const __be32 *of_get_address(struct device_node *dev, int index, u64 *size,
>  }
>  EXPORT_SYMBOL(of_get_address);
>  
> +#ifdef PCI_IOBASE
> +struct io_range {
> +	struct list_head list;
> +	phys_addr_t start;
> +	resource_size_t size;
> +};
> +
> +static LIST_HEAD(io_range_list);
> +static DEFINE_SPINLOCK(io_range_lock);
> +#endif
> +
> +/*
> + * Record the PCI IO range (expressed as CPU physical address + size).
> + * Return a negative value if an error has occured, zero otherwise
> + */
> +int __weak pci_register_io_range(phys_addr_t addr, resource_size_t size)
> +{
> +#ifdef PCI_IOBASE
> +	struct io_range *range;
> +	resource_size_t allocated_size = 0;
> +
> +	/* check if the range hasn't been previously recorded */
> +	spin_lock(&io_range_lock);
> +	list_for_each_entry(range, &io_range_list, list) {
> +		if (addr >= range->start && addr + size <= range->start + size)
> +			return 0;
> +		allocated_size += range->size;
> +	}
> +	spin_unlock(&io_range_lock);
> +
> +	/* range not registed yet, check for available space */
> +	if (allocated_size + size - 1 > IO_SPACE_LIMIT) {
> +		/* if it's too big check if 64K space can be reserved */
> +		if (allocated_size + SZ_64K - 1 > IO_SPACE_LIMIT)
> +			return -E2BIG;
> +
> +		size = SZ_64K;
> +		pr_warn("Requested IO range too big, new size set to 64K\n");
> +	}
> +
> +	/* add the range to the list */
> +	range = kzalloc(sizeof(*range), GFP_KERNEL);
> +	if (!range)
> +		return -ENOMEM;
> +
> +	range->start = addr;
> +	range->size = size;
> +
> +	list_add_tail(&range->list, &io_range_list);

Need spin_lock() here ?

> +#endif
> +
> +	return 0;
> +}
> +
> +phys_addr_t pci_pio_to_address(unsigned long pio)
> +{
> +	phys_addr_t address = (phys_addr_t)OF_BAD_ADDR;
> +
> +#ifdef PCI_IOBASE
> +	struct io_range *range;
> +	resource_size_t allocated_size = 0;
> +
> +	if (pio > IO_SPACE_LIMIT)
> +		return address;
> +
> +	spin_lock(&io_range_lock);
> +	list_for_each_entry(range, &io_range_list, list) {
> +		if (pio >= allocated_size && pio < allocated_size + range->size) {
> +			address = range->start + pio - allocated_size;
> +			break;
> +		}
> +		allocated_size += range->size;
> +	}
> +	spin_unlock(&io_range_lock);
> +#endif
> +
> +	return address;
> +}
> +
>  unsigned long __weak pci_address_to_pio(phys_addr_t address)
>  {
> +#ifdef PCI_IOBASE
> +	struct io_range *res;
> +	resource_size_t offset = 0;
> +
> +	list_for_each_entry(res, &io_range_list, list) {

And here.

> +		if (address >= res->start &&
> +			address < res->start + res->size) {
> +			return res->start - address + offset;
> +		}
> +		offset += res->size;
> +	}
> +
> +	return (unsigned long)-1;
> +#else
>  	if (address > IO_SPACE_LIMIT)
>  		return (unsigned long)-1;
>  
>  	return (unsigned long) address;
> +#endif
>  }
>  
>  static int __of_address_to_resource(struct device_node *dev,
> diff --git a/include/linux/of_address.h b/include/linux/of_address.h
> index c13b878..28e6836 100644
> --- a/include/linux/of_address.h
> +++ b/include/linux/of_address.h
> @@ -55,7 +55,9 @@ extern void __iomem *of_iomap(struct device_node *device, int index);
>  extern const __be32 *of_get_address(struct device_node *dev, int index,
>  			   u64 *size, unsigned int *flags);
>  
> +extern int pci_register_io_range(phys_addr_t addr, resource_size_t size);
>  extern unsigned long pci_address_to_pio(phys_addr_t addr);
> +extern phys_addr_t pci_pio_to_address(unsigned long pio);
>  
>  extern int of_pci_range_parser_init(struct of_pci_range_parser *parser,
>  			struct device_node *node);
> 


-- 
Thanks!
Yijing

[PATCH v9 03/12] PCI: Introduce helper functions to deal with PCI I/O ranges.

[Yijing Wang]

On 2014/8/13 0:25, Liviu Dudau wrote:
> Some architectures do not have a simple view of the PCI I/O space
> and instead use a range of CPU addresses that map to bus addresses.
> For some architectures these ranges will be expressed by OF bindings
> in a device tree file.
> 
> This patch introduces a pci_register_io_range() helper function with
> a generic implementation that can be used by such architectures to
> keep track of the I/O ranges described by the PCI bindings. If the
> PCI_IOBASE macro is not defined that signals lack of support for PCI
> and we return an error.
> 
> In order to retrieve the CPU address associated with an I/O port, a
> new helper function pci_pio_to_address() is introduced. This will
> search in the list of ranges registered with pci_register_io_range()
> and return the CPU address that corresponds to the given port.
> 
> Cc: Grant Likely <grant.likely@linaro.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
> ---
>  drivers/of/address.c       | 95 ++++++++++++++++++++++++++++++++++++++++++++++
>  include/linux/of_address.h |  2 +
>  2 files changed, 97 insertions(+)
> 
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 5edfcb0..4dab700 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -5,6 +5,7 @@
>  #include <linux/module.h>
>  #include <linux/of_address.h>
>  #include <linux/pci_regs.h>
> +#include <linux/slab.h>
>  #include <linux/string.h>
>  
>  /* Max address size we deal with */
> @@ -601,12 +602,106 @@ const __be32 *of_get_address(struct device_node *dev, int index, u64 *size,
>  }
>  EXPORT_SYMBOL(of_get_address);
>  
> +#ifdef PCI_IOBASE
> +struct io_range {
> +	struct list_head list;
> +	phys_addr_t start;
> +	resource_size_t size;
> +};
> +
> +static LIST_HEAD(io_range_list);
> +static DEFINE_SPINLOCK(io_range_lock);
> +#endif
> +
> +/*
> + * Record the PCI IO range (expressed as CPU physical address + size).
> + * Return a negative value if an error has occured, zero otherwise
> + */
> +int __weak pci_register_io_range(phys_addr_t addr, resource_size_t size)
> +{
> +#ifdef PCI_IOBASE
> +	struct io_range *range;
> +	resource_size_t allocated_size = 0;
> +
> +	/* check if the range hasn't been previously recorded */
> +	spin_lock(&io_range_lock);
> +	list_for_each_entry(range, &io_range_list, list) {
> +		if (addr >= range->start && addr + size <= range->start + size)
> +			return 0;
> +		allocated_size += range->size;
> +	}
> +	spin_unlock(&io_range_lock);
> +
> +	/* range not registed yet, check for available space */
> +	if (allocated_size + size - 1 > IO_SPACE_LIMIT) {
> +		/* if it's too big check if 64K space can be reserved */
> +		if (allocated_size + SZ_64K - 1 > IO_SPACE_LIMIT)
> +			return -E2BIG;
> +
> +		size = SZ_64K;
> +		pr_warn("Requested IO range too big, new size set to 64K\n");
> +	}
> +
> +	/* add the range to the list */
> +	range = kzalloc(sizeof(*range), GFP_KERNEL);
> +	if (!range)
> +		return -ENOMEM;
> +
> +	range->start = addr;
> +	range->size = size;
> +
> +	list_add_tail(&range->list, &io_range_list);

Need spin_lock() here ?

> +#endif
> +
> +	return 0;
> +}
> +
> +phys_addr_t pci_pio_to_address(unsigned long pio)
> +{
> +	phys_addr_t address = (phys_addr_t)OF_BAD_ADDR;
> +
> +#ifdef PCI_IOBASE
> +	struct io_range *range;
> +	resource_size_t allocated_size = 0;
> +
> +	if (pio > IO_SPACE_LIMIT)
> +		return address;
> +
> +	spin_lock(&io_range_lock);
> +	list_for_each_entry(range, &io_range_list, list) {
> +		if (pio >= allocated_size && pio < allocated_size + range->size) {
> +			address = range->start + pio - allocated_size;
> +			break;
> +		}
> +		allocated_size += range->size;
> +	}
> +	spin_unlock(&io_range_lock);
> +#endif
> +
> +	return address;
> +}
> +
>  unsigned long __weak pci_address_to_pio(phys_addr_t address)
>  {
> +#ifdef PCI_IOBASE
> +	struct io_range *res;
> +	resource_size_t offset = 0;
> +
> +	list_for_each_entry(res, &io_range_list, list) {

And here.

> +		if (address >= res->start &&
> +			address < res->start + res->size) {
> +			return res->start - address + offset;
> +		}
> +		offset += res->size;
> +	}
> +
> +	return (unsigned long)-1;
> +#else
>  	if (address > IO_SPACE_LIMIT)
>  		return (unsigned long)-1;
>  
>  	return (unsigned long) address;
> +#endif
>  }
>  
>  static int __of_address_to_resource(struct device_node *dev,
> diff --git a/include/linux/of_address.h b/include/linux/of_address.h
> index c13b878..28e6836 100644
> --- a/include/linux/of_address.h
> +++ b/include/linux/of_address.h
> @@ -55,7 +55,9 @@ extern void __iomem *of_iomap(struct device_node *device, int index);
>  extern const __be32 *of_get_address(struct device_node *dev, int index,
>  			   u64 *size, unsigned int *flags);
>  
> +extern int pci_register_io_range(phys_addr_t addr, resource_size_t size);
>  extern unsigned long pci_address_to_pio(phys_addr_t addr);
> +extern phys_addr_t pci_pio_to_address(unsigned long pio);
>  
>  extern int of_pci_range_parser_init(struct of_pci_range_parser *parser,
>  			struct device_node *node);
> 


-- 
Thanks!
Yijing

[PATCH v9 04/12] PCI: OF: Fix the conversion of IO ranges into IO resources.

[Liviu Dudau]

The ranges property for a host bridge controller in DT describes
the mapping between the PCI bus address and the CPU physical address.
The resources framework however expects that the IO resources start
at a pseudo "port" address 0 (zero) and have a maximum size of IO_SPACE_LIMIT.
The conversion from pci ranges to resources failed to take that into account.

In the process move the function into drivers/of/address.c as it now
depends on pci_address_to_pio() code and make it return an error code.

Cc: Grant Likely <grant.likely@linaro.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
---
 drivers/of/address.c       | 46 ++++++++++++++++++++++++++++++++++++++++++++++
 include/linux/of_address.h | 13 ++-----------
 2 files changed, 48 insertions(+), 11 deletions(-)

diff --git a/drivers/of/address.c b/drivers/of/address.c
index 4dab700..3735ac7 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -906,3 +906,49 @@ bool of_dma_is_coherent(struct device_node *np)
 	return false;
 }
 EXPORT_SYMBOL_GPL(of_dma_is_coherent);
+
+/*
+ * of_pci_range_to_resource - Create a resource from an of_pci_range
+ * @range:	the PCI range that describes the resource
+ * @np:		device node where the range belongs to
+ * @res:	pointer to a valid resource that will be updated to
+ *              reflect the values contained in the range.
+ *
+ * Returns EINVAL if the range cannot be converted to resource.
+ *
+ * Note that if the range is an IO range, the resource will be converted
+ * using pci_address_to_pio() which can fail if it is called too early or
+ * if the range cannot be matched to any host bridge IO space (our case here).
+ * To guard against that we try to register the IO range first.
+ * If that fails we know that pci_address_to_pio() will do too.
+ */
+int of_pci_range_to_resource(struct of_pci_range *range,
+	struct device_node *np, struct resource *res)
+{
+	int err;
+	res->flags = range->flags;
+	res->parent = res->child = res->sibling = NULL;
+	res->name = np->full_name;
+
+	if (res->flags & IORESOURCE_IO) {
+		unsigned long port = -1;
+		err = pci_register_io_range(range->cpu_addr, range->size);
+		if (err)
+			goto invalid_range;
+		port = pci_address_to_pio(range->cpu_addr);
+		if (port == (unsigned long)-1) {
+			err = -EINVAL;
+			goto invalid_range;
+		}
+		res->start = port;
+	} else {
+		res->start = range->cpu_addr;
+	}
+	res->end = res->start + range->size - 1;
+	return 0;
+
+invalid_range:
+	res->start = (resource_size_t)OF_BAD_ADDR;
+	res->end = (resource_size_t)OF_BAD_ADDR;
+	return err;
+}
diff --git a/include/linux/of_address.h b/include/linux/of_address.h
index 28e6836..6015f21 100644
--- a/include/linux/of_address.h
+++ b/include/linux/of_address.h
@@ -23,17 +23,8 @@ struct of_pci_range {
 #define for_each_of_pci_range(parser, range) \
 	for (; of_pci_range_parser_one(parser, range);)
 
-static inline void of_pci_range_to_resource(struct of_pci_range *range,
-					    struct device_node *np,
-					    struct resource *res)
-{
-	res->flags = range->flags;
-	res->start = range->cpu_addr;
-	res->end = range->cpu_addr + range->size - 1;
-	res->parent = res->child = res->sibling = NULL;
-	res->name = np->full_name;
-}
-
+extern int of_pci_range_to_resource(struct of_pci_range *range,
+		struct device_node *np, struct resource *res);
 /* Translate a DMA address from device space to CPU space */
 extern u64 of_translate_dma_address(struct device_node *dev,
 				    const __be32 *in_addr);
-- 
2.0.4

[PATCH v9 04/12] PCI: OF: Fix the conversion of IO ranges into IO resources.

[Liviu Dudau]

The ranges property for a host bridge controller in DT describes
the mapping between the PCI bus address and the CPU physical address.
The resources framework however expects that the IO resources start
at a pseudo "port" address 0 (zero) and have a maximum size of IO_SPACE_LIMIT.
The conversion from pci ranges to resources failed to take that into account.

In the process move the function into drivers/of/address.c as it now
depends on pci_address_to_pio() code and make it return an error code.

Cc: Grant Likely <grant.likely@linaro.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
---
 drivers/of/address.c       | 46 ++++++++++++++++++++++++++++++++++++++++++++++
 include/linux/of_address.h | 13 ++-----------
 2 files changed, 48 insertions(+), 11 deletions(-)

diff --git a/drivers/of/address.c b/drivers/of/address.c
index 4dab700..3735ac7 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -906,3 +906,49 @@ bool of_dma_is_coherent(struct device_node *np)
 	return false;
 }
 EXPORT_SYMBOL_GPL(of_dma_is_coherent);
+
+/*
+ * of_pci_range_to_resource - Create a resource from an of_pci_range
+ * @range:	the PCI range that describes the resource
+ * @np:		device node where the range belongs to
+ * @res:	pointer to a valid resource that will be updated to
+ *              reflect the values contained in the range.
+ *
+ * Returns EINVAL if the range cannot be converted to resource.
+ *
+ * Note that if the range is an IO range, the resource will be converted
+ * using pci_address_to_pio() which can fail if it is called too early or
+ * if the range cannot be matched to any host bridge IO space (our case here).
+ * To guard against that we try to register the IO range first.
+ * If that fails we know that pci_address_to_pio() will do too.
+ */
+int of_pci_range_to_resource(struct of_pci_range *range,
+	struct device_node *np, struct resource *res)
+{
+	int err;
+	res->flags = range->flags;
+	res->parent = res->child = res->sibling = NULL;
+	res->name = np->full_name;
+
+	if (res->flags & IORESOURCE_IO) {
+		unsigned long port = -1;
+		err = pci_register_io_range(range->cpu_addr, range->size);
+		if (err)
+			goto invalid_range;
+		port = pci_address_to_pio(range->cpu_addr);
+		if (port == (unsigned long)-1) {
+			err = -EINVAL;
+			goto invalid_range;
+		}
+		res->start = port;
+	} else {
+		res->start = range->cpu_addr;
+	}
+	res->end = res->start + range->size - 1;
+	return 0;
+
+invalid_range:
+	res->start = (resource_size_t)OF_BAD_ADDR;
+	res->end = (resource_size_t)OF_BAD_ADDR;
+	return err;
+}
diff --git a/include/linux/of_address.h b/include/linux/of_address.h
index 28e6836..6015f21 100644
--- a/include/linux/of_address.h
+++ b/include/linux/of_address.h
@@ -23,17 +23,8 @@ struct of_pci_range {
 #define for_each_of_pci_range(parser, range) \
 	for (; of_pci_range_parser_one(parser, range);)
 
-static inline void of_pci_range_to_resource(struct of_pci_range *range,
-					    struct device_node *np,
-					    struct resource *res)
-{
-	res->flags = range->flags;
-	res->start = range->cpu_addr;
-	res->end = range->cpu_addr + range->size - 1;
-	res->parent = res->child = res->sibling = NULL;
-	res->name = np->full_name;
-}
-
+extern int of_pci_range_to_resource(struct of_pci_range *range,
+		struct device_node *np, struct resource *res);
 /* Translate a DMA address from device space to CPU space */
 extern u64 of_translate_dma_address(struct device_node *dev,
 				    const __be32 *in_addr);
-- 
2.0.4

Re: [PATCH v9 04/12] PCI: OF: Fix the conversion of IO ranges into IO resources.

[Rob Herring]

On Tue, Aug 12, 2014 at 11:25 AM, Liviu Dudau <Liviu.Dudau@arm.com> wrote:
> The ranges property for a host bridge controller in DT describes
> the mapping between the PCI bus address and the CPU physical address.
> The resources framework however expects that the IO resources start
> at a pseudo "port" address 0 (zero) and have a maximum size of IO_SPACE_LIMIT.
> The conversion from pci ranges to resources failed to take that into account.
>
> In the process move the function into drivers/of/address.c as it now
> depends on pci_address_to_pio() code and make it return an error code.
>
> Cc: Grant Likely <grant.likely@linaro.org>
> Cc: Rob Herring <robh+dt@kernel.org>

Humm, this says I'm cc'ed, but I'm not which defeats the point of
recording the Cc's in the commit.

I still have the same concerns that this will break existing users.
Are you sure integrator is the only platform affected?

Rob

> Cc: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
> ---
>  drivers/of/address.c       | 46 ++++++++++++++++++++++++++++++++++++++++++++++
>  include/linux/of_address.h | 13 ++-----------
>  2 files changed, 48 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 4dab700..3735ac7 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -906,3 +906,49 @@ bool of_dma_is_coherent(struct device_node *np)
>         return false;
>  }
>  EXPORT_SYMBOL_GPL(of_dma_is_coherent);
> +
> +/*
> + * of_pci_range_to_resource - Create a resource from an of_pci_range
> + * @range:     the PCI range that describes the resource
> + * @np:                device node where the range belongs to
> + * @res:       pointer to a valid resource that will be updated to
> + *              reflect the values contained in the range.
> + *
> + * Returns EINVAL if the range cannot be converted to resource.
> + *
> + * Note that if the range is an IO range, the resource will be converted
> + * using pci_address_to_pio() which can fail if it is called too early or
> + * if the range cannot be matched to any host bridge IO space (our case here).
> + * To guard against that we try to register the IO range first.
> + * If that fails we know that pci_address_to_pio() will do too.
> + */
> +int of_pci_range_to_resource(struct of_pci_range *range,
> +       struct device_node *np, struct resource *res)
> +{
> +       int err;
> +       res->flags = range->flags;
> +       res->parent = res->child = res->sibling = NULL;
> +       res->name = np->full_name;
> +
> +       if (res->flags & IORESOURCE_IO) {
> +               unsigned long port = -1;
> +               err = pci_register_io_range(range->cpu_addr, range->size);
> +               if (err)
> +                       goto invalid_range;
> +               port = pci_address_to_pio(range->cpu_addr);
> +               if (port == (unsigned long)-1) {
> +                       err = -EINVAL;
> +                       goto invalid_range;
> +               }
> +               res->start = port;
> +       } else {
> +               res->start = range->cpu_addr;
> +       }
> +       res->end = res->start + range->size - 1;
> +       return 0;
> +
> +invalid_range:
> +       res->start = (resource_size_t)OF_BAD_ADDR;
> +       res->end = (resource_size_t)OF_BAD_ADDR;
> +       return err;
> +}
> diff --git a/include/linux/of_address.h b/include/linux/of_address.h
> index 28e6836..6015f21 100644
> --- a/include/linux/of_address.h
> +++ b/include/linux/of_address.h
> @@ -23,17 +23,8 @@ struct of_pci_range {
>  #define for_each_of_pci_range(parser, range) \
>         for (; of_pci_range_parser_one(parser, range);)
>
> -static inline void of_pci_range_to_resource(struct of_pci_range *range,
> -                                           struct device_node *np,
> -                                           struct resource *res)
> -{
> -       res->flags = range->flags;
> -       res->start = range->cpu_addr;
> -       res->end = range->cpu_addr + range->size - 1;
> -       res->parent = res->child = res->sibling = NULL;
> -       res->name = np->full_name;
> -}
> -
> +extern int of_pci_range_to_resource(struct of_pci_range *range,
> +               struct device_node *np, struct resource *res);
>  /* Translate a DMA address from device space to CPU space */
>  extern u64 of_translate_dma_address(struct device_node *dev,
>                                     const __be32 *in_addr);
> --
> 2.0.4
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v9 04/12] PCI: OF: Fix the conversion of IO ranges into IO resources.

[Rob Herring]

On Tue, Aug 12, 2014 at 11:25 AM, Liviu Dudau <Liviu.Dudau@arm.com> wrote:
> The ranges property for a host bridge controller in DT describes
> the mapping between the PCI bus address and the CPU physical address.
> The resources framework however expects that the IO resources start
> at a pseudo "port" address 0 (zero) and have a maximum size of IO_SPACE_LIMIT.
> The conversion from pci ranges to resources failed to take that into account.
>
> In the process move the function into drivers/of/address.c as it now
> depends on pci_address_to_pio() code and make it return an error code.
>
> Cc: Grant Likely <grant.likely@linaro.org>
> Cc: Rob Herring <robh+dt@kernel.org>

Humm, this says I'm cc'ed, but I'm not which defeats the point of
recording the Cc's in the commit.

I still have the same concerns that this will break existing users.
Are you sure integrator is the only platform affected?

Rob

> Cc: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
> ---
>  drivers/of/address.c       | 46 ++++++++++++++++++++++++++++++++++++++++++++++
>  include/linux/of_address.h | 13 ++-----------
>  2 files changed, 48 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 4dab700..3735ac7 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -906,3 +906,49 @@ bool of_dma_is_coherent(struct device_node *np)
>         return false;
>  }
>  EXPORT_SYMBOL_GPL(of_dma_is_coherent);
> +
> +/*
> + * of_pci_range_to_resource - Create a resource from an of_pci_range
> + * @range:     the PCI range that describes the resource
> + * @np:                device node where the range belongs to
> + * @res:       pointer to a valid resource that will be updated to
> + *              reflect the values contained in the range.
> + *
> + * Returns EINVAL if the range cannot be converted to resource.
> + *
> + * Note that if the range is an IO range, the resource will be converted
> + * using pci_address_to_pio() which can fail if it is called too early or
> + * if the range cannot be matched to any host bridge IO space (our case here).
> + * To guard against that we try to register the IO range first.
> + * If that fails we know that pci_address_to_pio() will do too.
> + */
> +int of_pci_range_to_resource(struct of_pci_range *range,
> +       struct device_node *np, struct resource *res)
> +{
> +       int err;
> +       res->flags = range->flags;
> +       res->parent = res->child = res->sibling = NULL;
> +       res->name = np->full_name;
> +
> +       if (res->flags & IORESOURCE_IO) {
> +               unsigned long port = -1;
> +               err = pci_register_io_range(range->cpu_addr, range->size);
> +               if (err)
> +                       goto invalid_range;
> +               port = pci_address_to_pio(range->cpu_addr);
> +               if (port == (unsigned long)-1) {
> +                       err = -EINVAL;
> +                       goto invalid_range;
> +               }
> +               res->start = port;
> +       } else {
> +               res->start = range->cpu_addr;
> +       }
> +       res->end = res->start + range->size - 1;
> +       return 0;
> +
> +invalid_range:
> +       res->start = (resource_size_t)OF_BAD_ADDR;
> +       res->end = (resource_size_t)OF_BAD_ADDR;
> +       return err;
> +}
> diff --git a/include/linux/of_address.h b/include/linux/of_address.h
> index 28e6836..6015f21 100644
> --- a/include/linux/of_address.h
> +++ b/include/linux/of_address.h
> @@ -23,17 +23,8 @@ struct of_pci_range {
>  #define for_each_of_pci_range(parser, range) \
>         for (; of_pci_range_parser_one(parser, range);)
>
> -static inline void of_pci_range_to_resource(struct of_pci_range *range,
> -                                           struct device_node *np,
> -                                           struct resource *res)
> -{
> -       res->flags = range->flags;
> -       res->start = range->cpu_addr;
> -       res->end = range->cpu_addr + range->size - 1;
> -       res->parent = res->child = res->sibling = NULL;
> -       res->name = np->full_name;
> -}
> -
> +extern int of_pci_range_to_resource(struct of_pci_range *range,
> +               struct device_node *np, struct resource *res);
>  /* Translate a DMA address from device space to CPU space */
>  extern u64 of_translate_dma_address(struct device_node *dev,
>                                     const __be32 *in_addr);
> --
> 2.0.4
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v9 04/12] PCI: OF: Fix the conversion of IO ranges into IO resources.

[Rob Herring]

On Tue, Aug 12, 2014 at 11:25 AM, Liviu Dudau <Liviu.Dudau-5wv7dgnIgG8@public.gmane.org> wrote:
> The ranges property for a host bridge controller in DT describes
> the mapping between the PCI bus address and the CPU physical address.
> The resources framework however expects that the IO resources start
> at a pseudo "port" address 0 (zero) and have a maximum size of IO_SPACE_LIMIT.
> The conversion from pci ranges to resources failed to take that into account.
>
> In the process move the function into drivers/of/address.c as it now
> depends on pci_address_to_pio() code and make it return an error code.
>
> Cc: Grant Likely <grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>

Humm, this says I'm cc'ed, but I'm not which defeats the point of
recording the Cc's in the commit.

I still have the same concerns that this will break existing users.
Are you sure integrator is the only platform affected?

Rob

> Cc: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
> Signed-off-by: Liviu Dudau <Liviu.Dudau-5wv7dgnIgG8@public.gmane.org>
> ---
>  drivers/of/address.c       | 46 ++++++++++++++++++++++++++++++++++++++++++++++
>  include/linux/of_address.h | 13 ++-----------
>  2 files changed, 48 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 4dab700..3735ac7 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -906,3 +906,49 @@ bool of_dma_is_coherent(struct device_node *np)
>         return false;
>  }
>  EXPORT_SYMBOL_GPL(of_dma_is_coherent);
> +
> +/*
> + * of_pci_range_to_resource - Create a resource from an of_pci_range
> + * @range:     the PCI range that describes the resource
> + * @np:                device node where the range belongs to
> + * @res:       pointer to a valid resource that will be updated to
> + *              reflect the values contained in the range.
> + *
> + * Returns EINVAL if the range cannot be converted to resource.
> + *
> + * Note that if the range is an IO range, the resource will be converted
> + * using pci_address_to_pio() which can fail if it is called too early or
> + * if the range cannot be matched to any host bridge IO space (our case here).
> + * To guard against that we try to register the IO range first.
> + * If that fails we know that pci_address_to_pio() will do too.
> + */
> +int of_pci_range_to_resource(struct of_pci_range *range,
> +       struct device_node *np, struct resource *res)
> +{
> +       int err;
> +       res->flags = range->flags;
> +       res->parent = res->child = res->sibling = NULL;
> +       res->name = np->full_name;
> +
> +       if (res->flags & IORESOURCE_IO) {
> +               unsigned long port = -1;
> +               err = pci_register_io_range(range->cpu_addr, range->size);
> +               if (err)
> +                       goto invalid_range;
> +               port = pci_address_to_pio(range->cpu_addr);
> +               if (port == (unsigned long)-1) {
> +                       err = -EINVAL;
> +                       goto invalid_range;
> +               }
> +               res->start = port;
> +       } else {
> +               res->start = range->cpu_addr;
> +       }
> +       res->end = res->start + range->size - 1;
> +       return 0;
> +
> +invalid_range:
> +       res->start = (resource_size_t)OF_BAD_ADDR;
> +       res->end = (resource_size_t)OF_BAD_ADDR;
> +       return err;
> +}
> diff --git a/include/linux/of_address.h b/include/linux/of_address.h
> index 28e6836..6015f21 100644
> --- a/include/linux/of_address.h
> +++ b/include/linux/of_address.h
> @@ -23,17 +23,8 @@ struct of_pci_range {
>  #define for_each_of_pci_range(parser, range) \
>         for (; of_pci_range_parser_one(parser, range);)
>
> -static inline void of_pci_range_to_resource(struct of_pci_range *range,
> -                                           struct device_node *np,
> -                                           struct resource *res)
> -{
> -       res->flags = range->flags;
> -       res->start = range->cpu_addr;
> -       res->end = range->cpu_addr + range->size - 1;
> -       res->parent = res->child = res->sibling = NULL;
> -       res->name = np->full_name;
> -}
> -
> +extern int of_pci_range_to_resource(struct of_pci_range *range,
> +               struct device_node *np, struct resource *res);
>  /* Translate a DMA address from device space to CPU space */
>  extern u64 of_translate_dma_address(struct device_node *dev,
>                                     const __be32 *in_addr);
> --
> 2.0.4
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 04/12] PCI: OF: Fix the conversion of IO ranges into IO resources.

[Liviu Dudau]

On Thu, Aug 21, 2014 at 11:08:48PM -0500, Rob Herring wrote:
> On Tue, Aug 12, 2014 at 11:25 AM, Liviu Dudau <Liviu.Dudau@arm.com> wrote:
> > The ranges property for a host bridge controller in DT describes
> > the mapping between the PCI bus address and the CPU physical address.
> > The resources framework however expects that the IO resources start
> > at a pseudo "port" address 0 (zero) and have a maximum size of IO_SPACE_LIMIT.
> > The conversion from pci ranges to resources failed to take that into account.
> >
> > In the process move the function into drivers/of/address.c as it now
> > depends on pci_address_to_pio() code and make it return an error code.
> >
> > Cc: Grant Likely <grant.likely@linaro.org>
> > Cc: Rob Herring <robh+dt@kernel.org>
> 
> Humm, this says I'm cc'ed, but I'm not which defeats the point of
> recording the Cc's in the commit.

Appologies, I've screwed up my git send-email arguments.

> 
> I still have the same concerns that this will break existing users.
> Are you sure integrator is the only platform affected?

microblaze and powerpc have their similar handcoded routine for parsing ranges
where they pre-compute the io_base and adjust the values again when registering
resources. I'm not absolutely sure they are not broken as I lack the appropriate
platforms to test (I've been asking for an FPGA engineer to build me a microblaze
image with all the bits included but haven't received anything yet and it is
possible Xilinx has now shifted their interests towards ARM + PCI as the ML605
board that I have seems to have been discontinued).

mips is doing the same thing and I believe is not affected, pci-host-generic.c
was adjusting the returned values afterwards so that will not be needed and Lorenzo
has a patch for the driver to adapt it to this series anyway.

pcie-designware.c also recalculates the io.start and io.end values, so that's fine
for now. The only ones that I believe are still affected are pci-tegra.c and
pcie-rcar.c for which I will need to provide a patch similar to integrator unless
the code gets converted to the new range parsing.

Best regards,
Liviu

> 
> Rob
> 
> > Cc: Arnd Bergmann <arnd@arndb.de>
> > Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
> > ---
> >  drivers/of/address.c       | 46 ++++++++++++++++++++++++++++++++++++++++++++++
> >  include/linux/of_address.h | 13 ++-----------
> >  2 files changed, 48 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/of/address.c b/drivers/of/address.c
> > index 4dab700..3735ac7 100644
> > --- a/drivers/of/address.c
> > +++ b/drivers/of/address.c
> > @@ -906,3 +906,49 @@ bool of_dma_is_coherent(struct device_node *np)
> >         return false;
> >  }
> >  EXPORT_SYMBOL_GPL(of_dma_is_coherent);
> > +
> > +/*
> > + * of_pci_range_to_resource - Create a resource from an of_pci_range
> > + * @range:     the PCI range that describes the resource
> > + * @np:                device node where the range belongs to
> > + * @res:       pointer to a valid resource that will be updated to
> > + *              reflect the values contained in the range.
> > + *
> > + * Returns EINVAL if the range cannot be converted to resource.
> > + *
> > + * Note that if the range is an IO range, the resource will be converted
> > + * using pci_address_to_pio() which can fail if it is called too early or
> > + * if the range cannot be matched to any host bridge IO space (our case here).
> > + * To guard against that we try to register the IO range first.
> > + * If that fails we know that pci_address_to_pio() will do too.
> > + */
> > +int of_pci_range_to_resource(struct of_pci_range *range,
> > +       struct device_node *np, struct resource *res)
> > +{
> > +       int err;
> > +       res->flags = range->flags;
> > +       res->parent = res->child = res->sibling = NULL;
> > +       res->name = np->full_name;
> > +
> > +       if (res->flags & IORESOURCE_IO) {
> > +               unsigned long port = -1;
> > +               err = pci_register_io_range(range->cpu_addr, range->size);
> > +               if (err)
> > +                       goto invalid_range;
> > +               port = pci_address_to_pio(range->cpu_addr);
> > +               if (port == (unsigned long)-1) {
> > +                       err = -EINVAL;
> > +                       goto invalid_range;
> > +               }
> > +               res->start = port;
> > +       } else {
> > +               res->start = range->cpu_addr;
> > +       }
> > +       res->end = res->start + range->size - 1;
> > +       return 0;
> > +
> > +invalid_range:
> > +       res->start = (resource_size_t)OF_BAD_ADDR;
> > +       res->end = (resource_size_t)OF_BAD_ADDR;
> > +       return err;
> > +}
> > diff --git a/include/linux/of_address.h b/include/linux/of_address.h
> > index 28e6836..6015f21 100644
> > --- a/include/linux/of_address.h
> > +++ b/include/linux/of_address.h
> > @@ -23,17 +23,8 @@ struct of_pci_range {
> >  #define for_each_of_pci_range(parser, range) \
> >         for (; of_pci_range_parser_one(parser, range);)
> >
> > -static inline void of_pci_range_to_resource(struct of_pci_range *range,
> > -                                           struct device_node *np,
> > -                                           struct resource *res)
> > -{
> > -       res->flags = range->flags;
> > -       res->start = range->cpu_addr;
> > -       res->end = range->cpu_addr + range->size - 1;
> > -       res->parent = res->child = res->sibling = NULL;
> > -       res->name = np->full_name;
> > -}
> > -
> > +extern int of_pci_range_to_resource(struct of_pci_range *range,
> > +               struct device_node *np, struct resource *res);
> >  /* Translate a DMA address from device space to CPU space */
> >  extern u64 of_translate_dma_address(struct device_node *dev,
> >                                     const __be32 *in_addr);
> > --
> > 2.0.4
> >
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
-------------------
   .oooO
   (   )
    \ (  Oooo.
     \_) (   )
          ) /
         (_/

 One small step
   for me ...

[PATCH v9 04/12] PCI: OF: Fix the conversion of IO ranges into IO resources.

[Liviu Dudau]

On Thu, Aug 21, 2014 at 11:08:48PM -0500, Rob Herring wrote:
> On Tue, Aug 12, 2014 at 11:25 AM, Liviu Dudau <Liviu.Dudau@arm.com> wrote:
> > The ranges property for a host bridge controller in DT describes
> > the mapping between the PCI bus address and the CPU physical address.
> > The resources framework however expects that the IO resources start
> > at a pseudo "port" address 0 (zero) and have a maximum size of IO_SPACE_LIMIT.
> > The conversion from pci ranges to resources failed to take that into account.
> >
> > In the process move the function into drivers/of/address.c as it now
> > depends on pci_address_to_pio() code and make it return an error code.
> >
> > Cc: Grant Likely <grant.likely@linaro.org>
> > Cc: Rob Herring <robh+dt@kernel.org>
> 
> Humm, this says I'm cc'ed, but I'm not which defeats the point of
> recording the Cc's in the commit.

Appologies, I've screwed up my git send-email arguments.

> 
> I still have the same concerns that this will break existing users.
> Are you sure integrator is the only platform affected?

microblaze and powerpc have their similar handcoded routine for parsing ranges
where they pre-compute the io_base and adjust the values again when registering
resources. I'm not absolutely sure they are not broken as I lack the appropriate
platforms to test (I've been asking for an FPGA engineer to build me a microblaze
image with all the bits included but haven't received anything yet and it is
possible Xilinx has now shifted their interests towards ARM + PCI as the ML605
board that I have seems to have been discontinued).

mips is doing the same thing and I believe is not affected, pci-host-generic.c
was adjusting the returned values afterwards so that will not be needed and Lorenzo
has a patch for the driver to adapt it to this series anyway.

pcie-designware.c also recalculates the io.start and io.end values, so that's fine
for now. The only ones that I believe are still affected are pci-tegra.c and
pcie-rcar.c for which I will need to provide a patch similar to integrator unless
the code gets converted to the new range parsing.

Best regards,
Liviu

> 
> Rob
> 
> > Cc: Arnd Bergmann <arnd@arndb.de>
> > Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
> > ---
> >  drivers/of/address.c       | 46 ++++++++++++++++++++++++++++++++++++++++++++++
> >  include/linux/of_address.h | 13 ++-----------
> >  2 files changed, 48 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/of/address.c b/drivers/of/address.c
> > index 4dab700..3735ac7 100644
> > --- a/drivers/of/address.c
> > +++ b/drivers/of/address.c
> > @@ -906,3 +906,49 @@ bool of_dma_is_coherent(struct device_node *np)
> >         return false;
> >  }
> >  EXPORT_SYMBOL_GPL(of_dma_is_coherent);
> > +
> > +/*
> > + * of_pci_range_to_resource - Create a resource from an of_pci_range
> > + * @range:     the PCI range that describes the resource
> > + * @np:                device node where the range belongs to
> > + * @res:       pointer to a valid resource that will be updated to
> > + *              reflect the values contained in the range.
> > + *
> > + * Returns EINVAL if the range cannot be converted to resource.
> > + *
> > + * Note that if the range is an IO range, the resource will be converted
> > + * using pci_address_to_pio() which can fail if it is called too early or
> > + * if the range cannot be matched to any host bridge IO space (our case here).
> > + * To guard against that we try to register the IO range first.
> > + * If that fails we know that pci_address_to_pio() will do too.
> > + */
> > +int of_pci_range_to_resource(struct of_pci_range *range,
> > +       struct device_node *np, struct resource *res)
> > +{
> > +       int err;
> > +       res->flags = range->flags;
> > +       res->parent = res->child = res->sibling = NULL;
> > +       res->name = np->full_name;
> > +
> > +       if (res->flags & IORESOURCE_IO) {
> > +               unsigned long port = -1;
> > +               err = pci_register_io_range(range->cpu_addr, range->size);
> > +               if (err)
> > +                       goto invalid_range;
> > +               port = pci_address_to_pio(range->cpu_addr);
> > +               if (port == (unsigned long)-1) {
> > +                       err = -EINVAL;
> > +                       goto invalid_range;
> > +               }
> > +               res->start = port;
> > +       } else {
> > +               res->start = range->cpu_addr;
> > +       }
> > +       res->end = res->start + range->size - 1;
> > +       return 0;
> > +
> > +invalid_range:
> > +       res->start = (resource_size_t)OF_BAD_ADDR;
> > +       res->end = (resource_size_t)OF_BAD_ADDR;
> > +       return err;
> > +}
> > diff --git a/include/linux/of_address.h b/include/linux/of_address.h
> > index 28e6836..6015f21 100644
> > --- a/include/linux/of_address.h
> > +++ b/include/linux/of_address.h
> > @@ -23,17 +23,8 @@ struct of_pci_range {
> >  #define for_each_of_pci_range(parser, range) \
> >         for (; of_pci_range_parser_one(parser, range);)
> >
> > -static inline void of_pci_range_to_resource(struct of_pci_range *range,
> > -                                           struct device_node *np,
> > -                                           struct resource *res)
> > -{
> > -       res->flags = range->flags;
> > -       res->start = range->cpu_addr;
> > -       res->end = range->cpu_addr + range->size - 1;
> > -       res->parent = res->child = res->sibling = NULL;
> > -       res->name = np->full_name;
> > -}
> > -
> > +extern int of_pci_range_to_resource(struct of_pci_range *range,
> > +               struct device_node *np, struct resource *res);
> >  /* Translate a DMA address from device space to CPU space */
> >  extern u64 of_translate_dma_address(struct device_node *dev,
> >                                     const __be32 *in_addr);
> > --
> > 2.0.4
> >
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
-------------------
   .oooO
   (   )
    \ (  Oooo.
     \_) (   )
          ) /
         (_/

 One small step
   for me ...

Re: [PATCH v9 04/12] PCI: OF: Fix the conversion of IO ranges into IO resources.

[Rob Herring]

On Fri, Aug 22, 2014 at 8:06 AM, Liviu Dudau <liviu@dudau.co.uk> wrote:
> On Thu, Aug 21, 2014 at 11:08:48PM -0500, Rob Herring wrote:
>> On Tue, Aug 12, 2014 at 11:25 AM, Liviu Dudau <Liviu.Dudau@arm.com> wrote:
>> > The ranges property for a host bridge controller in DT describes
>> > the mapping between the PCI bus address and the CPU physical address.
>> > The resources framework however expects that the IO resources start
>> > at a pseudo "port" address 0 (zero) and have a maximum size of IO_SPACE_LIMIT.
>> > The conversion from pci ranges to resources failed to take that into account.
>> >
>> > In the process move the function into drivers/of/address.c as it now
>> > depends on pci_address_to_pio() code and make it return an error code.
>> >
>> > Cc: Grant Likely <grant.likely@linaro.org>
>> > Cc: Rob Herring <robh+dt@kernel.org>
>>
>> Humm, this says I'm cc'ed, but I'm not which defeats the point of
>> recording the Cc's in the commit.
>
> Appologies, I've screwed up my git send-email arguments.
>
>>
>> I still have the same concerns that this will break existing users.
>> Are you sure integrator is the only platform affected?
>
> microblaze and powerpc have their similar handcoded routine for parsing ranges
> where they pre-compute the io_base and adjust the values again when registering
> resources. I'm not absolutely sure they are not broken as I lack the appropriate
> platforms to test (I've been asking for an FPGA engineer to build me a microblaze
> image with all the bits included but haven't received anything yet and it is
> possible Xilinx has now shifted their interests towards ARM + PCI as the ML605
> board that I have seems to have been discontinued).

I will settle for "I've read through the $arch code and believe they
are not broken". It is unrealistic for you to test on everything.

> mips is doing the same thing and I believe is not affected, pci-host-generic.c
> was adjusting the returned values afterwards so that will not be needed and Lorenzo
> has a patch for the driver to adapt it to this series anyway.
>
> pcie-designware.c also recalculates the io.start and io.end values, so that's fine
> for now. The only ones that I believe are still affected are pci-tegra.c and
> pcie-rcar.c for which I will need to provide a patch similar to integrator unless
> the code gets converted to the new range parsing.

Well, the latter would be nice, but they certainly have to be fixed.
Now that I think about it, this needs to be handled in a bisectable
way. So I think you need to fix all affected platforms in this patch
rather than a separate patch as you have done.

Rob

[PATCH v9 04/12] PCI: OF: Fix the conversion of IO ranges into IO resources.

[Rob Herring]

On Fri, Aug 22, 2014 at 8:06 AM, Liviu Dudau <liviu@dudau.co.uk> wrote:
> On Thu, Aug 21, 2014 at 11:08:48PM -0500, Rob Herring wrote:
>> On Tue, Aug 12, 2014 at 11:25 AM, Liviu Dudau <Liviu.Dudau@arm.com> wrote:
>> > The ranges property for a host bridge controller in DT describes
>> > the mapping between the PCI bus address and the CPU physical address.
>> > The resources framework however expects that the IO resources start
>> > at a pseudo "port" address 0 (zero) and have a maximum size of IO_SPACE_LIMIT.
>> > The conversion from pci ranges to resources failed to take that into account.
>> >
>> > In the process move the function into drivers/of/address.c as it now
>> > depends on pci_address_to_pio() code and make it return an error code.
>> >
>> > Cc: Grant Likely <grant.likely@linaro.org>
>> > Cc: Rob Herring <robh+dt@kernel.org>
>>
>> Humm, this says I'm cc'ed, but I'm not which defeats the point of
>> recording the Cc's in the commit.
>
> Appologies, I've screwed up my git send-email arguments.
>
>>
>> I still have the same concerns that this will break existing users.
>> Are you sure integrator is the only platform affected?
>
> microblaze and powerpc have their similar handcoded routine for parsing ranges
> where they pre-compute the io_base and adjust the values again when registering
> resources. I'm not absolutely sure they are not broken as I lack the appropriate
> platforms to test (I've been asking for an FPGA engineer to build me a microblaze
> image with all the bits included but haven't received anything yet and it is
> possible Xilinx has now shifted their interests towards ARM + PCI as the ML605
> board that I have seems to have been discontinued).

I will settle for "I've read through the $arch code and believe they
are not broken". It is unrealistic for you to test on everything.

> mips is doing the same thing and I believe is not affected, pci-host-generic.c
> was adjusting the returned values afterwards so that will not be needed and Lorenzo
> has a patch for the driver to adapt it to this series anyway.
>
> pcie-designware.c also recalculates the io.start and io.end values, so that's fine
> for now. The only ones that I believe are still affected are pci-tegra.c and
> pcie-rcar.c for which I will need to provide a patch similar to integrator unless
> the code gets converted to the new range parsing.

Well, the latter would be nice, but they certainly have to be fixed.
Now that I think about it, this needs to be handled in a bisectable
way. So I think you need to fix all affected platforms in this patch
rather than a separate patch as you have done.

Rob

Re: [PATCH v9 04/12] PCI: OF: Fix the conversion of IO ranges into IO resources.

[Bjorn Helgaas]

On Sun, Aug 24, 2014 at 06:27:48PM -0500, Rob Herring wrote:
> On Fri, Aug 22, 2014 at 8:06 AM, Liviu Dudau <liviu@dudau.co.uk> wrote:
> > mips is doing the same thing and I believe is not affected, pci-host-generic.c
> > was adjusting the returned values afterwards so that will not be needed and Lorenzo
> > has a patch for the driver to adapt it to this series anyway.
> >
> > pcie-designware.c also recalculates the io.start and io.end values, so that's fine
> > for now. The only ones that I believe are still affected are pci-tegra.c and
> > pcie-rcar.c for which I will need to provide a patch similar to integrator unless
> > the code gets converted to the new range parsing.
> 
> Well, the latter would be nice, but they certainly have to be fixed.
> Now that I think about it, this needs to be handled in a bisectable
> way. So I think you need to fix all affected platforms in this patch
> rather than a separate patch as you have done.

Yep, I was about to complain that the "ARM: integrator: Correct usage of
of_pci_range_to_resource()" patch needs to be squashed into whatever broke
it, but I see Rob already caught that.

Bjorn

[PATCH v9 04/12] PCI: OF: Fix the conversion of IO ranges into IO resources.

[Bjorn Helgaas]

On Sun, Aug 24, 2014 at 06:27:48PM -0500, Rob Herring wrote:
> On Fri, Aug 22, 2014 at 8:06 AM, Liviu Dudau <liviu@dudau.co.uk> wrote:
> > mips is doing the same thing and I believe is not affected, pci-host-generic.c
> > was adjusting the returned values afterwards so that will not be needed and Lorenzo
> > has a patch for the driver to adapt it to this series anyway.
> >
> > pcie-designware.c also recalculates the io.start and io.end values, so that's fine
> > for now. The only ones that I believe are still affected are pci-tegra.c and
> > pcie-rcar.c for which I will need to provide a patch similar to integrator unless
> > the code gets converted to the new range parsing.
> 
> Well, the latter would be nice, but they certainly have to be fixed.
> Now that I think about it, this needs to be handled in a bisectable
> way. So I think you need to fix all affected platforms in this patch
> rather than a separate patch as you have done.

Yep, I was about to complain that the "ARM: integrator: Correct usage of
of_pci_range_to_resource()" patch needs to be squashed into whatever broke
it, but I see Rob already caught that.

Bjorn

[PATCH v9 05/12] ARM: Define PCI_IOBASE as the base of virtual PCI IO space.

[Liviu Dudau]

This is needed for calls into OF code that parses PCI ranges.
It signals support for memory mapped PCI I/O accesses that
are described be device trees.

Cc: Russell King <linux@arm.linux.org.uk>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Herring <robh+dt@kernel.org>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
---
 arch/arm/include/asm/io.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
index 3d23418..22b7529 100644
--- a/arch/arm/include/asm/io.h
+++ b/arch/arm/include/asm/io.h
@@ -178,6 +178,7 @@ static inline void __iomem *__typesafe_io(unsigned long addr)
 
 /* PCI fixed i/o mapping */
 #define PCI_IO_VIRT_BASE	0xfee00000
+#define PCI_IOBASE		PCI_IO_VIRT_BASE
 
 #if defined(CONFIG_PCI)
 void pci_ioremap_set_mem_type(int mem_type);
-- 
2.0.4

[PATCH v9 05/12] ARM: Define PCI_IOBASE as the base of virtual PCI IO space.

[Liviu Dudau]

This is needed for calls into OF code that parses PCI ranges.
It signals support for memory mapped PCI I/O accesses that
are described be device trees.

Cc: Russell King <linux@arm.linux.org.uk>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Herring <robh+dt@kernel.org>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
---
 arch/arm/include/asm/io.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
index 3d23418..22b7529 100644
--- a/arch/arm/include/asm/io.h
+++ b/arch/arm/include/asm/io.h
@@ -178,6 +178,7 @@ static inline void __iomem *__typesafe_io(unsigned long addr)
 
 /* PCI fixed i/o mapping */
 #define PCI_IO_VIRT_BASE	0xfee00000
+#define PCI_IOBASE		PCI_IO_VIRT_BASE
 
 #if defined(CONFIG_PCI)
 void pci_ioremap_set_mem_type(int mem_type);
-- 
2.0.4

[PATCH v9 05/12] ARM: Define PCI_IOBASE as the base of virtual PCI IO space.

[Liviu Dudau]

This is needed for calls into OF code that parses PCI ranges.
It signals support for memory mapped PCI I/O accesses that
are described be device trees.

Cc: Russell King <linux@arm.linux.org.uk>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Herring <robh+dt@kernel.org>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
---
 arch/arm/include/asm/io.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
index 3d23418..22b7529 100644
--- a/arch/arm/include/asm/io.h
+++ b/arch/arm/include/asm/io.h
@@ -178,6 +178,7 @@ static inline void __iomem *__typesafe_io(unsigned long addr)
 
 /* PCI fixed i/o mapping */
 #define PCI_IO_VIRT_BASE	0xfee00000
+#define PCI_IOBASE		PCI_IO_VIRT_BASE
 
 #if defined(CONFIG_PCI)
 void pci_ioremap_set_mem_type(int mem_type);
-- 
2.0.4

[PATCH v9 06/12] ARM: integrator: Correct usage of of_pci_range_to_resource()

[Liviu Dudau]

Previously, of_pci_range_to_resource() would return a resource
that contained physical addresses of the IO space even if the
IORESOURCE_IO flags mandate a logical port set of values. Now
that the function has been fixed we need to update the drivers
that were taking advantage of the old behaviour.

Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
---
 arch/arm/mach-integrator/pci_v3.c | 24 +++++++++++++-----------
 1 file changed, 13 insertions(+), 11 deletions(-)

diff --git a/arch/arm/mach-integrator/pci_v3.c b/arch/arm/mach-integrator/pci_v3.c
index 05e1f73..193b7f8 100644
--- a/arch/arm/mach-integrator/pci_v3.c
+++ b/arch/arm/mach-integrator/pci_v3.c
@@ -660,6 +660,7 @@ static void __init pci_v3_preinit(void)
 {
 	unsigned long flags;
 	unsigned int temp;
+	phys_addr_t io_address = pci_pio_to_address(io_mem.start);
 
 	pcibios_min_mem = 0x00100000;
 
@@ -701,7 +702,7 @@ static void __init pci_v3_preinit(void)
 	/*
 	 * Setup window 2 - PCI IO
 	 */
-	v3_writel(V3_LB_BASE2, v3_addr_to_lb_base2(io_mem.start) |
+	v3_writel(V3_LB_BASE2, v3_addr_to_lb_base2(io_address) |
 			V3_LB_BASE_ENABLE);
 	v3_writew(V3_LB_MAP2, v3_addr_to_lb_map2(0));
 
@@ -742,6 +743,7 @@ static void __init pci_v3_preinit(void)
 static void __init pci_v3_postinit(void)
 {
 	unsigned int pci_cmd;
+	phys_addr_t io_address = pci_pio_to_address(io_mem.start);
 
 	pci_cmd = PCI_COMMAND_MEMORY |
 		  PCI_COMMAND_MASTER | PCI_COMMAND_INVALIDATE;
@@ -758,7 +760,7 @@ static void __init pci_v3_postinit(void)
 		       "interrupt: %d\n", ret);
 #endif
 
-	register_isa_ports(non_mem.start, io_mem.start, 0);
+	register_isa_ports(non_mem.start, io_address, 0);
 }
 
 /*
@@ -867,33 +869,33 @@ static int __init pci_v3_probe(struct platform_device *pdev)
 
 	for_each_of_pci_range(&parser, &range) {
 		if (!range.flags) {
-			of_pci_range_to_resource(&range, np, &conf_mem);
+			ret = of_pci_range_to_resource(&range, np, &conf_mem);
 			conf_mem.name = "PCIv3 config";
 		}
 		if (range.flags & IORESOURCE_IO) {
-			of_pci_range_to_resource(&range, np, &io_mem);
+			ret = of_pci_range_to_resource(&range, np, &io_mem);
+			dev_info(&pdev->dev, "IO PCI range converted\n");
 			io_mem.name = "PCIv3 I/O";
 		}
 		if ((range.flags & IORESOURCE_MEM) &&
 			!(range.flags & IORESOURCE_PREFETCH)) {
 			non_mem_pci = range.pci_addr;
 			non_mem_pci_sz = range.size;
-			of_pci_range_to_resource(&range, np, &non_mem);
+			ret = of_pci_range_to_resource(&range, np, &non_mem);
 			non_mem.name = "PCIv3 non-prefetched mem";
 		}
 		if ((range.flags & IORESOURCE_MEM) &&
 			(range.flags & IORESOURCE_PREFETCH)) {
 			pre_mem_pci = range.pci_addr;
 			pre_mem_pci_sz = range.size;
-			of_pci_range_to_resource(&range, np, &pre_mem);
+			ret = of_pci_range_to_resource(&range, np, &pre_mem);
 			pre_mem.name = "PCIv3 prefetched mem";
 		}
-	}
 
-	if (!conf_mem.start || !io_mem.start ||
-	    !non_mem.start || !pre_mem.start) {
-		dev_err(&pdev->dev, "missing ranges in device node\n");
-		return -EINVAL;
+		if (ret < 0) {
+			dev_err(&pdev->dev, "missing ranges in device node\n");
+			return -EINVAL;
+		}
 	}
 
 	pci_v3.map_irq = of_irq_parse_and_map_pci;
-- 
2.0.4

[PATCH v9 06/12] ARM: integrator: Correct usage of of_pci_range_to_resource()

[Liviu Dudau]

Previously, of_pci_range_to_resource() would return a resource
that contained physical addresses of the IO space even if the
IORESOURCE_IO flags mandate a logical port set of values. Now
that the function has been fixed we need to update the drivers
that were taking advantage of the old behaviour.

Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
---
 arch/arm/mach-integrator/pci_v3.c | 24 +++++++++++++-----------
 1 file changed, 13 insertions(+), 11 deletions(-)

diff --git a/arch/arm/mach-integrator/pci_v3.c b/arch/arm/mach-integrator/pci_v3.c
index 05e1f73..193b7f8 100644
--- a/arch/arm/mach-integrator/pci_v3.c
+++ b/arch/arm/mach-integrator/pci_v3.c
@@ -660,6 +660,7 @@ static void __init pci_v3_preinit(void)
 {
 	unsigned long flags;
 	unsigned int temp;
+	phys_addr_t io_address = pci_pio_to_address(io_mem.start);
 
 	pcibios_min_mem = 0x00100000;
 
@@ -701,7 +702,7 @@ static void __init pci_v3_preinit(void)
 	/*
 	 * Setup window 2 - PCI IO
 	 */
-	v3_writel(V3_LB_BASE2, v3_addr_to_lb_base2(io_mem.start) |
+	v3_writel(V3_LB_BASE2, v3_addr_to_lb_base2(io_address) |
 			V3_LB_BASE_ENABLE);
 	v3_writew(V3_LB_MAP2, v3_addr_to_lb_map2(0));
 
@@ -742,6 +743,7 @@ static void __init pci_v3_preinit(void)
 static void __init pci_v3_postinit(void)
 {
 	unsigned int pci_cmd;
+	phys_addr_t io_address = pci_pio_to_address(io_mem.start);
 
 	pci_cmd = PCI_COMMAND_MEMORY |
 		  PCI_COMMAND_MASTER | PCI_COMMAND_INVALIDATE;
@@ -758,7 +760,7 @@ static void __init pci_v3_postinit(void)
 		       "interrupt: %d\n", ret);
 #endif
 
-	register_isa_ports(non_mem.start, io_mem.start, 0);
+	register_isa_ports(non_mem.start, io_address, 0);
 }
 
 /*
@@ -867,33 +869,33 @@ static int __init pci_v3_probe(struct platform_device *pdev)
 
 	for_each_of_pci_range(&parser, &range) {
 		if (!range.flags) {
-			of_pci_range_to_resource(&range, np, &conf_mem);
+			ret = of_pci_range_to_resource(&range, np, &conf_mem);
 			conf_mem.name = "PCIv3 config";
 		}
 		if (range.flags & IORESOURCE_IO) {
-			of_pci_range_to_resource(&range, np, &io_mem);
+			ret = of_pci_range_to_resource(&range, np, &io_mem);
+			dev_info(&pdev->dev, "IO PCI range converted\n");
 			io_mem.name = "PCIv3 I/O";
 		}
 		if ((range.flags & IORESOURCE_MEM) &&
 			!(range.flags & IORESOURCE_PREFETCH)) {
 			non_mem_pci = range.pci_addr;
 			non_mem_pci_sz = range.size;
-			of_pci_range_to_resource(&range, np, &non_mem);
+			ret = of_pci_range_to_resource(&range, np, &non_mem);
 			non_mem.name = "PCIv3 non-prefetched mem";
 		}
 		if ((range.flags & IORESOURCE_MEM) &&
 			(range.flags & IORESOURCE_PREFETCH)) {
 			pre_mem_pci = range.pci_addr;
 			pre_mem_pci_sz = range.size;
-			of_pci_range_to_resource(&range, np, &pre_mem);
+			ret = of_pci_range_to_resource(&range, np, &pre_mem);
 			pre_mem.name = "PCIv3 prefetched mem";
 		}
-	}
 
-	if (!conf_mem.start || !io_mem.start ||
-	    !non_mem.start || !pre_mem.start) {
-		dev_err(&pdev->dev, "missing ranges in device node\n");
-		return -EINVAL;
+		if (ret < 0) {
+			dev_err(&pdev->dev, "missing ranges in device node\n");
+			return -EINVAL;
+		}
 	}
 
 	pci_v3.map_irq = of_irq_parse_and_map_pci;
-- 
2.0.4

[PATCH v9 06/12] ARM: integrator: Correct usage of of_pci_range_to_resource()

[Liviu Dudau]

Previously, of_pci_range_to_resource() would return a resource
that contained physical addresses of the IO space even if the
IORESOURCE_IO flags mandate a logical port set of values. Now
that the function has been fixed we need to update the drivers
that were taking advantage of the old behaviour.

Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
---
 arch/arm/mach-integrator/pci_v3.c | 24 +++++++++++++-----------
 1 file changed, 13 insertions(+), 11 deletions(-)

diff --git a/arch/arm/mach-integrator/pci_v3.c b/arch/arm/mach-integrator/pci_v3.c
index 05e1f73..193b7f8 100644
--- a/arch/arm/mach-integrator/pci_v3.c
+++ b/arch/arm/mach-integrator/pci_v3.c
@@ -660,6 +660,7 @@ static void __init pci_v3_preinit(void)
 {
 	unsigned long flags;
 	unsigned int temp;
+	phys_addr_t io_address = pci_pio_to_address(io_mem.start);
 
 	pcibios_min_mem = 0x00100000;
 
@@ -701,7 +702,7 @@ static void __init pci_v3_preinit(void)
 	/*
 	 * Setup window 2 - PCI IO
 	 */
-	v3_writel(V3_LB_BASE2, v3_addr_to_lb_base2(io_mem.start) |
+	v3_writel(V3_LB_BASE2, v3_addr_to_lb_base2(io_address) |
 			V3_LB_BASE_ENABLE);
 	v3_writew(V3_LB_MAP2, v3_addr_to_lb_map2(0));
 
@@ -742,6 +743,7 @@ static void __init pci_v3_preinit(void)
 static void __init pci_v3_postinit(void)
 {
 	unsigned int pci_cmd;
+	phys_addr_t io_address = pci_pio_to_address(io_mem.start);
 
 	pci_cmd = PCI_COMMAND_MEMORY |
 		  PCI_COMMAND_MASTER | PCI_COMMAND_INVALIDATE;
@@ -758,7 +760,7 @@ static void __init pci_v3_postinit(void)
 		       "interrupt: %d\n", ret);
 #endif
 
-	register_isa_ports(non_mem.start, io_mem.start, 0);
+	register_isa_ports(non_mem.start, io_address, 0);
 }
 
 /*
@@ -867,33 +869,33 @@ static int __init pci_v3_probe(struct platform_device *pdev)
 
 	for_each_of_pci_range(&parser, &range) {
 		if (!range.flags) {
-			of_pci_range_to_resource(&range, np, &conf_mem);
+			ret = of_pci_range_to_resource(&range, np, &conf_mem);
 			conf_mem.name = "PCIv3 config";
 		}
 		if (range.flags & IORESOURCE_IO) {
-			of_pci_range_to_resource(&range, np, &io_mem);
+			ret = of_pci_range_to_resource(&range, np, &io_mem);
+			dev_info(&pdev->dev, "IO PCI range converted\n");
 			io_mem.name = "PCIv3 I/O";
 		}
 		if ((range.flags & IORESOURCE_MEM) &&
 			!(range.flags & IORESOURCE_PREFETCH)) {
 			non_mem_pci = range.pci_addr;
 			non_mem_pci_sz = range.size;
-			of_pci_range_to_resource(&range, np, &non_mem);
+			ret = of_pci_range_to_resource(&range, np, &non_mem);
 			non_mem.name = "PCIv3 non-prefetched mem";
 		}
 		if ((range.flags & IORESOURCE_MEM) &&
 			(range.flags & IORESOURCE_PREFETCH)) {
 			pre_mem_pci = range.pci_addr;
 			pre_mem_pci_sz = range.size;
-			of_pci_range_to_resource(&range, np, &pre_mem);
+			ret = of_pci_range_to_resource(&range, np, &pre_mem);
 			pre_mem.name = "PCIv3 prefetched mem";
 		}
-	}
 
-	if (!conf_mem.start || !io_mem.start ||
-	    !non_mem.start || !pre_mem.start) {
-		dev_err(&pdev->dev, "missing ranges in device node\n");
-		return -EINVAL;
+		if (ret < 0) {
+			dev_err(&pdev->dev, "missing ranges in device node\n");
+			return -EINVAL;
+		}
 	}
 
 	pci_v3.map_irq = of_irq_parse_and_map_pci;
-- 
2.0.4

Re: [PATCH v9 06/12] ARM: integrator: Correct usage of of_pci_range_to_resource()

[Bjorn Helgaas]

[+cc Linus]

On Tue, Aug 12, 2014 at 05:25:19PM +0100, Liviu Dudau wrote:
> Previously, of_pci_range_to_resource() would return a resource
> that contained physical addresses of the IO space even if the
> IORESOURCE_IO flags mandate a logical port set of values. Now
> that the function has been fixed we need to update the drivers
> that were taking advantage of the old behaviour.
> 
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Russell King <linux@arm.linux.org.uk>
> Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

Something's wrong with the CC: list.  You list Linus here in the changelog,
but I don't see him in the CC: headers.

> ---
>  arch/arm/mach-integrator/pci_v3.c | 24 +++++++++++++-----------
>  1 file changed, 13 insertions(+), 11 deletions(-)
> 
> diff --git a/arch/arm/mach-integrator/pci_v3.c b/arch/arm/mach-integrator/pci_v3.c
> index 05e1f73..193b7f8 100644
> --- a/arch/arm/mach-integrator/pci_v3.c
> +++ b/arch/arm/mach-integrator/pci_v3.c
> @@ -660,6 +660,7 @@ static void __init pci_v3_preinit(void)
>  {
>  	unsigned long flags;
>  	unsigned int temp;
> +	phys_addr_t io_address = pci_pio_to_address(io_mem.start);
>  
>  	pcibios_min_mem = 0x00100000;
>  
> @@ -701,7 +702,7 @@ static void __init pci_v3_preinit(void)
>  	/*
>  	 * Setup window 2 - PCI IO
>  	 */
> -	v3_writel(V3_LB_BASE2, v3_addr_to_lb_base2(io_mem.start) |
> +	v3_writel(V3_LB_BASE2, v3_addr_to_lb_base2(io_address) |
>  			V3_LB_BASE_ENABLE);
>  	v3_writew(V3_LB_MAP2, v3_addr_to_lb_map2(0));
>  
> @@ -742,6 +743,7 @@ static void __init pci_v3_preinit(void)
>  static void __init pci_v3_postinit(void)
>  {
>  	unsigned int pci_cmd;
> +	phys_addr_t io_address = pci_pio_to_address(io_mem.start);
>  
>  	pci_cmd = PCI_COMMAND_MEMORY |
>  		  PCI_COMMAND_MASTER | PCI_COMMAND_INVALIDATE;
> @@ -758,7 +760,7 @@ static void __init pci_v3_postinit(void)
>  		       "interrupt: %d\n", ret);
>  #endif
>  
> -	register_isa_ports(non_mem.start, io_mem.start, 0);
> +	register_isa_ports(non_mem.start, io_address, 0);
>  }
>  
>  /*
> @@ -867,33 +869,33 @@ static int __init pci_v3_probe(struct platform_device *pdev)
>  
>  	for_each_of_pci_range(&parser, &range) {
>  		if (!range.flags) {
> -			of_pci_range_to_resource(&range, np, &conf_mem);
> +			ret = of_pci_range_to_resource(&range, np, &conf_mem);
>  			conf_mem.name = "PCIv3 config";
>  		}
>  		if (range.flags & IORESOURCE_IO) {
> -			of_pci_range_to_resource(&range, np, &io_mem);
> +			ret = of_pci_range_to_resource(&range, np, &io_mem);
> +			dev_info(&pdev->dev, "IO PCI range converted\n");
>  			io_mem.name = "PCIv3 I/O";
>  		}
>  		if ((range.flags & IORESOURCE_MEM) &&
>  			!(range.flags & IORESOURCE_PREFETCH)) {
>  			non_mem_pci = range.pci_addr;
>  			non_mem_pci_sz = range.size;
> -			of_pci_range_to_resource(&range, np, &non_mem);
> +			ret = of_pci_range_to_resource(&range, np, &non_mem);
>  			non_mem.name = "PCIv3 non-prefetched mem";
>  		}
>  		if ((range.flags & IORESOURCE_MEM) &&
>  			(range.flags & IORESOURCE_PREFETCH)) {
>  			pre_mem_pci = range.pci_addr;
>  			pre_mem_pci_sz = range.size;
> -			of_pci_range_to_resource(&range, np, &pre_mem);
> +			ret = of_pci_range_to_resource(&range, np, &pre_mem);
>  			pre_mem.name = "PCIv3 prefetched mem";
>  		}
> -	}
>  
> -	if (!conf_mem.start || !io_mem.start ||
> -	    !non_mem.start || !pre_mem.start) {
> -		dev_err(&pdev->dev, "missing ranges in device node\n");
> -		return -EINVAL;
> +		if (ret < 0) {
> +			dev_err(&pdev->dev, "missing ranges in device node\n");
> +			return -EINVAL;
> +		}
>  	}
>  
>  	pci_v3.map_irq = of_irq_parse_and_map_pci;
> -- 
> 2.0.4
> 

[PATCH v9 06/12] ARM: integrator: Correct usage of of_pci_range_to_resource()

[Bjorn Helgaas]

[+cc Linus]

On Tue, Aug 12, 2014 at 05:25:19PM +0100, Liviu Dudau wrote:
> Previously, of_pci_range_to_resource() would return a resource
> that contained physical addresses of the IO space even if the
> IORESOURCE_IO flags mandate a logical port set of values. Now
> that the function has been fixed we need to update the drivers
> that were taking advantage of the old behaviour.
> 
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Russell King <linux@arm.linux.org.uk>
> Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

Something's wrong with the CC: list.  You list Linus here in the changelog,
but I don't see him in the CC: headers.

> ---
>  arch/arm/mach-integrator/pci_v3.c | 24 +++++++++++++-----------
>  1 file changed, 13 insertions(+), 11 deletions(-)
> 
> diff --git a/arch/arm/mach-integrator/pci_v3.c b/arch/arm/mach-integrator/pci_v3.c
> index 05e1f73..193b7f8 100644
> --- a/arch/arm/mach-integrator/pci_v3.c
> +++ b/arch/arm/mach-integrator/pci_v3.c
> @@ -660,6 +660,7 @@ static void __init pci_v3_preinit(void)
>  {
>  	unsigned long flags;
>  	unsigned int temp;
> +	phys_addr_t io_address = pci_pio_to_address(io_mem.start);
>  
>  	pcibios_min_mem = 0x00100000;
>  
> @@ -701,7 +702,7 @@ static void __init pci_v3_preinit(void)
>  	/*
>  	 * Setup window 2 - PCI IO
>  	 */
> -	v3_writel(V3_LB_BASE2, v3_addr_to_lb_base2(io_mem.start) |
> +	v3_writel(V3_LB_BASE2, v3_addr_to_lb_base2(io_address) |
>  			V3_LB_BASE_ENABLE);
>  	v3_writew(V3_LB_MAP2, v3_addr_to_lb_map2(0));
>  
> @@ -742,6 +743,7 @@ static void __init pci_v3_preinit(void)
>  static void __init pci_v3_postinit(void)
>  {
>  	unsigned int pci_cmd;
> +	phys_addr_t io_address = pci_pio_to_address(io_mem.start);
>  
>  	pci_cmd = PCI_COMMAND_MEMORY |
>  		  PCI_COMMAND_MASTER | PCI_COMMAND_INVALIDATE;
> @@ -758,7 +760,7 @@ static void __init pci_v3_postinit(void)
>  		       "interrupt: %d\n", ret);
>  #endif
>  
> -	register_isa_ports(non_mem.start, io_mem.start, 0);
> +	register_isa_ports(non_mem.start, io_address, 0);
>  }
>  
>  /*
> @@ -867,33 +869,33 @@ static int __init pci_v3_probe(struct platform_device *pdev)
>  
>  	for_each_of_pci_range(&parser, &range) {
>  		if (!range.flags) {
> -			of_pci_range_to_resource(&range, np, &conf_mem);
> +			ret = of_pci_range_to_resource(&range, np, &conf_mem);
>  			conf_mem.name = "PCIv3 config";
>  		}
>  		if (range.flags & IORESOURCE_IO) {
> -			of_pci_range_to_resource(&range, np, &io_mem);
> +			ret = of_pci_range_to_resource(&range, np, &io_mem);
> +			dev_info(&pdev->dev, "IO PCI range converted\n");
>  			io_mem.name = "PCIv3 I/O";
>  		}
>  		if ((range.flags & IORESOURCE_MEM) &&
>  			!(range.flags & IORESOURCE_PREFETCH)) {
>  			non_mem_pci = range.pci_addr;
>  			non_mem_pci_sz = range.size;
> -			of_pci_range_to_resource(&range, np, &non_mem);
> +			ret = of_pci_range_to_resource(&range, np, &non_mem);
>  			non_mem.name = "PCIv3 non-prefetched mem";
>  		}
>  		if ((range.flags & IORESOURCE_MEM) &&
>  			(range.flags & IORESOURCE_PREFETCH)) {
>  			pre_mem_pci = range.pci_addr;
>  			pre_mem_pci_sz = range.size;
> -			of_pci_range_to_resource(&range, np, &pre_mem);
> +			ret = of_pci_range_to_resource(&range, np, &pre_mem);
>  			pre_mem.name = "PCIv3 prefetched mem";
>  		}
> -	}
>  
> -	if (!conf_mem.start || !io_mem.start ||
> -	    !non_mem.start || !pre_mem.start) {
> -		dev_err(&pdev->dev, "missing ranges in device node\n");
> -		return -EINVAL;
> +		if (ret < 0) {
> +			dev_err(&pdev->dev, "missing ranges in device node\n");
> +			return -EINVAL;
> +		}
>  	}
>  
>  	pci_v3.map_irq = of_irq_parse_and_map_pci;
> -- 
> 2.0.4
> 

Re: [PATCH v9 06/12] ARM: integrator: Correct usage of of_pci_range_to_resource()

[Liviu Dudau]

On Fri, Sep 05, 2014 at 11:08:20PM +0100, Bjorn Helgaas wrote:
> [+cc Linus]
> 
> On Tue, Aug 12, 2014 at 05:25:19PM +0100, Liviu Dudau wrote:
> > Previously, of_pci_range_to_resource() would return a resource
> > that contained physical addresses of the IO space even if the
> > IORESOURCE_IO flags mandate a logical port set of values. Now
> > that the function has been fixed we need to update the drivers
> > that were taking advantage of the old behaviour.
> > 
> > Cc: Linus Walleij <linus.walleij@linaro.org>
> > Cc: Arnd Bergmann <arnd@arndb.de>
> > Cc: Rob Herring <robh+dt@kernel.org>
> > Cc: Russell King <linux@arm.linux.org.uk>
> > Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
> 
> Something's wrong with the CC: list.  You list Linus here in the changelog,
> but I don't see him in the CC: headers.

Yes, turns out one of my .git/config directories had supresscc=all.

Best regards,
Liviu

> 
> > ---
> >  arch/arm/mach-integrator/pci_v3.c | 24 +++++++++++++-----------
> >  1 file changed, 13 insertions(+), 11 deletions(-)
> > 
> > diff --git a/arch/arm/mach-integrator/pci_v3.c b/arch/arm/mach-integrator/pci_v3.c
> > index 05e1f73..193b7f8 100644
> > --- a/arch/arm/mach-integrator/pci_v3.c
> > +++ b/arch/arm/mach-integrator/pci_v3.c
> > @@ -660,6 +660,7 @@ static void __init pci_v3_preinit(void)
> >  {
> >  	unsigned long flags;
> >  	unsigned int temp;
> > +	phys_addr_t io_address = pci_pio_to_address(io_mem.start);
> >  
> >  	pcibios_min_mem = 0x00100000;
> >  
> > @@ -701,7 +702,7 @@ static void __init pci_v3_preinit(void)
> >  	/*
> >  	 * Setup window 2 - PCI IO
> >  	 */
> > -	v3_writel(V3_LB_BASE2, v3_addr_to_lb_base2(io_mem.start) |
> > +	v3_writel(V3_LB_BASE2, v3_addr_to_lb_base2(io_address) |
> >  			V3_LB_BASE_ENABLE);
> >  	v3_writew(V3_LB_MAP2, v3_addr_to_lb_map2(0));
> >  
> > @@ -742,6 +743,7 @@ static void __init pci_v3_preinit(void)
> >  static void __init pci_v3_postinit(void)
> >  {
> >  	unsigned int pci_cmd;
> > +	phys_addr_t io_address = pci_pio_to_address(io_mem.start);
> >  
> >  	pci_cmd = PCI_COMMAND_MEMORY |
> >  		  PCI_COMMAND_MASTER | PCI_COMMAND_INVALIDATE;
> > @@ -758,7 +760,7 @@ static void __init pci_v3_postinit(void)
> >  		       "interrupt: %d\n", ret);
> >  #endif
> >  
> > -	register_isa_ports(non_mem.start, io_mem.start, 0);
> > +	register_isa_ports(non_mem.start, io_address, 0);
> >  }
> >  
> >  /*
> > @@ -867,33 +869,33 @@ static int __init pci_v3_probe(struct platform_device *pdev)
> >  
> >  	for_each_of_pci_range(&parser, &range) {
> >  		if (!range.flags) {
> > -			of_pci_range_to_resource(&range, np, &conf_mem);
> > +			ret = of_pci_range_to_resource(&range, np, &conf_mem);
> >  			conf_mem.name = "PCIv3 config";
> >  		}
> >  		if (range.flags & IORESOURCE_IO) {
> > -			of_pci_range_to_resource(&range, np, &io_mem);
> > +			ret = of_pci_range_to_resource(&range, np, &io_mem);
> > +			dev_info(&pdev->dev, "IO PCI range converted\n");
> >  			io_mem.name = "PCIv3 I/O";
> >  		}
> >  		if ((range.flags & IORESOURCE_MEM) &&
> >  			!(range.flags & IORESOURCE_PREFETCH)) {
> >  			non_mem_pci = range.pci_addr;
> >  			non_mem_pci_sz = range.size;
> > -			of_pci_range_to_resource(&range, np, &non_mem);
> > +			ret = of_pci_range_to_resource(&range, np, &non_mem);
> >  			non_mem.name = "PCIv3 non-prefetched mem";
> >  		}
> >  		if ((range.flags & IORESOURCE_MEM) &&
> >  			(range.flags & IORESOURCE_PREFETCH)) {
> >  			pre_mem_pci = range.pci_addr;
> >  			pre_mem_pci_sz = range.size;
> > -			of_pci_range_to_resource(&range, np, &pre_mem);
> > +			ret = of_pci_range_to_resource(&range, np, &pre_mem);
> >  			pre_mem.name = "PCIv3 prefetched mem";
> >  		}
> > -	}
> >  
> > -	if (!conf_mem.start || !io_mem.start ||
> > -	    !non_mem.start || !pre_mem.start) {
> > -		dev_err(&pdev->dev, "missing ranges in device node\n");
> > -		return -EINVAL;
> > +		if (ret < 0) {
> > +			dev_err(&pdev->dev, "missing ranges in device node\n");
> > +			return -EINVAL;
> > +		}
> >  	}
> >  
> >  	pci_v3.map_irq = of_irq_parse_and_map_pci;
> > -- 
> > 2.0.4
> > 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯

[PATCH v9 06/12] ARM: integrator: Correct usage of of_pci_range_to_resource()

[Liviu Dudau]

On Fri, Sep 05, 2014 at 11:08:20PM +0100, Bjorn Helgaas wrote:
> [+cc Linus]
> 
> On Tue, Aug 12, 2014 at 05:25:19PM +0100, Liviu Dudau wrote:
> > Previously, of_pci_range_to_resource() would return a resource
> > that contained physical addresses of the IO space even if the
> > IORESOURCE_IO flags mandate a logical port set of values. Now
> > that the function has been fixed we need to update the drivers
> > that were taking advantage of the old behaviour.
> > 
> > Cc: Linus Walleij <linus.walleij@linaro.org>
> > Cc: Arnd Bergmann <arnd@arndb.de>
> > Cc: Rob Herring <robh+dt@kernel.org>
> > Cc: Russell King <linux@arm.linux.org.uk>
> > Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
> 
> Something's wrong with the CC: list.  You list Linus here in the changelog,
> but I don't see him in the CC: headers.

Yes, turns out one of my .git/config directories had supresscc=all.

Best regards,
Liviu

> 
> > ---
> >  arch/arm/mach-integrator/pci_v3.c | 24 +++++++++++++-----------
> >  1 file changed, 13 insertions(+), 11 deletions(-)
> > 
> > diff --git a/arch/arm/mach-integrator/pci_v3.c b/arch/arm/mach-integrator/pci_v3.c
> > index 05e1f73..193b7f8 100644
> > --- a/arch/arm/mach-integrator/pci_v3.c
> > +++ b/arch/arm/mach-integrator/pci_v3.c
> > @@ -660,6 +660,7 @@ static void __init pci_v3_preinit(void)
> >  {
> >  	unsigned long flags;
> >  	unsigned int temp;
> > +	phys_addr_t io_address = pci_pio_to_address(io_mem.start);
> >  
> >  	pcibios_min_mem = 0x00100000;
> >  
> > @@ -701,7 +702,7 @@ static void __init pci_v3_preinit(void)
> >  	/*
> >  	 * Setup window 2 - PCI IO
> >  	 */
> > -	v3_writel(V3_LB_BASE2, v3_addr_to_lb_base2(io_mem.start) |
> > +	v3_writel(V3_LB_BASE2, v3_addr_to_lb_base2(io_address) |
> >  			V3_LB_BASE_ENABLE);
> >  	v3_writew(V3_LB_MAP2, v3_addr_to_lb_map2(0));
> >  
> > @@ -742,6 +743,7 @@ static void __init pci_v3_preinit(void)
> >  static void __init pci_v3_postinit(void)
> >  {
> >  	unsigned int pci_cmd;
> > +	phys_addr_t io_address = pci_pio_to_address(io_mem.start);
> >  
> >  	pci_cmd = PCI_COMMAND_MEMORY |
> >  		  PCI_COMMAND_MASTER | PCI_COMMAND_INVALIDATE;
> > @@ -758,7 +760,7 @@ static void __init pci_v3_postinit(void)
> >  		       "interrupt: %d\n", ret);
> >  #endif
> >  
> > -	register_isa_ports(non_mem.start, io_mem.start, 0);
> > +	register_isa_ports(non_mem.start, io_address, 0);
> >  }
> >  
> >  /*
> > @@ -867,33 +869,33 @@ static int __init pci_v3_probe(struct platform_device *pdev)
> >  
> >  	for_each_of_pci_range(&parser, &range) {
> >  		if (!range.flags) {
> > -			of_pci_range_to_resource(&range, np, &conf_mem);
> > +			ret = of_pci_range_to_resource(&range, np, &conf_mem);
> >  			conf_mem.name = "PCIv3 config";
> >  		}
> >  		if (range.flags & IORESOURCE_IO) {
> > -			of_pci_range_to_resource(&range, np, &io_mem);
> > +			ret = of_pci_range_to_resource(&range, np, &io_mem);
> > +			dev_info(&pdev->dev, "IO PCI range converted\n");
> >  			io_mem.name = "PCIv3 I/O";
> >  		}
> >  		if ((range.flags & IORESOURCE_MEM) &&
> >  			!(range.flags & IORESOURCE_PREFETCH)) {
> >  			non_mem_pci = range.pci_addr;
> >  			non_mem_pci_sz = range.size;
> > -			of_pci_range_to_resource(&range, np, &non_mem);
> > +			ret = of_pci_range_to_resource(&range, np, &non_mem);
> >  			non_mem.name = "PCIv3 non-prefetched mem";
> >  		}
> >  		if ((range.flags & IORESOURCE_MEM) &&
> >  			(range.flags & IORESOURCE_PREFETCH)) {
> >  			pre_mem_pci = range.pci_addr;
> >  			pre_mem_pci_sz = range.size;
> > -			of_pci_range_to_resource(&range, np, &pre_mem);
> > +			ret = of_pci_range_to_resource(&range, np, &pre_mem);
> >  			pre_mem.name = "PCIv3 prefetched mem";
> >  		}
> > -	}
> >  
> > -	if (!conf_mem.start || !io_mem.start ||
> > -	    !non_mem.start || !pre_mem.start) {
> > -		dev_err(&pdev->dev, "missing ranges in device node\n");
> > -		return -EINVAL;
> > +		if (ret < 0) {
> > +			dev_err(&pdev->dev, "missing ranges in device node\n");
> > +			return -EINVAL;
> > +		}
> >  	}
> >  
> >  	pci_v3.map_irq = of_irq_parse_and_map_pci;
> > -- 
> > 2.0.4
> > 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ?\_(?)_/?

Re: [PATCH v9 06/12] ARM: integrator: Correct usage of of_pci_range_to_resource()

[Linus Walleij]

On Tue, Aug 12, 2014 at 6:25 PM, Liviu Dudau <Liviu.Dudau@arm.com> wrote:

> Previously, of_pci_range_to_resource() would return a resource
> that contained physical addresses of the IO space even if the
> IORESOURCE_IO flags mandate a logical port set of values. Now
> that the function has been fixed we need to update the drivers
> that were taking advantage of the old behaviour.
>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Russell King <linux@arm.linux.org.uk>
> Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

I guess you know what you're doing so:
Acked-by: Linus Walleij <linus.walleij@linaro.org>

I expect this patch to go through the PCI tree or so? Or do you
expect me to funnel it?

Yours,
Linus Walleij

[PATCH v9 06/12] ARM: integrator: Correct usage of of_pci_range_to_resource()

[Linus Walleij]

On Tue, Aug 12, 2014 at 6:25 PM, Liviu Dudau <Liviu.Dudau@arm.com> wrote:

> Previously, of_pci_range_to_resource() would return a resource
> that contained physical addresses of the IO space even if the
> IORESOURCE_IO flags mandate a logical port set of values. Now
> that the function has been fixed we need to update the drivers
> that were taking advantage of the old behaviour.
>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Russell King <linux@arm.linux.org.uk>
> Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

I guess you know what you're doing so:
Acked-by: Linus Walleij <linus.walleij@linaro.org>

I expect this patch to go through the PCI tree or so? Or do you
expect me to funnel it?

Yours,
Linus Walleij

Re: [PATCH v9 06/12] ARM: integrator: Correct usage of of_pci_range_to_resource()

[Liviu Dudau]

On Mon, Sep 22, 2014 at 01:47:16PM +0100, Linus Walleij wrote:
> On Tue, Aug 12, 2014 at 6:25 PM, Liviu Dudau <Liviu.Dudau@arm.com> wrote:
> 
> > Previously, of_pci_range_to_resource() would return a resource
> > that contained physical addresses of the IO space even if the
> > IORESOURCE_IO flags mandate a logical port set of values. Now
> > that the function has been fixed we need to update the drivers
> > that were taking advantage of the old behaviour.
> >
> > Cc: Linus Walleij <linus.walleij@linaro.org>
> > Cc: Arnd Bergmann <arnd@arndb.de>
> > Cc: Rob Herring <robh+dt@kernel.org>
> > Cc: Russell King <linux@arm.linux.org.uk>
> > Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
> 
> I guess you know what you're doing so:

I hope so :)

> Acked-by: Linus Walleij <linus.walleij@linaro.org>

Thanks!

> 
> I expect this patch to go through the PCI tree or so? Or do you
> expect me to funnel it?

It will go through PCI tree together with the patch that "fixes"
the existing functionality.

Best regards,
Liviu 

> 
> Yours,
> Linus Walleij
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯

[PATCH v9 06/12] ARM: integrator: Correct usage of of_pci_range_to_resource()

[Liviu Dudau]

On Mon, Sep 22, 2014 at 01:47:16PM +0100, Linus Walleij wrote:
> On Tue, Aug 12, 2014 at 6:25 PM, Liviu Dudau <Liviu.Dudau@arm.com> wrote:
> 
> > Previously, of_pci_range_to_resource() would return a resource
> > that contained physical addresses of the IO space even if the
> > IORESOURCE_IO flags mandate a logical port set of values. Now
> > that the function has been fixed we need to update the drivers
> > that were taking advantage of the old behaviour.
> >
> > Cc: Linus Walleij <linus.walleij@linaro.org>
> > Cc: Arnd Bergmann <arnd@arndb.de>
> > Cc: Rob Herring <robh+dt@kernel.org>
> > Cc: Russell King <linux@arm.linux.org.uk>
> > Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
> 
> I guess you know what you're doing so:

I hope so :)

> Acked-by: Linus Walleij <linus.walleij@linaro.org>

Thanks!

> 
> I expect this patch to go through the PCI tree or so? Or do you
> expect me to funnel it?

It will go through PCI tree together with the patch that "fixes"
the existing functionality.

Best regards,
Liviu 

> 
> Yours,
> Linus Walleij
> 

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ?\_(?)_/?

[PATCH v9 07/12] PCI: Create pci_host_bridge before its associated bus in pci_create_root_bus.

[Liviu Dudau]

Before commit 7b5436635800 the pci_host_bridge was created before the root bus.
As that commit has added a needless dependency on the bus for pci_alloc_host_bridge()
the creation order has been changed for no good reason. Revert the order of
creation as we are going to depend on the pci_host_bridge structure to retrieve the
domain number of the root bus.

Cc: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
Acked-by: Grant Likely <grant.likely@linaro.org>
Tested-by: Tanmay Inamdar <tinamdar@apm.com>
---
 drivers/pci/probe.c | 32 +++++++++++++++++---------------
 1 file changed, 17 insertions(+), 15 deletions(-)

diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index e3cf8a2..5ff72ec 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -515,7 +515,7 @@ static void pci_release_host_bridge_dev(struct device *dev)
 	kfree(bridge);
 }
 
-static struct pci_host_bridge *pci_alloc_host_bridge(struct pci_bus *b)
+static struct pci_host_bridge *pci_alloc_host_bridge(void)
 {
 	struct pci_host_bridge *bridge;
 
@@ -524,7 +524,8 @@ static struct pci_host_bridge *pci_alloc_host_bridge(struct pci_bus *b)
 		return NULL;
 
 	INIT_LIST_HEAD(&bridge->windows);
-	bridge->bus = b;
+	bridge->dev.release = pci_release_host_bridge_dev;
+
 	return bridge;
 }
 
@@ -1761,9 +1762,15 @@ struct pci_bus *pci_create_root_bus(struct device *parent, int bus,
 	char bus_addr[64];
 	char *fmt;
 
+	bridge = pci_alloc_host_bridge();
+	if (!bridge)
+		return NULL;
+
+	bridge->dev.parent = parent;
+
 	b = pci_alloc_bus();
 	if (!b)
-		return NULL;
+		goto err_out;
 
 	b->sysdata = sysdata;
 	b->ops = ops;
@@ -1772,26 +1779,19 @@ struct pci_bus *pci_create_root_bus(struct device *parent, int bus,
 	if (b2) {
 		/* If we already got to this bus through a different bridge, ignore it */
 		dev_dbg(&b2->dev, "bus already known\n");
-		goto err_out;
+		goto err_bus_out;
 	}
 
-	bridge = pci_alloc_host_bridge(b);
-	if (!bridge)
-		goto err_out;
-
-	bridge->dev.parent = parent;
-	bridge->dev.release = pci_release_host_bridge_dev;
+	bridge->bus = b;
 	dev_set_name(&bridge->dev, "pci%04x:%02x", pci_domain_nr(b), bus);
 	error = pcibios_root_bridge_prepare(bridge);
-	if (error) {
-		kfree(bridge);
+	if (error)
 		goto err_out;
-	}
 
 	error = device_register(&bridge->dev);
 	if (error) {
 		put_device(&bridge->dev);
-		goto err_out;
+		goto err_bus_out;
 	}
 	b->bridge = get_device(&bridge->dev);
 	device_enable_async_suspend(b->bridge);
@@ -1848,8 +1848,10 @@ struct pci_bus *pci_create_root_bus(struct device *parent, int bus,
 class_dev_reg_err:
 	put_device(&bridge->dev);
 	device_unregister(&bridge->dev);
-err_out:
+err_bus_out:
 	kfree(b);
+err_out:
+	kfree(bridge);
 	return NULL;
 }
 
-- 
2.0.4

[PATCH v9 07/12] PCI: Create pci_host_bridge before its associated bus in pci_create_root_bus.

[Liviu Dudau]

Before commit 7b5436635800 the pci_host_bridge was created before the root bus.
As that commit has added a needless dependency on the bus for pci_alloc_host_bridge()
the creation order has been changed for no good reason. Revert the order of
creation as we are going to depend on the pci_host_bridge structure to retrieve the
domain number of the root bus.

Cc: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
Acked-by: Grant Likely <grant.likely@linaro.org>
Tested-by: Tanmay Inamdar <tinamdar@apm.com>
---
 drivers/pci/probe.c | 32 +++++++++++++++++---------------
 1 file changed, 17 insertions(+), 15 deletions(-)

diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index e3cf8a2..5ff72ec 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -515,7 +515,7 @@ static void pci_release_host_bridge_dev(struct device *dev)
 	kfree(bridge);
 }
 
-static struct pci_host_bridge *pci_alloc_host_bridge(struct pci_bus *b)
+static struct pci_host_bridge *pci_alloc_host_bridge(void)
 {
 	struct pci_host_bridge *bridge;
 
@@ -524,7 +524,8 @@ static struct pci_host_bridge *pci_alloc_host_bridge(struct pci_bus *b)
 		return NULL;
 
 	INIT_LIST_HEAD(&bridge->windows);
-	bridge->bus = b;
+	bridge->dev.release = pci_release_host_bridge_dev;
+
 	return bridge;
 }
 
@@ -1761,9 +1762,15 @@ struct pci_bus *pci_create_root_bus(struct device *parent, int bus,
 	char bus_addr[64];
 	char *fmt;
 
+	bridge = pci_alloc_host_bridge();
+	if (!bridge)
+		return NULL;
+
+	bridge->dev.parent = parent;
+
 	b = pci_alloc_bus();
 	if (!b)
-		return NULL;
+		goto err_out;
 
 	b->sysdata = sysdata;
 	b->ops = ops;
@@ -1772,26 +1779,19 @@ struct pci_bus *pci_create_root_bus(struct device *parent, int bus,
 	if (b2) {
 		/* If we already got to this bus through a different bridge, ignore it */
 		dev_dbg(&b2->dev, "bus already known\n");
-		goto err_out;
+		goto err_bus_out;
 	}
 
-	bridge = pci_alloc_host_bridge(b);
-	if (!bridge)
-		goto err_out;
-
-	bridge->dev.parent = parent;
-	bridge->dev.release = pci_release_host_bridge_dev;
+	bridge->bus = b;
 	dev_set_name(&bridge->dev, "pci%04x:%02x", pci_domain_nr(b), bus);
 	error = pcibios_root_bridge_prepare(bridge);
-	if (error) {
-		kfree(bridge);
+	if (error)
 		goto err_out;
-	}
 
 	error = device_register(&bridge->dev);
 	if (error) {
 		put_device(&bridge->dev);
-		goto err_out;
+		goto err_bus_out;
 	}
 	b->bridge = get_device(&bridge->dev);
 	device_enable_async_suspend(b->bridge);
@@ -1848,8 +1848,10 @@ struct pci_bus *pci_create_root_bus(struct device *parent, int bus,
 class_dev_reg_err:
 	put_device(&bridge->dev);
 	device_unregister(&bridge->dev);
-err_out:
+err_bus_out:
 	kfree(b);
+err_out:
+	kfree(bridge);
 	return NULL;
 }
 
-- 
2.0.4

[PATCH v9 08/12] PCI: Introduce generic domain handling for PCI busses.

[Liviu Dudau]

The handling of PCI domains (or PCI segments in ACPI speak) is
usually a straightforward affair but its implementation is
currently left to the architectural code, with pci_domain_nr(b)
querying the value of the domain associated with bus b.

This patch introduces CONFIG_PCI_DOMAINS_GENERIC as an
option that can be selected if an architecture want a
simple implementation where the value of the domain
associated with a bus is stored in struct pci_bus.

The architectures that select CONFIG_PCI_DOMAINS_GENERIC will
then have to implement pci_bus_assign_domain_nr() as a way
of setting the domain number associated with a root bus.
All child busses except the root bus will inherit the domain_nr
value from their parent.

Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Catalin Marinas <Catalin.Marinas@arm.com>
[Renamed pci_set_domain_nr() to pci_bus_assign_domain_nr()]
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
---
 drivers/pci/probe.c | 11 ++++++++---
 include/linux/pci.h | 21 +++++++++++++++++++++
 2 files changed, 29 insertions(+), 3 deletions(-)

diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 5ff72ec..ef891d2 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -485,7 +485,7 @@ void pci_read_bridge_bases(struct pci_bus *child)
 	}
 }
 
-static struct pci_bus *pci_alloc_bus(void)
+static struct pci_bus *pci_alloc_bus(struct pci_bus *parent)
 {
 	struct pci_bus *b;
 
@@ -500,6 +500,10 @@ static struct pci_bus *pci_alloc_bus(void)
 	INIT_LIST_HEAD(&b->resources);
 	b->max_bus_speed = PCI_SPEED_UNKNOWN;
 	b->cur_bus_speed = PCI_SPEED_UNKNOWN;
+#ifdef CONFIG_PCI_DOMAINS_GENERIC
+	if (parent)
+		b->domain_nr = parent->domain_nr;
+#endif
 	return b;
 }
 
@@ -672,7 +676,7 @@ static struct pci_bus *pci_alloc_child_bus(struct pci_bus *parent,
 	/*
 	 * Allocate a new bus, and inherit stuff from the parent..
 	 */
-	child = pci_alloc_bus();
+	child = pci_alloc_bus(parent);
 	if (!child)
 		return NULL;
 
@@ -1768,13 +1772,14 @@ struct pci_bus *pci_create_root_bus(struct device *parent, int bus,
 
 	bridge->dev.parent = parent;
 
-	b = pci_alloc_bus();
+	b = pci_alloc_bus(NULL);
 	if (!b)
 		goto err_out;
 
 	b->sysdata = sysdata;
 	b->ops = ops;
 	b->number = b->busn_res.start = bus;
+	pci_bus_assign_domain_nr(b, parent);
 	b2 = pci_find_bus(pci_domain_nr(b), bus);
 	if (b2) {
 		/* If we already got to this bus through a different bridge, ignore it */
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 466bcd1..1d0e0b5 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -456,6 +456,9 @@ struct pci_bus {
 	unsigned char	primary;	/* number of primary bridge */
 	unsigned char	max_bus_speed;	/* enum pci_bus_speed */
 	unsigned char	cur_bus_speed;	/* enum pci_bus_speed */
+#ifdef CONFIG_PCI_DOMAINS_GENERIC
+	int		domain_nr;
+#endif
 
 	char		name[48];
 
@@ -1288,6 +1291,24 @@ static inline int pci_domain_nr(struct pci_bus *bus) { return 0; }
 static inline int pci_proc_domain(struct pci_bus *bus) { return 0; }
 #endif /* CONFIG_PCI_DOMAINS */
 
+/*
+ * Generic implementation for PCI domain support. If your
+ * architecture does not need custom management of PCI
+ * domains then this implementation will be used
+ */
+#ifdef CONFIG_PCI_DOMAINS_GENERIC
+static inline int pci_domain_nr(struct pci_bus *bus)
+{
+	return bus->domain_nr;
+}
+void pci_bus_assign_domain_nr(struct pci_bus *bus, struct device *parent);
+#else
+static inline void pci_bus_assign_domain_nr(struct pci_bus *bus,
+					struct device *parent)
+{
+}
+#endif
+
 /* some architectures require additional setup to direct VGA traffic */
 typedef int (*arch_set_vga_state_t)(struct pci_dev *pdev, bool decode,
 		      unsigned int command_bits, u32 flags);
-- 
2.0.4

[PATCH v9 08/12] PCI: Introduce generic domain handling for PCI busses.

[Liviu Dudau]

The handling of PCI domains (or PCI segments in ACPI speak) is
usually a straightforward affair but its implementation is
currently left to the architectural code, with pci_domain_nr(b)
querying the value of the domain associated with bus b.

This patch introduces CONFIG_PCI_DOMAINS_GENERIC as an
option that can be selected if an architecture want a
simple implementation where the value of the domain
associated with a bus is stored in struct pci_bus.

The architectures that select CONFIG_PCI_DOMAINS_GENERIC will
then have to implement pci_bus_assign_domain_nr() as a way
of setting the domain number associated with a root bus.
All child busses except the root bus will inherit the domain_nr
value from their parent.

Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Catalin Marinas <Catalin.Marinas@arm.com>
[Renamed pci_set_domain_nr() to pci_bus_assign_domain_nr()]
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
---
 drivers/pci/probe.c | 11 ++++++++---
 include/linux/pci.h | 21 +++++++++++++++++++++
 2 files changed, 29 insertions(+), 3 deletions(-)

diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 5ff72ec..ef891d2 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -485,7 +485,7 @@ void pci_read_bridge_bases(struct pci_bus *child)
 	}
 }
 
-static struct pci_bus *pci_alloc_bus(void)
+static struct pci_bus *pci_alloc_bus(struct pci_bus *parent)
 {
 	struct pci_bus *b;
 
@@ -500,6 +500,10 @@ static struct pci_bus *pci_alloc_bus(void)
 	INIT_LIST_HEAD(&b->resources);
 	b->max_bus_speed = PCI_SPEED_UNKNOWN;
 	b->cur_bus_speed = PCI_SPEED_UNKNOWN;
+#ifdef CONFIG_PCI_DOMAINS_GENERIC
+	if (parent)
+		b->domain_nr = parent->domain_nr;
+#endif
 	return b;
 }
 
@@ -672,7 +676,7 @@ static struct pci_bus *pci_alloc_child_bus(struct pci_bus *parent,
 	/*
 	 * Allocate a new bus, and inherit stuff from the parent..
 	 */
-	child = pci_alloc_bus();
+	child = pci_alloc_bus(parent);
 	if (!child)
 		return NULL;
 
@@ -1768,13 +1772,14 @@ struct pci_bus *pci_create_root_bus(struct device *parent, int bus,
 
 	bridge->dev.parent = parent;
 
-	b = pci_alloc_bus();
+	b = pci_alloc_bus(NULL);
 	if (!b)
 		goto err_out;
 
 	b->sysdata = sysdata;
 	b->ops = ops;
 	b->number = b->busn_res.start = bus;
+	pci_bus_assign_domain_nr(b, parent);
 	b2 = pci_find_bus(pci_domain_nr(b), bus);
 	if (b2) {
 		/* If we already got to this bus through a different bridge, ignore it */
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 466bcd1..1d0e0b5 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -456,6 +456,9 @@ struct pci_bus {
 	unsigned char	primary;	/* number of primary bridge */
 	unsigned char	max_bus_speed;	/* enum pci_bus_speed */
 	unsigned char	cur_bus_speed;	/* enum pci_bus_speed */
+#ifdef CONFIG_PCI_DOMAINS_GENERIC
+	int		domain_nr;
+#endif
 
 	char		name[48];
 
@@ -1288,6 +1291,24 @@ static inline int pci_domain_nr(struct pci_bus *bus) { return 0; }
 static inline int pci_proc_domain(struct pci_bus *bus) { return 0; }
 #endif /* CONFIG_PCI_DOMAINS */
 
+/*
+ * Generic implementation for PCI domain support. If your
+ * architecture does not need custom management of PCI
+ * domains then this implementation will be used
+ */
+#ifdef CONFIG_PCI_DOMAINS_GENERIC
+static inline int pci_domain_nr(struct pci_bus *bus)
+{
+	return bus->domain_nr;
+}
+void pci_bus_assign_domain_nr(struct pci_bus *bus, struct device *parent);
+#else
+static inline void pci_bus_assign_domain_nr(struct pci_bus *bus,
+					struct device *parent)
+{
+}
+#endif
+
 /* some architectures require additional setup to direct VGA traffic */
 typedef int (*arch_set_vga_state_t)(struct pci_dev *pdev, bool decode,
 		      unsigned int command_bits, u32 flags);
-- 
2.0.4

[PATCH v9 09/12] OF: Introduce helper function for getting PCI domain_nr

[Liviu Dudau]

Add of_pci_get_domain_nr() to retrieve the PCI domain number
of a given device from DT. If the information is not present,
the function can be requested to allocate a new domain number.

Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Rob Herring <robh+dt@kernel.org>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
---
 drivers/of/of_pci.c    | 34 ++++++++++++++++++++++++++++++++++
 include/linux/of_pci.h |  7 +++++++
 2 files changed, 41 insertions(+)

diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 8481996..a107edb 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -89,6 +89,40 @@ int of_pci_parse_bus_range(struct device_node *node, struct resource *res)
 }
 EXPORT_SYMBOL_GPL(of_pci_parse_bus_range);
 
+static atomic_t of_domain_nr = ATOMIC_INIT(-1);
+
+/**
+ * This function will try to obtain the host bridge domain number by
+ * using of_alias_get_id() call with "pci-domain" as a stem. If that
+ * fails, a local allocator will be used. The local allocator can
+ * be requested to return a new domain_nr if the information is missing
+ * from the device tree.
+ *
+ * @node: device tree node with the domain information
+ * @allocate_if_missing: if DT lacks information about the domain nr,
+ * allocate a new number.
+ *
+ * Returns the associated domain number from DT, or a new domain number
+ * if DT information is missing and @allocate_if_missing is true. If
+ * @allocate_if_missing is false then the last allocated domain number
+ * will be returned.
+ */
+int of_pci_get_domain_nr(struct device_node *node, bool allocate_if_missing)
+{
+	int domain;
+
+	domain = of_alias_get_id(node, "pci-domain");
+	if (domain == -ENODEV) {
+		if (allocate_if_missing)
+			domain = atomic_inc_return(&of_domain_nr);
+		else
+			domain = atomic_read(&of_domain_nr);
+	}
+
+	return domain;
+}
+EXPORT_SYMBOL_GPL(of_pci_get_domain_nr);
+
 #ifdef CONFIG_PCI_MSI
 
 static LIST_HEAD(of_pci_msi_chip_list);
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index dde3a4a..3a3824c 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -15,6 +15,7 @@ struct device_node *of_pci_find_child_device(struct device_node *parent,
 int of_pci_get_devfn(struct device_node *np);
 int of_irq_parse_and_map_pci(const struct pci_dev *dev, u8 slot, u8 pin);
 int of_pci_parse_bus_range(struct device_node *node, struct resource *res);
+int of_pci_get_domain_nr(struct device_node *node, bool allocate_if_missing);
 #else
 static inline int of_irq_parse_pci(const struct pci_dev *pdev, struct of_phandle_args *out_irq)
 {
@@ -43,6 +44,12 @@ of_pci_parse_bus_range(struct device_node *node, struct resource *res)
 {
 	return -EINVAL;
 }
+
+static inline int
+of_pci_get_domain_nr(struct device_node *node, bool allocate_if_missing)
+{
+	return -1;
+}
 #endif
 
 #if defined(CONFIG_OF) && defined(CONFIG_PCI_MSI)
-- 
2.0.4

[PATCH v9 09/12] OF: Introduce helper function for getting PCI domain_nr

[Liviu Dudau]

Add of_pci_get_domain_nr() to retrieve the PCI domain number
of a given device from DT. If the information is not present,
the function can be requested to allocate a new domain number.

Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Rob Herring <robh+dt@kernel.org>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
---
 drivers/of/of_pci.c    | 34 ++++++++++++++++++++++++++++++++++
 include/linux/of_pci.h |  7 +++++++
 2 files changed, 41 insertions(+)

diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 8481996..a107edb 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -89,6 +89,40 @@ int of_pci_parse_bus_range(struct device_node *node, struct resource *res)
 }
 EXPORT_SYMBOL_GPL(of_pci_parse_bus_range);
 
+static atomic_t of_domain_nr = ATOMIC_INIT(-1);
+
+/**
+ * This function will try to obtain the host bridge domain number by
+ * using of_alias_get_id() call with "pci-domain" as a stem. If that
+ * fails, a local allocator will be used. The local allocator can
+ * be requested to return a new domain_nr if the information is missing
+ * from the device tree.
+ *
+ * @node: device tree node with the domain information
+ * @allocate_if_missing: if DT lacks information about the domain nr,
+ * allocate a new number.
+ *
+ * Returns the associated domain number from DT, or a new domain number
+ * if DT information is missing and @allocate_if_missing is true. If
+ * @allocate_if_missing is false then the last allocated domain number
+ * will be returned.
+ */
+int of_pci_get_domain_nr(struct device_node *node, bool allocate_if_missing)
+{
+	int domain;
+
+	domain = of_alias_get_id(node, "pci-domain");
+	if (domain == -ENODEV) {
+		if (allocate_if_missing)
+			domain = atomic_inc_return(&of_domain_nr);
+		else
+			domain = atomic_read(&of_domain_nr);
+	}
+
+	return domain;
+}
+EXPORT_SYMBOL_GPL(of_pci_get_domain_nr);
+
 #ifdef CONFIG_PCI_MSI
 
 static LIST_HEAD(of_pci_msi_chip_list);
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index dde3a4a..3a3824c 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -15,6 +15,7 @@ struct device_node *of_pci_find_child_device(struct device_node *parent,
 int of_pci_get_devfn(struct device_node *np);
 int of_irq_parse_and_map_pci(const struct pci_dev *dev, u8 slot, u8 pin);
 int of_pci_parse_bus_range(struct device_node *node, struct resource *res);
+int of_pci_get_domain_nr(struct device_node *node, bool allocate_if_missing);
 #else
 static inline int of_irq_parse_pci(const struct pci_dev *pdev, struct of_phandle_args *out_irq)
 {
@@ -43,6 +44,12 @@ of_pci_parse_bus_range(struct device_node *node, struct resource *res)
 {
 	return -EINVAL;
 }
+
+static inline int
+of_pci_get_domain_nr(struct device_node *node, bool allocate_if_missing)
+{
+	return -1;
+}
 #endif
 
 #if defined(CONFIG_OF) && defined(CONFIG_PCI_MSI)
-- 
2.0.4

[PATCH v9 10/12] OF: PCI: Add support for creating a generic host_bridge from DT

[Liviu Dudau]

Provide a function to parse the PCI DT ranges and use it to
create a pci_host_bridge structure together with its associated
bus. Scan all the child busses and add the devices found.

This is the OF equivalent of pci_scan_root_bus() where all the
resources needed for creating the root bus are discovered from
information passed in the device tree.

Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Tanmay Inamdar <tinamdar@apm.com>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
---
 drivers/of/of_pci.c       | 159 ++++++++++++++++++++++++++++++++++++++++++++++
 drivers/pci/host-bridge.c |  15 +++++
 include/linux/of_pci.h    |  13 ++++
 include/linux/pci.h       |   6 ++
 4 files changed, 193 insertions(+)

diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index a107edb..895b59f 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -1,7 +1,9 @@
 #include <linux/kernel.h>
 #include <linux/export.h>
 #include <linux/of.h>
+#include <linux/of_address.h>
 #include <linux/of_pci.h>
+#include <linux/slab.h>
 
 static inline int __of_pci_pci_compare(struct device_node *node,
 				       unsigned int data)
@@ -123,6 +125,163 @@ int of_pci_get_domain_nr(struct device_node *node, bool allocate_if_missing)
 }
 EXPORT_SYMBOL_GPL(of_pci_get_domain_nr);
 
+/**
+ * pci_host_bridge_of_get_ranges - Parse PCI host bridge resources from DT
+ * @dev: device node of the host bridge having the range property
+ * @resources: list where the range of resources will be added after DT parsing
+ * @io_base: pointer to a variable that will contain on return the physical
+ * address for the start of the I/O range.
+ *
+ * It is the callers job to free the @resources list if an error is returned.
+ *
+ * This function will parse the "ranges" property of a PCI host bridge device
+ * node and setup the resource mapping based on its content. It is expected
+ * that the property conforms with the Power ePAPR document.
+ *
+ * Each architecture is then offered the chance of applying their own
+ * filtering of pci_host_bridge_windows based on their own restrictions by
+ * calling pcibios_fixup_bridge_ranges(). The filtered list of windows
+ * can then be used when creating a pci_host_bridge structure.
+ */
+static int pci_host_bridge_of_get_ranges(struct device_node *dev,
+		struct list_head *resources, resource_size_t *io_base)
+{
+	struct resource *res;
+	struct of_pci_range range;
+	struct of_pci_range_parser parser;
+	int err;
+
+	pr_info("PCI host bridge %s ranges:\n", dev->full_name);
+
+	/* Check for ranges property */
+	err = of_pci_range_parser_init(&parser, dev);
+	if (err)
+		return err;
+
+	pr_debug("Parsing ranges property...\n");
+	for_each_of_pci_range(&parser, &range) {
+		/* Read next ranges element */
+		pr_info(" %s %#010llx..%#010llx -> %#010llx\n",
+			((range.flags & IORESOURCE_TYPE_BITS) == IORESOURCE_IO) ? " IO" : "MEM",
+			range.cpu_addr, range.cpu_addr + range.size - 1,
+			range.pci_addr);
+
+		/*
+		 * If we failed translation or got a zero-sized region
+		 * then skip this range
+		 */
+		if (range.cpu_addr == OF_BAD_ADDR || range.size == 0)
+			continue;
+
+		res = kzalloc(sizeof(struct resource), GFP_KERNEL);
+		if (!res)
+			return -ENOMEM;
+
+		err = of_pci_range_to_resource(&range, dev, res);
+		if (err) {
+			kfree(res);
+			return err;
+		}
+
+		if (resource_type(res) == IORESOURCE_IO) {
+			if (*io_base)
+				pr_warn("More than one I/O resource converted. CPU offset for old range lost!\n");
+			*io_base = range.cpu_addr;
+		}
+
+		pci_add_resource_offset(resources, res,
+				res->start - range.pci_addr);
+	}
+
+	/* Apply architecture specific fixups for the ranges */
+	return pcibios_fixup_bridge_ranges(resources);
+}
+
+/**
+ * of_create_pci_host_bridge - Create a PCI host bridge structure using
+ * information passed in the DT.
+ * @parent: device owning this host bridge
+ * @busno: bus number associated with the bridge root bus.
+ * @bus_max: maximum number of busses for this bridge.
+ * @ops: pci_ops associated with the host controller
+ * @setup: setup function used by host controller driver to prepare the bridge.
+ * @host_data: opaque data structure used by the host controller.
+ *
+ * Returns zero if successful or a negative error value if the call failed.
+ */
+int of_create_pci_host_bridge(struct device *parent, unsigned char busno,
+			unsigned char bus_max, struct pci_ops *ops,
+			int (*setup)(struct pci_host_bridge *, resource_size_t),
+			void *host_data)
+{
+	int err, max;
+	struct resource *bus_range;
+	struct pci_bus *root_bus;
+	struct pci_host_bridge *bridge = NULL;
+	resource_size_t io_base = 0;	/* physical address for the start of I/O area */
+	LIST_HEAD(res);
+
+	bus_range = kzalloc(sizeof(*bus_range), GFP_KERNEL);
+	if (!bus_range)
+		return -ENOMEM;
+
+	err = of_pci_parse_bus_range(parent->of_node, bus_range);
+	if (err) {
+		bus_range->start = busno;
+		bus_range->end = bus_max;
+		bus_range->flags = IORESOURCE_BUS;
+		dev_info(parent, "No bus range found for %s, using %pR\n",
+			parent->of_node->full_name, &bus_range);
+	} else {
+		if (bus_range->end > bus_range->start + bus_max)
+			bus_range->end = bus_range->start + bus_max;
+	}
+	pci_add_resource(&res, bus_range);
+
+	/* now parse the rest of host bridge bus ranges */
+	err = pci_host_bridge_of_get_ranges(parent->of_node, &res, &io_base);
+	if (err)
+		goto err_create;
+
+	/* then create the root bus */
+	root_bus = pci_create_root_bus(parent, busno, ops, host_data, &res);
+	if (!root_bus) {
+		err = -ENXIO;
+		goto err_create;
+	}
+
+	bridge = to_pci_host_bridge(root_bus->bridge);
+
+	/* give control to the host controller driver to finish setup */
+	if (setup) {
+		err = setup(bridge, io_base);
+		if (err)
+			goto err_setup;
+	}
+
+	max = pci_scan_child_bus(root_bus);
+	pci_bus_update_busn_res_end(root_bus, max);
+
+	if (!pci_has_flag(PCI_PROBE_ONLY))
+		pci_assign_unassigned_bus_resources(root_bus);
+
+	pci_bus_add_devices(root_bus);
+
+	return 0;
+
+err_setup:
+	pci_remove_bus(root_bus);
+	put_device(&bridge->dev);
+	device_unregister(&bridge->dev);
+	kfree(root_bus);
+	kfree(bridge);
+
+err_create:
+	pci_free_resource_list(&res);
+	return err;
+}
+EXPORT_SYMBOL_GPL(of_create_pci_host_bridge);
+
 #ifdef CONFIG_PCI_MSI
 
 static LIST_HEAD(of_pci_msi_chip_list);
diff --git a/drivers/pci/host-bridge.c b/drivers/pci/host-bridge.c
index 0e5f3c9..3b22f93 100644
--- a/drivers/pci/host-bridge.c
+++ b/drivers/pci/host-bridge.c
@@ -82,3 +82,18 @@ void pcibios_bus_to_resource(struct pci_bus *bus, struct resource *res,
 	res->end = region->end + offset;
 }
 EXPORT_SYMBOL(pcibios_bus_to_resource);
+
+/**
+ * Simple version of the platform specific code for filtering the list
+ * of resources obtained from the ranges declaration in DT.
+ *
+ * Platforms can override this function in order to impose stronger
+ * constraints onto the list of resources that a host bridge can use.
+ * The filtered list will then be used to create a root bus and associate
+ * it with the host bridge.
+ *
+ */
+int __weak pcibios_fixup_bridge_ranges(struct list_head *resources)
+{
+	return 0;
+}
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index 3a3824c..f58a1cb 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -16,6 +16,11 @@ int of_pci_get_devfn(struct device_node *np);
 int of_irq_parse_and_map_pci(const struct pci_dev *dev, u8 slot, u8 pin);
 int of_pci_parse_bus_range(struct device_node *node, struct resource *res);
 int of_pci_get_domain_nr(struct device_node *node, bool allocate_if_missing);
+int of_create_pci_host_bridge(struct device *parent, unsigned char busno,
+			unsigned char bus_max, struct pci_ops *ops,
+			int (*setup)(struct pci_host_bridge *, resource_size_t),
+			void *host_data);
+
 #else
 static inline int of_irq_parse_pci(const struct pci_dev *pdev, struct of_phandle_args *out_irq)
 {
@@ -50,6 +55,14 @@ of_pci_get_domain_nr(struct device_node *node, bool allocate_if_missing)
 {
 	return -1;
 }
+
+int of_create_pci_host_bridge(struct device *parent, unsigned char busno,
+			unsigned char bus_max, struct pci_ops *ops,
+			int (*setup)(struct pci_host_bridge *, resource_size_t),
+			void *host_data)
+{
+	return -EINVAL;
+}
 #endif
 
 #if defined(CONFIG_OF) && defined(CONFIG_PCI_MSI)
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 1d0e0b5..e1e0d80 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1821,6 +1821,12 @@ static inline struct device_node *pci_bus_to_OF_node(struct pci_bus *bus)
 	return bus ? bus->dev.of_node : NULL;
 }
 
+/*
+ * Used by architecture code to apply any quirks to the list of
+ * pci_host_bridge resource ranges before they are being used
+ * by of_create_pci_host_bridge()
+ */
+int pcibios_fixup_bridge_ranges(struct list_head *resources);
 #else /* CONFIG_OF */
 static inline void pci_set_of_node(struct pci_dev *dev) { }
 static inline void pci_release_of_node(struct pci_dev *dev) { }
-- 
2.0.4

[PATCH v9 10/12] OF: PCI: Add support for creating a generic host_bridge from DT

[Liviu Dudau]

Provide a function to parse the PCI DT ranges and use it to
create a pci_host_bridge structure together with its associated
bus. Scan all the child busses and add the devices found.

This is the OF equivalent of pci_scan_root_bus() where all the
resources needed for creating the root bus are discovered from
information passed in the device tree.

Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Tanmay Inamdar <tinamdar@apm.com>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
---
 drivers/of/of_pci.c       | 159 ++++++++++++++++++++++++++++++++++++++++++++++
 drivers/pci/host-bridge.c |  15 +++++
 include/linux/of_pci.h    |  13 ++++
 include/linux/pci.h       |   6 ++
 4 files changed, 193 insertions(+)

diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index a107edb..895b59f 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -1,7 +1,9 @@
 #include <linux/kernel.h>
 #include <linux/export.h>
 #include <linux/of.h>
+#include <linux/of_address.h>
 #include <linux/of_pci.h>
+#include <linux/slab.h>
 
 static inline int __of_pci_pci_compare(struct device_node *node,
 				       unsigned int data)
@@ -123,6 +125,163 @@ int of_pci_get_domain_nr(struct device_node *node, bool allocate_if_missing)
 }
 EXPORT_SYMBOL_GPL(of_pci_get_domain_nr);
 
+/**
+ * pci_host_bridge_of_get_ranges - Parse PCI host bridge resources from DT
+ * @dev: device node of the host bridge having the range property
+ * @resources: list where the range of resources will be added after DT parsing
+ * @io_base: pointer to a variable that will contain on return the physical
+ * address for the start of the I/O range.
+ *
+ * It is the callers job to free the @resources list if an error is returned.
+ *
+ * This function will parse the "ranges" property of a PCI host bridge device
+ * node and setup the resource mapping based on its content. It is expected
+ * that the property conforms with the Power ePAPR document.
+ *
+ * Each architecture is then offered the chance of applying their own
+ * filtering of pci_host_bridge_windows based on their own restrictions by
+ * calling pcibios_fixup_bridge_ranges(). The filtered list of windows
+ * can then be used when creating a pci_host_bridge structure.
+ */
+static int pci_host_bridge_of_get_ranges(struct device_node *dev,
+		struct list_head *resources, resource_size_t *io_base)
+{
+	struct resource *res;
+	struct of_pci_range range;
+	struct of_pci_range_parser parser;
+	int err;
+
+	pr_info("PCI host bridge %s ranges:\n", dev->full_name);
+
+	/* Check for ranges property */
+	err = of_pci_range_parser_init(&parser, dev);
+	if (err)
+		return err;
+
+	pr_debug("Parsing ranges property...\n");
+	for_each_of_pci_range(&parser, &range) {
+		/* Read next ranges element */
+		pr_info(" %s %#010llx..%#010llx -> %#010llx\n",
+			((range.flags & IORESOURCE_TYPE_BITS) == IORESOURCE_IO) ? " IO" : "MEM",
+			range.cpu_addr, range.cpu_addr + range.size - 1,
+			range.pci_addr);
+
+		/*
+		 * If we failed translation or got a zero-sized region
+		 * then skip this range
+		 */
+		if (range.cpu_addr == OF_BAD_ADDR || range.size == 0)
+			continue;
+
+		res = kzalloc(sizeof(struct resource), GFP_KERNEL);
+		if (!res)
+			return -ENOMEM;
+
+		err = of_pci_range_to_resource(&range, dev, res);
+		if (err) {
+			kfree(res);
+			return err;
+		}
+
+		if (resource_type(res) == IORESOURCE_IO) {
+			if (*io_base)
+				pr_warn("More than one I/O resource converted. CPU offset for old range lost!\n");
+			*io_base = range.cpu_addr;
+		}
+
+		pci_add_resource_offset(resources, res,
+				res->start - range.pci_addr);
+	}
+
+	/* Apply architecture specific fixups for the ranges */
+	return pcibios_fixup_bridge_ranges(resources);
+}
+
+/**
+ * of_create_pci_host_bridge - Create a PCI host bridge structure using
+ * information passed in the DT.
+ * @parent: device owning this host bridge
+ * @busno: bus number associated with the bridge root bus.
+ * @bus_max: maximum number of busses for this bridge.
+ * @ops: pci_ops associated with the host controller
+ * @setup: setup function used by host controller driver to prepare the bridge.
+ * @host_data: opaque data structure used by the host controller.
+ *
+ * Returns zero if successful or a negative error value if the call failed.
+ */
+int of_create_pci_host_bridge(struct device *parent, unsigned char busno,
+			unsigned char bus_max, struct pci_ops *ops,
+			int (*setup)(struct pci_host_bridge *, resource_size_t),
+			void *host_data)
+{
+	int err, max;
+	struct resource *bus_range;
+	struct pci_bus *root_bus;
+	struct pci_host_bridge *bridge = NULL;
+	resource_size_t io_base = 0;	/* physical address for the start of I/O area */
+	LIST_HEAD(res);
+
+	bus_range = kzalloc(sizeof(*bus_range), GFP_KERNEL);
+	if (!bus_range)
+		return -ENOMEM;
+
+	err = of_pci_parse_bus_range(parent->of_node, bus_range);
+	if (err) {
+		bus_range->start = busno;
+		bus_range->end = bus_max;
+		bus_range->flags = IORESOURCE_BUS;
+		dev_info(parent, "No bus range found for %s, using %pR\n",
+			parent->of_node->full_name, &bus_range);
+	} else {
+		if (bus_range->end > bus_range->start + bus_max)
+			bus_range->end = bus_range->start + bus_max;
+	}
+	pci_add_resource(&res, bus_range);
+
+	/* now parse the rest of host bridge bus ranges */
+	err = pci_host_bridge_of_get_ranges(parent->of_node, &res, &io_base);
+	if (err)
+		goto err_create;
+
+	/* then create the root bus */
+	root_bus = pci_create_root_bus(parent, busno, ops, host_data, &res);
+	if (!root_bus) {
+		err = -ENXIO;
+		goto err_create;
+	}
+
+	bridge = to_pci_host_bridge(root_bus->bridge);
+
+	/* give control to the host controller driver to finish setup */
+	if (setup) {
+		err = setup(bridge, io_base);
+		if (err)
+			goto err_setup;
+	}
+
+	max = pci_scan_child_bus(root_bus);
+	pci_bus_update_busn_res_end(root_bus, max);
+
+	if (!pci_has_flag(PCI_PROBE_ONLY))
+		pci_assign_unassigned_bus_resources(root_bus);
+
+	pci_bus_add_devices(root_bus);
+
+	return 0;
+
+err_setup:
+	pci_remove_bus(root_bus);
+	put_device(&bridge->dev);
+	device_unregister(&bridge->dev);
+	kfree(root_bus);
+	kfree(bridge);
+
+err_create:
+	pci_free_resource_list(&res);
+	return err;
+}
+EXPORT_SYMBOL_GPL(of_create_pci_host_bridge);
+
 #ifdef CONFIG_PCI_MSI
 
 static LIST_HEAD(of_pci_msi_chip_list);
diff --git a/drivers/pci/host-bridge.c b/drivers/pci/host-bridge.c
index 0e5f3c9..3b22f93 100644
--- a/drivers/pci/host-bridge.c
+++ b/drivers/pci/host-bridge.c
@@ -82,3 +82,18 @@ void pcibios_bus_to_resource(struct pci_bus *bus, struct resource *res,
 	res->end = region->end + offset;
 }
 EXPORT_SYMBOL(pcibios_bus_to_resource);
+
+/**
+ * Simple version of the platform specific code for filtering the list
+ * of resources obtained from the ranges declaration in DT.
+ *
+ * Platforms can override this function in order to impose stronger
+ * constraints onto the list of resources that a host bridge can use.
+ * The filtered list will then be used to create a root bus and associate
+ * it with the host bridge.
+ *
+ */
+int __weak pcibios_fixup_bridge_ranges(struct list_head *resources)
+{
+	return 0;
+}
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index 3a3824c..f58a1cb 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -16,6 +16,11 @@ int of_pci_get_devfn(struct device_node *np);
 int of_irq_parse_and_map_pci(const struct pci_dev *dev, u8 slot, u8 pin);
 int of_pci_parse_bus_range(struct device_node *node, struct resource *res);
 int of_pci_get_domain_nr(struct device_node *node, bool allocate_if_missing);
+int of_create_pci_host_bridge(struct device *parent, unsigned char busno,
+			unsigned char bus_max, struct pci_ops *ops,
+			int (*setup)(struct pci_host_bridge *, resource_size_t),
+			void *host_data);
+
 #else
 static inline int of_irq_parse_pci(const struct pci_dev *pdev, struct of_phandle_args *out_irq)
 {
@@ -50,6 +55,14 @@ of_pci_get_domain_nr(struct device_node *node, bool allocate_if_missing)
 {
 	return -1;
 }
+
+int of_create_pci_host_bridge(struct device *parent, unsigned char busno,
+			unsigned char bus_max, struct pci_ops *ops,
+			int (*setup)(struct pci_host_bridge *, resource_size_t),
+			void *host_data)
+{
+	return -EINVAL;
+}
 #endif
 
 #if defined(CONFIG_OF) && defined(CONFIG_PCI_MSI)
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 1d0e0b5..e1e0d80 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1821,6 +1821,12 @@ static inline struct device_node *pci_bus_to_OF_node(struct pci_bus *bus)
 	return bus ? bus->dev.of_node : NULL;
 }
 
+/*
+ * Used by architecture code to apply any quirks to the list of
+ * pci_host_bridge resource ranges before they are being used
+ * by of_create_pci_host_bridge()
+ */
+int pcibios_fixup_bridge_ranges(struct list_head *resources);
 #else /* CONFIG_OF */
 static inline void pci_set_of_node(struct pci_dev *dev) { }
 static inline void pci_release_of_node(struct pci_dev *dev) { }
-- 
2.0.4

[PATCH v9 10/12] OF: PCI: Add support for creating a generic host_bridge from DT

[Liviu Dudau]

Provide a function to parse the PCI DT ranges and use it to
create a pci_host_bridge structure together with its associated
bus. Scan all the child busses and add the devices found.

This is the OF equivalent of pci_scan_root_bus() where all the
resources needed for creating the root bus are discovered from
information passed in the device tree.

Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Tanmay Inamdar <tinamdar@apm.com>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
---
 drivers/of/of_pci.c       | 159 ++++++++++++++++++++++++++++++++++++++++++++++
 drivers/pci/host-bridge.c |  15 +++++
 include/linux/of_pci.h    |  13 ++++
 include/linux/pci.h       |   6 ++
 4 files changed, 193 insertions(+)

diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index a107edb..895b59f 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -1,7 +1,9 @@
 #include <linux/kernel.h>
 #include <linux/export.h>
 #include <linux/of.h>
+#include <linux/of_address.h>
 #include <linux/of_pci.h>
+#include <linux/slab.h>
 
 static inline int __of_pci_pci_compare(struct device_node *node,
 				       unsigned int data)
@@ -123,6 +125,163 @@ int of_pci_get_domain_nr(struct device_node *node, bool allocate_if_missing)
 }
 EXPORT_SYMBOL_GPL(of_pci_get_domain_nr);
 
+/**
+ * pci_host_bridge_of_get_ranges - Parse PCI host bridge resources from DT
+ * @dev: device node of the host bridge having the range property
+ * @resources: list where the range of resources will be added after DT parsing
+ * @io_base: pointer to a variable that will contain on return the physical
+ * address for the start of the I/O range.
+ *
+ * It is the callers job to free the @resources list if an error is returned.
+ *
+ * This function will parse the "ranges" property of a PCI host bridge device
+ * node and setup the resource mapping based on its content. It is expected
+ * that the property conforms with the Power ePAPR document.
+ *
+ * Each architecture is then offered the chance of applying their own
+ * filtering of pci_host_bridge_windows based on their own restrictions by
+ * calling pcibios_fixup_bridge_ranges(). The filtered list of windows
+ * can then be used when creating a pci_host_bridge structure.
+ */
+static int pci_host_bridge_of_get_ranges(struct device_node *dev,
+		struct list_head *resources, resource_size_t *io_base)
+{
+	struct resource *res;
+	struct of_pci_range range;
+	struct of_pci_range_parser parser;
+	int err;
+
+	pr_info("PCI host bridge %s ranges:\n", dev->full_name);
+
+	/* Check for ranges property */
+	err = of_pci_range_parser_init(&parser, dev);
+	if (err)
+		return err;
+
+	pr_debug("Parsing ranges property...\n");
+	for_each_of_pci_range(&parser, &range) {
+		/* Read next ranges element */
+		pr_info(" %s %#010llx..%#010llx -> %#010llx\n",
+			((range.flags & IORESOURCE_TYPE_BITS) == IORESOURCE_IO) ? " IO" : "MEM",
+			range.cpu_addr, range.cpu_addr + range.size - 1,
+			range.pci_addr);
+
+		/*
+		 * If we failed translation or got a zero-sized region
+		 * then skip this range
+		 */
+		if (range.cpu_addr == OF_BAD_ADDR || range.size == 0)
+			continue;
+
+		res = kzalloc(sizeof(struct resource), GFP_KERNEL);
+		if (!res)
+			return -ENOMEM;
+
+		err = of_pci_range_to_resource(&range, dev, res);
+		if (err) {
+			kfree(res);
+			return err;
+		}
+
+		if (resource_type(res) == IORESOURCE_IO) {
+			if (*io_base)
+				pr_warn("More than one I/O resource converted. CPU offset for old range lost!\n");
+			*io_base = range.cpu_addr;
+		}
+
+		pci_add_resource_offset(resources, res,
+				res->start - range.pci_addr);
+	}
+
+	/* Apply architecture specific fixups for the ranges */
+	return pcibios_fixup_bridge_ranges(resources);
+}
+
+/**
+ * of_create_pci_host_bridge - Create a PCI host bridge structure using
+ * information passed in the DT.
+ * @parent: device owning this host bridge
+ * @busno: bus number associated with the bridge root bus.
+ * @bus_max: maximum number of busses for this bridge.
+ * @ops: pci_ops associated with the host controller
+ * @setup: setup function used by host controller driver to prepare the bridge.
+ * @host_data: opaque data structure used by the host controller.
+ *
+ * Returns zero if successful or a negative error value if the call failed.
+ */
+int of_create_pci_host_bridge(struct device *parent, unsigned char busno,
+			unsigned char bus_max, struct pci_ops *ops,
+			int (*setup)(struct pci_host_bridge *, resource_size_t),
+			void *host_data)
+{
+	int err, max;
+	struct resource *bus_range;
+	struct pci_bus *root_bus;
+	struct pci_host_bridge *bridge = NULL;
+	resource_size_t io_base = 0;	/* physical address for the start of I/O area */
+	LIST_HEAD(res);
+
+	bus_range = kzalloc(sizeof(*bus_range), GFP_KERNEL);
+	if (!bus_range)
+		return -ENOMEM;
+
+	err = of_pci_parse_bus_range(parent->of_node, bus_range);
+	if (err) {
+		bus_range->start = busno;
+		bus_range->end = bus_max;
+		bus_range->flags = IORESOURCE_BUS;
+		dev_info(parent, "No bus range found for %s, using %pR\n",
+			parent->of_node->full_name, &bus_range);
+	} else {
+		if (bus_range->end > bus_range->start + bus_max)
+			bus_range->end = bus_range->start + bus_max;
+	}
+	pci_add_resource(&res, bus_range);
+
+	/* now parse the rest of host bridge bus ranges */
+	err = pci_host_bridge_of_get_ranges(parent->of_node, &res, &io_base);
+	if (err)
+		goto err_create;
+
+	/* then create the root bus */
+	root_bus = pci_create_root_bus(parent, busno, ops, host_data, &res);
+	if (!root_bus) {
+		err = -ENXIO;
+		goto err_create;
+	}
+
+	bridge = to_pci_host_bridge(root_bus->bridge);
+
+	/* give control to the host controller driver to finish setup */
+	if (setup) {
+		err = setup(bridge, io_base);
+		if (err)
+			goto err_setup;
+	}
+
+	max = pci_scan_child_bus(root_bus);
+	pci_bus_update_busn_res_end(root_bus, max);
+
+	if (!pci_has_flag(PCI_PROBE_ONLY))
+		pci_assign_unassigned_bus_resources(root_bus);
+
+	pci_bus_add_devices(root_bus);
+
+	return 0;
+
+err_setup:
+	pci_remove_bus(root_bus);
+	put_device(&bridge->dev);
+	device_unregister(&bridge->dev);
+	kfree(root_bus);
+	kfree(bridge);
+
+err_create:
+	pci_free_resource_list(&res);
+	return err;
+}
+EXPORT_SYMBOL_GPL(of_create_pci_host_bridge);
+
 #ifdef CONFIG_PCI_MSI
 
 static LIST_HEAD(of_pci_msi_chip_list);
diff --git a/drivers/pci/host-bridge.c b/drivers/pci/host-bridge.c
index 0e5f3c9..3b22f93 100644
--- a/drivers/pci/host-bridge.c
+++ b/drivers/pci/host-bridge.c
@@ -82,3 +82,18 @@ void pcibios_bus_to_resource(struct pci_bus *bus, struct resource *res,
 	res->end = region->end + offset;
 }
 EXPORT_SYMBOL(pcibios_bus_to_resource);
+
+/**
+ * Simple version of the platform specific code for filtering the list
+ * of resources obtained from the ranges declaration in DT.
+ *
+ * Platforms can override this function in order to impose stronger
+ * constraints onto the list of resources that a host bridge can use.
+ * The filtered list will then be used to create a root bus and associate
+ * it with the host bridge.
+ *
+ */
+int __weak pcibios_fixup_bridge_ranges(struct list_head *resources)
+{
+	return 0;
+}
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index 3a3824c..f58a1cb 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -16,6 +16,11 @@ int of_pci_get_devfn(struct device_node *np);
 int of_irq_parse_and_map_pci(const struct pci_dev *dev, u8 slot, u8 pin);
 int of_pci_parse_bus_range(struct device_node *node, struct resource *res);
 int of_pci_get_domain_nr(struct device_node *node, bool allocate_if_missing);
+int of_create_pci_host_bridge(struct device *parent, unsigned char busno,
+			unsigned char bus_max, struct pci_ops *ops,
+			int (*setup)(struct pci_host_bridge *, resource_size_t),
+			void *host_data);
+
 #else
 static inline int of_irq_parse_pci(const struct pci_dev *pdev, struct of_phandle_args *out_irq)
 {
@@ -50,6 +55,14 @@ of_pci_get_domain_nr(struct device_node *node, bool allocate_if_missing)
 {
 	return -1;
 }
+
+int of_create_pci_host_bridge(struct device *parent, unsigned char busno,
+			unsigned char bus_max, struct pci_ops *ops,
+			int (*setup)(struct pci_host_bridge *, resource_size_t),
+			void *host_data)
+{
+	return -EINVAL;
+}
 #endif
 
 #if defined(CONFIG_OF) && defined(CONFIG_PCI_MSI)
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 1d0e0b5..e1e0d80 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1821,6 +1821,12 @@ static inline struct device_node *pci_bus_to_OF_node(struct pci_bus *bus)
 	return bus ? bus->dev.of_node : NULL;
 }
 
+/*
+ * Used by architecture code to apply any quirks to the list of
+ * pci_host_bridge resource ranges before they are being used
+ * by of_create_pci_host_bridge()
+ */
+int pcibios_fixup_bridge_ranges(struct list_head *resources);
 #else /* CONFIG_OF */
 static inline void pci_set_of_node(struct pci_dev *dev) { }
 static inline void pci_release_of_node(struct pci_dev *dev) { }
-- 
2.0.4

[PATCH v9 11/12] arm64: Add pgprot_device() interface for device mappings.

[Liviu Dudau]

Add pgprot_device(). It will be aliased to pgprot_noncached for
architectures that do not support special attributes for device
mapping. Used by arm64 to define new attributes for devices.

Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
---
 include/asm-generic/pgtable.h    | 4 ++++
 arch/arm64/include/asm/pgtable.h | 2 ++
 2 files changed, 6 insertions(+)

diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
index 53b2acc..977e545 100644
--- a/include/asm-generic/pgtable.h
+++ b/include/asm-generic/pgtable.h
@@ -249,6 +249,10 @@ static inline int pmd_same(pmd_t pmd_a, pmd_t pmd_b)
 #define pgprot_writecombine pgprot_noncached
 #endif
 
+#ifndef pgprot_device
+#define pgprot_device pgprot_noncached
+#endif
+
 /*
  * When walking page tables, get the address of the next boundary,
  * or the end address of the range if that comes earlier.  Although no
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index e0ccceb..7dbacaf 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -277,6 +277,8 @@ static inline int has_transparent_hugepage(void)
 	__pgprot_modify(prot, PTE_ATTRINDX_MASK, PTE_ATTRINDX(MT_DEVICE_nGnRnE) | PTE_PXN | PTE_UXN)
 #define pgprot_writecombine(prot) \
 	__pgprot_modify(prot, PTE_ATTRINDX_MASK, PTE_ATTRINDX(MT_NORMAL_NC) | PTE_PXN | PTE_UXN)
+#define pgprot_device(prot) \
+	__pgprot_modify(prot, PTE_ATTRINDX_MASK, PTE_ATTRINDX(MT_DEVICE_nGnRE) | PTE_PXN | PTE_UXN)
 #define __HAVE_PHYS_MEM_ACCESS_PROT
 struct file;
 extern pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn,
-- 
2.0.4

[PATCH v9 11/12] arm64: Add pgprot_device() interface for device mappings.

[Liviu Dudau]

Add pgprot_device(). It will be aliased to pgprot_noncached for
architectures that do not support special attributes for device
mapping. Used by arm64 to define new attributes for devices.

Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
---
 include/asm-generic/pgtable.h    | 4 ++++
 arch/arm64/include/asm/pgtable.h | 2 ++
 2 files changed, 6 insertions(+)

diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
index 53b2acc..977e545 100644
--- a/include/asm-generic/pgtable.h
+++ b/include/asm-generic/pgtable.h
@@ -249,6 +249,10 @@ static inline int pmd_same(pmd_t pmd_a, pmd_t pmd_b)
 #define pgprot_writecombine pgprot_noncached
 #endif
 
+#ifndef pgprot_device
+#define pgprot_device pgprot_noncached
+#endif
+
 /*
  * When walking page tables, get the address of the next boundary,
  * or the end address of the range if that comes earlier.  Although no
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index e0ccceb..7dbacaf 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -277,6 +277,8 @@ static inline int has_transparent_hugepage(void)
 	__pgprot_modify(prot, PTE_ATTRINDX_MASK, PTE_ATTRINDX(MT_DEVICE_nGnRnE) | PTE_PXN | PTE_UXN)
 #define pgprot_writecombine(prot) \
 	__pgprot_modify(prot, PTE_ATTRINDX_MASK, PTE_ATTRINDX(MT_NORMAL_NC) | PTE_PXN | PTE_UXN)
+#define pgprot_device(prot) \
+	__pgprot_modify(prot, PTE_ATTRINDX_MASK, PTE_ATTRINDX(MT_DEVICE_nGnRE) | PTE_PXN | PTE_UXN)
 #define __HAVE_PHYS_MEM_ACCESS_PROT
 struct file;
 extern pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn,
-- 
2.0.4

[PATCH v9 11/12] arm64: Add pgprot_device() interface for device mappings.

[Liviu Dudau]

Add pgprot_device(). It will be aliased to pgprot_noncached for
architectures that do not support special attributes for device
mapping. Used by arm64 to define new attributes for devices.

Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
---
 include/asm-generic/pgtable.h    | 4 ++++
 arch/arm64/include/asm/pgtable.h | 2 ++
 2 files changed, 6 insertions(+)

diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
index 53b2acc..977e545 100644
--- a/include/asm-generic/pgtable.h
+++ b/include/asm-generic/pgtable.h
@@ -249,6 +249,10 @@ static inline int pmd_same(pmd_t pmd_a, pmd_t pmd_b)
 #define pgprot_writecombine pgprot_noncached
 #endif
 
+#ifndef pgprot_device
+#define pgprot_device pgprot_noncached
+#endif
+
 /*
  * When walking page tables, get the address of the next boundary,
  * or the end address of the range if that comes earlier.  Although no
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index e0ccceb..7dbacaf 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -277,6 +277,8 @@ static inline int has_transparent_hugepage(void)
 	__pgprot_modify(prot, PTE_ATTRINDX_MASK, PTE_ATTRINDX(MT_DEVICE_nGnRnE) | PTE_PXN | PTE_UXN)
 #define pgprot_writecombine(prot) \
 	__pgprot_modify(prot, PTE_ATTRINDX_MASK, PTE_ATTRINDX(MT_NORMAL_NC) | PTE_PXN | PTE_UXN)
+#define pgprot_device(prot) \
+	__pgprot_modify(prot, PTE_ATTRINDX_MASK, PTE_ATTRINDX(MT_DEVICE_nGnRE) | PTE_PXN | PTE_UXN)
 #define __HAVE_PHYS_MEM_ACCESS_PROT
 struct file;
 extern pgprot_t phys_mem_access_prot(struct file *file, unsigned long pfn,
-- 
2.0.4

Re: [PATCH v9 11/12] arm64: Add pgprot_device() interface for device mappings.

[Catalin Marinas]

On Tue, Aug 12, 2014 at 05:25:24PM +0100, Liviu Dudau wrote:
> Add pgprot_device(). It will be aliased to pgprot_noncached for
> architectures that do not support special attributes for device
> mapping. Used by arm64 to define new attributes for devices.
> 
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

Acked-by: Catalin Marinas <catalin.marinas@arm.com>

[PATCH v9 11/12] arm64: Add pgprot_device() interface for device mappings.

[Catalin Marinas]

On Tue, Aug 12, 2014 at 05:25:24PM +0100, Liviu Dudau wrote:
> Add pgprot_device(). It will be aliased to pgprot_noncached for
> architectures that do not support special attributes for device
> mapping. Used by arm64 to define new attributes for devices.
> 
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

Acked-by: Catalin Marinas <catalin.marinas@arm.com>

[PATCH v9 12/12] PCI: Introduce pci_remap_iospace() for remapping PCI I/O bus resources into CPU space

[Liviu Dudau]

Introduce a default implementation for remapping PCI bus I/O resources
onto the CPU address space. Architectures with special needs may
provide their own version, but most should be able to use this one.

Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Herring <robh+dt@kernel.org>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
---
 drivers/pci/pci.c   | 33 +++++++++++++++++++++++++++++++++
 include/linux/pci.h |  3 +++
 2 files changed, 36 insertions(+)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 29d1775..76d21b6 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -2707,6 +2707,39 @@ int pci_request_regions_exclusive(struct pci_dev *pdev, const char *res_name)
 }
 EXPORT_SYMBOL(pci_request_regions_exclusive);
 
+/**
+ *	pci_remap_iospace - Remap the memory mapped I/O space
+ *	@res: Resource describing the I/O space
+ *	@phys_addr: physical address where the range will be mapped.
+ *
+ *	Remap the memory mapped I/O space described by the @res
+ *	into the CPU physical address space. Only architectures
+ *	that have memory mapped IO defined (and hence PCI_IOBASE)
+ *	should call this function.
+ */
+int __weak pci_remap_iospace(const struct resource *res, phys_addr_t phys_addr)
+{
+	int err = -ENODEV;
+
+#ifdef PCI_IOBASE
+	if (!(res->flags & IORESOURCE_IO))
+		return -EINVAL;
+
+	if (res->end > IO_SPACE_LIMIT)
+		return -EINVAL;
+
+	err = ioremap_page_range(res->start + (unsigned long)PCI_IOBASE,
+				res->end + 1 + (unsigned long)PCI_IOBASE,
+				phys_addr, pgprot_device(PAGE_KERNEL));
+#else
+	/* this architecture does not have memory mapped I/O space,
+	   so this function should never be called */
+	WARN_ON(1);
+#endif
+
+	return err;
+}
+
 static void __pci_set_master(struct pci_dev *dev, bool enable)
 {
 	u16 old_cmd, cmd;
diff --git a/include/linux/pci.h b/include/linux/pci.h
index e1e0d80..988c2f5 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1098,6 +1098,9 @@ int __must_check pci_bus_alloc_resource(struct pci_bus *bus,
 						  resource_size_t),
 			void *alignf_data);
 
+
+int pci_remap_iospace(const struct resource *res, phys_addr_t phys_addr);
+
 static inline dma_addr_t pci_bus_address(struct pci_dev *pdev, int bar)
 {
 	struct pci_bus_region region;
-- 
2.0.4

[PATCH v9 12/12] PCI: Introduce pci_remap_iospace() for remapping PCI I/O bus resources into CPU space

[Liviu Dudau]

Introduce a default implementation for remapping PCI bus I/O resources
onto the CPU address space. Architectures with special needs may
provide their own version, but most should be able to use this one.

Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Herring <robh+dt@kernel.org>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
---
 drivers/pci/pci.c   | 33 +++++++++++++++++++++++++++++++++
 include/linux/pci.h |  3 +++
 2 files changed, 36 insertions(+)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 29d1775..76d21b6 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -2707,6 +2707,39 @@ int pci_request_regions_exclusive(struct pci_dev *pdev, const char *res_name)
 }
 EXPORT_SYMBOL(pci_request_regions_exclusive);
 
+/**
+ *	pci_remap_iospace - Remap the memory mapped I/O space
+ *	@res: Resource describing the I/O space
+ *	@phys_addr: physical address where the range will be mapped.
+ *
+ *	Remap the memory mapped I/O space described by the @res
+ *	into the CPU physical address space. Only architectures
+ *	that have memory mapped IO defined (and hence PCI_IOBASE)
+ *	should call this function.
+ */
+int __weak pci_remap_iospace(const struct resource *res, phys_addr_t phys_addr)
+{
+	int err = -ENODEV;
+
+#ifdef PCI_IOBASE
+	if (!(res->flags & IORESOURCE_IO))
+		return -EINVAL;
+
+	if (res->end > IO_SPACE_LIMIT)
+		return -EINVAL;
+
+	err = ioremap_page_range(res->start + (unsigned long)PCI_IOBASE,
+				res->end + 1 + (unsigned long)PCI_IOBASE,
+				phys_addr, pgprot_device(PAGE_KERNEL));
+#else
+	/* this architecture does not have memory mapped I/O space,
+	   so this function should never be called */
+	WARN_ON(1);
+#endif
+
+	return err;
+}
+
 static void __pci_set_master(struct pci_dev *dev, bool enable)
 {
 	u16 old_cmd, cmd;
diff --git a/include/linux/pci.h b/include/linux/pci.h
index e1e0d80..988c2f5 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1098,6 +1098,9 @@ int __must_check pci_bus_alloc_resource(struct pci_bus *bus,
 						  resource_size_t),
 			void *alignf_data);
 
+
+int pci_remap_iospace(const struct resource *res, phys_addr_t phys_addr);
+
 static inline dma_addr_t pci_bus_address(struct pci_dev *pdev, int bar)
 {
 	struct pci_bus_region region;
-- 
2.0.4

[PATCH v9 12/12] PCI: Introduce pci_remap_iospace() for remapping PCI I/O bus resources into CPU space

[Liviu Dudau]

Introduce a default implementation for remapping PCI bus I/O resources
onto the CPU address space. Architectures with special needs may
provide their own version, but most should be able to use this one.

Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Herring <robh+dt@kernel.org>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
---
 drivers/pci/pci.c   | 33 +++++++++++++++++++++++++++++++++
 include/linux/pci.h |  3 +++
 2 files changed, 36 insertions(+)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 29d1775..76d21b6 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -2707,6 +2707,39 @@ int pci_request_regions_exclusive(struct pci_dev *pdev, const char *res_name)
 }
 EXPORT_SYMBOL(pci_request_regions_exclusive);
 
+/**
+ *	pci_remap_iospace - Remap the memory mapped I/O space
+ *	@res: Resource describing the I/O space
+ *	@phys_addr: physical address where the range will be mapped.
+ *
+ *	Remap the memory mapped I/O space described by the @res
+ *	into the CPU physical address space. Only architectures
+ *	that have memory mapped IO defined (and hence PCI_IOBASE)
+ *	should call this function.
+ */
+int __weak pci_remap_iospace(const struct resource *res, phys_addr_t phys_addr)
+{
+	int err = -ENODEV;
+
+#ifdef PCI_IOBASE
+	if (!(res->flags & IORESOURCE_IO))
+		return -EINVAL;
+
+	if (res->end > IO_SPACE_LIMIT)
+		return -EINVAL;
+
+	err = ioremap_page_range(res->start + (unsigned long)PCI_IOBASE,
+				res->end + 1 + (unsigned long)PCI_IOBASE,
+				phys_addr, pgprot_device(PAGE_KERNEL));
+#else
+	/* this architecture does not have memory mapped I/O space,
+	   so this function should never be called */
+	WARN_ON(1);
+#endif
+
+	return err;
+}
+
 static void __pci_set_master(struct pci_dev *dev, bool enable)
 {
 	u16 old_cmd, cmd;
diff --git a/include/linux/pci.h b/include/linux/pci.h
index e1e0d80..988c2f5 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1098,6 +1098,9 @@ int __must_check pci_bus_alloc_resource(struct pci_bus *bus,
 						  resource_size_t),
 			void *alignf_data);
 
+
+int pci_remap_iospace(const struct resource *res, phys_addr_t phys_addr);
+
 static inline dma_addr_t pci_bus_address(struct pci_dev *pdev, int bar)
 {
 	struct pci_bus_region region;
-- 
2.0.4

Re: [PATCH v9 12/12] PCI: Introduce pci_remap_iospace() for remapping PCI I/O bus resources into CPU space

[Catalin Marinas]

On Tue, Aug 12, 2014 at 05:25:25PM +0100, Liviu Dudau wrote:
> Introduce a default implementation for remapping PCI bus I/O resources
> onto the CPU address space. Architectures with special needs may
> provide their own version, but most should be able to use this one.
> 
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Rob Herring <robh+dt@kernel.org>
> Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

I guess you could have added the generic pgprot_device definition to
this patch and the arm64 specific one in the separate arm64 PCIe support
(and one less patch in total). But not a big issue either way.

-- 
Catalin

[PATCH v9 12/12] PCI: Introduce pci_remap_iospace() for remapping PCI I/O bus resources into CPU space

[Catalin Marinas]

On Tue, Aug 12, 2014 at 05:25:25PM +0100, Liviu Dudau wrote:
> Introduce a default implementation for remapping PCI bus I/O resources
> onto the CPU address space. Architectures with special needs may
> provide their own version, but most should be able to use this one.
> 
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Rob Herring <robh+dt@kernel.org>
> Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

I guess you could have added the generic pgprot_device definition to
this patch and the arm64 specific one in the separate arm64 PCIe support
(and one less patch in total). But not a big issue either way.

-- 
Catalin

Re: [PATCH v9 12/12] PCI: Introduce pci_remap_iospace() for remapping PCI I/O bus resources into CPU space

[Liviu Dudau]

On Wed, Aug 13, 2014 at 11:01:18AM +0100, Catalin Marinas wrote:
> On Tue, Aug 12, 2014 at 05:25:25PM +0100, Liviu Dudau wrote:
> > Introduce a default implementation for remapping PCI bus I/O resources
> > onto the CPU address space. Architectures with special needs may
> > provide their own version, but most should be able to use this one.
> > 
> > Cc: Bjorn Helgaas <bhelgaas@google.com>
> > Cc: Arnd Bergmann <arnd@arndb.de>
> > Cc: Rob Herring <robh+dt@kernel.org>
> > Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
> 
> I guess you could have added the generic pgprot_device definition to
> this patch and the arm64 specific one in the separate arm64 PCIe support
> (and one less patch in total). But not a big issue either way.

I went by the established history on that file, where a new interface gets
introduced together with its use. I guess it makes backing out the change
much easier?

Best regards,
Liviu

> 
> -- 
> Catalin

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ¯\_(ツ)_/¯

[PATCH v9 12/12] PCI: Introduce pci_remap_iospace() for remapping PCI I/O bus resources into CPU space

[Liviu Dudau]

On Wed, Aug 13, 2014 at 11:01:18AM +0100, Catalin Marinas wrote:
> On Tue, Aug 12, 2014 at 05:25:25PM +0100, Liviu Dudau wrote:
> > Introduce a default implementation for remapping PCI bus I/O resources
> > onto the CPU address space. Architectures with special needs may
> > provide their own version, but most should be able to use this one.
> > 
> > Cc: Bjorn Helgaas <bhelgaas@google.com>
> > Cc: Arnd Bergmann <arnd@arndb.de>
> > Cc: Rob Herring <robh+dt@kernel.org>
> > Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
> 
> I guess you could have added the generic pgprot_device definition to
> this patch and the arm64 specific one in the separate arm64 PCIe support
> (and one less patch in total). But not a big issue either way.

I went by the established history on that file, where a new interface gets
introduced together with its use. I guess it makes backing out the change
much easier?

Best regards,
Liviu

> 
> -- 
> Catalin

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ?\_(?)_/?

Re: [PATCH v9 12/12] PCI: Introduce pci_remap_iospace() for remapping PCI I/O bus resources into CPU space

[Catalin Marinas]

On Wed, Aug 13, 2014 at 11:33:11AM +0100, Liviu Dudau wrote:
> On Wed, Aug 13, 2014 at 11:01:18AM +0100, Catalin Marinas wrote:
> > On Tue, Aug 12, 2014 at 05:25:25PM +0100, Liviu Dudau wrote:
> > > Introduce a default implementation for remapping PCI bus I/O resources
> > > onto the CPU address space. Architectures with special needs may
> > > provide their own version, but most should be able to use this one.
> > > 
> > > Cc: Bjorn Helgaas <bhelgaas@google.com>
> > > Cc: Arnd Bergmann <arnd@arndb.de>
> > > Cc: Rob Herring <robh+dt@kernel.org>
> > > Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
> > 
> > I guess you could have added the generic pgprot_device definition to
> > this patch and the arm64 specific one in the separate arm64 PCIe support
> > (and one less patch in total). But not a big issue either way.
> 
> I went by the established history on that file, where a new interface gets
> introduced together with its use. I guess it makes backing out the change
> much easier?

The point is that the only user of pgprot_device is pci_remap_iospace()
currently, so it makes sense to introduce the generic definition
together with this patch.

-- 
Catalin

[PATCH v9 12/12] PCI: Introduce pci_remap_iospace() for remapping PCI I/O bus resources into CPU space

[Catalin Marinas]

On Wed, Aug 13, 2014 at 11:33:11AM +0100, Liviu Dudau wrote:
> On Wed, Aug 13, 2014 at 11:01:18AM +0100, Catalin Marinas wrote:
> > On Tue, Aug 12, 2014 at 05:25:25PM +0100, Liviu Dudau wrote:
> > > Introduce a default implementation for remapping PCI bus I/O resources
> > > onto the CPU address space. Architectures with special needs may
> > > provide their own version, but most should be able to use this one.
> > > 
> > > Cc: Bjorn Helgaas <bhelgaas@google.com>
> > > Cc: Arnd Bergmann <arnd@arndb.de>
> > > Cc: Rob Herring <robh+dt@kernel.org>
> > > Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
> > 
> > I guess you could have added the generic pgprot_device definition to
> > this patch and the arm64 specific one in the separate arm64 PCIe support
> > (and one less patch in total). But not a big issue either way.
> 
> I went by the established history on that file, where a new interface gets
> introduced together with its use. I guess it makes backing out the change
> much easier?

The point is that the only user of pgprot_device is pci_remap_iospace()
currently, so it makes sense to introduce the generic definition
together with this patch.

-- 
Catalin

Re: [PATCH v9 12/12] PCI: Introduce pci_remap_iospace() for remapping PCI I/O bus resources into CPU space

[Rob Herring]

On Tue, Aug 12, 2014 at 11:25 AM, Liviu Dudau <Liviu.Dudau@arm.com> wrote:
> Introduce a default implementation for remapping PCI bus I/O resources
> onto the CPU address space. Architectures with special needs may
> provide their own version, but most should be able to use this one.
>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Rob Herring <robh+dt@kernel.org>
> Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

Reviewed-by: Rob Herring <robh@kernel.org>

However, I would like to see ARM pci_ioremap_io converted over to this function.

Rob

> ---
>  drivers/pci/pci.c   | 33 +++++++++++++++++++++++++++++++++
>  include/linux/pci.h |  3 +++
>  2 files changed, 36 insertions(+)
>
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index 29d1775..76d21b6 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -2707,6 +2707,39 @@ int pci_request_regions_exclusive(struct pci_dev *pdev, const char *res_name)
>  }
>  EXPORT_SYMBOL(pci_request_regions_exclusive);
>
> +/**
> + *     pci_remap_iospace - Remap the memory mapped I/O space
> + *     @res: Resource describing the I/O space
> + *     @phys_addr: physical address where the range will be mapped.
> + *
> + *     Remap the memory mapped I/O space described by the @res
> + *     into the CPU physical address space. Only architectures
> + *     that have memory mapped IO defined (and hence PCI_IOBASE)
> + *     should call this function.
> + */
> +int __weak pci_remap_iospace(const struct resource *res, phys_addr_t phys_addr)
> +{
> +       int err = -ENODEV;
> +
> +#ifdef PCI_IOBASE
> +       if (!(res->flags & IORESOURCE_IO))
> +               return -EINVAL;
> +
> +       if (res->end > IO_SPACE_LIMIT)
> +               return -EINVAL;
> +
> +       err = ioremap_page_range(res->start + (unsigned long)PCI_IOBASE,
> +                               res->end + 1 + (unsigned long)PCI_IOBASE,
> +                               phys_addr, pgprot_device(PAGE_KERNEL));
> +#else
> +       /* this architecture does not have memory mapped I/O space,
> +          so this function should never be called */
> +       WARN_ON(1);
> +#endif
> +
> +       return err;
> +}
> +
>  static void __pci_set_master(struct pci_dev *dev, bool enable)
>  {
>         u16 old_cmd, cmd;
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index e1e0d80..988c2f5 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -1098,6 +1098,9 @@ int __must_check pci_bus_alloc_resource(struct pci_bus *bus,
>                                                   resource_size_t),
>                         void *alignf_data);
>
> +
> +int pci_remap_iospace(const struct resource *res, phys_addr_t phys_addr);
> +
>  static inline dma_addr_t pci_bus_address(struct pci_dev *pdev, int bar)
>  {
>         struct pci_bus_region region;
> --
> 2.0.4
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v9 12/12] PCI: Introduce pci_remap_iospace() for remapping PCI I/O bus resources into CPU space

[Rob Herring]

On Tue, Aug 12, 2014 at 11:25 AM, Liviu Dudau <Liviu.Dudau@arm.com> wrote:
> Introduce a default implementation for remapping PCI bus I/O resources
> onto the CPU address space. Architectures with special needs may
> provide their own version, but most should be able to use this one.
>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Rob Herring <robh+dt@kernel.org>
> Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

Reviewed-by: Rob Herring <robh@kernel.org>

However, I would like to see ARM pci_ioremap_io converted over to this function.

Rob

> ---
>  drivers/pci/pci.c   | 33 +++++++++++++++++++++++++++++++++
>  include/linux/pci.h |  3 +++
>  2 files changed, 36 insertions(+)
>
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index 29d1775..76d21b6 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -2707,6 +2707,39 @@ int pci_request_regions_exclusive(struct pci_dev *pdev, const char *res_name)
>  }
>  EXPORT_SYMBOL(pci_request_regions_exclusive);
>
> +/**
> + *     pci_remap_iospace - Remap the memory mapped I/O space
> + *     @res: Resource describing the I/O space
> + *     @phys_addr: physical address where the range will be mapped.
> + *
> + *     Remap the memory mapped I/O space described by the @res
> + *     into the CPU physical address space. Only architectures
> + *     that have memory mapped IO defined (and hence PCI_IOBASE)
> + *     should call this function.
> + */
> +int __weak pci_remap_iospace(const struct resource *res, phys_addr_t phys_addr)
> +{
> +       int err = -ENODEV;
> +
> +#ifdef PCI_IOBASE
> +       if (!(res->flags & IORESOURCE_IO))
> +               return -EINVAL;
> +
> +       if (res->end > IO_SPACE_LIMIT)
> +               return -EINVAL;
> +
> +       err = ioremap_page_range(res->start + (unsigned long)PCI_IOBASE,
> +                               res->end + 1 + (unsigned long)PCI_IOBASE,
> +                               phys_addr, pgprot_device(PAGE_KERNEL));
> +#else
> +       /* this architecture does not have memory mapped I/O space,
> +          so this function should never be called */
> +       WARN_ON(1);
> +#endif
> +
> +       return err;
> +}
> +
>  static void __pci_set_master(struct pci_dev *dev, bool enable)
>  {
>         u16 old_cmd, cmd;
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index e1e0d80..988c2f5 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -1098,6 +1098,9 @@ int __must_check pci_bus_alloc_resource(struct pci_bus *bus,
>                                                   resource_size_t),
>                         void *alignf_data);
>
> +
> +int pci_remap_iospace(const struct resource *res, phys_addr_t phys_addr);
> +
>  static inline dma_addr_t pci_bus_address(struct pci_dev *pdev, int bar)
>  {
>         struct pci_bus_region region;
> --
> 2.0.4
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v9 12/12] PCI: Introduce pci_remap_iospace() for remapping PCI I/O bus resources into CPU space

[Rob Herring]

On Tue, Aug 12, 2014 at 11:25 AM, Liviu Dudau <Liviu.Dudau-5wv7dgnIgG8@public.gmane.org> wrote:
> Introduce a default implementation for remapping PCI bus I/O resources
> onto the CPU address space. Architectures with special needs may
> provide their own version, but most should be able to use this one.
>
> Cc: Bjorn Helgaas <bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
> Cc: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Signed-off-by: Liviu Dudau <Liviu.Dudau-5wv7dgnIgG8@public.gmane.org>

Reviewed-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>

However, I would like to see ARM pci_ioremap_io converted over to this function.

Rob

> ---
>  drivers/pci/pci.c   | 33 +++++++++++++++++++++++++++++++++
>  include/linux/pci.h |  3 +++
>  2 files changed, 36 insertions(+)
>
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index 29d1775..76d21b6 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -2707,6 +2707,39 @@ int pci_request_regions_exclusive(struct pci_dev *pdev, const char *res_name)
>  }
>  EXPORT_SYMBOL(pci_request_regions_exclusive);
>
> +/**
> + *     pci_remap_iospace - Remap the memory mapped I/O space
> + *     @res: Resource describing the I/O space
> + *     @phys_addr: physical address where the range will be mapped.
> + *
> + *     Remap the memory mapped I/O space described by the @res
> + *     into the CPU physical address space. Only architectures
> + *     that have memory mapped IO defined (and hence PCI_IOBASE)
> + *     should call this function.
> + */
> +int __weak pci_remap_iospace(const struct resource *res, phys_addr_t phys_addr)
> +{
> +       int err = -ENODEV;
> +
> +#ifdef PCI_IOBASE
> +       if (!(res->flags & IORESOURCE_IO))
> +               return -EINVAL;
> +
> +       if (res->end > IO_SPACE_LIMIT)
> +               return -EINVAL;
> +
> +       err = ioremap_page_range(res->start + (unsigned long)PCI_IOBASE,
> +                               res->end + 1 + (unsigned long)PCI_IOBASE,
> +                               phys_addr, pgprot_device(PAGE_KERNEL));
> +#else
> +       /* this architecture does not have memory mapped I/O space,
> +          so this function should never be called */
> +       WARN_ON(1);
> +#endif
> +
> +       return err;
> +}
> +
>  static void __pci_set_master(struct pci_dev *dev, bool enable)
>  {
>         u16 old_cmd, cmd;
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index e1e0d80..988c2f5 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -1098,6 +1098,9 @@ int __must_check pci_bus_alloc_resource(struct pci_bus *bus,
>                                                   resource_size_t),
>                         void *alignf_data);
>
> +
> +int pci_remap_iospace(const struct resource *res, phys_addr_t phys_addr);
> +
>  static inline dma_addr_t pci_bus_address(struct pci_dev *pdev, int bar)
>  {
>         struct pci_bus_region region;
> --
> 2.0.4
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 12/12] PCI: Introduce pci_remap_iospace() for remapping PCI I/O bus resources into CPU space

[Liviu Dudau]

On Thu, Aug 21, 2014 at 11:16:16PM -0500, Rob Herring wrote:
> On Tue, Aug 12, 2014 at 11:25 AM, Liviu Dudau <Liviu.Dudau@arm.com> wrote:
> > Introduce a default implementation for remapping PCI bus I/O resources
> > onto the CPU address space. Architectures with special needs may
> > provide their own version, but most should be able to use this one.
> >
> > Cc: Bjorn Helgaas <bhelgaas@google.com>
> > Cc: Arnd Bergmann <arnd@arndb.de>
> > Cc: Rob Herring <robh+dt@kernel.org>
> > Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
> 
> Reviewed-by: Rob Herring <robh@kernel.org>

Thanks, Rob, much appreciated!

> 
> However, I would like to see ARM pci_ioremap_io converted over to this function.

Do you care if this is done as a separate patch?

Best regards,
Liviu

> 
> Rob
> 
> > ---
> >  drivers/pci/pci.c   | 33 +++++++++++++++++++++++++++++++++
> >  include/linux/pci.h |  3 +++
> >  2 files changed, 36 insertions(+)
> >
> > diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> > index 29d1775..76d21b6 100644
> > --- a/drivers/pci/pci.c
> > +++ b/drivers/pci/pci.c
> > @@ -2707,6 +2707,39 @@ int pci_request_regions_exclusive(struct pci_dev *pdev, const char *res_name)
> >  }
> >  EXPORT_SYMBOL(pci_request_regions_exclusive);
> >
> > +/**
> > + *     pci_remap_iospace - Remap the memory mapped I/O space
> > + *     @res: Resource describing the I/O space
> > + *     @phys_addr: physical address where the range will be mapped.
> > + *
> > + *     Remap the memory mapped I/O space described by the @res
> > + *     into the CPU physical address space. Only architectures
> > + *     that have memory mapped IO defined (and hence PCI_IOBASE)
> > + *     should call this function.
> > + */
> > +int __weak pci_remap_iospace(const struct resource *res, phys_addr_t phys_addr)
> > +{
> > +       int err = -ENODEV;
> > +
> > +#ifdef PCI_IOBASE
> > +       if (!(res->flags & IORESOURCE_IO))
> > +               return -EINVAL;
> > +
> > +       if (res->end > IO_SPACE_LIMIT)
> > +               return -EINVAL;
> > +
> > +       err = ioremap_page_range(res->start + (unsigned long)PCI_IOBASE,
> > +                               res->end + 1 + (unsigned long)PCI_IOBASE,
> > +                               phys_addr, pgprot_device(PAGE_KERNEL));
> > +#else
> > +       /* this architecture does not have memory mapped I/O space,
> > +          so this function should never be called */
> > +       WARN_ON(1);
> > +#endif
> > +
> > +       return err;
> > +}
> > +
> >  static void __pci_set_master(struct pci_dev *dev, bool enable)
> >  {
> >         u16 old_cmd, cmd;
> > diff --git a/include/linux/pci.h b/include/linux/pci.h
> > index e1e0d80..988c2f5 100644
> > --- a/include/linux/pci.h
> > +++ b/include/linux/pci.h
> > @@ -1098,6 +1098,9 @@ int __must_check pci_bus_alloc_resource(struct pci_bus *bus,
> >                                                   resource_size_t),
> >                         void *alignf_data);
> >
> > +
> > +int pci_remap_iospace(const struct resource *res, phys_addr_t phys_addr);
> > +
> >  static inline dma_addr_t pci_bus_address(struct pci_dev *pdev, int bar)
> >  {
> >         struct pci_bus_region region;
> > --
> > 2.0.4
> >
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
-------------------
   .oooO
   (   )
    \ (  Oooo.
     \_) (   )
          ) /
         (_/

 One small step
   for me ...

[PATCH v9 12/12] PCI: Introduce pci_remap_iospace() for remapping PCI I/O bus resources into CPU space

[Liviu Dudau]

On Thu, Aug 21, 2014 at 11:16:16PM -0500, Rob Herring wrote:
> On Tue, Aug 12, 2014 at 11:25 AM, Liviu Dudau <Liviu.Dudau@arm.com> wrote:
> > Introduce a default implementation for remapping PCI bus I/O resources
> > onto the CPU address space. Architectures with special needs may
> > provide their own version, but most should be able to use this one.
> >
> > Cc: Bjorn Helgaas <bhelgaas@google.com>
> > Cc: Arnd Bergmann <arnd@arndb.de>
> > Cc: Rob Herring <robh+dt@kernel.org>
> > Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
> 
> Reviewed-by: Rob Herring <robh@kernel.org>

Thanks, Rob, much appreciated!

> 
> However, I would like to see ARM pci_ioremap_io converted over to this function.

Do you care if this is done as a separate patch?

Best regards,
Liviu

> 
> Rob
> 
> > ---
> >  drivers/pci/pci.c   | 33 +++++++++++++++++++++++++++++++++
> >  include/linux/pci.h |  3 +++
> >  2 files changed, 36 insertions(+)
> >
> > diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> > index 29d1775..76d21b6 100644
> > --- a/drivers/pci/pci.c
> > +++ b/drivers/pci/pci.c
> > @@ -2707,6 +2707,39 @@ int pci_request_regions_exclusive(struct pci_dev *pdev, const char *res_name)
> >  }
> >  EXPORT_SYMBOL(pci_request_regions_exclusive);
> >
> > +/**
> > + *     pci_remap_iospace - Remap the memory mapped I/O space
> > + *     @res: Resource describing the I/O space
> > + *     @phys_addr: physical address where the range will be mapped.
> > + *
> > + *     Remap the memory mapped I/O space described by the @res
> > + *     into the CPU physical address space. Only architectures
> > + *     that have memory mapped IO defined (and hence PCI_IOBASE)
> > + *     should call this function.
> > + */
> > +int __weak pci_remap_iospace(const struct resource *res, phys_addr_t phys_addr)
> > +{
> > +       int err = -ENODEV;
> > +
> > +#ifdef PCI_IOBASE
> > +       if (!(res->flags & IORESOURCE_IO))
> > +               return -EINVAL;
> > +
> > +       if (res->end > IO_SPACE_LIMIT)
> > +               return -EINVAL;
> > +
> > +       err = ioremap_page_range(res->start + (unsigned long)PCI_IOBASE,
> > +                               res->end + 1 + (unsigned long)PCI_IOBASE,
> > +                               phys_addr, pgprot_device(PAGE_KERNEL));
> > +#else
> > +       /* this architecture does not have memory mapped I/O space,
> > +          so this function should never be called */
> > +       WARN_ON(1);
> > +#endif
> > +
> > +       return err;
> > +}
> > +
> >  static void __pci_set_master(struct pci_dev *dev, bool enable)
> >  {
> >         u16 old_cmd, cmd;
> > diff --git a/include/linux/pci.h b/include/linux/pci.h
> > index e1e0d80..988c2f5 100644
> > --- a/include/linux/pci.h
> > +++ b/include/linux/pci.h
> > @@ -1098,6 +1098,9 @@ int __must_check pci_bus_alloc_resource(struct pci_bus *bus,
> >                                                   resource_size_t),
> >                         void *alignf_data);
> >
> > +
> > +int pci_remap_iospace(const struct resource *res, phys_addr_t phys_addr);
> > +
> >  static inline dma_addr_t pci_bus_address(struct pci_dev *pdev, int bar)
> >  {
> >         struct pci_bus_region region;
> > --
> > 2.0.4
> >
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
-------------------
   .oooO
   (   )
    \ (  Oooo.
     \_) (   )
          ) /
         (_/

 One small step
   for me ...

Re: [PATCH v9 12/12] PCI: Introduce pci_remap_iospace() for remapping PCI I/O bus resources into CPU space

[Rob Herring]

On Fri, Aug 22, 2014 at 7:43 AM, Liviu Dudau <liviu@dudau.co.uk> wrote:
> On Thu, Aug 21, 2014 at 11:16:16PM -0500, Rob Herring wrote:
>> On Tue, Aug 12, 2014 at 11:25 AM, Liviu Dudau <Liviu.Dudau@arm.com> wrote:
>> > Introduce a default implementation for remapping PCI bus I/O resources
>> > onto the CPU address space. Architectures with special needs may
>> > provide their own version, but most should be able to use this one.
>> >
>> > Cc: Bjorn Helgaas <bhelgaas@google.com>
>> > Cc: Arnd Bergmann <arnd@arndb.de>
>> > Cc: Rob Herring <robh+dt@kernel.org>
>> > Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
>>
>> Reviewed-by: Rob Herring <robh@kernel.org>
>
> Thanks, Rob, much appreciated!
>
>>
>> However, I would like to see ARM pci_ioremap_io converted over to this function.
>
> Do you care if this is done as a separate patch?

Yes, that's fine hence the reviewed-by.

Rob

[PATCH v9 12/12] PCI: Introduce pci_remap_iospace() for remapping PCI I/O bus resources into CPU space

[Rob Herring]

On Fri, Aug 22, 2014 at 7:43 AM, Liviu Dudau <liviu@dudau.co.uk> wrote:
> On Thu, Aug 21, 2014 at 11:16:16PM -0500, Rob Herring wrote:
>> On Tue, Aug 12, 2014 at 11:25 AM, Liviu Dudau <Liviu.Dudau@arm.com> wrote:
>> > Introduce a default implementation for remapping PCI bus I/O resources
>> > onto the CPU address space. Architectures with special needs may
>> > provide their own version, but most should be able to use this one.
>> >
>> > Cc: Bjorn Helgaas <bhelgaas@google.com>
>> > Cc: Arnd Bergmann <arnd@arndb.de>
>> > Cc: Rob Herring <robh+dt@kernel.org>
>> > Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
>>
>> Reviewed-by: Rob Herring <robh@kernel.org>
>
> Thanks, Rob, much appreciated!
>
>>
>> However, I would like to see ARM pci_ioremap_io converted over to this function.
>
> Do you care if this is done as a separate patch?

Yes, that's fine hence the reviewed-by.

Rob

Re: [PATCH v9 12/12] PCI: Introduce pci_remap_iospace() for remapping PCI I/O bus resources into CPU space

[Rob Herring]

On Fri, Aug 22, 2014 at 7:43 AM, Liviu Dudau <liviu-I3yL/QOVVjH10XsdtD+oqA@public.gmane.org> wrote:
> On Thu, Aug 21, 2014 at 11:16:16PM -0500, Rob Herring wrote:
>> On Tue, Aug 12, 2014 at 11:25 AM, Liviu Dudau <Liviu.Dudau-5wv7dgnIgG8@public.gmane.org> wrote:
>> > Introduce a default implementation for remapping PCI bus I/O resources
>> > onto the CPU address space. Architectures with special needs may
>> > provide their own version, but most should be able to use this one.
>> >
>> > Cc: Bjorn Helgaas <bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
>> > Cc: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
>> > Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>> > Signed-off-by: Liviu Dudau <Liviu.Dudau-5wv7dgnIgG8@public.gmane.org>
>>
>> Reviewed-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>
> Thanks, Rob, much appreciated!
>
>>
>> However, I would like to see ARM pci_ioremap_io converted over to this function.
>
> Do you care if this is done as a separate patch?

Yes, that's fine hence the reviewed-by.

Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 00/12] Support for creating generic PCI host bridges from DT

[Catalin Marinas]

On Tue, Aug 12, 2014 at 05:25:13PM +0100, Liviu Dudau wrote:
> This is my updated attempt at adding support for generic PCI host
> bridge controllers that make use of device tree information to
> configure themselves. This version incorporates Catalin's proposal
> for managing domain numbers that got Bjorn's approval. I am now requesting
> ACKs from the relevant maintainers as I would like to get the upstream ball
> rolling.

As this series kept me busy on a long flight, you can add:

Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>

[PATCH v9 00/12] Support for creating generic PCI host bridges from DT

[Catalin Marinas]

On Tue, Aug 12, 2014 at 05:25:13PM +0100, Liviu Dudau wrote:
> This is my updated attempt at adding support for generic PCI host
> bridge controllers that make use of device tree information to
> configure themselves. This version incorporates Catalin's proposal
> for managing domain numbers that got Bjorn's approval. I am now requesting
> ACKs from the relevant maintainers as I would like to get the upstream ball
> rolling.

As this series kept me busy on a long flight, you can add:

Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>

Re: [PATCH v9 00/12] Support for creating generic PCI host bridges from DT

[Liviu Dudau]

On Mon, Aug 18, 2014 at 03:26:22PM +0100, Catalin Marinas wrote:
> On Tue, Aug 12, 2014 at 05:25:13PM +0100, Liviu Dudau wrote:
> > This is my updated attempt at adding support for generic PCI host
> > bridge controllers that make use of device tree information to
> > configure themselves. This version incorporates Catalin's proposal
> > for managing domain numbers that got Bjorn's approval. I am now requesting
> > ACKs from the relevant maintainers as I would like to get the upstream ball
> > rolling.
> 
> As this series kept me busy on a long flight, you can add:

Damn, I don't know wether I should be proud or scared.

> 
> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>

Thanks! :)

Liviu

> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
-------------------
   .oooO
   (   )
    \ (  Oooo.
     \_) (   )
          ) /
         (_/

 One small step
   for me ...

[PATCH v9 00/12] Support for creating generic PCI host bridges from DT

[Liviu Dudau]

On Mon, Aug 18, 2014 at 03:26:22PM +0100, Catalin Marinas wrote:
> On Tue, Aug 12, 2014 at 05:25:13PM +0100, Liviu Dudau wrote:
> > This is my updated attempt at adding support for generic PCI host
> > bridge controllers that make use of device tree information to
> > configure themselves. This version incorporates Catalin's proposal
> > for managing domain numbers that got Bjorn's approval. I am now requesting
> > ACKs from the relevant maintainers as I would like to get the upstream ball
> > rolling.
> 
> As this series kept me busy on a long flight, you can add:

Damn, I don't know wether I should be proud or scared.

> 
> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>

Thanks! :)

Liviu

> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
-------------------
   .oooO
   (   )
    \ (  Oooo.
     \_) (   )
          ) /
         (_/

 One small step
   for me ...

Re: [PATCH v9 00/12] Support for creating generic PCI host bridges from DT

[Robert Richter]

Liviu,

On 12.08.14 17:25:13, Liviu Dudau wrote:
> This is my updated attempt at adding support for generic PCI host
> bridge controllers that make use of device tree information to
> configure themselves. This version incorporates Catalin's proposal
> for managing domain numbers that got Bjorn's approval. I am now requesting
> ACKs from the relevant maintainers as I would like to get the upstream ball
> rolling.
>
> Of the more important changes vs v8, this version has an altered implementation
> of of_create_pci_host_bridge() that allows for easier conversion of architectures
> that use pci_scan_root_bus() in their code rather than pci_create_root_bus().
> With my v8 version of the patchset it would've meant adding back the code
> from pci_scan_root_bus() into architectural code. v9 fixes that and adds
> a callback parameter to of_create_pci_host_bridge() that permits the host
> controller driver to finish the driver setup before the bus is being scanned.
>
> To repeat for the benefit of people writing host bridge drivers on top of
> my patchset: the API for of_create_pci_host_bridge() has changed and it will now
> do all the child bus and device scanning for you, so you only need to provide a
> setup function that will be called before scanning start. I will post a patch
> that Lorenzo has kindly constructed for converting pci-host-generic.c to my API.

would it be possible to provide a branch with this patch set in your
git repo as for v8?

This would make rebasing and testing of our Cavium Thunder code base
much easier. We could then also refer to a public repo where our
patches base on.

Thanks,

-Robert

[PATCH v9 00/12] Support for creating generic PCI host bridges from DT

[Robert Richter]

Liviu,

On 12.08.14 17:25:13, Liviu Dudau wrote:
> This is my updated attempt at adding support for generic PCI host
> bridge controllers that make use of device tree information to
> configure themselves. This version incorporates Catalin's proposal
> for managing domain numbers that got Bjorn's approval. I am now requesting
> ACKs from the relevant maintainers as I would like to get the upstream ball
> rolling.
>
> Of the more important changes vs v8, this version has an altered implementation
> of of_create_pci_host_bridge() that allows for easier conversion of architectures
> that use pci_scan_root_bus() in their code rather than pci_create_root_bus().
> With my v8 version of the patchset it would've meant adding back the code
> from pci_scan_root_bus() into architectural code. v9 fixes that and adds
> a callback parameter to of_create_pci_host_bridge() that permits the host
> controller driver to finish the driver setup before the bus is being scanned.
>
> To repeat for the benefit of people writing host bridge drivers on top of
> my patchset: the API for of_create_pci_host_bridge() has changed and it will now
> do all the child bus and device scanning for you, so you only need to provide a
> setup function that will be called before scanning start. I will post a patch
> that Lorenzo has kindly constructed for converting pci-host-generic.c to my API.

would it be possible to provide a branch with this patch set in your
git repo as for v8?

This would make rebasing and testing of our Cavium Thunder code base
much easier. We could then also refer to a public repo where our
patches base on.

Thanks,

-Robert

Re: [PATCH v9 00/12] Support for creating generic PCI host bridges from DT

[Robert Richter]

Liviu,

On 12.08.14 17:25:13, Liviu Dudau wrote:
> This is my updated attempt at adding support for generic PCI host
> bridge controllers that make use of device tree information to
> configure themselves. This version incorporates Catalin's proposal
> for managing domain numbers that got Bjorn's approval. I am now requesting
> ACKs from the relevant maintainers as I would like to get the upstream ball
> rolling.
>
> Of the more important changes vs v8, this version has an altered implementation
> of of_create_pci_host_bridge() that allows for easier conversion of architectures
> that use pci_scan_root_bus() in their code rather than pci_create_root_bus().
> With my v8 version of the patchset it would've meant adding back the code
> from pci_scan_root_bus() into architectural code. v9 fixes that and adds
> a callback parameter to of_create_pci_host_bridge() that permits the host
> controller driver to finish the driver setup before the bus is being scanned.
>
> To repeat for the benefit of people writing host bridge drivers on top of
> my patchset: the API for of_create_pci_host_bridge() has changed and it will now
> do all the child bus and device scanning for you, so you only need to provide a
> setup function that will be called before scanning start. I will post a patch
> that Lorenzo has kindly constructed for converting pci-host-generic.c to my API.

would it be possible to provide a branch with this patch set in your
git repo as for v8?

This would make rebasing and testing of our Cavium Thunder code base
much easier. We could then also refer to a public repo where our
patches base on.

Thanks,

-Robert
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html