WANTED: someone who knows what exactly that ssb thingy is intended/used for
stefan.bader at canonical.com
Fri Jul 10 13:08:09 BST 2009
Matthew Garrett wrote:
> On Wed, Jul 08, 2009 at 06:20:30PM +0200, Stefan Bader wrote:
>> thank you for this explanation. Interestingly, from experiments, the wl driver
>> module works without the ssb module being loaded. My explanation is that the
>> ssb driver binds to all supported pci devices. So it either does handle this
>> internally or it does not need to explicitly address the ssb.
> Each PCI broadcom device has its own PCI->SSB bridge. By default, the
> ssb driver will bind to all the ssb devices available. If wl is loaded
> first then wl will claim the b43 PCI->SSB bridge. ssb will no longer be
> able to bind to that PCI device, but if loaded later will succeed in
> binding to the b44 PCI->SSB bridge.
What looks a bit strange to me is that for the b44 case, it is the driver that
matches by pci id and loads ssb as it depends on it. The b44 driver has one
modalias to the ssb bus but three more that match on the pci bus. So ssb does
not bind to all broadcom devices.
On the other hand the b43 driver has only aliases for the ssb bus. None which
would match against the 4328 device (obviously, the driver needs to get support
> The optimal solution to this is to implement support for the LP and
> N-phys in the b43 driver. The alternative is to fiddle with load order -
> that'll involve working out some way to enforce entries appearing
> earlier in the module mapping files.
This is what is done in the end (doing some modprobe rules to un- and reload
the b44 part after loading the wl driver). The whole issue was just me
wondering why there is the ssb driver matching for the pci device but nothing
else is happening apart from that. It would not be my first case of re-using
the same pci id for two different devices.
But knowing the background, well ok, at least I know why this twiddling is
When all other means of communication fail, try words!
More information about the kernel-team