From mboxrd@z Thu Jan  1 00:00:00 1970
From: Marek Vasut <marex@denx.de>
Date: Sun, 06 Mar 2016 08:44:44 +0100
Subject: [U-Boot] [U-BOOT.V2] usb: xhci: Fix vendor command error if the
	request
In-Reply-To: <CANAwSgQMNuXm-yEu3jR3ck+QcLztXqVcsKrUc1nNARpWeQ-ACw@mail.gmail.com>
References: <1457167393-2559-1-git-send-email-linux.amoon@gmail.com>
 <56DAD183.8080309@denx.de>
 <CANAwSgQMNuXm-yEu3jR3ck+QcLztXqVcsKrUc1nNARpWeQ-ACw@mail.gmail.com>
Message-ID: <56DBDFEC.3070803@denx.de>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

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 at denx.de, swarren at nvidia.com, u-boot at lists.denx.de
>>> Cc: linux.amoon at 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
> 


-- 
Best regards,
Marek Vasut