Re: [RFC PATCH 1/5] drivers : introduce device_path api

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

On 11/27/2012 05:07 AM, the mail apparently from Alan Stern included:
> On Mon, 26 Nov 2012, Greg KH wrote:
>
>> Ah, here's the root of your problem, right?  You need a way for your
>> hardware to tell the kernel that you have a regulator attached to a
>> specific device?  Using the device path and hard-coding it into the
>> kernel is not the proper way to solve this, sorry.  Use some other
>> unique way to describe the hardware, surely the hardware designers
>> couldn't have been that foolish not to provide this [1]?
>
> As far as I know, the kernel has no other way to describe devices.
>
> What about using partial matches?  In this example, instead of doing a
> wildcard match against
>
> 	/platform/usbhs_omap/ehci-omap.0/usb*
>
> (which would fail if the "platform" part of the path changes), suppose
> the string "ehci-omap.0/usb*" could be associated with the usbhs_omap
> component somehow.  Or even better, the string "usb*" could be
> associated with the ehci-omap.0 device.
>
> Then the path-matching code could restrict its attention to that part
> of the path and to devices below the specified one.  Naming changes
> wouldn't be an issue, because the changes themselves would be made in
> the same source file that contains the partial path string.

Yes just dropping the starting / on the match and allowing a fragment to 
match further up the string would solve it.  ehci-omap.0 won't appear 
down any other earlier device paths than the right one.

> On the other hand, this may be way more general than we really need.
> For this particular case, all we need to do is take special action the
> first time any device is registered below the ehci-omap.0 platform
> device.  There ought to be a more direct way to accomplish this,
> without using string pattern-matching or sysfs pathnames (and without
> adding overhead every time a device is added or deleted).

There are no sysfs pathnames involved here at all.  Greg invented that.

> I don't know if such an approach would be sufficiently general for
> future requirements, but it would solve the problem at hand.

We can get a notification about device creation and do things there. 
But the cost of that is like the tuple suggestion, they'll only be able 
to do a fixed thing like operate on regulators.

Actually the targeted device may have arbitrary associated assets like 
generic GPIO to turn on a "flash" for built-in webcam controlled 
out-of-band.  These also can be reached by known names.  And the driver 
may wish to do things with them that are more complex than enable / 
disable or follow logical lifecycle of the hub or whatever.

However when the guidance from Greg is that we can do nothing except 
complain at hardware designers for some reason I failed to quite 
identify, I fear we are moving deckchairs on the titanic.

-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