On 06/22/2011 05:19 PM, Felipe Balbi wrote:
Hi,
On Wed, Jun 22, 2011 at 11:02:27AM -0400, Alan Stern wrote:
No, the patch is appropriate.
Indeed.
We don't need better communication. If g_mass_storage (for example)
knows that the device is in use, it can block suspends by returning
-EBUSY from its own suspend callback. The UDC driver doesn't need to
worry about these matters; it should assume that such things have
already been handled elsewhere. That's what Dmitry meant when he was
talking about a "higher level driver" -- maybe "lower level" would have
been a better choice of words. :-)
The suspend at driver level should not care about filesystem in use, etc
... A disconnected cable cannot be prevented by the kernel, and the
effect in fine is the same as the suspend.
Until recently, ordering of the suspend callbacks didn't present any
problem. The gadget device was a child of the UDC device and therefore
its suspend callback would always be invoked first.
With the new UDC framework, I don't know if this is true any more.
It's something to consider.
That true also for the UDC driver, which should be suspended before the
transciever, so that it can complete its shutdown properly.
That's what bothers me with the patch.
And we should not confuse the 2 suspends :
(1) driver suspend, which happens at suspendToRam or suspendToDisk
(the one we're discussing here)
(2) USB suspend (which if I remember correctly is a special USB
command while the USB bus remains powered).
The order of suspend in (1) requires :
- gadget (gzero, gether, ...) suspended first
- UDC suspended second
- transceiver suspended last
The order of suspend in (2) doesn't require anything AFAIR.
For order in (1) :
- gadget before UDC should be enforced by the framework, as the UDC
usb_gadget_probe_driver() method calls device_add() on the gadget<
- UDC before transceiver is enforced in some drivers by directly
manipulating the gpio line.
So Dimitry, do you have an idea as how to guarantee order of suspend in
(1), between UDC driver and gpio_vbus ? Maybe an otg_*() call would do
the trick ?
Cheers.
--
Robert
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
