Re: [PATCH v4 1/5] usb: introduce OTG 2.0 related kernel feature and API.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Peter,

2015-04-20 13:30 GMT+08:00 Peter Chen <peter.chen@xxxxxxxxxxxxx>:
> On Thu, Apr 16, 2015 at 02:56:59PM +0800, 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.
[Deleted]
>
> Do we really need another usb_otg_descritor20, how about define
> otg descriptor like below:
>
> struct usb_otg_descriptor {
>         __u8  bLength;
>         __u8  bDescriptorType;
>
>         __u8  bmAttributes;     /* support for HNP, SRP, etc */
> #ifdef CONFIG_USB_OTG20
>         __le16 bcdOTG;          /* OTG release number */
> #endif
>
> } __attribute__ ((packed));

This is because some OTG-2.0 compatible OTG hardware might also
compatible with OTG-1.3.
These kind of hardware may have dynamic detection compatibility and
could adjust their response timing at electrical level.
These could be adjusted by register configuration after re-enumeration.
Hence we may need to prepare OTG 1.3 and OTG 2.0 descriptors for these
hardware which can do dynamic
detection when the other A/B device will be connected.

> At gadget driver, assign otg descriptor like below:
>
> 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,
> #ifdef CONFIG_USB_OTG20
>                 .bcdOTG =  cpu_to_le16(0x0200),
> #endif
>         },
>         NULL,
> };

And these array should be specified by gadget's hardware driver by
querying included their capabilities.
Instead of hard-coded capabilities.
Like Li Jun's previous comment,

"After you introduce some flags for controller to decide if HNP/SRP/ADP can be
supported, this setting in all gadget drivers should be override
according to those
flags too, otherwise there will be possible mismatch between the OTG descriptor
within config(like above setting) and the response for getting OTG descriptor
request(your patch 3 does in composite.c)."

Hence this kind of descriptor should be dynamic queried from gadget's
hardware driver instead
hard-code at compiling stage.

-- 
Best regards,
Macpaul Lin
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux