lkml.org 
[lkml]   [2008]   [Jun]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC] generic GPIO parameter API
From
Date

On Tue, 2008-06-03 at 08:42 +0200, Guennadi Liakhovetski wrote:
> On Tue, 3 Jun 2008, Ben Nizette wrote:
>
> > On Mon, 2008-06-02 at 19:54 +0200, Guennadi Liakhovetski wrote:
> > > On Mon, 2 Jun 2008, Guennadi Liakhovetski wrote:
> > > > int gpio_register_parameter(struct gpio_chip *chip, struct gpio_parameter
> > > > *param);
> > > > struct gpio_parameter *gpio_find_parameter(struct gpio_chip *chip, char
> > > > *name);
> > >
> > > Actually, I think, it would be even better to just add two fields
> > >
> > > struct gpio_parameter *param;
> > > int param_n;
> > >
> > > to struct gpio_chip.
> >
> > I like the idea in general. The biggest worry I have is trying to find
> > the parameter for you to fiddle with.
>
> Oh, this doesn't worry me - I have a driver here for a controller with
> switchable pullups.

You're talking about a gpio chip driver? How does the end user go about
turning the pullups on and off? How does the end user know that that's
what they want to do?

>
> > The driver which is going to want
> > to set the parameters is going to have the gpio number, not the
> > gpio_chip.
>
> Sure, right.
>
> > Also, the fact that the parameters are uniquely identified
> > by strings is a bit awkward. I can see people registering the same kind
> > of parameter for different chips like "pullup", "Pullup", "pu" etc
> > making the driver's task even harder.
>
> Well, I thought about that too, but then I decided there would have to be
> too many of those macros. But we can try it that way too.
>
> > So, I reckon if we're to do this we should stick with the current style
> > of gpio calls for the outside interface, maybe something more like
> >
> > int gpio_set_param(int gpio, int param, int val);
> > int gpio_get_param(int gpio, int param);
>
> For the get I would rather pass it "int *val" because we don't know which
> values are valid and which are an error code for this specific parameter.

Well everything else in the world just uses negative returns for errors,
I'm sure that any parameter get/set routines can conform with that, no?
This way is more consistent with, gpio_{get,set}_val etc not to mention
the rest of the kernel.

--Ben.




\
 
 \ /
  Last update: 2008-06-03 09:35    [W:3.145 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site