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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
