linux-kernel - Re: [PATCH] usb: also announce bcdDevice

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] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 05 May 2012 17:09:06 +0200
From:	Martin Mokrejs <mmokrejs@...d.natur.cuni.cz>
To:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
CC:	Paul Bolle <pebolle@...cali.nl>, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] usb: also announce bcdDevice

Greg Kroah-Hartman wrote:
> On Sat, May 05, 2012 at 02:14:43PM +0200, Martin Mokrejs wrote:
>> Paul Bolle wrote:
>>> Currently announce_device() does print the idVendor and idProduct values
>>> but does not print the bcdDevice value. USB devices are accurately
>>> identified by all three values. See, for instance, the USB storage
>>> quirks which will only apply for a certain (range of) bcdDevice
>>> value(s). So it seems useful to also print bcdDevice when announcing USB
>>> devices.
>>
>> Could it also report negotiated speed? full-speed, high-speed, super-speed?
> 
> All of this, including the bcdDevice, can be found in sysfs.  So I don't
> want to take this patch, otherwise we would be just adding more and more
> to the kernel log.
> 
> If you programatically want to find this out, use libudev or listen to
> the dbus messages for new devices, don't watch the kernel log messages.

Hmm, but when you go through your syslog/dmesg lines especially in case of
USB devices which you swap in and out quite often, it is too late to lookup
some file elsewhere which relates to *current* device. The information
is lost already if you changed device meanwhile. You just realize USB disk
disconnected but you have not way find out except from the log files what
speed did it use. In case of USB3 devices capable of lower speeds it is
quite important. Some just claim USB3 capabilities (on the package box)
but in real, always end up at high-speed only.

For me testing several USB disks, USB to SATA bridges, host controllers,
kernel command-lines ... it is way to much work. Having the USB debug
enabled, especially XHCI_HCD_DEBUG gives on the other had too much output
for daily use but as this is all stuff prone to fail somewhere and at some
point I keep it enabled.

I don't think it clutters syslog nor that it adds significant extra size
to the output. It would save people from enabling debug just because of this.
And no, average linux user never never lookup sysfs nor use libudev, really.
Still, the link speed is of interest to everybody fiddling with the stuff
and wondering why the damn thing is so slow or why did it disconnect. It gives
an answer or at least a hint.

And if it is not enough to identify a device based on idVendor and idProduct
but one needs also bcdDevice, why not to print it?

Thanks,
Martin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/