[lkml]   [2005]   [Mar]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] USB: usbnet uses netif_msg_*() ethtool filtering
On Wednesday 30 March 2005 4:30 pm, Jeff Garzik wrote:
> Linux Kernel Mailing List wrote:
> > ChangeSet 1.2181.4.72, 2005/03/24 15:31:29-08:00,
> >
> > [PATCH] USB: usbnet uses netif_msg_*() ethtool filtering
> >
> > This converts most of the usbnet code to actually use the ethtool
> > message flags. The ASIX code is left untouched, since there are
> > a bunch of patches pending there ... that's where the remaining
> > handful of "sparse -Wbitwise" warnings come from.
> >
> > Signed-off-by: David Brownell <>
> > Signed-off-by: Greg Kroah-Hartman <>
> It would be nice if people at least CC'd me on net driver patches.

Sorry. When drivers fit multiple classifications (e.g. USB _and_ NET,
or USB _and_ PCI _and_ PM, etc) it's unfortunately routine that not all
interested parties see them until something hits LKML. Even when the
changes have significant cross-subsystem impact (these don't).

> netfi_msg_ifdown() is only for __interface__ up/down events; as such,
> there should be only one message of this type in dev->open(), and one
> message of this type in dev->stop().

I was going by the only writeup I've ever seen, which doesn't mention
such a rule at all. The messages you highlighted are compatible with
these rules: the interface is actually going down at that point.

If there are other rules, they belong in Documentation/netif-msg.txt
don't they? That way folk won't be forced to guess. Or risk
accidentally following the "wrong" set of rules...

> > @@ -3044,7 +3047,7 @@
> >
> > memset(urb->transfer_buffer, 0, urb->transfer_buffer_length);
> > status = usb_submit_urb (urb, GFP_ATOMIC);
> > - if (status != 0)
> > + if (status != 0 && netif_msg_timer (dev))
> > deverr(dev, "intr resubmit --> %d", status);
> > }
> >
> this looks more like a debugging message?

It's an error of the "what do I do now??" variety, triggered by
what's effectively a timer callback. USB interrupt transfers
are polled by the host controller according to a schedule that's
maintained by the HCD.

- Dave

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-04-06 13:31    [W:0.061 / U:9.868 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site