On 11/28/2012 12:37 AM, the mail apparently from Alan Stern included:
On Tue, 27 Nov 2012, Andy Green wrote:
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.
I'm not quite sure what you mean by that. _Any_ function is capable of
doing only a fixed thing.
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.
Let's worry about that when it arises.
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.
Greg's advice was simply not to rely on pathnames in sysfs because they
aren't fixed in stone. That leaves plenty of other ways to approach
this problem.
It's sage advice, but there is zero code provided in my patches that
"relies on pathnames in sysfs".
Basically, what you want is for something related to device A (the
regulator or the GPIO) to happen whenever device B (the ehci-omap.0
platform device) is bound to a driver. The most straightforward way to
arrange this is for A's driver to have a callback that is invoked
whenever B is bound or unbound. The most straightforward way to
arrange _that_ is to allow each platform_device to have a list of
callbacks.
Sorry I didn't really understand this proposal yet. You want "A", the
regulator, driver to grow a callback function that gets called when the
targeted platform_device ("B", ehci-omap.0) probe happens. Could you
expand what the callback prototype or new members in the struct might
look like? It's your tuple thing or we pass it an opaque pointer that
is the struct regulator * or suchlike?
Throwing out the path stuff and limiting this to platform_device means
you cannot bind to dynamically created objects like hub or anything
downstream of a hub. So Felipe's identification of the hub as the
happening place to do this is out of luck.
-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
