On Sat, 8 Jan 2011, Kevin D. Kissell wrote:
> > With the Bonito I'd have assumed it was some low-level PCI code rewrite
> > -- that seem to keep happening over and over again -- that missed a bit in
> > the Bonito driver or the driver altogether. With the Bonito core cards
> > limited to the MIPS 20Kc core and some exotic (for the Malta) QED CPU
> > options that would be no surprise at all to me.
> I don't think it's a "classic" Bonito, YAMON calls out:
> MIPS SOC-it 101 OCP / 1.3 SDR-FW-1:1
If it doesn't say "Bonito", then it's not a Bonito. ;)
I've had a peek at the driver and I bet it's related to the "PCI iomap"
thing. The PCNet32 driver doesn't use it and goes for the traditional
direct inw()/outw()/etc. approach. I haven't been following the relevant
discussions, so I can't say offhand whether PCI iomap has become mandatory
now or not, but what I think is happening is that inw()/outw()/etc. no
longer reach the PCI port I/O space from the driver on your system by
Now the other driver presumably does use PCI iomap and when it
initialises, it maps a piece of PCI port I/O space somewhere in the
virtual address space (or initialises a KSEG/XKPHYS mapping in kernel's
structures) making inw()/outw()/etc. see it. And given due to PC/AT
legacy PCI port I/O space ranges requested are typically small (256
contiguous bytes are the guaranteed maximum on PC/AT-compatible systems),
one MMU page spans more than one (as does obviously a kernel segment)
making the other driver's mapping inadvertently valid for this driver too.
This in turn magically makes it work.
Note, while a plausible explanation, this is a pure guess on my side. If
it is indeed valid, then where the bug lies will depend on whether PCI
iomap has become mandatory or not.