Avoiding platform-specific callbacks in drivers?

Avoiding platform-specific callbacks in drivers?

[Bill Gatliff]

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.
-- 
Bill Gatliff
bgat@billgatliff.com

Re: Avoiding platform-specific callbacks in drivers?

[Kevin Dankwardt]

> 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?

Re: Avoiding platform-specific callbacks in drivers?

[Bill Gatliff]

Kevin:


On Tue, Nov 9, 2010 at 6:02 PM, Kevin Dankwardt <k@kcomputing.com> 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
bgat@billgatliff.com

Re: Avoiding platform-specific callbacks in drivers?

[Nicolas Pitre]

On Tue, 9 Nov 2010, Bill Gatliff wrote:

> Let's say that on a given platform, I need to twiddle with a GPIO pin
> when a chip enters and exits suspend.

What driver?  What platform?  This may depend on those.

> 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.  :)

Sure.  but if it makes sense for your hardware to do this GPIO 
twiddling, maybe someone else is doing that too.  In which case a driver 
solution might be justifiable.

> 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.

That would still be your best bet.  The pseudo-device could register the 
real device and set itself as the parent.


Nicolas

Re: Avoiding platform-specific callbacks in drivers?

[Bill Gatliff]

Nicolas:

On Tue, Nov 9, 2010 at 6:10 PM, Nicolas Pitre <nico@fluxnic.net> wrote:
>
> The pseudo-device could register the
> real device and set itself as the parent.

That little tidbit there is the part I seem to have been missing
before now--- actually doing the physical device registration during
the probing of the pseudo-device.  With that, the approach actually
makes sense.

Before now, I was thinking that I would still register both devices
externally, which made things clumsy to think about.


Thanks!


b.g.
-- 
Bill Gatliff
bgat@billgatliff.com