U-Boot allocating PCI I/O space from 0 (Was: pata_sl82c105 can not reserve IO region)

[Sergei Shtylyov]

Hello.

Benjamin Herrenschmidt wrote:

>>I don't think that is the problem. pci_request_regions() handles all
>>this internally. It is incorrect for me to not request BAR 5
>>if present as nobody else should use that resource with my driver loaded.

>>The underlying problem appears to be that PPC64 isn't setting up the
>>resources properly (at least as viewed by the pci core code). If a
>>resource is not set up then pci_request_resource() correctly handles
>>it .. except on PPC64. You have a resource at zero with a length and
>>type. PPC64 is not reporting to the upper layers that the resource was
>>not allocated. It is reporting that the resource *was* allocated, and at a
>>bogus address of zero.

>>If you trust the firmware that is fine, but you need to report the truth,
>>at which point pci_request_resources() will work correctly.

> We don't have a choice but to trust the firmware on those machines. We
> can't assign things ourselves on most of them for various reasons (in
> many cases, the hypervisor won't let us).

> So you suggest that I clear resource->flags in that case ?

> I think part of the problem is a firmware bug in that the firmware data
> actually decodes to BAR 5 is assigned to address 0 ... I suppose we can
> consider that address 0 is never valid on those machines and consider
> that as unassigned but it's a bit dodgy.. Or maybe a PCI quirk in the
> pSeries code would be best.

    Well, I'm having a very related issue with the U-Boot on MPC85xx: recently 
I've noticed that it started allocating PCI I/O space from 0 (while the older 
versions started from 0x1000). The IDE core can't tolerate this, giving me 
such messages on bootup:

PDC20269: inconsistent baseregs (BIOS) for port 0, skipping

when I have Promise Ultra133TX2 card inserted into PCI alone. I've looked thru 
the U-Boot sources and commit history but failed to locate the change that led 
to this...

WBR, Sergei