hselasky@c2i.net said:
> The only solution I see is that  we change the USB API

I've been doubtful about big USB API changes for some
reasons:
-source compatibility with the other BSDs
-potential breakage due to many changes to drivers working
 around weak abstraction barriers in the existing API
-limited chances to get test coverage for some hardware

However, after I've looked for ways to implement power
management in a clean way, I'm beginning to change my mind.
We need a way to suspend an (interrupt/isochronous) pipe
while leaving the bookkeeping for it in place. Rather than
hacking this into the existing API it would be much cleaner
to separate the pipe allocation from enqueuing it for
transfers. (Actually, we could save a lot of code duplication
if we extended that concept so that all pipes for an interface
were handled with one API call.)

IIRC (it is admittedly a while ago that I looked at your code)
your patches aim into the same direction.
I should have another look...

cherry.g.mathew@gmail.com said:
> uhub3: port 2, device disappeared after reset
> uhub0: port 2, set config at addr 2 failed
> uhub0: device problem, disabling port 2 
> Would this possibly be fixed by the new code ?

As I understand, this is unlikely because the port handling
is quite seperate from pipe/transfer stuff.
Which NetBSD version is this? (I'm using a mouse on a
USB2 system all the time as probably others do as well,
but this is a low speed device.)

> Any pointers on where to start debugging ?

As a first try, you might increase the delays in the
path, and it might be useful to print the UHCI_PORTSCx
register at various points. What chipset is it?
(The code dealing with the PORTSC on UHCI needs
review. The resume handling is completely broken.)

best regards
Matthias