Subject: Re: USB stack needs early review (Re: Someone should fix our USB stack...)
To: None <M.Drochner@fz-juelich.de>
From: Cherry G. Mathew <cherry.g.mathew@gmail.com>
List: tech-kern
Date: 04/09/2007 22:45:24
On 3/19/07, Matthias Drochner <M.Drochner@fz-juelich.de> wrote:
>
> 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
>
>

Updating to current ( April 08 ) fixed this problem. I have no idea
how it got fixed. Maybe you new autoconf interface commits ? In any
case, it works great. Thanks!


-- 
~Cherry