[PATCH v2 00/22] usb gadget update for OTG 2.0

[PATCH v2 00/22] usb gadget update for OTG 2.0

[Li Jun]

Changes for v2:
- Use zero-length array as Peter Chen suggested to support usb_otg_descriptors
  with different size.
- Add a new property otg-rev to specify the OTG release number with which the
  device is compliant.
- Add a new interfate usb_otg_descriptor_add() to allocate and init usb_otg_descriptor
  according to gadget otg options, for those do not use new otg options, keep
  the usb_otg_descriptor setting unchanged.
- Remove static usb_otg_descriptor definitions in all legacy gadget driver, but
  use usb_otg_descriptor_add to handle it while build usb configurations.
- Handle usb_otg_descriptor through usb_otg_descriptor_add and add it in each usb
  configurations for configfs driver.

This is a follow-up of Macpaul Lin's previous patchset to resolve usb gadget driver
working with OTG 2.0, and set otg features by not only usb driver config but also usb
hardware property in DT, main changes:
1. keep one usb_otg_descriptor definition, add bcdOTG by zero-length array, which
   can be passed via device tree.
2. OTG features(SRP/HNP/ADP) can be decided by combination of usb HW properties and
   USB driver config.
3. Change the chipidea usb driver to use the updated mechanism.
4. Init usb_otg_descriptor according to otg options in each gadget driver.

Li Jun (18):
  doc: dt-binding: usb: add otg related properties
  usb: common: add API to get usb otg features from device tree
  usb: chipidea: udc: set usb gadeget's otg config
  usb: chipidea: update ci_otg_is_fsm_mode conditions
  usb: gadget: add usb_otg_descriptor_add interface to init
    usb_otg_descriptor
  usb: gadget: configfs: init and add usb_otg_descriptor for usb
    configurations
  usb: gadget: ether: init usb_otg_descriptor via usb_otg_descriptor_add
  usb: gadget: acm_ms: init usb_otg_descriptor via
    usb_otg_descriptor_add
  usb: gadget: audio: init usb_otg_descriptor via usb_otg_descriptor_add
  usb: gadget: cdc2: init usb_otg_descriptor via usb_otg_descriptor_add
  usb: gadget: g_ffs: init usb_otg_descriptor via usb_otg_descriptor_add
  usb: gadget: hid: init usb_otg_descriptor via usb_otg_descriptor_add
  usb: gadget: mass_storage: init usb_otg_descriptor via
    usb_otg_descriptor_add
  usb: gadget: multi: init usb_otg_descriptor via usb_otg_descriptor_add
  usb: gadget: ncm: init usb_otg_descriptor via usb_otg_descriptor_add
  usb: gadget: printer: init usb_otg_descriptor via
    usb_otg_descriptor_add
  usb: gadget: serial: init usb_otg_descriptor via
    usb_otg_descriptor_add
  usb: gadget: zero: init usb_otg_descriptor via usb_otg_descriptor_add

Macpaul Lin (4):
  usb: add OTG version number in usb_otg_descriptor
  usb: add USB_OTG_ADP definition
  usb: add OTG feature options to gadget structure.
  usb: gadget: composite: add USB_DT_OTG request handling

 Documentation/devicetree/bindings/usb/generic.txt | 10 ++++
 drivers/usb/chipidea/ci.h                         |  3 +-
 drivers/usb/chipidea/core.c                       | 16 ++++++
 drivers/usb/chipidea/debug.c                      |  1 +
 drivers/usb/chipidea/udc.c                        | 20 ++++++-
 drivers/usb/common/common.c                       | 64 +++++++++++++++++++++++
 drivers/usb/gadget/composite.c                    | 21 ++++++++
 drivers/usb/gadget/config.c                       | 37 +++++++++++++
 drivers/usb/gadget/configfs.c                     | 26 +++++----
 drivers/usb/gadget/legacy/acm_ms.c                | 26 ++++-----
 drivers/usb/gadget/legacy/audio.c                 | 25 ++++-----
 drivers/usb/gadget/legacy/cdc2.c                  | 26 ++++-----
 drivers/usb/gadget/legacy/ether.c                 | 32 +++++++-----
 drivers/usb/gadget/legacy/g_ffs.c                 | 26 ++++-----
 drivers/usb/gadget/legacy/hid.c                   | 27 +++++-----
 drivers/usb/gadget/legacy/mass_storage.c          | 26 ++++-----
 drivers/usb/gadget/legacy/multi.c                 | 33 ++++++------
 drivers/usb/gadget/legacy/ncm.c                   | 25 ++++-----
 drivers/usb/gadget/legacy/printer.c               | 22 ++++----
 drivers/usb/gadget/legacy/serial.c                | 26 +++++----
 drivers/usb/gadget/legacy/zero.c                  | 25 ++++-----
 include/linux/usb/chipidea.h                      |  4 ++
 include/linux/usb/gadget.h                        | 12 +++++
 include/linux/usb/of.h                            | 20 +++++++
 include/uapi/linux/usb/ch9.h                      |  7 ++-
 25 files changed, 377 insertions(+), 183 deletions(-)

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 01/22] usb: add OTG version number in usb_otg_descriptor

[Li Jun]

From: Macpaul Lin <macpaul-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

OTG 2.0 introduces bcdOTG to identify the OTG and EH supplement release
number with which the OTG device is compliant, so adds it for
usb_otg_descriptor.

Signed-off-by: Macpaul Lin <macpaul-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Signed-off-by: Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
---
 include/uapi/linux/usb/ch9.h | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/include/uapi/linux/usb/ch9.h b/include/uapi/linux/usb/ch9.h
index aa33fd1..ce405fb 100644
--- a/include/uapi/linux/usb/ch9.h
+++ b/include/uapi/linux/usb/ch9.h
@@ -665,13 +665,17 @@ struct usb_qualifier_descriptor {
 
 
 /*-------------------------------------------------------------------------*/
+struct bcdOTG {
+	__le16 bcdOTG;
+};
 
-/* USB_DT_OTG (from OTG 1.0a supplement) */
+/* USB_DT_OTG */
 struct usb_otg_descriptor {
 	__u8  bLength;
 	__u8  bDescriptorType;
 
 	__u8  bmAttributes;	/* support for HNP, SRP, etc */
+	struct bcdOTG otg_rev[0];
 } __attribute__ ((packed));
 
 /* from usb_otg_descriptor.bmAttributes */
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 01/22] usb: add OTG version number in usb_otg_descriptor

[Roger Quadros]

Hi,

On Mon, 8 Jun 2015 23:01:56 +0800
Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:

> From: Macpaul Lin <macpaul-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> 
> OTG 2.0 introduces bcdOTG to identify the OTG and EH supplement release
> number with which the OTG device is compliant, so adds it for
> usb_otg_descriptor.
> 
> Signed-off-by: Macpaul Lin <macpaul-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Signed-off-by: Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> ---
>  include/uapi/linux/usb/ch9.h | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/include/uapi/linux/usb/ch9.h b/include/uapi/linux/usb/ch9.h
> index aa33fd1..ce405fb 100644
> --- a/include/uapi/linux/usb/ch9.h
> +++ b/include/uapi/linux/usb/ch9.h
> @@ -665,13 +665,17 @@ struct usb_qualifier_descriptor {
>  
>  
>  /*-------------------------------------------------------------------------*/
> +struct bcdOTG {
> +	__le16 bcdOTG;
> +};
>  
> -/* USB_DT_OTG (from OTG 1.0a supplement) */
> +/* USB_DT_OTG */
>  struct usb_otg_descriptor {
>  	__u8  bLength;
>  	__u8  bDescriptorType;
>  
>  	__u8  bmAttributes;	/* support for HNP, SRP, etc */
> +	struct bcdOTG otg_rev[0];
>  } __attribute__ ((packed));

This change by itself breaks existing users that depend
on sizeof(struct usb_otg_descriptor) and are USB OTG v1.0 compliant.

For otg v1.0 length of otg descriptor is 3
for otg v2.0 it is 5.

>  
>  /* from usb_otg_descriptor.bmAttributes */

cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 01/22] usb: add OTG version number in usb_otg_descriptor

[Roger Quadros]

On Mon, 8 Jun 2015 23:01:56 +0800
Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:

> From: Macpaul Lin <macpaul-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> 
> OTG 2.0 introduces bcdOTG to identify the OTG and EH supplement release
> number with which the OTG device is compliant, so adds it for
> usb_otg_descriptor.
> 
> Signed-off-by: Macpaul Lin <macpaul-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Signed-off-by: Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> ---
>  include/uapi/linux/usb/ch9.h | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/include/uapi/linux/usb/ch9.h b/include/uapi/linux/usb/ch9.h
> index aa33fd1..ce405fb 100644
> --- a/include/uapi/linux/usb/ch9.h
> +++ b/include/uapi/linux/usb/ch9.h
> @@ -665,13 +665,17 @@ struct usb_qualifier_descriptor {
>  
>  
>  /*-------------------------------------------------------------------------*/
> +struct bcdOTG {
> +	__le16 bcdOTG;
> +};
>  
> -/* USB_DT_OTG (from OTG 1.0a supplement) */
> +/* USB_DT_OTG */
>  struct usb_otg_descriptor {
>  	__u8  bLength;
>  	__u8  bDescriptorType;
>  
>  	__u8  bmAttributes;	/* support for HNP, SRP, etc */
> +	struct bcdOTG otg_rev[0];

why not just __le16 bcdOTG here ?

>  } __attribute__ ((packed));
>  
>  /* from usb_otg_descriptor.bmAttributes */

cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 01/22] usb: add OTG version number in usb_otg_descriptor

[Li Jun]

On Tue, Jun 09, 2015 at 03:56:44PM +0300, Roger Quadros wrote:
> 
> 
> On Mon, 8 Jun 2015 23:01:56 +0800
> Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> 
> > From: Macpaul Lin <macpaul-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > 
> > OTG 2.0 introduces bcdOTG to identify the OTG and EH supplement release
> > number with which the OTG device is compliant, so adds it for
> > usb_otg_descriptor.
> > 
> > Signed-off-by: Macpaul Lin <macpaul-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > Signed-off-by: Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> > ---
> >  include/uapi/linux/usb/ch9.h | 6 +++++-
> >  1 file changed, 5 insertions(+), 1 deletion(-)
> > 
> > diff --git a/include/uapi/linux/usb/ch9.h b/include/uapi/linux/usb/ch9.h
> > index aa33fd1..ce405fb 100644
> > --- a/include/uapi/linux/usb/ch9.h
> > +++ b/include/uapi/linux/usb/ch9.h
> > @@ -665,13 +665,17 @@ struct usb_qualifier_descriptor {
> >  
> >  
> >  /*-------------------------------------------------------------------------*/
> > +struct bcdOTG {
> > +	__le16 bcdOTG;
> > +};
> >  
> > -/* USB_DT_OTG (from OTG 1.0a supplement) */
> > +/* USB_DT_OTG */
> >  struct usb_otg_descriptor {
> >  	__u8  bLength;
> >  	__u8  bDescriptorType;
> >  
> >  	__u8  bmAttributes;	/* support for HNP, SRP, etc */
> > +	struct bcdOTG otg_rev[0];
> 
> why not just __le16 bcdOTG here ?

usb_otg_descriptor of OTG 1.0 and 2.0 have different size, if directly add
__le16 bcdOTG here, then it cannot used for OTG 1.0.
I use a zero length array as Peter suggested here for bcdOTG, then the size
of usb_otg_descriptor is still 3(not 5), which is compliant with OTG 1.x, if OTG
2.0 or later, we can use member of otg_rev to add bcdOTG, then the size
of usb_otg_descriptor + bcdOTG will be 5, in one word, I want to use existing
usb_otg_descriptor struct to cover both OTG 1.x and 2.0

Li Jun
> 
> >  } __attribute__ ((packed));
> >  
> >  /* from usb_otg_descriptor.bmAttributes */
> 
> cheers,
> -roger
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 01/22] usb: add OTG version number in usb_otg_descriptor

[Alan Stern]

On Tue, 9 Jun 2015, Li Jun wrote:

> > > -/* USB_DT_OTG (from OTG 1.0a supplement) */
> > > +/* USB_DT_OTG */
> > >  struct usb_otg_descriptor {
> > >  	__u8  bLength;
> > >  	__u8  bDescriptorType;
> > >  
> > >  	__u8  bmAttributes;	/* support for HNP, SRP, etc */
> > > +	struct bcdOTG otg_rev[0];
> > 
> > why not just __le16 bcdOTG here ?
> 
> usb_otg_descriptor of OTG 1.0 and 2.0 have different size, if directly add
> __le16 bcdOTG here, then it cannot used for OTG 1.0.
> I use a zero length array as Peter suggested here for bcdOTG, then the size
> of usb_otg_descriptor is still 3(not 5), which is compliant with OTG 1.x, if OTG
> 2.0 or later, we can use member of otg_rev to add bcdOTG, then the size
> of usb_otg_descriptor + bcdOTG will be 5, in one word, I want to use existing
> usb_otg_descriptor struct to cover both OTG 1.x and 2.0

In the end, you may find it is simpler to use two different 
structures: usb_otg_descriptor and usb_otg_20_descriptor.  
Try it and see.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 01/22] usb: add OTG version number in usb_otg_descriptor

[Roger Quadros]

On Tue, 9 Jun 2015 10:16:23 -0400
Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org> wrote:

> On Tue, 9 Jun 2015, Li Jun wrote:
> 
> > > > -/* USB_DT_OTG (from OTG 1.0a supplement) */
> > > > +/* USB_DT_OTG */
> > > >  struct usb_otg_descriptor {
> > > >  	__u8  bLength;
> > > >  	__u8  bDescriptorType;
> > > >  
> > > >  	__u8  bmAttributes;	/* support for HNP, SRP, etc */
> > > > +	struct bcdOTG otg_rev[0];
> > > 
> > > why not just __le16 bcdOTG here ?
> > 
> > usb_otg_descriptor of OTG 1.0 and 2.0 have different size, if directly add
> > __le16 bcdOTG here, then it cannot used for OTG 1.0.
> > I use a zero length array as Peter suggested here for bcdOTG, then the size
> > of usb_otg_descriptor is still 3(not 5), which is compliant with OTG 1.x, if OTG

where does the memory for the zero length array pointer get allocated then?

> > 2.0 or later, we can use member of otg_rev to add bcdOTG, then the size
> > of usb_otg_descriptor + bcdOTG will be 5, in one word, I want to use existing
> > usb_otg_descriptor struct to cover both OTG 1.x and 2.0
> 
> In the end, you may find it is simpler to use two different 
> structures: usb_otg_descriptor and usb_otg_20_descriptor.  
> Try it and see.
> 

cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 01/22] usb: add OTG version number in usb_otg_descriptor

[Li Jun]

On Tue, Jun 09, 2015 at 10:16:23AM -0400, Alan Stern wrote:
> On Tue, 9 Jun 2015, Li Jun wrote:
> 
> > > > -/* USB_DT_OTG (from OTG 1.0a supplement) */
> > > > +/* USB_DT_OTG */
> > > >  struct usb_otg_descriptor {
> > > >  	__u8  bLength;
> > > >  	__u8  bDescriptorType;
> > > >  
> > > >  	__u8  bmAttributes;	/* support for HNP, SRP, etc */
> > > > +	struct bcdOTG otg_rev[0];
> > > 
> > > why not just __le16 bcdOTG here ?
> > 
> > usb_otg_descriptor of OTG 1.0 and 2.0 have different size, if directly add
> > __le16 bcdOTG here, then it cannot used for OTG 1.0.
> > I use a zero length array as Peter suggested here for bcdOTG, then the size
> > of usb_otg_descriptor is still 3(not 5), which is compliant with OTG 1.x, if OTG
> > 2.0 or later, we can use member of otg_rev to add bcdOTG, then the size
> > of usb_otg_descriptor + bcdOTG will be 5, in one word, I want to use existing
> > usb_otg_descriptor struct to cover both OTG 1.x and 2.0
> 
> In the end, you may find it is simpler to use two different 
> structures: usb_otg_descriptor and usb_otg_20_descriptor.  
> Try it and see.

That should be, I will try your suggested approach, thanks.

Li Jun
> 
> Alan Stern
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 02/22] usb: add USB_OTG_ADP definition

[Li Jun]

From: Macpaul Lin <macpaul-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

Add USB_OTG_ADP definition for usb_otg_descriptor.bmAttributes.

Signed-off-by: Macpaul Lin <macpaul-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Signed-off-by: Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Acked-by: Peter Chen <peter.chen-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
---
 include/uapi/linux/usb/ch9.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/uapi/linux/usb/ch9.h b/include/uapi/linux/usb/ch9.h
index ce405fb..70938c2 100644
--- a/include/uapi/linux/usb/ch9.h
+++ b/include/uapi/linux/usb/ch9.h
@@ -681,6 +681,7 @@ struct usb_otg_descriptor {
 /* from usb_otg_descriptor.bmAttributes */
 #define USB_OTG_SRP		(1 << 0)
 #define USB_OTG_HNP		(1 << 1)	/* swap host/device roles */
+#define USB_OTG_ADP		(1 << 2)	/* support ADP */
 
 /*-------------------------------------------------------------------------*/
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 03/22] usb: add OTG feature options to gadget structure.

[Li Jun]

From: Macpaul Lin <macpaul-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

Add ADP, HNP and SRP feature options and otg version to gadget structure.

Signed-off-by: Macpaul Lin <macpaul-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Signed-off-by: Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
---
 include/linux/usb/gadget.h | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index 4f3dfb7..2f4f39c 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -514,6 +514,12 @@ struct usb_gadget_ops {
  * @sg_supported: true if we can handle scatter-gather
  * @is_otg: True if the USB device port uses a Mini-AB jack, so that the
  *	gadget driver must provide a USB OTG descriptor.
+ * @adp_support: OTG device feature flag, indicating that the device
+	supports ADP at this port.
+ * @hnp_support: OTG device feature flag, indicating that the device
+	supports HNP at this port.
+ * @srp_support: OTG device feature flag, indicating that the device
+	supports SRP at this port.
  * @is_a_peripheral: False unless is_otg, the "A" end of a USB cable
  *	is in the Mini-AB jack, and HNP has been used to switch roles
  *	so that the "A" device currently acts as A-Peripheral, not A-Host.
@@ -526,6 +532,7 @@ struct usb_gadget_ops {
  * @quirk_ep_out_aligned_size: epout requires buffer size to be aligned to
  *	MaxPacketSize.
  * @is_selfpowered: if the gadget is self-powered.
+ * @otg_rev: The OTG reversion number the device is compliant to.
  *
  * Gadgets have a mostly-portable "gadget driver" implementing device
  * functions, handling all usb configurations and interfaces.  Gadget
@@ -562,12 +569,16 @@ struct usb_gadget {
 
 	unsigned			sg_supported:1;
 	unsigned			is_otg:1;
+	unsigned			adp_support:1;
+	unsigned			hnp_support:1;
+	unsigned			srp_support:1;
 	unsigned			is_a_peripheral:1;
 	unsigned			b_hnp_enable:1;
 	unsigned			a_hnp_support:1;
 	unsigned			a_alt_hnp_support:1;
 	unsigned			quirk_ep_out_aligned_size:1;
 	unsigned			is_selfpowered:1;
+	unsigned			otg_rev;
 };
 #define work_to_gadget(w)	(container_of((w), struct usb_gadget, work))
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 03/22] usb: add OTG feature options to gadget structure.

[Roger Quadros]

On Mon, 8 Jun 2015 23:01:58 +0800
Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:

> From: Macpaul Lin <macpaul-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> 
> Add ADP, HNP and SRP feature options and otg version to gadget structure.
> 
> Signed-off-by: Macpaul Lin <macpaul-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Signed-off-by: Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> ---
>  include/linux/usb/gadget.h | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
> index 4f3dfb7..2f4f39c 100644
> --- a/include/linux/usb/gadget.h
> +++ b/include/linux/usb/gadget.h
> @@ -514,6 +514,12 @@ struct usb_gadget_ops {
>   * @sg_supported: true if we can handle scatter-gather
>   * @is_otg: True if the USB device port uses a Mini-AB jack, so that the
>   *	gadget driver must provide a USB OTG descriptor.
> + * @adp_support: OTG device feature flag, indicating that the device
> +	supports ADP at this port.
> + * @hnp_support: OTG device feature flag, indicating that the device
> +	supports HNP at this port.
> + * @srp_support: OTG device feature flag, indicating that the device
> +	supports SRP at this port.
>   * @is_a_peripheral: False unless is_otg, the "A" end of a USB cable
>   *	is in the Mini-AB jack, and HNP has been used to switch roles
>   *	so that the "A" device currently acts as A-Peripheral, not A-Host.
> @@ -526,6 +532,7 @@ struct usb_gadget_ops {
>   * @quirk_ep_out_aligned_size: epout requires buffer size to be aligned to
>   *	MaxPacketSize.
>   * @is_selfpowered: if the gadget is self-powered.
> + * @otg_rev: The OTG reversion number the device is compliant to.
>   *
>   * Gadgets have a mostly-portable "gadget driver" implementing device
>   * functions, handling all usb configurations and interfaces.  Gadget
> @@ -562,12 +569,16 @@ struct usb_gadget {
>  
>  	unsigned			sg_supported:1;
>  	unsigned			is_otg:1;
> +	unsigned			adp_support:1;
> +	unsigned			hnp_support:1;
> +	unsigned			srp_support:1;
>  	unsigned			is_a_peripheral:1;
>  	unsigned			b_hnp_enable:1;
>  	unsigned			a_hnp_support:1;
>  	unsigned			a_alt_hnp_support:1;
>  	unsigned			quirk_ep_out_aligned_size:1;
>  	unsigned			is_selfpowered:1;
> +	unsigned			otg_rev;

this could be a dedicated type rather than unsigned.

>  };
>  #define work_to_gadget(w)	(container_of((w), struct usb_gadget, work))
>  

cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 04/22] usb: gadget: composite: add USB_DT_OTG request handling

[Li Jun]

From: Macpaul Lin <macpaul-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

Copy usb_otg_descriptor from config's descriptor if host requests
USB_DT_OTG.

Signed-off-by: Macpaul Lin <macpaul-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Signed-off-by: Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
---
 drivers/usb/gadget/composite.c | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
index 4e3447b..6b5a0c6 100644
--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -1534,6 +1534,27 @@ composite_setup(struct usb_gadget *gadget, const struct usb_ctrlrequest *ctrl)
 				value = min(w_length, (u16) value);
 			}
 			break;
+		case USB_DT_OTG:
+			if (gadget_is_otg(gadget)) {
+				struct usb_configuration *config;
+				int otg_desc_len =
+					sizeof(struct usb_otg_descriptor);
+
+				if (cdev->config)
+					config = cdev->config;
+				else
+					config = list_first_entry(
+							&cdev->configs,
+						struct usb_configuration, list);
+				if (!config)
+					goto done;
+
+				if (gadget->otg_rev >= 0x0200)
+					otg_desc_len += sizeof(struct bcdOTG);
+				value = min_t(int, w_length, otg_desc_len);
+				memcpy(req->buf, config->descriptors[0], value);
+			}
+			break;
 		}
 		break;
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 04/22] usb: gadget: composite: add USB_DT_OTG request handling

[Roger Quadros]

Hi,

On Mon, 8 Jun 2015 23:01:59 +0800
Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:

> From: Macpaul Lin <macpaul-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> 
> Copy usb_otg_descriptor from config's descriptor if host requests
> USB_DT_OTG.
> 
> Signed-off-by: Macpaul Lin <macpaul-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Signed-off-by: Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> ---
>  drivers/usb/gadget/composite.c | 21 +++++++++++++++++++++
>  1 file changed, 21 insertions(+)
> 
> diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
> index 4e3447b..6b5a0c6 100644
> --- a/drivers/usb/gadget/composite.c
> +++ b/drivers/usb/gadget/composite.c
> @@ -1534,6 +1534,27 @@ composite_setup(struct usb_gadget *gadget, const struct usb_ctrlrequest *ctrl)
>  				value = min(w_length, (u16) value);
>  			}
>  			break;
> +		case USB_DT_OTG:
> +			if (gadget_is_otg(gadget)) {
> +				struct usb_configuration *config;
> +				int otg_desc_len =
> +					sizeof(struct usb_otg_descriptor);

This evaluates to 5 which is wrong for otg v1.0

> +
> +				if (cdev->config)
> +					config = cdev->config;
> +				else
> +					config = list_first_entry(
> +							&cdev->configs,
> +						struct usb_configuration, list);
> +				if (!config)
> +					goto done;
> +
> +				if (gadget->otg_rev >= 0x0200)
> +					otg_desc_len += sizeof(struct bcdOTG);

This will become 5 + 2 which is wrong for otg v2.0

> +				value = min_t(int, w_length, otg_desc_len);
> +				memcpy(req->buf, config->descriptors[0], value);
> +			}
> +			break;
>  		}
>  		break;
>  

cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 04/22] usb: gadget: composite: add USB_DT_OTG request handling

[Li Jun]

On Tue, Jun 09, 2015 at 03:27:29PM +0300, Roger Quadros wrote:
> Hi,
> 
> On Mon, 8 Jun 2015 23:01:59 +0800
> Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> 
> > From: Macpaul Lin <macpaul-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > 
> > Copy usb_otg_descriptor from config's descriptor if host requests
> > USB_DT_OTG.
> > 
> > Signed-off-by: Macpaul Lin <macpaul-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > Signed-off-by: Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> > ---
> >  drivers/usb/gadget/composite.c | 21 +++++++++++++++++++++
> >  1 file changed, 21 insertions(+)
> > 
> > diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
> > index 4e3447b..6b5a0c6 100644
> > --- a/drivers/usb/gadget/composite.c
> > +++ b/drivers/usb/gadget/composite.c
> > @@ -1534,6 +1534,27 @@ composite_setup(struct usb_gadget *gadget, const struct usb_ctrlrequest *ctrl)
> >  				value = min(w_length, (u16) value);
> >  			}
> >  			break;
> > +		case USB_DT_OTG:
> > +			if (gadget_is_otg(gadget)) {
> > +				struct usb_configuration *config;
> > +				int otg_desc_len =
> > +					sizeof(struct usb_otg_descriptor);
> 
> This evaluates to 5 which is wrong for otg v1.0
> 
It's still 3 for OTG 1.x

> > +
> > +				if (cdev->config)
> > +					config = cdev->config;
> > +				else
> > +					config = list_first_entry(
> > +							&cdev->configs,
> > +						struct usb_configuration, list);
> > +				if (!config)
> > +					goto done;
> > +
> > +				if (gadget->otg_rev >= 0x0200)
> > +					otg_desc_len += sizeof(struct bcdOTG);
> 
> This will become 5 + 2 which is wrong for otg v2.0
> 
It will be 3+2 for OTG 2.0

> > +				value = min_t(int, w_length, otg_desc_len);
> > +				memcpy(req->buf, config->descriptors[0], value);
> > +			}
> > +			break;
> >  		}
> >  		break;
> >  
> 
> cheers,
> -roger
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 05/22] doc: dt-binding: usb: add otg related properties

[Li Jun]

Add otg version, srp, hnp and adp support for usb OTG port, then those OTG
features don't have to be decided by usb gadget drivers.

Signed-off-by: Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
---
 Documentation/devicetree/bindings/usb/generic.txt | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/generic.txt b/Documentation/devicetree/bindings/usb/generic.txt
index 477d5bb..7386f4a 100644
--- a/Documentation/devicetree/bindings/usb/generic.txt
+++ b/Documentation/devicetree/bindings/usb/generic.txt
@@ -11,6 +11,12 @@ Optional properties:
 			"peripheral" and "otg". In case this attribute isn't
 			passed via DT, USB DRD controllers should default to
 			OTG.
+ - otg-rev: tells usb driver the release number of the OTG and EH supplement
+			with which the device and its descriptors are compliant,
+			in binary-coded decimal (i.e. 2.0 is 0200H).
+ - srp-support: tells OTG controllers we want to enable SRP.
+ - hnp-support: tells OTG controllers we want to enable HNP.
+ - adp-support: tells OTG controllers we want to enable ADP.
 
 This is an attribute to a USB controller such as:
 
@@ -21,4 +27,8 @@ dwc3@4a030000 {
 	usb-phy = <&usb2_phy>, <&usb3,phy>;
 	maximum-speed = "super-speed";
 	dr_mode = "otg";
+	otg-rev = <0x0200>;
+	srp-support;
+	hnp-support;
+	adp-support;
 };
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 05/22] doc: dt-binding: usb: add otg related properties

[Rob Herring]

On Mon, Jun 8, 2015 at 10:02 AM, Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> Add otg version, srp, hnp and adp support for usb OTG port, then those OTG
> features don't have to be decided by usb gadget drivers.
>
> Signed-off-by: Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> ---
>  Documentation/devicetree/bindings/usb/generic.txt | 10 ++++++++++
>  1 file changed, 10 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/usb/generic.txt b/Documentation/devicetree/bindings/usb/generic.txt
> index 477d5bb..7386f4a 100644
> --- a/Documentation/devicetree/bindings/usb/generic.txt
> +++ b/Documentation/devicetree/bindings/usb/generic.txt
> @@ -11,6 +11,12 @@ Optional properties:
>                         "peripheral" and "otg". In case this attribute isn't
>                         passed via DT, USB DRD controllers should default to
>                         OTG.
> + - otg-rev: tells usb driver the release number of the OTG and EH supplement
> +                       with which the device and its descriptors are compliant,
> +                       in binary-coded decimal (i.e. 2.0 is 0200H).

I would assume OTG 2.0 is somehow backwards compatible? Is this a h/w
dependency or a driver feature?

> + - srp-support: tells OTG controllers we want to enable SRP.
> + - hnp-support: tells OTG controllers we want to enable HNP.
> + - adp-support: tells OTG controllers we want to enable ADP.

I've recently run into a problem[1] and found that I have to disable
OTG in the kernel to get my device to work. Having to turn-off OTG
seems like the wrong solution, and shifting the problem to DT seems
wrong too. Why is this not a user configurable option (within whatever
h/w constraints there are)?

What are the valid combinations? When do we want these enabled or not?
Wouldn't default enabled be better?

We already have dr_mode property. How is it related to these?

Rob

[1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1047527
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 05/22] doc: dt-binding: usb: add otg related properties

[Li Jun]

On Mon, Jun 08, 2015 at 11:06:49AM -0500, Rob Herring wrote:
> On Mon, Jun 8, 2015 at 10:02 AM, Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> > Add otg version, srp, hnp and adp support for usb OTG port, then those OTG
> > features don't have to be decided by usb gadget drivers.
> >
> > Signed-off-by: Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> > ---
> >  Documentation/devicetree/bindings/usb/generic.txt | 10 ++++++++++
> >  1 file changed, 10 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/usb/generic.txt b/Documentation/devicetree/bindings/usb/generic.txt
> > index 477d5bb..7386f4a 100644
> > --- a/Documentation/devicetree/bindings/usb/generic.txt
> > +++ b/Documentation/devicetree/bindings/usb/generic.txt
> > @@ -11,6 +11,12 @@ Optional properties:
> >                         "peripheral" and "otg". In case this attribute isn't
> >                         passed via DT, USB DRD controllers should default to
> >                         OTG.
> > + - otg-rev: tells usb driver the release number of the OTG and EH supplement
> > +                       with which the device and its descriptors are compliant,
> > +                       in binary-coded decimal (i.e. 2.0 is 0200H).
> 
> I would assume OTG 2.0 is somehow backwards compatible? Is this a h/w
> dependency or a driver feature?
> 
Not fully compatible, OTG 2.0 extend the usb_otg_descriptor by adding a new
member bcdOTG to identify the OTG version, this descriptor needs to be sent
to OTG host with correct size and content, so we have to know which release
version the OTG device is compliant with, either by menuconfig config or pass
via DT.

> > + - srp-support: tells OTG controllers we want to enable SRP.
> > + - hnp-support: tells OTG controllers we want to enable HNP.
> > + - adp-support: tells OTG controllers we want to enable ADP.
> 
> I've recently run into a problem[1] and found that I have to disable
> OTG in the kernel to get my device to work. Having to turn-off OTG
> seems like the wrong solution, and shifting the problem to DT seems
> wrong too. Why is this not a user configurable option (within whatever
> h/w constraints there are)?
The problem of below link, seems your device is claiming it's a HNP capable
OTG device, but connecting to a non-OTG port of your Host, assume your Host
does have a OTG port, your Host issue a A_ALT_HNP_SUPPORT request to your
OTG device to remind it can use another port with HNP, but the request failed
(maybe STALL by your device, this request is defined in OTG 1.3 but obsolete
in OTG 2.0), so your Host just stopped enumeration of your device, this is not
reasonable because current OTG code is some out of data.

I am trying to make those OTG feaures to be configurable options, you mean
by sys?

> 
> What are the valid combinations? When do we want these enabled or not?
> Wouldn't default enabled be better?

We want to enable all those support in kernel driver, but some platform or
hardware may not want to enable any or some of them, so those hardware
can disable it by not pass the property in dt, the 3 sub features of OTG are
not mandatory for so called OTG device, normally we at least enable HNP, and
SRP and ADP are optional.

> 
> We already have dr_mode property. How is it related to these?

dr_mode is to tell the device it will work at OTG mode(there is another simple
dual role mode which is commom used but not HNP), srp/hnp/adp can further specify
which protocol the OTG device will support.
> 
> Rob
> 
> [1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1047527
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 05/22] doc: dt-binding: usb: add otg related properties

[Rob Herring]

On Mon, Jun 8, 2015 at 8:18 PM, Li Jun <b47624-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> On Mon, Jun 08, 2015 at 11:06:49AM -0500, Rob Herring wrote:
>> On Mon, Jun 8, 2015 at 10:02 AM, Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
>> > Add otg version, srp, hnp and adp support for usb OTG port, then those OTG
>> > features don't have to be decided by usb gadget drivers.
>> >
>> > Signed-off-by: Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
>> > ---
>> >  Documentation/devicetree/bindings/usb/generic.txt | 10 ++++++++++
>> >  1 file changed, 10 insertions(+)
>> >
>> > diff --git a/Documentation/devicetree/bindings/usb/generic.txt b/Documentation/devicetree/bindings/usb/generic.txt
>> > index 477d5bb..7386f4a 100644
>> > --- a/Documentation/devicetree/bindings/usb/generic.txt
>> > +++ b/Documentation/devicetree/bindings/usb/generic.txt
>> > @@ -11,6 +11,12 @@ Optional properties:
>> >                         "peripheral" and "otg". In case this attribute isn't
>> >                         passed via DT, USB DRD controllers should default to
>> >                         OTG.
>> > + - otg-rev: tells usb driver the release number of the OTG and EH supplement
>> > +                       with which the device and its descriptors are compliant,
>> > +                       in binary-coded decimal (i.e. 2.0 is 0200H).
>>
>> I would assume OTG 2.0 is somehow backwards compatible? Is this a h/w
>> dependency or a driver feature?
>>
> Not fully compatible, OTG 2.0 extend the usb_otg_descriptor by adding a new
> member bcdOTG to identify the OTG version, this descriptor needs to be sent
> to OTG host with correct size and content, so we have to know which release
> version the OTG device is compliant with, either by menuconfig config or pass
> via DT.

So you have to change the version depending on the host you are
connected to? That really seems strange that plugging in a OTG 2.0
device to an OTG 1.3 host would not work and doesn't make for a good
user experience.

>> > + - srp-support: tells OTG controllers we want to enable SRP.
>> > + - hnp-support: tells OTG controllers we want to enable HNP.
>> > + - adp-support: tells OTG controllers we want to enable ADP.
>>
>> I've recently run into a problem[1] and found that I have to disable
>> OTG in the kernel to get my device to work. Having to turn-off OTG
>> seems like the wrong solution, and shifting the problem to DT seems
>> wrong too. Why is this not a user configurable option (within whatever
>> h/w constraints there are)?
> The problem of below link, seems your device is claiming it's a HNP capable
> OTG device, but connecting to a non-OTG port of your Host, assume your Host
> does have a OTG port, your Host issue a A_ALT_HNP_SUPPORT request to your
> OTG device to remind it can use another port with HNP, but the request failed
> (maybe STALL by your device, this request is defined in OTG 1.3 but obsolete
> in OTG 2.0), so your Host just stopped enumeration of your device, this is not
> reasonable because current OTG code is some out of data.

Do PCs have OTG ports typically? My expectation is that if I plug in
an OTG device as a B device to any host port, that it will work as a
device no matter what the host OTG capabilities are. If I have to
change the kernel config or DT, that is a problem.

> I am trying to make those OTG feaures to be configurable options, you mean
> by sys?

Yes.

>> What are the valid combinations? When do we want these enabled or not?
>> Wouldn't default enabled be better?
>
> We want to enable all those support in kernel driver, but some platform or
> hardware may not want to enable any or some of them, so those hardware
> can disable it by not pass the property in dt, the 3 sub features of OTG are
> not mandatory for so called OTG device, normally we at least enable HNP, and
> SRP and ADP are optional.

Please answer my questions in the doc.

>>
>> We already have dr_mode property. How is it related to these?
>
> dr_mode is to tell the device it will work at OTG mode(there is another simple
> dual role mode which is commom used but not HNP), srp/hnp/adp can further specify
> which protocol the OTG device will support.

By simple DR, you mean ID pin detect, right. So please define how you
support just ID pin detect vs. other levels of capability. Does only
dr_mode = otg mean ID pin detect? That may be a problem for existing
DTs if you disable other OTG functions because they have not been
added to the DT, then that is a problem.

I'm feeling less convinced that this belongs in DT at all. Please
convince me otherwise.

Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 05/22] doc: dt-binding: usb: add otg related properties

[Roger Quadros]

Rob,

On Tue, 9 Jun 2015 08:26:20 -0500
Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> On Mon, Jun 8, 2015 at 8:18 PM, Li Jun <b47624-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> > On Mon, Jun 08, 2015 at 11:06:49AM -0500, Rob Herring wrote:
> >> On Mon, Jun 8, 2015 at 10:02 AM, Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> >> > Add otg version, srp, hnp and adp support for usb OTG port, then those OTG
> >> > features don't have to be decided by usb gadget drivers.
> >> >
> >> > Signed-off-by: Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> >> > ---
> >> >  Documentation/devicetree/bindings/usb/generic.txt | 10 ++++++++++
> >> >  1 file changed, 10 insertions(+)
> >> >
> >> > diff --git a/Documentation/devicetree/bindings/usb/generic.txt b/Documentation/devicetree/bindings/usb/generic.txt
> >> > index 477d5bb..7386f4a 100644
> >> > --- a/Documentation/devicetree/bindings/usb/generic.txt
> >> > +++ b/Documentation/devicetree/bindings/usb/generic.txt
> >> > @@ -11,6 +11,12 @@ Optional properties:
> >> >                         "peripheral" and "otg". In case this attribute isn't
> >> >                         passed via DT, USB DRD controllers should default to
> >> >                         OTG.
> >> > + - otg-rev: tells usb driver the release number of the OTG and EH supplement
> >> > +                       with which the device and its descriptors are compliant,
> >> > +                       in binary-coded decimal (i.e. 2.0 is 0200H).
> >>
> >> I would assume OTG 2.0 is somehow backwards compatible? Is this a h/w
> >> dependency or a driver feature?
> >>
> > Not fully compatible, OTG 2.0 extend the usb_otg_descriptor by adding a new
> > member bcdOTG to identify the OTG version, this descriptor needs to be sent
> > to OTG host with correct size and content, so we have to know which release
> > version the OTG device is compliant with, either by menuconfig config or pass
> > via DT.
> 
> So you have to change the version depending on the host you are
> connected to? That really seems strange that plugging in a OTG 2.0
> device to an OTG 1.3 host would not work and doesn't make for a good
> user experience.

No. The OTG version in the OTG descriptor for any device is usually fixed for the
lifetime of the product.

Let's assume it is 2.0.

If you plug this to OTG 1.0 host, it won't be an issue as OTG 1.0 host doesn't
read the BCD version.

> 
> >> > + - srp-support: tells OTG controllers we want to enable SRP.
> >> > + - hnp-support: tells OTG controllers we want to enable HNP.
> >> > + - adp-support: tells OTG controllers we want to enable ADP.
> >>
> >> I've recently run into a problem[1] and found that I have to disable
> >> OTG in the kernel to get my device to work. Having to turn-off OTG
> >> seems like the wrong solution, and shifting the problem to DT seems
> >> wrong too. Why is this not a user configurable option (within whatever
> >> h/w constraints there are)?
> > The problem of below link, seems your device is claiming it's a HNP capable
> > OTG device, but connecting to a non-OTG port of your Host, assume your Host
> > does have a OTG port, your Host issue a A_ALT_HNP_SUPPORT request to your
> > OTG device to remind it can use another port with HNP, but the request failed
> > (maybe STALL by your device, this request is defined in OTG 1.3 but obsolete
> > in OTG 2.0), so your Host just stopped enumeration of your device, this is not
> > reasonable because current OTG code is some out of data.
> 
> Do PCs have OTG ports typically? My expectation is that if I plug in
> an OTG device as a B device to any host port, that it will work as a
> device no matter what the host OTG capabilities are. If I have to
> change the kernel config or DT, that is a problem.

AFAIK PCs don't have OTG ports.

If you plug in OTG device to a non-otg host port it will work as normal B-device.
The host doesn't request for OTG descriptors and doesn't care what OTG features it
supports or not.

> 
> > I am trying to make those OTG feaures to be configurable options, you mean
> > by sys?
> 
> Yes.

why do you need OTG features to be sysfs configurable other than for debugging?

> 
> >> What are the valid combinations? When do we want these enabled or not?
> >> Wouldn't default enabled be better?
> >
> > We want to enable all those support in kernel driver, but some platform or
> > hardware may not want to enable any or some of them, so those hardware
> > can disable it by not pass the property in dt, the 3 sub features of OTG are
> > not mandatory for so called OTG device, normally we at least enable HNP, and
> > SRP and ADP are optional.
> 
> Please answer my questions in the doc.
> 
> >>
> >> We already have dr_mode property. How is it related to these?

dr_mode states what mode the controller will operate in.

for dr_mode == "host" we don't care about these otg flags.

for dr_mode == "peripheral" or dr_mode == "otg"
we care about these OTG flags to create our OTG descriptor on the fly.

> >
> > dr_mode is to tell the device it will work at OTG mode(there is another simple
> > dual role mode which is commom used but not HNP), srp/hnp/adp can further specify
> > which protocol the OTG device will support.
> 
> By simple DR, you mean ID pin detect, right. So please define how you
> support just ID pin detect vs. other levels of capability. Does only
> dr_mode = otg mean ID pin detect? That may be a problem for existing
> DTs if you disable other OTG functions because they have not been
> added to the DT, then that is a problem.
> 
> I'm feeling less convinced that this belongs in DT at all. Please
> convince me otherwise.

Yes not specifying anything in DT should work and default to the
best OTG version and features supported by the OTG controller.

But if the device manufacturer wants to restrict the OTG version
to something less or disable some OTG features then the DT flags come
into play.

cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 05/22] doc: dt-binding: usb: add otg related properties

[Rob Herring]

On Tue, Jun 9, 2015 at 10:29 AM, Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org> wrote:
> Rob,
>
> On Tue, 9 Jun 2015 08:26:20 -0500
> Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>> On Mon, Jun 8, 2015 at 8:18 PM, Li Jun <b47624-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
>> > On Mon, Jun 08, 2015 at 11:06:49AM -0500, Rob Herring wrote:
>> >> On Mon, Jun 8, 2015 at 10:02 AM, Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
>> >> > Add otg version, srp, hnp and adp support for usb OTG port, then those OTG
>> >> > features don't have to be decided by usb gadget drivers.
>> >> >
>> >> > Signed-off-by: Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
>> >> > ---
>> >> >  Documentation/devicetree/bindings/usb/generic.txt | 10 ++++++++++
>> >> >  1 file changed, 10 insertions(+)
>> >> >
>> >> > diff --git a/Documentation/devicetree/bindings/usb/generic.txt b/Documentation/devicetree/bindings/usb/generic.txt
>> >> > index 477d5bb..7386f4a 100644
>> >> > --- a/Documentation/devicetree/bindings/usb/generic.txt
>> >> > +++ b/Documentation/devicetree/bindings/usb/generic.txt
>> >> > @@ -11,6 +11,12 @@ Optional properties:
>> >> >                         "peripheral" and "otg". In case this attribute isn't
>> >> >                         passed via DT, USB DRD controllers should default to
>> >> >                         OTG.
>> >> > + - otg-rev: tells usb driver the release number of the OTG and EH supplement
>> >> > +                       with which the device and its descriptors are compliant,
>> >> > +                       in binary-coded decimal (i.e. 2.0 is 0200H).
>> >>
>> >> I would assume OTG 2.0 is somehow backwards compatible? Is this a h/w
>> >> dependency or a driver feature?
>> >>
>> > Not fully compatible, OTG 2.0 extend the usb_otg_descriptor by adding a new
>> > member bcdOTG to identify the OTG version, this descriptor needs to be sent
>> > to OTG host with correct size and content, so we have to know which release
>> > version the OTG device is compliant with, either by menuconfig config or pass
>> > via DT.
>>
>> So you have to change the version depending on the host you are
>> connected to? That really seems strange that plugging in a OTG 2.0
>> device to an OTG 1.3 host would not work and doesn't make for a good
>> user experience.
>
> No. The OTG version in the OTG descriptor for any device is usually fixed for the
> lifetime of the product.
>
> Let's assume it is 2.0.
>
> If you plug this to OTG 1.0 host, it won't be an issue as OTG 1.0 host doesn't
> read the BCD version.

That makes sense, but there was some discussion about the size mattering.

So is there a reason not to always report 2.0 with any kernel that has
2.0 support?

>>
>> >> > + - srp-support: tells OTG controllers we want to enable SRP.
>> >> > + - hnp-support: tells OTG controllers we want to enable HNP.
>> >> > + - adp-support: tells OTG controllers we want to enable ADP.
>> >>
>> >> I've recently run into a problem[1] and found that I have to disable
>> >> OTG in the kernel to get my device to work. Having to turn-off OTG
>> >> seems like the wrong solution, and shifting the problem to DT seems
>> >> wrong too. Why is this not a user configurable option (within whatever
>> >> h/w constraints there are)?
>> > The problem of below link, seems your device is claiming it's a HNP capable
>> > OTG device, but connecting to a non-OTG port of your Host, assume your Host
>> > does have a OTG port, your Host issue a A_ALT_HNP_SUPPORT request to your
>> > OTG device to remind it can use another port with HNP, but the request failed
>> > (maybe STALL by your device, this request is defined in OTG 1.3 but obsolete
>> > in OTG 2.0), so your Host just stopped enumeration of your device, this is not
>> > reasonable because current OTG code is some out of data.
>>
>> Do PCs have OTG ports typically? My expectation is that if I plug in
>> an OTG device as a B device to any host port, that it will work as a
>> device no matter what the host OTG capabilities are. If I have to
>> change the kernel config or DT, that is a problem.
>
> AFAIK PCs don't have OTG ports.
>
> If you plug in OTG device to a non-otg host port it will work as normal B-device.
> The host doesn't request for OTG descriptors and doesn't care what OTG features it
> supports or not.

That is what I would expect. My testing and the bug report show otherwise.

>> > I am trying to make those OTG feaures to be configurable options, you mean
>> > by sys?
>>
>> Yes.
>
> why do you need OTG features to be sysfs configurable other than for debugging?

I don't know. Buggy host perhaps? Why do you need them in DT?

If they are truly debugging, then they would belong in debugfs rather
than sysfs.

>> >> What are the valid combinations? When do we want these enabled or not?
>> >> Wouldn't default enabled be better?
>> >
>> > We want to enable all those support in kernel driver, but some platform or
>> > hardware may not want to enable any or some of them, so those hardware
>> > can disable it by not pass the property in dt, the 3 sub features of OTG are
>> > not mandatory for so called OTG device, normally we at least enable HNP, and
>> > SRP and ADP are optional.
>>
>> Please answer my questions in the doc.
>>
>> >>
>> >> We already have dr_mode property. How is it related to these?
>
> dr_mode states what mode the controller will operate in.
>
> for dr_mode == "host" we don't care about these otg flags.
>
> for dr_mode == "peripheral" or dr_mode == "otg"
> we care about these OTG flags to create our OTG descriptor on the fly.

Then how do I specify my device is peripheral only even though I have
a DR controller?

How is ID pin detect supposed to be supported? Do we need dr_mode = "idpin"?

>> > dr_mode is to tell the device it will work at OTG mode(there is another simple
>> > dual role mode which is commom used but not HNP), srp/hnp/adp can further specify
>> > which protocol the OTG device will support.
>>
>> By simple DR, you mean ID pin detect, right. So please define how you
>> support just ID pin detect vs. other levels of capability. Does only
>> dr_mode = otg mean ID pin detect? That may be a problem for existing
>> DTs if you disable other OTG functions because they have not been
>> added to the DT, then that is a problem.
>>
>> I'm feeling less convinced that this belongs in DT at all. Please
>> convince me otherwise.
>
> Yes not specifying anything in DT should work and default to the
> best OTG version and features supported by the OTG controller.

Right, hence why I suggested disable flags, not enable flags.

> But if the device manufacturer wants to restrict the OTG version
> to something less or disable some OTG features then the DT flags come
> into play.

Why would they?

Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 05/22] doc: dt-binding: usb: add otg related properties

[Roger Quadros]

On Tue, 9 Jun 2015 11:33:11 -0500
Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> On Tue, Jun 9, 2015 at 10:29 AM, Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org> wrote:
> > Rob,
> >
> > On Tue, 9 Jun 2015 08:26:20 -0500
> > Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >
> >> On Mon, Jun 8, 2015 at 8:18 PM, Li Jun <b47624-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> >> > On Mon, Jun 08, 2015 at 11:06:49AM -0500, Rob Herring wrote:
> >> >> On Mon, Jun 8, 2015 at 10:02 AM, Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> >> >> > Add otg version, srp, hnp and adp support for usb OTG port, then those OTG
> >> >> > features don't have to be decided by usb gadget drivers.
> >> >> >
> >> >> > Signed-off-by: Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> >> >> > ---
> >> >> >  Documentation/devicetree/bindings/usb/generic.txt | 10 ++++++++++
> >> >> >  1 file changed, 10 insertions(+)
> >> >> >
> >> >> > diff --git a/Documentation/devicetree/bindings/usb/generic.txt b/Documentation/devicetree/bindings/usb/generic.txt
> >> >> > index 477d5bb..7386f4a 100644
> >> >> > --- a/Documentation/devicetree/bindings/usb/generic.txt
> >> >> > +++ b/Documentation/devicetree/bindings/usb/generic.txt
> >> >> > @@ -11,6 +11,12 @@ Optional properties:
> >> >> >                         "peripheral" and "otg". In case this attribute isn't
> >> >> >                         passed via DT, USB DRD controllers should default to
> >> >> >                         OTG.
> >> >> > + - otg-rev: tells usb driver the release number of the OTG and EH supplement
> >> >> > +                       with which the device and its descriptors are compliant,
> >> >> > +                       in binary-coded decimal (i.e. 2.0 is 0200H).
> >> >>
> >> >> I would assume OTG 2.0 is somehow backwards compatible? Is this a h/w
> >> >> dependency or a driver feature?
> >> >>
> >> > Not fully compatible, OTG 2.0 extend the usb_otg_descriptor by adding a new
> >> > member bcdOTG to identify the OTG version, this descriptor needs to be sent
> >> > to OTG host with correct size and content, so we have to know which release
> >> > version the OTG device is compliant with, either by menuconfig config or pass
> >> > via DT.
> >>
> >> So you have to change the version depending on the host you are
> >> connected to? That really seems strange that plugging in a OTG 2.0
> >> device to an OTG 1.3 host would not work and doesn't make for a good
> >> user experience.
> >
> > No. The OTG version in the OTG descriptor for any device is usually fixed for the
> > lifetime of the product.
> >
> > Let's assume it is 2.0.
> >
> > If you plug this to OTG 1.0 host, it won't be an issue as OTG 1.0 host doesn't
> > read the BCD version.
> 
> That makes sense, but there was some discussion about the size mattering.
> 
> So is there a reason not to always report 2.0 with any kernel that has
> 2.0 support?

A 2.0 host would still need to know if the attached OTG device is 1.0 or 2.0
so we don't want to force existing 1.0 devices to 2.0.

> 
> >>
> >> >> > + - srp-support: tells OTG controllers we want to enable SRP.
> >> >> > + - hnp-support: tells OTG controllers we want to enable HNP.
> >> >> > + - adp-support: tells OTG controllers we want to enable ADP.
> >> >>
> >> >> I've recently run into a problem[1] and found that I have to disable
> >> >> OTG in the kernel to get my device to work. Having to turn-off OTG
> >> >> seems like the wrong solution, and shifting the problem to DT seems
> >> >> wrong too. Why is this not a user configurable option (within whatever
> >> >> h/w constraints there are)?
> >> > The problem of below link, seems your device is claiming it's a HNP capable
> >> > OTG device, but connecting to a non-OTG port of your Host, assume your Host
> >> > does have a OTG port, your Host issue a A_ALT_HNP_SUPPORT request to your
> >> > OTG device to remind it can use another port with HNP, but the request failed
> >> > (maybe STALL by your device, this request is defined in OTG 1.3 but obsolete
> >> > in OTG 2.0), so your Host just stopped enumeration of your device, this is not
> >> > reasonable because current OTG code is some out of data.
> >>
> >> Do PCs have OTG ports typically? My expectation is that if I plug in
> >> an OTG device as a B device to any host port, that it will work as a
> >> device no matter what the host OTG capabilities are. If I have to
> >> change the kernel config or DT, that is a problem.
> >
> > AFAIK PCs don't have OTG ports.
> >
> > If you plug in OTG device to a non-otg host port it will work as normal B-device.
> > The host doesn't request for OTG descriptors and doesn't care what OTG features it
> > supports or not.
> 
> That is what I would expect. My testing and the bug report show otherwise.

what kernel and platform are you on?

> 
> >> > I am trying to make those OTG feaures to be configurable options, you mean
> >> > by sys?
> >>
> >> Yes.
> >
> > why do you need OTG features to be sysfs configurable other than for debugging?
> 
> I don't know. Buggy host perhaps? Why do you need them in DT?

I'll explain why we need in DT below.

> 
> If they are truly debugging, then they would belong in debugfs rather
> than sysfs.

agreed.
> 
> >> >> What are the valid combinations? When do we want these enabled or not?
> >> >> Wouldn't default enabled be better?
> >> >
> >> > We want to enable all those support in kernel driver, but some platform or
> >> > hardware may not want to enable any or some of them, so those hardware
> >> > can disable it by not pass the property in dt, the 3 sub features of OTG are
> >> > not mandatory for so called OTG device, normally we at least enable HNP, and
> >> > SRP and ADP are optional.
> >>
> >> Please answer my questions in the doc.
> >>
> >> >>
> >> >> We already have dr_mode property. How is it related to these?
> >
> > dr_mode states what mode the controller will operate in.
> >
> > for dr_mode == "host" we don't care about these otg flags.
> >
> > for dr_mode == "peripheral" or dr_mode == "otg"
> > we care about these OTG flags to create our OTG descriptor on the fly.
> 
> Then how do I specify my device is peripheral only even though I have
> a DR controller?

by specifying dr_mode = "peripheral" in the DT.

> 
> How is ID pin detect supposed to be supported? Do we need dr_mode = "idpin"?

ID pin is not used in single role mode. It will be used only when dr_mode = "otg".

> 
> >> > dr_mode is to tell the device it will work at OTG mode(there is another simple
> >> > dual role mode which is commom used but not HNP), srp/hnp/adp can further specify
> >> > which protocol the OTG device will support.
> >>
> >> By simple DR, you mean ID pin detect, right. So please define how you
> >> support just ID pin detect vs. other levels of capability. Does only
> >> dr_mode = otg mean ID pin detect? That may be a problem for existing
> >> DTs if you disable other OTG functions because they have not been
> >> added to the DT, then that is a problem.
> >>
> >> I'm feeling less convinced that this belongs in DT at all. Please
> >> convince me otherwise.
> >
> > Yes not specifying anything in DT should work and default to the
> > best OTG version and features supported by the OTG controller.
> 
> Right, hence why I suggested disable flags, not enable flags.

I second that. They must be disable flags.

> 
> > But if the device manufacturer wants to restrict the OTG version
> > to something less or disable some OTG features then the DT flags come
> > into play.
> 
> Why would they?

Maybe they just don't want some of the features.
one example is DRD mode. In DRD mode the controller works as host or
peripheral but doesn't support dynamic role switching or host negotiation.

For that they can set

	dr_mode = "otg"
	disable-adp;
	disable-hnp;
	disable-srp;

cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 05/22] doc: dt-binding: usb: add otg related properties

[Li Jun]

On Wed, Jun 10, 2015 at 03:37:37PM +0800, Roger Quadros wrote:
> On Tue, 9 Jun 2015 11:33:11 -0500
> Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> 
> > On Tue, Jun 9, 2015 at 10:29 AM, Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org> wrote:
> > > Rob,
> > >
> > > On Tue, 9 Jun 2015 08:26:20 -0500
> > > Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > >
> > >> On Mon, Jun 8, 2015 at 8:18 PM, Li Jun <b47624-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> > >> > On Mon, Jun 08, 2015 at 11:06:49AM -0500, Rob Herring wrote:
> > >> >> On Mon, Jun 8, 2015 at 10:02 AM, Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> > >> >> > Add otg version, srp, hnp and adp support for usb OTG port, then those OTG
> > >> >> > features don't have to be decided by usb gadget drivers.
> > >> >> >
> > >> >> > Signed-off-by: Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> > >> >> > ---
> > >> >> >  Documentation/devicetree/bindings/usb/generic.txt | 10 ++++++++++
> > >> >> >  1 file changed, 10 insertions(+)
> > >> >> >
> > >> >> > diff --git a/Documentation/devicetree/bindings/usb/generic.txt b/Documentation/devicetree/bindings/usb/generic.txt
> > >> >> > index 477d5bb..7386f4a 100644
> > >> >> > --- a/Documentation/devicetree/bindings/usb/generic.txt
> > >> >> > +++ b/Documentation/devicetree/bindings/usb/generic.txt
> > >> >> > @@ -11,6 +11,12 @@ Optional properties:
> > >> >> >                         "peripheral" and "otg". In case this attribute isn't
> > >> >> >                         passed via DT, USB DRD controllers should default to
> > >> >> >                         OTG.
> > >> >> > + - otg-rev: tells usb driver the release number of the OTG and EH supplement
> > >> >> > +                       with which the device and its descriptors are compliant,
> > >> >> > +                       in binary-coded decimal (i.e. 2.0 is 0200H).
> > >> >>
> > >> >> I would assume OTG 2.0 is somehow backwards compatible? Is this a h/w
> > >> >> dependency or a driver feature?
> > >> >>
> > >> > Not fully compatible, OTG 2.0 extend the usb_otg_descriptor by adding a new
> > >> > member bcdOTG to identify the OTG version, this descriptor needs to be sent
> > >> > to OTG host with correct size and content, so we have to know which release
> > >> > version the OTG device is compliant with, either by menuconfig config or pass
> > >> > via DT.
> > >>
> > >> So you have to change the version depending on the host you are
> > >> connected to? That really seems strange that plugging in a OTG 2.0
> > >> device to an OTG 1.3 host would not work and doesn't make for a good
> > >> user experience.
> > >
> > > No. The OTG version in the OTG descriptor for any device is usually fixed for the
> > > lifetime of the product.
> > >
> > > Let's assume it is 2.0.
> > >
> > > If you plug this to OTG 1.0 host, it won't be an issue as OTG 1.0 host doesn't
> > > read the BCD version.
> > 
> > That makes sense, but there was some discussion about the size mattering.
> > 
> > So is there a reason not to always report 2.0 with any kernel that has
> > 2.0 support?
> 
> A 2.0 host would still need to know if the attached OTG device is 1.0 or 2.0
> so we don't want to force existing 1.0 devices to 2.0.
> 
> > 
> > >>
> > >> >> > + - srp-support: tells OTG controllers we want to enable SRP.
> > >> >> > + - hnp-support: tells OTG controllers we want to enable HNP.
> > >> >> > + - adp-support: tells OTG controllers we want to enable ADP.
> > >> >>
> > >> >> I've recently run into a problem[1] and found that I have to disable
> > >> >> OTG in the kernel to get my device to work. Having to turn-off OTG
> > >> >> seems like the wrong solution, and shifting the problem to DT seems
> > >> >> wrong too. Why is this not a user configurable option (within whatever
> > >> >> h/w constraints there are)?
> > >> > The problem of below link, seems your device is claiming it's a HNP capable
> > >> > OTG device, but connecting to a non-OTG port of your Host, assume your Host
> > >> > does have a OTG port, your Host issue a A_ALT_HNP_SUPPORT request to your
> > >> > OTG device to remind it can use another port with HNP, but the request failed
> > >> > (maybe STALL by your device, this request is defined in OTG 1.3 but obsolete
> > >> > in OTG 2.0), so your Host just stopped enumeration of your device, this is not
> > >> > reasonable because current OTG code is some out of data.
> > >>
> > >> Do PCs have OTG ports typically? My expectation is that if I plug in
> > >> an OTG device as a B device to any host port, that it will work as a
> > >> device no matter what the host OTG capabilities are. If I have to
> > >> change the kernel config or DT, that is a problem.
> > >
> > > AFAIK PCs don't have OTG ports.
> > >
> > > If you plug in OTG device to a non-otg host port it will work as normal B-device.
> > > The host doesn't request for OTG descriptors and doesn't care what OTG features it
> > > supports or not.
> > 
> > That is what I would expect. My testing and the bug report show otherwise.
> 
> what kernel and platform are you on?
> 
> > 
> > >> > I am trying to make those OTG feaures to be configurable options, you mean
> > >> > by sys?
> > >>
> > >> Yes.
> > >
> > > why do you need OTG features to be sysfs configurable other than for debugging?
> > 
> > I don't know. Buggy host perhaps? Why do you need them in DT?
> 
> I'll explain why we need in DT below.
> 
> > 
> > If they are truly debugging, then they would belong in debugfs rather
> > than sysfs.
> 
> agreed.
> > 
> > >> >> What are the valid combinations? When do we want these enabled or not?
> > >> >> Wouldn't default enabled be better?
> > >> >
> > >> > We want to enable all those support in kernel driver, but some platform or
> > >> > hardware may not want to enable any or some of them, so those hardware
> > >> > can disable it by not pass the property in dt, the 3 sub features of OTG are
> > >> > not mandatory for so called OTG device, normally we at least enable HNP, and
> > >> > SRP and ADP are optional.
> > >>
> > >> Please answer my questions in the doc.
> > >>
> > >> >>
> > >> >> We already have dr_mode property. How is it related to these?
> > >
> > > dr_mode states what mode the controller will operate in.
> > >
> > > for dr_mode == "host" we don't care about these otg flags.
> > >
> > > for dr_mode == "peripheral" or dr_mode == "otg"
> > > we care about these OTG flags to create our OTG descriptor on the fly.
> > 
> > Then how do I specify my device is peripheral only even though I have
> > a DR controller?
> 
> by specifying dr_mode = "peripheral" in the DT.
> 
> > 
> > How is ID pin detect supposed to be supported? Do we need dr_mode = "idpin"?
> 
> ID pin is not used in single role mode. It will be used only when dr_mode = "otg".
> 
> > 
> > >> > dr_mode is to tell the device it will work at OTG mode(there is another simple
> > >> > dual role mode which is commom used but not HNP), srp/hnp/adp can further specify
> > >> > which protocol the OTG device will support.
> > >>
> > >> By simple DR, you mean ID pin detect, right. So please define how you
> > >> support just ID pin detect vs. other levels of capability. Does only
> > >> dr_mode = otg mean ID pin detect? That may be a problem for existing
> > >> DTs if you disable other OTG functions because they have not been
> > >> added to the DT, then that is a problem.
> > >>
> > >> I'm feeling less convinced that this belongs in DT at all. Please
> > >> convince me otherwise.
> > >
> > > Yes not specifying anything in DT should work and default to the
> > > best OTG version and features supported by the OTG controller.
> > 
> > Right, hence why I suggested disable flags, not enable flags.
> 
> I second that. They must be disable flags.
> 

Disable flags may not work with current situation of gadget driver:
Currently each gadget class driver hard coded the OTG attributes
to be HNP | SRP, independent of controller driver.

E.g. some platform with OTG enabled: gadget->is_otg = 1
HNP and SRP are enabled by gadget driver, ADP = 0, this OTG port
can really support HNP and SRP, but not ADP. 
if use disable flag, this platform has to add adp-disable property
otherwise it will report ADP support to the host.

But with enable flags, I can check all those 3 properties,
1)If none of them are passed, but gadget->is_otg == 1, I suppose it's
legacy platform, still set HNP and SRP as current gadget driver does,
works as before;
2)If any one of them appear, I will set all those features by dt property.
3)If some platform already based on those properties, wants to disable
all 3 OTG features, also not pass any one of them like 1), it will not
be a OTG device at all, set gadget->is_otg = 0 in its controller driver,
then no need set and report any OTG features, this can meet ID pin detect
case.
 
> > 
> > > But if the device manufacturer wants to restrict the OTG version
> > > to something less or disable some OTG features then the DT flags come
> > > into play.
> > 
> > Why would they?
> 
> Maybe they just don't want some of the features.
> one example is DRD mode. In DRD mode the controller works as host or
> peripheral but doesn't support dynamic role switching or host negotiation.
> 
> For that they can set
> 
> 	dr_mode = "otg"
> 	disable-adp;
> 	disable-hnp;
> 	disable-srp;

Other possible reasons maybe power saving, ADP need constantly do vbus
probe if there is no usb device connected, this will consume power.
 
> cheers,
> -roger
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 05/22] doc: dt-binding: usb: add otg related properties

[Roger Quadros]

On Wed, 10 Jun 2015 21:47:51 +0800
Li Jun <b47624-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:

> On Wed, Jun 10, 2015 at 03:37:37PM +0800, Roger Quadros wrote:
> > On Tue, 9 Jun 2015 11:33:11 -0500
> > Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > 
> > > On Tue, Jun 9, 2015 at 10:29 AM, Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org> wrote:
> > > > Rob,
> > > >
> > > > On Tue, 9 Jun 2015 08:26:20 -0500
> > > > Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > >
> > > >> On Mon, Jun 8, 2015 at 8:18 PM, Li Jun <b47624-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> > > >> > On Mon, Jun 08, 2015 at 11:06:49AM -0500, Rob Herring wrote:
> > > >> >> On Mon, Jun 8, 2015 at 10:02 AM, Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> > > >> >> > Add otg version, srp, hnp and adp support for usb OTG port, then those OTG
> > > >> >> > features don't have to be decided by usb gadget drivers.
> > > >> >> >
> > > >> >> > Signed-off-by: Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> > > >> >> > ---
> > > >> >> >  Documentation/devicetree/bindings/usb/generic.txt | 10 ++++++++++
> > > >> >> >  1 file changed, 10 insertions(+)
> > > >> >> >
> > > >> >> > diff --git a/Documentation/devicetree/bindings/usb/generic.txt b/Documentation/devicetree/bindings/usb/generic.txt
> > > >> >> > index 477d5bb..7386f4a 100644
> > > >> >> > --- a/Documentation/devicetree/bindings/usb/generic.txt
> > > >> >> > +++ b/Documentation/devicetree/bindings/usb/generic.txt
> > > >> >> > @@ -11,6 +11,12 @@ Optional properties:
> > > >> >> >                         "peripheral" and "otg". In case this attribute isn't
> > > >> >> >                         passed via DT, USB DRD controllers should default to
> > > >> >> >                         OTG.
> > > >> >> > + - otg-rev: tells usb driver the release number of the OTG and EH supplement
> > > >> >> > +                       with which the device and its descriptors are compliant,
> > > >> >> > +                       in binary-coded decimal (i.e. 2.0 is 0200H).
> > > >> >>
> > > >> >> I would assume OTG 2.0 is somehow backwards compatible? Is this a h/w
> > > >> >> dependency or a driver feature?
> > > >> >>
> > > >> > Not fully compatible, OTG 2.0 extend the usb_otg_descriptor by adding a new
> > > >> > member bcdOTG to identify the OTG version, this descriptor needs to be sent
> > > >> > to OTG host with correct size and content, so we have to know which release
> > > >> > version the OTG device is compliant with, either by menuconfig config or pass
> > > >> > via DT.
> > > >>
> > > >> So you have to change the version depending on the host you are
> > > >> connected to? That really seems strange that plugging in a OTG 2.0
> > > >> device to an OTG 1.3 host would not work and doesn't make for a good
> > > >> user experience.
> > > >
> > > > No. The OTG version in the OTG descriptor for any device is usually fixed for the
> > > > lifetime of the product.
> > > >
> > > > Let's assume it is 2.0.
> > > >
> > > > If you plug this to OTG 1.0 host, it won't be an issue as OTG 1.0 host doesn't
> > > > read the BCD version.
> > > 
> > > That makes sense, but there was some discussion about the size mattering.
> > > 
> > > So is there a reason not to always report 2.0 with any kernel that has
> > > 2.0 support?
> > 
> > A 2.0 host would still need to know if the attached OTG device is 1.0 or 2.0
> > so we don't want to force existing 1.0 devices to 2.0.
> > 
> > > 
> > > >>
> > > >> >> > + - srp-support: tells OTG controllers we want to enable SRP.
> > > >> >> > + - hnp-support: tells OTG controllers we want to enable HNP.
> > > >> >> > + - adp-support: tells OTG controllers we want to enable ADP.
> > > >> >>
> > > >> >> I've recently run into a problem[1] and found that I have to disable
> > > >> >> OTG in the kernel to get my device to work. Having to turn-off OTG
> > > >> >> seems like the wrong solution, and shifting the problem to DT seems
> > > >> >> wrong too. Why is this not a user configurable option (within whatever
> > > >> >> h/w constraints there are)?
> > > >> > The problem of below link, seems your device is claiming it's a HNP capable
> > > >> > OTG device, but connecting to a non-OTG port of your Host, assume your Host
> > > >> > does have a OTG port, your Host issue a A_ALT_HNP_SUPPORT request to your
> > > >> > OTG device to remind it can use another port with HNP, but the request failed
> > > >> > (maybe STALL by your device, this request is defined in OTG 1.3 but obsolete
> > > >> > in OTG 2.0), so your Host just stopped enumeration of your device, this is not
> > > >> > reasonable because current OTG code is some out of data.
> > > >>
> > > >> Do PCs have OTG ports typically? My expectation is that if I plug in
> > > >> an OTG device as a B device to any host port, that it will work as a
> > > >> device no matter what the host OTG capabilities are. If I have to
> > > >> change the kernel config or DT, that is a problem.
> > > >
> > > > AFAIK PCs don't have OTG ports.
> > > >
> > > > If you plug in OTG device to a non-otg host port it will work as normal B-device.
> > > > The host doesn't request for OTG descriptors and doesn't care what OTG features it
> > > > supports or not.
> > > 
> > > That is what I would expect. My testing and the bug report show otherwise.
> > 
> > what kernel and platform are you on?
> > 
> > > 
> > > >> > I am trying to make those OTG feaures to be configurable options, you mean
> > > >> > by sys?
> > > >>
> > > >> Yes.
> > > >
> > > > why do you need OTG features to be sysfs configurable other than for debugging?
> > > 
> > > I don't know. Buggy host perhaps? Why do you need them in DT?
> > 
> > I'll explain why we need in DT below.
> > 
> > > 
> > > If they are truly debugging, then they would belong in debugfs rather
> > > than sysfs.
> > 
> > agreed.
> > > 
> > > >> >> What are the valid combinations? When do we want these enabled or not?
> > > >> >> Wouldn't default enabled be better?
> > > >> >
> > > >> > We want to enable all those support in kernel driver, but some platform or
> > > >> > hardware may not want to enable any or some of them, so those hardware
> > > >> > can disable it by not pass the property in dt, the 3 sub features of OTG are
> > > >> > not mandatory for so called OTG device, normally we at least enable HNP, and
> > > >> > SRP and ADP are optional.
> > > >>
> > > >> Please answer my questions in the doc.
> > > >>
> > > >> >>
> > > >> >> We already have dr_mode property. How is it related to these?
> > > >
> > > > dr_mode states what mode the controller will operate in.
> > > >
> > > > for dr_mode == "host" we don't care about these otg flags.
> > > >
> > > > for dr_mode == "peripheral" or dr_mode == "otg"
> > > > we care about these OTG flags to create our OTG descriptor on the fly.
> > > 
> > > Then how do I specify my device is peripheral only even though I have
> > > a DR controller?
> > 
> > by specifying dr_mode = "peripheral" in the DT.
> > 
> > > 
> > > How is ID pin detect supposed to be supported? Do we need dr_mode = "idpin"?
> > 
> > ID pin is not used in single role mode. It will be used only when dr_mode = "otg".
> > 
> > > 
> > > >> > dr_mode is to tell the device it will work at OTG mode(there is another simple
> > > >> > dual role mode which is commom used but not HNP), srp/hnp/adp can further specify
> > > >> > which protocol the OTG device will support.
> > > >>
> > > >> By simple DR, you mean ID pin detect, right. So please define how you
> > > >> support just ID pin detect vs. other levels of capability. Does only
> > > >> dr_mode = otg mean ID pin detect? That may be a problem for existing
> > > >> DTs if you disable other OTG functions because they have not been
> > > >> added to the DT, then that is a problem.
> > > >>
> > > >> I'm feeling less convinced that this belongs in DT at all. Please
> > > >> convince me otherwise.
> > > >
> > > > Yes not specifying anything in DT should work and default to the
> > > > best OTG version and features supported by the OTG controller.
> > > 
> > > Right, hence why I suggested disable flags, not enable flags.
> > 
> > I second that. They must be disable flags.
> > 
> 
> Disable flags may not work with current situation of gadget driver:
> Currently each gadget class driver hard coded the OTG attributes
> to be HNP | SRP, independent of controller driver.

That is wrong in the first place. Gadget drivers shouldn't decide
the OTG attributes. Platform code/DT should.

If gadget drivers define OTG flags then they cannot be used on
different platforms with different OTG needs.

> 
> E.g. some platform with OTG enabled: gadget->is_otg = 1
> HNP and SRP are enabled by gadget driver, ADP = 0, this OTG port
> can really support HNP and SRP, but not ADP. 

What if the platform on which the gadget driver is used doesn't want
SRP enabled?

> if use disable flag, this platform has to add adp-disable property
> otherwise it will report ADP support to the host.

This issue won't happen if gadget driver doesn't define any OTG attributes.

> 
> But with enable flags, I can check all those 3 properties,

I don't see why you can't do that with disable flags. Note that there are 2 things.
1) disable flags from DT
2) support flags from controller. This information is already known to the
controller.

Based on these 2 you can decide what OTG features you want to set/clear.
And you can't combine the 2 by just defining enable flags in DT.

> 1)If none of them are passed, but gadget->is_otg == 1, I suppose it's
> legacy platform, still set HNP and SRP as current gadget driver does,
> works as before;
> 2)If any one of them appear, I will set all those features by dt property.
> 3)If some platform already based on those properties, wants to disable
> all 3 OTG features, also not pass any one of them like 1), it will not
> be a OTG device at all, set gadget->is_otg = 0 in its controller driver,
> then no need set and report any OTG features, this can meet ID pin detect
> case.

With enable flags you don't get what you set.
e.g. in DT, we might set enable-adp.
but if controller doesn't support adp, you don't have ADP working.
So this is misleading.

cheers,
-roger

>  
> > > 
> > > > But if the device manufacturer wants to restrict the OTG version
> > > > to something less or disable some OTG features then the DT flags come
> > > > into play.
> > > 
> > > Why would they?
> > 
> > Maybe they just don't want some of the features.
> > one example is DRD mode. In DRD mode the controller works as host or
> > peripheral but doesn't support dynamic role switching or host negotiation.
> > 
> > For that they can set
> > 
> > 	dr_mode = "otg"
> > 	disable-adp;
> > 	disable-hnp;
> > 	disable-srp;
> 
> Other possible reasons maybe power saving, ADP need constantly do vbus
> probe if there is no usb device connected, this will consume power.
>  
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 05/22] doc: dt-binding: usb: add otg related properties

[Li Jun]

On Thu, Jun 11, 2015 at 10:18:53AM +0300, Roger Quadros wrote:
> 
> On Wed, 10 Jun 2015 21:47:51 +0800
> Li Jun <b47624-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> 
> > On Wed, Jun 10, 2015 at 03:37:37PM +0800, Roger Quadros wrote:
> > > On Tue, 9 Jun 2015 11:33:11 -0500
> > > Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > 
> > > > On Tue, Jun 9, 2015 at 10:29 AM, Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org> wrote:
> > > > > Rob,
> > > > >
> > > > > On Tue, 9 Jun 2015 08:26:20 -0500
> > > > > Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > > >
> > > > >> On Mon, Jun 8, 2015 at 8:18 PM, Li Jun <b47624-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> > > > >> > On Mon, Jun 08, 2015 at 11:06:49AM -0500, Rob Herring wrote:
> > > > >> >> On Mon, Jun 8, 2015 at 10:02 AM, Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> > > > >> >> > Add otg version, srp, hnp and adp support for usb OTG port, then those OTG
> > > > >> >> > features don't have to be decided by usb gadget drivers.
> > > > >> >> >
> > > > >> >> > Signed-off-by: Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> > > > >> >> > ---
> > > > >> >> >  Documentation/devicetree/bindings/usb/generic.txt | 10 ++++++++++
> > > > >> >> >  1 file changed, 10 insertions(+)
> > > > >> >> >
> > > > >> >> > diff --git a/Documentation/devicetree/bindings/usb/generic.txt b/Documentation/devicetree/bindings/usb/generic.txt
> > > > >> >> > index 477d5bb..7386f4a 100644
> > > > >> >> > --- a/Documentation/devicetree/bindings/usb/generic.txt
> > > > >> >> > +++ b/Documentation/devicetree/bindings/usb/generic.txt
> > > > >> >> > @@ -11,6 +11,12 @@ Optional properties:
> > > > >> >> >                         "peripheral" and "otg". In case this attribute isn't
> > > > >> >> >                         passed via DT, USB DRD controllers should default to
> > > > >> >> >                         OTG.
> > > > >> >> > + - otg-rev: tells usb driver the release number of the OTG and EH supplement
> > > > >> >> > +                       with which the device and its descriptors are compliant,
> > > > >> >> > +                       in binary-coded decimal (i.e. 2.0 is 0200H).
> > > > >> >>
> > > > >> >> I would assume OTG 2.0 is somehow backwards compatible? Is this a h/w
> > > > >> >> dependency or a driver feature?
> > > > >> >>
> > > > >> > Not fully compatible, OTG 2.0 extend the usb_otg_descriptor by adding a new
> > > > >> > member bcdOTG to identify the OTG version, this descriptor needs to be sent
> > > > >> > to OTG host with correct size and content, so we have to know which release
> > > > >> > version the OTG device is compliant with, either by menuconfig config or pass
> > > > >> > via DT.
> > > > >>
> > > > >> So you have to change the version depending on the host you are
> > > > >> connected to? That really seems strange that plugging in a OTG 2.0
> > > > >> device to an OTG 1.3 host would not work and doesn't make for a good
> > > > >> user experience.
> > > > >
> > > > > No. The OTG version in the OTG descriptor for any device is usually fixed for the
> > > > > lifetime of the product.
> > > > >
> > > > > Let's assume it is 2.0.
> > > > >
> > > > > If you plug this to OTG 1.0 host, it won't be an issue as OTG 1.0 host doesn't
> > > > > read the BCD version.
> > > > 
> > > > That makes sense, but there was some discussion about the size mattering.
> > > > 
> > > > So is there a reason not to always report 2.0 with any kernel that has
> > > > 2.0 support?
> > > 
> > > A 2.0 host would still need to know if the attached OTG device is 1.0 or 2.0
> > > so we don't want to force existing 1.0 devices to 2.0.
> > > 
> > > > 
> > > > >>
> > > > >> >> > + - srp-support: tells OTG controllers we want to enable SRP.
> > > > >> >> > + - hnp-support: tells OTG controllers we want to enable HNP.
> > > > >> >> > + - adp-support: tells OTG controllers we want to enable ADP.
> > > > >> >>
> > > > >> >> I've recently run into a problem[1] and found that I have to disable
> > > > >> >> OTG in the kernel to get my device to work. Having to turn-off OTG
> > > > >> >> seems like the wrong solution, and shifting the problem to DT seems
> > > > >> >> wrong too. Why is this not a user configurable option (within whatever
> > > > >> >> h/w constraints there are)?
> > > > >> > The problem of below link, seems your device is claiming it's a HNP capable
> > > > >> > OTG device, but connecting to a non-OTG port of your Host, assume your Host
> > > > >> > does have a OTG port, your Host issue a A_ALT_HNP_SUPPORT request to your
> > > > >> > OTG device to remind it can use another port with HNP, but the request failed
> > > > >> > (maybe STALL by your device, this request is defined in OTG 1.3 but obsolete
> > > > >> > in OTG 2.0), so your Host just stopped enumeration of your device, this is not
> > > > >> > reasonable because current OTG code is some out of data.
> > > > >>
> > > > >> Do PCs have OTG ports typically? My expectation is that if I plug in
> > > > >> an OTG device as a B device to any host port, that it will work as a
> > > > >> device no matter what the host OTG capabilities are. If I have to
> > > > >> change the kernel config or DT, that is a problem.
> > > > >
> > > > > AFAIK PCs don't have OTG ports.
> > > > >
> > > > > If you plug in OTG device to a non-otg host port it will work as normal B-device.
> > > > > The host doesn't request for OTG descriptors and doesn't care what OTG features it
> > > > > supports or not.
> > > > 
> > > > That is what I would expect. My testing and the bug report show otherwise.
> > > 
> > > what kernel and platform are you on?
> > > 
> > > > 
> > > > >> > I am trying to make those OTG feaures to be configurable options, you mean
> > > > >> > by sys?
> > > > >>
> > > > >> Yes.
> > > > >
> > > > > why do you need OTG features to be sysfs configurable other than for debugging?
> > > > 
> > > > I don't know. Buggy host perhaps? Why do you need them in DT?
> > > 
> > > I'll explain why we need in DT below.
> > > 
> > > > 
> > > > If they are truly debugging, then they would belong in debugfs rather
> > > > than sysfs.
> > > 
> > > agreed.
> > > > 
> > > > >> >> What are the valid combinations? When do we want these enabled or not?
> > > > >> >> Wouldn't default enabled be better?
> > > > >> >
> > > > >> > We want to enable all those support in kernel driver, but some platform or
> > > > >> > hardware may not want to enable any or some of them, so those hardware
> > > > >> > can disable it by not pass the property in dt, the 3 sub features of OTG are
> > > > >> > not mandatory for so called OTG device, normally we at least enable HNP, and
> > > > >> > SRP and ADP are optional.
> > > > >>
> > > > >> Please answer my questions in the doc.
> > > > >>
> > > > >> >>
> > > > >> >> We already have dr_mode property. How is it related to these?
> > > > >
> > > > > dr_mode states what mode the controller will operate in.
> > > > >
> > > > > for dr_mode == "host" we don't care about these otg flags.
> > > > >
> > > > > for dr_mode == "peripheral" or dr_mode == "otg"
> > > > > we care about these OTG flags to create our OTG descriptor on the fly.
> > > > 
> > > > Then how do I specify my device is peripheral only even though I have
> > > > a DR controller?
> > > 
> > > by specifying dr_mode = "peripheral" in the DT.
> > > 
> > > > 
> > > > How is ID pin detect supposed to be supported? Do we need dr_mode = "idpin"?
> > > 
> > > ID pin is not used in single role mode. It will be used only when dr_mode = "otg".
> > > 
> > > > 
> > > > >> > dr_mode is to tell the device it will work at OTG mode(there is another simple
> > > > >> > dual role mode which is commom used but not HNP), srp/hnp/adp can further specify
> > > > >> > which protocol the OTG device will support.
> > > > >>
> > > > >> By simple DR, you mean ID pin detect, right. So please define how you
> > > > >> support just ID pin detect vs. other levels of capability. Does only
> > > > >> dr_mode = otg mean ID pin detect? That may be a problem for existing
> > > > >> DTs if you disable other OTG functions because they have not been
> > > > >> added to the DT, then that is a problem.
> > > > >>
> > > > >> I'm feeling less convinced that this belongs in DT at all. Please
> > > > >> convince me otherwise.
> > > > >
> > > > > Yes not specifying anything in DT should work and default to the
> > > > > best OTG version and features supported by the OTG controller.
> > > > 
> > > > Right, hence why I suggested disable flags, not enable flags.
> > > 
> > > I second that. They must be disable flags.
> > > 
> > 
> > Disable flags may not work with current situation of gadget driver:
> > Currently each gadget class driver hard coded the OTG attributes
> > to be HNP | SRP, independent of controller driver.
> 
> That is wrong in the first place. Gadget drivers shouldn't decide
> the OTG attributes. Platform code/DT should.
> 

I totally agree the current code is wrong.

> If gadget drivers define OTG flags then they cannot be used on
> different platforms with different OTG needs.
> 
Agree too.

But some platforms may already work with current "wrong" way, I do not want
to break them.

> > 
> > E.g. some platform with OTG enabled: gadget->is_otg = 1
> > HNP and SRP are enabled by gadget driver, ADP = 0, this OTG port
> > can really support HNP and SRP, but not ADP. 
> 
> What if the platform on which the gadget driver is used doesn't want
> SRP enabled?

As far as I know, there is no controller driver to override this setting,
maybe it still keeps SRP enabled even it does not support it in fact. 

> 
> > if use disable flag, this platform has to add adp-disable property
> > otherwise it will report ADP support to the host.
> 
> This issue won't happen if gadget driver doesn't define any OTG attributes.
> 
But some existing platform already rely on gadget driver to define OTG
attributes, Can I break those already working platforms? I think it's hard
to figure out all this kind of platforms and then correct every one with
new approach.

Who define this attributes doesn't matter, key is this attributes should
base on correct input.

So my principle is to not break any existing platforms, and introduce new
approach, old platforms can work without any change.

> > 
> > But with enable flags, I can check all those 3 properties,
> 
> I don't see why you can't do that with disable flags. Note that there are 2 things.
> 1) disable flags from DT
> 2) support flags from controller. This information is already known to the
> controller.
> 
> Based on these 2 you can decide what OTG features you want to set/clear.
> And you can't combine the 2 by just defining enable flags in DT.
> 

Yes, I have the same understanding. So:
1) In controller driver:
if (controller_can_support_srp(controller)) {
	if (srp_enabled_in_dt(of))
		gadget->srp_support = 1;
}
2) In gadget driver:
if (gadget->srp_support)
	attribute |= SRP;

> > 1)If none of them are passed, but gadget->is_otg == 1, I suppose it's
> > legacy platform, still set HNP and SRP as current gadget driver does,
> > works as before;
> > 2)If any one of them appear, I will set all those features by dt property.
> > 3)If some platform already based on those properties, wants to disable
> > all 3 OTG features, also not pass any one of them like 1), it will not
> > be a OTG device at all, set gadget->is_otg = 0 in its controller driver,
> > then no need set and report any OTG features, this can meet ID pin detect
> > case.
> 
> With enable flags you don't get what you set.
> e.g. in DT, we might set enable-adp.
> but if controller doesn't support adp, you don't have ADP working.
> So this is misleading.
> 

Why someone might do that? If someone adds some property which is not supported
by its controller, of cos this feature cannot work.

If some platform utilize those new properties, both enable and disable flags
can work, but for those existing platforms with HNP/SRP support, they have
no any new flags in its DT, I need make it work as before.

thanks Roger.

Li Jun

> cheers,
> -roger
> 
> >  
> > > > 
> > > > > But if the device manufacturer wants to restrict the OTG version
> > > > > to something less or disable some OTG features then the DT flags come
> > > > > into play.
> > > > 
> > > > Why would they?
> > > 
> > > Maybe they just don't want some of the features.
> > > one example is DRD mode. In DRD mode the controller works as host or
> > > peripheral but doesn't support dynamic role switching or host negotiation.
> > > 
> > > For that they can set
> > > 
> > > 	dr_mode = "otg"
> > > 	disable-adp;
> > > 	disable-hnp;
> > > 	disable-srp;
> > 
> > Other possible reasons maybe power saving, ADP need constantly do vbus
> > probe if there is no usb device connected, this will consume power.
> >  
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 05/22] doc: dt-binding: usb: add otg related properties

[Roger Quadros]

On Thu, 11 Jun 2015 16:20:13 +0800
Li Jun <b47624-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:

> On Thu, Jun 11, 2015 at 10:18:53AM +0300, Roger Quadros wrote:
> > 
> > On Wed, 10 Jun 2015 21:47:51 +0800
> > Li Jun <b47624-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> > 
> > > On Wed, Jun 10, 2015 at 03:37:37PM +0800, Roger Quadros wrote:
> > > > On Tue, 9 Jun 2015 11:33:11 -0500
> > > > Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > > 
> > > > > On Tue, Jun 9, 2015 at 10:29 AM, Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org> wrote:
> > > > > > Rob,
> > > > > >
> > > > > > On Tue, 9 Jun 2015 08:26:20 -0500
> > > > > > Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > > > >
> > > > > >> On Mon, Jun 8, 2015 at 8:18 PM, Li Jun <b47624-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> > > > > >> > On Mon, Jun 08, 2015 at 11:06:49AM -0500, Rob Herring wrote:
> > > > > >> >> On Mon, Jun 8, 2015 at 10:02 AM, Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> > > > > >> >> > Add otg version, srp, hnp and adp support for usb OTG port, then those OTG
> > > > > >> >> > features don't have to be decided by usb gadget drivers.
> > > > > >> >> >
> > > > > >> >> > Signed-off-by: Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> > > > > >> >> > ---
> > > > > >> >> >  Documentation/devicetree/bindings/usb/generic.txt | 10 ++++++++++
> > > > > >> >> >  1 file changed, 10 insertions(+)
> > > > > >> >> >
> > > > > >> >> > diff --git a/Documentation/devicetree/bindings/usb/generic.txt b/Documentation/devicetree/bindings/usb/generic.txt
> > > > > >> >> > index 477d5bb..7386f4a 100644
> > > > > >> >> > --- a/Documentation/devicetree/bindings/usb/generic.txt
> > > > > >> >> > +++ b/Documentation/devicetree/bindings/usb/generic.txt
> > > > > >> >> > @@ -11,6 +11,12 @@ Optional properties:
> > > > > >> >> >                         "peripheral" and "otg". In case this attribute isn't
> > > > > >> >> >                         passed via DT, USB DRD controllers should default to
> > > > > >> >> >                         OTG.
> > > > > >> >> > + - otg-rev: tells usb driver the release number of the OTG and EH supplement
> > > > > >> >> > +                       with which the device and its descriptors are compliant,
> > > > > >> >> > +                       in binary-coded decimal (i.e. 2.0 is 0200H).
> > > > > >> >>
> > > > > >> >> I would assume OTG 2.0 is somehow backwards compatible? Is this a h/w
> > > > > >> >> dependency or a driver feature?
> > > > > >> >>
> > > > > >> > Not fully compatible, OTG 2.0 extend the usb_otg_descriptor by adding a new
> > > > > >> > member bcdOTG to identify the OTG version, this descriptor needs to be sent
> > > > > >> > to OTG host with correct size and content, so we have to know which release
> > > > > >> > version the OTG device is compliant with, either by menuconfig config or pass
> > > > > >> > via DT.
> > > > > >>
> > > > > >> So you have to change the version depending on the host you are
> > > > > >> connected to? That really seems strange that plugging in a OTG 2.0
> > > > > >> device to an OTG 1.3 host would not work and doesn't make for a good
> > > > > >> user experience.
> > > > > >
> > > > > > No. The OTG version in the OTG descriptor for any device is usually fixed for the
> > > > > > lifetime of the product.
> > > > > >
> > > > > > Let's assume it is 2.0.
> > > > > >
> > > > > > If you plug this to OTG 1.0 host, it won't be an issue as OTG 1.0 host doesn't
> > > > > > read the BCD version.
> > > > > 
> > > > > That makes sense, but there was some discussion about the size mattering.
> > > > > 
> > > > > So is there a reason not to always report 2.0 with any kernel that has
> > > > > 2.0 support?
> > > > 
> > > > A 2.0 host would still need to know if the attached OTG device is 1.0 or 2.0
> > > > so we don't want to force existing 1.0 devices to 2.0.
> > > > 
> > > > > 
> > > > > >>
> > > > > >> >> > + - srp-support: tells OTG controllers we want to enable SRP.
> > > > > >> >> > + - hnp-support: tells OTG controllers we want to enable HNP.
> > > > > >> >> > + - adp-support: tells OTG controllers we want to enable ADP.
> > > > > >> >>
> > > > > >> >> I've recently run into a problem[1] and found that I have to disable
> > > > > >> >> OTG in the kernel to get my device to work. Having to turn-off OTG
> > > > > >> >> seems like the wrong solution, and shifting the problem to DT seems
> > > > > >> >> wrong too. Why is this not a user configurable option (within whatever
> > > > > >> >> h/w constraints there are)?
> > > > > >> > The problem of below link, seems your device is claiming it's a HNP capable
> > > > > >> > OTG device, but connecting to a non-OTG port of your Host, assume your Host
> > > > > >> > does have a OTG port, your Host issue a A_ALT_HNP_SUPPORT request to your
> > > > > >> > OTG device to remind it can use another port with HNP, but the request failed
> > > > > >> > (maybe STALL by your device, this request is defined in OTG 1.3 but obsolete
> > > > > >> > in OTG 2.0), so your Host just stopped enumeration of your device, this is not
> > > > > >> > reasonable because current OTG code is some out of data.
> > > > > >>
> > > > > >> Do PCs have OTG ports typically? My expectation is that if I plug in
> > > > > >> an OTG device as a B device to any host port, that it will work as a
> > > > > >> device no matter what the host OTG capabilities are. If I have to
> > > > > >> change the kernel config or DT, that is a problem.
> > > > > >
> > > > > > AFAIK PCs don't have OTG ports.
> > > > > >
> > > > > > If you plug in OTG device to a non-otg host port it will work as normal B-device.
> > > > > > The host doesn't request for OTG descriptors and doesn't care what OTG features it
> > > > > > supports or not.
> > > > > 
> > > > > That is what I would expect. My testing and the bug report show otherwise.
> > > > 
> > > > what kernel and platform are you on?
> > > > 
> > > > > 
> > > > > >> > I am trying to make those OTG feaures to be configurable options, you mean
> > > > > >> > by sys?
> > > > > >>
> > > > > >> Yes.
> > > > > >
> > > > > > why do you need OTG features to be sysfs configurable other than for debugging?
> > > > > 
> > > > > I don't know. Buggy host perhaps? Why do you need them in DT?
> > > > 
> > > > I'll explain why we need in DT below.
> > > > 
> > > > > 
> > > > > If they are truly debugging, then they would belong in debugfs rather
> > > > > than sysfs.
> > > > 
> > > > agreed.
> > > > > 
> > > > > >> >> What are the valid combinations? When do we want these enabled or not?
> > > > > >> >> Wouldn't default enabled be better?
> > > > > >> >
> > > > > >> > We want to enable all those support in kernel driver, but some platform or
> > > > > >> > hardware may not want to enable any or some of them, so those hardware
> > > > > >> > can disable it by not pass the property in dt, the 3 sub features of OTG are
> > > > > >> > not mandatory for so called OTG device, normally we at least enable HNP, and
> > > > > >> > SRP and ADP are optional.
> > > > > >>
> > > > > >> Please answer my questions in the doc.
> > > > > >>
> > > > > >> >>
> > > > > >> >> We already have dr_mode property. How is it related to these?
> > > > > >
> > > > > > dr_mode states what mode the controller will operate in.
> > > > > >
> > > > > > for dr_mode == "host" we don't care about these otg flags.
> > > > > >
> > > > > > for dr_mode == "peripheral" or dr_mode == "otg"
> > > > > > we care about these OTG flags to create our OTG descriptor on the fly.
> > > > > 
> > > > > Then how do I specify my device is peripheral only even though I have
> > > > > a DR controller?
> > > > 
> > > > by specifying dr_mode = "peripheral" in the DT.
> > > > 
> > > > > 
> > > > > How is ID pin detect supposed to be supported? Do we need dr_mode = "idpin"?
> > > > 
> > > > ID pin is not used in single role mode. It will be used only when dr_mode = "otg".
> > > > 
> > > > > 
> > > > > >> > dr_mode is to tell the device it will work at OTG mode(there is another simple
> > > > > >> > dual role mode which is commom used but not HNP), srp/hnp/adp can further specify
> > > > > >> > which protocol the OTG device will support.
> > > > > >>
> > > > > >> By simple DR, you mean ID pin detect, right. So please define how you
> > > > > >> support just ID pin detect vs. other levels of capability. Does only
> > > > > >> dr_mode = otg mean ID pin detect? That may be a problem for existing
> > > > > >> DTs if you disable other OTG functions because they have not been
> > > > > >> added to the DT, then that is a problem.
> > > > > >>
> > > > > >> I'm feeling less convinced that this belongs in DT at all. Please
> > > > > >> convince me otherwise.
> > > > > >
> > > > > > Yes not specifying anything in DT should work and default to the
> > > > > > best OTG version and features supported by the OTG controller.
> > > > > 
> > > > > Right, hence why I suggested disable flags, not enable flags.
> > > > 
> > > > I second that. They must be disable flags.
> > > > 
> > > 
> > > Disable flags may not work with current situation of gadget driver:
> > > Currently each gadget class driver hard coded the OTG attributes
> > > to be HNP | SRP, independent of controller driver.
> > 
> > That is wrong in the first place. Gadget drivers shouldn't decide
> > the OTG attributes. Platform code/DT should.
> > 
> 
> I totally agree the current code is wrong.
> 
> > If gadget drivers define OTG flags then they cannot be used on
> > different platforms with different OTG needs.
> > 
> Agree too.
> 
> But some platforms may already work with current "wrong" way, I do not want
> to break them.
> 
> > > 
> > > E.g. some platform with OTG enabled: gadget->is_otg = 1
> > > HNP and SRP are enabled by gadget driver, ADP = 0, this OTG port
> > > can really support HNP and SRP, but not ADP. 
> > 
> > What if the platform on which the gadget driver is used doesn't want
> > SRP enabled?
> 
> As far as I know, there is no controller driver to override this setting,
> maybe it still keeps SRP enabled even it does not support it in fact. 
> 
> > 
> > > if use disable flag, this platform has to add adp-disable property
> > > otherwise it will report ADP support to the host.
> > 
> > This issue won't happen if gadget driver doesn't define any OTG attributes.
> > 
> But some existing platform already rely on gadget driver to define OTG
> attributes, Can I break those already working platforms? I think it's hard
> to figure out all this kind of platforms and then correct every one with
> new approach.
> 
> Who define this attributes doesn't matter, key is this attributes should
> base on correct input.
> 
> So my principle is to not break any existing platforms, and introduce new
> approach, old platforms can work without any change.

But we don't know which platforms use what so we need to define a sane
default configuration for all gadgets. I don't think we can have a gadget
specific configuration.

If anyone complains we need to ask them to set the right DT flags for their
platform. I don't see any other way.

> 
> > > 
> > > But with enable flags, I can check all those 3 properties,
> > 
> > I don't see why you can't do that with disable flags. Note that there are 2 things.
> > 1) disable flags from DT
> > 2) support flags from controller. This information is already known to the
> > controller.
> > 
> > Based on these 2 you can decide what OTG features you want to set/clear.
> > And you can't combine the 2 by just defining enable flags in DT.
> > 
> 
> Yes, I have the same understanding. So:
> 1) In controller driver:
> if (controller_can_support_srp(controller)) {
> 	if (srp_enabled_in_dt(of))
> 		gadget->srp_support = 1;

Existing platforms don't have feature_enabled_in_dt so this will fail for all.
So need to have
	if (srp_not_disabled_in_dt(of))
		gadget->srp_support = 1;

> }
> 2) In gadget driver:
> if (gadget->srp_support)
> 	attribute |= SRP;

Agreed.

> 
> > > 1)If none of them are passed, but gadget->is_otg == 1, I suppose it's
> > > legacy platform, still set HNP and SRP as current gadget driver does,
> > > works as before;
> > > 2)If any one of them appear, I will set all those features by dt property.
> > > 3)If some platform already based on those properties, wants to disable
> > > all 3 OTG features, also not pass any one of them like 1), it will not
> > > be a OTG device at all, set gadget->is_otg = 0 in its controller driver,
> > > then no need set and report any OTG features, this can meet ID pin detect
> > > case.
> > 
> > With enable flags you don't get what you set.
> > e.g. in DT, we might set enable-adp.
> > but if controller doesn't support adp, you don't have ADP working.
> > So this is misleading.
> > 
> 
> Why someone might do that? If someone adds some property which is not supported
> by its controller, of cos this feature cannot work.

OK.

> 
> If some platform utilize those new properties, both enable and disable flags
> can work, but for those existing platforms with HNP/SRP support, they have
> no any new flags in its DT, I need make it work as before.

Right, existing platforms need to work as is without DT changes. So features
have to be enabled by default. That's another reason why we need disable-flags
and not enable-flags in DT.

cheers,
-roger

> 
> thanks Roger.
> 
> Li Jun
> 
> > cheers,
> > -roger
> > 
> > >  
> > > > > 
> > > > > > But if the device manufacturer wants to restrict the OTG version
> > > > > > to something less or disable some OTG features then the DT flags come
> > > > > > into play.
> > > > > 
> > > > > Why would they?
> > > > 
> > > > Maybe they just don't want some of the features.
> > > > one example is DRD mode. In DRD mode the controller works as host or
> > > > peripheral but doesn't support dynamic role switching or host negotiation.
> > > > 
> > > > For that they can set
> > > > 
> > > > 	dr_mode = "otg"
> > > > 	disable-adp;
> > > > 	disable-hnp;
> > > > 	disable-srp;
> > > 
> > > Other possible reasons maybe power saving, ADP need constantly do vbus
> > > probe if there is no usb device connected, this will consume power.
> > >  

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 05/22] doc: dt-binding: usb: add otg related properties

[Li Jun]

On Thu, Jun 11, 2015 at 03:37:03PM +0300, Roger Quadros wrote:
> 
> On Thu, 11 Jun 2015 16:20:13 +0800
> Li Jun <b47624-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> 
> > On Thu, Jun 11, 2015 at 10:18:53AM +0300, Roger Quadros wrote:
> > > 
> > > On Wed, 10 Jun 2015 21:47:51 +0800
> > > Li Jun <b47624-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> > > 
> > > > On Wed, Jun 10, 2015 at 03:37:37PM +0800, Roger Quadros wrote:
> > > > > On Tue, 9 Jun 2015 11:33:11 -0500
> > > > > Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > > > 
> > > > > > On Tue, Jun 9, 2015 at 10:29 AM, Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org> wrote:
> > > > > > > Rob,
> > > > > > >
> > > > > > > On Tue, 9 Jun 2015 08:26:20 -0500
> > > > > > > Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > > > > >
> > > > > > >> On Mon, Jun 8, 2015 at 8:18 PM, Li Jun <b47624-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> > > > > > >> > On Mon, Jun 08, 2015 at 11:06:49AM -0500, Rob Herring wrote:
> > > > > > >> >> On Mon, Jun 8, 2015 at 10:02 AM, Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> > > > > > >> >> > Add otg version, srp, hnp and adp support for usb OTG port, then those OTG
> > > > > > >> >> > features don't have to be decided by usb gadget drivers.
> > > > > > >> >> >
> > > > > > >> >> > Signed-off-by: Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> > > > > > >> >> > ---
> > > > > > >> >> >  Documentation/devicetree/bindings/usb/generic.txt | 10 ++++++++++
> > > > > > >> >> >  1 file changed, 10 insertions(+)
> > > > > > >> >> >
> > > > > > >> >> > diff --git a/Documentation/devicetree/bindings/usb/generic.txt b/Documentation/devicetree/bindings/usb/generic.txt
> > > > > > >> >> > index 477d5bb..7386f4a 100644
> > > > > > >> >> > --- a/Documentation/devicetree/bindings/usb/generic.txt
> > > > > > >> >> > +++ b/Documentation/devicetree/bindings/usb/generic.txt
> > > > > > >> >> > @@ -11,6 +11,12 @@ Optional properties:
> > > > > > >> >> >                         "peripheral" and "otg". In case this attribute isn't
> > > > > > >> >> >                         passed via DT, USB DRD controllers should default to
> > > > > > >> >> >                         OTG.
> > > > > > >> >> > + - otg-rev: tells usb driver the release number of the OTG and EH supplement
> > > > > > >> >> > +                       with which the device and its descriptors are compliant,
> > > > > > >> >> > +                       in binary-coded decimal (i.e. 2.0 is 0200H).
> > > > > > >> >>
> > > > > > >> >> I would assume OTG 2.0 is somehow backwards compatible? Is this a h/w
> > > > > > >> >> dependency or a driver feature?
> > > > > > >> >>
> > > > > > >> > Not fully compatible, OTG 2.0 extend the usb_otg_descriptor by adding a new
> > > > > > >> > member bcdOTG to identify the OTG version, this descriptor needs to be sent
> > > > > > >> > to OTG host with correct size and content, so we have to know which release
> > > > > > >> > version the OTG device is compliant with, either by menuconfig config or pass
> > > > > > >> > via DT.
> > > > > > >>
> > > > > > >> So you have to change the version depending on the host you are
> > > > > > >> connected to? That really seems strange that plugging in a OTG 2.0
> > > > > > >> device to an OTG 1.3 host would not work and doesn't make for a good
> > > > > > >> user experience.
> > > > > > >
> > > > > > > No. The OTG version in the OTG descriptor for any device is usually fixed for the
> > > > > > > lifetime of the product.
> > > > > > >
> > > > > > > Let's assume it is 2.0.
> > > > > > >
> > > > > > > If you plug this to OTG 1.0 host, it won't be an issue as OTG 1.0 host doesn't
> > > > > > > read the BCD version.
> > > > > > 
> > > > > > That makes sense, but there was some discussion about the size mattering.
> > > > > > 
> > > > > > So is there a reason not to always report 2.0 with any kernel that has
> > > > > > 2.0 support?
> > > > > 
> > > > > A 2.0 host would still need to know if the attached OTG device is 1.0 or 2.0
> > > > > so we don't want to force existing 1.0 devices to 2.0.
> > > > > 
> > > > > > 
> > > > > > >>
> > > > > > >> >> > + - srp-support: tells OTG controllers we want to enable SRP.
> > > > > > >> >> > + - hnp-support: tells OTG controllers we want to enable HNP.
> > > > > > >> >> > + - adp-support: tells OTG controllers we want to enable ADP.
> > > > > > >> >>
> > > > > > >> >> I've recently run into a problem[1] and found that I have to disable
> > > > > > >> >> OTG in the kernel to get my device to work. Having to turn-off OTG
> > > > > > >> >> seems like the wrong solution, and shifting the problem to DT seems
> > > > > > >> >> wrong too. Why is this not a user configurable option (within whatever
> > > > > > >> >> h/w constraints there are)?
> > > > > > >> > The problem of below link, seems your device is claiming it's a HNP capable
> > > > > > >> > OTG device, but connecting to a non-OTG port of your Host, assume your Host
> > > > > > >> > does have a OTG port, your Host issue a A_ALT_HNP_SUPPORT request to your
> > > > > > >> > OTG device to remind it can use another port with HNP, but the request failed
> > > > > > >> > (maybe STALL by your device, this request is defined in OTG 1.3 but obsolete
> > > > > > >> > in OTG 2.0), so your Host just stopped enumeration of your device, this is not
> > > > > > >> > reasonable because current OTG code is some out of data.
> > > > > > >>
> > > > > > >> Do PCs have OTG ports typically? My expectation is that if I plug in
> > > > > > >> an OTG device as a B device to any host port, that it will work as a
> > > > > > >> device no matter what the host OTG capabilities are. If I have to
> > > > > > >> change the kernel config or DT, that is a problem.
> > > > > > >
> > > > > > > AFAIK PCs don't have OTG ports.
> > > > > > >
> > > > > > > If you plug in OTG device to a non-otg host port it will work as normal B-device.
> > > > > > > The host doesn't request for OTG descriptors and doesn't care what OTG features it
> > > > > > > supports or not.
> > > > > > 
> > > > > > That is what I would expect. My testing and the bug report show otherwise.
> > > > > 
> > > > > what kernel and platform are you on?
> > > > > 
> > > > > > 
> > > > > > >> > I am trying to make those OTG feaures to be configurable options, you mean
> > > > > > >> > by sys?
> > > > > > >>
> > > > > > >> Yes.
> > > > > > >
> > > > > > > why do you need OTG features to be sysfs configurable other than for debugging?
> > > > > > 
> > > > > > I don't know. Buggy host perhaps? Why do you need them in DT?
> > > > > 
> > > > > I'll explain why we need in DT below.
> > > > > 
> > > > > > 
> > > > > > If they are truly debugging, then they would belong in debugfs rather
> > > > > > than sysfs.
> > > > > 
> > > > > agreed.
> > > > > > 
> > > > > > >> >> What are the valid combinations? When do we want these enabled or not?
> > > > > > >> >> Wouldn't default enabled be better?
> > > > > > >> >
> > > > > > >> > We want to enable all those support in kernel driver, but some platform or
> > > > > > >> > hardware may not want to enable any or some of them, so those hardware
> > > > > > >> > can disable it by not pass the property in dt, the 3 sub features of OTG are
> > > > > > >> > not mandatory for so called OTG device, normally we at least enable HNP, and
> > > > > > >> > SRP and ADP are optional.
> > > > > > >>
> > > > > > >> Please answer my questions in the doc.
> > > > > > >>
> > > > > > >> >>
> > > > > > >> >> We already have dr_mode property. How is it related to these?
> > > > > > >
> > > > > > > dr_mode states what mode the controller will operate in.
> > > > > > >
> > > > > > > for dr_mode == "host" we don't care about these otg flags.
> > > > > > >
> > > > > > > for dr_mode == "peripheral" or dr_mode == "otg"
> > > > > > > we care about these OTG flags to create our OTG descriptor on the fly.
> > > > > > 
> > > > > > Then how do I specify my device is peripheral only even though I have
> > > > > > a DR controller?
> > > > > 
> > > > > by specifying dr_mode = "peripheral" in the DT.
> > > > > 
> > > > > > 
> > > > > > How is ID pin detect supposed to be supported? Do we need dr_mode = "idpin"?
> > > > > 
> > > > > ID pin is not used in single role mode. It will be used only when dr_mode = "otg".
> > > > > 
> > > > > > 
> > > > > > >> > dr_mode is to tell the device it will work at OTG mode(there is another simple
> > > > > > >> > dual role mode which is commom used but not HNP), srp/hnp/adp can further specify
> > > > > > >> > which protocol the OTG device will support.
> > > > > > >>
> > > > > > >> By simple DR, you mean ID pin detect, right. So please define how you
> > > > > > >> support just ID pin detect vs. other levels of capability. Does only
> > > > > > >> dr_mode = otg mean ID pin detect? That may be a problem for existing
> > > > > > >> DTs if you disable other OTG functions because they have not been
> > > > > > >> added to the DT, then that is a problem.
> > > > > > >>
> > > > > > >> I'm feeling less convinced that this belongs in DT at all. Please
> > > > > > >> convince me otherwise.
> > > > > > >
> > > > > > > Yes not specifying anything in DT should work and default to the
> > > > > > > best OTG version and features supported by the OTG controller.
> > > > > > 
> > > > > > Right, hence why I suggested disable flags, not enable flags.
> > > > > 
> > > > > I second that. They must be disable flags.
> > > > > 
> > > > 
> > > > Disable flags may not work with current situation of gadget driver:
> > > > Currently each gadget class driver hard coded the OTG attributes
> > > > to be HNP | SRP, independent of controller driver.
> > > 
> > > That is wrong in the first place. Gadget drivers shouldn't decide
> > > the OTG attributes. Platform code/DT should.
> > > 
> > 
> > I totally agree the current code is wrong.
> > 
> > > If gadget drivers define OTG flags then they cannot be used on
> > > different platforms with different OTG needs.
> > > 
> > Agree too.
> > 
> > But some platforms may already work with current "wrong" way, I do not want
> > to break them.
> > 
> > > > 
> > > > E.g. some platform with OTG enabled: gadget->is_otg = 1
> > > > HNP and SRP are enabled by gadget driver, ADP = 0, this OTG port
> > > > can really support HNP and SRP, but not ADP. 
> > > 
> > > What if the platform on which the gadget driver is used doesn't want
> > > SRP enabled?
> > 
> > As far as I know, there is no controller driver to override this setting,
> > maybe it still keeps SRP enabled even it does not support it in fact. 
> > 
> > > 
> > > > if use disable flag, this platform has to add adp-disable property
> > > > otherwise it will report ADP support to the host.
> > > 
> > > This issue won't happen if gadget driver doesn't define any OTG attributes.
> > > 
> > But some existing platform already rely on gadget driver to define OTG
> > attributes, Can I break those already working platforms? I think it's hard
> > to figure out all this kind of platforms and then correct every one with
> > new approach.
> > 
> > Who define this attributes doesn't matter, key is this attributes should
> > base on correct input.
> > 
> > So my principle is to not break any existing platforms, and introduce new
> > approach, old platforms can work without any change.
> 
> But we don't know which platforms use what so we need to define a sane
> default configuration for all gadgets. I don't think we can have a gadget
> specific configuration.
> 
Yes, we don't know, what I can do is to keep all unchanged for those platforms
if those new properties doesn't appear at all. (i.e. SRP and HNP still enabled
in its otg descriptor anyway like current gadget driver does)

> If anyone complains we need to ask them to set the right DT flags for their
> platform. I don't see any other way.
> 

My current way is to achieve this goal.

> > 
> > > > 
> > > > But with enable flags, I can check all those 3 properties,
> > > 
> > > I don't see why you can't do that with disable flags. Note that there are 2 things.
> > > 1) disable flags from DT
> > > 2) support flags from controller. This information is already known to the
> > > controller.
> > > 
> > > Based on these 2 you can decide what OTG features you want to set/clear.
> > > And you can't combine the 2 by just defining enable flags in DT.
> > > 
> > 
> > Yes, I have the same understanding. So:
> > 1) In controller driver:
> > if (controller_can_support_srp(controller)) {

This check only can be done in each controller driver.

> > 	if (srp_enabled_in_dt(of))
> > 		gadget->srp_support = 1;
> 
> Existing platforms don't have feature_enabled_in_dt so this will fail for all.

Above code is for how "new" platform set new flags if it want to utilize those new
properties, existing platform doesn't need any code change. This is not common code
shared by all controller drivers, like gadget->is_otg, it should be set by specific
controller driver.

> So need to have
> 	if (srp_not_disabled_in_dt(of))
>  		gadget->srp_support = 1;

Maybe you think it's common code called by every platform.
I am putting it in my chipidea driver.

> 
> > }
> > 2) In gadget driver:
> > if (gadget->srp_support)
> > 	attribute |= SRP;
> 
> Agreed.
> 

You may take a look my 9/22 patch to see how existing platform is handled:

	if (gadget->adp_support || gadget->hnp_support ||
					gadget->srp_support) {
		/* means th
		if (gadget->adp_support)
			otg_desc->bmAttributes |= USB_OTG_ADP;
		if (gadget->hnp_support)
		otg_desc->bmAttributes |= USB_OTG_HNP;
		if (gadget->srp_support)
			otg_desc->bmAttributes |= USB_OTG_SRP;
	} else {
		otg_desc->bmAttributes = USB_OTG_SRP | USB_OTG_HNP;
	}

This is common code will be called by every platform.

Those existing platforms do not use those new flags of gadget, so all are 0,
then otg_desc->bmAttributes = USB_OTG_SRP | USB_OTG_HNP. This is current
"wrong" way.

If any platform want to use any new flags, then He must fully understand
those flags and change accordingly, set gadget->xxx_support in its controller
driver either by dt, or by other way(hard code...what ever).


> > 
> > > > 1)If none of them are passed, but gadget->is_otg == 1, I suppose it's
> > > > legacy platform, still set HNP and SRP as current gadget driver does,
> > > > works as before;
> > > > 2)If any one of them appear, I will set all those features by dt property.
> > > > 3)If some platform already based on those properties, wants to disable
> > > > all 3 OTG features, also not pass any one of them like 1), it will not
> > > > be a OTG device at all, set gadget->is_otg = 0 in its controller driver,
> > > > then no need set and report any OTG features, this can meet ID pin detect
> > > > case.
> > > 
> > > With enable flags you don't get what you set.
> > > e.g. in DT, we might set enable-adp.
> > > but if controller doesn't support adp, you don't have ADP working.
> > > So this is misleading.
> > > 
> > 
> > Why someone might do that? If someone adds some property which is not supported
> > by its controller, of cos this feature cannot work.
> 
> OK.
> 
> > 
> > If some platform utilize those new properties, both enable and disable flags
> > can work, but for those existing platforms with HNP/SRP support, they have
> > no any new flags in its DT, I need make it work as before.
> 
> Right, existing platforms need to work as is without DT changes. So features
> have to be enabled by default. That's another reason why we need disable-flags
> and not enable-flags in DT.

You are right if current code enables all 3 features by default,
Unfortunately only SRP and HNP are enabled, ADP is disabled,  

The key point here is, if none of new properties is added, are there 2 cases
which we cannot differentiate one from the other? 

By disable flags, if none passed in dt, there are 2 cases:
1) Legacy platforms(some may only support HNP and SRP, but no ADP).
2) New platform, it can really support all 3 features. 
I cannot differentiate 1) from 2), to correct set 1), I have to add
"adp-disable" for a legacy platform.

By enable flags, if none passed in dt, there are 2 cases:
1) Legacy platforms
2) New platform, it cannot support any features, so it's not a OTG device
   at all. Then the gadget->is_otg is 0, no any OTG related report needed.

> 
> cheers,
> -roger
> 
> > 
> > thanks Roger.
> > 
> > Li Jun
> > 
> > > cheers,
> > > -roger
> > > 
> > > >  
> > > > > > 
> > > > > > > But if the device manufacturer wants to restrict the OTG version
> > > > > > > to something less or disable some OTG features then the DT flags come
> > > > > > > into play.
> > > > > > 
> > > > > > Why would they?
> > > > > 
> > > > > Maybe they just don't want some of the features.
> > > > > one example is DRD mode. In DRD mode the controller works as host or
> > > > > peripheral but doesn't support dynamic role switching or host negotiation.
> > > > > 
> > > > > For that they can set
> > > > > 
> > > > > 	dr_mode = "otg"
> > > > > 	disable-adp;
> > > > > 	disable-hnp;
> > > > > 	disable-srp;
> > > > 
> > > > Other possible reasons maybe power saving, ADP need constantly do vbus
> > > > probe if there is no usb device connected, this will consume power.
> > > >  
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 05/22] doc: dt-binding: usb: add otg related properties

[Roger Quadros]

On Thu, 11 Jun 2015 22:11:22 +0800
Li Jun <b47624-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:

> On Thu, Jun 11, 2015 at 03:37:03PM +0300, Roger Quadros wrote:
> > 
> > On Thu, 11 Jun 2015 16:20:13 +0800
> > Li Jun <b47624-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> > 
> > > On Thu, Jun 11, 2015 at 10:18:53AM +0300, Roger Quadros wrote:
> > > > 
> > > > On Wed, 10 Jun 2015 21:47:51 +0800
> > > > Li Jun <b47624-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> > > > 
> > > > > On Wed, Jun 10, 2015 at 03:37:37PM +0800, Roger Quadros wrote:
> > > > > > On Tue, 9 Jun 2015 11:33:11 -0500
> > > > > > Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > > > > 
> > > > > > > On Tue, Jun 9, 2015 at 10:29 AM, Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org> wrote:
> > > > > > > > Rob,
> > > > > > > >
> > > > > > > > On Tue, 9 Jun 2015 08:26:20 -0500
> > > > > > > > Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > > > > > >
> > > > > > > >> On Mon, Jun 8, 2015 at 8:18 PM, Li Jun <b47624-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> > > > > > > >> > On Mon, Jun 08, 2015 at 11:06:49AM -0500, Rob Herring wrote:
> > > > > > > >> >> On Mon, Jun 8, 2015 at 10:02 AM, Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> > > > > > > >> >> > Add otg version, srp, hnp and adp support for usb OTG port, then those OTG
> > > > > > > >> >> > features don't have to be decided by usb gadget drivers.
> > > > > > > >> >> >
> > > > > > > >> >> > Signed-off-by: Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> > > > > > > >> >> > ---
> > > > > > > >> >> >  Documentation/devicetree/bindings/usb/generic.txt | 10 ++++++++++
> > > > > > > >> >> >  1 file changed, 10 insertions(+)
> > > > > > > >> >> >
> > > > > > > >> >> > diff --git a/Documentation/devicetree/bindings/usb/generic.txt b/Documentation/devicetree/bindings/usb/generic.txt
> > > > > > > >> >> > index 477d5bb..7386f4a 100644
> > > > > > > >> >> > --- a/Documentation/devicetree/bindings/usb/generic.txt
> > > > > > > >> >> > +++ b/Documentation/devicetree/bindings/usb/generic.txt
> > > > > > > >> >> > @@ -11,6 +11,12 @@ Optional properties:
> > > > > > > >> >> >                         "peripheral" and "otg". In case this attribute isn't
> > > > > > > >> >> >                         passed via DT, USB DRD controllers should default to
> > > > > > > >> >> >                         OTG.
> > > > > > > >> >> > + - otg-rev: tells usb driver the release number of the OTG and EH supplement
> > > > > > > >> >> > +                       with which the device and its descriptors are compliant,
> > > > > > > >> >> > +                       in binary-coded decimal (i.e. 2.0 is 0200H).
> > > > > > > >> >>
> > > > > > > >> >> I would assume OTG 2.0 is somehow backwards compatible? Is this a h/w
> > > > > > > >> >> dependency or a driver feature?
> > > > > > > >> >>
> > > > > > > >> > Not fully compatible, OTG 2.0 extend the usb_otg_descriptor by adding a new
> > > > > > > >> > member bcdOTG to identify the OTG version, this descriptor needs to be sent
> > > > > > > >> > to OTG host with correct size and content, so we have to know which release
> > > > > > > >> > version the OTG device is compliant with, either by menuconfig config or pass
> > > > > > > >> > via DT.
> > > > > > > >>
> > > > > > > >> So you have to change the version depending on the host you are
> > > > > > > >> connected to? That really seems strange that plugging in a OTG 2.0
> > > > > > > >> device to an OTG 1.3 host would not work and doesn't make for a good
> > > > > > > >> user experience.
> > > > > > > >
> > > > > > > > No. The OTG version in the OTG descriptor for any device is usually fixed for the
> > > > > > > > lifetime of the product.
> > > > > > > >
> > > > > > > > Let's assume it is 2.0.
> > > > > > > >
> > > > > > > > If you plug this to OTG 1.0 host, it won't be an issue as OTG 1.0 host doesn't
> > > > > > > > read the BCD version.
> > > > > > > 
> > > > > > > That makes sense, but there was some discussion about the size mattering.
> > > > > > > 
> > > > > > > So is there a reason not to always report 2.0 with any kernel that has
> > > > > > > 2.0 support?
> > > > > > 
> > > > > > A 2.0 host would still need to know if the attached OTG device is 1.0 or 2.0
> > > > > > so we don't want to force existing 1.0 devices to 2.0.
> > > > > > 
> > > > > > > 
> > > > > > > >>
> > > > > > > >> >> > + - srp-support: tells OTG controllers we want to enable SRP.
> > > > > > > >> >> > + - hnp-support: tells OTG controllers we want to enable HNP.
> > > > > > > >> >> > + - adp-support: tells OTG controllers we want to enable ADP.
> > > > > > > >> >>
> > > > > > > >> >> I've recently run into a problem[1] and found that I have to disable
> > > > > > > >> >> OTG in the kernel to get my device to work. Having to turn-off OTG
> > > > > > > >> >> seems like the wrong solution, and shifting the problem to DT seems
> > > > > > > >> >> wrong too. Why is this not a user configurable option (within whatever
> > > > > > > >> >> h/w constraints there are)?
> > > > > > > >> > The problem of below link, seems your device is claiming it's a HNP capable
> > > > > > > >> > OTG device, but connecting to a non-OTG port of your Host, assume your Host
> > > > > > > >> > does have a OTG port, your Host issue a A_ALT_HNP_SUPPORT request to your
> > > > > > > >> > OTG device to remind it can use another port with HNP, but the request failed
> > > > > > > >> > (maybe STALL by your device, this request is defined in OTG 1.3 but obsolete
> > > > > > > >> > in OTG 2.0), so your Host just stopped enumeration of your device, this is not
> > > > > > > >> > reasonable because current OTG code is some out of data.
> > > > > > > >>
> > > > > > > >> Do PCs have OTG ports typically? My expectation is that if I plug in
> > > > > > > >> an OTG device as a B device to any host port, that it will work as a
> > > > > > > >> device no matter what the host OTG capabilities are. If I have to
> > > > > > > >> change the kernel config or DT, that is a problem.
> > > > > > > >
> > > > > > > > AFAIK PCs don't have OTG ports.
> > > > > > > >
> > > > > > > > If you plug in OTG device to a non-otg host port it will work as normal B-device.
> > > > > > > > The host doesn't request for OTG descriptors and doesn't care what OTG features it
> > > > > > > > supports or not.
> > > > > > > 
> > > > > > > That is what I would expect. My testing and the bug report show otherwise.
> > > > > > 
> > > > > > what kernel and platform are you on?
> > > > > > 
> > > > > > > 
> > > > > > > >> > I am trying to make those OTG feaures to be configurable options, you mean
> > > > > > > >> > by sys?
> > > > > > > >>
> > > > > > > >> Yes.
> > > > > > > >
> > > > > > > > why do you need OTG features to be sysfs configurable other than for debugging?
> > > > > > > 
> > > > > > > I don't know. Buggy host perhaps? Why do you need them in DT?
> > > > > > 
> > > > > > I'll explain why we need in DT below.
> > > > > > 
> > > > > > > 
> > > > > > > If they are truly debugging, then they would belong in debugfs rather
> > > > > > > than sysfs.
> > > > > > 
> > > > > > agreed.
> > > > > > > 
> > > > > > > >> >> What are the valid combinations? When do we want these enabled or not?
> > > > > > > >> >> Wouldn't default enabled be better?
> > > > > > > >> >
> > > > > > > >> > We want to enable all those support in kernel driver, but some platform or
> > > > > > > >> > hardware may not want to enable any or some of them, so those hardware
> > > > > > > >> > can disable it by not pass the property in dt, the 3 sub features of OTG are
> > > > > > > >> > not mandatory for so called OTG device, normally we at least enable HNP, and
> > > > > > > >> > SRP and ADP are optional.
> > > > > > > >>
> > > > > > > >> Please answer my questions in the doc.
> > > > > > > >>
> > > > > > > >> >>
> > > > > > > >> >> We already have dr_mode property. How is it related to these?
> > > > > > > >
> > > > > > > > dr_mode states what mode the controller will operate in.
> > > > > > > >
> > > > > > > > for dr_mode == "host" we don't care about these otg flags.
> > > > > > > >
> > > > > > > > for dr_mode == "peripheral" or dr_mode == "otg"
> > > > > > > > we care about these OTG flags to create our OTG descriptor on the fly.
> > > > > > > 
> > > > > > > Then how do I specify my device is peripheral only even though I have
> > > > > > > a DR controller?
> > > > > > 
> > > > > > by specifying dr_mode = "peripheral" in the DT.
> > > > > > 
> > > > > > > 
> > > > > > > How is ID pin detect supposed to be supported? Do we need dr_mode = "idpin"?
> > > > > > 
> > > > > > ID pin is not used in single role mode. It will be used only when dr_mode = "otg".
> > > > > > 
> > > > > > > 
> > > > > > > >> > dr_mode is to tell the device it will work at OTG mode(there is another simple
> > > > > > > >> > dual role mode which is commom used but not HNP), srp/hnp/adp can further specify
> > > > > > > >> > which protocol the OTG device will support.
> > > > > > > >>
> > > > > > > >> By simple DR, you mean ID pin detect, right. So please define how you
> > > > > > > >> support just ID pin detect vs. other levels of capability. Does only
> > > > > > > >> dr_mode = otg mean ID pin detect? That may be a problem for existing
> > > > > > > >> DTs if you disable other OTG functions because they have not been
> > > > > > > >> added to the DT, then that is a problem.
> > > > > > > >>
> > > > > > > >> I'm feeling less convinced that this belongs in DT at all. Please
> > > > > > > >> convince me otherwise.
> > > > > > > >
> > > > > > > > Yes not specifying anything in DT should work and default to the
> > > > > > > > best OTG version and features supported by the OTG controller.
> > > > > > > 
> > > > > > > Right, hence why I suggested disable flags, not enable flags.
> > > > > > 
> > > > > > I second that. They must be disable flags.
> > > > > > 
> > > > > 
> > > > > Disable flags may not work with current situation of gadget driver:
> > > > > Currently each gadget class driver hard coded the OTG attributes
> > > > > to be HNP | SRP, independent of controller driver.
> > > > 
> > > > That is wrong in the first place. Gadget drivers shouldn't decide
> > > > the OTG attributes. Platform code/DT should.
> > > > 
> > > 
> > > I totally agree the current code is wrong.
> > > 
> > > > If gadget drivers define OTG flags then they cannot be used on
> > > > different platforms with different OTG needs.
> > > > 
> > > Agree too.
> > > 
> > > But some platforms may already work with current "wrong" way, I do not want
> > > to break them.
> > > 
> > > > > 
> > > > > E.g. some platform with OTG enabled: gadget->is_otg = 1
> > > > > HNP and SRP are enabled by gadget driver, ADP = 0, this OTG port
> > > > > can really support HNP and SRP, but not ADP. 
> > > > 
> > > > What if the platform on which the gadget driver is used doesn't want
> > > > SRP enabled?
> > > 
> > > As far as I know, there is no controller driver to override this setting,
> > > maybe it still keeps SRP enabled even it does not support it in fact. 
> > > 
> > > > 
> > > > > if use disable flag, this platform has to add adp-disable property
> > > > > otherwise it will report ADP support to the host.
> > > > 
> > > > This issue won't happen if gadget driver doesn't define any OTG attributes.
> > > > 
> > > But some existing platform already rely on gadget driver to define OTG
> > > attributes, Can I break those already working platforms? I think it's hard
> > > to figure out all this kind of platforms and then correct every one with
> > > new approach.
> > > 
> > > Who define this attributes doesn't matter, key is this attributes should
> > > base on correct input.
> > > 
> > > So my principle is to not break any existing platforms, and introduce new
> > > approach, old platforms can work without any change.
> > 
> > But we don't know which platforms use what so we need to define a sane
> > default configuration for all gadgets. I don't think we can have a gadget
> > specific configuration.
> > 
> Yes, we don't know, what I can do is to keep all unchanged for those platforms
> if those new properties doesn't appear at all. (i.e. SRP and HNP still enabled
> in its otg descriptor anyway like current gadget driver does)
> 
> > If anyone complains we need to ask them to set the right DT flags for their
> > platform. I don't see any other way.
> > 
> 
> My current way is to achieve this goal.
> 
> > > 
> > > > > 
> > > > > But with enable flags, I can check all those 3 properties,
> > > > 
> > > > I don't see why you can't do that with disable flags. Note that there are 2 things.
> > > > 1) disable flags from DT
> > > > 2) support flags from controller. This information is already known to the
> > > > controller.
> > > > 
> > > > Based on these 2 you can decide what OTG features you want to set/clear.
> > > > And you can't combine the 2 by just defining enable flags in DT.
> > > > 
> > > 
> > > Yes, I have the same understanding. So:
> > > 1) In controller driver:
> > > if (controller_can_support_srp(controller)) {
> 
> This check only can be done in each controller driver.
> 
> > > 	if (srp_enabled_in_dt(of))
> > > 		gadget->srp_support = 1;
> > 
> > Existing platforms don't have feature_enabled_in_dt so this will fail for all.
> 
> Above code is for how "new" platform set new flags if it want to utilize those new
> properties, existing platform doesn't need any code change. This is not common code
> shared by all controller drivers, like gadget->is_otg, it should be set by specific
> controller driver.
> 
> > So need to have
> > 	if (srp_not_disabled_in_dt(of))
> >  		gadget->srp_support = 1;
> 
> Maybe you think it's common code called by every platform.
> I am putting it in my chipidea driver.
> 
> > 
> > > }
> > > 2) In gadget driver:
> > > if (gadget->srp_support)
> > > 	attribute |= SRP;
> > 
> > Agreed.
> > 
> 
> You may take a look my 9/22 patch to see how existing platform is handled:
> 
> 	if (gadget->adp_support || gadget->hnp_support ||
> 					gadget->srp_support) {
> 		/* means th
> 		if (gadget->adp_support)
> 			otg_desc->bmAttributes |= USB_OTG_ADP;
> 		if (gadget->hnp_support)
> 		otg_desc->bmAttributes |= USB_OTG_HNP;
> 		if (gadget->srp_support)
> 			otg_desc->bmAttributes |= USB_OTG_SRP;
> 	} else {
> 		otg_desc->bmAttributes = USB_OTG_SRP | USB_OTG_HNP;
> 	}
> 
> This is common code will be called by every platform.

So you are using  gadget->xyz_support flags to determine if it is a legacy
platform and that's why we have a problem with having disable flags in DT.

This also has a side effect of SRP and HNP being enabled for any platform
even if enable-srp/enable-hnp is not set in DT.
This will be more of a bug than supporting legacy users.

Instead we could have ADP disabled by default for all cases
and expect enable-adp in DT to get it enabled. SRP/HNP could still
be disable flags.

Then your above code reduces to

		if (gadget->adp_support)
 			otg_desc->bmAttributes |= USB_OTG_ADP;
 		if (gadget->hnp_support)
 			otg_desc->bmAttributes |= USB_OTG_HNP;
 		if (gadget->srp_support)
 			otg_desc->bmAttributes |= USB_OTG_SRP;

cheers,
-roger

> 
> Those existing platforms do not use those new flags of gadget, so all are 0,
> then otg_desc->bmAttributes = USB_OTG_SRP | USB_OTG_HNP. This is current
> "wrong" way.
> 
> If any platform want to use any new flags, then He must fully understand
> those flags and change accordingly, set gadget->xxx_support in its controller
> driver either by dt, or by other way(hard code...what ever).
> 
> 
> > > 
> > > > > 1)If none of them are passed, but gadget->is_otg == 1, I suppose it's
> > > > > legacy platform, still set HNP and SRP as current gadget driver does,
> > > > > works as before;
> > > > > 2)If any one of them appear, I will set all those features by dt property.
> > > > > 3)If some platform already based on those properties, wants to disable
> > > > > all 3 OTG features, also not pass any one of them like 1), it will not
> > > > > be a OTG device at all, set gadget->is_otg = 0 in its controller driver,
> > > > > then no need set and report any OTG features, this can meet ID pin detect
> > > > > case.
> > > > 
> > > > With enable flags you don't get what you set.
> > > > e.g. in DT, we might set enable-adp.
> > > > but if controller doesn't support adp, you don't have ADP working.
> > > > So this is misleading.
> > > > 
> > > 
> > > Why someone might do that? If someone adds some property which is not supported
> > > by its controller, of cos this feature cannot work.
> > 
> > OK.
> > 
> > > 
> > > If some platform utilize those new properties, both enable and disable flags
> > > can work, but for those existing platforms with HNP/SRP support, they have
> > > no any new flags in its DT, I need make it work as before.
> > 
> > Right, existing platforms need to work as is without DT changes. So features
> > have to be enabled by default. That's another reason why we need disable-flags
> > and not enable-flags in DT.
> 
> You are right if current code enables all 3 features by default,
> Unfortunately only SRP and HNP are enabled, ADP is disabled,  
> 
> The key point here is, if none of new properties is added, are there 2 cases
> which we cannot differentiate one from the other? 
> 
> By disable flags, if none passed in dt, there are 2 cases:
> 1) Legacy platforms(some may only support HNP and SRP, but no ADP).
> 2) New platform, it can really support all 3 features. 
> I cannot differentiate 1) from 2), to correct set 1), I have to add
> "adp-disable" for a legacy platform.
> 
> By enable flags, if none passed in dt, there are 2 cases:
> 1) Legacy platforms
> 2) New platform, it cannot support any features, so it's not a OTG device
>    at all. Then the gadget->is_otg is 0, no any OTG related report needed.
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 05/22] doc: dt-binding: usb: add otg related properties

[Li Jun]

On Thu, Jun 11, 2015 at 05:52:15PM +0300, Roger Quadros wrote:
> 
> On Thu, 11 Jun 2015 22:11:22 +0800
> Li Jun <b47624-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> 
> > On Thu, Jun 11, 2015 at 03:37:03PM +0300, Roger Quadros wrote:
> > > 
> > > On Thu, 11 Jun 2015 16:20:13 +0800
> > > Li Jun <b47624-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> > > 
> > > > On Thu, Jun 11, 2015 at 10:18:53AM +0300, Roger Quadros wrote:
> > > > > 
> > > > > On Wed, 10 Jun 2015 21:47:51 +0800
> > > > > Li Jun <b47624-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> > > > > 
> > > > > > On Wed, Jun 10, 2015 at 03:37:37PM +0800, Roger Quadros wrote:
> > > > > > > On Tue, 9 Jun 2015 11:33:11 -0500
> > > > > > > Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > > > > > 
> > > > > > > > On Tue, Jun 9, 2015 at 10:29 AM, Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org> wrote:
> > > > > > > > > Rob,
> > > > > > > > >
> > > > > > > > > On Tue, 9 Jun 2015 08:26:20 -0500
> > > > > > > > > Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > > > > > > >
> > > > > > > > >> On Mon, Jun 8, 2015 at 8:18 PM, Li Jun <b47624-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> > > > > > > > >> > On Mon, Jun 08, 2015 at 11:06:49AM -0500, Rob Herring wrote:
> > > > > > > > >> >> On Mon, Jun 8, 2015 at 10:02 AM, Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> > > > > > > > >> >> > Add otg version, srp, hnp and adp support for usb OTG port, then those OTG
> > > > > > > > >> >> > features don't have to be decided by usb gadget drivers.
> > > > > > > > >> >> >
> > > > > > > > >> >> > Signed-off-by: Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> > > > > > > > >> >> > ---
> > > > > > > > >> >> >  Documentation/devicetree/bindings/usb/generic.txt | 10 ++++++++++
> > > > > > > > >> >> >  1 file changed, 10 insertions(+)
> > > > > > > > >> >> >
> > > > > > > > >> >> > diff --git a/Documentation/devicetree/bindings/usb/generic.txt b/Documentation/devicetree/bindings/usb/generic.txt
> > > > > > > > >> >> > index 477d5bb..7386f4a 100644
> > > > > > > > >> >> > --- a/Documentation/devicetree/bindings/usb/generic.txt
> > > > > > > > >> >> > +++ b/Documentation/devicetree/bindings/usb/generic.txt
> > > > > > > > >> >> > @@ -11,6 +11,12 @@ Optional properties:
> > > > > > > > >> >> >                         "peripheral" and "otg". In case this attribute isn't
> > > > > > > > >> >> >                         passed via DT, USB DRD controllers should default to
> > > > > > > > >> >> >                         OTG.
> > > > > > > > >> >> > + - otg-rev: tells usb driver the release number of the OTG and EH supplement
> > > > > > > > >> >> > +                       with which the device and its descriptors are compliant,
> > > > > > > > >> >> > +                       in binary-coded decimal (i.e. 2.0 is 0200H).
> > > > > > > > >> >>
> > > > > > > > >> >> I would assume OTG 2.0 is somehow backwards compatible? Is this a h/w
> > > > > > > > >> >> dependency or a driver feature?
> > > > > > > > >> >>
> > > > > > > > >> > Not fully compatible, OTG 2.0 extend the usb_otg_descriptor by adding a new
> > > > > > > > >> > member bcdOTG to identify the OTG version, this descriptor needs to be sent
> > > > > > > > >> > to OTG host with correct size and content, so we have to know which release
> > > > > > > > >> > version the OTG device is compliant with, either by menuconfig config or pass
> > > > > > > > >> > via DT.
> > > > > > > > >>
> > > > > > > > >> So you have to change the version depending on the host you are
> > > > > > > > >> connected to? That really seems strange that plugging in a OTG 2.0
> > > > > > > > >> device to an OTG 1.3 host would not work and doesn't make for a good
> > > > > > > > >> user experience.
> > > > > > > > >
> > > > > > > > > No. The OTG version in the OTG descriptor for any device is usually fixed for the
> > > > > > > > > lifetime of the product.
> > > > > > > > >
> > > > > > > > > Let's assume it is 2.0.
> > > > > > > > >
> > > > > > > > > If you plug this to OTG 1.0 host, it won't be an issue as OTG 1.0 host doesn't
> > > > > > > > > read the BCD version.
> > > > > > > > 
> > > > > > > > That makes sense, but there was some discussion about the size mattering.
> > > > > > > > 
> > > > > > > > So is there a reason not to always report 2.0 with any kernel that has
> > > > > > > > 2.0 support?
> > > > > > > 
> > > > > > > A 2.0 host would still need to know if the attached OTG device is 1.0 or 2.0
> > > > > > > so we don't want to force existing 1.0 devices to 2.0.
> > > > > > > 
> > > > > > > > 
> > > > > > > > >>
> > > > > > > > >> >> > + - srp-support: tells OTG controllers we want to enable SRP.
> > > > > > > > >> >> > + - hnp-support: tells OTG controllers we want to enable HNP.
> > > > > > > > >> >> > + - adp-support: tells OTG controllers we want to enable ADP.
> > > > > > > > >> >>
> > > > > > > > >> >> I've recently run into a problem[1] and found that I have to disable
> > > > > > > > >> >> OTG in the kernel to get my device to work. Having to turn-off OTG
> > > > > > > > >> >> seems like the wrong solution, and shifting the problem to DT seems
> > > > > > > > >> >> wrong too. Why is this not a user configurable option (within whatever
> > > > > > > > >> >> h/w constraints there are)?
> > > > > > > > >> > The problem of below link, seems your device is claiming it's a HNP capable
> > > > > > > > >> > OTG device, but connecting to a non-OTG port of your Host, assume your Host
> > > > > > > > >> > does have a OTG port, your Host issue a A_ALT_HNP_SUPPORT request to your
> > > > > > > > >> > OTG device to remind it can use another port with HNP, but the request failed
> > > > > > > > >> > (maybe STALL by your device, this request is defined in OTG 1.3 but obsolete
> > > > > > > > >> > in OTG 2.0), so your Host just stopped enumeration of your device, this is not
> > > > > > > > >> > reasonable because current OTG code is some out of data.
> > > > > > > > >>
> > > > > > > > >> Do PCs have OTG ports typically? My expectation is that if I plug in
> > > > > > > > >> an OTG device as a B device to any host port, that it will work as a
> > > > > > > > >> device no matter what the host OTG capabilities are. If I have to
> > > > > > > > >> change the kernel config or DT, that is a problem.
> > > > > > > > >
> > > > > > > > > AFAIK PCs don't have OTG ports.
> > > > > > > > >
> > > > > > > > > If you plug in OTG device to a non-otg host port it will work as normal B-device.
> > > > > > > > > The host doesn't request for OTG descriptors and doesn't care what OTG features it
> > > > > > > > > supports or not.
> > > > > > > > 
> > > > > > > > That is what I would expect. My testing and the bug report show otherwise.
> > > > > > > 
> > > > > > > what kernel and platform are you on?
> > > > > > > 
> > > > > > > > 
> > > > > > > > >> > I am trying to make those OTG feaures to be configurable options, you mean
> > > > > > > > >> > by sys?
> > > > > > > > >>
> > > > > > > > >> Yes.
> > > > > > > > >
> > > > > > > > > why do you need OTG features to be sysfs configurable other than for debugging?
> > > > > > > > 
> > > > > > > > I don't know. Buggy host perhaps? Why do you need them in DT?
> > > > > > > 
> > > > > > > I'll explain why we need in DT below.
> > > > > > > 
> > > > > > > > 
> > > > > > > > If they are truly debugging, then they would belong in debugfs rather
> > > > > > > > than sysfs.
> > > > > > > 
> > > > > > > agreed.
> > > > > > > > 
> > > > > > > > >> >> What are the valid combinations? When do we want these enabled or not?
> > > > > > > > >> >> Wouldn't default enabled be better?
> > > > > > > > >> >
> > > > > > > > >> > We want to enable all those support in kernel driver, but some platform or
> > > > > > > > >> > hardware may not want to enable any or some of them, so those hardware
> > > > > > > > >> > can disable it by not pass the property in dt, the 3 sub features of OTG are
> > > > > > > > >> > not mandatory for so called OTG device, normally we at least enable HNP, and
> > > > > > > > >> > SRP and ADP are optional.
> > > > > > > > >>
> > > > > > > > >> Please answer my questions in the doc.
> > > > > > > > >>
> > > > > > > > >> >>
> > > > > > > > >> >> We already have dr_mode property. How is it related to these?
> > > > > > > > >
> > > > > > > > > dr_mode states what mode the controller will operate in.
> > > > > > > > >
> > > > > > > > > for dr_mode == "host" we don't care about these otg flags.
> > > > > > > > >
> > > > > > > > > for dr_mode == "peripheral" or dr_mode == "otg"
> > > > > > > > > we care about these OTG flags to create our OTG descriptor on the fly.
> > > > > > > > 
> > > > > > > > Then how do I specify my device is peripheral only even though I have
> > > > > > > > a DR controller?
> > > > > > > 
> > > > > > > by specifying dr_mode = "peripheral" in the DT.
> > > > > > > 
> > > > > > > > 
> > > > > > > > How is ID pin detect supposed to be supported? Do we need dr_mode = "idpin"?
> > > > > > > 
> > > > > > > ID pin is not used in single role mode. It will be used only when dr_mode = "otg".
> > > > > > > 
> > > > > > > > 
> > > > > > > > >> > dr_mode is to tell the device it will work at OTG mode(there is another simple
> > > > > > > > >> > dual role mode which is commom used but not HNP), srp/hnp/adp can further specify
> > > > > > > > >> > which protocol the OTG device will support.
> > > > > > > > >>
> > > > > > > > >> By simple DR, you mean ID pin detect, right. So please define how you
> > > > > > > > >> support just ID pin detect vs. other levels of capability. Does only
> > > > > > > > >> dr_mode = otg mean ID pin detect? That may be a problem for existing
> > > > > > > > >> DTs if you disable other OTG functions because they have not been
> > > > > > > > >> added to the DT, then that is a problem.
> > > > > > > > >>
> > > > > > > > >> I'm feeling less convinced that this belongs in DT at all. Please
> > > > > > > > >> convince me otherwise.
> > > > > > > > >
> > > > > > > > > Yes not specifying anything in DT should work and default to the
> > > > > > > > > best OTG version and features supported by the OTG controller.
> > > > > > > > 
> > > > > > > > Right, hence why I suggested disable flags, not enable flags.
> > > > > > > 
> > > > > > > I second that. They must be disable flags.
> > > > > > > 
> > > > > > 
> > > > > > Disable flags may not work with current situation of gadget driver:
> > > > > > Currently each gadget class driver hard coded the OTG attributes
> > > > > > to be HNP | SRP, independent of controller driver.
> > > > > 
> > > > > That is wrong in the first place. Gadget drivers shouldn't decide
> > > > > the OTG attributes. Platform code/DT should.
> > > > > 
> > > > 
> > > > I totally agree the current code is wrong.
> > > > 
> > > > > If gadget drivers define OTG flags then they cannot be used on
> > > > > different platforms with different OTG needs.
> > > > > 
> > > > Agree too.
> > > > 
> > > > But some platforms may already work with current "wrong" way, I do not want
> > > > to break them.
> > > > 
> > > > > > 
> > > > > > E.g. some platform with OTG enabled: gadget->is_otg = 1
> > > > > > HNP and SRP are enabled by gadget driver, ADP = 0, this OTG port
> > > > > > can really support HNP and SRP, but not ADP. 
> > > > > 
> > > > > What if the platform on which the gadget driver is used doesn't want
> > > > > SRP enabled?
> > > > 
> > > > As far as I know, there is no controller driver to override this setting,
> > > > maybe it still keeps SRP enabled even it does not support it in fact. 
> > > > 
> > > > > 
> > > > > > if use disable flag, this platform has to add adp-disable property
> > > > > > otherwise it will report ADP support to the host.
> > > > > 
> > > > > This issue won't happen if gadget driver doesn't define any OTG attributes.
> > > > > 
> > > > But some existing platform already rely on gadget driver to define OTG
> > > > attributes, Can I break those already working platforms? I think it's hard
> > > > to figure out all this kind of platforms and then correct every one with
> > > > new approach.
> > > > 
> > > > Who define this attributes doesn't matter, key is this attributes should
> > > > base on correct input.
> > > > 
> > > > So my principle is to not break any existing platforms, and introduce new
> > > > approach, old platforms can work without any change.
> > > 
> > > But we don't know which platforms use what so we need to define a sane
> > > default configuration for all gadgets. I don't think we can have a gadget
> > > specific configuration.
> > > 
> > Yes, we don't know, what I can do is to keep all unchanged for those platforms
> > if those new properties doesn't appear at all. (i.e. SRP and HNP still enabled
> > in its otg descriptor anyway like current gadget driver does)
> > 
> > > If anyone complains we need to ask them to set the right DT flags for their
> > > platform. I don't see any other way.
> > > 
> > 
> > My current way is to achieve this goal.
> > 
> > > > 
> > > > > > 
> > > > > > But with enable flags, I can check all those 3 properties,
> > > > > 
> > > > > I don't see why you can't do that with disable flags. Note that there are 2 things.
> > > > > 1) disable flags from DT
> > > > > 2) support flags from controller. This information is already known to the
> > > > > controller.
> > > > > 
> > > > > Based on these 2 you can decide what OTG features you want to set/clear.
> > > > > And you can't combine the 2 by just defining enable flags in DT.
> > > > > 
> > > > 
> > > > Yes, I have the same understanding. So:
> > > > 1) In controller driver:
> > > > if (controller_can_support_srp(controller)) {
> > 
> > This check only can be done in each controller driver.
> > 
> > > > 	if (srp_enabled_in_dt(of))
> > > > 		gadget->srp_support = 1;
> > > 
> > > Existing platforms don't have feature_enabled_in_dt so this will fail for all.
> > 
> > Above code is for how "new" platform set new flags if it want to utilize those new
> > properties, existing platform doesn't need any code change. This is not common code
> > shared by all controller drivers, like gadget->is_otg, it should be set by specific
> > controller driver.
> > 
> > > So need to have
> > > 	if (srp_not_disabled_in_dt(of))
> > >  		gadget->srp_support = 1;
> > 
> > Maybe you think it's common code called by every platform.
> > I am putting it in my chipidea driver.
> > 
> > > 
> > > > }
> > > > 2) In gadget driver:
> > > > if (gadget->srp_support)
> > > > 	attribute |= SRP;
> > > 
> > > Agreed.
> > > 
> > 
> > You may take a look my 9/22 patch to see how existing platform is handled:
> > 
> > 	if (gadget->adp_support || gadget->hnp_support ||
> > 					gadget->srp_support) {
> > 		/* means th
> > 		if (gadget->adp_support)
> > 			otg_desc->bmAttributes |= USB_OTG_ADP;
> > 		if (gadget->hnp_support)
> > 		otg_desc->bmAttributes |= USB_OTG_HNP;
> > 		if (gadget->srp_support)
> > 			otg_desc->bmAttributes |= USB_OTG_SRP;
> > 	} else {
> > 		otg_desc->bmAttributes = USB_OTG_SRP | USB_OTG_HNP;
> > 	}
> > 
> > This is common code will be called by every platform.
> 
> So you are using  gadget->xyz_support flags to determine if it is a legacy
> platform and that's why we have a problem with having disable flags in DT.
> 
Other than those new flags, I have not found other good way to judge
whether some platform is a legacy one.
Directly use dt property? Then above code has to be moved to controller
driver, consequently the usb_otg_descriptor has to be allocated by
controller driver at runtime, and I have to create some new way to pass it
to gadget driver, for those legacy platform, I still need gadget driver to
allocate it...too complicated.

(You know, there are 2 different otg_desc structures: otg_desc and
otg_20_desc, I need select one and allocate it at runtime)

> This also has a side effect of SRP and HNP being enabled for any platform
> even if enable-srp/enable-hnp is not set in DT.
That's the current situation before my patch, not the side effect
brought by me.

> This will be more of a bug than supporting legacy users.
I have to leave the _existing_ bug there, because I can't know
which platform can really support HNP/SRP, which one cannot.
So I do not fix the _existing_ bug, meanwhile I also do not introduce
a new bug either. If some legacy platform with this bug, want to fix it,
fine, use dt or other way to set gadget->xyz_support correctly
in its controller driver, no more change needed.

Any other reason you think enable flags are still not reasonable?

> 
> Instead we could have ADP disabled by default for all cases
> and expect enable-adp in DT to get it enabled. SRP/HNP could still
> be disable flags.
> 
Yes, this can work, but seems they look some odd:), some are xxx_disable,
some are xxx_enable.
 
> Then your above code reduces to
> 
> 		if (gadget->adp_support)
>  			otg_desc->bmAttributes |= USB_OTG_ADP;
>  		if (gadget->hnp_support)
>  			otg_desc->bmAttributes |= USB_OTG_HNP;
>  		if (gadget->srp_support)
>  			otg_desc->bmAttributes |= USB_OTG_SRP;
>
Yes if those code is put in controller driver of new platforms.
No if we put it in common routine and called by both new and
legacy platforms.

> cheers,
> -roger
> 
> > 
> > Those existing platforms do not use those new flags of gadget, so all are 0,
> > then otg_desc->bmAttributes = USB_OTG_SRP | USB_OTG_HNP. This is current
> > "wrong" way.
> > 
> > If any platform want to use any new flags, then He must fully understand
> > those flags and change accordingly, set gadget->xxx_support in its controller
> > driver either by dt, or by other way(hard code...what ever).
> > 
> > 
> > > > 
> > > > > > 1)If none of them are passed, but gadget->is_otg == 1, I suppose it's
> > > > > > legacy platform, still set HNP and SRP as current gadget driver does,
> > > > > > works as before;
> > > > > > 2)If any one of them appear, I will set all those features by dt property.
> > > > > > 3)If some platform already based on those properties, wants to disable
> > > > > > all 3 OTG features, also not pass any one of them like 1), it will not
> > > > > > be a OTG device at all, set gadget->is_otg = 0 in its controller driver,
> > > > > > then no need set and report any OTG features, this can meet ID pin detect
> > > > > > case.
> > > > > 
> > > > > With enable flags you don't get what you set.
> > > > > e.g. in DT, we might set enable-adp.
> > > > > but if controller doesn't support adp, you don't have ADP working.
> > > > > So this is misleading.
> > > > > 
> > > > 
> > > > Why someone might do that? If someone adds some property which is not supported
> > > > by its controller, of cos this feature cannot work.
> > > 
> > > OK.
> > > 
> > > > 
> > > > If some platform utilize those new properties, both enable and disable flags
> > > > can work, but for those existing platforms with HNP/SRP support, they have
> > > > no any new flags in its DT, I need make it work as before.
> > > 
> > > Right, existing platforms need to work as is without DT changes. So features
> > > have to be enabled by default. That's another reason why we need disable-flags
> > > and not enable-flags in DT.
> > 
> > You are right if current code enables all 3 features by default,
> > Unfortunately only SRP and HNP are enabled, ADP is disabled,  
> > 
> > The key point here is, if none of new properties is added, are there 2 cases
> > which we cannot differentiate one from the other? 
> > 
> > By disable flags, if none passed in dt, there are 2 cases:
> > 1) Legacy platforms(some may only support HNP and SRP, but no ADP).
> > 2) New platform, it can really support all 3 features. 
> > I cannot differentiate 1) from 2), to correct set 1), I have to add
> > "adp-disable" for a legacy platform.
> > 
> > By enable flags, if none passed in dt, there are 2 cases:
> > 1) Legacy platforms
> > 2) New platform, it cannot support any features, so it's not a OTG device
> >    at all. Then the gadget->is_otg is 0, no any OTG related report needed.
> > 
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 05/22] doc: dt-binding: usb: add otg related properties

[Roger Quadros]

On Fri, 12 Jun 2015 11:09:17 +0800
Li Jun <b47624-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:

> On Thu, Jun 11, 2015 at 05:52:15PM +0300, Roger Quadros wrote:
> > 
> > On Thu, 11 Jun 2015 22:11:22 +0800
> > Li Jun <b47624-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> > 
> > > On Thu, Jun 11, 2015 at 03:37:03PM +0300, Roger Quadros wrote:
> > > > 
> > > > On Thu, 11 Jun 2015 16:20:13 +0800
> > > > Li Jun <b47624-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> > > > 
> > > > > On Thu, Jun 11, 2015 at 10:18:53AM +0300, Roger Quadros wrote:
> > > > > > 
> > > > > > On Wed, 10 Jun 2015 21:47:51 +0800
> > > > > > Li Jun <b47624-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> > > > > > 
> > > > > > > On Wed, Jun 10, 2015 at 03:37:37PM +0800, Roger Quadros wrote:
> > > > > > > > On Tue, 9 Jun 2015 11:33:11 -0500
> > > > > > > > Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > > > > > > 
> > > > > > > > > On Tue, Jun 9, 2015 at 10:29 AM, Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org> wrote:
> > > > > > > > > > Rob,
> > > > > > > > > >
> > > > > > > > > > On Tue, 9 Jun 2015 08:26:20 -0500
> > > > > > > > > > Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > > > > > > > >
> > > > > > > > > >> On Mon, Jun 8, 2015 at 8:18 PM, Li Jun <b47624-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> > > > > > > > > >> > On Mon, Jun 08, 2015 at 11:06:49AM -0500, Rob Herring wrote:
> > > > > > > > > >> >> On Mon, Jun 8, 2015 at 10:02 AM, Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> > > > > > > > > >> >> > Add otg version, srp, hnp and adp support for usb OTG port, then those OTG
> > > > > > > > > >> >> > features don't have to be decided by usb gadget drivers.
> > > > > > > > > >> >> >
> > > > > > > > > >> >> > Signed-off-by: Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> > > > > > > > > >> >> > ---
> > > > > > > > > >> >> >  Documentation/devicetree/bindings/usb/generic.txt | 10 ++++++++++
> > > > > > > > > >> >> >  1 file changed, 10 insertions(+)
> > > > > > > > > >> >> >
> > > > > > > > > >> >> > diff --git a/Documentation/devicetree/bindings/usb/generic.txt b/Documentation/devicetree/bindings/usb/generic.txt
> > > > > > > > > >> >> > index 477d5bb..7386f4a 100644
> > > > > > > > > >> >> > --- a/Documentation/devicetree/bindings/usb/generic.txt
> > > > > > > > > >> >> > +++ b/Documentation/devicetree/bindings/usb/generic.txt
> > > > > > > > > >> >> > @@ -11,6 +11,12 @@ Optional properties:
> > > > > > > > > >> >> >                         "peripheral" and "otg". In case this attribute isn't
> > > > > > > > > >> >> >                         passed via DT, USB DRD controllers should default to
> > > > > > > > > >> >> >                         OTG.
> > > > > > > > > >> >> > + - otg-rev: tells usb driver the release number of the OTG and EH supplement
> > > > > > > > > >> >> > +                       with which the device and its descriptors are compliant,
> > > > > > > > > >> >> > +                       in binary-coded decimal (i.e. 2.0 is 0200H).
> > > > > > > > > >> >>
> > > > > > > > > >> >> I would assume OTG 2.0 is somehow backwards compatible? Is this a h/w
> > > > > > > > > >> >> dependency or a driver feature?
> > > > > > > > > >> >>
> > > > > > > > > >> > Not fully compatible, OTG 2.0 extend the usb_otg_descriptor by adding a new
> > > > > > > > > >> > member bcdOTG to identify the OTG version, this descriptor needs to be sent
> > > > > > > > > >> > to OTG host with correct size and content, so we have to know which release
> > > > > > > > > >> > version the OTG device is compliant with, either by menuconfig config or pass
> > > > > > > > > >> > via DT.
> > > > > > > > > >>
> > > > > > > > > >> So you have to change the version depending on the host you are
> > > > > > > > > >> connected to? That really seems strange that plugging in a OTG 2.0
> > > > > > > > > >> device to an OTG 1.3 host would not work and doesn't make for a good
> > > > > > > > > >> user experience.
> > > > > > > > > >
> > > > > > > > > > No. The OTG version in the OTG descriptor for any device is usually fixed for the
> > > > > > > > > > lifetime of the product.
> > > > > > > > > >
> > > > > > > > > > Let's assume it is 2.0.
> > > > > > > > > >
> > > > > > > > > > If you plug this to OTG 1.0 host, it won't be an issue as OTG 1.0 host doesn't
> > > > > > > > > > read the BCD version.
> > > > > > > > > 
> > > > > > > > > That makes sense, but there was some discussion about the size mattering.
> > > > > > > > > 
> > > > > > > > > So is there a reason not to always report 2.0 with any kernel that has
> > > > > > > > > 2.0 support?
> > > > > > > > 
> > > > > > > > A 2.0 host would still need to know if the attached OTG device is 1.0 or 2.0
> > > > > > > > so we don't want to force existing 1.0 devices to 2.0.
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > >>
> > > > > > > > > >> >> > + - srp-support: tells OTG controllers we want to enable SRP.
> > > > > > > > > >> >> > + - hnp-support: tells OTG controllers we want to enable HNP.
> > > > > > > > > >> >> > + - adp-support: tells OTG controllers we want to enable ADP.
> > > > > > > > > >> >>
> > > > > > > > > >> >> I've recently run into a problem[1] and found that I have to disable
> > > > > > > > > >> >> OTG in the kernel to get my device to work. Having to turn-off OTG
> > > > > > > > > >> >> seems like the wrong solution, and shifting the problem to DT seems
> > > > > > > > > >> >> wrong too. Why is this not a user configurable option (within whatever
> > > > > > > > > >> >> h/w constraints there are)?
> > > > > > > > > >> > The problem of below link, seems your device is claiming it's a HNP capable
> > > > > > > > > >> > OTG device, but connecting to a non-OTG port of your Host, assume your Host
> > > > > > > > > >> > does have a OTG port, your Host issue a A_ALT_HNP_SUPPORT request to your
> > > > > > > > > >> > OTG device to remind it can use another port with HNP, but the request failed
> > > > > > > > > >> > (maybe STALL by your device, this request is defined in OTG 1.3 but obsolete
> > > > > > > > > >> > in OTG 2.0), so your Host just stopped enumeration of your device, this is not
> > > > > > > > > >> > reasonable because current OTG code is some out of data.
> > > > > > > > > >>
> > > > > > > > > >> Do PCs have OTG ports typically? My expectation is that if I plug in
> > > > > > > > > >> an OTG device as a B device to any host port, that it will work as a
> > > > > > > > > >> device no matter what the host OTG capabilities are. If I have to
> > > > > > > > > >> change the kernel config or DT, that is a problem.
> > > > > > > > > >
> > > > > > > > > > AFAIK PCs don't have OTG ports.
> > > > > > > > > >
> > > > > > > > > > If you plug in OTG device to a non-otg host port it will work as normal B-device.
> > > > > > > > > > The host doesn't request for OTG descriptors and doesn't care what OTG features it
> > > > > > > > > > supports or not.
> > > > > > > > > 
> > > > > > > > > That is what I would expect. My testing and the bug report show otherwise.
> > > > > > > > 
> > > > > > > > what kernel and platform are you on?
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > >> > I am trying to make those OTG feaures to be configurable options, you mean
> > > > > > > > > >> > by sys?
> > > > > > > > > >>
> > > > > > > > > >> Yes.
> > > > > > > > > >
> > > > > > > > > > why do you need OTG features to be sysfs configurable other than for debugging?
> > > > > > > > > 
> > > > > > > > > I don't know. Buggy host perhaps? Why do you need them in DT?
> > > > > > > > 
> > > > > > > > I'll explain why we need in DT below.
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > If they are truly debugging, then they would belong in debugfs rather
> > > > > > > > > than sysfs.
> > > > > > > > 
> > > > > > > > agreed.
> > > > > > > > > 
> > > > > > > > > >> >> What are the valid combinations? When do we want these enabled or not?
> > > > > > > > > >> >> Wouldn't default enabled be better?
> > > > > > > > > >> >
> > > > > > > > > >> > We want to enable all those support in kernel driver, but some platform or
> > > > > > > > > >> > hardware may not want to enable any or some of them, so those hardware
> > > > > > > > > >> > can disable it by not pass the property in dt, the 3 sub features of OTG are
> > > > > > > > > >> > not mandatory for so called OTG device, normally we at least enable HNP, and
> > > > > > > > > >> > SRP and ADP are optional.
> > > > > > > > > >>
> > > > > > > > > >> Please answer my questions in the doc.
> > > > > > > > > >>
> > > > > > > > > >> >>
> > > > > > > > > >> >> We already have dr_mode property. How is it related to these?
> > > > > > > > > >
> > > > > > > > > > dr_mode states what mode the controller will operate in.
> > > > > > > > > >
> > > > > > > > > > for dr_mode == "host" we don't care about these otg flags.
> > > > > > > > > >
> > > > > > > > > > for dr_mode == "peripheral" or dr_mode == "otg"
> > > > > > > > > > we care about these OTG flags to create our OTG descriptor on the fly.
> > > > > > > > > 
> > > > > > > > > Then how do I specify my device is peripheral only even though I have
> > > > > > > > > a DR controller?
> > > > > > > > 
> > > > > > > > by specifying dr_mode = "peripheral" in the DT.
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > How is ID pin detect supposed to be supported? Do we need dr_mode = "idpin"?
> > > > > > > > 
> > > > > > > > ID pin is not used in single role mode. It will be used only when dr_mode = "otg".
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > >> > dr_mode is to tell the device it will work at OTG mode(there is another simple
> > > > > > > > > >> > dual role mode which is commom used but not HNP), srp/hnp/adp can further specify
> > > > > > > > > >> > which protocol the OTG device will support.
> > > > > > > > > >>
> > > > > > > > > >> By simple DR, you mean ID pin detect, right. So please define how you
> > > > > > > > > >> support just ID pin detect vs. other levels of capability. Does only
> > > > > > > > > >> dr_mode = otg mean ID pin detect? That may be a problem for existing
> > > > > > > > > >> DTs if you disable other OTG functions because they have not been
> > > > > > > > > >> added to the DT, then that is a problem.
> > > > > > > > > >>
> > > > > > > > > >> I'm feeling less convinced that this belongs in DT at all. Please
> > > > > > > > > >> convince me otherwise.
> > > > > > > > > >
> > > > > > > > > > Yes not specifying anything in DT should work and default to the
> > > > > > > > > > best OTG version and features supported by the OTG controller.
> > > > > > > > > 
> > > > > > > > > Right, hence why I suggested disable flags, not enable flags.
> > > > > > > > 
> > > > > > > > I second that. They must be disable flags.
> > > > > > > > 
> > > > > > > 
> > > > > > > Disable flags may not work with current situation of gadget driver:
> > > > > > > Currently each gadget class driver hard coded the OTG attributes
> > > > > > > to be HNP | SRP, independent of controller driver.
> > > > > > 
> > > > > > That is wrong in the first place. Gadget drivers shouldn't decide
> > > > > > the OTG attributes. Platform code/DT should.
> > > > > > 
> > > > > 
> > > > > I totally agree the current code is wrong.
> > > > > 
> > > > > > If gadget drivers define OTG flags then they cannot be used on
> > > > > > different platforms with different OTG needs.
> > > > > > 
> > > > > Agree too.
> > > > > 
> > > > > But some platforms may already work with current "wrong" way, I do not want
> > > > > to break them.
> > > > > 
> > > > > > > 
> > > > > > > E.g. some platform with OTG enabled: gadget->is_otg = 1
> > > > > > > HNP and SRP are enabled by gadget driver, ADP = 0, this OTG port
> > > > > > > can really support HNP and SRP, but not ADP. 
> > > > > > 
> > > > > > What if the platform on which the gadget driver is used doesn't want
> > > > > > SRP enabled?
> > > > > 
> > > > > As far as I know, there is no controller driver to override this setting,
> > > > > maybe it still keeps SRP enabled even it does not support it in fact. 
> > > > > 
> > > > > > 
> > > > > > > if use disable flag, this platform has to add adp-disable property
> > > > > > > otherwise it will report ADP support to the host.
> > > > > > 
> > > > > > This issue won't happen if gadget driver doesn't define any OTG attributes.
> > > > > > 
> > > > > But some existing platform already rely on gadget driver to define OTG
> > > > > attributes, Can I break those already working platforms? I think it's hard
> > > > > to figure out all this kind of platforms and then correct every one with
> > > > > new approach.
> > > > > 
> > > > > Who define this attributes doesn't matter, key is this attributes should
> > > > > base on correct input.
> > > > > 
> > > > > So my principle is to not break any existing platforms, and introduce new
> > > > > approach, old platforms can work without any change.
> > > > 
> > > > But we don't know which platforms use what so we need to define a sane
> > > > default configuration for all gadgets. I don't think we can have a gadget
> > > > specific configuration.
> > > > 
> > > Yes, we don't know, what I can do is to keep all unchanged for those platforms
> > > if those new properties doesn't appear at all. (i.e. SRP and HNP still enabled
> > > in its otg descriptor anyway like current gadget driver does)
> > > 
> > > > If anyone complains we need to ask them to set the right DT flags for their
> > > > platform. I don't see any other way.
> > > > 
> > > 
> > > My current way is to achieve this goal.
> > > 
> > > > > 
> > > > > > > 
> > > > > > > But with enable flags, I can check all those 3 properties,
> > > > > > 
> > > > > > I don't see why you can't do that with disable flags. Note that there are 2 things.
> > > > > > 1) disable flags from DT
> > > > > > 2) support flags from controller. This information is already known to the
> > > > > > controller.
> > > > > > 
> > > > > > Based on these 2 you can decide what OTG features you want to set/clear.
> > > > > > And you can't combine the 2 by just defining enable flags in DT.
> > > > > > 
> > > > > 
> > > > > Yes, I have the same understanding. So:
> > > > > 1) In controller driver:
> > > > > if (controller_can_support_srp(controller)) {
> > > 
> > > This check only can be done in each controller driver.
> > > 
> > > > > 	if (srp_enabled_in_dt(of))
> > > > > 		gadget->srp_support = 1;
> > > > 
> > > > Existing platforms don't have feature_enabled_in_dt so this will fail for all.
> > > 
> > > Above code is for how "new" platform set new flags if it want to utilize those new
> > > properties, existing platform doesn't need any code change. This is not common code
> > > shared by all controller drivers, like gadget->is_otg, it should be set by specific
> > > controller driver.
> > > 
> > > > So need to have
> > > > 	if (srp_not_disabled_in_dt(of))
> > > >  		gadget->srp_support = 1;
> > > 
> > > Maybe you think it's common code called by every platform.
> > > I am putting it in my chipidea driver.
> > > 
> > > > 
> > > > > }
> > > > > 2) In gadget driver:
> > > > > if (gadget->srp_support)
> > > > > 	attribute |= SRP;
> > > > 
> > > > Agreed.
> > > > 
> > > 
> > > You may take a look my 9/22 patch to see how existing platform is handled:
> > > 
> > > 	if (gadget->adp_support || gadget->hnp_support ||
> > > 					gadget->srp_support) {
> > > 		/* means th
> > > 		if (gadget->adp_support)
> > > 			otg_desc->bmAttributes |= USB_OTG_ADP;
> > > 		if (gadget->hnp_support)
> > > 		otg_desc->bmAttributes |= USB_OTG_HNP;
> > > 		if (gadget->srp_support)
> > > 			otg_desc->bmAttributes |= USB_OTG_SRP;
> > > 	} else {
> > > 		otg_desc->bmAttributes = USB_OTG_SRP | USB_OTG_HNP;
> > > 	}
> > > 
> > > This is common code will be called by every platform.
> > 
> > So you are using  gadget->xyz_support flags to determine if it is a legacy
> > platform and that's why we have a problem with having disable flags in DT.
> > 
> Other than those new flags, I have not found other good way to judge
> whether some platform is a legacy one.
> Directly use dt property? Then above code has to be moved to controller
> driver, consequently the usb_otg_descriptor has to be allocated by
> controller driver at runtime, and I have to create some new way to pass it
> to gadget driver, for those legacy platform, I still need gadget driver to
> allocate it...too complicated.

Right. let's not do that.

> 
> (You know, there are 2 different otg_desc structures: otg_desc and
> otg_20_desc, I need select one and allocate it at runtime)
> 
> > This also has a side effect of SRP and HNP being enabled for any platform
> > even if enable-srp/enable-hnp is not set in DT.
> That's the current situation before my patch, not the side effect
> brought by me.

Agreed. I was thinking of fixing that side effect but if you want
legacy behaviour as well then it looks like it can't be done.

> 
> > This will be more of a bug than supporting legacy users.
> I have to leave the _existing_ bug there, because I can't know
> which platform can really support HNP/SRP, which one cannot.
> So I do not fix the _existing_ bug, meanwhile I also do not introduce
> a new bug either. If some legacy platform with this bug, want to fix it,
> fine, use dt or other way to set gadget->xyz_support correctly
> in its controller driver, no more change needed.
> 
> Any other reason you think enable flags are still not reasonable?

Yes. We can't specify that we don't want all 3 features from DT.
It will treat it as legacy and enable HNP/SRP. ;)

This is true for dual-role devices. We set dr_mode = "otg"
but disable all 3 features.

> 
> > 
> > Instead we could have ADP disabled by default for all cases
> > and expect enable-adp in DT to get it enabled. SRP/HNP could still
> > be disable flags.
> > 
> Yes, this can work, but seems they look some odd:), some are xxx_disable,
> some are xxx_enable.
>  
> > Then your above code reduces to
> > 
> > 		if (gadget->adp_support)
> >  			otg_desc->bmAttributes |= USB_OTG_ADP;
> >  		if (gadget->hnp_support)
> >  			otg_desc->bmAttributes |= USB_OTG_HNP;
> >  		if (gadget->srp_support)
> >  			otg_desc->bmAttributes |= USB_OTG_SRP;
> >
> Yes if those code is put in controller driver of new platforms.
> No if we put it in common routine and called by both new and
> legacy platforms.

Agreed. We still need to determine legacy platform if
none of the features are set.

How about defining the followong enum for gadget->xyz_support

enum otg_feature {
	OTG_FEATURE_UNDEFINED = 0,
	OTG_FEATURE_ENABLED,
	OTG_FEATURE_DISABLED,
};

for legacy platforms this will be UNDEFINED for all so you can detect it
and continue legacy behaviour i.e. enable HNP/SRP, disable ADP.

For new platforms at least one of them won't be UNDEFINED so you can
enable the feature if ENABLED and disable if UNDEFINED/DISABLED.

We can still keep disable flags so that users can disable all 3 OTG features
while in OTG mode.

cheers,
-roger

> > 
> > > 
> > > Those existing platforms do not use those new flags of gadget, so all are 0,
> > > then otg_desc->bmAttributes = USB_OTG_SRP | USB_OTG_HNP. This is current
> > > "wrong" way.
> > > 
> > > If any platform want to use any new flags, then He must fully understand
> > > those flags and change accordingly, set gadget->xxx_support in its controller
> > > driver either by dt, or by other way(hard code...what ever).
> > > 
> > > 
> > > > > 
> > > > > > > 1)If none of them are passed, but gadget->is_otg == 1, I suppose it's
> > > > > > > legacy platform, still set HNP and SRP as current gadget driver does,
> > > > > > > works as before;
> > > > > > > 2)If any one of them appear, I will set all those features by dt property.
> > > > > > > 3)If some platform already based on those properties, wants to disable
> > > > > > > all 3 OTG features, also not pass any one of them like 1), it will not
> > > > > > > be a OTG device at all, set gadget->is_otg = 0 in its controller driver,
> > > > > > > then no need set and report any OTG features, this can meet ID pin detect
> > > > > > > case.
> > > > > > 
> > > > > > With enable flags you don't get what you set.
> > > > > > e.g. in DT, we might set enable-adp.
> > > > > > but if controller doesn't support adp, you don't have ADP working.
> > > > > > So this is misleading.
> > > > > > 
> > > > > 
> > > > > Why someone might do that? If someone adds some property which is not supported
> > > > > by its controller, of cos this feature cannot work.
> > > > 
> > > > OK.
> > > > 
> > > > > 
> > > > > If some platform utilize those new properties, both enable and disable flags
> > > > > can work, but for those existing platforms with HNP/SRP support, they have
> > > > > no any new flags in its DT, I need make it work as before.
> > > > 
> > > > Right, existing platforms need to work as is without DT changes. So features
> > > > have to be enabled by default. That's another reason why we need disable-flags
> > > > and not enable-flags in DT.
> > > 
> > > You are right if current code enables all 3 features by default,
> > > Unfortunately only SRP and HNP are enabled, ADP is disabled,  
> > > 
> > > The key point here is, if none of new properties is added, are there 2 cases
> > > which we cannot differentiate one from the other? 
> > > 
> > > By disable flags, if none passed in dt, there are 2 cases:
> > > 1) Legacy platforms(some may only support HNP and SRP, but no ADP).
> > > 2) New platform, it can really support all 3 features. 
> > > I cannot differentiate 1) from 2), to correct set 1), I have to add
> > > "adp-disable" for a legacy platform.
> > > 
> > > By enable flags, if none passed in dt, there are 2 cases:
> > > 1) Legacy platforms
> > > 2) New platform, it cannot support any features, so it's not a OTG device
> > >    at all. Then the gadget->is_otg is 0, no any OTG related report needed.
> > > 

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 05/22] doc: dt-binding: usb: add otg related properties

[Li Jun]

On Fri, Jun 12, 2015 at 11:31:02AM +0300, Roger Quadros wrote:
> 
> 
> On Fri, 12 Jun 2015 11:09:17 +0800
> Li Jun <b47624-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> 
[...]

> > Other than those new flags, I have not found other good way to judge
> > whether some platform is a legacy one.
> > Directly use dt property? Then above code has to be moved to controller
> > driver, consequently the usb_otg_descriptor has to be allocated by
> > controller driver at runtime, and I have to create some new way to pass it
> > to gadget driver, for those legacy platform, I still need gadget driver to
> > allocate it...too complicated.
> 
> Right. let's not do that.
> 
> > 
> > (You know, there are 2 different otg_desc structures: otg_desc and
> > otg_20_desc, I need select one and allocate it at runtime)
> > 
> > > This also has a side effect of SRP and HNP being enabled for any platform
> > > even if enable-srp/enable-hnp is not set in DT.
> > That's the current situation before my patch, not the side effect
> > brought by me.
> 
> Agreed. I was thinking of fixing that side effect but if you want
> legacy behaviour as well then it looks like it can't be done.
> 
> > 
> > > This will be more of a bug than supporting legacy users.
> > I have to leave the _existing_ bug there, because I can't know
> > which platform can really support HNP/SRP, which one cannot.
> > So I do not fix the _existing_ bug, meanwhile I also do not introduce
> > a new bug either. If some legacy platform with this bug, want to fix it,
> > fine, use dt or other way to set gadget->xyz_support correctly
> > in its controller driver, no more change needed.
> > 
> > Any other reason you think enable flags are still not reasonable?
> 
> Yes. We can't specify that we don't want all 3 features from DT.
> It will treat it as legacy and enable HNP/SRP. ;)
> 
> This is true for dual-role devices. We set dr_mode = "otg"
> but disable all 3 features.
> 
> > 
> > > 
> > > Instead we could have ADP disabled by default for all cases
> > > and expect enable-adp in DT to get it enabled. SRP/HNP could still
> > > be disable flags.
> > > 
> > Yes, this can work, but seems they look some odd:), some are xxx_disable,
> > some are xxx_enable.
> >  
> > > Then your above code reduces to
> > > 
> > > 		if (gadget->adp_support)
> > >  			otg_desc->bmAttributes |= USB_OTG_ADP;
> > >  		if (gadget->hnp_support)
> > >  			otg_desc->bmAttributes |= USB_OTG_HNP;
> > >  		if (gadget->srp_support)
> > >  			otg_desc->bmAttributes |= USB_OTG_SRP;
> > >
> > Yes if those code is put in controller driver of new platforms.
> > No if we put it in common routine and called by both new and
> > legacy platforms.
> 
> Agreed. We still need to determine legacy platform if
> none of the features are set.
> 
> How about defining the followong enum for gadget->xyz_support
> 
> enum otg_feature {
> 	OTG_FEATURE_UNDEFINED = 0,
> 	OTG_FEATURE_ENABLED,
> 	OTG_FEATURE_DISABLED,
> };
> 
> for legacy platforms this will be UNDEFINED for all so you can detect it
> and continue legacy behaviour i.e. enable HNP/SRP, disable ADP.
> 
> For new platforms at least one of them won't be UNDEFINED so you can
> enable the feature if ENABLED and disable if UNDEFINED/DISABLED.
> 

Then some legacy platform will have problem if it wants to use those
new properties and flags, the existing DTs cannot work as before, E.g. for
some controller driver, before my patch, the HNP/SRP are enabled,
ADP is disabled, after utilize those new properties and flags in its
controller driver, it becomes a new platform, but the existing DTs
using this controller driver did not pass any xyz_disable, so
gadget->xyz_support will be updated to be OTG_FEATURE_ENABLED, and
the result will be HNP/SRP/ADP all are enabled.

In some controller driver:
if (xyz_disable_property_appear_in_dt())
	gadget->xyz_support = OTG_FEATURE_DISABLED;
else
	gadget->xyz_support = OTG_FEATURE_ENABLED;
The existing/old DT with this controller driver will enable all
OTG features no matter it support it or not, but it does not want
ADP.
 
Li Jun
> We can still keep disable flags so that users can disable all 3 OTG features
> while in OTG mode.
> 
> cheers,
> -roger
> 
> > > 
> > > > 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 05/22] doc: dt-binding: usb: add otg related properties

[Roger Quadros]

On Mon, 15 Jun 2015 14:32:46 +0800
Li Jun <b47624-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:

> On Fri, Jun 12, 2015 at 11:31:02AM +0300, Roger Quadros wrote:
> > 
> > 
> > On Fri, 12 Jun 2015 11:09:17 +0800
> > Li Jun <b47624-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> > 
> [...]
> 
> > > Other than those new flags, I have not found other good way to judge
> > > whether some platform is a legacy one.
> > > Directly use dt property? Then above code has to be moved to controller
> > > driver, consequently the usb_otg_descriptor has to be allocated by
> > > controller driver at runtime, and I have to create some new way to pass it
> > > to gadget driver, for those legacy platform, I still need gadget driver to
> > > allocate it...too complicated.
> > 
> > Right. let's not do that.
> > 
> > > 
> > > (You know, there are 2 different otg_desc structures: otg_desc and
> > > otg_20_desc, I need select one and allocate it at runtime)
> > > 
> > > > This also has a side effect of SRP and HNP being enabled for any platform
> > > > even if enable-srp/enable-hnp is not set in DT.
> > > That's the current situation before my patch, not the side effect
> > > brought by me.
> > 
> > Agreed. I was thinking of fixing that side effect but if you want
> > legacy behaviour as well then it looks like it can't be done.
> > 
> > > 
> > > > This will be more of a bug than supporting legacy users.
> > > I have to leave the _existing_ bug there, because I can't know
> > > which platform can really support HNP/SRP, which one cannot.
> > > So I do not fix the _existing_ bug, meanwhile I also do not introduce
> > > a new bug either. If some legacy platform with this bug, want to fix it,
> > > fine, use dt or other way to set gadget->xyz_support correctly
> > > in its controller driver, no more change needed.
> > > 
> > > Any other reason you think enable flags are still not reasonable?
> > 
> > Yes. We can't specify that we don't want all 3 features from DT.
> > It will treat it as legacy and enable HNP/SRP. ;)
> > 
> > This is true for dual-role devices. We set dr_mode = "otg"
> > but disable all 3 features.
> > 
> > > 
> > > > 
> > > > Instead we could have ADP disabled by default for all cases
> > > > and expect enable-adp in DT to get it enabled. SRP/HNP could still
> > > > be disable flags.
> > > > 
> > > Yes, this can work, but seems they look some odd:), some are xxx_disable,
> > > some are xxx_enable.
> > >  
> > > > Then your above code reduces to
> > > > 
> > > > 		if (gadget->adp_support)
> > > >  			otg_desc->bmAttributes |= USB_OTG_ADP;
> > > >  		if (gadget->hnp_support)
> > > >  			otg_desc->bmAttributes |= USB_OTG_HNP;
> > > >  		if (gadget->srp_support)
> > > >  			otg_desc->bmAttributes |= USB_OTG_SRP;
> > > >
> > > Yes if those code is put in controller driver of new platforms.
> > > No if we put it in common routine and called by both new and
> > > legacy platforms.
> > 
> > Agreed. We still need to determine legacy platform if
> > none of the features are set.
> > 
> > How about defining the followong enum for gadget->xyz_support
> > 
> > enum otg_feature {
> > 	OTG_FEATURE_UNDEFINED = 0,
> > 	OTG_FEATURE_ENABLED,
> > 	OTG_FEATURE_DISABLED,
> > };
> > 
> > for legacy platforms this will be UNDEFINED for all so you can detect it
> > and continue legacy behaviour i.e. enable HNP/SRP, disable ADP.
> > 
> > For new platforms at least one of them won't be UNDEFINED so you can
> > enable the feature if ENABLED and disable if UNDEFINED/DISABLED.
> > 
> 
> Then some legacy platform will have problem if it wants to use those
> new properties and flags, the existing DTs cannot work as before, E.g. for
> some controller driver, before my patch, the HNP/SRP are enabled,
> ADP is disabled, after utilize those new properties and flags in its
> controller driver, it becomes a new platform, but the existing DTs
> using this controller driver did not pass any xyz_disable, so
> gadget->xyz_support will be updated to be OTG_FEATURE_ENABLED, and
> the result will be HNP/SRP/ADP all are enabled.

Good point.

I was under the impression that if controller drivers change the platform
is no longer legacy but that is not always the case.

I agree that we are restricted to use enable flags in DT if we want to retain
OTG capability behaviour for legacy platforms.

cheers,
-roger

> 
> In some controller driver:
> if (xyz_disable_property_appear_in_dt())
> 	gadget->xyz_support = OTG_FEATURE_DISABLED;
> else
> 	gadget->xyz_support = OTG_FEATURE_ENABLED;
> The existing/old DT with this controller driver will enable all
> OTG features no matter it support it or not, but it does not want
> ADP.
>  
> Li Jun
> > We can still keep disable flags so that users can disable all 3 OTG features
> > while in OTG mode.
> > 
> > cheers,
> > -roger
> > 
> > > > 
> > > > > 
> > 

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 05/22] doc: dt-binding: usb: add otg related properties

[Li Jun]

On Fri, Jun 12, 2015 at 11:31:02AM +0300, Roger Quadros wrote:
> 
> 
> 
> Agreed. We still need to determine legacy platform if
> none of the features are set.
> 
> How about defining the followong enum for gadget->xyz_support
> 
> enum otg_feature {
> 	OTG_FEATURE_UNDEFINED = 0,
> 	OTG_FEATURE_ENABLED,
> 	OTG_FEATURE_DISABLED,
> };
> 
> for legacy platforms this will be UNDEFINED for all so you can detect it
> and continue legacy behaviour i.e. enable HNP/SRP, disable ADP.
> 
> For new platforms at least one of them won't be UNDEFINED so you can
> enable the feature if ENABLED and disable if UNDEFINED/DISABLED.
> 
> We can still keep disable flags so that users can disable all 3 OTG features
> while in OTG mode.
> 
> cheers,
> -roger

Regarding use of "xyz-disable" flags:
After more thinking this, I just realize that we can use "otg-rev" property
to handle the case of none of xyz-disable properties passed, for legacy
platforms, the new "otg-rev" not passed either, so it's a legacy platform,
if new platform does support all 3 features(SRP/HNP/ADP), the otg-rev
should be passed and also should be 2.0 or above, because ADP is
introduced in OTG 2.0(maybe that's why in current gadget driver, only
enable SRP/HNP).

So:
1) new platform with full otg feature support:
dr_mode = "otg";
otg-rev = "0x0200";

2) legacy platform
dr_mode = "otg"

Then I think we are okay to use disable flags.

thanks
Li Jun
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 05/22] doc: dt-binding: usb: add otg related properties

[Roger Quadros]

On Mon, 15 Jun 2015 15:41:02 +0800
Li Jun <b47624-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:

> On Fri, Jun 12, 2015 at 11:31:02AM +0300, Roger Quadros wrote:
> > 
> > 
> > 
> > Agreed. We still need to determine legacy platform if
> > none of the features are set.
> > 
> > How about defining the followong enum for gadget->xyz_support
> > 
> > enum otg_feature {
> > 	OTG_FEATURE_UNDEFINED = 0,
> > 	OTG_FEATURE_ENABLED,
> > 	OTG_FEATURE_DISABLED,
> > };
> > 
> > for legacy platforms this will be UNDEFINED for all so you can detect it
> > and continue legacy behaviour i.e. enable HNP/SRP, disable ADP.
> > 
> > For new platforms at least one of them won't be UNDEFINED so you can
> > enable the feature if ENABLED and disable if UNDEFINED/DISABLED.
> > 
> > We can still keep disable flags so that users can disable all 3 OTG features
> > while in OTG mode.
> > 
> > cheers,
> > -roger
> 
> Regarding use of "xyz-disable" flags:
> After more thinking this, I just realize that we can use "otg-rev" property
> to handle the case of none of xyz-disable properties passed, for legacy
> platforms, the new "otg-rev" not passed either, so it's a legacy platform,
> if new platform does support all 3 features(SRP/HNP/ADP), the otg-rev
> should be passed and also should be 2.0 or above, because ADP is
> introduced in OTG 2.0(maybe that's why in current gadget driver, only
> enable SRP/HNP).
> 
> So:
> 1) new platform with full otg feature support:
> dr_mode = "otg";
> otg-rev = "0x0200";
> 
> 2) legacy platform
> dr_mode = "otg"
> 
> Then I think we are okay to use disable flags.

I just agreed that it is ok to use enable flags and then read this mail :)

I like this approach of using otg-rev to decide if OTG capabilities will be
read from DT or not.

cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 05/22] doc: dt-binding: usb: add otg related properties

[Sergei Shtylyov]

Hello.

On 6/15/2015 10:41 AM, Li Jun wrote:

[...]

> Regarding use of "xyz-disable" flags:
> After more thinking this, I just realize that we can use "otg-rev" property
> to handle the case of none of xyz-disable properties passed, for legacy
> platforms, the new "otg-rev" not passed either, so it's a legacy platform,
> if new platform does support all 3 features(SRP/HNP/ADP), the otg-rev
> should be passed and also should be 2.0 or above, because ADP is
> introduced in OTG 2.0(maybe that's why in current gadget driver, only
> enable SRP/HNP).
>
> So:
> 1) new platform with full otg feature support:
> dr_mode = "otg";
> otg-rev = "0x0200";

    If you're going to use a string value for this prop, why not let it have a 
natural form, "2.0"?

WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 05/22] doc: dt-binding: usb: add otg related properties

[Li Jun]

On Mon, Jun 15, 2015 at 03:25:48PM +0300, Sergei Shtylyov wrote:
> Hello.
> 
> On 6/15/2015 10:41 AM, Li Jun wrote:
> 
> [...]
> 
> >Regarding use of "xyz-disable" flags:
> >After more thinking this, I just realize that we can use "otg-rev" property
> >to handle the case of none of xyz-disable properties passed, for legacy
> >platforms, the new "otg-rev" not passed either, so it's a legacy platform,
> >if new platform does support all 3 features(SRP/HNP/ADP), the otg-rev
> >should be passed and also should be 2.0 or above, because ADP is
> >introduced in OTG 2.0(maybe that's why in current gadget driver, only
> >enable SRP/HNP).
> >
> >So:
> >1) new platform with full otg feature support:
> >dr_mode = "otg";
> >otg-rev = "0x0200";
> 
>    If you're going to use a string value for this prop, why not let
> it have a natural form, "2.0"?
> 
> WBR, Sergei
> 
Sorry, I gave a wrong format in my example, it's not a string, but a bcd vaule.
otg-rev = <0x0200>;

Li Jun
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 05/22] doc: dt-binding: usb: add otg related properties

[Li Jun]

On Tue, Jun 09, 2015 at 11:29:31PM +0800, Roger Quadros wrote:
> Rob,
> 
> On Tue, 9 Jun 2015 08:26:20 -0500
> Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> 
> > On Mon, Jun 8, 2015 at 8:18 PM, Li Jun <b47624-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> > > On Mon, Jun 08, 2015 at 11:06:49AM -0500, Rob Herring wrote:
> > >> On Mon, Jun 8, 2015 at 10:02 AM, Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> > >> > Add otg version, srp, hnp and adp support for usb OTG port, then those OTG
> > >> > features don't have to be decided by usb gadget drivers.
> > >> >
> > >> > Signed-off-by: Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> > >> > ---
> > >> >  Documentation/devicetree/bindings/usb/generic.txt | 10 ++++++++++
> > >> >  1 file changed, 10 insertions(+)
> > >> >
> > >> > diff --git a/Documentation/devicetree/bindings/usb/generic.txt b/Documentation/devicetree/bindings/usb/generic.txt
> > >> > index 477d5bb..7386f4a 100644
> > >> > --- a/Documentation/devicetree/bindings/usb/generic.txt
> > >> > +++ b/Documentation/devicetree/bindings/usb/generic.txt
> > >> > @@ -11,6 +11,12 @@ Optional properties:
> > >> >                         "peripheral" and "otg". In case this attribute isn't
> > >> >                         passed via DT, USB DRD controllers should default to
> > >> >                         OTG.
> > >> > + - otg-rev: tells usb driver the release number of the OTG and EH supplement
> > >> > +                       with which the device and its descriptors are compliant,
> > >> > +                       in binary-coded decimal (i.e. 2.0 is 0200H).
> > >>
> > >> I would assume OTG 2.0 is somehow backwards compatible? Is this a h/w
> > >> dependency or a driver feature?
> > >>
> > > Not fully compatible, OTG 2.0 extend the usb_otg_descriptor by adding a new
> > > member bcdOTG to identify the OTG version, this descriptor needs to be sent
> > > to OTG host with correct size and content, so we have to know which release
> > > version the OTG device is compliant with, either by menuconfig config or pass
> > > via DT.
> > 
> > So you have to change the version depending on the host you are
> > connected to? That really seems strange that plugging in a OTG 2.0
> > device to an OTG 1.3 host would not work and doesn't make for a good
> > user experience.
> 
> No. The OTG version in the OTG descriptor for any device is usually fixed for the
> lifetime of the product.
> 
> Let's assume it is 2.0.
> 
> If you plug this to OTG 1.0 host, it won't be an issue as OTG 1.0 host doesn't
> read the BCD version.
> 
But OTG 1.0 host will send a 1.x specific OTG request for the 2.0 device.

> > 
> > >> > + - srp-support: tells OTG controllers we want to enable SRP.
> > >> > + - hnp-support: tells OTG controllers we want to enable HNP.
> > >> > + - adp-support: tells OTG controllers we want to enable ADP.
> > >>
> > >> I've recently run into a problem[1] and found that I have to disable
> > >> OTG in the kernel to get my device to work. Having to turn-off OTG
> > >> seems like the wrong solution, and shifting the problem to DT seems
> > >> wrong too. Why is this not a user configurable option (within whatever
> > >> h/w constraints there are)?
> > > The problem of below link, seems your device is claiming it's a HNP capable
> > > OTG device, but connecting to a non-OTG port of your Host, assume your Host
> > > does have a OTG port, your Host issue a A_ALT_HNP_SUPPORT request to your
> > > OTG device to remind it can use another port with HNP, but the request failed
> > > (maybe STALL by your device, this request is defined in OTG 1.3 but obsolete
> > > in OTG 2.0), so your Host just stopped enumeration of your device, this is not
> > > reasonable because current OTG code is some out of data.
> > 
> > Do PCs have OTG ports typically? My expectation is that if I plug in
> > an OTG device as a B device to any host port, that it will work as a
> > device no matter what the host OTG capabilities are. If I have to
> > change the kernel config or DT, that is a problem.
> 
> AFAIK PCs don't have OTG ports.
> 
> If you plug in OTG device to a non-otg host port it will work as normal B-device.
> The host doesn't request for OTG descriptors and doesn't care what OTG features it
> supports or not.
> 
This is not true in OTG 1.x and our current code, the host still request for
OTG descriptor and check if HNP is supported by it if CONFIG_USB_OTG is enabled
for the host.

> > 
> > > I am trying to make those OTG feaures to be configurable options, you mean
> > > by sys?
> > 
> > Yes.
> 
> why do you need OTG features to be sysfs configurable other than for debugging?
> 
> > 
> > >> What are the valid combinations? When do we want these enabled or not?
> > >> Wouldn't default enabled be better?
> > >
> > > We want to enable all those support in kernel driver, but some platform or
> > > hardware may not want to enable any or some of them, so those hardware
> > > can disable it by not pass the property in dt, the 3 sub features of OTG are
> > > not mandatory for so called OTG device, normally we at least enable HNP, and
> > > SRP and ADP are optional.
> > 
> > Please answer my questions in the doc.
> > 
> > >>
> > >> We already have dr_mode property. How is it related to these?
> 
> dr_mode states what mode the controller will operate in.
> 
> for dr_mode == "host" we don't care about these otg flags.
> 
> for dr_mode == "peripheral" or dr_mode == "otg"
> we care about these OTG flags to create our OTG descriptor on the fly.
> 

Yes.

> > >
> > > dr_mode is to tell the device it will work at OTG mode(there is another simple
> > > dual role mode which is commom used but not HNP), srp/hnp/adp can further specify
> > > which protocol the OTG device will support.
> > 
> > By simple DR, you mean ID pin detect, right. So please define how you
> > support just ID pin detect vs. other levels of capability. Does only
> > dr_mode = otg mean ID pin detect? That may be a problem for existing
> > DTs if you disable other OTG functions because they have not been
> > added to the DT, then that is a problem.
> > 
> > I'm feeling less convinced that this belongs in DT at all. Please
> > convince me otherwise.
> 
> Yes not specifying anything in DT should work and default to the
> best OTG version and features supported by the OTG controller.
> 
> But if the device manufacturer wants to restrict the OTG version
> to something less or disable some OTG features then the DT flags come
> into play.
> 
agree.

> cheers,
> -roger

Li Jun
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 05/22] doc: dt-binding: usb: add otg related properties

[Roger Quadros]

On Wed, 10 Jun 2015 20:06:25 +0800
Li Jun <b47624-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:

> On Tue, Jun 09, 2015 at 11:29:31PM +0800, Roger Quadros wrote:
> > Rob,
> > 
> > On Tue, 9 Jun 2015 08:26:20 -0500
> > Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > 
> > > On Mon, Jun 8, 2015 at 8:18 PM, Li Jun <b47624-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> > > > On Mon, Jun 08, 2015 at 11:06:49AM -0500, Rob Herring wrote:
> > > >> On Mon, Jun 8, 2015 at 10:02 AM, Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> > > >> > Add otg version, srp, hnp and adp support for usb OTG port, then those OTG
> > > >> > features don't have to be decided by usb gadget drivers.
> > > >> >
> > > >> > Signed-off-by: Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> > > >> > ---
> > > >> >  Documentation/devicetree/bindings/usb/generic.txt | 10 ++++++++++
> > > >> >  1 file changed, 10 insertions(+)
> > > >> >
> > > >> > diff --git a/Documentation/devicetree/bindings/usb/generic.txt b/Documentation/devicetree/bindings/usb/generic.txt
> > > >> > index 477d5bb..7386f4a 100644
> > > >> > --- a/Documentation/devicetree/bindings/usb/generic.txt
> > > >> > +++ b/Documentation/devicetree/bindings/usb/generic.txt
> > > >> > @@ -11,6 +11,12 @@ Optional properties:
> > > >> >                         "peripheral" and "otg". In case this attribute isn't
> > > >> >                         passed via DT, USB DRD controllers should default to
> > > >> >                         OTG.
> > > >> > + - otg-rev: tells usb driver the release number of the OTG and EH supplement
> > > >> > +                       with which the device and its descriptors are compliant,
> > > >> > +                       in binary-coded decimal (i.e. 2.0 is 0200H).
> > > >>
> > > >> I would assume OTG 2.0 is somehow backwards compatible? Is this a h/w
> > > >> dependency or a driver feature?
> > > >>
> > > > Not fully compatible, OTG 2.0 extend the usb_otg_descriptor by adding a new
> > > > member bcdOTG to identify the OTG version, this descriptor needs to be sent
> > > > to OTG host with correct size and content, so we have to know which release
> > > > version the OTG device is compliant with, either by menuconfig config or pass
> > > > via DT.
> > > 
> > > So you have to change the version depending on the host you are
> > > connected to? That really seems strange that plugging in a OTG 2.0
> > > device to an OTG 1.3 host would not work and doesn't make for a good
> > > user experience.
> > 
> > No. The OTG version in the OTG descriptor for any device is usually fixed for the
> > lifetime of the product.
> > 
> > Let's assume it is 2.0.
> > 
> > If you plug this to OTG 1.0 host, it won't be an issue as OTG 1.0 host doesn't
> > read the BCD version.
> > 
> But OTG 1.0 host will send a 1.x specific OTG request for the 2.0 device.
> 
> > > 
> > > >> > + - srp-support: tells OTG controllers we want to enable SRP.
> > > >> > + - hnp-support: tells OTG controllers we want to enable HNP.
> > > >> > + - adp-support: tells OTG controllers we want to enable ADP.
> > > >>
> > > >> I've recently run into a problem[1] and found that I have to disable
> > > >> OTG in the kernel to get my device to work. Having to turn-off OTG
> > > >> seems like the wrong solution, and shifting the problem to DT seems
> > > >> wrong too. Why is this not a user configurable option (within whatever
> > > >> h/w constraints there are)?
> > > > The problem of below link, seems your device is claiming it's a HNP capable
> > > > OTG device, but connecting to a non-OTG port of your Host, assume your Host
> > > > does have a OTG port, your Host issue a A_ALT_HNP_SUPPORT request to your
> > > > OTG device to remind it can use another port with HNP, but the request failed
> > > > (maybe STALL by your device, this request is defined in OTG 1.3 but obsolete
> > > > in OTG 2.0), so your Host just stopped enumeration of your device, this is not
> > > > reasonable because current OTG code is some out of data.
> > > 
> > > Do PCs have OTG ports typically? My expectation is that if I plug in
> > > an OTG device as a B device to any host port, that it will work as a
> > > device no matter what the host OTG capabilities are. If I have to
> > > change the kernel config or DT, that is a problem.
> > 
> > AFAIK PCs don't have OTG ports.
> > 
> > If you plug in OTG device to a non-otg host port it will work as normal B-device.
> > The host doesn't request for OTG descriptors and doesn't care what OTG features it
> > supports or not.
> > 
> This is not true in OTG 1.x and our current code, the host still request for
> OTG descriptor and check if HNP is supported by it if CONFIG_USB_OTG is enabled
> for the host.

Looks like the current USB host/hub code assumes that if CONFIG_USB_OTG is set
it is an OTG port even if it really isn't. This is wrong and the root of the problem.

We need to have is_otg flag + attributes for host port case as well
just like we have for device case.

cheers,
-roger

> 
> > > 
> > > > I am trying to make those OTG feaures to be configurable options, you mean
> > > > by sys?
> > > 
> > > Yes.
> > 
> > why do you need OTG features to be sysfs configurable other than for debugging?
> > 
> > > 
> > > >> What are the valid combinations? When do we want these enabled or not?
> > > >> Wouldn't default enabled be better?
> > > >
> > > > We want to enable all those support in kernel driver, but some platform or
> > > > hardware may not want to enable any or some of them, so those hardware
> > > > can disable it by not pass the property in dt, the 3 sub features of OTG are
> > > > not mandatory for so called OTG device, normally we at least enable HNP, and
> > > > SRP and ADP are optional.
> > > 
> > > Please answer my questions in the doc.
> > > 
> > > >>
> > > >> We already have dr_mode property. How is it related to these?
> > 
> > dr_mode states what mode the controller will operate in.
> > 
> > for dr_mode == "host" we don't care about these otg flags.
> > 
> > for dr_mode == "peripheral" or dr_mode == "otg"
> > we care about these OTG flags to create our OTG descriptor on the fly.
> > 
> 
> Yes.
> 
> > > >
> > > > dr_mode is to tell the device it will work at OTG mode(there is another simple
> > > > dual role mode which is commom used but not HNP), srp/hnp/adp can further specify
> > > > which protocol the OTG device will support.
> > > 
> > > By simple DR, you mean ID pin detect, right. So please define how you
> > > support just ID pin detect vs. other levels of capability. Does only
> > > dr_mode = otg mean ID pin detect? That may be a problem for existing
> > > DTs if you disable other OTG functions because they have not been
> > > added to the DT, then that is a problem.
> > > 
> > > I'm feeling less convinced that this belongs in DT at all. Please
> > > convince me otherwise.
> > 
> > Yes not specifying anything in DT should work and default to the
> > best OTG version and features supported by the OTG controller.
> > 
> > But if the device manufacturer wants to restrict the OTG version
> > to something less or disable some OTG features then the DT flags come
> > into play.
> > 
> agree.
> 
> > cheers,
> > -roger
> 
> Li Jun

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 05/22] doc: dt-binding: usb: add otg related properties

[Li Jun]

On Thu, Jun 11, 2015 at 10:30:35AM +0300, Roger Quadros wrote:
> 
> On Wed, 10 Jun 2015 20:06:25 +0800
> Li Jun <b47624-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> 
> > On Tue, Jun 09, 2015 at 11:29:31PM +0800, Roger Quadros wrote:
> > > Rob,
> > > 
> > > On Tue, 9 Jun 2015 08:26:20 -0500
> > > Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > 
> > > > On Mon, Jun 8, 2015 at 8:18 PM, Li Jun <b47624-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> > > > > On Mon, Jun 08, 2015 at 11:06:49AM -0500, Rob Herring wrote:
> > > > >> On Mon, Jun 8, 2015 at 10:02 AM, Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> > > > >> > Add otg version, srp, hnp and adp support for usb OTG port, then those OTG
> > > > >> > features don't have to be decided by usb gadget drivers.
> > > > >> >
> > > > >> > Signed-off-by: Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> > > > >> > ---
> > > > >> >  Documentation/devicetree/bindings/usb/generic.txt | 10 ++++++++++
> > > > >> >  1 file changed, 10 insertions(+)
> > > > >> >
> > > > >> > diff --git a/Documentation/devicetree/bindings/usb/generic.txt b/Documentation/devicetree/bindings/usb/generic.txt
> > > > >> > index 477d5bb..7386f4a 100644
> > > > >> > --- a/Documentation/devicetree/bindings/usb/generic.txt
> > > > >> > +++ b/Documentation/devicetree/bindings/usb/generic.txt
> > > > >> > @@ -11,6 +11,12 @@ Optional properties:
> > > > >> >                         "peripheral" and "otg". In case this attribute isn't
> > > > >> >                         passed via DT, USB DRD controllers should default to
> > > > >> >                         OTG.
> > > > >> > + - otg-rev: tells usb driver the release number of the OTG and EH supplement
> > > > >> > +                       with which the device and its descriptors are compliant,
> > > > >> > +                       in binary-coded decimal (i.e. 2.0 is 0200H).
> > > > >>
> > > > >> I would assume OTG 2.0 is somehow backwards compatible? Is this a h/w
> > > > >> dependency or a driver feature?
> > > > >>
> > > > > Not fully compatible, OTG 2.0 extend the usb_otg_descriptor by adding a new
> > > > > member bcdOTG to identify the OTG version, this descriptor needs to be sent
> > > > > to OTG host with correct size and content, so we have to know which release
> > > > > version the OTG device is compliant with, either by menuconfig config or pass
> > > > > via DT.
> > > > 
> > > > So you have to change the version depending on the host you are
> > > > connected to? That really seems strange that plugging in a OTG 2.0
> > > > device to an OTG 1.3 host would not work and doesn't make for a good
> > > > user experience.
> > > 
> > > No. The OTG version in the OTG descriptor for any device is usually fixed for the
> > > lifetime of the product.
> > > 
> > > Let's assume it is 2.0.
> > > 
> > > If you plug this to OTG 1.0 host, it won't be an issue as OTG 1.0 host doesn't
> > > read the BCD version.
> > > 
> > But OTG 1.0 host will send a 1.x specific OTG request for the 2.0 device.
> > 
> > > > 
> > > > >> > + - srp-support: tells OTG controllers we want to enable SRP.
> > > > >> > + - hnp-support: tells OTG controllers we want to enable HNP.
> > > > >> > + - adp-support: tells OTG controllers we want to enable ADP.
> > > > >>
> > > > >> I've recently run into a problem[1] and found that I have to disable
> > > > >> OTG in the kernel to get my device to work. Having to turn-off OTG
> > > > >> seems like the wrong solution, and shifting the problem to DT seems
> > > > >> wrong too. Why is this not a user configurable option (within whatever
> > > > >> h/w constraints there are)?
> > > > > The problem of below link, seems your device is claiming it's a HNP capable
> > > > > OTG device, but connecting to a non-OTG port of your Host, assume your Host
> > > > > does have a OTG port, your Host issue a A_ALT_HNP_SUPPORT request to your
> > > > > OTG device to remind it can use another port with HNP, but the request failed
> > > > > (maybe STALL by your device, this request is defined in OTG 1.3 but obsolete
> > > > > in OTG 2.0), so your Host just stopped enumeration of your device, this is not
> > > > > reasonable because current OTG code is some out of data.
> > > > 
> > > > Do PCs have OTG ports typically? My expectation is that if I plug in
> > > > an OTG device as a B device to any host port, that it will work as a
> > > > device no matter what the host OTG capabilities are. If I have to
> > > > change the kernel config or DT, that is a problem.
> > > 
> > > AFAIK PCs don't have OTG ports.
> > > 
> > > If you plug in OTG device to a non-otg host port it will work as normal B-device.
> > > The host doesn't request for OTG descriptors and doesn't care what OTG features it
> > > supports or not.
> > > 
> > This is not true in OTG 1.x and our current code, the host still request for
> > OTG descriptor and check if HNP is supported by it if CONFIG_USB_OTG is enabled
> > for the host.
> 
> Looks like the current USB host/hub code assumes that if CONFIG_USB_OTG is set
> it is an OTG port even if it really isn't. This is wrong and the root of the problem.
> 

There is another condition to judge if it's a OTG port: the current port
number is equal to the otg port number(bus->otg_port), if not, it will
assume there is another port with OTG, and send a OTG 1.x request to the
connected OTG device.
After OTG 2.0 otg descriptor introduced, I can fix it in host/hub by checking
the OTG version before sending 1.x specific request.

> We need to have is_otg flag + attributes for host port case as well
> just like we have for device case.
> 
We can use bus->otg_port, if there is no otg port, don't make it match any
port number of your available host ports.
 
> cheers,
> -roger
> 
> > 
> > > > 
> > > > > I am trying to make those OTG feaures to be configurable options, you mean
> > > > > by sys?
> > > > 
> > > > Yes.
> > > 
> > > why do you need OTG features to be sysfs configurable other than for debugging?
> > > 
> > > > 
> > > > >> What are the valid combinations? When do we want these enabled or not?
> > > > >> Wouldn't default enabled be better?
> > > > >
> > > > > We want to enable all those support in kernel driver, but some platform or
> > > > > hardware may not want to enable any or some of them, so those hardware
> > > > > can disable it by not pass the property in dt, the 3 sub features of OTG are
> > > > > not mandatory for so called OTG device, normally we at least enable HNP, and
> > > > > SRP and ADP are optional.
> > > > 
> > > > Please answer my questions in the doc.
> > > > 
> > > > >>
> > > > >> We already have dr_mode property. How is it related to these?
> > > 
> > > dr_mode states what mode the controller will operate in.
> > > 
> > > for dr_mode == "host" we don't care about these otg flags.
> > > 
> > > for dr_mode == "peripheral" or dr_mode == "otg"
> > > we care about these OTG flags to create our OTG descriptor on the fly.
> > > 
> > 
> > Yes.
> > 
> > > > >
> > > > > dr_mode is to tell the device it will work at OTG mode(there is another simple
> > > > > dual role mode which is commom used but not HNP), srp/hnp/adp can further specify
> > > > > which protocol the OTG device will support.
> > > > 
> > > > By simple DR, you mean ID pin detect, right. So please define how you
> > > > support just ID pin detect vs. other levels of capability. Does only
> > > > dr_mode = otg mean ID pin detect? That may be a problem for existing
> > > > DTs if you disable other OTG functions because they have not been
> > > > added to the DT, then that is a problem.
> > > > 
> > > > I'm feeling less convinced that this belongs in DT at all. Please
> > > > convince me otherwise.
> > > 
> > > Yes not specifying anything in DT should work and default to the
> > > best OTG version and features supported by the OTG controller.
> > > 
> > > But if the device manufacturer wants to restrict the OTG version
> > > to something less or disable some OTG features then the DT flags come
> > > into play.
> > > 
> > agree.
> > 
> > > cheers,
> > > -roger
> > 
> > Li Jun
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 05/22] doc: dt-binding: usb: add otg related properties

[Roger Quadros]

On Thu, 11 Jun 2015 16:38:52 +0800
Li Jun <b47624-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:

> On Thu, Jun 11, 2015 at 10:30:35AM +0300, Roger Quadros wrote:
> > 
> > On Wed, 10 Jun 2015 20:06:25 +0800
> > Li Jun <b47624-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> > 
> > > On Tue, Jun 09, 2015 at 11:29:31PM +0800, Roger Quadros wrote:
> > > > Rob,
> > > > 
> > > > On Tue, 9 Jun 2015 08:26:20 -0500
> > > > Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > > 
> > > > > On Mon, Jun 8, 2015 at 8:18 PM, Li Jun <b47624-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> > > > > > On Mon, Jun 08, 2015 at 11:06:49AM -0500, Rob Herring wrote:
> > > > > >> On Mon, Jun 8, 2015 at 10:02 AM, Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> > > > > >> > Add otg version, srp, hnp and adp support for usb OTG port, then those OTG
> > > > > >> > features don't have to be decided by usb gadget drivers.
> > > > > >> >
> > > > > >> > Signed-off-by: Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> > > > > >> > ---
> > > > > >> >  Documentation/devicetree/bindings/usb/generic.txt | 10 ++++++++++
> > > > > >> >  1 file changed, 10 insertions(+)
> > > > > >> >
> > > > > >> > diff --git a/Documentation/devicetree/bindings/usb/generic.txt b/Documentation/devicetree/bindings/usb/generic.txt
> > > > > >> > index 477d5bb..7386f4a 100644
> > > > > >> > --- a/Documentation/devicetree/bindings/usb/generic.txt
> > > > > >> > +++ b/Documentation/devicetree/bindings/usb/generic.txt
> > > > > >> > @@ -11,6 +11,12 @@ Optional properties:
> > > > > >> >                         "peripheral" and "otg". In case this attribute isn't
> > > > > >> >                         passed via DT, USB DRD controllers should default to
> > > > > >> >                         OTG.
> > > > > >> > + - otg-rev: tells usb driver the release number of the OTG and EH supplement
> > > > > >> > +                       with which the device and its descriptors are compliant,
> > > > > >> > +                       in binary-coded decimal (i.e. 2.0 is 0200H).
> > > > > >>
> > > > > >> I would assume OTG 2.0 is somehow backwards compatible? Is this a h/w
> > > > > >> dependency or a driver feature?
> > > > > >>
> > > > > > Not fully compatible, OTG 2.0 extend the usb_otg_descriptor by adding a new
> > > > > > member bcdOTG to identify the OTG version, this descriptor needs to be sent
> > > > > > to OTG host with correct size and content, so we have to know which release
> > > > > > version the OTG device is compliant with, either by menuconfig config or pass
> > > > > > via DT.
> > > > > 
> > > > > So you have to change the version depending on the host you are
> > > > > connected to? That really seems strange that plugging in a OTG 2.0
> > > > > device to an OTG 1.3 host would not work and doesn't make for a good
> > > > > user experience.
> > > > 
> > > > No. The OTG version in the OTG descriptor for any device is usually fixed for the
> > > > lifetime of the product.
> > > > 
> > > > Let's assume it is 2.0.
> > > > 
> > > > If you plug this to OTG 1.0 host, it won't be an issue as OTG 1.0 host doesn't
> > > > read the BCD version.
> > > > 
> > > But OTG 1.0 host will send a 1.x specific OTG request for the 2.0 device.
> > > 
> > > > > 
> > > > > >> > + - srp-support: tells OTG controllers we want to enable SRP.
> > > > > >> > + - hnp-support: tells OTG controllers we want to enable HNP.
> > > > > >> > + - adp-support: tells OTG controllers we want to enable ADP.
> > > > > >>
> > > > > >> I've recently run into a problem[1] and found that I have to disable
> > > > > >> OTG in the kernel to get my device to work. Having to turn-off OTG
> > > > > >> seems like the wrong solution, and shifting the problem to DT seems
> > > > > >> wrong too. Why is this not a user configurable option (within whatever
> > > > > >> h/w constraints there are)?
> > > > > > The problem of below link, seems your device is claiming it's a HNP capable
> > > > > > OTG device, but connecting to a non-OTG port of your Host, assume your Host
> > > > > > does have a OTG port, your Host issue a A_ALT_HNP_SUPPORT request to your
> > > > > > OTG device to remind it can use another port with HNP, but the request failed
> > > > > > (maybe STALL by your device, this request is defined in OTG 1.3 but obsolete
> > > > > > in OTG 2.0), so your Host just stopped enumeration of your device, this is not
> > > > > > reasonable because current OTG code is some out of data.
> > > > > 
> > > > > Do PCs have OTG ports typically? My expectation is that if I plug in
> > > > > an OTG device as a B device to any host port, that it will work as a
> > > > > device no matter what the host OTG capabilities are. If I have to
> > > > > change the kernel config or DT, that is a problem.
> > > > 
> > > > AFAIK PCs don't have OTG ports.
> > > > 
> > > > If you plug in OTG device to a non-otg host port it will work as normal B-device.
> > > > The host doesn't request for OTG descriptors and doesn't care what OTG features it
> > > > supports or not.
> > > > 
> > > This is not true in OTG 1.x and our current code, the host still request for
> > > OTG descriptor and check if HNP is supported by it if CONFIG_USB_OTG is enabled
> > > for the host.
> > 
> > Looks like the current USB host/hub code assumes that if CONFIG_USB_OTG is set
> > it is an OTG port even if it really isn't. This is wrong and the root of the problem.
> > 
> 
> There is another condition to judge if it's a OTG port: the current port
> number is equal to the otg port number(bus->otg_port), if not, it will
> assume there is another port with OTG, and send a OTG 1.x request to the
> connected OTG device.
> After OTG 2.0 otg descriptor introduced, I can fix it in host/hub by checking
> the OTG version before sending 1.x specific request.

That is not the issue.

This is the existing code I'm talking about

drivers/usb/core/hub.c

static int usb_enumerate_device_otg(struct usb_device *udev)
{
	int err = 0;

#ifdef	CONFIG_USB_OTG
	/*
	 * OTG-aware devices on OTG-capable root hubs may be able to use SRP,
	 * to wake us after we've powered off VBUS; and HNP, switching roles
	 * "host" to "peripheral".  The OTG descriptor helps figure this out.
	 */
	if (!udev->bus->is_b_host
			&& udev->config
			&& udev->parent == udev->bus->root_hub) {
		struct usb_otg_descriptor	*desc = NULL;
		struct usb_bus			*bus = udev->bus;

		/* descriptor may appear anywhere in config */
		if (__usb_get_extra_descriptor (udev->rawdescriptors[0],
					le16_to_cpu(udev->config[0].desc.wTotalLength),
					USB_DT_OTG, (void **) &desc) == 0) {
			if (desc->bmAttributes & USB_OTG_HNP) {
				unsigned		port1 = udev->portnum;

				dev_info(&udev->dev,
					"Dual-Role OTG device on %sHNP port\n",
					(port1 == bus->otg_port)
						? "" : "non-");

				/* enable HNP before suspend, it's simpler */
				if (port1 == bus->otg_port)
					bus->b_hnp_enable = 1;
				err = usb_control_msg(udev,
					usb_sndctrlpipe(udev, 0),
					USB_REQ_SET_FEATURE, 0,
					bus->b_hnp_enable
						? USB_DEVICE_B_HNP_ENABLE
						: USB_DEVICE_A_ALT_HNP_SUPPORT,
					0, NULL, 0, USB_CTRL_SET_TIMEOUT);

We're sending out this control request even if this host port is not OTG.
Isn't that wrong?

				if (err < 0) {
					/* OTG MESSAGE: report errors here,
					 * customize to match your product.
					 */
					dev_info(&udev->dev,
						"can't set HNP mode: %d\n",
						err);
					bus->b_hnp_enable = 0;
				}

Instead it should be moved inside the if (port1 == bus->otg_port) condition.

			}
		}
	}
#endif
	return err;
}

cheers,
-roger

> 
> > We need to have is_otg flag + attributes for host port case as well
> > just like we have for device case.
> > 
> We can use bus->otg_port, if there is no otg port, don't make it match any
> port number of your available host ports.
>  
> > cheers,
> > -roger
> > 
> > > 
> > > > > 
> > > > > > I am trying to make those OTG feaures to be configurable options, you mean
> > > > > > by sys?
> > > > > 
> > > > > Yes.
> > > > 
> > > > why do you need OTG features to be sysfs configurable other than for debugging?
> > > > 
> > > > > 
> > > > > >> What are the valid combinations? When do we want these enabled or not?
> > > > > >> Wouldn't default enabled be better?
> > > > > >
> > > > > > We want to enable all those support in kernel driver, but some platform or
> > > > > > hardware may not want to enable any or some of them, so those hardware
> > > > > > can disable it by not pass the property in dt, the 3 sub features of OTG are
> > > > > > not mandatory for so called OTG device, normally we at least enable HNP, and
> > > > > > SRP and ADP are optional.
> > > > > 
> > > > > Please answer my questions in the doc.
> > > > > 
> > > > > >>
> > > > > >> We already have dr_mode property. How is it related to these?
> > > > 
> > > > dr_mode states what mode the controller will operate in.
> > > > 
> > > > for dr_mode == "host" we don't care about these otg flags.
> > > > 
> > > > for dr_mode == "peripheral" or dr_mode == "otg"
> > > > we care about these OTG flags to create our OTG descriptor on the fly.
> > > > 
> > > 
> > > Yes.
> > > 
> > > > > >
> > > > > > dr_mode is to tell the device it will work at OTG mode(there is another simple
> > > > > > dual role mode which is commom used but not HNP), srp/hnp/adp can further specify
> > > > > > which protocol the OTG device will support.
> > > > > 
> > > > > By simple DR, you mean ID pin detect, right. So please define how you
> > > > > support just ID pin detect vs. other levels of capability. Does only
> > > > > dr_mode = otg mean ID pin detect? That may be a problem for existing
> > > > > DTs if you disable other OTG functions because they have not been
> > > > > added to the DT, then that is a problem.
> > > > > 
> > > > > I'm feeling less convinced that this belongs in DT at all. Please
> > > > > convince me otherwise.
> > > > 
> > > > Yes not specifying anything in DT should work and default to the
> > > > best OTG version and features supported by the OTG controller.
> > > > 
> > > > But if the device manufacturer wants to restrict the OTG version
> > > > to something less or disable some OTG features then the DT flags come
> > > > into play.
> > > > 
> > > agree.
> > > 
> > > > cheers,
> > > > -roger
> > > 
> > > Li Jun
> > 

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 05/22] doc: dt-binding: usb: add otg related properties

[Li Jun]

On Thu, Jun 11, 2015 at 03:51:02PM +0300, Roger Quadros wrote:
> 
> On Thu, 11 Jun 2015 16:38:52 +0800
> Li Jun <b47624-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> 
> > On Thu, Jun 11, 2015 at 10:30:35AM +0300, Roger Quadros wrote:
> > > 
> > > On Wed, 10 Jun 2015 20:06:25 +0800
> > > Li Jun <b47624-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> > > 
> > > > On Tue, Jun 09, 2015 at 11:29:31PM +0800, Roger Quadros wrote:
> > > > > Rob,
> > > > > 
> > > > > On Tue, 9 Jun 2015 08:26:20 -0500
> > > > > Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > > > 
> > > > > > On Mon, Jun 8, 2015 at 8:18 PM, Li Jun <b47624-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> > > > > > > On Mon, Jun 08, 2015 at 11:06:49AM -0500, Rob Herring wrote:
> > > > > > >> On Mon, Jun 8, 2015 at 10:02 AM, Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> > > > > > >> > Add otg version, srp, hnp and adp support for usb OTG port, then those OTG
> > > > > > >> > features don't have to be decided by usb gadget drivers.
> > > > > > >> >
> > > > > > >> > Signed-off-by: Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> > > > > > >> > ---
> > > > > > >> >  Documentation/devicetree/bindings/usb/generic.txt | 10 ++++++++++
> > > > > > >> >  1 file changed, 10 insertions(+)
> > > > > > >> >
> > > > > > >> > diff --git a/Documentation/devicetree/bindings/usb/generic.txt b/Documentation/devicetree/bindings/usb/generic.txt
> > > > > > >> > index 477d5bb..7386f4a 100644
> > > > > > >> > --- a/Documentation/devicetree/bindings/usb/generic.txt
> > > > > > >> > +++ b/Documentation/devicetree/bindings/usb/generic.txt
> > > > > > >> > @@ -11,6 +11,12 @@ Optional properties:
> > > > > > >> >                         "peripheral" and "otg". In case this attribute isn't
> > > > > > >> >                         passed via DT, USB DRD controllers should default to
> > > > > > >> >                         OTG.
> > > > > > >> > + - otg-rev: tells usb driver the release number of the OTG and EH supplement
> > > > > > >> > +                       with which the device and its descriptors are compliant,
> > > > > > >> > +                       in binary-coded decimal (i.e. 2.0 is 0200H).
> > > > > > >>
> > > > > > >> I would assume OTG 2.0 is somehow backwards compatible? Is this a h/w
> > > > > > >> dependency or a driver feature?
> > > > > > >>
> > > > > > > Not fully compatible, OTG 2.0 extend the usb_otg_descriptor by adding a new
> > > > > > > member bcdOTG to identify the OTG version, this descriptor needs to be sent
> > > > > > > to OTG host with correct size and content, so we have to know which release
> > > > > > > version the OTG device is compliant with, either by menuconfig config or pass
> > > > > > > via DT.
> > > > > > 
> > > > > > So you have to change the version depending on the host you are
> > > > > > connected to? That really seems strange that plugging in a OTG 2.0
> > > > > > device to an OTG 1.3 host would not work and doesn't make for a good
> > > > > > user experience.
> > > > > 
> > > > > No. The OTG version in the OTG descriptor for any device is usually fixed for the
> > > > > lifetime of the product.
> > > > > 
> > > > > Let's assume it is 2.0.
> > > > > 
> > > > > If you plug this to OTG 1.0 host, it won't be an issue as OTG 1.0 host doesn't
> > > > > read the BCD version.
> > > > > 
> > > > But OTG 1.0 host will send a 1.x specific OTG request for the 2.0 device.
> > > > 
> > > > > > 
> > > > > > >> > + - srp-support: tells OTG controllers we want to enable SRP.
> > > > > > >> > + - hnp-support: tells OTG controllers we want to enable HNP.
> > > > > > >> > + - adp-support: tells OTG controllers we want to enable ADP.
> > > > > > >>
> > > > > > >> I've recently run into a problem[1] and found that I have to disable
> > > > > > >> OTG in the kernel to get my device to work. Having to turn-off OTG
> > > > > > >> seems like the wrong solution, and shifting the problem to DT seems
> > > > > > >> wrong too. Why is this not a user configurable option (within whatever
> > > > > > >> h/w constraints there are)?
> > > > > > > The problem of below link, seems your device is claiming it's a HNP capable
> > > > > > > OTG device, but connecting to a non-OTG port of your Host, assume your Host
> > > > > > > does have a OTG port, your Host issue a A_ALT_HNP_SUPPORT request to your
> > > > > > > OTG device to remind it can use another port with HNP, but the request failed
> > > > > > > (maybe STALL by your device, this request is defined in OTG 1.3 but obsolete
> > > > > > > in OTG 2.0), so your Host just stopped enumeration of your device, this is not
> > > > > > > reasonable because current OTG code is some out of data.
> > > > > > 
> > > > > > Do PCs have OTG ports typically? My expectation is that if I plug in
> > > > > > an OTG device as a B device to any host port, that it will work as a
> > > > > > device no matter what the host OTG capabilities are. If I have to
> > > > > > change the kernel config or DT, that is a problem.
> > > > > 
> > > > > AFAIK PCs don't have OTG ports.
> > > > > 
> > > > > If you plug in OTG device to a non-otg host port it will work as normal B-device.
> > > > > The host doesn't request for OTG descriptors and doesn't care what OTG features it
> > > > > supports or not.
> > > > > 
> > > > This is not true in OTG 1.x and our current code, the host still request for
> > > > OTG descriptor and check if HNP is supported by it if CONFIG_USB_OTG is enabled
> > > > for the host.
> > > 
> > > Looks like the current USB host/hub code assumes that if CONFIG_USB_OTG is set
> > > it is an OTG port even if it really isn't. This is wrong and the root of the problem.
> > > 
> > 
> > There is another condition to judge if it's a OTG port: the current port
> > number is equal to the otg port number(bus->otg_port), if not, it will
> > assume there is another port with OTG, and send a OTG 1.x request to the
> > connected OTG device.
> > After OTG 2.0 otg descriptor introduced, I can fix it in host/hub by checking
> > the OTG version before sending 1.x specific request.
> 
> That is not the issue.
> 
> This is the existing code I'm talking about
> 
> drivers/usb/core/hub.c
> 
> static int usb_enumerate_device_otg(struct usb_device *udev)
> {
> 	int err = 0;
> 
> #ifdef	CONFIG_USB_OTG
> 	/*
> 	 * OTG-aware devices on OTG-capable root hubs may be able to use SRP,
> 	 * to wake us after we've powered off VBUS; and HNP, switching roles
> 	 * "host" to "peripheral".  The OTG descriptor helps figure this out.
> 	 */
> 	if (!udev->bus->is_b_host
> 			&& udev->config
> 			&& udev->parent == udev->bus->root_hub) {
> 		struct usb_otg_descriptor	*desc = NULL;
> 		struct usb_bus			*bus = udev->bus;
> 
> 		/* descriptor may appear anywhere in config */
> 		if (__usb_get_extra_descriptor (udev->rawdescriptors[0],
> 					le16_to_cpu(udev->config[0].desc.wTotalLength),
> 					USB_DT_OTG, (void **) &desc) == 0) {
> 			if (desc->bmAttributes & USB_OTG_HNP) {
> 				unsigned		port1 = udev->portnum;
> 
> 				dev_info(&udev->dev,
> 					"Dual-Role OTG device on %sHNP port\n",
> 					(port1 == bus->otg_port)
> 						? "" : "non-");
> 
> 				/* enable HNP before suspend, it's simpler */
> 				if (port1 == bus->otg_port)
> 					bus->b_hnp_enable = 1;
> 				err = usb_control_msg(udev,
> 					usb_sndctrlpipe(udev, 0),
> 					USB_REQ_SET_FEATURE, 0,
> 					bus->b_hnp_enable
> 						? USB_DEVICE_B_HNP_ENABLE
> 						: USB_DEVICE_A_ALT_HNP_SUPPORT,
> 					0, NULL, 0, USB_CTRL_SET_TIMEOUT);
> 
> We're sending out this control request even if this host port is not OTG.
> Isn't that wrong?

So send USB_DEVICE_A_ALT_HNP_SUPPORT request.
This is correct in OTG 1.x, its intention is to remind the user who is
connecting the HNP capable OTG device to a non-OTG port, He can change
to another port of this machine which is a OTG port(with HNP).

> 
> 				if (err < 0) {
> 					/* OTG MESSAGE: report errors here,
> 					 * customize to match your product.
> 					 */
> 					dev_info(&udev->dev,
> 						"can't set HNP mode: %d\n",
> 						err);
> 					bus->b_hnp_enable = 0;
> 				}
> 
> Instead it should be moved inside the if (port1 == bus->otg_port) condition.

Nope, as I explained above, this is really too detailed OTG protocol:)
> 
> 			}
> 		}
> 	}
> #endif
> 	return err;
> }
> 
> cheers,
> -roger
> 
> > 
> > > We need to have is_otg flag + attributes for host port case as well
> > > just like we have for device case.
> > > 
> > We can use bus->otg_port, if there is no otg port, don't make it match any
> > port number of your available host ports.
> >  
> > > cheers,
> > > -roger
> > > 
> > > > 
> > > > > > 
> > > > > > > I am trying to make those OTG feaures to be configurable options, you mean
> > > > > > > by sys?
> > > > > > 
> > > > > > Yes.
> > > > > 
> > > > > why do you need OTG features to be sysfs configurable other than for debugging?
> > > > > 
> > > > > > 
> > > > > > >> What are the valid combinations? When do we want these enabled or not?
> > > > > > >> Wouldn't default enabled be better?
> > > > > > >
> > > > > > > We want to enable all those support in kernel driver, but some platform or
> > > > > > > hardware may not want to enable any or some of them, so those hardware
> > > > > > > can disable it by not pass the property in dt, the 3 sub features of OTG are
> > > > > > > not mandatory for so called OTG device, normally we at least enable HNP, and
> > > > > > > SRP and ADP are optional.
> > > > > > 
> > > > > > Please answer my questions in the doc.
> > > > > > 
> > > > > > >>
> > > > > > >> We already have dr_mode property. How is it related to these?
> > > > > 
> > > > > dr_mode states what mode the controller will operate in.
> > > > > 
> > > > > for dr_mode == "host" we don't care about these otg flags.
> > > > > 
> > > > > for dr_mode == "peripheral" or dr_mode == "otg"
> > > > > we care about these OTG flags to create our OTG descriptor on the fly.
> > > > > 
> > > > 
> > > > Yes.
> > > > 
> > > > > > >
> > > > > > > dr_mode is to tell the device it will work at OTG mode(there is another simple
> > > > > > > dual role mode which is commom used but not HNP), srp/hnp/adp can further specify
> > > > > > > which protocol the OTG device will support.
> > > > > > 
> > > > > > By simple DR, you mean ID pin detect, right. So please define how you
> > > > > > support just ID pin detect vs. other levels of capability. Does only
> > > > > > dr_mode = otg mean ID pin detect? That may be a problem for existing
> > > > > > DTs if you disable other OTG functions because they have not been
> > > > > > added to the DT, then that is a problem.
> > > > > > 
> > > > > > I'm feeling less convinced that this belongs in DT at all. Please
> > > > > > convince me otherwise.
> > > > > 
> > > > > Yes not specifying anything in DT should work and default to the
> > > > > best OTG version and features supported by the OTG controller.
> > > > > 
> > > > > But if the device manufacturer wants to restrict the OTG version
> > > > > to something less or disable some OTG features then the DT flags come
> > > > > into play.
> > > > > 
> > > > agree.
> > > > 
> > > > > cheers,
> > > > > -roger
> > > > 
> > > > Li Jun
> > > 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 05/22] doc: dt-binding: usb: add otg related properties

[Roger Quadros]

On Thu, 11 Jun 2015 22:22:09 +0800
Li Jun <b47624-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:

> On Thu, Jun 11, 2015 at 03:51:02PM +0300, Roger Quadros wrote:
> > 
> > On Thu, 11 Jun 2015 16:38:52 +0800
> > Li Jun <b47624-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> > 
> > > On Thu, Jun 11, 2015 at 10:30:35AM +0300, Roger Quadros wrote:
> > > > 
> > > > On Wed, 10 Jun 2015 20:06:25 +0800
> > > > Li Jun <b47624-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> > > > 
> > > > > On Tue, Jun 09, 2015 at 11:29:31PM +0800, Roger Quadros wrote:
> > > > > > Rob,
> > > > > > 
> > > > > > On Tue, 9 Jun 2015 08:26:20 -0500
> > > > > > Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > > > > 
> > > > > > > On Mon, Jun 8, 2015 at 8:18 PM, Li Jun <b47624-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> > > > > > > > On Mon, Jun 08, 2015 at 11:06:49AM -0500, Rob Herring wrote:
> > > > > > > >> On Mon, Jun 8, 2015 at 10:02 AM, Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> > > > > > > >> > Add otg version, srp, hnp and adp support for usb OTG port, then those OTG
> > > > > > > >> > features don't have to be decided by usb gadget drivers.
> > > > > > > >> >
> > > > > > > >> > Signed-off-by: Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> > > > > > > >> > ---
> > > > > > > >> >  Documentation/devicetree/bindings/usb/generic.txt | 10 ++++++++++
> > > > > > > >> >  1 file changed, 10 insertions(+)
> > > > > > > >> >
> > > > > > > >> > diff --git a/Documentation/devicetree/bindings/usb/generic.txt b/Documentation/devicetree/bindings/usb/generic.txt
> > > > > > > >> > index 477d5bb..7386f4a 100644
> > > > > > > >> > --- a/Documentation/devicetree/bindings/usb/generic.txt
> > > > > > > >> > +++ b/Documentation/devicetree/bindings/usb/generic.txt
> > > > > > > >> > @@ -11,6 +11,12 @@ Optional properties:
> > > > > > > >> >                         "peripheral" and "otg". In case this attribute isn't
> > > > > > > >> >                         passed via DT, USB DRD controllers should default to
> > > > > > > >> >                         OTG.
> > > > > > > >> > + - otg-rev: tells usb driver the release number of the OTG and EH supplement
> > > > > > > >> > +                       with which the device and its descriptors are compliant,
> > > > > > > >> > +                       in binary-coded decimal (i.e. 2.0 is 0200H).
> > > > > > > >>
> > > > > > > >> I would assume OTG 2.0 is somehow backwards compatible? Is this a h/w
> > > > > > > >> dependency or a driver feature?
> > > > > > > >>
> > > > > > > > Not fully compatible, OTG 2.0 extend the usb_otg_descriptor by adding a new
> > > > > > > > member bcdOTG to identify the OTG version, this descriptor needs to be sent
> > > > > > > > to OTG host with correct size and content, so we have to know which release
> > > > > > > > version the OTG device is compliant with, either by menuconfig config or pass
> > > > > > > > via DT.
> > > > > > > 
> > > > > > > So you have to change the version depending on the host you are
> > > > > > > connected to? That really seems strange that plugging in a OTG 2.0
> > > > > > > device to an OTG 1.3 host would not work and doesn't make for a good
> > > > > > > user experience.
> > > > > > 
> > > > > > No. The OTG version in the OTG descriptor for any device is usually fixed for the
> > > > > > lifetime of the product.
> > > > > > 
> > > > > > Let's assume it is 2.0.
> > > > > > 
> > > > > > If you plug this to OTG 1.0 host, it won't be an issue as OTG 1.0 host doesn't
> > > > > > read the BCD version.
> > > > > > 
> > > > > But OTG 1.0 host will send a 1.x specific OTG request for the 2.0 device.
> > > > > 
> > > > > > > 
> > > > > > > >> > + - srp-support: tells OTG controllers we want to enable SRP.
> > > > > > > >> > + - hnp-support: tells OTG controllers we want to enable HNP.
> > > > > > > >> > + - adp-support: tells OTG controllers we want to enable ADP.
> > > > > > > >>
> > > > > > > >> I've recently run into a problem[1] and found that I have to disable
> > > > > > > >> OTG in the kernel to get my device to work. Having to turn-off OTG
> > > > > > > >> seems like the wrong solution, and shifting the problem to DT seems
> > > > > > > >> wrong too. Why is this not a user configurable option (within whatever
> > > > > > > >> h/w constraints there are)?
> > > > > > > > The problem of below link, seems your device is claiming it's a HNP capable
> > > > > > > > OTG device, but connecting to a non-OTG port of your Host, assume your Host
> > > > > > > > does have a OTG port, your Host issue a A_ALT_HNP_SUPPORT request to your
> > > > > > > > OTG device to remind it can use another port with HNP, but the request failed
> > > > > > > > (maybe STALL by your device, this request is defined in OTG 1.3 but obsolete
> > > > > > > > in OTG 2.0), so your Host just stopped enumeration of your device, this is not
> > > > > > > > reasonable because current OTG code is some out of data.
> > > > > > > 
> > > > > > > Do PCs have OTG ports typically? My expectation is that if I plug in
> > > > > > > an OTG device as a B device to any host port, that it will work as a
> > > > > > > device no matter what the host OTG capabilities are. If I have to
> > > > > > > change the kernel config or DT, that is a problem.
> > > > > > 
> > > > > > AFAIK PCs don't have OTG ports.
> > > > > > 
> > > > > > If you plug in OTG device to a non-otg host port it will work as normal B-device.
> > > > > > The host doesn't request for OTG descriptors and doesn't care what OTG features it
> > > > > > supports or not.
> > > > > > 
> > > > > This is not true in OTG 1.x and our current code, the host still request for
> > > > > OTG descriptor and check if HNP is supported by it if CONFIG_USB_OTG is enabled
> > > > > for the host.
> > > > 
> > > > Looks like the current USB host/hub code assumes that if CONFIG_USB_OTG is set
> > > > it is an OTG port even if it really isn't. This is wrong and the root of the problem.
> > > > 
> > > 
> > > There is another condition to judge if it's a OTG port: the current port
> > > number is equal to the otg port number(bus->otg_port), if not, it will
> > > assume there is another port with OTG, and send a OTG 1.x request to the
> > > connected OTG device.
> > > After OTG 2.0 otg descriptor introduced, I can fix it in host/hub by checking
> > > the OTG version before sending 1.x specific request.
> > 
> > That is not the issue.
> > 
> > This is the existing code I'm talking about
> > 
> > drivers/usb/core/hub.c
> > 
> > static int usb_enumerate_device_otg(struct usb_device *udev)
> > {
> > 	int err = 0;
> > 
> > #ifdef	CONFIG_USB_OTG
> > 	/*
> > 	 * OTG-aware devices on OTG-capable root hubs may be able to use SRP,
> > 	 * to wake us after we've powered off VBUS; and HNP, switching roles
> > 	 * "host" to "peripheral".  The OTG descriptor helps figure this out.
> > 	 */
> > 	if (!udev->bus->is_b_host
> > 			&& udev->config
> > 			&& udev->parent == udev->bus->root_hub) {
> > 		struct usb_otg_descriptor	*desc = NULL;
> > 		struct usb_bus			*bus = udev->bus;
> > 
> > 		/* descriptor may appear anywhere in config */
> > 		if (__usb_get_extra_descriptor (udev->rawdescriptors[0],
> > 					le16_to_cpu(udev->config[0].desc.wTotalLength),
> > 					USB_DT_OTG, (void **) &desc) == 0) {
> > 			if (desc->bmAttributes & USB_OTG_HNP) {
> > 				unsigned		port1 = udev->portnum;
> > 
> > 				dev_info(&udev->dev,
> > 					"Dual-Role OTG device on %sHNP port\n",
> > 					(port1 == bus->otg_port)
> > 						? "" : "non-");
> > 
> > 				/* enable HNP before suspend, it's simpler */
> > 				if (port1 == bus->otg_port)
> > 					bus->b_hnp_enable = 1;
> > 				err = usb_control_msg(udev,
> > 					usb_sndctrlpipe(udev, 0),
> > 					USB_REQ_SET_FEATURE, 0,
> > 					bus->b_hnp_enable
> > 						? USB_DEVICE_B_HNP_ENABLE
> > 						: USB_DEVICE_A_ALT_HNP_SUPPORT,
> > 					0, NULL, 0, USB_CTRL_SET_TIMEOUT);
> > 
> > We're sending out this control request even if this host port is not OTG.
> > Isn't that wrong?
> 
> So send USB_DEVICE_A_ALT_HNP_SUPPORT request.
> This is correct in OTG 1.x, its intention is to remind the user who is
> connecting the HNP capable OTG device to a non-OTG port, He can change
> to another port of this machine which is a OTG port(with HNP).

I didn't understand.
If CONFIG_USB_OTG is enabled doesn't mean that this USB host port is OTG host.
So it should not send any OTG specific request to device. Right?

> 
> > 
> > 				if (err < 0) {
> > 					/* OTG MESSAGE: report errors here,
> > 					 * customize to match your product.
> > 					 */
> > 					dev_info(&udev->dev,
> > 						"can't set HNP mode: %d\n",
> > 						err);
> > 					bus->b_hnp_enable = 0;
> > 				}
> > 
> > Instead it should be moved inside the if (port1 == bus->otg_port) condition.
> 
> Nope, as I explained above, this is really too detailed OTG protocol:)
> > 
> > 			}
> > 		}
> > 	}
> > #endif
> > 	return err;
> > }
> > 

cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 05/22] doc: dt-binding: usb: add otg related properties

[Li Jun]

On Thu, Jun 11, 2015 at 05:55:57PM +0300, Roger Quadros wrote:
> > > drivers/usb/core/hub.c
> > > 
> > > static int usb_enumerate_device_otg(struct usb_device *udev)
> > > {
> > > 	int err = 0;
> > > 
> > > #ifdef	CONFIG_USB_OTG
> > > 	/*
> > > 	 * OTG-aware devices on OTG-capable root hubs may be able to use SRP,
> > > 	 * to wake us after we've powered off VBUS; and HNP, switching roles
> > > 	 * "host" to "peripheral".  The OTG descriptor helps figure this out.
> > > 	 */
> > > 	if (!udev->bus->is_b_host
> > > 			&& udev->config
> > > 			&& udev->parent == udev->bus->root_hub) {
> > > 		struct usb_otg_descriptor	*desc = NULL;
> > > 		struct usb_bus			*bus = udev->bus;
> > > 
> > > 		/* descriptor may appear anywhere in config */
> > > 		if (__usb_get_extra_descriptor (udev->rawdescriptors[0],
> > > 					le16_to_cpu(udev->config[0].desc.wTotalLength),
> > > 					USB_DT_OTG, (void **) &desc) == 0) {
> > > 			if (desc->bmAttributes & USB_OTG_HNP) {
> > > 				unsigned		port1 = udev->portnum;
> > > 
> > > 				dev_info(&udev->dev,
> > > 					"Dual-Role OTG device on %sHNP port\n",
> > > 					(port1 == bus->otg_port)
> > > 						? "" : "non-");
> > > 
> > > 				/* enable HNP before suspend, it's simpler */
> > > 				if (port1 == bus->otg_port)
> > > 					bus->b_hnp_enable = 1;
> > > 				err = usb_control_msg(udev,
> > > 					usb_sndctrlpipe(udev, 0),
> > > 					USB_REQ_SET_FEATURE, 0,
> > > 					bus->b_hnp_enable
> > > 						? USB_DEVICE_B_HNP_ENABLE
> > > 						: USB_DEVICE_A_ALT_HNP_SUPPORT,
> > > 					0, NULL, 0, USB_CTRL_SET_TIMEOUT);
> > > 
> > > We're sending out this control request even if this host port is not OTG.
> > > Isn't that wrong?
> > 
> > So send USB_DEVICE_A_ALT_HNP_SUPPORT request.
> > This is correct in OTG 1.x, its intention is to remind the user who is
> > connecting the HNP capable OTG device to a non-OTG port, He can change
> > to another port of this machine which is a OTG port(with HNP).
> 
> I didn't understand.
> If CONFIG_USB_OTG is enabled doesn't mean that this USB host port is OTG host.
Yes, only CONFIG_USB_OTG enabled doesn't mean that this USB host port
is a OTG port, there are might multiple usb host ports, but only one
is a OTG port.
> So it should not send any OTG specific request to device. Right?
Non-otg port(in OTG 1.x protocol) + OTG 1.x device, should send,
otherwise, should not send.

So the code you pasted here was right only for OTG 1.x, I assume
OTG 2.0 has not been released when it was designed. But now it's
out of date, it's wrong if you connect a OTG 2.0 device. 

> 
> > 
> > > 
> > > 				if (err < 0) {
> > > 					/* OTG MESSAGE: report errors here,
> > > 					 * customize to match your product.
> > > 					 */
> > > 					dev_info(&udev->dev,
> > > 						"can't set HNP mode: %d\n",
> > > 						err);
> > > 					bus->b_hnp_enable = 0;
> > > 				}
> > > 
> > > Instead it should be moved inside the if (port1 == bus->otg_port) condition.
> > 
> > Nope, as I explained above, this is really too detailed OTG protocol:)
> > > 
> > > 			}
> > > 		}
> > > 	}
> > > #endif
> > > 	return err;
> > > }
> > > 
> 
> cheers,
> -roger
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 05/22] doc: dt-binding: usb: add otg related properties

[Roger Quadros]

On Fri, 12 Jun 2015 09:42:04 +0800
Li Jun <b47624-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:

> On Thu, Jun 11, 2015 at 05:55:57PM +0300, Roger Quadros wrote:
> > > > drivers/usb/core/hub.c
> > > > 
> > > > static int usb_enumerate_device_otg(struct usb_device *udev)
> > > > {
> > > > 	int err = 0;
> > > > 
> > > > #ifdef	CONFIG_USB_OTG
> > > > 	/*
> > > > 	 * OTG-aware devices on OTG-capable root hubs may be able to use SRP,
> > > > 	 * to wake us after we've powered off VBUS; and HNP, switching roles
> > > > 	 * "host" to "peripheral".  The OTG descriptor helps figure this out.
> > > > 	 */
> > > > 	if (!udev->bus->is_b_host
> > > > 			&& udev->config
> > > > 			&& udev->parent == udev->bus->root_hub) {
> > > > 		struct usb_otg_descriptor	*desc = NULL;
> > > > 		struct usb_bus			*bus = udev->bus;
> > > > 
> > > > 		/* descriptor may appear anywhere in config */
> > > > 		if (__usb_get_extra_descriptor (udev->rawdescriptors[0],
> > > > 					le16_to_cpu(udev->config[0].desc.wTotalLength),
> > > > 					USB_DT_OTG, (void **) &desc) == 0) {
> > > > 			if (desc->bmAttributes & USB_OTG_HNP) {
> > > > 				unsigned		port1 = udev->portnum;
> > > > 
> > > > 				dev_info(&udev->dev,
> > > > 					"Dual-Role OTG device on %sHNP port\n",
> > > > 					(port1 == bus->otg_port)
> > > > 						? "" : "non-");
> > > > 
> > > > 				/* enable HNP before suspend, it's simpler */
> > > > 				if (port1 == bus->otg_port)
> > > > 					bus->b_hnp_enable = 1;
> > > > 				err = usb_control_msg(udev,
> > > > 					usb_sndctrlpipe(udev, 0),
> > > > 					USB_REQ_SET_FEATURE, 0,
> > > > 					bus->b_hnp_enable
> > > > 						? USB_DEVICE_B_HNP_ENABLE
> > > > 						: USB_DEVICE_A_ALT_HNP_SUPPORT,
> > > > 					0, NULL, 0, USB_CTRL_SET_TIMEOUT);
> > > > 
> > > > We're sending out this control request even if this host port is not OTG.
> > > > Isn't that wrong?
> > > 
> > > So send USB_DEVICE_A_ALT_HNP_SUPPORT request.
> > > This is correct in OTG 1.x, its intention is to remind the user who is
> > > connecting the HNP capable OTG device to a non-OTG port, He can change
> > > to another port of this machine which is a OTG port(with HNP).
> > 
> > I didn't understand.
> > If CONFIG_USB_OTG is enabled doesn't mean that this USB host port is OTG host.
> Yes, only CONFIG_USB_OTG enabled doesn't mean that this USB host port
> is a OTG port, there are might multiple usb host ports, but only one
> is a OTG port.

Not necessarily. Many systems don't have any OTG port so that request cannot
be sent even if CONFIG_USB_OTG is enabled.

> > So it should not send any OTG specific request to device. Right?
> Non-otg port(in OTG 1.x protocol) + OTG 1.x device, should send,
> otherwise, should not send.

What did you mean by Non-OTG port (in OTG 1.x protocol)?
If it is Non-OTG port it doesn't understand any OTG protocol.
So Non-OTG port should not send any OTG request.

> 
> So the code you pasted here was right only for OTG 1.x, I assume
> OTG 2.0 has not been released when it was designed. But now it's
> out of date, it's wrong if you connect a OTG 2.0 device. 
> 

The code is wrong for non-OTG ports when CONFIG_USB_OTG is set.

Peter/Felipe, any comments on this?

cheers,
-roger

> > 
> > > 
> > > > 
> > > > 				if (err < 0) {
> > > > 					/* OTG MESSAGE: report errors here,
> > > > 					 * customize to match your product.
> > > > 					 */
> > > > 					dev_info(&udev->dev,
> > > > 						"can't set HNP mode: %d\n",
> > > > 						err);
> > > > 					bus->b_hnp_enable = 0;
> > > > 				}
> > > > 
> > > > Instead it should be moved inside the if (port1 == bus->otg_port) condition.
> > > 
> > > Nope, as I explained above, this is really too detailed OTG protocol:)
> > > > 
> > > > 			}
> > > > 		}
> > > > 	}
> > > > #endif
> > > > 	return err;
> > > > }
> > > > 

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 05/22] doc: dt-binding: usb: add otg related properties

[Li Jun]

On Fri, Jun 12, 2015 at 11:02:13AM +0300, Roger Quadros wrote:
> 
> On Fri, 12 Jun 2015 09:42:04 +0800
> Li Jun <b47624-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> 
> > On Thu, Jun 11, 2015 at 05:55:57PM +0300, Roger Quadros wrote:
> > > > > drivers/usb/core/hub.c
> > > > > 
> > > > > static int usb_enumerate_device_otg(struct usb_device *udev)
> > > > > {
> > > > > 	int err = 0;
> > > > > 
> > > > > #ifdef	CONFIG_USB_OTG
> > > > > 	/*
> > > > > 	 * OTG-aware devices on OTG-capable root hubs may be able to use SRP,
> > > > > 	 * to wake us after we've powered off VBUS; and HNP, switching roles
> > > > > 	 * "host" to "peripheral".  The OTG descriptor helps figure this out.
> > > > > 	 */
> > > > > 	if (!udev->bus->is_b_host
> > > > > 			&& udev->config
> > > > > 			&& udev->parent == udev->bus->root_hub) {
> > > > > 		struct usb_otg_descriptor	*desc = NULL;
> > > > > 		struct usb_bus			*bus = udev->bus;
> > > > > 
> > > > > 		/* descriptor may appear anywhere in config */
> > > > > 		if (__usb_get_extra_descriptor (udev->rawdescriptors[0],
> > > > > 					le16_to_cpu(udev->config[0].desc.wTotalLength),
> > > > > 					USB_DT_OTG, (void **) &desc) == 0) {
> > > > > 			if (desc->bmAttributes & USB_OTG_HNP) {
> > > > > 				unsigned		port1 = udev->portnum;
> > > > > 
> > > > > 				dev_info(&udev->dev,
> > > > > 					"Dual-Role OTG device on %sHNP port\n",
> > > > > 					(port1 == bus->otg_port)
> > > > > 						? "" : "non-");
> > > > > 
> > > > > 				/* enable HNP before suspend, it's simpler */
> > > > > 				if (port1 == bus->otg_port)
> > > > > 					bus->b_hnp_enable = 1;
> > > > > 				err = usb_control_msg(udev,
> > > > > 					usb_sndctrlpipe(udev, 0),
> > > > > 					USB_REQ_SET_FEATURE, 0,
> > > > > 					bus->b_hnp_enable
> > > > > 						? USB_DEVICE_B_HNP_ENABLE
> > > > > 						: USB_DEVICE_A_ALT_HNP_SUPPORT,
> > > > > 					0, NULL, 0, USB_CTRL_SET_TIMEOUT);
> > > > > 
> > > > > We're sending out this control request even if this host port is not OTG.
> > > > > Isn't that wrong?
> > > > 
> > > > So send USB_DEVICE_A_ALT_HNP_SUPPORT request.
> > > > This is correct in OTG 1.x, its intention is to remind the user who is
> > > > connecting the HNP capable OTG device to a non-OTG port, He can change
> > > > to another port of this machine which is a OTG port(with HNP).
> > > 
> > > I didn't understand.
> > > If CONFIG_USB_OTG is enabled doesn't mean that this USB host port is OTG host.
> > Yes, only CONFIG_USB_OTG enabled doesn't mean that this USB host port
> > is a OTG port, there are might multiple usb host ports, but only one
> > is a OTG port.
> 
> Not necessarily. Many systems don't have any OTG port so that request cannot
> be sent even if CONFIG_USB_OTG is enabled.
> 
That's the fact, but we are talking the code only for those systems which
have OTG port. If you think we need not cover the support for OTG 1.x host,
we can simply remove it.

> > > So it should not send any OTG specific request to device. Right?
> > Non-otg port(in OTG 1.x protocol) + OTG 1.x device, should send,
> > otherwise, should not send.
> 
> What did you mean by Non-OTG port (in OTG 1.x protocol)?

Means host only port without HNP.

> If it is Non-OTG port it doesn't understand any OTG protocol.

With common sense, yes, but there is one exception.

> So Non-OTG port should not send any OTG request.
> 
see below from OTG 1.3:

6.5.3 a_alt_hnp_support
Setting this feature indicates to the B-device that it is connected to
an A-device port that is not capable of HNP, but that the A-device does
have an alternate port that is capable of HNP.
The A-device is required to set this feature under the following conditions:
• the A-device has multiple receptacles
• the A-device port that connects to the B-device does not support HNP
• the A-device has another port that does support HNP
... ...

> > 
> > So the code you pasted here was right only for OTG 1.x, I assume
> > OTG 2.0 has not been released when it was designed. But now it's
> > out of date, it's wrong if you connect a OTG 2.0 device. 
> > 
> 
> The code is wrong for non-OTG ports when CONFIG_USB_OTG is set.
> 
> Peter/Felipe, any comments on this?
> 
> cheers,
> -roger
> 
> > > 
> > > > 
> > > > > 
> > > > > 				if (err < 0) {
> > > > > 					/* OTG MESSAGE: report errors here,
> > > > > 					 * customize to match your product.
> > > > > 					 */
> > > > > 					dev_info(&udev->dev,
> > > > > 						"can't set HNP mode: %d\n",
> > > > > 						err);
> > > > > 					bus->b_hnp_enable = 0;
> > > > > 				}
> > > > > 
> > > > > Instead it should be moved inside the if (port1 == bus->otg_port) condition.
> > > > 
> > > > Nope, as I explained above, this is really too detailed OTG protocol:)
> > > > > 
> > > > > 			}
> > > > > 		}
> > > > > 	}
> > > > > #endif
> > > > > 	return err;
> > > > > }
> > > > > 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 05/22] doc: dt-binding: usb: add otg related properties

[Roger Quadros]

On Fri, 12 Jun 2015 16:23:59 +0800
Li Jun <b47624-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:

> On Fri, Jun 12, 2015 at 11:02:13AM +0300, Roger Quadros wrote:
> > 
> > On Fri, 12 Jun 2015 09:42:04 +0800
> > Li Jun <b47624-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> > 
> > > On Thu, Jun 11, 2015 at 05:55:57PM +0300, Roger Quadros wrote:
> > > > > > drivers/usb/core/hub.c
> > > > > > 
> > > > > > static int usb_enumerate_device_otg(struct usb_device *udev)
> > > > > > {
> > > > > > 	int err = 0;
> > > > > > 
> > > > > > #ifdef	CONFIG_USB_OTG
> > > > > > 	/*
> > > > > > 	 * OTG-aware devices on OTG-capable root hubs may be able to use SRP,
> > > > > > 	 * to wake us after we've powered off VBUS; and HNP, switching roles
> > > > > > 	 * "host" to "peripheral".  The OTG descriptor helps figure this out.
> > > > > > 	 */
> > > > > > 	if (!udev->bus->is_b_host
> > > > > > 			&& udev->config
> > > > > > 			&& udev->parent == udev->bus->root_hub) {
> > > > > > 		struct usb_otg_descriptor	*desc = NULL;
> > > > > > 		struct usb_bus			*bus = udev->bus;
> > > > > > 
> > > > > > 		/* descriptor may appear anywhere in config */
> > > > > > 		if (__usb_get_extra_descriptor (udev->rawdescriptors[0],
> > > > > > 					le16_to_cpu(udev->config[0].desc.wTotalLength),
> > > > > > 					USB_DT_OTG, (void **) &desc) == 0) {
> > > > > > 			if (desc->bmAttributes & USB_OTG_HNP) {
> > > > > > 				unsigned		port1 = udev->portnum;
> > > > > > 
> > > > > > 				dev_info(&udev->dev,
> > > > > > 					"Dual-Role OTG device on %sHNP port\n",
> > > > > > 					(port1 == bus->otg_port)
> > > > > > 						? "" : "non-");
> > > > > > 
> > > > > > 				/* enable HNP before suspend, it's simpler */
> > > > > > 				if (port1 == bus->otg_port)
> > > > > > 					bus->b_hnp_enable = 1;
> > > > > > 				err = usb_control_msg(udev,
> > > > > > 					usb_sndctrlpipe(udev, 0),
> > > > > > 					USB_REQ_SET_FEATURE, 0,
> > > > > > 					bus->b_hnp_enable
> > > > > > 						? USB_DEVICE_B_HNP_ENABLE
> > > > > > 						: USB_DEVICE_A_ALT_HNP_SUPPORT,
> > > > > > 					0, NULL, 0, USB_CTRL_SET_TIMEOUT);
> > > > > > 
> > > > > > We're sending out this control request even if this host port is not OTG.
> > > > > > Isn't that wrong?
> > > > > 
> > > > > So send USB_DEVICE_A_ALT_HNP_SUPPORT request.
> > > > > This is correct in OTG 1.x, its intention is to remind the user who is
> > > > > connecting the HNP capable OTG device to a non-OTG port, He can change
> > > > > to another port of this machine which is a OTG port(with HNP).
> > > > 
> > > > I didn't understand.
> > > > If CONFIG_USB_OTG is enabled doesn't mean that this USB host port is OTG host.
> > > Yes, only CONFIG_USB_OTG enabled doesn't mean that this USB host port
> > > is a OTG port, there are might multiple usb host ports, but only one
> > > is a OTG port.
> > 
> > Not necessarily. Many systems don't have any OTG port so that request cannot
> > be sent even if CONFIG_USB_OTG is enabled.
> > 
> That's the fact, but we are talking the code only for those systems which
> have OTG port. If you think we need not cover the support for OTG 1.x host,
> we can simply remove it.

We should not remove it but need to add the following check.

Send that request only if the system has at least one OTG (v1.x) port that is
capable of HNP _and_ this port is not that HNP capable port _and_
the connected device is OTG (v1.x)

> 
> > > > So it should not send any OTG specific request to device. Right?
> > > Non-otg port(in OTG 1.x protocol) + OTG 1.x device, should send,
> > > otherwise, should not send.
> > 
> > What did you mean by Non-OTG port (in OTG 1.x protocol)?
> 
> Means host only port without HNP.
> 
> > If it is Non-OTG port it doesn't understand any OTG protocol.
> 
> With common sense, yes, but there is one exception.
> 
> > So Non-OTG port should not send any OTG request.
> > 
> see below from OTG 1.3:
> 
> 6.5.3 a_alt_hnp_support
> Setting this feature indicates to the B-device that it is connected to
> an A-device port that is not capable of HNP, but that the A-device does
> have an alternate port that is capable of HNP.
> The A-device is required to set this feature under the following conditions:
> • the A-device has multiple receptacles
> • the A-device port that connects to the B-device does not support HNP
> • the A-device has another port that does support HNP
> ... ...

Thanks for this info. I can't seem to find the OTG v1.3 spec.

cheers,
-roger

> 
> > > 
> > > So the code you pasted here was right only for OTG 1.x, I assume
> > > OTG 2.0 has not been released when it was designed. But now it's
> > > out of date, it's wrong if you connect a OTG 2.0 device. 
> > > 
> > 
> > The code is wrong for non-OTG ports when CONFIG_USB_OTG is set.
> > 
> > Peter/Felipe, any comments on this?
> > 
> > cheers,
> > -roger
> > 
> > > > 
> > > > > 
> > > > > > 
> > > > > > 				if (err < 0) {
> > > > > > 					/* OTG MESSAGE: report errors here,
> > > > > > 					 * customize to match your product.
> > > > > > 					 */
> > > > > > 					dev_info(&udev->dev,
> > > > > > 						"can't set HNP mode: %d\n",
> > > > > > 						err);
> > > > > > 					bus->b_hnp_enable = 0;
> > > > > > 				}
> > > > > > 
> > > > > > Instead it should be moved inside the if (port1 == bus->otg_port) condition.
> > > > > 
> > > > > Nope, as I explained above, this is really too detailed OTG protocol:)
> > > > > > 
> > > > > > 			}
> > > > > > 		}
> > > > > > 	}
> > > > > > #endif
> > > > > > 	return err;
> > > > > > }
> > > > > > 
> > 

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 05/22] doc: dt-binding: usb: add otg related properties

[Li Jun]

On Fri, Jun 12, 2015 at 11:41:40AM +0300, Roger Quadros wrote:
> 
> 
> On Fri, 12 Jun 2015 16:23:59 +0800
> Li Jun <b47624-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> 
> > On Fri, Jun 12, 2015 at 11:02:13AM +0300, Roger Quadros wrote:
> > > 
> > > On Fri, 12 Jun 2015 09:42:04 +0800
> > > Li Jun <b47624-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> > > 
> > > > On Thu, Jun 11, 2015 at 05:55:57PM +0300, Roger Quadros wrote:
> > > > > > > drivers/usb/core/hub.c
> > > > > > > 
> > > > > > > static int usb_enumerate_device_otg(struct usb_device *udev)
> > > > > > > {
> > > > > > > 	int err = 0;
> > > > > > > 
> > > > > > > #ifdef	CONFIG_USB_OTG

> > > 
> > > Not necessarily. Many systems don't have any OTG port so that request cannot
> > > be sent even if CONFIG_USB_OTG is enabled.
> > > 
> > That's the fact, but we are talking the code only for those systems which
> > have OTG port. If you think we need not cover the support for OTG 1.x host,
> > we can simply remove it.
> 
> We should not remove it but need to add the following check.
> 
> Send that request only if the system has at least one OTG (v1.x) port that is
> capable of HNP _and_ this port is not that HNP capable port _and_
> the connected device is OTG (v1.x)
> 
Agreed.

> > 
> > > > > So it should not send any OTG specific request to device. Right?
> > > > Non-otg port(in OTG 1.x protocol) + OTG 1.x device, should send,
> > > > otherwise, should not send.
> > > 
> > > What did you mean by Non-OTG port (in OTG 1.x protocol)?
> > 
> > Means host only port without HNP.
> > 
> > > If it is Non-OTG port it doesn't understand any OTG protocol.
> > 
> > With common sense, yes, but there is one exception.
> > 
> > > So Non-OTG port should not send any OTG request.
> > > 
> > see below from OTG 1.3:
> > 
> > 6.5.3 a_alt_hnp_support
> > Setting this feature indicates to the B-device that it is connected to
> > an A-device port that is not capable of HNP, but that the A-device does
> > have an alternate port that is capable of HNP.
> > The A-device is required to set this feature under the following conditions:
> > • the A-device has multiple receptacles
> > • the A-device port that connects to the B-device does not support HNP
> > • the A-device has another port that does support HNP
> > ... ...
> 
> Thanks for this info. I can't seem to find the OTG v1.3 spec.
> 
You can download from:
http://www.usb.org/developers/docs/USB_OTG_1-3.pdf

> cheers,
> -roger
> 
> > 
> > > > 
> > > > So the code you pasted here was right only for OTG 1.x, I assume
> > > > OTG 2.0 has not been released when it was designed. But now it's
> > > > out of date, it's wrong if you connect a OTG 2.0 device. 
> > > > 
> > > 
> > > The code is wrong for non-OTG ports when CONFIG_USB_OTG is set.
> > > 
> > > Peter/Felipe, any comments on this?
> > > 
> > > cheers,
> > > -roger
> > > 
> > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > 				if (err < 0) {
> > > > > > > 					/* OTG MESSAGE: report errors here,
> > > > > > > 					 * customize to match your product.
> > > > > > > 					 */
> > > > > > > 					dev_info(&udev->dev,
> > > > > > > 						"can't set HNP mode: %d\n",
> > > > > > > 						err);
> > > > > > > 					bus->b_hnp_enable = 0;
> > > > > > > 				}
> > > > > > > 
> > > > > > > Instead it should be moved inside the if (port1 == bus->otg_port) condition.
> > > > > > 
> > > > > > Nope, as I explained above, this is really too detailed OTG protocol:)
> > > > > > > 
> > > > > > > 			}
> > > > > > > 		}
> > > > > > > 	}
> > > > > > > #endif
> > > > > > > 	return err;
> > > > > > > }
> > > > > > > 
> > > 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 05/22] doc: dt-binding: usb: add otg related properties

[Roger Quadros]

On Fri, 12 Jun 2015 16:23:59 +0800
Li Jun <b47624-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:

> On Fri, Jun 12, 2015 at 11:02:13AM +0300, Roger Quadros wrote:
> > 
> > On Fri, 12 Jun 2015 09:42:04 +0800
> > Li Jun <b47624-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> > 
> > > On Thu, Jun 11, 2015 at 05:55:57PM +0300, Roger Quadros wrote:
> > > > > > drivers/usb/core/hub.c
> > > > > > 
> > > > > > static int usb_enumerate_device_otg(struct usb_device *udev)
> > > > > > {
> > > > > > 	int err = 0;
> > > > > > 
> > > > > > #ifdef	CONFIG_USB_OTG
> > > > > > 	/*
> > > > > > 	 * OTG-aware devices on OTG-capable root hubs may be able to use SRP,
> > > > > > 	 * to wake us after we've powered off VBUS; and HNP, switching roles
> > > > > > 	 * "host" to "peripheral".  The OTG descriptor helps figure this out.
> > > > > > 	 */
> > > > > > 	if (!udev->bus->is_b_host
> > > > > > 			&& udev->config
> > > > > > 			&& udev->parent == udev->bus->root_hub) {
> > > > > > 		struct usb_otg_descriptor	*desc = NULL;
> > > > > > 		struct usb_bus			*bus = udev->bus;
> > > > > > 
> > > > > > 		/* descriptor may appear anywhere in config */
> > > > > > 		if (__usb_get_extra_descriptor (udev->rawdescriptors[0],
> > > > > > 					le16_to_cpu(udev->config[0].desc.wTotalLength),
> > > > > > 					USB_DT_OTG, (void **) &desc) == 0) {
> > > > > > 			if (desc->bmAttributes & USB_OTG_HNP) {
> > > > > > 				unsigned		port1 = udev->portnum;
> > > > > > 
> > > > > > 				dev_info(&udev->dev,
> > > > > > 					"Dual-Role OTG device on %sHNP port\n",
> > > > > > 					(port1 == bus->otg_port)
> > > > > > 						? "" : "non-");
> > > > > > 
> > > > > > 				/* enable HNP before suspend, it's simpler */
> > > > > > 				if (port1 == bus->otg_port)
> > > > > > 					bus->b_hnp_enable = 1;
> > > > > > 				err = usb_control_msg(udev,
> > > > > > 					usb_sndctrlpipe(udev, 0),
> > > > > > 					USB_REQ_SET_FEATURE, 0,
> > > > > > 					bus->b_hnp_enable
> > > > > > 						? USB_DEVICE_B_HNP_ENABLE
> > > > > > 						: USB_DEVICE_A_ALT_HNP_SUPPORT,
> > > > > > 					0, NULL, 0, USB_CTRL_SET_TIMEOUT);
> > > > > > 
> > > > > > We're sending out this control request even if this host port is not OTG.
> > > > > > Isn't that wrong?
> > > > > 
> > > > > So send USB_DEVICE_A_ALT_HNP_SUPPORT request.
> > > > > This is correct in OTG 1.x, its intention is to remind the user who is
> > > > > connecting the HNP capable OTG device to a non-OTG port, He can change
> > > > > to another port of this machine which is a OTG port(with HNP).
> > > > 
> > > > I didn't understand.
> > > > If CONFIG_USB_OTG is enabled doesn't mean that this USB host port is OTG host.
> > > Yes, only CONFIG_USB_OTG enabled doesn't mean that this USB host port
> > > is a OTG port, there are might multiple usb host ports, but only one
> > > is a OTG port.
> > 
> > Not necessarily. Many systems don't have any OTG port so that request cannot
> > be sent even if CONFIG_USB_OTG is enabled.
> > 
> That's the fact, but we are talking the code only for those systems which
> have OTG port. If you think we need not cover the support for OTG 1.x host,
> we can simply remove it.
> 
> > > > So it should not send any OTG specific request to device. Right?
> > > Non-otg port(in OTG 1.x protocol) + OTG 1.x device, should send,
> > > otherwise, should not send.
> > 
> > What did you mean by Non-OTG port (in OTG 1.x protocol)?
> 
> Means host only port without HNP.
> 
> > If it is Non-OTG port it doesn't understand any OTG protocol.
> 
> With common sense, yes, but there is one exception.
> 
> > So Non-OTG port should not send any OTG request.
> > 
> see below from OTG 1.3:
> 
> 6.5.3 a_alt_hnp_support
> Setting this feature indicates to the B-device that it is connected to
> an A-device port that is not capable of HNP, but that the A-device does
> have an alternate port that is capable of HNP.
> The A-device is required to set this feature under the following conditions:
> • the A-device has multiple receptacles
> • the A-device port that connects to the B-device does not support HNP
> • the A-device has another port that does support HNP
> ... ...
> 
> > > 
> > > So the code you pasted here was right only for OTG 1.x, I assume
> > > OTG 2.0 has not been released when it was designed. But now it's
> > > out of date, it's wrong if you connect a OTG 2.0 device. 
> > > 
> > 
> > The code is wrong for non-OTG ports when CONFIG_USB_OTG is set.
> > 
> > Peter/Felipe, any comments on this?
> > 
> > cheers,
> > -roger
> > 
> > > > 
> > > > > 
> > > > > > 
> > > > > > 				if (err < 0) {
> > > > > > 					/* OTG MESSAGE: report errors here,
> > > > > > 					 * customize to match your product.
> > > > > > 					 */
> > > > > > 					dev_info(&udev->dev,
> > > > > > 						"can't set HNP mode: %d\n",
> > > > > > 						err);
> > > > > > 					bus->b_hnp_enable = 0;
> > > > > > 				}
> > > > > > 
> > > > > > Instead it should be moved inside the if (port1 == bus->otg_port) condition.
> > > > > 
> > > > > Nope, as I explained above, this is really too detailed OTG protocol:)
> > > > > > 
> > > > > > 			}
> > > > > > 		}
> > > > > > 	}
> > > > > > #endif
> > > > > > 	return err;
> > > > > > }
> > > > > > 
> > 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 05/22] doc: dt-binding: usb: add otg related properties

[Peter Chen]

On Tue, Jun 09, 2015 at 06:29:31PM +0300, Roger Quadros wrote:
> Rob,
> 
> On Tue, 9 Jun 2015 08:26:20 -0500
> Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> 
> > On Mon, Jun 8, 2015 at 8:18 PM, Li Jun <b47624-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> > > On Mon, Jun 08, 2015 at 11:06:49AM -0500, Rob Herring wrote:
> > >> On Mon, Jun 8, 2015 at 10:02 AM, Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> > >> > Add otg version, srp, hnp and adp support for usb OTG port, then those OTG
> > >> > features don't have to be decided by usb gadget drivers.
> > >> >
> > >> > Signed-off-by: Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> > >> > ---
> > >> >  Documentation/devicetree/bindings/usb/generic.txt | 10 ++++++++++
> > >> >  1 file changed, 10 insertions(+)
> > >> >
> > >> > diff --git a/Documentation/devicetree/bindings/usb/generic.txt b/Documentation/devicetree/bindings/usb/generic.txt
> > >> > index 477d5bb..7386f4a 100644
> > >> > --- a/Documentation/devicetree/bindings/usb/generic.txt
> > >> > +++ b/Documentation/devicetree/bindings/usb/generic.txt
> > >> > @@ -11,6 +11,12 @@ Optional properties:
> > >> >                         "peripheral" and "otg". In case this attribute isn't
> > >> >                         passed via DT, USB DRD controllers should default to
> > >> >                         OTG.
> > >> > + - otg-rev: tells usb driver the release number of the OTG and EH supplement
> > >> > +                       with which the device and its descriptors are compliant,
> > >> > +                       in binary-coded decimal (i.e. 2.0 is 0200H).
> > >>
> > >> I would assume OTG 2.0 is somehow backwards compatible? Is this a h/w
> > >> dependency or a driver feature?
> > >>
> > > Not fully compatible, OTG 2.0 extend the usb_otg_descriptor by adding a new
> > > member bcdOTG to identify the OTG version, this descriptor needs to be sent
> > > to OTG host with correct size and content, so we have to know which release
> > > version the OTG device is compliant with, either by menuconfig config or pass
> > > via DT.
> > 
> > So you have to change the version depending on the host you are
> > connected to? That really seems strange that plugging in a OTG 2.0
> > device to an OTG 1.3 host would not work and doesn't make for a good
> > user experience.
> 
> No. The OTG version in the OTG descriptor for any device is usually fixed for the
> lifetime of the product.
> 
> Let's assume it is 2.0.
> 
> If you plug this to OTG 1.0 host, it won't be an issue as OTG 1.0 host doesn't
> read the BCD version.
> 
> > 
> > >> > + - srp-support: tells OTG controllers we want to enable SRP.
> > >> > + - hnp-support: tells OTG controllers we want to enable HNP.
> > >> > + - adp-support: tells OTG controllers we want to enable ADP.
> > >>
> > >> I've recently run into a problem[1] and found that I have to disable
> > >> OTG in the kernel to get my device to work. Having to turn-off OTG
> > >> seems like the wrong solution, and shifting the problem to DT seems
> > >> wrong too. Why is this not a user configurable option (within whatever
> > >> h/w constraints there are)?
> > > The problem of below link, seems your device is claiming it's a HNP capable
> > > OTG device, but connecting to a non-OTG port of your Host, assume your Host
> > > does have a OTG port, your Host issue a A_ALT_HNP_SUPPORT request to your
> > > OTG device to remind it can use another port with HNP, but the request failed
> > > (maybe STALL by your device, this request is defined in OTG 1.3 but obsolete
> > > in OTG 2.0), so your Host just stopped enumeration of your device, this is not
> > > reasonable because current OTG code is some out of data.
> > 
> > Do PCs have OTG ports typically? My expectation is that if I plug in
> > an OTG device as a B device to any host port, that it will work as a
> > device no matter what the host OTG capabilities are. If I have to
> > change the kernel config or DT, that is a problem.
> 
> AFAIK PCs don't have OTG ports.
> 
> If you plug in OTG device to a non-otg host port it will work as normal B-device.
> The host doesn't request for OTG descriptors and doesn't care what OTG features it
> supports or not.
> 
> > 
> > > I am trying to make those OTG feaures to be configurable options, you mean
> > > by sys?
> > 
> > Yes.
> 
> why do you need OTG features to be sysfs configurable other than for debugging?
> 
> > 
> > >> What are the valid combinations? When do we want these enabled or not?
> > >> Wouldn't default enabled be better?
> > >
> > > We want to enable all those support in kernel driver, but some platform or
> > > hardware may not want to enable any or some of them, so those hardware
> > > can disable it by not pass the property in dt, the 3 sub features of OTG are
> > > not mandatory for so called OTG device, normally we at least enable HNP, and
> > > SRP and ADP are optional.
> > 
> > Please answer my questions in the doc.
> > 
> > >>
> > >> We already have dr_mode property. How is it related to these?
> 
> dr_mode states what mode the controller will operate in.
> 
> for dr_mode == "host" we don't care about these otg flags.
> 
> for dr_mode == "peripheral" or dr_mode == "otg"
> we care about these OTG flags to create our OTG descriptor on the fly.
> 

If dr_mode = "peripheral", we should not create OTG descriptor,
otherwise, the otg device at other side may consider it is an
"otg" device.

Peter
> > >
> > > dr_mode is to tell the device it will work at OTG mode(there is another simple
> > > dual role mode which is commom used but not HNP), srp/hnp/adp can further specify
> > > which protocol the OTG device will support.
> > 
> > By simple DR, you mean ID pin detect, right. So please define how you
> > support just ID pin detect vs. other levels of capability. Does only
> > dr_mode = otg mean ID pin detect? That may be a problem for existing
> > DTs if you disable other OTG functions because they have not been
> > added to the DT, then that is a problem.
> > 
> > I'm feeling less convinced that this belongs in DT at all. Please
> > convince me otherwise.
> 
> Yes not specifying anything in DT should work and default to the
> best OTG version and features supported by the OTG controller.
> 
> But if the device manufacturer wants to restrict the OTG version
> to something less or disable some OTG features then the DT flags come
> into play.
> 
> cheers,
> -roger

-- 

Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 05/22] doc: dt-binding: usb: add otg related properties

[Li Jun]

On Tue, Jun 09, 2015 at 09:26:20PM +0800, Rob Herring wrote:
> On Mon, Jun 8, 2015 at 8:18 PM, Li Jun <b47624-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> > On Mon, Jun 08, 2015 at 11:06:49AM -0500, Rob Herring wrote:
> >> On Mon, Jun 8, 2015 at 10:02 AM, Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> >> > Add otg version, srp, hnp and adp support for usb OTG port, then those OTG
> >> > features don't have to be decided by usb gadget drivers.
> >> >
> >> > Signed-off-by: Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> >> > ---
> >> >  Documentation/devicetree/bindings/usb/generic.txt | 10 ++++++++++
> >> >  1 file changed, 10 insertions(+)
> >> >
> >> > diff --git a/Documentation/devicetree/bindings/usb/generic.txt b/Documentation/devicetree/bindings/usb/generic.txt
> >> > index 477d5bb..7386f4a 100644
> >> > --- a/Documentation/devicetree/bindings/usb/generic.txt
> >> > +++ b/Documentation/devicetree/bindings/usb/generic.txt
> >> > @@ -11,6 +11,12 @@ Optional properties:
> >> >                         "peripheral" and "otg". In case this attribute isn't
> >> >                         passed via DT, USB DRD controllers should default to
> >> >                         OTG.
> >> > + - otg-rev: tells usb driver the release number of the OTG and EH supplement
> >> > +                       with which the device and its descriptors are compliant,
> >> > +                       in binary-coded decimal (i.e. 2.0 is 0200H).
> >>
> >> I would assume OTG 2.0 is somehow backwards compatible? Is this a h/w
> >> dependency or a driver feature?
> >>
> > Not fully compatible, OTG 2.0 extend the usb_otg_descriptor by adding a new
> > member bcdOTG to identify the OTG version, this descriptor needs to be sent
> > to OTG host with correct size and content, so we have to know which release
> > version the OTG device is compliant with, either by menuconfig config or pass
> > via DT.
> 
> So you have to change the version depending on the host you are
> connected to? That really seems strange that plugging in a OTG 2.0
> device to an OTG 1.3 host would not work and doesn't make for a good
> user experience.
> 
Depending on the OTG device itself with which release version it's compliant
, then OTG 2.0 host can differentiate them and talk to it with right version
protocol.
Maybe most of OTG 2.0 devices design does not consider to be compatible
with OTG 1.3 host, chipidea udc driver has fixed this issue with below patch:
http://www.spinics.net/lists/stable-commits/msg43003.html

> >> > + - srp-support: tells OTG controllers we want to enable SRP.
> >> > + - hnp-support: tells OTG controllers we want to enable HNP.
> >> > + - adp-support: tells OTG controllers we want to enable ADP.
> >>
> >> I've recently run into a problem[1] and found that I have to disable
> >> OTG in the kernel to get my device to work. Having to turn-off OTG
> >> seems like the wrong solution, and shifting the problem to DT seems
> >> wrong too. Why is this not a user configurable option (within whatever
> >> h/w constraints there are)?
> > The problem of below link, seems your device is claiming it's a HNP capable
> > OTG device, but connecting to a non-OTG port of your Host, assume your Host
> > does have a OTG port, your Host issue a A_ALT_HNP_SUPPORT request to your
> > OTG device to remind it can use another port with HNP, but the request failed
> > (maybe STALL by your device, this request is defined in OTG 1.3 but obsolete
> > in OTG 2.0), so your Host just stopped enumeration of your device, this is not
> > reasonable because current OTG code is some out of data.
> 
> Do PCs have OTG ports typically? My expectation is that if I plug in
> an OTG device as a B device to any host port, that it will work as a
> device no matter what the host OTG capabilities are. If I have to
> change the kernel config or DT, that is a problem.

Unfortunately current host code for OTG is some out of data and has not been
updated for OTG 2.0, so cannot work well with OTG 2.0 device, but this can be
another OTG topic. For now if your PC has no OTG port, you have to disable
CONFIG_USB_OTG, otherwise it will assume you have a OTG port on your machine.

> 
> > I am trying to make those OTG feaures to be configurable options, you mean
> > by sys?
> 
> Yes.
> 
This kind of feature may not be able to enable/disable at runtime.
E.g. ADP and SRP need OTG devices do pre-defined sequence when power up.

> >> What are the valid combinations? When do we want these enabled or not?
> >> Wouldn't default enabled be better?
> >
> > We want to enable all those support in kernel driver, but some platform or
> > hardware may not want to enable any or some of them, so those hardware
> > can disable it by not pass the property in dt, the 3 sub features of OTG are
> > not mandatory for so called OTG device, normally we at least enable HNP, and
> > SRP and ADP are optional.
> 
> Please answer my questions in the doc.
> 
> >>
> >> We already have dr_mode property. How is it related to these?
> >
> > dr_mode is to tell the device it will work at OTG mode(there is another simple
> > dual role mode which is commom used but not HNP), srp/hnp/adp can further specify
> > which protocol the OTG device will support.
> 
> By simple DR, you mean ID pin detect, right. So please define how you
> support just ID pin detect vs. other levels of capability. Does only
> dr_mode = otg mean ID pin detect? That may be a problem for existing
> DTs if you disable other OTG functions because they have not been
> added to the DT, then that is a problem.
I do not disable any OTG functions if those new properties has not been
added to DTs, they will work as before without any change. If some platform
has some real OTG features and want to utilize those properties, can set the
existing otg flag(e.g. gadget->is_otg, which is only needed for real OTG) by
srp/hnp/adp property, not just hard coded in its controller driver, then it
can use dr_mode = otg for ID pin detect, and above new properties for other
levels.

> 
> I'm feeling less convinced that this belongs in DT at all. Please
> convince me otherwise.
> 
> Rob

Li Jun
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 05/22] doc: dt-binding: usb: add otg related properties

[Roger Quadros]

On Mon, 8 Jun 2015 23:02:00 +0800
Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:

> Add otg version, srp, hnp and adp support for usb OTG port, then those OTG
> features don't have to be decided by usb gadget drivers.
> 
> Signed-off-by: Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> ---
>  Documentation/devicetree/bindings/usb/generic.txt | 10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/usb/generic.txt b/Documentation/devicetree/bindings/usb/generic.txt
> index 477d5bb..7386f4a 100644
> --- a/Documentation/devicetree/bindings/usb/generic.txt
> +++ b/Documentation/devicetree/bindings/usb/generic.txt
> @@ -11,6 +11,12 @@ Optional properties:
>  			"peripheral" and "otg". In case this attribute isn't
>  			passed via DT, USB DRD controllers should default to
>  			OTG.
> + - otg-rev: tells usb driver the release number of the OTG and EH supplement
> +			with which the device and its descriptors are compliant,
> +			in binary-coded decimal (i.e. 2.0 is 0200H).
> + - srp-support: tells OTG controllers we want to enable SRP.
> + - hnp-support: tells OTG controllers we want to enable HNP.
> + - adp-support: tells OTG controllers we want to enable ADP.

should we call these enable-<foo> as it doesn't indicate whether controller supports it or not
but just that the board DT wants to enable it.

>  
>  This is an attribute to a USB controller such as:
>  
> @@ -21,4 +27,8 @@ dwc3@4a030000 {
>  	usb-phy = <&usb2_phy>, <&usb3,phy>;
>  	maximum-speed = "super-speed";
>  	dr_mode = "otg";
> +	otg-rev = <0x0200>;
> +	srp-support;
> +	hnp-support;
> +	adp-support;
>  };

cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 06/22] usb: common: add API to get usb otg features from device tree

[Li Jun]

Check property of usb hardware to get otg version and if SRP, HNP and ADP
are supported.

Signed-off-by: Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
---
 drivers/usb/common/common.c | 64 +++++++++++++++++++++++++++++++++++++++++++++
 include/linux/usb/of.h      | 20 ++++++++++++++
 2 files changed, 84 insertions(+)

diff --git a/drivers/usb/common/common.c b/drivers/usb/common/common.c
index b530fd4..7b0594b 100644
--- a/drivers/usb/common/common.c
+++ b/drivers/usb/common/common.c
@@ -154,6 +154,70 @@ bool of_usb_host_tpl_support(struct device_node *np)
 	return false;
 }
 EXPORT_SYMBOL_GPL(of_usb_host_tpl_support);
+
+/**
+ * of_usb_otg_srp_support -  to get if otg srp is supported by the otg controller
+ * @np: Pointer to the given device_node
+ *
+ * The function gets if the otg port supports SRP
+ */
+bool of_usb_otg_srp_support(struct device_node *np)
+{
+	if (of_find_property(np, "srp-support", NULL))
+		return true;
+
+	return false;
+}
+EXPORT_SYMBOL_GPL(of_usb_otg_srp_support);
+
+/**
+ * of_usb_otg_hnp_support -  to get if otg hnp is supported by the otg controller
+ * @np: Pointer to the given device_node
+ *
+ * The function gets if the otg port supports HNP
+ */
+bool of_usb_otg_hnp_support(struct device_node *np)
+{
+	if (of_find_property(np, "hnp-support", NULL))
+		return true;
+
+	return false;
+}
+EXPORT_SYMBOL_GPL(of_usb_otg_hnp_support);
+
+/**
+ * of_usb_otg_adp_support -  to get if otg adp is supported by the otg controller
+ * @np: Pointer to the given device_node
+ *
+ * The function gets if the otg port supports ADP
+ */
+bool of_usb_otg_adp_support(struct device_node *np)
+{
+	if (of_find_property(np, "adp-support", NULL))
+		return true;
+
+	return false;
+}
+EXPORT_SYMBOL_GPL(of_usb_otg_adp_support);
+
+/**
+ * of_usb_otg_rev_number -  to get the otg release number the device is
+ * compliant with.
+ * @np: Pointer to the given device_node
+ *
+ * The function gets OTG and EH supplement release number in binary-coded
+ * decimal (i.e. 2.0 is 0200H).
+ */
+int of_usb_otg_rev_number(struct device_node *np)
+{
+	u32 otg_rev;
+
+	if (!of_property_read_u32(np, "otg-rev", &otg_rev))
+		return otg_rev;
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(of_usb_otg_rev_number);
 #endif
 
 MODULE_LICENSE("GPL");
diff --git a/include/linux/usb/of.h b/include/linux/usb/of.h
index cfe0528..9a3e82a 100644
--- a/include/linux/usb/of.h
+++ b/include/linux/usb/of.h
@@ -15,6 +15,10 @@
 enum usb_dr_mode of_usb_get_dr_mode(struct device_node *np);
 enum usb_device_speed of_usb_get_maximum_speed(struct device_node *np);
 bool of_usb_host_tpl_support(struct device_node *np);
+bool of_usb_otg_srp_support(struct device_node *np);
+bool of_usb_otg_hnp_support(struct device_node *np);
+bool of_usb_otg_adp_support(struct device_node *np);
+int of_usb_otg_rev_number(struct device_node *np);
 #else
 static inline enum usb_dr_mode of_usb_get_dr_mode(struct device_node *np)
 {
@@ -30,6 +34,22 @@ static inline bool of_usb_host_tpl_support(struct device_node *np)
 {
 	return false;
 }
+static inline bool of_usb_otg_srp_support(struct device_node *np)
+{
+	return false;
+}
+static inline bool of_usb_otg_hnp_support(struct device_node *np)
+{
+	return false;
+}
+static inline bool of_usb_otg_adp_support(struct device_node *np)
+{
+	return false;
+}
+static inline int of_usb_otg_rev_number(struct device_node *np)
+{
+	return 0;
+}
 #endif
 
 #if IS_ENABLED(CONFIG_OF) && IS_ENABLED(CONFIG_USB_SUPPORT)
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 06/22] usb: common: add API to get usb otg features from device tree

[Roger Quadros]

Hi,

On Mon, 8 Jun 2015 23:02:01 +0800
Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:

> Check property of usb hardware to get otg version and if SRP, HNP and ADP
> are supported.
> 
> Signed-off-by: Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> ---
>  drivers/usb/common/common.c | 64 +++++++++++++++++++++++++++++++++++++++++++++
>  include/linux/usb/of.h      | 20 ++++++++++++++
>  2 files changed, 84 insertions(+)
> 
> diff --git a/drivers/usb/common/common.c b/drivers/usb/common/common.c
> index b530fd4..7b0594b 100644
> --- a/drivers/usb/common/common.c
> +++ b/drivers/usb/common/common.c
> @@ -154,6 +154,70 @@ bool of_usb_host_tpl_support(struct device_node *np)
>  	return false;
>  }
>  EXPORT_SYMBOL_GPL(of_usb_host_tpl_support);
> +
> +/**
> + * of_usb_otg_srp_support -  to get if otg srp is supported by the otg controller

This is not really about otg controller supporting SRP but whether
the DT user wants it enabled or not.

IMO this function should be named of_usb_get_otg_srp_enable()

> + * @np: Pointer to the given device_node
> + *
> + * The function gets if the otg port supports SRP
> + */
> +bool of_usb_otg_srp_support(struct device_node *np)
> +{
> +	if (of_find_property(np, "srp-support", NULL))
> +		return true;
> +
> +	return false;
> +}
> +EXPORT_SYMBOL_GPL(of_usb_otg_srp_support);
> +
> +/**
> + * of_usb_otg_hnp_support -  to get if otg hnp is supported by the otg controller
> + * @np: Pointer to the given device_node
> + *
> + * The function gets if the otg port supports HNP
> + */
> +bool of_usb_otg_hnp_support(struct device_node *np)
> +{
> +	if (of_find_property(np, "hnp-support", NULL))
> +		return true;
> +
> +	return false;
> +}
> +EXPORT_SYMBOL_GPL(of_usb_otg_hnp_support);
> +
> +/**
> + * of_usb_otg_adp_support -  to get if otg adp is supported by the otg controller
> + * @np: Pointer to the given device_node
> + *
> + * The function gets if the otg port supports ADP
> + */
> +bool of_usb_otg_adp_support(struct device_node *np)
> +{
> +	if (of_find_property(np, "adp-support", NULL))
> +		return true;
> +
> +	return false;
> +}
> +EXPORT_SYMBOL_GPL(of_usb_otg_adp_support);
> +
> +/**
> + * of_usb_otg_rev_number -  to get the otg release number the device is
> + * compliant with.
> + * @np: Pointer to the given device_node
> + *
> + * The function gets OTG and EH supplement release number in binary-coded
> + * decimal (i.e. 2.0 is 0200H).
> + */
> +int of_usb_otg_rev_number(struct device_node *np)

how about of_usb_get_otg_rev()?

> +{
> +	u32 otg_rev;
> +
> +	if (!of_property_read_u32(np, "otg-rev", &otg_rev))
> +		return otg_rev;
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(of_usb_otg_rev_number);
>  #endif
>  

cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 06/22] usb: common: add API to get usb otg features from device tree

[Li Jun]

On Tue, Jun 09, 2015 at 03:55:29PM +0300, Roger Quadros wrote:
> Hi,
> 
> On Mon, 8 Jun 2015 23:02:01 +0800
> Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> 
> > Check property of usb hardware to get otg version and if SRP, HNP and ADP
> > are supported.
> > 
> > Signed-off-by: Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> > ---
> >  drivers/usb/common/common.c | 64 +++++++++++++++++++++++++++++++++++++++++++++
> >  include/linux/usb/of.h      | 20 ++++++++++++++
> >  2 files changed, 84 insertions(+)
> > 
> > diff --git a/drivers/usb/common/common.c b/drivers/usb/common/common.c
> > index b530fd4..7b0594b 100644
> > --- a/drivers/usb/common/common.c
> > +++ b/drivers/usb/common/common.c
> > @@ -154,6 +154,70 @@ bool of_usb_host_tpl_support(struct device_node *np)
> >  	return false;
> >  }
> >  EXPORT_SYMBOL_GPL(of_usb_host_tpl_support);
> > +
> > +/**
> > + * of_usb_otg_srp_support -  to get if otg srp is supported by the otg controller
> 
> This is not really about otg controller supporting SRP but whether
> the DT user wants it enabled or not.
> 
Yes.

> IMO this function should be named of_usb_get_otg_srp_enable()
> 
Sounds better, I will update.

> > + * @np: Pointer to the given device_node
> > + *
> > + * The function gets if the otg port supports SRP
> > + */
> > +bool of_usb_otg_srp_support(struct device_node *np)
> > +{
> > +	if (of_find_property(np, "srp-support", NULL))
> > +		return true;
> > +
> > +	return false;
> > +}
> > +EXPORT_SYMBOL_GPL(of_usb_otg_srp_support);
> > +
> > +/**
> > + * of_usb_otg_hnp_support -  to get if otg hnp is supported by the otg controller
> > + * @np: Pointer to the given device_node
> > + *
> > + * The function gets if the otg port supports HNP
> > + */
> > +bool of_usb_otg_hnp_support(struct device_node *np)
> > +{
> > +	if (of_find_property(np, "hnp-support", NULL))
> > +		return true;
> > +
> > +	return false;
> > +}
> > +EXPORT_SYMBOL_GPL(of_usb_otg_hnp_support);
> > +
> > +/**
> > + * of_usb_otg_adp_support -  to get if otg adp is supported by the otg controller
> > + * @np: Pointer to the given device_node
> > + *
> > + * The function gets if the otg port supports ADP
> > + */
> > +bool of_usb_otg_adp_support(struct device_node *np)
> > +{
> > +	if (of_find_property(np, "adp-support", NULL))
> > +		return true;
> > +
> > +	return false;
> > +}
> > +EXPORT_SYMBOL_GPL(of_usb_otg_adp_support);
> > +
> > +/**
> > + * of_usb_otg_rev_number -  to get the otg release number the device is
> > + * compliant with.
> > + * @np: Pointer to the given device_node
> > + *
> > + * The function gets OTG and EH supplement release number in binary-coded
> > + * decimal (i.e. 2.0 is 0200H).
> > + */
> > +int of_usb_otg_rev_number(struct device_node *np)
> 
> how about of_usb_get_otg_rev()?
> 
okay, I will update.

> > +{
> > +	u32 otg_rev;
> > +
> > +	if (!of_property_read_u32(np, "otg-rev", &otg_rev))
> > +		return otg_rev;
> > +
> > +	return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(of_usb_otg_rev_number);
> >  #endif
> >  
> 
> cheers,
> -roger
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 06/22] usb: common: add API to get usb otg features from device tree

[Li Jun]

On Tue, Jun 09, 2015 at 03:55:29PM +0300, Roger Quadros wrote:
> Hi,
> 
> On Mon, 8 Jun 2015 23:02:01 +0800
> Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> 
> > Check property of usb hardware to get otg version and if SRP, HNP and ADP
> > are supported.
> > 
> > Signed-off-by: Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> > ---
> >  drivers/usb/common/common.c | 64 +++++++++++++++++++++++++++++++++++++++++++++
> >  include/linux/usb/of.h      | 20 ++++++++++++++
> >  2 files changed, 84 insertions(+)
> > 
> > diff --git a/drivers/usb/common/common.c b/drivers/usb/common/common.c
> > index b530fd4..7b0594b 100644
> > --- a/drivers/usb/common/common.c
> > +++ b/drivers/usb/common/common.c
> > @@ -154,6 +154,70 @@ bool of_usb_host_tpl_support(struct device_node *np)
> >  	return false;
> >  }
> >  EXPORT_SYMBOL_GPL(of_usb_host_tpl_support);
> > +
> > +/**
> > + * of_usb_otg_srp_support -  to get if otg srp is supported by the otg controller
> 
> This is not really about otg controller supporting SRP but whether
> the DT user wants it enabled or not.
> 
Sorry, correct my precious answer, this is about if otg controller can support
SRP. Meanwhile DT user can disable it via this property even the HW has this
capability.

Li Jun
> IMO this function should be named of_usb_get_otg_srp_enable()
> 
> > + * @np: Pointer to the given device_node
> > + *
> > + * The function gets if the otg port supports SRP
> > + */
> > +bool of_usb_otg_srp_support(struct device_node *np)
> > +{
> > +	if (of_find_property(np, "srp-support", NULL))
> > +		return true;
> > +
> > +	return false;
> > +}
> > +EXPORT_SYMBOL_GPL(of_usb_otg_srp_support);
> > +
> > +/**
> > + * of_usb_otg_hnp_support -  to get if otg hnp is supported by the otg controller
> > + * @np: Pointer to the given device_node
> > + *
> > + * The function gets if the otg port supports HNP
> > + */
> > +bool of_usb_otg_hnp_support(struct device_node *np)
> > +{
> > +	if (of_find_property(np, "hnp-support", NULL))
> > +		return true;
> > +
> > +	return false;
> > +}
> > +EXPORT_SYMBOL_GPL(of_usb_otg_hnp_support);
> > +
> > +/**
> > + * of_usb_otg_adp_support -  to get if otg adp is supported by the otg controller
> > + * @np: Pointer to the given device_node
> > + *
> > + * The function gets if the otg port supports ADP
> > + */
> > +bool of_usb_otg_adp_support(struct device_node *np)
> > +{
> > +	if (of_find_property(np, "adp-support", NULL))
> > +		return true;
> > +
> > +	return false;
> > +}
> > +EXPORT_SYMBOL_GPL(of_usb_otg_adp_support);
> > +
> > +/**
> > + * of_usb_otg_rev_number -  to get the otg release number the device is
> > + * compliant with.
> > + * @np: Pointer to the given device_node
> > + *
> > + * The function gets OTG and EH supplement release number in binary-coded
> > + * decimal (i.e. 2.0 is 0200H).
> > + */
> > +int of_usb_otg_rev_number(struct device_node *np)
> 
> how about of_usb_get_otg_rev()?
> 
> > +{
> > +	u32 otg_rev;
> > +
> > +	if (!of_property_read_u32(np, "otg-rev", &otg_rev))
> > +		return otg_rev;
> > +
> > +	return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(of_usb_otg_rev_number);
> >  #endif
> >  
> 
> cheers,
> -roger
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 06/22] usb: common: add API to get usb otg features from device tree

[Roger Quadros]

On Tue, 9 Jun 2015 22:15:53 +0800
Li Jun <b47624-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:

> On Tue, Jun 09, 2015 at 03:55:29PM +0300, Roger Quadros wrote:
> > Hi,
> > 
> > On Mon, 8 Jun 2015 23:02:01 +0800
> > Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> > 
> > > Check property of usb hardware to get otg version and if SRP, HNP and ADP
> > > are supported.
> > > 
> > > Signed-off-by: Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> > > ---
> > >  drivers/usb/common/common.c | 64 +++++++++++++++++++++++++++++++++++++++++++++
> > >  include/linux/usb/of.h      | 20 ++++++++++++++
> > >  2 files changed, 84 insertions(+)
> > > 
> > > diff --git a/drivers/usb/common/common.c b/drivers/usb/common/common.c
> > > index b530fd4..7b0594b 100644
> > > --- a/drivers/usb/common/common.c
> > > +++ b/drivers/usb/common/common.c
> > > @@ -154,6 +154,70 @@ bool of_usb_host_tpl_support(struct device_node *np)
> > >  	return false;
> > >  }
> > >  EXPORT_SYMBOL_GPL(of_usb_host_tpl_support);
> > > +
> > > +/**
> > > + * of_usb_otg_srp_support -  to get if otg srp is supported by the otg controller
> > 
> > This is not really about otg controller supporting SRP but whether
> > the DT user wants it enabled or not.
> > 
> Sorry, correct my precious answer, this is about if otg controller can support
> SRP. Meanwhile DT user can disable it via this property even the HW has this
> capability.

Whether controller supports any capability shouldn't come from DT but from its
hardware capability registers.

If you want to disable any feature from DT the DT property will have to be called
disable-<foo> rather than <foo>-support.

cheers,
-roger

> 
> Li Jun
> > IMO this function should be named of_usb_get_otg_srp_enable()
> > 
> > > + * @np: Pointer to the given device_node
> > > + *
> > > + * The function gets if the otg port supports SRP
> > > + */
> > > +bool of_usb_otg_srp_support(struct device_node *np)
> > > +{
> > > +	if (of_find_property(np, "srp-support", NULL))
> > > +		return true;
> > > +
> > > +	return false;
> > > +}
> > > +EXPORT_SYMBOL_GPL(of_usb_otg_srp_support);
> > > +
> > > +/**
> > > + * of_usb_otg_hnp_support -  to get if otg hnp is supported by the otg controller
> > > + * @np: Pointer to the given device_node
> > > + *
> > > + * The function gets if the otg port supports HNP
> > > + */
> > > +bool of_usb_otg_hnp_support(struct device_node *np)
> > > +{
> > > +	if (of_find_property(np, "hnp-support", NULL))
> > > +		return true;
> > > +
> > > +	return false;
> > > +}
> > > +EXPORT_SYMBOL_GPL(of_usb_otg_hnp_support);
> > > +
> > > +/**
> > > + * of_usb_otg_adp_support -  to get if otg adp is supported by the otg controller
> > > + * @np: Pointer to the given device_node
> > > + *
> > > + * The function gets if the otg port supports ADP
> > > + */
> > > +bool of_usb_otg_adp_support(struct device_node *np)
> > > +{
> > > +	if (of_find_property(np, "adp-support", NULL))
> > > +		return true;
> > > +
> > > +	return false;
> > > +}
> > > +EXPORT_SYMBOL_GPL(of_usb_otg_adp_support);
> > > +
> > > +/**
> > > + * of_usb_otg_rev_number -  to get the otg release number the device is
> > > + * compliant with.
> > > + * @np: Pointer to the given device_node
> > > + *
> > > + * The function gets OTG and EH supplement release number in binary-coded
> > > + * decimal (i.e. 2.0 is 0200H).
> > > + */
> > > +int of_usb_otg_rev_number(struct device_node *np)
> > 
> > how about of_usb_get_otg_rev()?
> > 
> > > +{
> > > +	u32 otg_rev;
> > > +
> > > +	if (!of_property_read_u32(np, "otg-rev", &otg_rev))
> > > +		return otg_rev;
> > > +
> > > +	return 0;
> > > +}
> > > +EXPORT_SYMBOL_GPL(of_usb_otg_rev_number);
> > >  #endif
> > >  
> > 
> > cheers,
> > -roger

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 07/22] usb: chipidea: udc: set usb gadeget's otg config

[Li Jun]

Set gadget's otg features according to controller's capability and usb
property in device tree.

Signed-off-by: Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
---
 drivers/usb/chipidea/core.c  | 16 ++++++++++++++++
 drivers/usb/chipidea/udc.c   | 20 +++++++++++++++++++-
 include/linux/usb/chipidea.h |  4 ++++
 3 files changed, 39 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 74fea4f..a8ca9d7 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -588,6 +588,22 @@ static int ci_get_platdata(struct device *dev,
 				of_usb_host_tpl_support(dev->of_node);
 	}
 
+	if (platdata->dr_mode == USB_DR_MODE_OTG) {
+		if (!platdata->otg_rev) {
+			platdata->otg_rev =
+				of_usb_otg_rev_number(dev->of_node);
+		}
+		if (!platdata->srp_support)
+			platdata->srp_support =
+				of_usb_otg_srp_support(dev->of_node);
+		if (!platdata->hnp_support)
+			platdata->hnp_support =
+				of_usb_otg_hnp_support(dev->of_node);
+		if (!platdata->adp_support)
+			platdata->adp_support =
+				of_usb_otg_adp_support(dev->of_node);
+	}
+
 	if (of_usb_get_maximum_speed(dev->of_node) == USB_SPEED_FULL)
 		platdata->flags |= CI_HDRC_FORCE_FULLSPEED;
 
diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index 764f668..5d2c6e8 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -1821,6 +1821,24 @@ static irqreturn_t udc_irq(struct ci_hdrc *ci)
 }
 
 /**
+ * udc_update_otg_config: update gadget otg config
+ * * @ci: chipidea controller
+ */
+static void udc_update_otg_config(struct ci_hdrc *ci)
+{
+	if (!ci->is_otg)
+		return;
+
+	ci->gadget.otg_rev = ci->platdata->otg_rev;
+	ci->gadget.srp_support = ci->platdata->srp_support;
+	ci->gadget.hnp_support = ci->platdata->hnp_support;
+	ci->gadget.adp_support = ci->platdata->adp_support;
+	if (ci->gadget.srp_support || ci->gadget.hnp_support ||
+					ci->gadget.adp_support)
+		ci->gadget.is_otg = 1;
+}
+
+/**
  * udc_start: initialize gadget role
  * @ci: chipidea controller
  */
@@ -1834,9 +1852,9 @@ static int udc_start(struct ci_hdrc *ci)
 	ci->gadget.ops          = &usb_gadget_ops;
 	ci->gadget.speed        = USB_SPEED_UNKNOWN;
 	ci->gadget.max_speed    = USB_SPEED_HIGH;
-	ci->gadget.is_otg       = ci->is_otg ? 1 : 0;
 	ci->gadget.name         = ci->platdata->name;
 
+	udc_update_otg_config(ci);
 	INIT_LIST_HEAD(&ci->gadget.ep_list);
 
 	/* alloc resources */
diff --git a/include/linux/usb/chipidea.h b/include/linux/usb/chipidea.h
index ab94f78..c6aa3a4 100644
--- a/include/linux/usb/chipidea.h
+++ b/include/linux/usb/chipidea.h
@@ -34,7 +34,11 @@ struct ci_hdrc_platform_data {
 #define CI_HDRC_CONTROLLER_STOPPED_EVENT	1
 	void	(*notify_event) (struct ci_hdrc *ci, unsigned event);
 	struct regulator	*reg_vbus;
+	unsigned		otg_rev;
 	bool			tpl_support;
+	bool			srp_support;
+	bool			hnp_support;
+	bool			adp_support;
 };
 
 /* Default offset of capability registers */
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 07/22] usb: chipidea: udc: set usb gadeget's otg config

[Roger Quadros]

On Mon, 8 Jun 2015 23:02:02 +0800
Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:

> Set gadget's otg features according to controller's capability and usb
> property in device tree.
> 
> Signed-off-by: Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> ---
>  drivers/usb/chipidea/core.c  | 16 ++++++++++++++++
>  drivers/usb/chipidea/udc.c   | 20 +++++++++++++++++++-
>  include/linux/usb/chipidea.h |  4 ++++
>  3 files changed, 39 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> index 74fea4f..a8ca9d7 100644
> --- a/drivers/usb/chipidea/core.c
> +++ b/drivers/usb/chipidea/core.c
> @@ -588,6 +588,22 @@ static int ci_get_platdata(struct device *dev,
>  				of_usb_host_tpl_support(dev->of_node);
>  	}
>  
> +	if (platdata->dr_mode == USB_DR_MODE_OTG) {
> +		if (!platdata->otg_rev) {
> +			platdata->otg_rev =
> +				of_usb_otg_rev_number(dev->of_node);
> +		}
> +		if (!platdata->srp_support)
> +			platdata->srp_support =
> +				of_usb_otg_srp_support(dev->of_node);
> +		if (!platdata->hnp_support)
> +			platdata->hnp_support =
> +				of_usb_otg_hnp_support(dev->of_node);
> +		if (!platdata->adp_support)
> +			platdata->adp_support =
> +				of_usb_otg_adp_support(dev->of_node);

where do you check if the hardware really supports these features.
or is it that this hardware always supports these?

> +	}
> +
>  	if (of_usb_get_maximum_speed(dev->of_node) == USB_SPEED_FULL)
>  		platdata->flags |= CI_HDRC_FORCE_FULLSPEED;
>  
> diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
> index 764f668..5d2c6e8 100644
> --- a/drivers/usb/chipidea/udc.c
> +++ b/drivers/usb/chipidea/udc.c
> @@ -1821,6 +1821,24 @@ static irqreturn_t udc_irq(struct ci_hdrc *ci)
>  }
>  
>  /**
> + * udc_update_otg_config: update gadget otg config
> + * * @ci: chipidea controller
> + */
> +static void udc_update_otg_config(struct ci_hdrc *ci)
> +{
> +	if (!ci->is_otg)
> +		return;
> +
> +	ci->gadget.otg_rev = ci->platdata->otg_rev;
> +	ci->gadget.srp_support = ci->platdata->srp_support;
> +	ci->gadget.hnp_support = ci->platdata->hnp_support;
> +	ci->gadget.adp_support = ci->platdata->adp_support;
> +	if (ci->gadget.srp_support || ci->gadget.hnp_support ||
> +					ci->gadget.adp_support)
> +		ci->gadget.is_otg = 1;
> +}
> +
> +/**
>   * udc_start: initialize gadget role
>   * @ci: chipidea controller
>   */
> @@ -1834,9 +1852,9 @@ static int udc_start(struct ci_hdrc *ci)
>  	ci->gadget.ops          = &usb_gadget_ops;
>  	ci->gadget.speed        = USB_SPEED_UNKNOWN;
>  	ci->gadget.max_speed    = USB_SPEED_HIGH;
> -	ci->gadget.is_otg       = ci->is_otg ? 1 : 0;
>  	ci->gadget.name         = ci->platdata->name;
>  
> +	udc_update_otg_config(ci);

where is this function defined?

>  	INIT_LIST_HEAD(&ci->gadget.ep_list);
>  
>  	/* alloc resources */
> diff --git a/include/linux/usb/chipidea.h b/include/linux/usb/chipidea.h
> index ab94f78..c6aa3a4 100644
> --- a/include/linux/usb/chipidea.h
> +++ b/include/linux/usb/chipidea.h
> @@ -34,7 +34,11 @@ struct ci_hdrc_platform_data {
>  #define CI_HDRC_CONTROLLER_STOPPED_EVENT	1
>  	void	(*notify_event) (struct ci_hdrc *ci, unsigned event);
>  	struct regulator	*reg_vbus;
> +	unsigned		otg_rev;

I think we should have a dedicated type of otg_rev instead of unsigned
because it is not plain integer but BCD.

>  	bool			tpl_support;
> +	bool			srp_support;
> +	bool			hnp_support;
> +	bool			adp_support;
>  };
>  
>  /* Default offset of capability registers */

cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 08/22] usb: chipidea: update ci_otg_is_fsm_mode conditions

[Li Jun]

After introduce usb otg properties, update ci_otg_is_fsm_mode conditions
to be depending on both usb hardware properties and usb driver config,
also resolve a compile issue in debug.c after the API change.

Signed-off-by: Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
---
 drivers/usb/chipidea/ci.h    | 3 ++-
 drivers/usb/chipidea/debug.c | 1 +
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
index 6d6200e..90e8e53 100644
--- a/drivers/usb/chipidea/ci.h
+++ b/drivers/usb/chipidea/ci.h
@@ -407,7 +407,8 @@ static inline bool ci_otg_is_fsm_mode(struct ci_hdrc *ci)
 {
 #ifdef CONFIG_USB_OTG_FSM
 	return ci->is_otg && ci->roles[CI_ROLE_HOST] &&
-					ci->roles[CI_ROLE_GADGET];
+		ci->roles[CI_ROLE_GADGET] && (ci->platdata->srp_support ||
+		ci->platdata->hnp_support || ci->platdata->adp_support);
 #else
 	return false;
 #endif
diff --git a/drivers/usb/chipidea/debug.c b/drivers/usb/chipidea/debug.c
index 5b7061a..3869c6d 100644
--- a/drivers/usb/chipidea/debug.c
+++ b/drivers/usb/chipidea/debug.c
@@ -10,6 +10,7 @@
 #include <linux/usb/phy.h>
 #include <linux/usb/otg.h>
 #include <linux/usb/otg-fsm.h>
+#include <linux/usb/chipidea.h>
 
 #include "ci.h"
 #include "udc.h"
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 09/22] usb: gadget: add usb_otg_descriptor_add interface to init usb_otg_descriptor

[Li Jun]

Allocate usb_otg_descriptor and initialize it according to gadget otg
options, if none of options is not set, keep bmAttributes setting as
current gadget drivers, with this new interface, usb_otg_descriptor can
include bcdOTG if OTG 2.0 or later, and otg features can be decided by
the combination of usb hardware property and driver config.

Signed-off-by: Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
---
 drivers/usb/gadget/config.c | 37 +++++++++++++++++++++++++++++++++++++
 include/linux/usb/gadget.h  |  1 +
 2 files changed, 38 insertions(+)

diff --git a/drivers/usb/gadget/config.c b/drivers/usb/gadget/config.c
index 34e12fc..a86e079 100644
--- a/drivers/usb/gadget/config.c
+++ b/drivers/usb/gadget/config.c
@@ -195,3 +195,40 @@ void usb_free_all_descriptors(struct usb_function *f)
 	usb_free_descriptors(f->ss_descriptors);
 }
 EXPORT_SYMBOL_GPL(usb_free_all_descriptors);
+
+struct usb_otg_descriptor *usb_otg_descriptor_add(struct usb_gadget *gadget)
+{
+	struct usb_otg_descriptor *otg_desc;
+	unsigned otg_desc_length;
+
+	if (gadget->otg_rev >= 0x0200)
+		otg_desc_length = sizeof(*otg_desc) + sizeof(struct bcdOTG);
+	else
+		otg_desc_length = sizeof(*otg_desc);
+
+	otg_desc = (struct usb_otg_descriptor *)kzalloc(otg_desc_length,
+								GFP_KERNEL);
+	if (!otg_desc)
+		return otg_desc;
+
+	otg_desc->bLength = otg_desc_length;
+	otg_desc->bDescriptorType = USB_DT_OTG;
+
+	if (gadget->adp_support || gadget->hnp_support ||
+					gadget->srp_support) {
+		if (gadget->adp_support)
+			otg_desc->bmAttributes |= USB_OTG_ADP;
+		if (gadget->hnp_support)
+			otg_desc->bmAttributes |= USB_OTG_HNP;
+		if (gadget->srp_support)
+			otg_desc->bmAttributes |= USB_OTG_SRP;
+	} else {
+		otg_desc->bmAttributes = USB_OTG_SRP | USB_OTG_HNP;
+	}
+
+	if (gadget->otg_rev >= 0x0200)
+		otg_desc->otg_rev[0].bcdOTG = cpu_to_le16(gadget->otg_rev);
+
+	return otg_desc;
+}
+EXPORT_SYMBOL_GPL(usb_otg_descriptor_add);
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index 2f4f39c..e210466 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -1013,6 +1013,7 @@ int usb_assign_descriptors(struct usb_function *f,
 		struct usb_descriptor_header **ss);
 void usb_free_all_descriptors(struct usb_function *f);
 
+struct usb_otg_descriptor *usb_otg_descriptor_add(struct usb_gadget *gadget);
 /*-------------------------------------------------------------------------*/
 
 /* utility to simplify map/unmap of usb_requests to/from DMA */
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 09/22] usb: gadget: add usb_otg_descriptor_add interface to init usb_otg_descriptor

[Roger Quadros]

On Mon, 8 Jun 2015 23:02:04 +0800
Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:

> Allocate usb_otg_descriptor and initialize it according to gadget otg
> options, if none of options is not set, keep bmAttributes setting as
> current gadget drivers, with this new interface, usb_otg_descriptor can
> include bcdOTG if OTG 2.0 or later, and otg features can be decided by
> the combination of usb hardware property and driver config.
> 
> Signed-off-by: Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> ---
>  drivers/usb/gadget/config.c | 37 +++++++++++++++++++++++++++++++++++++
>  include/linux/usb/gadget.h  |  1 +
>  2 files changed, 38 insertions(+)
> 
> diff --git a/drivers/usb/gadget/config.c b/drivers/usb/gadget/config.c
> index 34e12fc..a86e079 100644
> --- a/drivers/usb/gadget/config.c
> +++ b/drivers/usb/gadget/config.c
> @@ -195,3 +195,40 @@ void usb_free_all_descriptors(struct usb_function *f)
>  	usb_free_descriptors(f->ss_descriptors);
>  }
>  EXPORT_SYMBOL_GPL(usb_free_all_descriptors);
> +
> +struct usb_otg_descriptor *usb_otg_descriptor_add(struct usb_gadget *gadget)
> +{
> +	struct usb_otg_descriptor *otg_desc;
> +	unsigned otg_desc_length;
> +
> +	if (gadget->otg_rev >= 0x0200)
> +		otg_desc_length = sizeof(*otg_desc) + sizeof(struct bcdOTG);
> +	else
> +		otg_desc_length = sizeof(*otg_desc);

This is wrong as otg_desc already contains bcdOTG in it.

> +
> +	otg_desc = (struct usb_otg_descriptor *)kzalloc(otg_desc_length,
> +								GFP_KERNEL);
> +	if (!otg_desc)
> +		return otg_desc;
> +
> +	otg_desc->bLength = otg_desc_length;
> +	otg_desc->bDescriptorType = USB_DT_OTG;
> +
> +	if (gadget->adp_support || gadget->hnp_support ||
> +					gadget->srp_support) {
> +		if (gadget->adp_support)
> +			otg_desc->bmAttributes |= USB_OTG_ADP;
> +		if (gadget->hnp_support)
> +			otg_desc->bmAttributes |= USB_OTG_HNP;
> +		if (gadget->srp_support)
> +			otg_desc->bmAttributes |= USB_OTG_SRP;
> +	} else {
> +		otg_desc->bmAttributes = USB_OTG_SRP | USB_OTG_HNP;
> +	}
> +
> +	if (gadget->otg_rev >= 0x0200)
> +		otg_desc->otg_rev[0].bcdOTG = cpu_to_le16(gadget->otg_rev);
> +
> +	return otg_desc;
> +}
> +EXPORT_SYMBOL_GPL(usb_otg_descriptor_add);
> diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
> index 2f4f39c..e210466 100644
> --- a/include/linux/usb/gadget.h
> +++ b/include/linux/usb/gadget.h
> @@ -1013,6 +1013,7 @@ int usb_assign_descriptors(struct usb_function *f,
>  		struct usb_descriptor_header **ss);
>  void usb_free_all_descriptors(struct usb_function *f);
>  
> +struct usb_otg_descriptor *usb_otg_descriptor_add(struct usb_gadget *gadget);
>  /*-------------------------------------------------------------------------*/
>  
>  /* utility to simplify map/unmap of usb_requests to/from DMA */

cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 09/22] usb: gadget: add usb_otg_descriptor_add interface to init usb_otg_descriptor

[Roger Quadros]

On Mon, 8 Jun 2015 23:02:04 +0800
Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:

> Allocate usb_otg_descriptor and initialize it according to gadget otg
> options, if none of options is not set, keep bmAttributes setting as
> current gadget drivers, with this new interface, usb_otg_descriptor can
> include bcdOTG if OTG 2.0 or later, and otg features can be decided by
> the combination of usb hardware property and driver config.
> 
> Signed-off-by: Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> ---
>  drivers/usb/gadget/config.c | 37 +++++++++++++++++++++++++++++++++++++
>  include/linux/usb/gadget.h  |  1 +
>  2 files changed, 38 insertions(+)
> 
> diff --git a/drivers/usb/gadget/config.c b/drivers/usb/gadget/config.c
> index 34e12fc..a86e079 100644
> --- a/drivers/usb/gadget/config.c
> +++ b/drivers/usb/gadget/config.c
> @@ -195,3 +195,40 @@ void usb_free_all_descriptors(struct usb_function *f)
>  	usb_free_descriptors(f->ss_descriptors);
>  }
>  EXPORT_SYMBOL_GPL(usb_free_all_descriptors);
> +
> +struct usb_otg_descriptor *usb_otg_descriptor_add(struct usb_gadget *gadget)
> +{
> +	struct usb_otg_descriptor *otg_desc;
> +	unsigned otg_desc_length;
> +
> +	if (gadget->otg_rev >= 0x0200)
> +		otg_desc_length = sizeof(*otg_desc) + sizeof(struct bcdOTG);
> +	else
> +		otg_desc_length = sizeof(*otg_desc);
> +
> +	otg_desc = (struct usb_otg_descriptor *)kzalloc(otg_desc_length,
> +								GFP_KERNEL); 

You are allocating memory here and expecting users will free it.
I suggest that you pass pointer to otg_desc as function argument and leave it upto
the caller to allocate/deallocate memory for it.

Most likely users will be a static allocation like they do now and it is a
lot simpler.

> +	if (!otg_desc)
> +		return otg_desc;
> +
> +	otg_desc->bLength = otg_desc_length;
> +	otg_desc->bDescriptorType = USB_DT_OTG;
> +
> +	if (gadget->adp_support || gadget->hnp_support ||
> +					gadget->srp_support) {
> +		if (gadget->adp_support)
> +			otg_desc->bmAttributes |= USB_OTG_ADP;
> +		if (gadget->hnp_support)
> +			otg_desc->bmAttributes |= USB_OTG_HNP;
> +		if (gadget->srp_support)
> +			otg_desc->bmAttributes |= USB_OTG_SRP;
> +	} else {
> +		otg_desc->bmAttributes = USB_OTG_SRP | USB_OTG_HNP;
> +	}
> +
> +	if (gadget->otg_rev >= 0x0200)
> +		otg_desc->otg_rev[0].bcdOTG = cpu_to_le16(gadget->otg_rev);
> +
> +	return otg_desc;
> +}
> +EXPORT_SYMBOL_GPL(usb_otg_descriptor_add);
> diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
> index 2f4f39c..e210466 100644
> --- a/include/linux/usb/gadget.h
> +++ b/include/linux/usb/gadget.h
> @@ -1013,6 +1013,7 @@ int usb_assign_descriptors(struct usb_function *f,
>  		struct usb_descriptor_header **ss);
>  void usb_free_all_descriptors(struct usb_function *f);
>  
> +struct usb_otg_descriptor *usb_otg_descriptor_add(struct usb_gadget *gadget);
>  /*-------------------------------------------------------------------------*/
>  
>  /* utility to simplify map/unmap of usb_requests to/from DMA */

cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 09/22] usb: gadget: add usb_otg_descriptor_add interface to init usb_otg_descriptor

[Li Jun]

On Tue, Jun 09, 2015 at 09:27:51PM +0800, Roger Quadros wrote:
> On Mon, 8 Jun 2015 23:02:04 +0800
> Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:
> 
> > Allocate usb_otg_descriptor and initialize it according to gadget otg
> > options, if none of options is not set, keep bmAttributes setting as
> > current gadget drivers, with this new interface, usb_otg_descriptor can
> > include bcdOTG if OTG 2.0 or later, and otg features can be decided by
> > the combination of usb hardware property and driver config.
> > 
> > Signed-off-by: Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> > ---
> >  drivers/usb/gadget/config.c | 37 +++++++++++++++++++++++++++++++++++++
> >  include/linux/usb/gadget.h  |  1 +
> >  2 files changed, 38 insertions(+)
> > 
> > diff --git a/drivers/usb/gadget/config.c b/drivers/usb/gadget/config.c
> > index 34e12fc..a86e079 100644
> > --- a/drivers/usb/gadget/config.c
> > +++ b/drivers/usb/gadget/config.c
> > @@ -195,3 +195,40 @@ void usb_free_all_descriptors(struct usb_function *f)
> >  	usb_free_descriptors(f->ss_descriptors);
> >  }
> >  EXPORT_SYMBOL_GPL(usb_free_all_descriptors);
> > +
> > +struct usb_otg_descriptor *usb_otg_descriptor_add(struct usb_gadget *gadget)
> > +{
> > +	struct usb_otg_descriptor *otg_desc;
> > +	unsigned otg_desc_length;
> > +
> > +	if (gadget->otg_rev >= 0x0200)
> > +		otg_desc_length = sizeof(*otg_desc) + sizeof(struct bcdOTG);
> > +	else
> > +		otg_desc_length = sizeof(*otg_desc);
> > +
> > +	otg_desc = (struct usb_otg_descriptor *)kzalloc(otg_desc_length,
> > +								GFP_KERNEL); 
> 
> You are allocating memory here and expecting users will free it.
> I suggest that you pass pointer to otg_desc as function argument and leave it upto
> the caller to allocate/deallocate memory for it.

Agreed, I will update accordingly.

> 
> Most likely users will be a static allocation like they do now and it is a
> lot simpler.
> 
I need allocate different size memory at runtime, that static
allocation should be changed, I will try Alan's suggestion with
2 different structures to make it simpler.

> > +	if (!otg_desc)
> > +		return otg_desc;
> > +
> > +	otg_desc->bLength = otg_desc_length;
> > +	otg_desc->bDescriptorType = USB_DT_OTG;
> > +
> > +	if (gadget->adp_support || gadget->hnp_support ||
> > +					gadget->srp_support) {
> > +		if (gadget->adp_support)
> > +			otg_desc->bmAttributes |= USB_OTG_ADP;
> > +		if (gadget->hnp_support)
> > +			otg_desc->bmAttributes |= USB_OTG_HNP;
> > +		if (gadget->srp_support)
> > +			otg_desc->bmAttributes |= USB_OTG_SRP;
> > +	} else {
> > +		otg_desc->bmAttributes = USB_OTG_SRP | USB_OTG_HNP;
> > +	}
> > +
> > +	if (gadget->otg_rev >= 0x0200)
> > +		otg_desc->otg_rev[0].bcdOTG = cpu_to_le16(gadget->otg_rev);
> > +
> > +	return otg_desc;
> > +}
> > +EXPORT_SYMBOL_GPL(usb_otg_descriptor_add);
> > diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
> > index 2f4f39c..e210466 100644
> > --- a/include/linux/usb/gadget.h
> > +++ b/include/linux/usb/gadget.h
> > @@ -1013,6 +1013,7 @@ int usb_assign_descriptors(struct usb_function *f,
> >  		struct usb_descriptor_header **ss);
> >  void usb_free_all_descriptors(struct usb_function *f);
> >  
> > +struct usb_otg_descriptor *usb_otg_descriptor_add(struct usb_gadget *gadget);
> >  /*-------------------------------------------------------------------------*/
> >  
> >  /* utility to simplify map/unmap of usb_requests to/from DMA */
> 
> cheers,
> -roger
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 10/22] usb: gadget: configfs: init and add usb_otg_descriptor for usb configurations

[Li Jun]

Use usb_otg_descriptor_add to allocate and initialize usb_otg_descriptor,
add it for each usb configurations, free it while composite unbind.

Signed-off-by: Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
---
 drivers/usb/gadget/configfs.c | 26 +++++++++++++++++---------
 1 file changed, 17 insertions(+), 9 deletions(-)

diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c
index 0495c94..bf3e625 100644
--- a/drivers/usb/gadget/configfs.c
+++ b/drivers/usb/gadget/configfs.c
@@ -41,6 +41,8 @@ int check_user_usb_string(const char *name,
 #define MAX_NAME_LEN	40
 #define MAX_USB_STRING_LANGS 2
 
+static const struct usb_descriptor_header *otg_desc[2];
+
 struct gadget_info {
 	struct config_group group;
 	struct config_group functions_group;
@@ -55,9 +57,6 @@ struct gadget_info {
 	struct list_head available_func;
 
 	const char *udc_name;
-#ifdef CONFIG_USB_OTG
-	struct usb_otg_descriptor otg;
-#endif
 	struct usb_composite_driver composite;
 	struct usb_composite_dev cdev;
 	bool use_os_desc;
@@ -1376,6 +1375,16 @@ static int configfs_composite_bind(struct usb_gadget *gadget,
 		memcpy(cdev->qw_sign, gi->qw_sign, OS_STRING_QW_SIGN_LEN);
 	}
 
+	if (gadget_is_otg(gadget) && !otg_desc[0]) {
+		otg_desc[0] = (struct usb_descriptor_header *)
+				usb_otg_descriptor_add(gi->cdev.gadget);
+		if (!otg_desc[0]) {
+			ret = -ENOMEM;
+			goto err_comp_cleanup;
+		}
+		otg_desc[1] = NULL;
+	}
+
 	/* Go through all configs, attach all functions */
 	list_for_each_entry(c, &gi->cdev.configs, list) {
 		struct config_usb_cfg *cfg;
@@ -1383,6 +1392,9 @@ static int configfs_composite_bind(struct usb_gadget *gadget,
 		struct usb_function *tmp;
 		struct gadget_config_name *cn;
 
+		if (gadget_is_otg(gadget))
+			c->descriptors = otg_desc;
+
 		cfg = container_of(c, struct config_usb_cfg, c);
 		if (!list_empty(&cfg->string_list)) {
 			i = 0;
@@ -1437,6 +1449,8 @@ static void configfs_composite_unbind(struct usb_gadget *gadget)
 	cdev = get_gadget_data(gadget);
 	gi = container_of(cdev, struct gadget_info, cdev);
 
+	kfree(otg_desc[0]);
+	otg_desc[0] = NULL;
 	purge_configs_funcs(gi);
 	composite_dev_cleanup(cdev);
 	usb_ep_autoconfig_reset(cdev->gadget);
@@ -1510,12 +1524,6 @@ static struct config_group *gadgets_make(
 	if (!gi->composite.gadget_driver.function)
 		goto err;
 
-#ifdef CONFIG_USB_OTG
-	gi->otg.bLength = sizeof(struct usb_otg_descriptor);
-	gi->otg.bDescriptorType = USB_DT_OTG;
-	gi->otg.bmAttributes = USB_OTG_SRP | USB_OTG_HNP;
-#endif

Re: [PATCH v2 10/22] usb: gadget: configfs: init and add usb_otg_descriptor for usb configurations

[Roger Quadros]

On Mon, 8 Jun 2015 23:02:05 +0800
Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org> wrote:

> Use usb_otg_descriptor_add to allocate and initialize usb_otg_descriptor,
> add it for each usb configurations, free it while composite unbind.
> 
> Signed-off-by: Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> ---
>  drivers/usb/gadget/configfs.c | 26 +++++++++++++++++---------
>  1 file changed, 17 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/usb/gadget/configfs.c b/drivers/usb/gadget/configfs.c
> index 0495c94..bf3e625 100644
> --- a/drivers/usb/gadget/configfs.c
> +++ b/drivers/usb/gadget/configfs.c
> @@ -41,6 +41,8 @@ int check_user_usb_string(const char *name,
>  #define MAX_NAME_LEN	40
>  #define MAX_USB_STRING_LANGS 2
>  
> +static const struct usb_descriptor_header *otg_desc[2];
> +
>  struct gadget_info {
>  	struct config_group group;
>  	struct config_group functions_group;
> @@ -55,9 +57,6 @@ struct gadget_info {
>  	struct list_head available_func;
>  
>  	const char *udc_name;
> -#ifdef CONFIG_USB_OTG
> -	struct usb_otg_descriptor otg;
> -#endif
>  	struct usb_composite_driver composite;
>  	struct usb_composite_dev cdev;
>  	bool use_os_desc;
> @@ -1376,6 +1375,16 @@ static int configfs_composite_bind(struct usb_gadget *gadget,
>  		memcpy(cdev->qw_sign, gi->qw_sign, OS_STRING_QW_SIGN_LEN);
>  	}
>  
> +	if (gadget_is_otg(gadget) && !otg_desc[0]) {
> +		otg_desc[0] = (struct usb_descriptor_header *)
> +				usb_otg_descriptor_add(gi->cdev.gadget);
> +		if (!otg_desc[0]) {
> +			ret = -ENOMEM;
> +			goto err_comp_cleanup;
> +		}
> +		otg_desc[1] = NULL;

If you use static allocation for otg_desc this code simplifies to
		usb_otg_descriptor_add(gi->cdev.gadget, &otg_desc[0]);

assuming we have already allocated for otg_desc like so

static struct usb_otg_descriptor otg_descriptor;	/* configured at runtime */
static const struct usb_descriptor_header *otg_desc[] = {
        (struct usb_descriptor_header *) &otg_descriptor,
        NULL,
};


> +	}
> +
>  	/* Go through all configs, attach all functions */
>  	list_for_each_entry(c, &gi->cdev.configs, list) {
>  		struct config_usb_cfg *cfg;
> @@ -1383,6 +1392,9 @@ static int configfs_composite_bind(struct usb_gadget *gadget,
>  		struct usb_function *tmp;
>  		struct gadget_config_name *cn;
>  
> +		if (gadget_is_otg(gadget))
> +			c->descriptors = otg_desc;
> +
>  		cfg = container_of(c, struct config_usb_cfg, c);
>  		if (!list_empty(&cfg->string_list)) {
>  			i = 0;
> @@ -1437,6 +1449,8 @@ static void configfs_composite_unbind(struct usb_gadget *gadget)
>  	cdev = get_gadget_data(gadget);
>  	gi = container_of(cdev, struct gadget_info, cdev);
>  
> +	kfree(otg_desc[0]);
> +	otg_desc[0] = NULL;
>  	purge_configs_funcs(gi);
>  	composite_dev_cleanup(cdev);
>  	usb_ep_autoconfig_reset(cdev->gadget);
> @@ -1510,12 +1524,6 @@ static struct config_group *gadgets_make(
>  	if (!gi->composite.gadget_driver.function)
>  		goto err;
>  
> -#ifdef CONFIG_USB_OTG
> -	gi->otg.bLength = sizeof(struct usb_otg_descriptor);
> -	gi->otg.bDescriptorType = USB_DT_OTG;
> -	gi->otg.bmAttributes = USB_OTG_SRP | USB_OTG_HNP;
> -#endif
> -
>  	config_group_init_type_name(&gi->group, name,
>  				&gadget_root_type);
>  	return &gi->group;

cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 11/22] usb: gadget: ether: init usb_otg_descriptor via usb_otg_descriptor_add

[Li Jun]

Use usb_otg_descriptor_add to allocate and initialize usb_otg_descriptor,
free it while composite unbind.

Signed-off-by: Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
---
 drivers/usb/gadget/legacy/ether.c | 32 ++++++++++++++++++--------------
 1 file changed, 18 insertions(+), 14 deletions(-)

diff --git a/drivers/usb/gadget/legacy/ether.c b/drivers/usb/gadget/legacy/ether.c
index a3323dc..b9eebe3 100644
--- a/drivers/usb/gadget/legacy/ether.c
+++ b/drivers/usb/gadget/legacy/ether.c
@@ -171,20 +171,7 @@ static struct usb_device_descriptor device_desc = {
 	.bNumConfigurations =	1,
 };
 
-static struct usb_otg_descriptor otg_descriptor = {
-	.bLength =		sizeof otg_descriptor,
-	.bDescriptorType =	USB_DT_OTG,
-
-	/* REVISIT SRP-only hardware is possible, although
-	 * it would not be called "OTG" ...
-	 */
-	.bmAttributes =		USB_OTG_SRP | USB_OTG_HNP,
-};
-
-static const struct usb_descriptor_header *otg_desc[] = {
-	(struct usb_descriptor_header *) &otg_descriptor,
-	NULL,
-};
+static const struct usb_descriptor_header *otg_desc[2];
 
 static struct usb_string strings_dev[] = {
 	[USB_GADGET_MANUFACTURER_IDX].s = "",
@@ -229,6 +216,13 @@ static int rndis_do_config(struct usb_configuration *c)
 	/* FIXME alloc iConfiguration string, set it in c->strings */
 
 	if (gadget_is_otg(c->cdev->gadget)) {
+		if (!otg_desc[0]) {
+			otg_desc[0] = (struct usb_descriptor_header *)
+				usb_otg_descriptor_add(c->cdev->gadget);
+			if (!otg_desc[0])
+				return -ENOMEM;
+			otg_desc[1] = NULL;
+		}
 		c->descriptors = otg_desc;
 		c->bmAttributes |= USB_CONFIG_ATT_WAKEUP;
 	}
@@ -271,6 +265,13 @@ static int eth_do_config(struct usb_configuration *c)
 	/* FIXME alloc iConfiguration string, set it in c->strings */
 
 	if (gadget_is_otg(c->cdev->gadget)) {
+		if (!otg_desc[0]) {
+			otg_desc[0] = (struct usb_descriptor_header *)
+				usb_otg_descriptor_add(c->cdev->gadget);
+			if (!otg_desc[0])
+				return -ENOMEM;
+			otg_desc[1] = NULL;
+		}
 		c->descriptors = otg_desc;
 		c->bmAttributes |= USB_CONFIG_ATT_WAKEUP;
 	}
@@ -463,6 +464,9 @@ static int eth_unbind(struct usb_composite_dev *cdev)
 		usb_put_function(f_geth);
 		usb_put_function_instance(fi_geth);
 	}
+	kfree(otg_desc[0]);
+	otg_desc[0] = NULL;
+
 	return 0;
 }
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 12/22] usb: gadget: acm_ms: init usb_otg_descriptor via usb_otg_descriptor_add

[Li Jun]

Use usb_otg_descriptor_add to allocate and initialize usb_otg_descriptor,
free it while composite unbind.

Signed-off-by: Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
---
 drivers/usb/gadget/legacy/acm_ms.c | 26 +++++++++++---------------
 1 file changed, 11 insertions(+), 15 deletions(-)

diff --git a/drivers/usb/gadget/legacy/acm_ms.c b/drivers/usb/gadget/legacy/acm_ms.c
index 1194b09..fc02384 100644
--- a/drivers/usb/gadget/legacy/acm_ms.c
+++ b/drivers/usb/gadget/legacy/acm_ms.c
@@ -58,21 +58,7 @@ static struct usb_device_descriptor device_desc = {
 	/*.bNumConfigurations =	DYNAMIC*/
 };
 
-static struct usb_otg_descriptor otg_descriptor = {
-	.bLength =		sizeof otg_descriptor,
-	.bDescriptorType =	USB_DT_OTG,
-
-	/*
-	 * REVISIT SRP-only hardware is possible, although
-	 * it would not be called "OTG" ...
-	 */
-	.bmAttributes =		USB_OTG_SRP | USB_OTG_HNP,
-};
-
-static const struct usb_descriptor_header *otg_desc[] = {
-	(struct usb_descriptor_header *) &otg_descriptor,
-	NULL,
-};
+static const struct usb_descriptor_header *otg_desc[2];
 
 /* string IDs are assigned dynamically */
 static struct usb_string strings_dev[] = {
@@ -127,6 +113,13 @@ static int acm_ms_do_config(struct usb_configuration *c)
 	int	status;
 
 	if (gadget_is_otg(c->cdev->gadget)) {
+		if (!otg_desc[0]) {
+			otg_desc[0] = (struct usb_descriptor_header *)
+				usb_otg_descriptor_add(c->cdev->gadget);
+			if (!otg_desc[0])
+				return -ENOMEM;
+			otg_desc[1] = NULL;
+		}
 		c->descriptors = otg_desc;
 		c->bmAttributes |= USB_CONFIG_ATT_WAKEUP;
 	}
@@ -255,6 +248,9 @@ static int acm_ms_unbind(struct usb_composite_dev *cdev)
 	usb_put_function_instance(fi_msg);
 	usb_put_function(f_acm);
 	usb_put_function_instance(f_acm_inst);
+	kfree(otg_desc[0]);
+	otg_desc[0] = NULL;
+
 	return 0;
 }
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 13/22] usb: gadget: audio: init usb_otg_descriptor via usb_otg_descriptor_add

[Li Jun]

Use usb_otg_descriptor_add to allocate and initialize usb_otg_descriptor,
free it while composite unbind.

Signed-off-by: Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
---
 drivers/usb/gadget/legacy/audio.c | 25 +++++++++++--------------
 1 file changed, 11 insertions(+), 14 deletions(-)

diff --git a/drivers/usb/gadget/legacy/audio.c b/drivers/usb/gadget/legacy/audio.c
index f289caf..abe53f2 100644
--- a/drivers/usb/gadget/legacy/audio.c
+++ b/drivers/usb/gadget/legacy/audio.c
@@ -150,20 +150,7 @@ static struct usb_device_descriptor device_desc = {
 	.bNumConfigurations =	1,
 };
 
-static struct usb_otg_descriptor otg_descriptor = {
-	.bLength =		sizeof otg_descriptor,
-	.bDescriptorType =	USB_DT_OTG,
-
-	/* REVISIT SRP-only hardware is possible, although
-	 * it would not be called "OTG" ...
-	 */
-	.bmAttributes =		USB_OTG_SRP | USB_OTG_HNP,
-};
-
-static const struct usb_descriptor_header *otg_desc[] = {
-	(struct usb_descriptor_header *) &otg_descriptor,
-	NULL,
-};
+static const struct usb_descriptor_header *otg_desc[2];
 
 /*-------------------------------------------------------------------------*/
 
@@ -174,6 +161,13 @@ static int audio_do_config(struct usb_configuration *c)
 	/* FIXME alloc iConfiguration string, set it in c->strings */
 
 	if (gadget_is_otg(c->cdev->gadget)) {
+		if (!otg_desc[0]) {
+			otg_desc[0] = (struct usb_descriptor_header *)
+				usb_otg_descriptor_add(c->cdev->gadget);
+			if (!otg_desc[0])
+				return -ENOMEM;
+			otg_desc[1] = NULL;
+		}
 		c->descriptors = otg_desc;
 		c->bmAttributes |= USB_CONFIG_ATT_WAKEUP;
 	}
@@ -289,6 +283,9 @@ static int audio_unbind(struct usb_composite_dev *cdev)
 	if (!IS_ERR_OR_NULL(fi_uac2))
 		usb_put_function_instance(fi_uac2);
 #endif
+	kfree(otg_desc[0]);
+	otg_desc[0] = NULL;
+
 	return 0;
 }
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 14/22] usb: gadget: cdc2: init usb_otg_descriptor via usb_otg_descriptor_add

[Li Jun]

Use usb_otg_descriptor_add to allocate and initialize usb_otg_descriptor,
free it while composite unbind.

Signed-off-by: Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
---
 drivers/usb/gadget/legacy/cdc2.c | 26 +++++++++++---------------
 1 file changed, 11 insertions(+), 15 deletions(-)

diff --git a/drivers/usb/gadget/legacy/cdc2.c b/drivers/usb/gadget/legacy/cdc2.c
index afd3e37..34141e4 100644
--- a/drivers/usb/gadget/legacy/cdc2.c
+++ b/drivers/usb/gadget/legacy/cdc2.c
@@ -60,21 +60,7 @@ static struct usb_device_descriptor device_desc = {
 	.bNumConfigurations =	1,
 };
 
-static struct usb_otg_descriptor otg_descriptor = {
-	.bLength =		sizeof otg_descriptor,
-	.bDescriptorType =	USB_DT_OTG,
-
-	/* REVISIT SRP-only hardware is possible, although
-	 * it would not be called "OTG" ...
-	 */
-	.bmAttributes =		USB_OTG_SRP | USB_OTG_HNP,
-};
-
-static const struct usb_descriptor_header *otg_desc[] = {
-	(struct usb_descriptor_header *) &otg_descriptor,
-	NULL,
-};
-
+static const struct usb_descriptor_header *otg_desc[2];
 
 /* string IDs are assigned dynamically */
 static struct usb_string strings_dev[] = {
@@ -109,6 +95,13 @@ static int cdc_do_config(struct usb_configuration *c)
 	int	status;
 
 	if (gadget_is_otg(c->cdev->gadget)) {
+		if (!otg_desc[0]) {
+			otg_desc[0] = (struct usb_descriptor_header *)
+				usb_otg_descriptor_add(c->cdev->gadget);
+			if (!otg_desc[0])
+				return -ENOMEM;
+			otg_desc[1] = NULL;
+		}
 		c->descriptors = otg_desc;
 		c->bmAttributes |= USB_CONFIG_ATT_WAKEUP;
 	}
@@ -219,6 +212,9 @@ static int cdc_unbind(struct usb_composite_dev *cdev)
 		usb_put_function(f_ecm);
 	if (!IS_ERR_OR_NULL(fi_ecm))
 		usb_put_function_instance(fi_ecm);
+	kfree(otg_desc[0]);
+	otg_desc[0] = NULL;
+
 	return 0;
 }
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 15/22] usb: gadget: g_ffs: init usb_otg_descriptor via usb_otg_descriptor_add

[Li Jun]

Use usb_otg_descriptor_add to allocate and initialize usb_otg_descriptor,
free it while composite unbind.

Signed-off-by: Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
---
 drivers/usb/gadget/legacy/g_ffs.c | 26 +++++++++++---------------
 1 file changed, 11 insertions(+), 15 deletions(-)

diff --git a/drivers/usb/gadget/legacy/g_ffs.c b/drivers/usb/gadget/legacy/g_ffs.c
index 7b9ef7e..38e4452 100644
--- a/drivers/usb/gadget/legacy/g_ffs.c
+++ b/drivers/usb/gadget/legacy/g_ffs.c
@@ -88,21 +88,7 @@ MODULE_PARM_DESC(bDeviceProtocol, "USB Device protocol");
 module_param_array_named(functions, func_names, charp, &func_num, 0);
 MODULE_PARM_DESC(functions, "USB Functions list");
 
-static const struct usb_descriptor_header *gfs_otg_desc[] = {
-	(const struct usb_descriptor_header *)
-	&(const struct usb_otg_descriptor) {
-		.bLength		= sizeof(struct usb_otg_descriptor),
-		.bDescriptorType	= USB_DT_OTG,
-
-		/*
-		 * REVISIT SRP-only hardware is possible, although
-		 * it would not be called "OTG" ...
-		 */
-		.bmAttributes		= USB_OTG_SRP | USB_OTG_HNP,
-	},
-
-	NULL
-};
+static const struct usb_descriptor_header *gfs_otg_desc[2];
 
 /* String IDs are assigned dynamically */
 static struct usb_string gfs_strings[] = {
@@ -471,6 +457,9 @@ static int gfs_unbind(struct usb_composite_dev *cdev)
 	for (i = 0; i < N_CONF * func_num; ++i)
 		usb_put_function(*(f_ffs[0] + i));
 
+	kfree(gfs_otg_desc[0]);
+	gfs_otg_desc[0] = NULL;
+
 	return 0;
 }
 
@@ -489,6 +478,13 @@ static int gfs_do_config(struct usb_configuration *c)
 		return -ENODEV;
 
 	if (gadget_is_otg(c->cdev->gadget)) {
+		if (!gfs_otg_desc[0]) {
+			gfs_otg_desc[0] = (struct usb_descriptor_header *)
+					usb_otg_descriptor_add(c->cdev->gadget);
+			if (!gfs_otg_desc[0])
+				return -ENOMEM;
+			gfs_otg_desc[1] = NULL;
+		}
 		c->descriptors = gfs_otg_desc;
 		c->bmAttributes |= USB_CONFIG_ATT_WAKEUP;
 	}
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 16/22] usb: gadget: hid: init usb_otg_descriptor via usb_otg_descriptor_add

[Li Jun]

Use usb_otg_descriptor_add to allocate and initialize usb_otg_descriptor,
free it while composite unbind.

Signed-off-by: Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
---
 drivers/usb/gadget/legacy/hid.c | 27 ++++++++++++---------------
 1 file changed, 12 insertions(+), 15 deletions(-)

diff --git a/drivers/usb/gadget/legacy/hid.c b/drivers/usb/gadget/legacy/hid.c
index 2baa572..1010166 100644
--- a/drivers/usb/gadget/legacy/hid.c
+++ b/drivers/usb/gadget/legacy/hid.c
@@ -68,21 +68,7 @@ static struct usb_device_descriptor device_desc = {
 	.bNumConfigurations =	1,
 };
 
-static struct usb_otg_descriptor otg_descriptor = {
-	.bLength =		sizeof otg_descriptor,
-	.bDescriptorType =	USB_DT_OTG,
-
-	/* REVISIT SRP-only hardware is possible, although
-	 * it would not be called "OTG" ...
-	 */
-	.bmAttributes =		USB_OTG_SRP | USB_OTG_HNP,
-};
-
-static const struct usb_descriptor_header *otg_desc[] = {
-	(struct usb_descriptor_header *) &otg_descriptor,
-	NULL,
-};
-
+static const struct usb_descriptor_header *otg_desc[2];
 
 /* string IDs are assigned dynamically */
 static struct usb_string strings_dev[] = {
@@ -112,6 +98,13 @@ static int do_config(struct usb_configuration *c)
 	int status = 0;
 
 	if (gadget_is_otg(c->cdev->gadget)) {
+		if (!otg_desc[0]) {
+			otg_desc[0] = (struct usb_descriptor_header *)
+				usb_otg_descriptor_add(c->cdev->gadget);
+			if (!otg_desc[0])
+				return -ENOMEM;
+			otg_desc[1] = NULL;
+		}
 		c->descriptors = otg_desc;
 		c->bmAttributes |= USB_CONFIG_ATT_WAKEUP;
 	}
@@ -213,6 +206,10 @@ static int hid_unbind(struct usb_composite_dev *cdev)
 		usb_put_function(n->f);
 		usb_put_function_instance(n->fi);
 	}
+
+	kfree(otg_desc[0]);
+	otg_desc[0] = NULL;
+
 	return 0;
 }
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 17/22] usb: gadget: mass_storage: init usb_otg_descriptor via usb_otg_descriptor_add

[Li Jun]

Use usb_otg_descriptor_add to allocate and initialize usb_otg_descriptor,
free it while composite unbind.

Signed-off-by: Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
---
 drivers/usb/gadget/legacy/mass_storage.c | 26 +++++++++++---------------
 1 file changed, 11 insertions(+), 15 deletions(-)

diff --git a/drivers/usb/gadget/legacy/mass_storage.c b/drivers/usb/gadget/legacy/mass_storage.c
index e7bfb08..20fdc2f 100644
--- a/drivers/usb/gadget/legacy/mass_storage.c
+++ b/drivers/usb/gadget/legacy/mass_storage.c
@@ -64,21 +64,7 @@ static struct usb_device_descriptor msg_device_desc = {
 	.bNumConfigurations =	1,
 };
 
-static struct usb_otg_descriptor otg_descriptor = {
-	.bLength =		sizeof otg_descriptor,
-	.bDescriptorType =	USB_DT_OTG,
-
-	/*
-	 * REVISIT SRP-only hardware is possible, although
-	 * it would not be called "OTG" ...
-	 */
-	.bmAttributes =		USB_OTG_SRP | USB_OTG_HNP,
-};
-
-static const struct usb_descriptor_header *otg_desc[] = {
-	(struct usb_descriptor_header *) &otg_descriptor,
-	NULL,
-};
+static const struct usb_descriptor_header *otg_desc[2];
 
 static struct usb_string strings_dev[] = {
 	[USB_GADGET_MANUFACTURER_IDX].s = "",
@@ -136,6 +122,13 @@ static int msg_do_config(struct usb_configuration *c)
 	int ret;
 
 	if (gadget_is_otg(c->cdev->gadget)) {
+		if (!otg_desc[0]) {
+			otg_desc[0] = (struct usb_descriptor_header *)
+				usb_otg_descriptor_add(c->cdev->gadget);
+			if (!otg_desc[0])
+				return -ENOMEM;
+			otg_desc[1] = NULL;
+		}
 		c->descriptors = otg_desc;
 		c->bmAttributes |= USB_CONFIG_ATT_WAKEUP;
 	}
@@ -243,6 +236,9 @@ static int msg_unbind(struct usb_composite_dev *cdev)
 	if (!IS_ERR(fi_msg))
 		usb_put_function_instance(fi_msg);
 
+	kfree(otg_desc[0]);
+	otg_desc[0] = NULL;
+
 	return 0;
 }
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 18/22] usb: gadget: multi: init usb_otg_descriptor via usb_otg_descriptor_add

[Li Jun]

Use usb_otg_descriptor_add to allocate and initialize usb_otg_descriptor,
free it while composite unbind.

Signed-off-by: Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
---
 drivers/usb/gadget/legacy/multi.c | 33 ++++++++++++++++++---------------
 1 file changed, 18 insertions(+), 15 deletions(-)

diff --git a/drivers/usb/gadget/legacy/multi.c b/drivers/usb/gadget/legacy/multi.c
index b21b51f..f5de51d 100644
--- a/drivers/usb/gadget/legacy/multi.c
+++ b/drivers/usb/gadget/legacy/multi.c
@@ -78,21 +78,7 @@ static struct usb_device_descriptor device_desc = {
 	.idProduct =		cpu_to_le16(MULTI_PRODUCT_NUM),
 };
 
-
-static const struct usb_descriptor_header *otg_desc[] = {
-	(struct usb_descriptor_header *) &(struct usb_otg_descriptor){
-		.bLength =		sizeof(struct usb_otg_descriptor),
-		.bDescriptorType =	USB_DT_OTG,
-
-		/*
-		 * REVISIT SRP-only hardware is possible, although
-		 * it would not be called "OTG" ...
-		 */
-		.bmAttributes =		USB_OTG_SRP | USB_OTG_HNP,
-	},
-	NULL,
-};
-
+static const struct usb_descriptor_header *otg_desc[2];
 
 enum {
 	MULTI_STRING_RNDIS_CONFIG_IDX = USB_GADGET_FIRST_AVAIL_IDX,
@@ -155,6 +141,13 @@ static int rndis_do_config(struct usb_configuration *c)
 	int ret;
 
 	if (gadget_is_otg(c->cdev->gadget)) {
+		if (!otg_desc[0]) {
+			otg_desc[0] = (struct usb_descriptor_header *)
+				usb_otg_descriptor_add(c->cdev->gadget);
+			if (!otg_desc[0])
+				return -ENOMEM;
+			otg_desc[1] = NULL;
+		}
 		c->descriptors = otg_desc;
 		c->bmAttributes |= USB_CONFIG_ATT_WAKEUP;
 	}
@@ -243,6 +236,13 @@ static int cdc_do_config(struct usb_configuration *c)
 	int ret;
 
 	if (gadget_is_otg(c->cdev->gadget)) {
+		if (!otg_desc[0]) {
+			otg_desc[0] = (struct usb_descriptor_header *)
+				usb_otg_descriptor_add(c->cdev->gadget);
+			if (!otg_desc[0])
+				return -ENOMEM;
+			otg_desc[1] = NULL;
+		}
 		c->descriptors = otg_desc;
 		c->bmAttributes |= USB_CONFIG_ATT_WAKEUP;
 	}
@@ -490,6 +490,9 @@ static int multi_unbind(struct usb_composite_dev *cdev)
 	usb_put_function(f_ecm);
 	usb_put_function_instance(fi_ecm);
 #endif
+	kfree(otg_desc[0]);
+	otg_desc[0] = NULL;
+
 	return 0;
 }
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 19/22] usb: gadget: ncm: init usb_otg_descriptor via usb_otg_descriptor_add

[Li Jun]

Use usb_otg_descriptor_add to allocate and initialize usb_otg_descriptor,
free it while composite unbind.

Signed-off-by: Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
---
 drivers/usb/gadget/legacy/ncm.c | 25 +++++++++++--------------
 1 file changed, 11 insertions(+), 14 deletions(-)

diff --git a/drivers/usb/gadget/legacy/ncm.c b/drivers/usb/gadget/legacy/ncm.c
index 6ce7421..644df4f 100644
--- a/drivers/usb/gadget/legacy/ncm.c
+++ b/drivers/usb/gadget/legacy/ncm.c
@@ -69,20 +69,7 @@ static struct usb_device_descriptor device_desc = {
 	.bNumConfigurations =	1,
 };
 
-static struct usb_otg_descriptor otg_descriptor = {
-	.bLength =		sizeof otg_descriptor,
-	.bDescriptorType =	USB_DT_OTG,
-
-	/* REVISIT SRP-only hardware is possible, although
-	 * it would not be called "OTG" ...
-	 */
-	.bmAttributes =		USB_OTG_SRP | USB_OTG_HNP,
-};
-
-static const struct usb_descriptor_header *otg_desc[] = {
-	(struct usb_descriptor_header *) &otg_descriptor,
-	NULL,
-};
+static const struct usb_descriptor_header *otg_desc[2];
 
 /* string IDs are assigned dynamically */
 static struct usb_string strings_dev[] = {
@@ -114,6 +101,13 @@ static int ncm_do_config(struct usb_configuration *c)
 	/* FIXME alloc iConfiguration string, set it in c->strings */
 
 	if (gadget_is_otg(c->cdev->gadget)) {
+		if (!otg_desc[0]) {
+			otg_desc[0] = (struct usb_descriptor_header *)
+				usb_otg_descriptor_add(c->cdev->gadget);
+			if (!otg_desc[0])
+				return -ENOMEM;
+			otg_desc[1] = NULL;
+		}
 		c->descriptors = otg_desc;
 		c->bmAttributes |= USB_CONFIG_ATT_WAKEUP;
 	}
@@ -192,6 +186,9 @@ static int gncm_unbind(struct usb_composite_dev *cdev)
 		usb_put_function(f_ncm);
 	if (!IS_ERR_OR_NULL(f_ncm_inst))
 		usb_put_function_instance(f_ncm_inst);
+	kfree(otg_desc[0]);
+	otg_desc[0] = NULL;
+
 	return 0;
 }
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 20/22] usb: gadget: printer: init usb_otg_descriptor via usb_otg_descriptor_add

[Li Jun]

Use usb_otg_descriptor_add to allocate and initialize usb_otg_descriptor,
free it while composite unbind.

Signed-off-by: Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
---
 drivers/usb/gadget/legacy/printer.c | 22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/usb/gadget/legacy/printer.c b/drivers/usb/gadget/legacy/printer.c
index 1ce7df1..4611040 100644
--- a/drivers/usb/gadget/legacy/printer.c
+++ b/drivers/usb/gadget/legacy/printer.c
@@ -82,16 +82,7 @@ static struct usb_device_descriptor device_desc = {
 	.bNumConfigurations =	1
 };
 
-static struct usb_otg_descriptor otg_descriptor = {
-	.bLength =              sizeof otg_descriptor,
-	.bDescriptorType =      USB_DT_OTG,
-	.bmAttributes =         USB_OTG_SRP,
-};
-
-static const struct usb_descriptor_header *otg_desc[] = {
-	(struct usb_descriptor_header *) &otg_descriptor,
-	NULL,
-};
+static const struct usb_descriptor_header *otg_desc[2];
 
 /*-------------------------------------------------------------------------*/
 
@@ -136,7 +127,13 @@ static int printer_do_config(struct usb_configuration *c)
 	usb_gadget_set_selfpowered(gadget);
 
 	if (gadget_is_otg(gadget)) {
-		otg_descriptor.bmAttributes |= USB_OTG_HNP;
+		if (!otg_desc[0]) {
+			otg_desc[0] = (struct usb_descriptor_header *)
+				usb_otg_descriptor_add(c->cdev->gadget);
+			if (!otg_desc[0])
+				return -ENOMEM;
+			otg_desc[1] = NULL;
+		}
 		printer_cfg_driver.descriptors = otg_desc;
 		printer_cfg_driver.bmAttributes |= USB_CONFIG_ATT_WAKEUP;
 	}
@@ -196,6 +193,9 @@ static int printer_unbind(struct usb_composite_dev *cdev)
 	usb_put_function(f_printer);
 	usb_put_function_instance(fi_printer);
 
+	kfree(otg_desc[0]);
+	otg_desc[0] = NULL;
+
 	return 0;
 }
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 21/22] usb: gadget: serial: init usb_otg_descriptor via usb_otg_descriptor_add

[Li Jun]

Use usb_otg_descriptor_add to allocate and initialize usb_otg_descriptor,
free it while composite unbind.

Signed-off-by: Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
---
 drivers/usb/gadget/legacy/serial.c | 26 ++++++++++++--------------
 1 file changed, 12 insertions(+), 14 deletions(-)

diff --git a/drivers/usb/gadget/legacy/serial.c b/drivers/usb/gadget/legacy/serial.c
index 8b7528f..20e9f49 100644
--- a/drivers/usb/gadget/legacy/serial.c
+++ b/drivers/usb/gadget/legacy/serial.c
@@ -79,20 +79,7 @@ static struct usb_device_descriptor device_desc = {
 	.bNumConfigurations =	1,
 };
 
-static struct usb_otg_descriptor otg_descriptor = {
-	.bLength =		sizeof otg_descriptor,
-	.bDescriptorType =	USB_DT_OTG,
-
-	/* REVISIT SRP-only hardware is possible, although
-	 * it would not be called "OTG" ...
-	 */
-	.bmAttributes =		USB_OTG_SRP | USB_OTG_HNP,
-};
-
-static const struct usb_descriptor_header *otg_desc[] = {
-	(struct usb_descriptor_header *) &otg_descriptor,
-	NULL,
-};
+static const struct usb_descriptor_header *otg_desc[2];
 
 /*-------------------------------------------------------------------------*/
 
@@ -191,6 +178,13 @@ static int gs_bind(struct usb_composite_dev *cdev)
 	serial_config_driver.iConfiguration = status;
 
 	if (gadget_is_otg(cdev->gadget)) {
+		if (!otg_desc[0]) {
+			otg_desc[0] = (struct usb_descriptor_header *)
+					usb_otg_descriptor_add(cdev->gadget);
+			if (!otg_desc[0])
+				return -ENOMEM;
+			otg_desc[1] = NULL;
+		}
 		serial_config_driver.descriptors = otg_desc;
 		serial_config_driver.bmAttributes |= USB_CONFIG_ATT_WAKEUP;
 	}
@@ -227,6 +221,10 @@ static int gs_unbind(struct usb_composite_dev *cdev)
 		usb_put_function(f_serial[i]);
 		usb_put_function_instance(fi_serial[i]);
 	}
+
+	kfree(otg_desc[0]);
+	otg_desc[0] = NULL;
+
 	return 0;
 }
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 22/22] usb: gadget: zero: init usb_otg_descriptor via usb_otg_descriptor_add

[Li Jun]

Use usb_otg_descriptor_add to allocate and initialize usb_otg_descriptor,
free it while composite unbind.

Signed-off-by: Li Jun <jun.li-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
---
 drivers/usb/gadget/legacy/zero.c | 25 +++++++++++--------------
 1 file changed, 11 insertions(+), 14 deletions(-)

diff --git a/drivers/usb/gadget/legacy/zero.c b/drivers/usb/gadget/legacy/zero.c
index c986e8a..fe8cddb 100644
--- a/drivers/usb/gadget/legacy/zero.c
+++ b/drivers/usb/gadget/legacy/zero.c
@@ -122,20 +122,7 @@ static struct usb_device_descriptor device_desc = {
 };
 
 #ifdef CONFIG_USB_OTG
-static struct usb_otg_descriptor otg_descriptor = {
-	.bLength =		sizeof otg_descriptor,
-	.bDescriptorType =	USB_DT_OTG,
-
-	/* REVISIT SRP-only hardware is possible, although
-	 * it would not be called "OTG" ...
-	 */
-	.bmAttributes =		USB_OTG_SRP | USB_OTG_HNP,
-};
-
-static const struct usb_descriptor_header *otg_desc[] = {
-	(struct usb_descriptor_header *) &otg_descriptor,
-	NULL,
-};
+static const struct usb_descriptor_header *otg_desc[2];
 #else
 #define otg_desc	NULL
 #endif
@@ -341,6 +328,13 @@ static int zero_bind(struct usb_composite_dev *cdev)
 
 	/* support OTG systems */
 	if (gadget_is_otg(cdev->gadget)) {
+		if (!otg_desc[0]) {
+			otg_desc[0] = (struct usb_descriptor_header *)
+					usb_otg_descriptor_add(cdev->gadget);
+			if (!otg_desc[0])
+				return -ENOMEM;
+			otg_desc[1] = NULL;
+		}
 		sourcesink_driver.descriptors = otg_desc;
 		sourcesink_driver.bmAttributes |= USB_CONFIG_ATT_WAKEUP;
 		loopback_driver.descriptors = otg_desc;
@@ -397,6 +391,9 @@ static int zero_unbind(struct usb_composite_dev *cdev)
 	if (!IS_ERR_OR_NULL(func_lb))
 		usb_put_function(func_lb);
 	usb_put_function_instance(func_inst_lb);
+	kfree(otg_desc[0]);
+	otg_desc[0] = NULL;
+
 	return 0;
 }
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html