[U-Boot] [PATCH 10/14] tegra: usb: Add support for USB peripheral

[Simon Glass]

Hi Stephen,

On Mon, Dec 12, 2011 at 10:18 AM, Stephen Warren <swarren at nvidia.com> wrote:
> On 12/08/2011 02:24 PM, Simon Glass wrote:
>> On Wed, Dec 7, 2011 at 3:46 PM, Stephen Warren <swarren at nvidia.com> wrote:
>>> On 12/06/2011 02:23 PM, Simon Glass wrote:
> ...
>>> I think the best implementation would be to enumerate everything solely
>>> based on compatible flags, and allowing "usb start" to accept either an
>>> alias name (which would be fixed) or a DT unit address or node name
>>> (which would be fixed) or a controller index (which might vary based on
>>> enumeration order) to select the controller.
>>>
>>> The next best implementation would be to enumerate solely based on
>>> compatible flags, then sort the list based on alias, thus allowing alias
>>> to cause a static order.
>>>
>>> However, enumerating based on alias, then enumerating based on
>>> compatible flags and adding any missing nodes would be fine.
>>
>> Well ok. Since this is basically a small *addition* to the code
>> (scanning things that don't have an alias), and will have no effect
>> with the device tree as included in this series, I would like to do
>> this as a follow-on patch after the series. I hope you can live with
>> that also?
>
> I suppose it'll have to do.
>
> It's totally the wrong way to go about it though, and will provide a bad
> example that'll probably end up proliferating itself through the code
> since it's the first example.
>
> In other words rather than:
>
> Now: Scan /aliases for USB, add then all.
>
> Later: Scan device nodes for any that weren't in /aliases, add them all
>
> I'd prefer to see:
>
> Now: Scan /aliases for USB, add then all.
>
> Later: Remove all the /aliases scanning code, fix the code to scan all
> child nodes of the SoC node, find all nodes matching the USB compatible
> flag, add them all. While adding a USB controller, check the /alias node
> and honor any alias there if there is one.

OK, perhaps I am thinking too closely about an efficient algorithm as
separate from the required function. This patch series does the 'Now'
but, and the 'Later' bit can be done as you say I think. Issues that
come include someone having an alias for port 2 but not 1, and having
to detect this and move things down at the end. I will need to think
about support in fdtdec to make this easy. That's why I want to do it
later as this patch series is already large and we are well aware of
its limitations in several areas (e.g. there is no way to use port 1
in U-Boot yet).

Regards,
Simon

>
> --
> nvpublic