Stephen: On Thu, Dec 15, 2011 at 10:30 AM, Stephen Warren <swarren@xxxxxxxxxx> wrote: > > This sounds like something the new pinctrl subsystem will eventually grow > to address. It might, but I'm not sure it is exactly what I want. In particular, in what I gather from reading about pinctrl it seems to presume that only events on the device in question will invoke pin control events. I'm trying to do things at a higher level, by using the Device Model to express relationships between devices beyond simple electrical and data connections. The vreg APIs are a good example, since they allow me to name regulators on a per-device basis but still associate those names with a physical regulator at some point. This additional layer of indirection lets me refer to device-specific pin names like "VIN" in my probe() methods, and have something behind the scenes do the "Device X's VIN is actually regulator LDO23 on this platform" translation. I can get similar behaviors when I create a "virtual" platform device as a parent of one or more platform devices representing actual hardware. That allows me to tell the kernel, "After you suspend devices X and Y, I need to know about it". The only thing that gets clumsy here is the additional code to deal with the split device/driver implementation, which facilitates managing N devices just fine but in my case I know there will only be one of the virtual devices. In a way, I'm trying to implement a generic "device event notification shim" that can wedge in between a parent and child device of any type, and intercept events passing between them. I think I can get this done with ordinary struct device and struct driver implementations, plus judicious use of device_move(). I just wanted to be sure I wasn't reinventing anything before going down this path. Assuming I survive the trip, I'll report back with what I find. :) b.g. -- Bill Gatliff bgat@xxxxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
