Re: [PATCH 16/16] ARM: OMAP: omap4panda: Power down the USB PHY and ETH when not in use

[Andy Green <andy.green-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>]

On 11/24/12 23:38, the mail apparently from Alan Stern included:
> On Sat, 24 Nov 2012, Andy Green wrote:
>
>> If we're just looking at fixing the current "magic regulator name"
>> scheme of "hsusb0" so that it can work with abstract devices like any
>> hub / port, we could invert what my original "device path" scheme did.
>>
>> So instead of having a parser (which boiled down quite small, but is
>> complicated by usb%d being the same for different usb drivers), we could
>> just add a helper function that walks the device parents to generate a
>> string representing the device instance.  Like
>>
>> int device_path_generate(struct device *device, char *name, int len);
>>
>> if you called it from the hub driver's probe function (or anything
>> else's probe function) with the new hub device pointer, it might fill
>> name with "ehci1/usbhub1-1/1-1.1" or somesuch.
>
> It's not that simple.  In your example, the very same device might show
> up, after rebooting, as "ehci2/usbhub2-1/2-1.1".  Even if a more or
> less stable name for the controller is used, the bus-number parts of
> the name (the '2's in this example) are always subject to change.  The

Agreed; I pointed this out in a previous mail in this thread already, 
after someone else pointed it out to me some months ago.  Indeed we 
can't use "usb%d", the nth "usb" bus because the ordering of driver 
insertion for the various drivers that can create "usb%d"s breaks the 
determinism of it.

So we can only use in the matching paths a %d that represents the nth 
instance of a device from a specific driver, the "nth ehci host 
controller" for example.

> device_path_generate routine would have to possess special knowledge
> about the USB subsystem's naming scheme to generate a truly stable
> name.

I think there's enough info exposed to do everything generically with no 
access to driver-private info.

When walking struct device "path" one of the things we know at each 
stage is matched driver name.  So we might meet a device of name "usb2" 
but afaik we can trivially also see the matched driver has the name 
"ehci-hcd".

If we can walk a list of "usb%d"s, we can determine that our device is 
the nth device of that type belonging to "ehci-hcd" driver.  That list 
may be nondeterministic in terms of drivers getting modprobed in and 
out, say inserting themselves randomly in the ordering of the list 
before and after we modprobe ehci-hcd, but afaics no amount of insertion 
or removal will change the sequencing of other entries of the same type 
already there (first ehci-hcd one will always appear in the list in the 
same relative order to the second ehci-hcd one).  I think this would be 
reliable for getting as far as "ehci1/" and it's generic code walking 
device path and bus member lists that will work on all buses with that 
problem.

> Presumably the same would hold for other subsystems too.

Although it looks like that method will bounce off of usbhub%d since the 
driver name does not vary, I think it can also be alright.

If we can walk a list of usbhubs finding the ones that have the same 
parent pointer as the parent we arrived at in our walking, we should 
again get an ordinal we can use representing the nth hub on that 
particular host controller.  Afaics that should work for m hub levels 
too if we just filter by an opaque parent device pointer.

Of course the code should not particularly know it's looking at "usb%d" 
or "usbhub" just generic buses or classes or whatever it sees in use 
while walking the device path.  And although there's some walking around 
described, we only do it at probe time and only for devices that are 
interested in getting a deterministic device name to bind assets with.

The above is logically workable I think but to find out if it's 
practical to "walk usbhubs" and so on for me anyway the code needs to be 
attempted.  So I'm curious if you see any flaw already with this scheme.

-Andy

-- 
Andy Green | TI Landing Team Leader
Linaro.org │ Open source software for ARM SoCs | Follow Linaro
http://facebook.com/pages/Linaro/155974581091106  - 
http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html