[PATCH v3 2/3] ARM: bios32: use pci_enable_resource to enable PCI resources

[will.deacon@arm.com (Will Deacon)]

Hi Jason, Bjorn,

Thanks for the comments.

On Fri, Feb 21, 2014 at 12:36:19AM +0000, Jason Gunthorpe wrote:
> On Thu, Feb 20, 2014 at 12:39:16PM -0700, Bjorn Helgaas wrote:
> > > Damn, I just found a problem with this patch when PCI_PROBE_ONLY is set.
> > >
> > > The problem is that bios32.c won't create a resource hierarchy for the
> > > firmware-initialised resources, so we have a bunch of orphaned resources
> > > that we can't pass to pci_enable_resources (since it checks r->parent).
> > >
> > > This means that, unless firmware *enables* all of the resources, Linux won't
> > > be able to enable them. I think this is stronger than simply not
> > > re-assigning devices like the PCI_PROBE_ONLY flag intends.
> > 
> > By "firmware enabling resources," do you mean firmware assigning
> > addresses in the BARs and turning on the PCI_COMMAND_MEMORY (or _IO)
> > bits?
> > 
> > I'd like to make the generic code ignore BAR values if
> > PCI_COMMAND_MEMORY (or _IO) is cleared.  When those bits are cleared,
> > I don't think there's a good way to determine whether the address in a
> > BAR is valid.
> 
> I think this is pretty smart, PROBE_ONLY really should mean
> 'everything is perfect, do not touch it' and if the device isn't
> enabled, well.. It isn't enabled, the firmware should have done it.

Yes, that's one (sane) interpretation of the PROBE_ONLY flag and I'm happy
to run with it if we all agree. We'll need some extra code paths to assign
disabled resources when PROBE_ONLY is passed, but that can come later.

> Will, this if for kvmtool right? Keeping the patch as is and instead
> changing kvmtool to enable the devices seems like a good option?

Sure, I can do that easily enough. I just wanted to make sure that we agree
on PROBE_ONLY before I start hacking kvmtool. I'll drop this additional
patch.

Cheers,

Will