Kevin:
On Tue, Nov 9, 2010 at 6:02 PM, Kevin Dankwardt <[email protected]> wrote: > Isn't the general approach to avoid platform-dependencies to abstract the > behavior? As is used throughout the kernel, an "operations" struct that > provides the abstractions and each driver fills in its implementation as > required. The "polymorphism" approach. Maybe the operations are > "begin_suspend()" and "end_suspend()" and in this case the functions twiddle > a GPIO pin? The begin_suspend()/end_suspend() approach just moves the problem, really. Unless you put those function pointers into the platform data, you can't change them without touching the driver code. And if you do put those function pointers into the platform data, that seems an awful lot like open-coding. Gets the job done, but seems a fairly blunt instrument. In my case, the device model itself already provides the answer. The "GPIO twiddling" can be dealt with by implementing a pseudo-device that registers the actual device underneath it. Then the pseudo device neatly gets the suspend/resume events at the right times relative to the device. AND you get the benefits of sysfs and debugfs for free. I knew the answer was there; it just took an expert like Nicolas Pitre to point out the obvious to me. I can be so dense sometimes! :) b.g. -- Bill Gatliff [email protected] -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
