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 10:29 +0200, Guennadi Liakhovetski wrote:
> On Tue, 3 Jun 2008, Ben Nizette wrote:
> > On Tue, 2008-06-03 at 08:42 +0200, Guennadi Liakhovetski wrote:
> > > On Tue, 3 Jun 2008, Ben Nizette wrote:
> > > >
> > > > 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?
>
> Yes.
>
> > How does the end user go about turning the pullups on and off?
>
> Either using the in-kernel API

I guess it's this bit I was wondering about more precisely. _Which_ in
kernel API? The gpio_find_parameter thing you had above? If so, how
are you discovering the gpio_chip? (Note that if you are indeed
discovering the gpio_chip, this isn't portable. gpio chips shouldn't be
known outside of gpiolib, gpiolib's optional and separate from the gpio
framework).

> or over sysfs, if it's a user-space app.
>
> > How does the end user know that that's what they want to do?
>
> That's their problem, isn't it? We are talking about an embedded system,
> where applications are written with datasheets and schematics in hand. So,
> you will know whether or not you want to switch pullups.
>
> > > > 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.
>
> gpio_get_val() is easy - you can only get a 0 or a 1 in success case
> there. Whereas with an arbitrary gpio parameter you don't know what valid
> values it can return. Ok, practically, I can hardly imagine a GPIO
> parameter with 2^32 valid values, but who knows...
>

Hmm, in the absence of a solid use case I'm a fan of sticking with
tradition. I can just see people forgetting to put an &foo in get but
just foo in set (I know I would). But so long as it's solidly
documented then I guess I wouldn't be able to complain :-)

Just so long as we agree that there should be this kind of interface in
the gpio framework, quite apart from how it's implemented inside
gpiolib.

Cheers,
--Ben.

> Thanks
> Guennadi
> ---
> Guennadi Liakhovetski, Ph.D.
> Freelance Open-Source Software Developer


\
 
 \ /
  Last update: 2008-06-04 00:05    [W:0.047 / U:0.764 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site