Am Donnerstag, 4. Juni 2009 23:38:48 schrieb Alan Stern:
> > The problem with that is that it is a difference in behavior to the sync
> > versions. It violates the principle of least surprise.
>
> We could convert the field to atomic_t; it wouldn't bother anyone.
> However it is worthwhile mentioning that this behavior of the async
> routines _is_ documented in Documentation/usb/power-management.txt.
Sure. But had I read documentation, I couldn't be surprised ;-)
> By the way, what is your application? And doesn't it turn out that you
> naturally want to hold a private lock during these calls anyway?
I am looking at usbnet. And it turns out that I don't want locking.
That's what it looks like now. I suspect you want locking in character
devices and drivers that reuse URB(s).
If you have flow control in an upper layer and free completed URBs
I suspect locking is an unnecessary complication.
You are looking at the serial layer too often. It makes you think locking
is natural here ;-)
Regards
Oliver
static void tx_complete (struct urb *urb)
{
struct sk_buff *skb = (struct sk_buff *) urb->context;
struct skb_data *entry = (struct skb_data *) skb->cb;
struct usbnet *dev = entry->dev;
if (urb->status == 0) {
dev->stats.tx_packets++;
dev->stats.tx_bytes += entry->length;
usb_autopm_put_interface_async(dev->intf);
} else {
dev->stats.tx_errors++;
switch (urb->status) {
case -EPIPE:
/* we do not allow autosuspension */
usbnet_defer_kevent (dev, EVENT_TX_HALT);
break;
/* software-driven interface shutdown */
case -ECONNRESET: // async unlink
case -ESHUTDOWN: // hardware gone
usb_autopm_put_interface_async(dev->intf);
break;
--
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
