On Fri, Jul 11, 2014 at 11:09 AM, Yinghai Lu <yinghai@xxxxxxxxxx> wrote:
>
> If the BAR have all 0, cpu can not access it as hw will forward access to ram
> controller according to routing table.
On PC's, yes (also likely with many devices - there are definitely
devices out there were setting the BAR to zero disables it).
On other platforms? Not necessarily at all, and some devices have no
way of disabling the BAR (even clearing the IO/MEM bits in the
control/status register does *not* necessarily disable things like
root bridge BARs). I'm pretty sure we had it actually happen (I'd like
to say "Powerpc", but I wouldn't really bet on it)
Anyway, the rule is that "r->flags = 0" means that it doesn't exist.
And that rule makes sense, and is completely unambiguous. Relying on
the BAR _value_ being zero is bogus and wrong.
Probing that finds a valid BAR, but an unassigned one, will set the
UNSET bit. Plus IORESOURCE_MEM or IO should also always be set for a
valid bar. So a value of zero really is completely unambiguous - it
does not exist. It's not unassigned, it really isn't there.
Of course, it's possible that we get this wrong, and initial probing
will obviously start out with a zero value, so there is clearly one
valid situation where we go from "does not exist" to something else,
but in general, "r->flags == 0" really is special.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
