Re: [RFC] ARM/ARM64 PCI_PROBE_ONLY platforms

[Bjorn Helgaas <helgaas@kernel.org>]

On Mon, Feb 01, 2016 at 03:25:07PM +0000, Lorenzo Pieralisi wrote:
> On Sat, Jan 30, 2016 at 07:30:27AM -0600, Bjorn Helgaas wrote:
> 
> [...]
> 
> > > 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.
> 
> > 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
> 
> 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).

Yes.  But even if platforms assign resources in a way they can be
successfully claimed, I don't think platforms should rely on that
assignment being unchanged.  For example, even if the boot-time
configuration is valid, the kernel may need to move things around to
deal with hotplug.  I know we don't really do that today, but I think
we should be able to do it in principle.

Bjorn