> Date: Tue, 10 Nov 2015 20:28:24 +0000
> From: Miod Vallat <[email protected]>
>
> > The SDHC on this machine comes with a 64-bit BAR, so we need to fix
> > that XXX. I did change the error handling a bit such that we give up
> > after the first unmappable BAR. It seems multi-slot controllers are
> > rare and it is questionable whether higher numbered slots work if we
> > can't properly configure a lower numbered slot.
> >
> > ok?
>
> I agree with the intent, but your diff will cause the loop to exit for
> any mapping error or if an I/O BAR is found - could the latter occur on
> some systems?
The Simplified SD Host Controller Specification specifies that the
BARs are "mapped to memory space". So if an I/O BAR is found, the
device does not conform to the specification. But it also indicates
that bit 07-01 should be hardwired to 0. So it doesn't allow 64-bit
memory BARs either. But perhaps there is an update of the SD Host
Controller Specification that does allow this. The AMD controller
claims to conform to the standard since its interface code is set to
01.
There is no reason why an I/O BAR couln't work with our driver since
bus_space(9) nicely abstracts away the differences. But I don't
really expect to see devices that have one.
> I'd rather see something like this:
>
> for (... ; ...; reg += span) {
> if (pci_mapreg_probe() fails)
> break; /* because there is nothing better we can do */
>
> if (type == PCI_MAPREG_TYPE_IO)
> span = 4;
> else
> span = type & PCI_MAPREG_MEM_TYPE_64BIT ? 8 : 4;
>
> ...
> }
