arm64: acpi/pci: allow the firmware BAR configuration to be preserved
Get series with b4
b4 am 20170518174612.GA31373@red-moonVersions newest first
- v1 Latest0 of 2 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 2 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [PATCH 0/2] arm64: acpi/pci: allow the firmware BAR configuration to be preserved
Quoted 40 lines · Ard Biesheuvel
Quoted 39 lines · Lorenzo Pieralisi
On Thu, May 18, 2017 at 04:10:28PM +0100, Ard Biesheuvel wrote:
[...]
Quoted 13 lines
Quoted 6 lines
Quoted 5 lines
Re
_DSM: I think it makes sense to honour it, because it puts the allocation under the control of the firmware, which completely removes the burden of having to reason about a policy in the kernel. That leaves the question which will be the default, but that is of minor importance IMO.Quoted 6 lines
I agree; we should try to follow the spec unless we have a good reason not to, which argues for honoring the
_DSM, so I think it's worth a try. Booting with "pci=realloc" could override the_DSMand taint the kernel (because we don't know the effect of reassigning something the firmware told us not to touch).Quoted 3 lines
I'd like to hear Lorenzo's view on this first, but I can certainly respin my
_DSMpatch to take pci=realloc into account, and move the handling to generic code as well.I agree with both of you on
_DSMimplementation and interpretation.Now, if we use it correctly (ie by the FW standard) on ARM64 systems we are going to trigger regressions, that's certain (ie we can then boot with pci=realloc - still, we are breaking systems), that's the reason why for patch(2) I'd like to create a branch and send a CFT for ARM64 ACPI testing before queuing it (either I can set-up a testing branch or we ask Bjorn to do it - as you guys prefer - as long as we have a branch for people to test patch(2) on ARM64 ACPI systems).
You still need to assign resources that could not be claimed though so patch(2) still needs updating:
PCI FW spec 3.1 - 4.6.5
"...However, the operating system is free to configure the devices in this hierarchy that have not been configured by the firmware."
Quoted 8 lines
Quoted 3 lines
Which in kernel-speak it means that you have to assign resources that could not be claimed.
Right. AFAICT this is the part that is typically handled by
pcibios_resource_survey()et al, whose default__weakimplementations are empty functions. Shall I override those for arm64 to host this logic?
I think it makes sense yes unless Bjorn spots something wrong with that but you should also call it in ARM64 pci_acpi_scan_root() since it is not called by PCI core on non-hot-added bridges, I reckon you figured that out already though.
Thanks a lot !
Lorenzo