Hi,
On 16/04/15 09:56, Macpaul Lin wrote:
> Introduce kernel feature CONFIG_USB_OTG20 and related
> gadget_is_otg20() API for supporting OTG20 compliant
> drivers.
> This patch also updated usb_otg_descritpor.
>
> Signed-off-by: Macpaul Lin <macp...@gmail.com>
> ---
> changes for v2:
> - Add USB_OTG_ADP definition in ch9.h.
> changes for v3:
> - ch9.h: replace a tab to space when check #ifdef on CONFIG_USB_OTG20.
> - ch9.h: split structure usb_otg_descriptor into usb_otg_descriptor
> and usb_otg_descriptor20 because some OTG 2.0 hardware can support
> OTG 1.3 and 2.0 by configuration dynamically.
> - gadget.h: fix the description of function gadget_is_otg20().
> - Kconfig: renew and fix the description of OTG 2.0 kernel option.
> changes for v4:
> - fix description of each git commits.
>
> drivers/usb/core/Kconfig | 18 ++++++++++++++++++
> include/linux/usb/gadget.h | 23 +++++++++++++++++++++++
> include/uapi/linux/usb/ch9.h | 10 ++++++++++
> 3 files changed, 51 insertions(+)
>
> diff --git a/drivers/usb/core/Kconfig b/drivers/usb/core/Kconfig
> index cc0ced0..11c7501 100644
> --- a/drivers/usb/core/Kconfig
> +++ b/drivers/usb/core/Kconfig
> @@ -55,6 +55,24 @@ config USB_OTG
> Select this only if your board has Mini-AB/Micro-AB
> connector.
>
> +config USB_OTG20
> + bool "OTG 2.0 support"
> + depends on USB_OTG
> + help
> + There are some incompatibilities in both HNP and SRP between
> + the 1.3 and 2.0 versions of the OTG supplement. Such as timing
> + criterions which might be controlled only by circuit. These may
> + lead to interoperability issues when using these protocols. However,
> + some OTG 2.0 devices can be compatible with those 1.3 devices.
> + If both the gadget hardware and driver support OTG 2.0, the driver
> + should set is_otg20 flag as true when initializing its own usb_gadget
> + structure.
> +
> + This feature is still under developing.
> +
> + Select this only if your board support OTG 2.0's hardware
> + requirements.
> +
This solution will break multi-platform images. e.g. if you want to use the
same kernel image to boot on OTG1.3 and OTG2.0 hardware.
Instead of relying on a kernel config to decide whether the hardware
supports OTG2.0 or not, you must rely on the information provided by the
hardware
itself (e.g. OTG version registers) or platform_data/device tree.
> config USB_OTG_WHITELIST
> bool "Rely on OTG and EH Targeted Peripherals List"
> depends on USB
> diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
> index 4f3dfb7..c63a8db 100644
> --- a/include/linux/usb/gadget.h
> +++ b/include/linux/usb/gadget.h
> @@ -514,6 +514,8 @@ 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.
> + * @is_otg20: True if the USB hardware supports OTG 2.0 specification.
> + * The gadget driver must provide USB OTG 2.0 descriptor.
> * @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.
> @@ -562,6 +564,7 @@ struct usb_gadget {
>
> unsigned sg_supported:1;
> unsigned is_otg:1;
> + unsigned is_otg20:1;
How about adding otg_version instead. That way for otg_30 we don't need another
is otg30 flag. This version number can be translated to bcdOTG in the
OTG descriptor at runtime.
> unsigned is_a_peripheral:1;
> unsigned b_hnp_enable:1;
> unsigned a_hnp_support:1;
> @@ -637,6 +640,22 @@ static inline int gadget_is_otg(struct usb_gadget *g)
> }
>
> /**
> + * gadget_is_otg20 - return true iff the hardware is OTG 2.0-ready
s/iff/if
> + * @g: controller that might supports OTG 2.0 specification.
> + *
> + * This is a runtime test, since kernels with a USB-OTG stack sometimes
> + * run on boards which supports OTG 2.0,
> + */
> +static inline int gadget_is_otg20(struct usb_gadget *g)
> +{
> +#ifdef CONFIG_USB_OTG20
> + return g->is_otg20;
> +#else
> + return 0;
> +#endif
> +}
> +
> +/**
> * usb_gadget_frame_number - returns the current frame number
> * @gadget: controller that reports the frame number
> *
> @@ -835,6 +854,10 @@ static inline int usb_gadget_disconnect(struct
> usb_gadget *gadget)
> * having called usb_gadget_disconnect(), and the USB host stack has
> * initialized.
> *
> + * If gadget->is_otg20 is true, the gadget driver must provide an OTG 2.0
> + * descriptor during enumeration, and related behavior must compliant with
> + * OTG 2.0 specificaiton.
> + *
> * Drivers use hardware-specific knowledge to configure the usb hardware.
> * endpoint addressing is only one of several hardware characteristics that
> * are in descriptors the ep0 implementation returns from setup() calls.
> diff --git a/include/uapi/linux/usb/ch9.h b/include/uapi/linux/usb/ch9.h
> index aa33fd1..1a50d78 100644
> --- a/include/uapi/linux/usb/ch9.h
> +++ b/include/uapi/linux/usb/ch9.h
> @@ -674,9 +674,19 @@ struct usb_otg_descriptor {
> __u8 bmAttributes; /* support for HNP, SRP, etc */
> } __attribute__ ((packed));
>
> +/* USB_DT_OTG (from OTG 2.0 supplement) */
> +struct usb_otg_descriptor20 {
> + __u8 bLength;
> + __u8 bDescriptorType;
> +
> + __u8 bmAttributes; /* support for HNP, SRP, etc */
> + __le16 bcdOTG; /* Support OTG 2.0 */
> +} __attribute__ ((packed));
> +
This can be re-used for OTG 3.0 as well. So i'd suggest to
name the original usb_otg_descriptor to usb_otg_descriptor_legacy
and name the new one to 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 */
It would be nice to add OTG 3.0 definitions as well
#define USB_OTG_RSP (1 << 3) /* supports RSP */
>
> /*-------------------------------------------------------------------------*/
>
>
cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
