linux-kernel - Re: [PATCH 2/5 v6] usb: Add usb_endpoint_descriptor to be part of the struct usb

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:	Mon, 11 Apr 2011 16:39:30 +0200
From:	Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To:	Felipe Balbi <balbi@...com>
Cc:	Tanya Brokhman <tlinder@...eaurora.org>, gregkh@...e.de,
	linux-arm-msm@...r.kernel.org, ablay@...eaurora.org,
	"'open list:USB GADGET/PERIPH...'" <linux-usb@...r.kernel.org>,
	'open list' <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/5 v6] usb: Add usb_endpoint_descriptor to be part of
 the struct usb_ep

* Felipe Balbi | 2011-03-28 11:46:25 [+0300]:

>> Could you please share you concerns? Even if they are not strong arguments
>> :).
>> Our pros for this change were that it seems more accurate that the EP
>> descriptor will be handled by the composite layer and not the FDs. Thus we
>> tried to spare the FD from saving the chosen EP descriptor and passing it to
>> different functions.
>> This change is needed for our algorithm of SS implementation in the later
>> patches in this series. 
>
>Yes, I understood that much, but it's useful for UDCs to access the EP
>descriptor (ok, we can still access it by dereferencing ep) since we can
>(actually we need to) use that to let the HW know about max packet
>sizes, endpoint types, etc etc.
>
>Also, I'm not sure composite.c should know the details about the
>endpoint. That's just a thin layer implementing the more generic part
>(standard usb requests, handling, helpers for finding endpoints, etc),
>but the one who should look into endpoint descriptors is the underlying
>controller code for the reasons I listed above.
>
>That's my feeling...

If I look at the diffstat between patch 2 and 4 I see 
| 30 files changed, 299 insertions(+), 393 deletions(-)

So she got rid of almost 100 lines. While looking at the code it seems
that every gadget driver does the same thing which is now done in one
place. I like that so far :)

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/