On Thu, Mar 30, 2000, Matthew Dharm <[EMAIL PROTECTED]> wrote:
> On Thu, 30 Mar 2000, Johannes Erdfelt wrote:
>
> > I haven't tested the code (not even tried compiling it), but I think it
> > should work. I know the above code won't work on a root hub (it'll
> > oops).
>
> Hrm... we'll need a solution that works on root hubs, also.
It'll work on devices connected to a root hub (I think), but it won't
work on a root hub itself since there is no parent (dev->parent is
NULL).
What are you plans for resetting the root hub?
> > The device should disconnect and then reconnect. This will cause it to
> > go through the normal connect and disconnect code paths. This means that
> > dev, after calling the function is invalid.
>
> Will this disconnect and reconnect be serialized? Transactions which go
> through hubs are serialized, so I expect so. But I've been wrong before,
> so I want to ask explicitly.
Yeah, it'll go through the normal code path which is pretty much
serialized right now (only non case is the remove HC path).
I have a patch that truly serializes everything. (Rebuilding some of my
patches after my development system corrupted some of my sources, grr)
> Also, will the disconnect and reconnect occur before the function returns?
> Just the disconnect? Neither?
Dunno. It's a race condition. I'd suggest being done with the device
structure before calling the function.
> > usb_set_port_feature is part of hub.c (declared static) so you may want
> > to throw the function in hub.c and export the symbol from there.
>
> Probably a good idea. Or, perhaps it could go into usb.c -- tho in either
> case it winds up in the core module.
You could put it in usb.c, but you'd have to play with prototypes, etc.
JE
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
