[PATCH 0/2] arm64: acpi/pci: allow the firmware BAR configuration to be preserved
Ard Biesheuvel
ard.biesheuvel at linaro.org
Thu May 18 09:51:44 PDT 2017
On 18 May 2017 at 16:47, Lorenzo Pieralisi <lorenzo.pieralisi at arm.com> wrote:
> On Thu, May 18, 2017 at 04:10:28PM +0100, Ard Biesheuvel wrote:
>
> [...]
>
>> >> 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.
>> >
>> > 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 _DSM and taint the
>> > kernel (because we don't know the effect of reassigning something the
>> > firmware told us not to touch).
>> >
>>
>> I'd like to hear Lorenzo's view on this first, but I can certainly
>> respin my _DSM patch to take pci=realloc into account, and move the
>> handling to generic code as well.
>
> I agree with both of you on _DSM implementation 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."
>
> 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 __weak implementations
are empty functions. Shall I override those for arm64 to host this
logic?
More information about the linux-arm-kernel
mailing list