diff mbox

[U-Boot,U-BOOT.V2] usb: xhci: Fix vendor command error if the request

Message ID 1457167393-2559-1-git-send-email-linux.amoon@gmail.com
State Deferred
Delegated to: Marek Vasut
Headers show

Commit Message

Anand Moon March 5, 2016, 8:43 a.m. UTC 
From: Ted Chen <tedchen@realtek.com>

From: Ted Chen <tedchen@realtek.com>

type is USB_REQ_SET_ADDRESS or USB_REQ_SET_CONFIGURATION.
To: marex@denx.de, swarren@nvidia.com, u-boot@lists.denx.de
Cc: linux.amoon@gmail.com, Ted Chen <tedchen@realtek.com>

Add a condition of set_address and set_configuration to check
if the request is standardized.

Signed-off-by: Ted Chen <tedchen@realtek.com>
---
Resend this patch it some how got missed
Changes since v1: None.

Tested on Odroid XU4: with Ethernet USB3.0 RT8153-VB
---
 drivers/usb/host/xhci.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

Comments

Marek Vasut March 5, 2016, 12:30 p.m. UTC | #1 
On 03/05/2016 09:43 AM, Anand Moon wrote:
> From: Ted Chen <tedchen@realtek.com>
> 
> From: Ted Chen <tedchen@realtek.com>
> 
> type is USB_REQ_SET_ADDRESS or USB_REQ_SET_CONFIGURATION.
> To: marex@denx.de, swarren@nvidia.com, u-boot@lists.denx.de
> Cc: linux.amoon@gmail.com, Ted Chen <tedchen@realtek.com>
> 
> Add a condition of set_address and set_configuration to check
> if the request is standardized.

Can you please rephrase the commit message ? It's really hard to
understand. I believe such a patch will be needed for ehci as well,
can you prepare one ?

> Signed-off-by: Ted Chen <tedchen@realtek.com>
> ---
> Resend this patch it some how got missed
> Changes since v1: None.
> 
> Tested on Odroid XU4: with Ethernet USB3.0 RT8153-VB
> ---
>  drivers/usb/host/xhci.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
> index ca598aa..cb8a04b 100644
> --- a/drivers/usb/host/xhci.c
> +++ b/drivers/usb/host/xhci.c
> @@ -941,10 +941,12 @@ static int _xhci_submit_control_msg(struct usb_device *udev, unsigned long pipe,
>  	if (usb_pipedevice(pipe) == ctrl->rootdev)
>  		return xhci_submit_root(udev, pipe, buffer, setup);
>  
> -	if (setup->request == USB_REQ_SET_ADDRESS)
> +	if (setup->request == USB_REQ_SET_ADDRESS &&
> +	   (setup->requesttype & USB_TYPE_MASK) == USB_TYPE_STANDARD)
>  		return xhci_address_device(udev, root_portnr);
>  
> -	if (setup->request == USB_REQ_SET_CONFIGURATION) {
> +	if (setup->request == USB_REQ_SET_CONFIGURATION &&
> +	   (setup->requesttype & USB_TYPE_MASK) == USB_TYPE_STANDARD) {
>  		ret = xhci_set_configuration(udev);
>  		if (ret) {
>  			puts("Failed to configure xHCI endpoint\n");
> 

What happens to the non-standard requests ?
Anand Moon March 5, 2016, 5:53 p.m. UTC | #2 
Hi Marek,

On 5 March 2016 at 18:00, Marek Vasut <marex@denx.de> wrote:
> On 03/05/2016 09:43 AM, Anand Moon wrote:
>> From: Ted Chen <tedchen@realtek.com>
>>
>> From: Ted Chen <tedchen@realtek.com>
>>
>> type is USB_REQ_SET_ADDRESS or USB_REQ_SET_CONFIGURATION.
>> To: marex@denx.de, swarren@nvidia.com, u-boot@lists.denx.de
>> Cc: linux.amoon@gmail.com, Ted Chen <tedchen@realtek.com>
>>
>> Add a condition of set_address and set_configuration to check
>> if the request is standardized.
>
> Can you please rephrase the commit message ? It's really hard to
> understand. I believe such a patch will be needed for ehci as well,
> can you prepare one ?

I could not find any need for such check in ehci-hcd driver.

Sorry for this mess in commit message, I completely missed formatting
the statement
because of it got warped up in the message
Will send this message again with proper commit message.

>
>> Signed-off-by: Ted Chen <tedchen@realtek.com>
>> ---
>> Resend this patch it some how got missed
>> Changes since v1: None.
>>
>> Tested on Odroid XU4: with Ethernet USB3.0 RT8153-VB
>> ---
>>  drivers/usb/host/xhci.c | 6 ++++--
>>  1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
>> index ca598aa..cb8a04b 100644
>> --- a/drivers/usb/host/xhci.c
>> +++ b/drivers/usb/host/xhci.c
>> @@ -941,10 +941,12 @@ static int _xhci_submit_control_msg(struct usb_device *udev, unsigned long pipe,
>>       if (usb_pipedevice(pipe) == ctrl->rootdev)
>>               return xhci_submit_root(udev, pipe, buffer, setup);
>>
>> -     if (setup->request == USB_REQ_SET_ADDRESS)
>> +     if (setup->request == USB_REQ_SET_ADDRESS &&
>> +        (setup->requesttype & USB_TYPE_MASK) == USB_TYPE_STANDARD)
>>               return xhci_address_device(udev, root_portnr);
>>
>> -     if (setup->request == USB_REQ_SET_CONFIGURATION) {
>> +     if (setup->request == USB_REQ_SET_CONFIGURATION &&
>> +        (setup->requesttype & USB_TYPE_MASK) == USB_TYPE_STANDARD) {
>>               ret = xhci_set_configuration(udev);
>>               if (ret) {
>>                       puts("Failed to configure xHCI endpoint\n");
>>
>
> What happens to the non-standard requests ?
>
Device will not able to detect leaving message
"scanning usb for ethernet devices... Non standard request in USB
vendor command"
> --
> Best regards,
> Marek Vasut

Here is the modified commit message

"Add a condition of set_address and set_configuration to check
if the requesttype is of standardized in the USB vendor request
so that usb device is detected"

Do you agree with this modified commit statement.

Best regards,
-Anand Moon
Marek Vasut March 6, 2016, 7:44 a.m. UTC | #3 
On 03/05/2016 06:53 PM, Anand Moon wrote:
> Hi Marek,

Hi!

> On 5 March 2016 at 18:00, Marek Vasut <marex@denx.de> wrote:
>> On 03/05/2016 09:43 AM, Anand Moon wrote:
>>> From: Ted Chen <tedchen@realtek.com>
>>>
>>> From: Ted Chen <tedchen@realtek.com>
>>>
>>> type is USB_REQ_SET_ADDRESS or USB_REQ_SET_CONFIGURATION.
>>> To: marex@denx.de, swarren@nvidia.com, u-boot@lists.denx.de
>>> Cc: linux.amoon@gmail.com, Ted Chen <tedchen@realtek.com>
>>>
>>> Add a condition of set_address and set_configuration to check
>>> if the request is standardized.
>>
>> Can you please rephrase the commit message ? It's really hard to
>> understand. I believe such a patch will be needed for ehci as well,
>> can you prepare one ?
> 
> I could not find any need for such check in ehci-hcd driver.

Please explain why this is not needed.

> Sorry for this mess in commit message, I completely missed formatting
> the statement
> because of it got warped up in the message
> Will send this message again with proper commit message.

Yes, the message is complete chaos.

>>
>>> Signed-off-by: Ted Chen <tedchen@realtek.com>
>>> ---
>>> Resend this patch it some how got missed
>>> Changes since v1: None.
>>>
>>> Tested on Odroid XU4: with Ethernet USB3.0 RT8153-VB
>>> ---
>>>  drivers/usb/host/xhci.c | 6 ++++--
>>>  1 file changed, 4 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
>>> index ca598aa..cb8a04b 100644
>>> --- a/drivers/usb/host/xhci.c
>>> +++ b/drivers/usb/host/xhci.c
>>> @@ -941,10 +941,12 @@ static int _xhci_submit_control_msg(struct usb_device *udev, unsigned long pipe,
>>>       if (usb_pipedevice(pipe) == ctrl->rootdev)
>>>               return xhci_submit_root(udev, pipe, buffer, setup);
>>>
>>> -     if (setup->request == USB_REQ_SET_ADDRESS)
>>> +     if (setup->request == USB_REQ_SET_ADDRESS &&
>>> +        (setup->requesttype & USB_TYPE_MASK) == USB_TYPE_STANDARD)
>>>               return xhci_address_device(udev, root_portnr);
>>>
>>> -     if (setup->request == USB_REQ_SET_CONFIGURATION) {
>>> +     if (setup->request == USB_REQ_SET_CONFIGURATION &&
>>> +        (setup->requesttype & USB_TYPE_MASK) == USB_TYPE_STANDARD) {
>>>               ret = xhci_set_configuration(udev);
>>>               if (ret) {
>>>                       puts("Failed to configure xHCI endpoint\n");
>>>
>>
>> What happens to the non-standard requests ?
>>
> Device will not able to detect leaving message
> "scanning usb for ethernet devices... Non standard request in USB
> vendor command"

Let me re-phrase, how are the non-standard requests handled ?

>> --
>> Best regards,
>> Marek Vasut
> 
> Here is the modified commit message
> 
> "Add a condition of set_address and set_configuration to check
> if the requesttype is of standardized in the USB vendor request
> so that usb device is detected"

Add test into xhci_submit_control_message for usb requesttype in USB
vendor request being of standardized type. This fixes detection of
certain USB fixes, for example <fill here>.

> Do you agree with this modified commit statement.
> 
> Best regards,
> -Anand Moon
>
Anand Moon March 13, 2016, 9:53 a.m. UTC | #4 
Hi Marek

Sorry for late replay.

On 6 March 2016 at 13:14, Marek Vasut <marex@denx.de> wrote:
> On 03/05/2016 06:53 PM, Anand Moon wrote:
>> Hi Marek,
>
> Hi!
>
>> On 5 March 2016 at 18:00, Marek Vasut <marex@denx.de> wrote:
>>> On 03/05/2016 09:43 AM, Anand Moon wrote:
>>>> From: Ted Chen <tedchen@realtek.com>
>>>>
>>>> From: Ted Chen <tedchen@realtek.com>
>>>>
>>>> type is USB_REQ_SET_ADDRESS or USB_REQ_SET_CONFIGURATION.
>>>> To: marex@denx.de, swarren@nvidia.com, u-boot@lists.denx.de
>>>> Cc: linux.amoon@gmail.com, Ted Chen <tedchen@realtek.com>
>>>>
>>>> Add a condition of set_address and set_configuration to check
>>>> if the request is standardized.
>>>
>>> Can you please rephrase the commit message ? It's really hard to
>>> understand. I believe such a patch will be needed for ehci as well,
>>> can you prepare one ?
>>
>> I could not find any need for such check in ehci-hcd driver.
>
> Please explain why this is not needed.

I had give this a try but it failed to detect device connected to usb
device connected to USB 2.0 port.
But I will work on this and send a different patch.

>
>> Sorry for this mess in commit message, I completely missed formatting
>> the statement
>> because of it got warped up in the message
>> Will send this message again with proper commit message.
>
> Yes, the message is complete chaos.
>
>>>
>>>> Signed-off-by: Ted Chen <tedchen@realtek.com>
>>>> ---
>>>> Resend this patch it some how got missed
>>>> Changes since v1: None.
>>>>
>>>> Tested on Odroid XU4: with Ethernet USB3.0 RT8153-VB
>>>> ---
>>>>  drivers/usb/host/xhci.c | 6 ++++--
>>>>  1 file changed, 4 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
>>>> index ca598aa..cb8a04b 100644
>>>> --- a/drivers/usb/host/xhci.c
>>>> +++ b/drivers/usb/host/xhci.c
>>>> @@ -941,10 +941,12 @@ static int _xhci_submit_control_msg(struct usb_device *udev, unsigned long pipe,
>>>>       if (usb_pipedevice(pipe) == ctrl->rootdev)
>>>>               return xhci_submit_root(udev, pipe, buffer, setup);
>>>>
>>>> -     if (setup->request == USB_REQ_SET_ADDRESS)
>>>> +     if (setup->request == USB_REQ_SET_ADDRESS &&
>>>> +        (setup->requesttype & USB_TYPE_MASK) == USB_TYPE_STANDARD)
>>>>               return xhci_address_device(udev, root_portnr);
>>>>
>>>> -     if (setup->request == USB_REQ_SET_CONFIGURATION) {
>>>> +     if (setup->request == USB_REQ_SET_CONFIGURATION &&
>>>> +        (setup->requesttype & USB_TYPE_MASK) == USB_TYPE_STANDARD) {
>>>>               ret = xhci_set_configuration(udev);
>>>>               if (ret) {
>>>>                       puts("Failed to configure xHCI endpoint\n");
>>>>
>>>
>>> What happens to the non-standard requests ?
>>>
>> Device will not able to detect leaving message
>> "scanning usb for ethernet devices... Non standard request in USB
>> vendor command"
>
> Let me re-phrase, how are the non-standard requests handled ?

Note: With this patch such request are ignored.

I have tried various way to handle this situation but nothing work perfectly.

>>> --
>>> Best regards,
>>> Marek Vasut
>>
>> Here is the modified commit message
>>
>> "Add a condition of set_address and set_configuration to check
>> if the requesttype is of standardized in the USB vendor request
>> so that usb device is detected"
>
> Add test into xhci_submit_control_message for usb requesttype in USB
> vendor request being of standardized type. This fixes detection of
> certain USB fixes, for example <fill here>.
>
I will update the commit message.
>> Do you agree with this modified commit statement.
>>
>> Best regards,
>> -Anand Moon
>>
>
>
> --
> Best regards,
> Marek Vasut

OdroidXU4 development board 2 USB 3 port, 1 usb port and RTL8153
Ethernet connected to USB 3.0.
--------------------------------------------------------------------------------------------------------------------------------------------------

U-Boot 2016.03-rc3-01571-g76aab9e-dirty (Mar 13 2016 - 19:43:54 +1030)
for ODROID-XU3

CPU:   Exynos5422 @ 800 MHz
Model: Odroid XU3 based on EXYNOS5422
Board: Odroid XU3 based on EXYNOS5422
Type:  xu4
DRAM:  2 GiB
MMC:   EXYNOS DWMMC: 0, EXYNOS DWMMC: 1
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Net:   No ethernet found.
Hit any key to stop autoboot:  0
ODROID-XU3 #
ODROID-XU3 #
ODROID-XU3 #
ODROID-XU3 # usb start
starting USB...
USB0:   USB EHCI 1.00
USB1:   Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.00
USB2:   Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.00
scanning bus 0 for devices... 1 USB Device(s) found
scanning bus 1 for devices... 2 USB Device(s) found
scanning bus 2 for devices... 2 USB Device(s) found
       scanning usb for ethernet devices... 1 Ethernet Device(s) found
ODROID-XU3 # usb info
1: Hub,  USB Revision 2.0
 - u-boot EHCI Host Controller
 - Class: Hub
 - PacketSize: 64  Configurations: 1
 - Vendor: 0x0000  Product 0x0000 Version 1.0
   Configuration: 1
   - Interfaces: 1 Self Powered 0mA
     Interface: 0
     - Alternate Setting 0, Endpoints: 1
     - Class Hub
     - Endpoint 1 In Interrupt MaxPacket 8 Interval 255ms

1: Hub,  USB Revision 3.0
 - U-Boot XHCI Host Controller
 - Class: Hub
 - PacketSize: 9  Configurations: 1
 - Vendor: 0x0000  Product 0x0000 Version 1.0
   Configuration: 1
   - Interfaces: 1 Self Powered 0mA
     Interface: 0
     - Alternate Setting 0, Endpoints: 1
     - Class Hub
     - Endpoint 1 In Interrupt MaxPacket 8 Interval 255ms

2: Hub,  USB Revision 2.10
 - GenesysLogic USB2.0 Hub
 - Class: Hub
 - PacketSize: 64  Configurations: 1
 - Vendor: 0x05e3  Product 0x0610 Version 146.34
   Configuration: 1
   - Interfaces: 1 Self Powered Remote Wakeup 100mA
     Interface: 0
     - Alternate Setting 0, Endpoints: 1
     - Class Hub
     - Endpoint 1 In Interrupt MaxPacket 1 Interval 12ms
     - Endpoint 1 In Interrupt MaxPacket 1 Interval 12ms

1: Hub,  USB Revision 3.0
 - U-Boot XHCI Host Controller
 - Class: Hub
 - PacketSize: 9  Configurations: 1
 - Vendor: 0x0000  Product 0x0000 Version 1.0
   Configuration: 1
   - Interfaces: 1 Self Powered 0mA
     Interface: 0
     - Alternate Setting 0, Endpoints: 1
     - Class Hub
     - Endpoint 1 In Interrupt MaxPacket 8 Interval 255ms

2: Vendor specific,  USB Revision 2.10
 - Realtek USB 10/100/1000 LAN 000001000000
 - Class: (from Interface) Vendor specific
 - PacketSize: 64  Configurations: 2
 - Vendor: 0x0bda  Product 0x8153 Version 48.0
   Configuration: 1
   - Interfaces: 1 Bus Powered Remote Wakeup 180mA
     Interface: 0
     - Alternate Setting 0, Endpoints: 3
     - Class Vendor specific
     - Endpoint 1 In Bulk MaxPacket 512
     - Endpoint 2 Out Bulk MaxPacket 512
     - Endpoint 3 In Interrupt MaxPacket 2 Interval 8ms

ODROID-XU3 #

Best Regards
-Anand Moon
Marek Vasut March 14, 2016, 5:26 p.m. UTC | #5 
On 03/13/2016 10:53 AM, Anand Moon wrote:
> Hi Marek

Hi!

> Sorry for late replay.
> 
> On 6 March 2016 at 13:14, Marek Vasut <marex@denx.de> wrote:
>> On 03/05/2016 06:53 PM, Anand Moon wrote:
>>> Hi Marek,
>>
>> Hi!
>>
>>> On 5 March 2016 at 18:00, Marek Vasut <marex@denx.de> wrote:
>>>> On 03/05/2016 09:43 AM, Anand Moon wrote:
>>>>> From: Ted Chen <tedchen@realtek.com>
>>>>>
>>>>> From: Ted Chen <tedchen@realtek.com>
>>>>>
>>>>> type is USB_REQ_SET_ADDRESS or USB_REQ_SET_CONFIGURATION.
>>>>> To: marex@denx.de, swarren@nvidia.com, u-boot@lists.denx.de
>>>>> Cc: linux.amoon@gmail.com, Ted Chen <tedchen@realtek.com>
>>>>>
>>>>> Add a condition of set_address and set_configuration to check
>>>>> if the request is standardized.
>>>>
>>>> Can you please rephrase the commit message ? It's really hard to
>>>> understand. I believe such a patch will be needed for ehci as well,
>>>> can you prepare one ?
>>>
>>> I could not find any need for such check in ehci-hcd driver.
>>
>> Please explain why this is not needed.
> 
> I had give this a try but it failed to detect device connected to usb
> device connected to USB 2.0 port.
> But I will work on this and send a different patch.

So USB 2.0 code does need similar fix ?

>>> Sorry for this mess in commit message, I completely missed formatting
>>> the statement
>>> because of it got warped up in the message
>>> Will send this message again with proper commit message.
>>
>> Yes, the message is complete chaos.
>>
>>>>
>>>>> Signed-off-by: Ted Chen <tedchen@realtek.com>
>>>>> ---
>>>>> Resend this patch it some how got missed
>>>>> Changes since v1: None.
>>>>>
>>>>> Tested on Odroid XU4: with Ethernet USB3.0 RT8153-VB
>>>>> ---
>>>>>  drivers/usb/host/xhci.c | 6 ++++--
>>>>>  1 file changed, 4 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
>>>>> index ca598aa..cb8a04b 100644
>>>>> --- a/drivers/usb/host/xhci.c
>>>>> +++ b/drivers/usb/host/xhci.c
>>>>> @@ -941,10 +941,12 @@ static int _xhci_submit_control_msg(struct usb_device *udev, unsigned long pipe,
>>>>>       if (usb_pipedevice(pipe) == ctrl->rootdev)
>>>>>               return xhci_submit_root(udev, pipe, buffer, setup);
>>>>>
>>>>> -     if (setup->request == USB_REQ_SET_ADDRESS)
>>>>> +     if (setup->request == USB_REQ_SET_ADDRESS &&
>>>>> +        (setup->requesttype & USB_TYPE_MASK) == USB_TYPE_STANDARD)
>>>>>               return xhci_address_device(udev, root_portnr);
>>>>>
>>>>> -     if (setup->request == USB_REQ_SET_CONFIGURATION) {
>>>>> +     if (setup->request == USB_REQ_SET_CONFIGURATION &&
>>>>> +        (setup->requesttype & USB_TYPE_MASK) == USB_TYPE_STANDARD) {
>>>>>               ret = xhci_set_configuration(udev);
>>>>>               if (ret) {
>>>>>                       puts("Failed to configure xHCI endpoint\n");
>>>>>
>>>>
>>>> What happens to the non-standard requests ?
>>>>
>>> Device will not able to detect leaving message
>>> "scanning usb for ethernet devices... Non standard request in USB
>>> vendor command"
>>
>> Let me re-phrase, how are the non-standard requests handled ?
> 
> Note: With this patch such request are ignored.

This should be stated in the commit message for sure, thanks!

> I have tried various way to handle this situation but nothing work perfectly.

Got it.

Can you just update the commit message, send a V3 and let me pick it up?
Thanks!

>>>> --
>>>> Best regards,
>>>> Marek Vasut
>>>
>>> Here is the modified commit message
>>>
>>> "Add a condition of set_address and set_configuration to check
>>> if the requesttype is of standardized in the USB vendor request
>>> so that usb device is detected"
>>
>> Add test into xhci_submit_control_message for usb requesttype in USB
>> vendor request being of standardized type. This fixes detection of
>> certain USB fixes, for example <fill here>.
>>
> I will update the commit message.
>>> Do you agree with this modified commit statement.
>>>
>>> Best regards,
>>> -Anand Moon
>>>
>>
>>
>> --
>> Best regards,
>> Marek Vasut
> 
> OdroidXU4 development board 2 USB 3 port, 1 usb port and RTL8153
> Ethernet connected to USB 3.0.
> --------------------------------------------------------------------------------------------------------------------------------------------------
> 
> U-Boot 2016.03-rc3-01571-g76aab9e-dirty (Mar 13 2016 - 19:43:54 +1030)
> for ODROID-XU3
> 
> CPU:   Exynos5422 @ 800 MHz
> Model: Odroid XU3 based on EXYNOS5422
> Board: Odroid XU3 based on EXYNOS5422
> Type:  xu4
> DRAM:  2 GiB
> MMC:   EXYNOS DWMMC: 0, EXYNOS DWMMC: 1
> *** Warning - bad CRC, using default environment
> 
> In:    serial
> Out:   serial
> Err:   serial
> Net:   No ethernet found.
> Hit any key to stop autoboot:  0
> ODROID-XU3 #
> ODROID-XU3 #
> ODROID-XU3 #
> ODROID-XU3 # usb start
> starting USB...
> USB0:   USB EHCI 1.00
> USB1:   Register 2000140 NbrPorts 2
> Starting the controller
> USB XHCI 1.00
> USB2:   Register 2000140 NbrPorts 2
> Starting the controller
> USB XHCI 1.00
> scanning bus 0 for devices... 1 USB Device(s) found
> scanning bus 1 for devices... 2 USB Device(s) found
> scanning bus 2 for devices... 2 USB Device(s) found
>        scanning usb for ethernet devices... 1 Ethernet Device(s) found
> ODROID-XU3 # usb info
> 1: Hub,  USB Revision 2.0
>  - u-boot EHCI Host Controller
>  - Class: Hub
>  - PacketSize: 64  Configurations: 1
>  - Vendor: 0x0000  Product 0x0000 Version 1.0
>    Configuration: 1
>    - Interfaces: 1 Self Powered 0mA
>      Interface: 0
>      - Alternate Setting 0, Endpoints: 1
>      - Class Hub
>      - Endpoint 1 In Interrupt MaxPacket 8 Interval 255ms
> 
> 1: Hub,  USB Revision 3.0
>  - U-Boot XHCI Host Controller
>  - Class: Hub
>  - PacketSize: 9  Configurations: 1
>  - Vendor: 0x0000  Product 0x0000 Version 1.0
>    Configuration: 1
>    - Interfaces: 1 Self Powered 0mA
>      Interface: 0
>      - Alternate Setting 0, Endpoints: 1
>      - Class Hub
>      - Endpoint 1 In Interrupt MaxPacket 8 Interval 255ms
> 
> 2: Hub,  USB Revision 2.10
>  - GenesysLogic USB2.0 Hub
>  - Class: Hub
>  - PacketSize: 64  Configurations: 1
>  - Vendor: 0x05e3  Product 0x0610 Version 146.34
>    Configuration: 1
>    - Interfaces: 1 Self Powered Remote Wakeup 100mA
>      Interface: 0
>      - Alternate Setting 0, Endpoints: 1
>      - Class Hub
>      - Endpoint 1 In Interrupt MaxPacket 1 Interval 12ms
>      - Endpoint 1 In Interrupt MaxPacket 1 Interval 12ms
> 
> 1: Hub,  USB Revision 3.0
>  - U-Boot XHCI Host Controller
>  - Class: Hub
>  - PacketSize: 9  Configurations: 1
>  - Vendor: 0x0000  Product 0x0000 Version 1.0
>    Configuration: 1
>    - Interfaces: 1 Self Powered 0mA
>      Interface: 0
>      - Alternate Setting 0, Endpoints: 1
>      - Class Hub
>      - Endpoint 1 In Interrupt MaxPacket 8 Interval 255ms
> 
> 2: Vendor specific,  USB Revision 2.10
>  - Realtek USB 10/100/1000 LAN 000001000000
>  - Class: (from Interface) Vendor specific
>  - PacketSize: 64  Configurations: 2
>  - Vendor: 0x0bda  Product 0x8153 Version 48.0
>    Configuration: 1
>    - Interfaces: 1 Bus Powered Remote Wakeup 180mA
>      Interface: 0
>      - Alternate Setting 0, Endpoints: 3
>      - Class Vendor specific
>      - Endpoint 1 In Bulk MaxPacket 512
>      - Endpoint 2 Out Bulk MaxPacket 512
>      - Endpoint 3 In Interrupt MaxPacket 2 Interval 8ms
> 
> ODROID-XU3 #
> 
> Best Regards
> -Anand Moon
> _______________________________________________
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
diff mbox

Patch

diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index ca598aa..cb8a04b 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -941,10 +941,12 @@  static int _xhci_submit_control_msg(struct usb_device *udev, unsigned long pipe,
 	if (usb_pipedevice(pipe) == ctrl->rootdev)
 		return xhci_submit_root(udev, pipe, buffer, setup);
 
-	if (setup->request == USB_REQ_SET_ADDRESS)
+	if (setup->request == USB_REQ_SET_ADDRESS &&
+	   (setup->requesttype & USB_TYPE_MASK) == USB_TYPE_STANDARD)
 		return xhci_address_device(udev, root_portnr);
 
-	if (setup->request == USB_REQ_SET_CONFIGURATION) {
+	if (setup->request == USB_REQ_SET_CONFIGURATION &&
+	   (setup->requesttype & USB_TYPE_MASK) == USB_TYPE_STANDARD) {
 		ret = xhci_set_configuration(udev);
 		if (ret) {
 			puts("Failed to configure xHCI endpoint\n");