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?
> 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.
> 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.
> /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.
> 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.
--
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
