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
