ARM/ARM64 PCI_PROBE_ONLY platforms

Hi,

I noticed that:

79953dd22c1d ("PCI: rcar: Remove dependency on ARM-specific struct hw_pci") cbce7900598c ("PCI: designware: Make driver arch-agnostic")

added code in the respective host controller drivers to size bridges and assign resources only if the PCI_PROBE_ONLY flag is clear, which makes me wonder if there exists PCI_PROBE_ONLY set-ups for the respective host controllers:

- On ARM PCI_PROBE_ONLY can be set-up only via the command line or by DT (but the host controllers drivers have to check the DT and set it - see of_pci_check_probe_only()

in drivers/pci/host/pci-host-generic.c

neither designware nor rcar calls that function and I do not see any dts file with that property). Given that I can't see a way to set up PCI_PROBE_ONLY other than the command line on designware or rcar I assume the PCI_PROBE_ONLY set-ups have been tested by forcing it through command line parameter

- On ARM64 PCI_PROBE_ONLY can *only* be set via DT, so see above

We want to get rid of PCI_PROBE_ONLY on ARM/ARM64:

https://patchwork.ozlabs.org/patch/545671/

so unless you really have *existing* set-ups that require it, please remove the respective checks from the host controller drivers, this is becoming a serious issue, because either:

- we claim resources if and only if PCI_PROBE_ONLY is set

Either like this (to be done for every host controllers and ARM bios32):

https://patchwork.ozlabs.org/patch/545670/

or in core ARM/ARM64 code - eg pcibios_fixup_bus() - (to avoid adding a resource claiming call in ALL PCI host controllers)

- or we *always* carry out resource claiming regardless of PCI_PROBE_ONLY (but on ARM we can't really do that since PCI FW set-up on most of the platforms is not present)

On PCI_PROBE_ONLY systems resources claiming is mandatory if we want to get rid of arches workarounds:

https://patchwork.ozlabs.org/patch/545671/

Comments very appreciated.

Thanks,
Lorenzo
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 24 lines · Lorenzo Pieralisi

Hi,

I noticed that:

79953dd22c1d ("PCI: rcar: Remove dependency on ARM-specific struct hw_pci") cbce7900598c ("PCI: designware: Make driver arch-agnostic")

added code in the respective host controller drivers to size bridges and assign resources only if the PCI_PROBE_ONLY flag is clear, which makes me wonder if there exists PCI_PROBE_ONLY set-ups for the respective host controllers:

- On ARM PCI_PROBE_ONLY can be set-up only via the command line or by DT (but the host controllers drivers have to check the DT and set it - see of_pci_check_probe_only()

in drivers/pci/host/pci-host-generic.c

neither designware nor rcar calls that function and I do not see any dts file with that property). Given that I can't see a way to set up PCI_PROBE_ONLY other than the command line on designware or rcar I assume the PCI_PROBE_ONLY set-ups have been tested by forcing it through command line parameter

Quoted 3 lines

- On ARM64 PCI_PROBE_ONLY can *only* be set via DT, so see above

We want to get rid of PCI_PROBE_ONLY on ARM/ARM64:

For platforms that does not have UEFI BIOS, it makes sense to remove the probe only option as the firmware is not doing anything.

For server like arm64 platforms, the behavior should be identical to x86 world. The UEFI BIOS sets up the resources, kernel uses the resources.

Can we set this flag all the time for ACPI builds instead?

What's so special about arm64 that we can't do probe only builds and x86 can do?

Quoted 20 lines

https://patchwork.ozlabs.org/patch/545671/

so unless you really have *existing* set-ups that require it, please remove the respective checks from the host controller drivers, this is becoming a serious issue, because either:

- we claim resources if and only if PCI_PROBE_ONLY is set

Either like this (to be done for every host controllers and ARM bios32):

https://patchwork.ozlabs.org/patch/545670/

or in core ARM/ARM64 code - eg pcibios_fixup_bus() - (to avoid adding a resource claiming call in ALL PCI host controllers)

- or we *always* carry out resource claiming regardless of PCI_PROBE_ONLY (but on ARM we can't really do that since PCI FW set-up on most of the platforms is not present)

Quoted 2 lines

On PCI_PROBE_ONLY systems resources claiming is mandatory if we want to get rid of arches workarounds:

I'm hoping to see x86 like behavior on ARM64 without any gotchas as there is nothing special about CPU type when it comes to PCI.

Quoted 13 lines

https://patchwork.ozlabs.org/patch/545671/

Comments very appreciated.

Thanks,
Lorenzo
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Signature · 3 lines

Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

Quoted 32 lines · Sinan Kaya

Quoted 24 lines · Lorenzo Pieralisi

Hi,

I noticed that:

79953dd22c1d ("PCI: rcar: Remove dependency on ARM-specific struct hw_pci") cbce7900598c ("PCI: designware: Make driver arch-agnostic")

added code in the respective host controller drivers to size bridges and assign resources only if the PCI_PROBE_ONLY flag is clear, which makes me wonder if there exists PCI_PROBE_ONLY set-ups for the respective host controllers:

- On ARM PCI_PROBE_ONLY can be set-up only via the command line or by DT (but the host controllers drivers have to check the DT and set it - see of_pci_check_probe_only()

in drivers/pci/host/pci-host-generic.c

neither designware nor rcar calls that function and I do not see any dts file with that property). Given that I can't see a way to set up PCI_PROBE_ONLY other than the command line on designware or rcar I assume the PCI_PROBE_ONLY set-ups have been tested by forcing it through command line parameter

Quoted 3 lines

- On ARM64 PCI_PROBE_ONLY can *only* be set via DT, so see above

We want to get rid of PCI_PROBE_ONLY on ARM/ARM64:

For platforms that does not have UEFI BIOS, it makes sense to remove the probe only option as the firmware is not doing anything.

Quoted 8 lines

For server like arm64 platforms, the behavior should be identical to x86 world. The UEFI BIOS sets up the resources, kernel uses the resources.

Can we set this flag all the time for ACPI builds instead?

What's so special about arm64 that we can't do probe only builds and x86 can do?

Ok, let me give you a bit of background otherwise we talk at cross purposes here.

ARM and ARM64 arch code is currently forced to prevent calling:

pci_enable_resources() (eg arch/arm/kernel/bios32.c)

because, on platforms that are "PCI_PROBE_ONLY" (whatever that means), resources are neither assigned nor claimed. This works in practice but it is basically a workaround (ie the resources hierarchy is not validated at all in the kernel on PCI_PROBE_ONLY systems) and we want to get rid of that, that's what I mean by "get rid of PCI_PROBE_ONLY".

Now, how we can get rid of that plaster in pcibios_enable_device().

To do that, we must claim resources on PCI_PROBE_ONLY systems, but I know for certain Bjorn does not like the idea (I let you trawl the archives - at least he does not accept the idea of claiming resources ONLY on PCI_PROBE_ONLY systems, he thinks we should always claim resources regardless of that flag and fall-back to reassigning them in case claiming fails. That's perfectly reasonable, at least on systems with FW initializing PCI). The problem is dealing with legacy, so switching to resources claiming by default is a tad complicated, at least for testing (code is easy to implement).

So yes, on arm64 ACPI systems, regardless of PCI_PROBE_ONLY, resources must be claimed and reassigned if claiming fails (as x86), we start from fresh and we *must* do it from the beginning.

We can do that on arm64 (for ACPI - where PCI FW set-up is _supposed_ to be correct).

On other arm64 (and arm) platforms, the question is whether it is safe to claim resources or not. Remember that there are already PCI host controller drivers in the kernel (with equivalent FW set-up) so there is legacy.

Resources claiming and assignment should be managed in arch code, not in host controllers specific code, and that's the reason I complained in this RFC about the scattering of PCI_PROBE_ONLY flag checks in host drivers, it is becoming unmanageable (if useful at all on designware and rcar, I would like to know if there are PCI_PROBE_ONLY set-ups probing those host drivers).

Does it make the point clearer ?

Quoted 24 lines

Quoted 23 lines

https://patchwork.ozlabs.org/patch/545671/

so unless you really have *existing* set-ups that require it, please remove the respective checks from the host controller drivers, this is becoming a serious issue, because either:

- we claim resources if and only if PCI_PROBE_ONLY is set

Either like this (to be done for every host controllers and ARM bios32):

https://patchwork.ozlabs.org/patch/545670/

or in core ARM/ARM64 code - eg pcibios_fixup_bus() - (to avoid adding a resource claiming call in ALL PCI host controllers)

- or we *always* carry out resource claiming regardless of PCI_PROBE_ONLY (but on ARM we can't really do that since PCI FW set-up on most of the platforms is not present)

On PCI_PROBE_ONLY systems resources claiming is mandatory if we want to get rid of arches workarounds:

Quoted 2 lines

I'm hoping to see x86 like behavior on ARM64 without any gotchas as there is nothing special about CPU type when it comes to PCI.

As I said, we must enforce it with ACPI, for DT platforms I am all ears to decide how we can implement it sanely (I think the only way to do it is by claiming the PCI resources on PCI_PROBE_ONLY systems, that's not ideal but it simplifies things a lot).

Thanks,
Lorenzo

Quoted 20 lines

Quoted 13 lines

https://patchwork.ozlabs.org/patch/545671/

Comments very appreciated.

Thanks,
Lorenzo
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Signature · 3 lines

Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

Footnote: I remember reading somewhere that some BIOS want to keep track of where the endpoints are mapped. Reassigning the resources break such systems.

Quoted 6 lines · Sinan Kaya

Quoted 5 lines · Lorenzo Pieralisi

Hi,

I noticed that:

79953dd22c1d ("PCI: rcar: Remove dependency on ARM-specific struct

hw_pci")

Quoted 7 lines

Quoted 7 lines

cbce7900598c ("PCI: designware: Make driver arch-agnostic")

added code in the respective host controller drivers to size bridges and assign resources only if the PCI_PROBE_ONLY flag is clear, which makes me wonder if there exists PCI_PROBE_ONLY set-ups for the respective host controllers:

Resources claiming and assignment should be managed in arch code, not in host controllers specific code, and that's the reason I complained in this RFC about the scattering of PCI_PROBE_ONLY flag checks in host drivers, it is becoming unmanageable (if useful at all on designware and rcar, I would like to know if there are PCI_PROBE_ONLY set-ups probing those host drivers).

Does it make the point clearer ?

Quoted 20 lines

Quoted 20 lines

https://patchwork.ozlabs.org/patch/545671/

so unless you really have *existing* set-ups that require it, please remove the respective checks from the host controller drivers, this is becoming a serious issue, because either:

- we claim resources if and only if PCI_PROBE_ONLY is set

Either like this (to be done for every host controllers and ARM bios32):

https://patchwork.ozlabs.org/patch/545670/

or in core ARM/ARM64 code - eg pcibios_fixup_bus() - (to avoid adding a resource claiming call in ALL PCI host controllers)

- or we *always* carry out resource claiming regardless of PCI_PROBE_ONLY (but on ARM we can't really do that since PCI FW set-up on most of the platforms is not present)

Quoted 5 lines

Quoted 2 lines

On PCI_PROBE_ONLY systems resources claiming is mandatory if we want to get rid of arches workarounds:

I'm hoping to see x86 like behavior on ARM64 without any gotchas as there is nothing special about CPU type when it comes to PCI.

As I said, we must enforce it with ACPI, for DT platforms I am all ears to decide how we can implement it sanely (I think the only way to do it is by claiming the PCI resources on PCI_PROBE_ONLY systems, that's not ideal but it simplifies things a lot).

Thanks,
Lorenzo

Quoted 15 lines

Quoted 4 lines

https://patchwork.ozlabs.org/patch/545671/

Quoted 9 lines

Comments very appreciated.

Thanks,
Lorenzo
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 4 lines

--
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux

Foundation Collaborative Project

Quoted 1 line

Hi Lorenzo,

Quoted 15 lines · Lorenzo Pieralisi

Quoted 6 lines · Sinan Kaya

Quoted 5 lines · Lorenzo Pieralisi

Hi,

I noticed that:

79953dd22c1d ("PCI: rcar: Remove dependency on ARM-specific struct

hw_pci")

Quoted 7 lines

Quoted 7 lines

cbce7900598c ("PCI: designware: Make driver arch-agnostic")

added code in the respective host controller drivers to size bridges and assign resources only if the PCI_PROBE_ONLY flag is clear, which makes me wonder if there exists PCI_PROBE_ONLY set-ups for the respective host controllers:

<snip>

Quoted 6 lines

Resources claiming and assignment should be managed in arch code, not in host controllers specific code, and that's the reason I complained in this RFC about the scattering of PCI_PROBE_ONLY flag checks in host drivers, it is becoming unmanageable (if useful at all on designware and rcar, I would like to know if there are PCI_PROBE_ONLY set-ups probing those host drivers).

I am pretty sure there are no rcar set-ups that use PCI_PROBE_ONLY, so I am happy for that code to go.

Hi Lorenzo,

Quoted 15 lines · Lorenzo Pieralisi

Quoted 6 lines · Sinan Kaya

Quoted 5 lines · Lorenzo Pieralisi

Hi,

I noticed that:

79953dd22c1d ("PCI: rcar: Remove dependency on ARM-specific struct

hw_pci")

Quoted 7 lines

Quoted 7 lines

cbce7900598c ("PCI: designware: Make driver arch-agnostic")

added code in the respective host controller drivers to size bridges and assign resources only if the PCI_PROBE_ONLY flag is clear, which makes me wonder if there exists PCI_PROBE_ONLY set-ups for the respective host controllers:

<snip>

Quoted 6 lines

Resources claiming and assignment should be managed in arch code, not in host controllers specific code, and that's the reason I complained in this RFC about the scattering of PCI_PROBE_ONLY flag checks in host drivers, it is becoming unmanageable (if useful at all on designware and rcar, I would like to know if there are PCI_PROBE_ONLY set-ups probing those host drivers).

I am pretty sure there are no rcar set-ups that use PCI_PROBE_ONLY, so I am happy for that code to go.

Thanks
Phil

Quoted 51 lines

Does it make the point clearer ?

Quoted 20 lines

Quoted 20 lines

https://patchwork.ozlabs.org/patch/545671/

so unless you really have *existing* set-ups that require it, please remove the respective checks from the host controller drivers, this is becoming a serious issue, because either:

- we claim resources if and only if PCI_PROBE_ONLY is set

Either like this (to be done for every host controllers and ARM bios32):

https://patchwork.ozlabs.org/patch/545670/

or in core ARM/ARM64 code - eg pcibios_fixup_bus() - (to avoid adding a resource claiming call in ALL PCI host controllers)

- or we *always* carry out resource claiming regardless of PCI_PROBE_ONLY (but on ARM we can't really do that since PCI FW set-up on most of the platforms is not present)

Quoted 5 lines

Quoted 2 lines

On PCI_PROBE_ONLY systems resources claiming is mandatory if we want to get rid of arches workarounds:

I'm hoping to see x86 like behavior on ARM64 without any gotchas as there is nothing special about CPU type when it comes to PCI.

As I said, we must enforce it with ACPI, for DT platforms I am all ears to decide how we can implement it sanely (I think the only way to do it is by claiming the PCI resources on PCI_PROBE_ONLY systems, that's not ideal but it simplifies things a lot).

Thanks,
Lorenzo

Quoted 15 lines

Quoted 13 lines

https://patchwork.ozlabs.org/patch/545671/

Comments very appreciated.

Thanks,
Lorenzo
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 6 lines

Quoted 4 lines

--
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux

Foundation Collaborative Project

Quoted 1 line

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

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Lorenzo Pieralisi
Sent: 28 January 2016 17:27
To: Phil Edworthy; Pratyush Anand; Jingoo Han; Gabriele Paoloni
Cc: [email protected]; Wangzhou (B); Bjorn Helgaas; Sinan Kaya
Subject: Re: [RFC] ARM/ARM64 PCI_PROBE_ONLY platforms

[+ Pratyush, Jingoo, Gabriele]

any comment on this for the designware driver ?

From our side we (HiSilicon) do not use such flag.

Thanks,
Lorenzo

Quoted 15 lines · Phil Edworthy

Hi Lorenzo,

Quoted 12 lines · Lorenzo Pieralisi

Quoted 6 lines · Sinan Kaya

Quoted 5 lines · Lorenzo Pieralisi

Hi,

I noticed that:

79953dd22c1d ("PCI: rcar: Remove dependency on ARM-specific struct

hw_pci")

Quoted 4 lines

Quoted 4 lines

cbce7900598c ("PCI: designware: Make driver arch-agnostic")

added code in the respective host controller drivers to size bridges and assign resources only if the PCI_PROBE_ONLY flag is clear, which

makes

Quoted 12 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

me wonder if there exists PCI_PROBE_ONLY set-ups for the respective host controllers:

<snip>

Quoted 6 lines

Resources claiming and assignment should be managed in arch code, not in host controllers specific code, and that's the reason I complained in this RFC about the scattering of PCI_PROBE_ONLY flag checks in host drivers, it is becoming unmanageable (if useful at all on designware and rcar, I would like to know if there are PCI_PROBE_ONLY set-ups probing those host drivers).

Quoted 22 lines

I am pretty sure there are no rcar set-ups that use PCI_PROBE_ONLY, so I am happy for that code to go.

Thanks
Phil

Quoted 16 lines

Does it make the point clearer ?

Quoted 14 lines

Quoted 14 lines

https://patchwork.ozlabs.org/patch/545671/

so unless you really have *existing* set-ups that require it, please remove the respective checks from the host controller drivers, this is becoming a serious issue, because either:

- we claim resources if and only if PCI_PROBE_ONLY is set

Either like this (to be done for every host controllers and ARM bios32):

https://patchwork.ozlabs.org/patch/545670/

or in core ARM/ARM64 code - eg pcibios_fixup_bus() - (to avoid adding

a

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

resource claiming call in ALL PCI host controllers)

- or we *always* carry out resource claiming regardless of

PCI_PROBE_ONLY

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

(but on ARM we can't really do that since PCI FW set-up on most of

the

Quoted 18 lines

Quoted 18 lines

Quoted 7 lines

Quoted 4 lines

platforms is not present)

On PCI_PROBE_ONLY systems resources claiming is mandatory if we want to get rid of arches workarounds:

I'm hoping to see x86 like behavior on ARM64 without any gotchas as there is nothing special about CPU type when it comes to PCI.

As I said, we must enforce it with ACPI, for DT platforms I am all ears to decide how we can implement it sanely (I think the only way to do it is by claiming the PCI resources on PCI_PROBE_ONLY systems, that's not ideal but it simplifies things a lot).

Thanks,
Lorenzo

Quoted 2 lines

Quoted 2 lines

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

https://patchwork.ozlabs.org/patch/545671/

Comments very appreciated.

Thanks,
Lorenzo
--
To unsubscribe from this list: send the line "unsubscribe linux-pci"

in

Quoted 9 lines

Quoted 9 lines

Quoted 9 lines

Quoted 3 lines

the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

--
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a

Linux

Quoted 7 lines

Quoted 2 lines

Foundation Collaborative Project

Quoted 1 line

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

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

Quoted 6 lines

Resources claiming and assignment should be managed in arch code, not in host controllers specific code, and that's the reason I complained in this RFC about the scattering of PCI_PROBE_ONLY flag checks in host drivers, it is becoming unmanageable (if useful at all on designware and rcar, I would like to know if there are PCI_PROBE_ONLY set-ups probing those host drivers).

I am pretty sure there are no rcar set-ups that use PCI_PROBE_ONLY, so I am happy for that code to go.

To do that, we must claim resources on PCI_PROBE_ONLY systems, but I know for certain Bjorn does not like the idea (I let you trawl the archives - at least he does not accept the idea of claiming resources ONLY on PCI_PROBE_ONLY systems, he thinks we should always claim resources regardless of that flag and fall-back to reassigning them in case claiming fails. That's perfectly reasonable, at least on systems with FW initializing PCI). The problem is dealing with legacy, so switching to resources claiming by default is a tad complicated, at least for testing (code is easy to implement).

Quoted 9 lines · Lorenzo Pieralisi

To do that, we must claim resources on PCI_PROBE_ONLY systems, but I know for certain Bjorn does not like the idea (I let you trawl the archives - at least he does not accept the idea of claiming resources ONLY on PCI_PROBE_ONLY systems, he thinks we should always claim resources regardless of that flag and fall-back to reassigning them in case claiming fails. That's perfectly reasonable, at least on systems with FW initializing PCI). The problem is dealing with legacy, so switching to resources claiming by default is a tad complicated, at least for testing (code is easy to implement).

I'd like to think of PCI_PROBE_ONLY basically as "setting IORESOURCE_PCI_FIXED for every BAR", i.e., we can do everything we normally do *except* write to the BAR (of course we have to write to it to size the BAR during enumeration, but we have to restore the original value).

I don't think PCI_PROBE_ONLY should have anything to do with the iomem_resource and ioport_resource trees. /proc/iomem and /proc/ioports should still contain every resource we know about, regardless of whether PCI_PROBE_ONLY is set or not.

Quoted 12 lines · Bjorn Helgaas

Quoted 9 lines · Lorenzo Pieralisi

To do that, we must claim resources on PCI_PROBE_ONLY systems, but I know for certain Bjorn does not like the idea (I let you trawl the archives - at least he does not accept the idea of claiming resources ONLY on PCI_PROBE_ONLY systems, he thinks we should always claim resources regardless of that flag and fall-back to reassigning them in case claiming fails. That's perfectly reasonable, at least on systems with FW initializing PCI). The problem is dealing with legacy, so switching to resources claiming by default is a tad complicated, at least for testing (code is easy to implement).

Quoted 5 lines

I'd like to think of PCI_PROBE_ONLY basically as "setting IORESOURCE_PCI_FIXED for every BAR", i.e., we can do everything we normally do *except* write to the BAR (of course we have to write to it to size the BAR during enumeration, but we have to restore the original value).

I am honestly a bit confused about the distinction between PCI_PROBE_ONLY and "IORESOURCE_PCI_FIXED for every BAR", the more so if I read the resources assignment code, in particular:

pci_assign_resource()

in drivers/pci/setup-res.c

That function assigns the resource but does not update the BAR if IORESOURCE_PCI_FIXED is set. I wonder why the resource is assigned at all if IORESOURCE_PCI_FIXED is set, probably to initialize its parent pointer and set it, still, the value in the struct resource may differ from what's in the BAR, I am not sure I understand why we are happy with that or I am reading code the wrong way (does not this give a view of resource tree disconnected from how HW is actually programmed ?)

Quoted 2 lines · Lorenzo Pieralisi

We want to get rid of PCI_PROBE_ONLY on ARM/ARM64:

For platforms that does not have UEFI BIOS, it makes sense to remove the probe only option as the firmware is not doing anything.

For server like arm64 platforms, the behavior should be identical to x86 world.

The UEFI BIOS sets up the resources, kernel uses the resources.

Quoted 6 lines · Sinan Kaya

Quoted 2 lines · Lorenzo Pieralisi

We want to get rid of PCI_PROBE_ONLY on ARM/ARM64:

For platforms that does not have UEFI BIOS, it makes sense to remove the probe only option as the firmware is not doing anything.

I don't understand this statement. It sounds like you mean "non-UEFI BIOS firmware doesn't assign PCI BARs", but that's not true, so you must mean something else.

Quoted 3 lines

For server like arm64 platforms, the behavior should be identical to x86 world.

Quoted 1 line

The UEFI BIOS sets up the resources, kernel uses the resources.

Is there actually a requirement that a UEFI BIOS assign resources to
PCI BARs? I know that historically, x86 BIOS has set up most or all
PCI BARs. But I thought there was something in UEFI that relaxed that, so it would only have to program BARs for the boot and console devices it actually needed. But I can't find a spec reference either way.

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

Quoted 8 lines · Bjorn Helgaas

Quoted 6 lines · Sinan Kaya

Quoted 2 lines · Lorenzo Pieralisi

We want to get rid of PCI_PROBE_ONLY on ARM/ARM64:

For platforms that does not have UEFI BIOS, it makes sense to remove the probe only option as the firmware is not doing anything.

Quoted 3 lines

I don't understand this statement. It sounds like you mean "non-UEFI BIOS firmware doesn't assign PCI BARs", but that's not true, so you must mean something else.

It depends on the firmware flavor. I know u-boot does some PCI assignment but it does minimum to use PCI itself not for OS consumption. It may not deal with with switches/bridges etc. or will only assign mem32 resources and not touch prefetchable.

Most non-UEFI firmwares I have seen on ARM rely on device specific driver like synopsys etc. to do the device initialization and ask kernel to do the enumeration.

ACPI systems on the other hand handle the resource assignment before the OS starts.

Quoted 10 lines · Bjorn Helgaas

Quoted 6 lines · Sinan Kaya

Quoted 5 lines · Lorenzo Pieralisi

Quoted 2 lines

We want to get rid of PCI_PROBE_ONLY on ARM/ARM64:

For platforms that does not have UEFI BIOS, it makes sense to remove

the probe only

Quoted 2 lines

Quoted 1 line

option as the firmware is not doing anything.

Quoted 8 lines

Quoted 3 lines

I don't understand this statement. It sounds like you mean "non-UEFI BIOS firmware doesn't assign PCI BARs", but that's not true, so you must mean something else.

It depends on the firmware flavor. I know u-boot does some PCI assignment but it does minimum to use PCI itself not for OS consumption. It may not deal with with switches/bridges etc. or will only assign mem32 resources and not touch prefetchable.

Ah, I see the problem. When you wrote "non-UEFI BIOS," I thought "old-fashioned x86 BIOS," which generally do assign resources. But I don't have much experience with other firmware like U-boot. There are good reasons, e.g., portability and boot-time optimization, why firmware might not touch things it doesn't need. That's especially true for PCI resource assignment, where we know the OS must do it itself anyway, and there's little point in doing it twice.

Quoted 6 lines

Most non-UEFI firmwares I have seen on ARM rely on device specific driver like synopsys etc. to do the device initialization and ask kernel to do the enumeration.

ACPI systems on the other hand handle the resource assignment before the OS starts.

My guess is that this is more of a tradition than anything actually required by the spec.

The bottom line is that Linux can't rely on much consistency across the universe of architectures and firmwares. I think the only thing that really makes sense for us to do is:

- Read whatever assignments the firmware may have made
- Keep them unchanged if they seem sensible
- Reassign them if they aren't sensible
- Use quirks to handle exceptions

Bjorn

Quoted 6 lines

Most non-UEFI firmwares I have seen on ARM rely on device specific driver like synopsys etc. to do the device initialization and ask kernel to do the enumeration.

ACPI systems on the other hand handle the resource assignment before the OS starts.

My guess is that this is more of a tradition than anything actually required by the spec.

The bottom line is that Linux can't rely on much consistency across the universe of architectures and firmwares. I think the only thing that really makes sense for us to do is:

- Read whatever assignments the firmware may have made
- Keep them unchanged if they seem sensible

- Reassign them if they aren't sensible

On Sat, Jan 30, 2016 at 07:30:27AM -0600, Bjorn Helgaas wrote:

[...]

Quoted 9 lines

Quoted 6 lines

Most non-UEFI firmwares I have seen on ARM rely on device specific driver like synopsys etc. to do the device initialization and ask kernel to do the enumeration.

ACPI systems on the other hand handle the resource assignment before the OS starts.

My guess is that this is more of a tradition than anything actually required by the spec.

I share your opinion, and that tradition on ARM64 should be built on top of existing DT based systems where the bootloader assigns *NOTHING* in 90% of designs.

That's why I want to see resource claiming carried out by default on ACPI on ARM64, this would foster the tradition :), hopefully.

Quoted 4 lines

The bottom line is that Linux can't rely on much consistency across the universe of architectures and firmwares. I think the only thing that really makes sense for us to do is:

Quoted 2 lines

- Read whatever assignments the firmware may have made
- Keep them unchanged if they seem sensible

Here I take "sensible" as "it can be successfully claimed" - ie the resource is allocated in a valid way, though it may not be optimal (eg bridge window apertures).