Re: [PATCH v1 00/25] PCI: Request host bridge window resources

[Duc Dang]

On Mon, Jun 6, 2016 at 4:04 PM, Bjorn Helgaas  wrote:
> Several host bridge drivers (designware and all derivatives, iproc,
> xgene, xilinx, and xilinx-nwl) don't request the MMIO and I/O port
> windows they forward downstream to the PCI bus.
>
> That means the PCI core can't request resources for PCI bridge
> windows and PCI BARs.
>
> Several other drivers (altera, generic, mvebu, rcar, tegra) do request
> the windows, but use some duplicated code to do it.
>
> This adds a new devm_request_pci_bus_resources() interface and changes
> these drivers to use it.  It also fixes several error paths where we failed
> to free the resource list allocated by of_pci_get_host_bridge_resources().
>
> Tegra guys, please take a look at "PCI: tegra: Remove top-level resource
> from hierarchy" in particular.  Removing the top-level resource definitely
> makes /proc/iomem look uglier (although it will look more like that of
> other drivers).  A short-term fix could be to include device information in
> the resource name.  I think a better long-term fix would be to make the DT
> or platform device core request all the resources from the DT.
>
> Comments welcome.  I expect we'll trip over something here, so I marked
> this "v1" and I don't plan to put it into -next for a while.
>
> This is on my pci/host-request-windows branch, which you can pull or view
> at 
> https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/log/?h=pci/host-request-windows
>
> ---
>
> Bjorn Helgaas (25):
>   PCI: Add devm_request_pci_bus_resources()
>   PCI: designware: Free bridge resource list on failure
>   PCI: designware: Request host bridge window resources
>   PCI: designware: Simplify host bridge window iteration
>   PCI: iproc: Request host bridge window resources
>   PCI: xgene: Free bridge resource list on failure
>   PCI: xgene: Request host bridge window resources
>   PCI: xilinx: Free bridge resource list on failure
>   PCI: xilinx: Request host bridge window resources
>   PCI: xilinx-nwl: Free bridge resource list on failure
>   PCI: xilinx-nwl: Request host bridge window resources
>   PCI: xilinx-nwl: Use dev_printk() when possible
>   PCI: altera: Request host bridge window resources with core function
>   PCI: altera: Simplify host bridge window iteration
>   PCI: generic: Free resource list close to where it's allocated
>   PCI: generic: Request host bridge window resources with core function
>   PCI: generic: Simplify host bridge window iteration
>   PCI: mvebu: Request host bridge window resources with core function
>   PCI: rcar Gen2: Request host bridge window resources
>   PCI: rcar: Request host bridge window resources with core function
>   PCI: rcar: Simplify host bridge window iteration
>   PCI: tegra: Remove top-level resource from hierarchy
>   PCI: tegra: Request host bridge window resources with core function
>   PCI: versatile: Request host bridge window resources with core function
>   PCI: versatile: Simplify host bridge window iteration

Thanks, Bjorn.

For the 2 X-Gene patches:
 PCI: xgene: Free bridge resource list on failure
 PCI: xgene: Request host bridge window resources

Tested-by: Duc Dang 

Regards,
Duc Dang.
>
>
>  drivers/pci/bus.c  |   29 +
>  drivers/pci/host/pci-host-common.c |   61 
> +++-
>  drivers/pci/host/pci-mvebu.c   |   17 --
>  drivers/pci/host/pci-rcar-gen2.c   |4 ++
>  drivers/pci/host/pci-tegra.c   |   35 +++--
>  drivers/pci/host/pci-versatile.c   |   29 ++---
>  drivers/pci/host/pci-xgene.c   |   16 -
>  drivers/pci/host/pcie-altera.c |   35 ++---
>  drivers/pci/host/pcie-designware.c |   34 +---
>  drivers/pci/host/pcie-iproc.c  |4 ++
>  drivers/pci/host/pcie-rcar.c   |   33 +--
>  drivers/pci/host/pcie-xilinx-nwl.c |   20 +---
>  drivers/pci/host/pcie-xilinx.c |   16 -
>  include/linux/pci.h|5 ++-
>  14 files changed, 170 insertions(+), 168 deletions(-)
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v1 00/25] PCI: Request host bridge window resources

[Duc Dang]

On Mon, Jun 6, 2016 at 4:04 PM, Bjorn Helgaas  wrote:
> Several host bridge drivers (designware and all derivatives, iproc,
> xgene, xilinx, and xilinx-nwl) don't request the MMIO and I/O port
> windows they forward downstream to the PCI bus.
>
> That means the PCI core can't request resources for PCI bridge
> windows and PCI BARs.
>
> Several other drivers (altera, generic, mvebu, rcar, tegra) do request
> the windows, but use some duplicated code to do it.
>
> This adds a new devm_request_pci_bus_resources() interface and changes
> these drivers to use it.  It also fixes several error paths where we failed
> to free the resource list allocated by of_pci_get_host_bridge_resources().
>
> Tegra guys, please take a look at "PCI: tegra: Remove top-level resource
> from hierarchy" in particular.  Removing the top-level resource definitely
> makes /proc/iomem look uglier (although it will look more like that of
> other drivers).  A short-term fix could be to include device information in
> the resource name.  I think a better long-term fix would be to make the DT
> or platform device core request all the resources from the DT.
>
> Comments welcome.  I expect we'll trip over something here, so I marked
> this "v1" and I don't plan to put it into -next for a while.
>
> This is on my pci/host-request-windows branch, which you can pull or view
> at 
> https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/log/?h=pci/host-request-windows
>
> ---
>
> Bjorn Helgaas (25):
>   PCI: Add devm_request_pci_bus_resources()
>   PCI: designware: Free bridge resource list on failure
>   PCI: designware: Request host bridge window resources
>   PCI: designware: Simplify host bridge window iteration
>   PCI: iproc: Request host bridge window resources
>   PCI: xgene: Free bridge resource list on failure
>   PCI: xgene: Request host bridge window resources
>   PCI: xilinx: Free bridge resource list on failure
>   PCI: xilinx: Request host bridge window resources
>   PCI: xilinx-nwl: Free bridge resource list on failure
>   PCI: xilinx-nwl: Request host bridge window resources
>   PCI: xilinx-nwl: Use dev_printk() when possible
>   PCI: altera: Request host bridge window resources with core function
>   PCI: altera: Simplify host bridge window iteration
>   PCI: generic: Free resource list close to where it's allocated
>   PCI: generic: Request host bridge window resources with core function
>   PCI: generic: Simplify host bridge window iteration
>   PCI: mvebu: Request host bridge window resources with core function
>   PCI: rcar Gen2: Request host bridge window resources
>   PCI: rcar: Request host bridge window resources with core function
>   PCI: rcar: Simplify host bridge window iteration
>   PCI: tegra: Remove top-level resource from hierarchy
>   PCI: tegra: Request host bridge window resources with core function
>   PCI: versatile: Request host bridge window resources with core function
>   PCI: versatile: Simplify host bridge window iteration

Thanks, Bjorn.

For the 2 X-Gene patches:
 PCI: xgene: Free bridge resource list on failure
 PCI: xgene: Request host bridge window resources

Tested-by: Duc Dang 

Regards,
Duc Dang.
>
>
>  drivers/pci/bus.c  |   29 +
>  drivers/pci/host/pci-host-common.c |   61 
> +++-
>  drivers/pci/host/pci-mvebu.c   |   17 --
>  drivers/pci/host/pci-rcar-gen2.c   |4 ++
>  drivers/pci/host/pci-tegra.c   |   35 +++--
>  drivers/pci/host/pci-versatile.c   |   29 ++---
>  drivers/pci/host/pci-xgene.c   |   16 -
>  drivers/pci/host/pcie-altera.c |   35 ++---
>  drivers/pci/host/pcie-designware.c |   34 +---
>  drivers/pci/host/pcie-iproc.c  |4 ++
>  drivers/pci/host/pcie-rcar.c   |   33 +--
>  drivers/pci/host/pcie-xilinx-nwl.c |   20 +---
>  drivers/pci/host/pcie-xilinx.c |   16 -
>  include/linux/pci.h|5 ++-
>  14 files changed, 170 insertions(+), 168 deletions(-)
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v1 00/25] PCI: Request host bridge window resources

[wangyijing]

在 2016/6/21 23:03, Bjorn Helgaas 写道:
> On Tue, Jun 21, 2016 at 07:58:08PM +0800, wangyijing wrote:
>> Hi Bjorn, use devm_request_resource() for host bridge resource is cool,
>> what about do the similar change for x86, now we request host bridge resource
>> in pci_acpi_root_add_resources() in x86, and we would release the host bridge
>> resource when host bridge device refcount reach 0. This logic may introduce 
>> issue,
>> E.g.
>> If we try to remove a pci host bridge, but there is a child pci device which 
>> refcount
>> cannot decrease to 0 after remove the device, in this case, its parent 
>> pci_bus and
>> parent device, all their refcount cannot reach to 0, the result is pci host 
>> bridge
>> refcount can not reach 0, so its .release_fn() won't be called, and host 
>> bridge
>> resouces can not release. If we want to add the pci host bridge again, all 
>> pci devices
>> can not work because the resource is conflict with the old.
>>
>> devm resource would be released when the driver detach, this is better than 
>> what we do now, I think.
> 
> I'm not going to convert pci_root.c to use devm right now.  That might
> be a good thing, but this current series is mostly trivial.  I think
> changing pci_root.c would not be trivial, so that looks like a project
> all by itself.

OK.

> 
> I don't quite follow the example of removing a host bridge while a
> child PCI device refcount is non-zero.  That sounds like an invalid
> scenario regardless of whether the resources are released by a
> .release_fn() or by devm.

I would send a draft patch to describe and fix the issue, because it's not 
related to
this series, so let's discuess it in another thread. :)

Thanks!
Yijing.


> 
> Bjorn
> 
> .
> 

Re: [PATCH v1 00/25] PCI: Request host bridge window resources

[wangyijing]

在 2016/6/21 23:03, Bjorn Helgaas 写道:
> On Tue, Jun 21, 2016 at 07:58:08PM +0800, wangyijing wrote:
>> Hi Bjorn, use devm_request_resource() for host bridge resource is cool,
>> what about do the similar change for x86, now we request host bridge resource
>> in pci_acpi_root_add_resources() in x86, and we would release the host bridge
>> resource when host bridge device refcount reach 0. This logic may introduce 
>> issue,
>> E.g.
>> If we try to remove a pci host bridge, but there is a child pci device which 
>> refcount
>> cannot decrease to 0 after remove the device, in this case, its parent 
>> pci_bus and
>> parent device, all their refcount cannot reach to 0, the result is pci host 
>> bridge
>> refcount can not reach 0, so its .release_fn() won't be called, and host 
>> bridge
>> resouces can not release. If we want to add the pci host bridge again, all 
>> pci devices
>> can not work because the resource is conflict with the old.
>>
>> devm resource would be released when the driver detach, this is better than 
>> what we do now, I think.
> 
> I'm not going to convert pci_root.c to use devm right now.  That might
> be a good thing, but this current series is mostly trivial.  I think
> changing pci_root.c would not be trivial, so that looks like a project
> all by itself.

OK.

> 
> I don't quite follow the example of removing a host bridge while a
> child PCI device refcount is non-zero.  That sounds like an invalid
> scenario regardless of whether the resources are released by a
> .release_fn() or by devm.

I would send a draft patch to describe and fix the issue, because it's not 
related to
this series, so let's discuess it in another thread. :)

Thanks!
Yijing.


> 
> Bjorn
> 
> .
> 

Re: [PATCH v1 00/25] PCI: Request host bridge window resources

[Bjorn Helgaas]

On Tue, Jun 21, 2016 at 07:58:08PM +0800, wangyijing wrote:
> Hi Bjorn, use devm_request_resource() for host bridge resource is cool,
> what about do the similar change for x86, now we request host bridge resource
> in pci_acpi_root_add_resources() in x86, and we would release the host bridge
> resource when host bridge device refcount reach 0. This logic may introduce 
> issue,
> E.g.
> If we try to remove a pci host bridge, but there is a child pci device which 
> refcount
> cannot decrease to 0 after remove the device, in this case, its parent 
> pci_bus and
> parent device, all their refcount cannot reach to 0, the result is pci host 
> bridge
> refcount can not reach 0, so its .release_fn() won't be called, and host 
> bridge
> resouces can not release. If we want to add the pci host bridge again, all 
> pci devices
> can not work because the resource is conflict with the old.
> 
> devm resource would be released when the driver detach, this is better than 
> what we do now, I think.

I'm not going to convert pci_root.c to use devm right now.  That might
be a good thing, but this current series is mostly trivial.  I think
changing pci_root.c would not be trivial, so that looks like a project
all by itself.

I don't quite follow the example of removing a host bridge while a
child PCI device refcount is non-zero.  That sounds like an invalid
scenario regardless of whether the resources are released by a
.release_fn() or by devm.

Bjorn

Re: [PATCH v1 00/25] PCI: Request host bridge window resources

[Bjorn Helgaas]

On Tue, Jun 21, 2016 at 07:58:08PM +0800, wangyijing wrote:
> Hi Bjorn, use devm_request_resource() for host bridge resource is cool,
> what about do the similar change for x86, now we request host bridge resource
> in pci_acpi_root_add_resources() in x86, and we would release the host bridge
> resource when host bridge device refcount reach 0. This logic may introduce 
> issue,
> E.g.
> If we try to remove a pci host bridge, but there is a child pci device which 
> refcount
> cannot decrease to 0 after remove the device, in this case, its parent 
> pci_bus and
> parent device, all their refcount cannot reach to 0, the result is pci host 
> bridge
> refcount can not reach 0, so its .release_fn() won't be called, and host 
> bridge
> resouces can not release. If we want to add the pci host bridge again, all 
> pci devices
> can not work because the resource is conflict with the old.
> 
> devm resource would be released when the driver detach, this is better than 
> what we do now, I think.

I'm not going to convert pci_root.c to use devm right now.  That might
be a good thing, but this current series is mostly trivial.  I think
changing pci_root.c would not be trivial, so that looks like a project
all by itself.

I don't quite follow the example of removing a host bridge while a
child PCI device refcount is non-zero.  That sounds like an invalid
scenario regardless of whether the resources are released by a
.release_fn() or by devm.

Bjorn

Re: [PATCH v1 00/25] PCI: Request host bridge window resources

[wangyijing]

Hi Bjorn, use devm_request_resource() for host bridge resource is cool,
what about do the similar change for x86, now we request host bridge resource
in pci_acpi_root_add_resources() in x86, and we would release the host bridge
resource when host bridge device refcount reach 0. This logic may introduce 
issue,
E.g.
If we try to remove a pci host bridge, but there is a child pci device which 
refcount
cannot decrease to 0 after remove the device, in this case, its parent pci_bus 
and
parent device, all their refcount cannot reach to 0, the result is pci host 
bridge
refcount can not reach 0, so its .release_fn() won't be called, and host bridge
resouces can not release. If we want to add the pci host bridge again, all pci 
devices
can not work because the resource is conflict with the old.

devm resource would be released when the driver detach, this is better than 
what we do now, I think.

Thanks!
Yijing.

在 2016/6/19 2:07, Bjorn Helgaas 写道:
> On Mon, Jun 06, 2016 at 06:04:44PM -0500, Bjorn Helgaas wrote:
>> Several host bridge drivers (designware and all derivatives, iproc,
>> xgene, xilinx, and xilinx-nwl) don't request the MMIO and I/O port
>> windows they forward downstream to the PCI bus.
>>
>> That means the PCI core can't request resources for PCI bridge
>> windows and PCI BARs.
>>
>> Several other drivers (altera, generic, mvebu, rcar, tegra) do request
>> the windows, but use some duplicated code to do it.
>>
>> This adds a new devm_request_pci_bus_resources() interface and changes
>> these drivers to use it.  It also fixes several error paths where we failed
>> to free the resource list allocated by of_pci_get_host_bridge_resources().
>>
>> Tegra guys, please take a look at "PCI: tegra: Remove top-level resource
>> from hierarchy" in particular.  Removing the top-level resource definitely
>> makes /proc/iomem look uglier (although it will look more like that of
>> other drivers).  A short-term fix could be to include device information in
>> the resource name.  I think a better long-term fix would be to make the DT
>> or platform device core request all the resources from the DT.
>>
>> Comments welcome.  I expect we'll trip over something here, so I marked
>> this "v1" and I don't plan to put it into -next for a while.
>>
>> This is on my pci/host-request-windows branch, which you can pull or view
>> at 
>> https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/log/?h=pci/host-request-windows
> 
> I merged this to my -next branch, so it should show up in linux-next
> in a couple days.  Let me know if you see any problems.
> 
>> Bjorn Helgaas (25):
>>   PCI: Add devm_request_pci_bus_resources()
>>   PCI: designware: Free bridge resource list on failure
>>   PCI: designware: Request host bridge window resources
>>   PCI: designware: Simplify host bridge window iteration
>>   PCI: iproc: Request host bridge window resources
>>   PCI: xgene: Free bridge resource list on failure
>>   PCI: xgene: Request host bridge window resources
>>   PCI: xilinx: Free bridge resource list on failure
>>   PCI: xilinx: Request host bridge window resources
>>   PCI: xilinx-nwl: Free bridge resource list on failure
>>   PCI: xilinx-nwl: Request host bridge window resources
>>   PCI: xilinx-nwl: Use dev_printk() when possible
>>   PCI: altera: Request host bridge window resources with core function
>>   PCI: altera: Simplify host bridge window iteration
>>   PCI: generic: Free resource list close to where it's allocated
>>   PCI: generic: Request host bridge window resources with core function
>>   PCI: generic: Simplify host bridge window iteration
>>   PCI: mvebu: Request host bridge window resources with core function
>>   PCI: rcar Gen2: Request host bridge window resources
>>   PCI: rcar: Request host bridge window resources with core function
>>   PCI: rcar: Simplify host bridge window iteration
>>   PCI: tegra: Remove top-level resource from hierarchy
>>   PCI: tegra: Request host bridge window resources with core function
>>   PCI: versatile: Request host bridge window resources with core function
>>   PCI: versatile: Simplify host bridge window iteration
>>
>>
>>  drivers/pci/bus.c  |   29 +
>>  drivers/pci/host/pci-host-common.c |   61 
>> +++-
>>  drivers/pci/host/pci-mvebu.c   |   17 --
>>  drivers/pci/host/pci-rcar-gen2.c   |4 ++
>>  drivers/pci/host/pci-tegra.c   |   35 +++--
>>  drivers/pci/host/pci-versatile.c   |   29 ++---
>>  drivers/pci/host/pci-xgene.c   |   16 -
>>  drivers/pci/host/pcie-altera.c |   35 ++---
>>  drivers/pci/host/pcie-designware.c |   34 +---
>>  drivers/pci/host/pcie-iproc.c  |4 ++
>>  drivers/pci/host/pcie-rcar.c   |   33 +--
>>  drivers/pci/host/pcie-xilinx-nwl.c |   20 +---
>>  

Re: [PATCH v1 00/25] PCI: Request host bridge window resources

[wangyijing]

Hi Bjorn, use devm_request_resource() for host bridge resource is cool,
what about do the similar change for x86, now we request host bridge resource
in pci_acpi_root_add_resources() in x86, and we would release the host bridge
resource when host bridge device refcount reach 0. This logic may introduce 
issue,
E.g.
If we try to remove a pci host bridge, but there is a child pci device which 
refcount
cannot decrease to 0 after remove the device, in this case, its parent pci_bus 
and
parent device, all their refcount cannot reach to 0, the result is pci host 
bridge
refcount can not reach 0, so its .release_fn() won't be called, and host bridge
resouces can not release. If we want to add the pci host bridge again, all pci 
devices
can not work because the resource is conflict with the old.

devm resource would be released when the driver detach, this is better than 
what we do now, I think.

Thanks!
Yijing.

在 2016/6/19 2:07, Bjorn Helgaas 写道:
> On Mon, Jun 06, 2016 at 06:04:44PM -0500, Bjorn Helgaas wrote:
>> Several host bridge drivers (designware and all derivatives, iproc,
>> xgene, xilinx, and xilinx-nwl) don't request the MMIO and I/O port
>> windows they forward downstream to the PCI bus.
>>
>> That means the PCI core can't request resources for PCI bridge
>> windows and PCI BARs.
>>
>> Several other drivers (altera, generic, mvebu, rcar, tegra) do request
>> the windows, but use some duplicated code to do it.
>>
>> This adds a new devm_request_pci_bus_resources() interface and changes
>> these drivers to use it.  It also fixes several error paths where we failed
>> to free the resource list allocated by of_pci_get_host_bridge_resources().
>>
>> Tegra guys, please take a look at "PCI: tegra: Remove top-level resource
>> from hierarchy" in particular.  Removing the top-level resource definitely
>> makes /proc/iomem look uglier (although it will look more like that of
>> other drivers).  A short-term fix could be to include device information in
>> the resource name.  I think a better long-term fix would be to make the DT
>> or platform device core request all the resources from the DT.
>>
>> Comments welcome.  I expect we'll trip over something here, so I marked
>> this "v1" and I don't plan to put it into -next for a while.
>>
>> This is on my pci/host-request-windows branch, which you can pull or view
>> at 
>> https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/log/?h=pci/host-request-windows
> 
> I merged this to my -next branch, so it should show up in linux-next
> in a couple days.  Let me know if you see any problems.
> 
>> Bjorn Helgaas (25):
>>   PCI: Add devm_request_pci_bus_resources()
>>   PCI: designware: Free bridge resource list on failure
>>   PCI: designware: Request host bridge window resources
>>   PCI: designware: Simplify host bridge window iteration
>>   PCI: iproc: Request host bridge window resources
>>   PCI: xgene: Free bridge resource list on failure
>>   PCI: xgene: Request host bridge window resources
>>   PCI: xilinx: Free bridge resource list on failure
>>   PCI: xilinx: Request host bridge window resources
>>   PCI: xilinx-nwl: Free bridge resource list on failure
>>   PCI: xilinx-nwl: Request host bridge window resources
>>   PCI: xilinx-nwl: Use dev_printk() when possible
>>   PCI: altera: Request host bridge window resources with core function
>>   PCI: altera: Simplify host bridge window iteration
>>   PCI: generic: Free resource list close to where it's allocated
>>   PCI: generic: Request host bridge window resources with core function
>>   PCI: generic: Simplify host bridge window iteration
>>   PCI: mvebu: Request host bridge window resources with core function
>>   PCI: rcar Gen2: Request host bridge window resources
>>   PCI: rcar: Request host bridge window resources with core function
>>   PCI: rcar: Simplify host bridge window iteration
>>   PCI: tegra: Remove top-level resource from hierarchy
>>   PCI: tegra: Request host bridge window resources with core function
>>   PCI: versatile: Request host bridge window resources with core function
>>   PCI: versatile: Simplify host bridge window iteration
>>
>>
>>  drivers/pci/bus.c  |   29 +
>>  drivers/pci/host/pci-host-common.c |   61 
>> +++-
>>  drivers/pci/host/pci-mvebu.c   |   17 --
>>  drivers/pci/host/pci-rcar-gen2.c   |4 ++
>>  drivers/pci/host/pci-tegra.c   |   35 +++--
>>  drivers/pci/host/pci-versatile.c   |   29 ++---
>>  drivers/pci/host/pci-xgene.c   |   16 -
>>  drivers/pci/host/pcie-altera.c |   35 ++---
>>  drivers/pci/host/pcie-designware.c |   34 +---
>>  drivers/pci/host/pcie-iproc.c  |4 ++
>>  drivers/pci/host/pcie-rcar.c   |   33 +--
>>  drivers/pci/host/pcie-xilinx-nwl.c |   20 +---
>>  

Re: [PATCH v1 00/25] PCI: Request host bridge window resources

[Bjorn Helgaas]

On Mon, Jun 06, 2016 at 06:04:44PM -0500, Bjorn Helgaas wrote:
> Several host bridge drivers (designware and all derivatives, iproc,
> xgene, xilinx, and xilinx-nwl) don't request the MMIO and I/O port
> windows they forward downstream to the PCI bus.
> 
> That means the PCI core can't request resources for PCI bridge
> windows and PCI BARs.
> 
> Several other drivers (altera, generic, mvebu, rcar, tegra) do request
> the windows, but use some duplicated code to do it.
> 
> This adds a new devm_request_pci_bus_resources() interface and changes
> these drivers to use it.  It also fixes several error paths where we failed
> to free the resource list allocated by of_pci_get_host_bridge_resources().
> 
> Tegra guys, please take a look at "PCI: tegra: Remove top-level resource
> from hierarchy" in particular.  Removing the top-level resource definitely
> makes /proc/iomem look uglier (although it will look more like that of
> other drivers).  A short-term fix could be to include device information in
> the resource name.  I think a better long-term fix would be to make the DT
> or platform device core request all the resources from the DT.
> 
> Comments welcome.  I expect we'll trip over something here, so I marked
> this "v1" and I don't plan to put it into -next for a while.
> 
> This is on my pci/host-request-windows branch, which you can pull or view
> at 
> https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/log/?h=pci/host-request-windows

I merged this to my -next branch, so it should show up in linux-next
in a couple days.  Let me know if you see any problems.

> Bjorn Helgaas (25):
>   PCI: Add devm_request_pci_bus_resources()
>   PCI: designware: Free bridge resource list on failure
>   PCI: designware: Request host bridge window resources
>   PCI: designware: Simplify host bridge window iteration
>   PCI: iproc: Request host bridge window resources
>   PCI: xgene: Free bridge resource list on failure
>   PCI: xgene: Request host bridge window resources
>   PCI: xilinx: Free bridge resource list on failure
>   PCI: xilinx: Request host bridge window resources
>   PCI: xilinx-nwl: Free bridge resource list on failure
>   PCI: xilinx-nwl: Request host bridge window resources
>   PCI: xilinx-nwl: Use dev_printk() when possible
>   PCI: altera: Request host bridge window resources with core function
>   PCI: altera: Simplify host bridge window iteration
>   PCI: generic: Free resource list close to where it's allocated
>   PCI: generic: Request host bridge window resources with core function
>   PCI: generic: Simplify host bridge window iteration
>   PCI: mvebu: Request host bridge window resources with core function
>   PCI: rcar Gen2: Request host bridge window resources
>   PCI: rcar: Request host bridge window resources with core function
>   PCI: rcar: Simplify host bridge window iteration
>   PCI: tegra: Remove top-level resource from hierarchy
>   PCI: tegra: Request host bridge window resources with core function
>   PCI: versatile: Request host bridge window resources with core function
>   PCI: versatile: Simplify host bridge window iteration
> 
> 
>  drivers/pci/bus.c  |   29 +
>  drivers/pci/host/pci-host-common.c |   61 
> +++-
>  drivers/pci/host/pci-mvebu.c   |   17 --
>  drivers/pci/host/pci-rcar-gen2.c   |4 ++
>  drivers/pci/host/pci-tegra.c   |   35 +++--
>  drivers/pci/host/pci-versatile.c   |   29 ++---
>  drivers/pci/host/pci-xgene.c   |   16 -
>  drivers/pci/host/pcie-altera.c |   35 ++---
>  drivers/pci/host/pcie-designware.c |   34 +---
>  drivers/pci/host/pcie-iproc.c  |4 ++
>  drivers/pci/host/pcie-rcar.c   |   33 +--
>  drivers/pci/host/pcie-xilinx-nwl.c |   20 +---
>  drivers/pci/host/pcie-xilinx.c |   16 -
>  include/linux/pci.h|5 ++-
>  14 files changed, 170 insertions(+), 168 deletions(-)
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v1 00/25] PCI: Request host bridge window resources

[Bjorn Helgaas]

On Mon, Jun 06, 2016 at 06:04:44PM -0500, Bjorn Helgaas wrote:
> Several host bridge drivers (designware and all derivatives, iproc,
> xgene, xilinx, and xilinx-nwl) don't request the MMIO and I/O port
> windows they forward downstream to the PCI bus.
> 
> That means the PCI core can't request resources for PCI bridge
> windows and PCI BARs.
> 
> Several other drivers (altera, generic, mvebu, rcar, tegra) do request
> the windows, but use some duplicated code to do it.
> 
> This adds a new devm_request_pci_bus_resources() interface and changes
> these drivers to use it.  It also fixes several error paths where we failed
> to free the resource list allocated by of_pci_get_host_bridge_resources().
> 
> Tegra guys, please take a look at "PCI: tegra: Remove top-level resource
> from hierarchy" in particular.  Removing the top-level resource definitely
> makes /proc/iomem look uglier (although it will look more like that of
> other drivers).  A short-term fix could be to include device information in
> the resource name.  I think a better long-term fix would be to make the DT
> or platform device core request all the resources from the DT.
> 
> Comments welcome.  I expect we'll trip over something here, so I marked
> this "v1" and I don't plan to put it into -next for a while.
> 
> This is on my pci/host-request-windows branch, which you can pull or view
> at 
> https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/log/?h=pci/host-request-windows

I merged this to my -next branch, so it should show up in linux-next
in a couple days.  Let me know if you see any problems.

> Bjorn Helgaas (25):
>   PCI: Add devm_request_pci_bus_resources()
>   PCI: designware: Free bridge resource list on failure
>   PCI: designware: Request host bridge window resources
>   PCI: designware: Simplify host bridge window iteration
>   PCI: iproc: Request host bridge window resources
>   PCI: xgene: Free bridge resource list on failure
>   PCI: xgene: Request host bridge window resources
>   PCI: xilinx: Free bridge resource list on failure
>   PCI: xilinx: Request host bridge window resources
>   PCI: xilinx-nwl: Free bridge resource list on failure
>   PCI: xilinx-nwl: Request host bridge window resources
>   PCI: xilinx-nwl: Use dev_printk() when possible
>   PCI: altera: Request host bridge window resources with core function
>   PCI: altera: Simplify host bridge window iteration
>   PCI: generic: Free resource list close to where it's allocated
>   PCI: generic: Request host bridge window resources with core function
>   PCI: generic: Simplify host bridge window iteration
>   PCI: mvebu: Request host bridge window resources with core function
>   PCI: rcar Gen2: Request host bridge window resources
>   PCI: rcar: Request host bridge window resources with core function
>   PCI: rcar: Simplify host bridge window iteration
>   PCI: tegra: Remove top-level resource from hierarchy
>   PCI: tegra: Request host bridge window resources with core function
>   PCI: versatile: Request host bridge window resources with core function
>   PCI: versatile: Simplify host bridge window iteration
> 
> 
>  drivers/pci/bus.c  |   29 +
>  drivers/pci/host/pci-host-common.c |   61 
> +++-
>  drivers/pci/host/pci-mvebu.c   |   17 --
>  drivers/pci/host/pci-rcar-gen2.c   |4 ++
>  drivers/pci/host/pci-tegra.c   |   35 +++--
>  drivers/pci/host/pci-versatile.c   |   29 ++---
>  drivers/pci/host/pci-xgene.c   |   16 -
>  drivers/pci/host/pcie-altera.c |   35 ++---
>  drivers/pci/host/pcie-designware.c |   34 +---
>  drivers/pci/host/pcie-iproc.c  |4 ++
>  drivers/pci/host/pcie-rcar.c   |   33 +--
>  drivers/pci/host/pcie-xilinx-nwl.c |   20 +---
>  drivers/pci/host/pcie-xilinx.c |   16 -
>  include/linux/pci.h|5 ++-
>  14 files changed, 170 insertions(+), 168 deletions(-)
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v1 00/25] PCI: Request host bridge window resources

[Bjorn Helgaas]

On Tue, Jun 07, 2016 at 08:11:05AM -0500, Bjorn Helgaas wrote:
> On Tue, Jun 07, 2016 at 10:21:36AM +0200, Arnd Bergmann wrote:
> > On Monday, June 6, 2016 6:04:44 PM CEST Bjorn Helgaas wrote:
> > > Several host bridge drivers (designware and all derivatives, iproc,
> > > xgene, xilinx, and xilinx-nwl) don't request the MMIO and I/O port
> > > windows they forward downstream to the PCI bus.
> > > 
> > > That means the PCI core can't request resources for PCI bridge
> > > windows and PCI BARs.
> > > 
> > > Several other drivers (altera, generic, mvebu, rcar, tegra) do request
> > > the windows, but use some duplicated code to do it.
> > > 
> > > This adds a new devm_request_pci_bus_resources() interface and changes
> > > these drivers to use it.  It also fixes several error paths where we 
> > > failed
> > > to free the resource list allocated by of_pci_get_host_bridge_resources().
> > > 
> > > Tegra guys, please take a look at "PCI: tegra: Remove top-level resource
> > > from hierarchy" in particular.  Removing the top-level resource definitely
> > > makes /proc/iomem look uglier (although it will look more like that of
> > > other drivers).  A short-term fix could be to include device information 
> > > in
> > > the resource name.  I think a better long-term fix would be to make the DT
> > > or platform device core request all the resources from the DT.
> > > 
> > > Comments welcome.  I expect we'll trip over something here, so I marked
> > > this "v1" and I don't plan to put it into -next for a while.
> > > 
> > > This is on my pci/host-request-windows branch, which you can pull or view
> > > at 
> > > https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/log/?h=pci/host-request-windows
> > 
> > This looks very nice. There is one related aspect that I have been
> > grumbling about for a while, but I don't know what the driver is
> > actually supposed to do there:
> > 
> > For the IORESOURCE_IO resources, some drivers request the MMIO address
> > that the window is mapped into, some drivers request the PIO range, and
> > some of them request both. I also believe the resource that gets put
> > into the bridge resources list is not always the same one (or maybe
> > that got fixed by now).
> > 
> > What do you think is the correct behavior here, should the driver only
> > request the PIO range with parent=ioport_resource, or should it also
> > request the MMIO window for the I/O ports with parent=iomem_resource?
> > In the latter case, any idea how that can be generalized?
> 
> I think it should request both because I think iomem_resource should
> contain everything in the memory map.  This would be required if we ever
> did any significant reassignment of top-level devices, e.g., ACPI devices.
> For example, on ia64, we do this:
> 
>   /proc/ioports:
>   -3fff : PCI Bus :00
>   4000-9fff : PCI Bus :80
>   a000-bfff : PCI Bus :a0
>   c000- : PCI Bus :c0
> 
>   /proc/iomem:
>   8000-9fff : PCI Bus :00
>   a000-cfff : PCI Bus :80
>   d000-dfff : PCI Bus :a0
>   e000-fdff : PCI Bus :c0
>   8000400-80103fe : PCI Bus :00
>   c000400-c0103fe : PCI Bus :80
>   d000400-d0103fe : PCI Bus :a0
>   e000400-e0103fe : PCI Bus :c0
>   3fc00-3fcff : PCI Bus :00 I/O Ports -3fff
>   3fd00-3fe7f : PCI Bus :80 I/O Ports 4000-9fff
>   3fe80-3feff : PCI Bus :a0 I/O Ports a000-bfff
>   3ff00-3 : PCI Bus :c0 I/O Ports c000-
> 
> > Another aspect is that we already have the
> > gen_pci_parse_request_of_pci_ranges() function that does the same as your
> > new devm_request_pci_bus_resources() and then a few other things. I
> > have been wondering whether we could move that function into common
> > code convert drivers to use that wherever possible, but I guess we can
> > always do that as a follow-up after this series.
> 
> Oh, I didn't notice that; thanks for pointing it out.  That should be
> consolidated somehow.  It also checks to be sure there is a
> non-prefetchable memory resource.  A few other drivers also do that, but
> most don't.  I suppose that will mostly catch DT errors.

Coming back to this, I did actually change
gen_pci_parse_request_of_pci_ranges() to call my new function in
[16/25] "PCI: generic: Request host bridge window resources with core
function".

The gen_pci_parse_request_of_pci_ranges() is still there and it still
contains the loop to deal with the I/O port space and to validate that
a non-prefetchable memory window exists.  Both of those could probably
be made more generic later.

Bjorn

Re: [PATCH v1 00/25] PCI: Request host bridge window resources

[Bjorn Helgaas]

On Tue, Jun 07, 2016 at 08:11:05AM -0500, Bjorn Helgaas wrote:
> On Tue, Jun 07, 2016 at 10:21:36AM +0200, Arnd Bergmann wrote:
> > On Monday, June 6, 2016 6:04:44 PM CEST Bjorn Helgaas wrote:
> > > Several host bridge drivers (designware and all derivatives, iproc,
> > > xgene, xilinx, and xilinx-nwl) don't request the MMIO and I/O port
> > > windows they forward downstream to the PCI bus.
> > > 
> > > That means the PCI core can't request resources for PCI bridge
> > > windows and PCI BARs.
> > > 
> > > Several other drivers (altera, generic, mvebu, rcar, tegra) do request
> > > the windows, but use some duplicated code to do it.
> > > 
> > > This adds a new devm_request_pci_bus_resources() interface and changes
> > > these drivers to use it.  It also fixes several error paths where we 
> > > failed
> > > to free the resource list allocated by of_pci_get_host_bridge_resources().
> > > 
> > > Tegra guys, please take a look at "PCI: tegra: Remove top-level resource
> > > from hierarchy" in particular.  Removing the top-level resource definitely
> > > makes /proc/iomem look uglier (although it will look more like that of
> > > other drivers).  A short-term fix could be to include device information 
> > > in
> > > the resource name.  I think a better long-term fix would be to make the DT
> > > or platform device core request all the resources from the DT.
> > > 
> > > Comments welcome.  I expect we'll trip over something here, so I marked
> > > this "v1" and I don't plan to put it into -next for a while.
> > > 
> > > This is on my pci/host-request-windows branch, which you can pull or view
> > > at 
> > > https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/log/?h=pci/host-request-windows
> > 
> > This looks very nice. There is one related aspect that I have been
> > grumbling about for a while, but I don't know what the driver is
> > actually supposed to do there:
> > 
> > For the IORESOURCE_IO resources, some drivers request the MMIO address
> > that the window is mapped into, some drivers request the PIO range, and
> > some of them request both. I also believe the resource that gets put
> > into the bridge resources list is not always the same one (or maybe
> > that got fixed by now).
> > 
> > What do you think is the correct behavior here, should the driver only
> > request the PIO range with parent=ioport_resource, or should it also
> > request the MMIO window for the I/O ports with parent=iomem_resource?
> > In the latter case, any idea how that can be generalized?
> 
> I think it should request both because I think iomem_resource should
> contain everything in the memory map.  This would be required if we ever
> did any significant reassignment of top-level devices, e.g., ACPI devices.
> For example, on ia64, we do this:
> 
>   /proc/ioports:
>   -3fff : PCI Bus :00
>   4000-9fff : PCI Bus :80
>   a000-bfff : PCI Bus :a0
>   c000- : PCI Bus :c0
> 
>   /proc/iomem:
>   8000-9fff : PCI Bus :00
>   a000-cfff : PCI Bus :80
>   d000-dfff : PCI Bus :a0
>   e000-fdff : PCI Bus :c0
>   8000400-80103fe : PCI Bus :00
>   c000400-c0103fe : PCI Bus :80
>   d000400-d0103fe : PCI Bus :a0
>   e000400-e0103fe : PCI Bus :c0
>   3fc00-3fcff : PCI Bus :00 I/O Ports -3fff
>   3fd00-3fe7f : PCI Bus :80 I/O Ports 4000-9fff
>   3fe80-3feff : PCI Bus :a0 I/O Ports a000-bfff
>   3ff00-3 : PCI Bus :c0 I/O Ports c000-
> 
> > Another aspect is that we already have the
> > gen_pci_parse_request_of_pci_ranges() function that does the same as your
> > new devm_request_pci_bus_resources() and then a few other things. I
> > have been wondering whether we could move that function into common
> > code convert drivers to use that wherever possible, but I guess we can
> > always do that as a follow-up after this series.
> 
> Oh, I didn't notice that; thanks for pointing it out.  That should be
> consolidated somehow.  It also checks to be sure there is a
> non-prefetchable memory resource.  A few other drivers also do that, but
> most don't.  I suppose that will mostly catch DT errors.

Coming back to this, I did actually change
gen_pci_parse_request_of_pci_ranges() to call my new function in
[16/25] "PCI: generic: Request host bridge window resources with core
function".

The gen_pci_parse_request_of_pci_ranges() is still there and it still
contains the loop to deal with the I/O port space and to validate that
a non-prefetchable memory window exists.  Both of those could probably
be made more generic later.

Bjorn

Re: [PATCH v1 00/25] PCI: Request host bridge window resources

[Duc Dang]

On Mon, Jun 6, 2016 at 4:04 PM, Bjorn Helgaas  wrote:
> Several host bridge drivers (designware and all derivatives, iproc,
> xgene, xilinx, and xilinx-nwl) don't request the MMIO and I/O port
> windows they forward downstream to the PCI bus.
>
> That means the PCI core can't request resources for PCI bridge
> windows and PCI BARs.
>
> Several other drivers (altera, generic, mvebu, rcar, tegra) do request
> the windows, but use some duplicated code to do it.
>
> This adds a new devm_request_pci_bus_resources() interface and changes
> these drivers to use it.  It also fixes several error paths where we failed
> to free the resource list allocated by of_pci_get_host_bridge_resources().
>
> Tegra guys, please take a look at "PCI: tegra: Remove top-level resource
> from hierarchy" in particular.  Removing the top-level resource definitely
> makes /proc/iomem look uglier (although it will look more like that of
> other drivers).  A short-term fix could be to include device information in
> the resource name.  I think a better long-term fix would be to make the DT
> or platform device core request all the resources from the DT.
>
> Comments welcome.  I expect we'll trip over something here, so I marked
> this "v1" and I don't plan to put it into -next for a while.
>
> This is on my pci/host-request-windows branch, which you can pull or view
> at 
> https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/log/?h=pci/host-request-windows
>
> ---
>
> Bjorn Helgaas (25):
>   PCI: Add devm_request_pci_bus_resources()
>   PCI: designware: Free bridge resource list on failure
>   PCI: designware: Request host bridge window resources
>   PCI: designware: Simplify host bridge window iteration
>   PCI: iproc: Request host bridge window resources
>   PCI: xgene: Free bridge resource list on failure
>   PCI: xgene: Request host bridge window resources
>   PCI: xilinx: Free bridge resource list on failure
>   PCI: xilinx: Request host bridge window resources
>   PCI: xilinx-nwl: Free bridge resource list on failure
>   PCI: xilinx-nwl: Request host bridge window resources
>   PCI: xilinx-nwl: Use dev_printk() when possible
>   PCI: altera: Request host bridge window resources with core function
>   PCI: altera: Simplify host bridge window iteration
>   PCI: generic: Free resource list close to where it's allocated
>   PCI: generic: Request host bridge window resources with core function
>   PCI: generic: Simplify host bridge window iteration
>   PCI: mvebu: Request host bridge window resources with core function
>   PCI: rcar Gen2: Request host bridge window resources
>   PCI: rcar: Request host bridge window resources with core function
>   PCI: rcar: Simplify host bridge window iteration
>   PCI: tegra: Remove top-level resource from hierarchy
>   PCI: tegra: Request host bridge window resources with core function
>   PCI: versatile: Request host bridge window resources with core function
>   PCI: versatile: Simplify host bridge window iteration

Thanks, Bjorn.

For the 2 X-Gene patches:
 PCI: xgene: Free bridge resource list on failure
 PCI: xgene: Request host bridge window resources

Tested-by: Duc Dang 

Regards,
Duc Dang.
>
>
>  drivers/pci/bus.c  |   29 +
>  drivers/pci/host/pci-host-common.c |   61 
> +++-
>  drivers/pci/host/pci-mvebu.c   |   17 --
>  drivers/pci/host/pci-rcar-gen2.c   |4 ++
>  drivers/pci/host/pci-tegra.c   |   35 +++--
>  drivers/pci/host/pci-versatile.c   |   29 ++---
>  drivers/pci/host/pci-xgene.c   |   16 -
>  drivers/pci/host/pcie-altera.c |   35 ++---
>  drivers/pci/host/pcie-designware.c |   34 +---
>  drivers/pci/host/pcie-iproc.c  |4 ++
>  drivers/pci/host/pcie-rcar.c   |   33 +--
>  drivers/pci/host/pcie-xilinx-nwl.c |   20 +---
>  drivers/pci/host/pcie-xilinx.c |   16 -
>  include/linux/pci.h|5 ++-
>  14 files changed, 170 insertions(+), 168 deletions(-)
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v1 00/25] PCI: Request host bridge window resources

[Duc Dang]

On Mon, Jun 6, 2016 at 4:04 PM, Bjorn Helgaas  wrote:
> Several host bridge drivers (designware and all derivatives, iproc,
> xgene, xilinx, and xilinx-nwl) don't request the MMIO and I/O port
> windows they forward downstream to the PCI bus.
>
> That means the PCI core can't request resources for PCI bridge
> windows and PCI BARs.
>
> Several other drivers (altera, generic, mvebu, rcar, tegra) do request
> the windows, but use some duplicated code to do it.
>
> This adds a new devm_request_pci_bus_resources() interface and changes
> these drivers to use it.  It also fixes several error paths where we failed
> to free the resource list allocated by of_pci_get_host_bridge_resources().
>
> Tegra guys, please take a look at "PCI: tegra: Remove top-level resource
> from hierarchy" in particular.  Removing the top-level resource definitely
> makes /proc/iomem look uglier (although it will look more like that of
> other drivers).  A short-term fix could be to include device information in
> the resource name.  I think a better long-term fix would be to make the DT
> or platform device core request all the resources from the DT.
>
> Comments welcome.  I expect we'll trip over something here, so I marked
> this "v1" and I don't plan to put it into -next for a while.
>
> This is on my pci/host-request-windows branch, which you can pull or view
> at 
> https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/log/?h=pci/host-request-windows
>
> ---
>
> Bjorn Helgaas (25):
>   PCI: Add devm_request_pci_bus_resources()
>   PCI: designware: Free bridge resource list on failure
>   PCI: designware: Request host bridge window resources
>   PCI: designware: Simplify host bridge window iteration
>   PCI: iproc: Request host bridge window resources
>   PCI: xgene: Free bridge resource list on failure
>   PCI: xgene: Request host bridge window resources
>   PCI: xilinx: Free bridge resource list on failure
>   PCI: xilinx: Request host bridge window resources
>   PCI: xilinx-nwl: Free bridge resource list on failure
>   PCI: xilinx-nwl: Request host bridge window resources
>   PCI: xilinx-nwl: Use dev_printk() when possible
>   PCI: altera: Request host bridge window resources with core function
>   PCI: altera: Simplify host bridge window iteration
>   PCI: generic: Free resource list close to where it's allocated
>   PCI: generic: Request host bridge window resources with core function
>   PCI: generic: Simplify host bridge window iteration
>   PCI: mvebu: Request host bridge window resources with core function
>   PCI: rcar Gen2: Request host bridge window resources
>   PCI: rcar: Request host bridge window resources with core function
>   PCI: rcar: Simplify host bridge window iteration
>   PCI: tegra: Remove top-level resource from hierarchy
>   PCI: tegra: Request host bridge window resources with core function
>   PCI: versatile: Request host bridge window resources with core function
>   PCI: versatile: Simplify host bridge window iteration

Thanks, Bjorn.

For the 2 X-Gene patches:
 PCI: xgene: Free bridge resource list on failure
 PCI: xgene: Request host bridge window resources

Tested-by: Duc Dang 

Regards,
Duc Dang.
>
>
>  drivers/pci/bus.c  |   29 +
>  drivers/pci/host/pci-host-common.c |   61 
> +++-
>  drivers/pci/host/pci-mvebu.c   |   17 --
>  drivers/pci/host/pci-rcar-gen2.c   |4 ++
>  drivers/pci/host/pci-tegra.c   |   35 +++--
>  drivers/pci/host/pci-versatile.c   |   29 ++---
>  drivers/pci/host/pci-xgene.c   |   16 -
>  drivers/pci/host/pcie-altera.c |   35 ++---
>  drivers/pci/host/pcie-designware.c |   34 +---
>  drivers/pci/host/pcie-iproc.c  |4 ++
>  drivers/pci/host/pcie-rcar.c   |   33 +--
>  drivers/pci/host/pcie-xilinx-nwl.c |   20 +---
>  drivers/pci/host/pcie-xilinx.c |   16 -
>  include/linux/pci.h|5 ++-
>  14 files changed, 170 insertions(+), 168 deletions(-)
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v1 00/25] PCI: Request host bridge window resources

[Bjorn Helgaas]

On Tue, Jun 07, 2016 at 03:25:46PM +0200, Arnd Bergmann wrote:
> On Tuesday, June 7, 2016 8:11:05 AM CEST Bjorn Helgaas wrote:
> > > 
> > > What do you think is the correct behavior here, should the driver only
> > > request the PIO range with parent=ioport_resource, or should it also
> > > request the MMIO window for the I/O ports with parent=iomem_resource?
> > > In the latter case, any idea how that can be generalized?
> > 
> > I think it should request both because I think iomem_resource should
> > contain everything in the memory map.  This would be required if we ever
> > did any significant reassignment of top-level devices, e.g., ACPI devices.
> 
> Ok. Should we try to pass the mmio resource for the I/O window to
> the devm_request_pci_bus_resources() function along with the other
> arguments then?

I think memory-mapped I/O port windows are different enough that maybe
we ought to handle them separately.  It seems like there are several
things related to setting up those windows (requesting the resource,
ioremapping it, allocating the CPU port number space, etc.), and maybe
if we keep this out, a pattern will emerge.

Maybe I should rename this to "devm_request_pci_host_windows()" or
something?

> As far as I can tell, it should not go into the resource list
> because it is not something the PCI core code should access the
> way it handles the other resources.

Right.

Bjorn

Re: [PATCH v1 00/25] PCI: Request host bridge window resources

[Bjorn Helgaas]

On Tue, Jun 07, 2016 at 03:25:46PM +0200, Arnd Bergmann wrote:
> On Tuesday, June 7, 2016 8:11:05 AM CEST Bjorn Helgaas wrote:
> > > 
> > > What do you think is the correct behavior here, should the driver only
> > > request the PIO range with parent=ioport_resource, or should it also
> > > request the MMIO window for the I/O ports with parent=iomem_resource?
> > > In the latter case, any idea how that can be generalized?
> > 
> > I think it should request both because I think iomem_resource should
> > contain everything in the memory map.  This would be required if we ever
> > did any significant reassignment of top-level devices, e.g., ACPI devices.
> 
> Ok. Should we try to pass the mmio resource for the I/O window to
> the devm_request_pci_bus_resources() function along with the other
> arguments then?

I think memory-mapped I/O port windows are different enough that maybe
we ought to handle them separately.  It seems like there are several
things related to setting up those windows (requesting the resource,
ioremapping it, allocating the CPU port number space, etc.), and maybe
if we keep this out, a pattern will emerge.

Maybe I should rename this to "devm_request_pci_host_windows()" or
something?

> As far as I can tell, it should not go into the resource list
> because it is not something the PCI core code should access the
> way it handles the other resources.

Right.

Bjorn

Re: [PATCH v1 00/25] PCI: Request host bridge window resources

[Arnd Bergmann]

On Tuesday, June 7, 2016 8:11:05 AM CEST Bjorn Helgaas wrote:
> > 
> > What do you think is the correct behavior here, should the driver only
> > request the PIO range with parent=ioport_resource, or should it also
> > request the MMIO window for the I/O ports with parent=iomem_resource?
> > In the latter case, any idea how that can be generalized?
> 
> I think it should request both because I think iomem_resource should
> contain everything in the memory map.  This would be required if we ever
> did any significant reassignment of top-level devices, e.g., ACPI devices.

Ok. Should we try to pass the mmio resource for the I/O window to
the devm_request_pci_bus_resources() function along with the other
arguments then?

As far as I can tell, it should not go into the resource list
because it is not something the PCI core code should access the
way it handles the other resources.

Arnd

Re: [PATCH v1 00/25] PCI: Request host bridge window resources

[Arnd Bergmann]

On Tuesday, June 7, 2016 8:11:05 AM CEST Bjorn Helgaas wrote:
> > 
> > What do you think is the correct behavior here, should the driver only
> > request the PIO range with parent=ioport_resource, or should it also
> > request the MMIO window for the I/O ports with parent=iomem_resource?
> > In the latter case, any idea how that can be generalized?
> 
> I think it should request both because I think iomem_resource should
> contain everything in the memory map.  This would be required if we ever
> did any significant reassignment of top-level devices, e.g., ACPI devices.

Ok. Should we try to pass the mmio resource for the I/O window to
the devm_request_pci_bus_resources() function along with the other
arguments then?

As far as I can tell, it should not go into the resource list
because it is not something the PCI core code should access the
way it handles the other resources.

Arnd

Re: [PATCH v1 00/25] PCI: Request host bridge window resources

[Bjorn Helgaas]

On Tue, Jun 07, 2016 at 10:21:36AM +0200, Arnd Bergmann wrote:
> On Monday, June 6, 2016 6:04:44 PM CEST Bjorn Helgaas wrote:
> > Several host bridge drivers (designware and all derivatives, iproc,
> > xgene, xilinx, and xilinx-nwl) don't request the MMIO and I/O port
> > windows they forward downstream to the PCI bus.
> > 
> > That means the PCI core can't request resources for PCI bridge
> > windows and PCI BARs.
> > 
> > Several other drivers (altera, generic, mvebu, rcar, tegra) do request
> > the windows, but use some duplicated code to do it.
> > 
> > This adds a new devm_request_pci_bus_resources() interface and changes
> > these drivers to use it.  It also fixes several error paths where we failed
> > to free the resource list allocated by of_pci_get_host_bridge_resources().
> > 
> > Tegra guys, please take a look at "PCI: tegra: Remove top-level resource
> > from hierarchy" in particular.  Removing the top-level resource definitely
> > makes /proc/iomem look uglier (although it will look more like that of
> > other drivers).  A short-term fix could be to include device information in
> > the resource name.  I think a better long-term fix would be to make the DT
> > or platform device core request all the resources from the DT.
> > 
> > Comments welcome.  I expect we'll trip over something here, so I marked
> > this "v1" and I don't plan to put it into -next for a while.
> > 
> > This is on my pci/host-request-windows branch, which you can pull or view
> > at 
> > https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/log/?h=pci/host-request-windows
> 
> This looks very nice. There is one related aspect that I have been
> grumbling about for a while, but I don't know what the driver is
> actually supposed to do there:
> 
> For the IORESOURCE_IO resources, some drivers request the MMIO address
> that the window is mapped into, some drivers request the PIO range, and
> some of them request both. I also believe the resource that gets put
> into the bridge resources list is not always the same one (or maybe
> that got fixed by now).
> 
> What do you think is the correct behavior here, should the driver only
> request the PIO range with parent=ioport_resource, or should it also
> request the MMIO window for the I/O ports with parent=iomem_resource?
> In the latter case, any idea how that can be generalized?

I think it should request both because I think iomem_resource should
contain everything in the memory map.  This would be required if we ever
did any significant reassignment of top-level devices, e.g., ACPI devices.
For example, on ia64, we do this:

  /proc/ioports:
  -3fff : PCI Bus :00
  4000-9fff : PCI Bus :80
  a000-bfff : PCI Bus :a0
  c000- : PCI Bus :c0

  /proc/iomem:
  8000-9fff : PCI Bus :00
  a000-cfff : PCI Bus :80
  d000-dfff : PCI Bus :a0
  e000-fdff : PCI Bus :c0
  8000400-80103fe : PCI Bus :00
  c000400-c0103fe : PCI Bus :80
  d000400-d0103fe : PCI Bus :a0
  e000400-e0103fe : PCI Bus :c0
  3fc00-3fcff : PCI Bus :00 I/O Ports -3fff
  3fd00-3fe7f : PCI Bus :80 I/O Ports 4000-9fff
  3fe80-3feff : PCI Bus :a0 I/O Ports a000-bfff
  3ff00-3 : PCI Bus :c0 I/O Ports c000-

> Another aspect is that we already have the
> gen_pci_parse_request_of_pci_ranges() function that does the same as your
> new devm_request_pci_bus_resources() and then a few other things. I
> have been wondering whether we could move that function into common
> code convert drivers to use that wherever possible, but I guess we can
> always do that as a follow-up after this series.

Oh, I didn't notice that; thanks for pointing it out.  That should be
consolidated somehow.  It also checks to be sure there is a
non-prefetchable memory resource.  A few other drivers also do that, but
most don't.  I suppose that will mostly catch DT errors.

Bjorn

Re: [PATCH v1 00/25] PCI: Request host bridge window resources

[Bjorn Helgaas]

On Tue, Jun 07, 2016 at 10:21:36AM +0200, Arnd Bergmann wrote:
> On Monday, June 6, 2016 6:04:44 PM CEST Bjorn Helgaas wrote:
> > Several host bridge drivers (designware and all derivatives, iproc,
> > xgene, xilinx, and xilinx-nwl) don't request the MMIO and I/O port
> > windows they forward downstream to the PCI bus.
> > 
> > That means the PCI core can't request resources for PCI bridge
> > windows and PCI BARs.
> > 
> > Several other drivers (altera, generic, mvebu, rcar, tegra) do request
> > the windows, but use some duplicated code to do it.
> > 
> > This adds a new devm_request_pci_bus_resources() interface and changes
> > these drivers to use it.  It also fixes several error paths where we failed
> > to free the resource list allocated by of_pci_get_host_bridge_resources().
> > 
> > Tegra guys, please take a look at "PCI: tegra: Remove top-level resource
> > from hierarchy" in particular.  Removing the top-level resource definitely
> > makes /proc/iomem look uglier (although it will look more like that of
> > other drivers).  A short-term fix could be to include device information in
> > the resource name.  I think a better long-term fix would be to make the DT
> > or platform device core request all the resources from the DT.
> > 
> > Comments welcome.  I expect we'll trip over something here, so I marked
> > this "v1" and I don't plan to put it into -next for a while.
> > 
> > This is on my pci/host-request-windows branch, which you can pull or view
> > at 
> > https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/log/?h=pci/host-request-windows
> 
> This looks very nice. There is one related aspect that I have been
> grumbling about for a while, but I don't know what the driver is
> actually supposed to do there:
> 
> For the IORESOURCE_IO resources, some drivers request the MMIO address
> that the window is mapped into, some drivers request the PIO range, and
> some of them request both. I also believe the resource that gets put
> into the bridge resources list is not always the same one (or maybe
> that got fixed by now).
> 
> What do you think is the correct behavior here, should the driver only
> request the PIO range with parent=ioport_resource, or should it also
> request the MMIO window for the I/O ports with parent=iomem_resource?
> In the latter case, any idea how that can be generalized?

I think it should request both because I think iomem_resource should
contain everything in the memory map.  This would be required if we ever
did any significant reassignment of top-level devices, e.g., ACPI devices.
For example, on ia64, we do this:

  /proc/ioports:
  -3fff : PCI Bus :00
  4000-9fff : PCI Bus :80
  a000-bfff : PCI Bus :a0
  c000- : PCI Bus :c0

  /proc/iomem:
  8000-9fff : PCI Bus :00
  a000-cfff : PCI Bus :80
  d000-dfff : PCI Bus :a0
  e000-fdff : PCI Bus :c0
  8000400-80103fe : PCI Bus :00
  c000400-c0103fe : PCI Bus :80
  d000400-d0103fe : PCI Bus :a0
  e000400-e0103fe : PCI Bus :c0
  3fc00-3fcff : PCI Bus :00 I/O Ports -3fff
  3fd00-3fe7f : PCI Bus :80 I/O Ports 4000-9fff
  3fe80-3feff : PCI Bus :a0 I/O Ports a000-bfff
  3ff00-3 : PCI Bus :c0 I/O Ports c000-

> Another aspect is that we already have the
> gen_pci_parse_request_of_pci_ranges() function that does the same as your
> new devm_request_pci_bus_resources() and then a few other things. I
> have been wondering whether we could move that function into common
> code convert drivers to use that wherever possible, but I guess we can
> always do that as a follow-up after this series.

Oh, I didn't notice that; thanks for pointing it out.  That should be
consolidated somehow.  It also checks to be sure there is a
non-prefetchable memory resource.  A few other drivers also do that, but
most don't.  I suppose that will mostly catch DT errors.

Bjorn

Re: [PATCH v1 00/25] PCI: Request host bridge window resources

[Arnd Bergmann]

On Monday, June 6, 2016 6:04:44 PM CEST Bjorn Helgaas wrote:
> Several host bridge drivers (designware and all derivatives, iproc,
> xgene, xilinx, and xilinx-nwl) don't request the MMIO and I/O port
> windows they forward downstream to the PCI bus.
> 
> That means the PCI core can't request resources for PCI bridge
> windows and PCI BARs.
> 
> Several other drivers (altera, generic, mvebu, rcar, tegra) do request
> the windows, but use some duplicated code to do it.
> 
> This adds a new devm_request_pci_bus_resources() interface and changes
> these drivers to use it.  It also fixes several error paths where we failed
> to free the resource list allocated by of_pci_get_host_bridge_resources().
> 
> Tegra guys, please take a look at "PCI: tegra: Remove top-level resource
> from hierarchy" in particular.  Removing the top-level resource definitely
> makes /proc/iomem look uglier (although it will look more like that of
> other drivers).  A short-term fix could be to include device information in
> the resource name.  I think a better long-term fix would be to make the DT
> or platform device core request all the resources from the DT.
> 
> Comments welcome.  I expect we'll trip over something here, so I marked
> this "v1" and I don't plan to put it into -next for a while.
> 
> This is on my pci/host-request-windows branch, which you can pull or view
> at 
> https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/log/?h=pci/host-request-windows

This looks very nice. There is one related aspect that I have been
grumbling about for a while, but I don't know what the driver is
actually supposed to do there:

For the IORESOURCE_IO resources, some drivers request the MMIO address
that the window is mapped into, some drivers request the PIO range, and
some of them request both. I also believe the resource that gets put
into the bridge resources list is not always the same one (or maybe
that got fixed by now).

What do you think is the correct behavior here, should the driver only
request the PIO range with parent=ioport_resource, or should it also
request the MMIO window for the I/O ports with parent=iomem_resource?
In the latter case, any idea how that can be generalized?

Another aspect is that we already have the
gen_pci_parse_request_of_pci_ranges() function that does the same as your
new devm_request_pci_bus_resources() and then a few other things. I
have been wondering whether we could move that function into common
code convert drivers to use that wherever possible, but I guess we can
always do that as a follow-up after this series.

Arnd

Re: [PATCH v1 00/25] PCI: Request host bridge window resources

[Arnd Bergmann]

On Monday, June 6, 2016 6:04:44 PM CEST Bjorn Helgaas wrote:
> Several host bridge drivers (designware and all derivatives, iproc,
> xgene, xilinx, and xilinx-nwl) don't request the MMIO and I/O port
> windows they forward downstream to the PCI bus.
> 
> That means the PCI core can't request resources for PCI bridge
> windows and PCI BARs.
> 
> Several other drivers (altera, generic, mvebu, rcar, tegra) do request
> the windows, but use some duplicated code to do it.
> 
> This adds a new devm_request_pci_bus_resources() interface and changes
> these drivers to use it.  It also fixes several error paths where we failed
> to free the resource list allocated by of_pci_get_host_bridge_resources().
> 
> Tegra guys, please take a look at "PCI: tegra: Remove top-level resource
> from hierarchy" in particular.  Removing the top-level resource definitely
> makes /proc/iomem look uglier (although it will look more like that of
> other drivers).  A short-term fix could be to include device information in
> the resource name.  I think a better long-term fix would be to make the DT
> or platform device core request all the resources from the DT.
> 
> Comments welcome.  I expect we'll trip over something here, so I marked
> this "v1" and I don't plan to put it into -next for a while.
> 
> This is on my pci/host-request-windows branch, which you can pull or view
> at 
> https://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/log/?h=pci/host-request-windows

This looks very nice. There is one related aspect that I have been
grumbling about for a while, but I don't know what the driver is
actually supposed to do there:

For the IORESOURCE_IO resources, some drivers request the MMIO address
that the window is mapped into, some drivers request the PIO range, and
some of them request both. I also believe the resource that gets put
into the bridge resources list is not always the same one (or maybe
that got fixed by now).

What do you think is the correct behavior here, should the driver only
request the PIO range with parent=ioport_resource, or should it also
request the MMIO window for the I/O ports with parent=iomem_resource?
In the latter case, any idea how that can be generalized?

Another aspect is that we already have the
gen_pci_parse_request_of_pci_ranges() function that does the same as your
new devm_request_pci_bus_resources() and then a few other things. I
have been wondering whether we could move that function into common
code convert drivers to use that wherever possible, but I guess we can
always do that as a follow-up after this series.

Arnd