linux-kernel - RE: [PATCH 5/5 v5] usb:gadget: Add SuperSpeed support to the Gadget Framework

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: <000601cbed28$aee4dc20$0cae9460$@org>
Date:	Mon, 28 Mar 2011 11:15:26 +0200
From:	"Tanya Brokhman" <tlinder@...eaurora.org>
To:	<balbi@...com>
Cc:	<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 5/5 v5] usb:gadget: Add SuperSpeed support to the Gadget Framework

Hi
 
> > I believe that in the future all gadget drivers will define their own
> SS
> > descriptors with values that are suitable for that gadget driver and
> the
> > create_ss_descriptors() will become obsolete. As I've already
> mentioned this
> > is just a way to allow all the existing drivers to operate in SS mode
> with
> > minimum changes to their code. So this patch doesn't contradict your
> > approach, just extends it.
> 
> but that's not a good approach. You're adding bloat which will be
> removed soon. Problem is that once it's there, we will have to support
> it for a long long time as we won't know if there are any out of tree
> gadget drivers depending on that, forcing us on publising of
> Documentation/feature-removal-schedule.txt that we will remove that
> layer in e.g. 4 major revisions. So, IMHO, better not to add it.
> 

I see your point. I'll generate a different patch for this function
(create_ss_descriptors()) so it will be easy to take it out of the patch
series if we eventually decide against it. I think it's still useful to have
this ability since it can help developers at the beginning even if not
adding it to the formal kernel release and just have it in the mailing list
archives.

Best regards,
Tanya Brokhman
Consultant for Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum





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