On Thu, 29 Jul 2004, David Brownell wrote:
> > Our work on the hub driver is well on its way to getting hopelessly
> > tangled. Should we try to coordinate the changes we've been sending in
> > independently?
>
> This looked OK to me with respect to RC2 and to what's in Greg's tree
> (except for some "endpoint_running" detritus in Greg's tree), so I'm
> not quite sure what you mean.
I'm referring to patches as338 and as340b, which I sent to Greg a few
weeks ago but he hasn't applied yet.
> > Why do you want to use locktree() in hub_events() and
> > usb_reset_device()?
>
> Because of what it protects: everything downstream of that
> port, against use of those types of signaling. And that main
> khubd entry point certainly uses that kind of signaling, as
> do usb_{reset,suspend,resume}_device(), so they've all
> got to use the same locking.
So you would delay someone from resetting a device while a hub upstream of
that device gets a connect-change event on an unrelated port? And you
would delay khubd from handling a port change event on a hub while the
/proc/bus/usb/devices code is running on that bus?
I realize that these delays would be minimal, but I don't see any reason
for imposing them at all. And I don't understand what you mean by "that
kind of signaling". Making usb_reset_device() use locktree won't protect
any downstream devices; instead it will prevent someone from resetting the
device while an upstream hub is locked. Likewise for khubd.
> > The FIXME comments added to hub_port_disable() and hub_port_init()
> > are misleading, because disconnect() would run into trouble if
> > called from within usb_reset_device(). At one point I considered
> > doing the same thing but decided against it for that reason.
>
> Point is: when is disconnect() getting called? There are several
> paths where devices get marked as gone, but they never actually
> get disconnected. I don't care when it's called, but it shouldn't
> be too much later ...
They _do_ get disconnected later on. Or rather, the devices that have
already been through usb_new_device() get disconnected. And it's not all
that much later; it's as soon as khubd can wake up and process the
virtual-disconnect notification.
> > Rather than fretting too much about unbinding drivers that don't
> > support suspend(), one could improve things a lot right now by
> > adding suspend/resume support to the HID driver.
>
> That won't address usb-storage, or any of the other drivers, though.
> (I tried to suspend my Swiss Army Knife USB-key, and it misbehaved
> rudely during suspend since something kept probing it through SCSI.
Really? Exactly how did it misbehave? Numerous SCSI errors showing up in
your system log?
> Though it came back on resume, unlike HID.) Meanwhile we **KNOW**
> every USB driver probe()/disconnect() cycle is basically working now,
> so that the USB parts of the problem have a simple solution.
>
> Thing is, I think we want to go from where we are to an environment
> where USB suspend behaves _without_ having to change every single
> last driver both in-tree and external. Implementing suspend() and
> resume() callbacks should be just to add value; drivers without them
> don't need to act broken.
That's all true; however it's got to be easier to add suspend/resume to
the HID driver than to fix up the driver-model core. Quicker, anyway.
And adding suspend/resume support to usb-storage will also be very easy.
> Plus, I don't think anyone can seriously argue that it's reasonable for
> the driver model PM code to self-deadlock so readily.
Of course not. Evidently the designers didn't take into account the need
for a callback routine to make a separate nontrivial call into the driver
core.
Alan Stern
-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
