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]
Message-ID: <20110522105908.GA26607@linutronix.de>
Date:	Sun, 22 May 2011 12:59:08 +0200
From:	Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To:	Tanya Brokhman <tlinder@...eaurora.org>
Cc:	greg@...ah.com, linux-usb@...r.kernel.org, balbi@...com,
	ablay@...eaurora.org, linux-arm-msm@...r.kernel.org,
	'open list' <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v11 4/7] usb:gadget: Add SuperSpeed support to the
 Gadget Framework

* Tanya Brokhman | 2011-05-22 10:20:42 [+0300]:

>Hi Sebastian
Hi Tanya,

>> >+	usb_ext = (struct usb_ext_cap_descriptor *)
>> cdev->req->buf is (void *) so you can skip that cast.
>> 
>> >+			(cdev->req->buf+bos->wTotalLength);
>> a space between + please. bos->wTotalLength is le16 so you can't simply
>> do that way.
>> 
>> What about something like
>> 
>>   usb_ext = (struct usb_ext_cap_descriptor *)(bos + 1)
>> 
>> ?
>
>Added the spaces and the le16_to_cpu(bos->wTotalLength). 
>It seems clearer to me to leave it as 
>	usb_ext = cdev->req->buf + le16_to_cpu(bos->wTotalLength);
>if that's ok with you.
Yes it is.

>
>> >@@ -499,6 +633,9 @@ static int set_config(struct usb_composite_dev
>> *cdev,
>> > 		case USB_SPEED_LOW:	speed = "low"; break;
>> > 		case USB_SPEED_FULL:	speed = "full"; break;
>> > 		case USB_SPEED_HIGH:	speed = "high"; break;
>> >+		case USB_SPEED_SUPER:
>> >+			speed = "super";
>> >+			break;
>> 
>> This is not my favorite style either but please do it the way the other
>> three are done.
>
>Well here is the dilemma: if I do it the other tree were done - I get
>checkpatch error. 
>You're right, adding this the way it's above doesn't look too good but when
>I fixed the other three I was asked not to do so in this patch, which also
>makes sense since it has nothing to do with SS support...
>So what do I do? Submit with a checkpatch error?

It is nice to have things consistent and a follow-up patch could fix the
checkpatch error(s).

>
>

Sebastian
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ