On 11/25/2013 04:44 AM, Alan Stern wrote:
On Mon, 25 Nov 2013, Xenia Ragiadakou wrote:
On 11/25/2013 01:50 AM, Xenia Ragiadakou wrote:
[snip]
Also, while you're going through the whole remove-and-add procedure for
endpoints that aren't halted, do you want to hold the bandwidth mutex?
If the procedure isn't atomic, there's a possibility that some other
device could change configs in the middle. This would also prevent
concurrent altsetting changes.
Yes, i need to lock the bandwidth_mutex. I will fix this.
Alan Stern
After i looked at it more carefully, there will be a deadlock if i try
to aqcuire the bandwidth_mutex in reset endpoint code.
In usb_set_configuration(), the bandwidth_mutex is held while
usb_enable_interface() is called for each interface and
usb_enable_interface() will attempt to reset the endpoints via
usb_enable_endpoint() since the 3rd argument is set to true.
So, I think it's not a good idea to try to lock the bandwidth_mutex
given that, right?
Right. We don't have to worry about config changes anyway, because the
config can't be changed until all the old endpoints are disabled. You
just have to make sure that an endpoint can't be disabled until a
pending reset is finished.
Alan Stern
Actually, xhci driver does not implement endpoint_disable(). So, how can
I force the disable not to be finished until the pending reset is
finished? The only way i see is by implementing endpoint_disable()
callback for xhci. Do you have something else in mind maybe?
Also, probably there was an implementation for it,
xhci_endpoint_disable(), but it seems to have been reverted. I just saw
this function name to appear in a comment in xhci_add_endpoint().
thanks,
ksenia
--
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
