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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux