linux-kernel - Re: [PATCHv4 1/4] usb: Provide usb_speed

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:	Mon, 22 Aug 2011 21:42:35 +0200
From:	"Michal Nazarewicz" <mina86@...a86.com>
To:	"Alan Stern" <stern@...land.harvard.edu>
Cc:	"Felipe Balbi" <balbi@...com>,
	"Sebastian Andrzej Siewior" <bigeasy@...utronix.de>,
	"Yang Rui Rui" <ruirui.r.yang@...to.com>,
	"Dave Young" <hidave.darkstar@...il.com>,
	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCHv4 1/4] usb: Provide usb_speed_string() function

On Mon, 22 Aug 2011 19:28:46 +0200, Alan Stern <stern@...land.harvard.edu>  
wrote:

> On Mon, 22 Aug 2011, Michal Nazarewicz wrote:
>
>> From: Michal Nazarewicz <mina86@...a86.com>
>>
>> In a few places in the kernel, the code prints
>> a human-readable USB device speed (eg. "high speed").
>> This involves a switch statement sometimes wrapped
>> around in ({ ... }) block leading to code repetition.
>>
>> To mitigate this issue, this commit introduces
>> usb_speed_string() function, which returns
>> a human-readable name of provided speed.
>>
>> It also changes a few places switch was used to use
>> this new function.  This changes a bit the way the
>> speed is printed in few instances at the same time
>> standardising it.
>
>> --- a/drivers/usb/Makefile
>> +++ b/drivers/usb/Makefile
>> @@ -51,3 +51,6 @@ obj-$(CONFIG_USB_MUSB_HDRC)	+= musb/
>>  obj-$(CONFIG_USB_RENESAS_USBHS)	+= renesas_usbhs/
>>  obj-$(CONFIG_USB_OTG_UTILS)	+= otg/
>>  obj-$(CONFIG_USB_GADGET)	+= gadget/
>> +
>> +obj-$(CONFIG_USB)		+= common.o
>> +obj-$(CONFIG_USB_GADGET)	+= common.o
>
> Will this cause problems?  For example, what if CONFIG_USB is Y and
> CONFIG_USB_GADGET is M?

Hmm, I haven't thought about that.

> Also, it seems a little silly to have an entire kernel module devoted
> to a single, little function.

Agreed.  And again, I haven't thought about compiling as a module which
would result in a major overkill.

> This is a symptom of the difficulty of
> sharing code between the host-side and gadget-side USB stacks.

Agreed.

I'm open to any suggestions on how this could be solved.

Sticking the function to the header file as static inline seems
like bit... ”bloaty”.

If this is not easily solvable, I'll probably just drop this patch
for now.

-- 
Best regards,                                         _     _
.o. | Liege of Serenely Enlightened Majesty of      o' \,=./ `o
..o | Computer Science,  Michal "mina86" Nazarewicz    (o o)
ooo +-----<email/xmpp: mnazarewicz@...gle.com>-----ooO--(_)--Ooo--
--
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/