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

[Andy Green <andy.green@linaro.org>]

On 11/27/2012 03:22 AM, the mail apparently from Greg KH included:
> On Mon, Nov 26, 2012 at 12:45:34PM +0000, Andy Green wrote:
>> This adds a small optional API into drivers/base which deals with generating,
>> matching and registration of wildcard device paths.
>>
>> >From a struct device * you can generate a string like
>>
>>   /platform/usbhs_omap/ehci-omap.0/usb1/1-1
>>
>> which enapsulates the path of the device's connection to the board.
>>
>> These can be used to match up other assets, for example struct regulators,
>> that have been registed elsewhere with a device instance that is probed
>> asynchronously from the other board assets.
>>
>> If your device is on a bus, as it probably is, the device path will feature
>> redundant bus indexes that do not contain information about the connectivity.
>
> Huh?  A bus "index" does show the connectivity, well, one type of
> connectivity, but perhaps it's not the one _you_ happen to want at the
> moment.  Which is fine, but I don't see why you want to try to figure
> this out using the device path in the first place, surely you have some
> other way that the hardware can describe itself to the kernel as to
> where it needs to be hooked up to?

The bus index is like a counter, it shows logical connectivity inside 
Linux that isn't repeatable and doesn't reflect hardware routing 
information directly.

>> For example if more than one driver can generate devices on the same bus,
>> then the ordering of device probing will change the path, despite the
>> connectivity remains the same.
>
> That's an expected thing, I don't see the issue here.

Alan brought up in a thread here the last days, "wouldn't it be nice if 
we could arbitrarily bind regulators to asynchronously probed objects", 
and after discussion proposed this wildcard matching scheme to mask 
these generated bus numbers.

>> For that reason, to get a deterministic path for matching, wildcards are
>> allowed.  If your target device has the path
>
> Wait, no, why would you want a deterministic path and have that
> hard-coded into the kernel here?  You can't rely on that any more than
> userspace can, so let's not start making the mistake that lots of
> userspace programmers originally did when they started using sysfs
> please.  We have learned from our past mistakes.

I guess that is a fair point.  I was going to say that it's no different 
than using any kernel API in code, which history proves is very mutable; 
people deal with it by changing the usages as they change the API 
definition.  But it's complicated a bit by DTs meant to be more stable 
and these paths would turn up in the DT.

In "platform" case though, a heuristic that leaving off the initial / 
and allowing matches anywhere along the path then to the end would get 
around it.

>>   /platform/usbhs_omap/ehci-omap.0/usb1/1-1
>>
>> generated, in the asset you wish to match with it you can instead use
>>
>> /platform/usbhs_omap/ehci-omap.0/usb*/*-1
>>
>> in order to only leave the useful, invariant parts of the path to match
>> against.
>>
>> To avoid having to adapt every kind of "search by string" api to also use
>> the wildcards, the api takes the approach you can register your wildcard,
>> and if a matching path is generated for a device, the wildcard itself is
>> handed back as the device path instead.
>>
>> So if your board code or a (not yet done) DT binding registers this wildcard
>>
>>   /platform/usbhs_omap/ehci-omap.0/usb*
>
> Device tree lists sysfs paths in it's descriptions?  That's news to me.

It does not say that...

>> and the usb hub driver asks to generate its device path
>>
>> 	device_path_generate(dev, name, sizeof name);
>>
>> that is actually
>>
>>   /platform/usbhs_omap/ehci-omap.0/usb1
>>
>> then what will be returned is
>>
>>   /platform/usbhs_omap/ehci-omap.0/usb*
>>
>> providing the same literal string for ehci-omap.0 hub no matter how many\
>> usb buses have been registered before.
>>
>> This wildcard string can then be matched to regulators or other string-
>> searchable assets intended for the device on that hardware path.
>
> 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]?
>
> thanks,
>
> greg k-h
>
> [1] Yeah, I know I'm being hopeful here, and probably wrong, but then
>      you need to push back.  We are not helpless here.

Specific hardware information is something that's kept hidden away and 
private in the driver for good reasons.

We could add elective, additional information at the driver for every 
physical interface it represented and match that way.  But I am not sure 
the effort involved is repaid by the relatively few instances that need 
what is basically asynchronously probed platform_data.

-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-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html