> While the subject is in the air, how about device resets? They can be
> initiated by a driver bound to any interface, but they affect the whole
> device.
A sore spot.
> I don't know enough about how the core handles resets... the device needs
> to be re-configured (USB address assigned, etc.), but that doesn't
> necessarily imply the creation of a new device structure. In fact, it
> would make sense to keep the old structure, avoid re-enumeration, and
> re-assign the same address as before the reset. Is that how it works now?
Yes, the reset code itself is good. The implications are not understood.
> But there has to be a way to inform drivers about it. The current
> approach is extremely ad-hoc: the driver that requested the reset is
> responsible for calling disconnect() followed by probe() for all the
> interfaces on the device. That's got two problems: it decentralizes
> something that ought to reside in the core, and it's too extreme.
> Resetting should not cause a hot-unplug event followed by a hot-plug, for
> example -- since we _know_ that it is the same device before and after.
> But that's just what would happen in the usb-storage driver, e.g.
You should find my configuration change patch in the archives. I can't send
you it right now. It's not on this laptop's drive. It should fix the issue.
But there's just no other suitable primitive than disconnect()/probe()
right now. Furthermore the locking requirements are interessting.
The approach to do disconnect()/probe() is solidity. For things like
hubs you have hardly an other option.
> The approach that seems most logical to me is to define another entry
> point for USB device drivers. This entry point should be called by the
> core whenever a device bound to the driver is reset. The driver can then
> decide what to do: maybe re-initialize the device, maybe do nothing.
That's not enough. Telling a driver that it's data just sent has gone to the
bit bucket is not nice. You need to warn it beforehand and give indication
that it's safe afterwards.
The closest thing would be suspend/resume.
Regards
Oliver
-------------------------------------------------------
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
