[U-Boot] [PATCH 10/16] usb: xhci: Program 'route string' in the input slot context

[Bin Meng]

Hi Marek,

On Tue, Jun 27, 2017 at 5:31 PM, Marek Vasut <marex at denx.de> wrote:
> On 06/27/2017 07:23 AM, Stefan Roese wrote:
>> Hi Bin,
>>
>> On 27.06.2017 02:01, Bin Meng wrote:
>>> On Tue, Jun 27, 2017 at 2:07 AM, Marek Vasut <marex at denx.de> wrote:
>>>> On 06/24/2017 03:57 AM, Bin Meng wrote:
>>>>> Hi Marek,
>>>>>
>>>>> On Sat, Jun 24, 2017 at 2:02 AM, Marek Vasut <marex at denx.de> wrote:
>>>>>> On 06/23/2017 11:54 AM, Bin Meng wrote:
>>>>>>> xHCI spec says: the values of the 'route string' field shall be
>>>>>>> initialized by the first 'Address Device' command issued to a
>>>>>>> device slot, and shall not be modified by any other command.
>>>>>>>
>>>>>>> So far U-Boot does not program this field, and it does not prevent
>>>>>>> SS device directly attached to root port, or HS device behind an HS
>>>>>>> hub, from working, due to the fact that 'route string' is used by
>>>>>>> the xHC to target SS packets. But in order to enumerate devices
>>>>>>> behind an SS hub, this field must be programmed.
>>>>>>>
>>>>>>> With this commit and along with previous commits, now SS & HS devices
>>>>>>> attached to a USB 3.0 hub can be enumerated by U-Boot.
>>>>>>>
>>>>>>> As usual, this new feature is only available when DM is on.
>>>>>>
>>>>>> Great, but I really dislike the ifdef pollution, so this needs to be
>>>>>> sorted out.
>>>>>
>>>>> The ifdef was needed due to it calls DM APIs or access DM udevice. I
>>>>> have no intention to add a new feature to the non-DM driver.
>>>>
>>>> But then this creates a massive disparity, it's like we're growing two
>>>> USB stacks.
>>>>
>>>
>>> Yep, unfortunately. But if we continue adding new features/fixes to
>>> the old non-DM stuff, I am not sure how this can encourage people to
>>> switch to DM.
>>
>> Correct. We definitely don't want to add new features to non-DM
>> drivers / IF, if this is non-trivial.
>
> Fine, but we also don't want to grow two distinct stacks with a boatload
> of ifdefs all over the place. That's a nightmare to maintain.
> I think I mentioned that already, but I'd be far more accepting to this
> solution if we could at least keep the added ifdefs to minimum and
> somehow keep them in one place instead of adding them all over the code.
>

OK, I will see if I can do some additional work to remove the #ifdefs
or limit them in a minimum way, even if that means I have to bring
(part of) this feature to the non-DM driver.

>>> Maybe I can check all boards that use xHCI to see if
>>> they are switched to DM?
>>
>> xHCI is still quite new in U-Boot, so I would expect that all
>> platforms using it, are using DM or at least not far away from using
>> it. Yes, please check all xHCI "users", if they use DM. Then we
>> know if and which users need some "persuasion" to switch over to
>> DM soon. ;)

[snip]

Regards,
Bin