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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <BY1PR0301MB0855ACDA4337AE3FC7F616E081EF0@BY1PR0301MB0855.namprd03.prod.outlook.com>
Date:	Tue, 21 Apr 2015 06:04:39 +0000
From:	Peter Chen <Peter.Chen@...escale.com>
To:	Roger Quadros <rogerq@...com>
CC:	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
	"balbi@...com" <balbi@...com>,
	"stern@...land.harvard.edu" <stern@...land.harvard.edu>,
	"dan.j.williams@...el.com" <dan.j.williams@...el.com>,
	"Jun.Li@...escale.com" <Jun.Li@...escale.com>,
	"mathias.nyman@...ux.intel.com" <mathias.nyman@...ux.intel.com>,
	"tony@...mide.com" <tony@...mide.com>,
	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>,
	"macpaul@...il.com" <macpaul@...il.com>
Subject: RE: [RFC][PATCH v2 00/13] USB: OTG/DRD Core functionality

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

Ok, let's put this patch set in mainline first, since your patch set may need some
information from it.
 
> > - 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.
> 

Since "dr_mode" has been widely used now, if we add a new property for it,  we
need to change all drivers.

Your OTG/DRD framework needs to (partial) use otg fsm, and we will not teach old
driver to use it since there are some driver related stuffs.

SRP/HNP/ADP support can be board level capabilities, and we may consider the
otg device which does not support otg fsm (hardware finishes fsm). So I suggest
we have below properties at dts:

- otg-support /* fully otg support */
- otg-fsm-support /* fully otg fsm support */
- otg-ver /* eh & otg supplement version */
- adp-support /* board adp support */ 
- srp-support /* board srp support */
- hnp-support /* board hnp support */

Currently, if CONFIG_USB_OTG and CONFIG_USB_OTG_FSM are enabled, we will
have otg fsm code (usb-otg-fsm.c).

if (otg-support & otg-fsm-support)
	this device has fully otg support, and will follow full otg fsm transitions. 
else
	this device is drd, and will follow simple otg fsm transtions. 

Peter

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