SSB Bus: Need advice representing 2 devices in a core (BCM5354 USB2.0 core)

[Steve Brown <sbrown@cortland.com>]

I'm posting to this list because I think this is basically a ssb bus 
issue. If it doesn't belong here, where should I go?

The USB 2.0 core in the BCM5354 is both a OHCI & EHCI device. I now have 
a OHCI & EHCI driver. The former is essentially the current ohci-ssb.c 
w/ a dma mask fix and the latter I derived from ohci-ssb and ehci-pci. 
Either one, but not both, will attach to the USB 2.0 core and mostly work.

1. Multiple devices per core

The ssb bus code seems to expect only one device per core. I modified 
drivers/ssb/scan.c to add an additional identical device in the case of 
the USB 2.0 core.  However, once a driver binds to one device, the other 
seems to no longer be available either. When the second driver loads, 
ssb_bus_match never sees the second device. I haven't figured out what's 
happening yet.

I also considered modifying drivers/ssb/scan.c to add a phony additional 
core/device for SSB_DEV_USB20_HOST and then add that phony core to the 
OHCI device list. But, this seems really ugly.

2. Avoiding multiple core initializations

I also need a way to determine if the core is already enabled, as I 
can't initialize it more than once. The initialization gets done in the 
probe code in ohci-ssb and ehci-ssb.  The first one loaded does that and 
the second driver needs to skip the initialization. Does the following 
look like a safe test for a reset core?

(ssb_read32(dev, SSB_TMSLOW) & SSB_TMSLOW_RESET)

As ssb_enable always first resets the core, maybe this test isn't always 
reliable. If it isn't, should I just add a flag to the ssb_device 
structure that follows ssb_enable/ssb_disable?

Any suggestions are appreciated. As I'm probably less than qualified to 
be doing this, I'll accept that as advice as well.

Steve