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

Simon Glass sjg at chromium.org
Fri Jul 7 03:57:35 UTC 2017


Hi Marek,

On 27 June 2017 at 03:31, 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.

One idea is to set a deadline (e.g. end of year) for all boards to
move to DM_USB, and turn off USB for those that don't make it? In some
areas the old code is quite a significant impediment to progress /
productivity.

>
>>> 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. ;)

Regards,
Simon


More information about the U-Boot mailing list