On Wed, Feb 27, 2008 at 1:47 AM, John W. Linville
<linville@tuxdriver.com> wrote:
Is there any reason the ssb driver should claim the bcm43xx pci ids in
the first place? I have very little understanding what the Sonic Silicon
Backplane really is, but I see that the b44 driver claims its PCI ids
directly. I also think I understand why the b43/b43legacy drivers can't
claim the ids directly: because the driver-device matching is done not
with the pci bus methods, but with the ssb bus methods, and it would
be impossible to automatically choose the right driver for the right
device (with same ssb ids), as the first of the two drivers loaded would
succeed in probe()'ing the pci "ssb bridge" device, and not letting the
other to take control, even after moments later the ssb probe for the
non-supported ssb device would fail. (Or am I completely wrong?)
That said, I still think that the ssb driver claims the wrong pci ids,
which is especially wrong if the the b43/b43legacy drivers are not
even built. And my patch fixes exactly this problem - the ssb driver
no more claims the broadcom pci ids, when the b43/b43legacy drivers
are not built.
One better solution I think might be to move the b43_pci_bridge.c
code to a separate module, and let the b43/b43legacy drivers
depend on it, but as I said, I have little knowledge in the
ssb stuff, so I did it the easy way.
Btw, at least in the 8139cp/8139too case the right driver is
chosen automatically, because they both can detect
the problem at the pci probe() time and tell the device
is not supported early.
--
