> Looks bad. I went through the code, and I discovered that indeed,
> usb_add_hcd() calls driver->reset() before anything else, that is,
> before giving the low level driver a chance to initialize it's local
> data structure, including the spinlock. On EHCI, at least, reset will
> dive deep into the guts of the driver tying among others to acquire the
> lock.

The last step of the misnamed ehci "reset" routine calls ehci_init()
to set up the HCD data structures ... which is well after the comment
saying "below this point it's all PCI-specific", and in particular it's
after the call to ehci_pci_reinit() which implicitly requires that init
to have been done already.  I'll be testing the attached patch, which
moves that data structure init up above that relevant line.

I think I see why I've not been seeing this problem though.  The
machines I can use for testing lately don't have per-port power
switching with EHCI ... so this particular codepath doesn't trigger.

 
> That is very bad. It's yet another example of broken "mid-layer" design.
> I can't say enough how bad this whole mid-layer hcd stuff is but you
> guys don't beleive it.

You _could_ get down off that hobby-horse, Ben.  In this case the issue
has nothing to do with how the hcd glue works, or doesn't.  :)

We've been slowly refactoring things to make them better.  Given that
it needs to be done while not breaking *lots of stuff* it goes slowly.
And the fact that we've been having to fill in some significant missing
pieces while we do that has also made it go slowly.


> So what you should do to fix the immediate problem is to have a separate
> "init" callback to the low level driver to initialize it's private data
> structure before anything else is called. A kind of "constructor". Call
> that from usb_add_hcd() before you call reset().

As of 2.6.15 I think the "reset" semantics have been entirely re-whacked;
we may well change the "reset" method name to match.  Not all the code
or comments have caught up to those changes yet.  The PCI devices are now
always using the "early usb handoff" logic, but the non-PCI devices need
some updates...

But there's a related point, that usb_add_hcd() sequences things in a
pretty strange order.  For one thing, the root hub isn't created at
the time that misnamed reset/init/setup routine is called ... which
means that one-time root hub customization must be done elsewhere, in
some routine that's not for one-time setup.  Of course I have a patch
for that; but that calls for a bit more testing.

- Dave