Re: Avoiding platform-specific callbacks in drivers?

[Kevin Dankwardt <k@kcomputing.com>]

> Guys:
>
>
> Let's say that on a given platform, I need to twiddle with a GPIO pin
> when a chip enters and exits suspend.  One way to do that is to hack
> the driver itself; a slightly less-inelegant way is to add a function
> pointer in the platform data, and have the driver call back in its
> suspend() and resume() methods.  I'm not real keen on either strategy,
> because they both involve touching driver code that should be
> platform-agnostic.  They seem... hacky.  :)
>
> I would love to come up with a way that prevents touching the driver
> at all, since the activity is terribly platform-specific. Is there
> such a way?
>
> One possibility is to set up some sort of parent-child relationship
> between the device and a pseudo-device that deals with the GPIO pin.
> But I'm not sure that will actually work, and it seems a bit
> overly-complicated.
>
> Ideas, anyone?  I'll be happy to try them out if they seem feasible,
> and post code and feedback.
>
>
> b.g.
>    

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?