WANTED: someone who knows what exactly that ssb thingy is intended/used for

[Stefan Bader]

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 
for it).

> 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 
necessary.


-- 

When all other means of communication fail, try words!