netdev - Re: [patch v2] net/usb: remove err() messages in few drivers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Wed, 14 Jan 2009 09:09:43 +0100
From:	Oliver Neukum <oliver@...kum.org>
To:	"Alexey Klimov" <klimov.linux@...il.com>
Cc:	"David Brownell" <david-b@...bell.net>, davem@...emloft.net,
	"Greg KH" <greg@...ah.com>, netdev@...r.kernel.org,
	linux-usb@...r.kernel.org
Subject: Re: [patch v2] net/usb: remove err() messages in few drivers

Am Wednesday 14 January 2009 01:22:26 schrieb Alexey Klimov:
> > Use the interface passed into probe():  dev_err(&intf->dev, ...) etc

A USB driver is fundamentally a driver for a device's interfaces.
Therefore the interface's device struct is the obviously correct choice.

> Well, in few v4l-dvb drivers successfully used &radio->usbdev->dev in
> debug messages and that doesn't look wrong.

That will not allow you to identify which interface caused the message.

> Hmm, i see that struct usb_interface passed to probe function for
> example, and here in catc_irq_done struct urb passed, and then we have
> struct catc. So, messages based on catc->usbdev->dev. I can switch to
> &catc->netdev->dev when it's safe to do, right?

You cannot. The point of passing a device pointer is to identify the device.
The device in the network view and the USB view is not identical. You
have to pick one choice and stick with it and if for some reason that is not
possible you cannot use this debugging functions.

	Regards
		Oliver
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html