On 11/27/2012 03:12 AM, the mail apparently from Alan Stern included:
On Mon, 26 Nov 2012, 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.
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.
For that reason, to get a deterministic path for matching, wildcards are
allowed. If your target device has the path
/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.
Have you considered limiting these wildcards in various useful ways?
In this example, the wildcard must match a string of decimal digits.
(Furthermore the two wildcard strings will always match each other,
although it's probably not necessary to add this sort of constraint.)
I don't know what sort of matches people will want in the future.
Perhaps one for hex digits, or one for arbitrary text with the
exception of a few characters (such as '/' but perhaps others too).
To do what you want for now, the match should be restricted to digits.
I'm not sure what we'd use that for... it doesn't seem the biggest
problem we have at the moment ^^
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*
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.
That's not how I would do it, at least, not for this application. I
would register tuples containing a name, a pointer, and two callback
routines. For example,
("/platform/usbhs_omap/ehci-omap.0/usb*", &omap_vhub_device,
turn_on_regulator, turn_off_regulator)
The when a device is registered whose path matches the string in such a
tuple, the device core would know to invoke the first callback. The
arguments would be a pointer to the device being registered and the
pointer in the tuple. Similarly, the device core would invoke the
second callback when the device is unregistered.
There doesn't have to be anything in this scheme that's specific to
hubs or even to USB. In particular, no changes to the hub driver would
be needed.
By just using paths, it's not restricted to regulators or binary
operations on them but anything that needs a "floating" binding to
another named kernel object can leverage it.
-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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
