On Thu, May 18, 2017 at 05:51:44PM +0100, Ard Biesheuvel wrote: > On 18 May 2017 at 16:47, Lorenzo Pieralisi <lorenzo.pieralisi@xxxxxxx> 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? 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
