linux-kernel - Re: [RFC][PATCH v2 00/13] USB: OTG/DRD Core functionality

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 20 Apr 2015 10:28:12 +0300
From:	Roger Quadros <rogerq@...com>
To:	Peter Chen <peter.chen@...escale.com>
CC:	<gregkh@...uxfoundation.org>, <balbi@...com>,
	<stern@...land.harvard.edu>, <dan.j.williams@...el.com>,
	<jun.li@...escale.com>, <mathias.nyman@...ux.intel.com>,
	<tony@...mide.com>, <linux-usb@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <linux-omap@...r.kernel.org>,
	<macpaul@...il.com>
Subject: Re: [RFC][PATCH v2 00/13] USB: OTG/DRD Core functionality

Hi Peter,

On 20/04/15 06:05, Peter Chen wrote:
> On Tue, Apr 14, 2015 at 01:41:47PM +0300, Roger Quadros wrote:
>> This is an attempt to centralize OTG/Dual-role functionality in the kernel.
>> As of now I've got Dual-role functionality working pretty reliably on
>> dra7-evm. xhci side of things for OTG/DRD use are fixed in
>> http://thread.gmane.org/gmane.linux.kernel/1923161
> 
> Hi Roger,
> 
> Currently, there are two main problems for DRD/OTG framework.
> 
> - For multi-platform supports, we may define CONFIG_USB_OTG, but the
> gadget should not add its otg descriptor to its configuration
> descriptors if it does not support one of otg features (SRP/HNP/ADP).
> Macpaul Lin's patch set [1] is the right way to do it.

Agreed. That check (whether OTG descriptor can be added and which version
of it) has to be done at runtime and it must be added only if hardware
supports OTG _and_ kernel OTG support is enabled.

> - We are lack of framework to handle OTG (DRD) switch, it is great you
> are designing it. The main problem for this framework is how to handle
> DRD/OTG FSM unify. My thought is we add two paths for them separate.
> For easy, I suggest if the platform supports one of otg features, then
> it goes to fully otg fsm, else it goes to simply otg fsm (like your drd 
> fsm). If you agree with it too, you may not need to add another "dr_mode"
> value.

It would be nice that way but unfortunately it does't work in all cases.
e.g. What if the SoC itself supports all OTG features but the board is not
designed for OTG. Or the product designer simply is not interested in full OTG
support but just dual-role. So we need some flexibility for the
device tree/platform-data to specify that. This is where a new
"dr_mode" == "dual-role" is needed.

cheers,
-roger

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