public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ben Nizette <bn@niasdigital.com>
To: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: David Brownell <david-b@pacbell.net>, linux-kernel@vger.kernel.org
Subject: Re: [RFC] generic GPIO parameter API
Date: Tue, 03 Jun 2008 09:13:57 +1000	[thread overview]
Message-ID: <1212448437.5446.21.camel@moss.renham> (raw)
In-Reply-To: <Pine.LNX.4.64.0806021949210.30390@axis700.grange>


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.  The driver which is going to want
to set the parameters is going to have the gpio number, not the
gpio_chip.  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.

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);

with the different parameters defined as an enum in some gpio.h
somewhere.  Where to keep the gpio_parameters and how to search/find
them should be up to the implementation (though the gpiolib
implementation would probably look quite like what you've got above).

Note you'll probably want a char *name in there somewhere for the sysfs
interface, but I don't think it should be the primary mechanism for
identification.

Anyway, that's my $0.02  :-)

	--Ben.



  reply	other threads:[~2008-06-02 23:14 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-02 17:22 [RFC] generic GPIO parameter API Guennadi Liakhovetski
2008-06-02 17:54 ` Guennadi Liakhovetski
2008-06-02 23:13   ` Ben Nizette [this message]
2008-06-03  6:42     ` Guennadi Liakhovetski
2008-06-03  7:32       ` Ben Nizette
2008-06-03  8:29         ` Guennadi Liakhovetski
2008-06-03 22:02           ` Ben Nizette
2008-06-06  5:29 ` David Brownell
2008-06-06  5:50   ` Guennadi Liakhovetski
2008-06-09 16:23   ` Guennadi Liakhovetski
2008-06-09 16:54     ` Mark Brown
2008-06-09 17:09       ` Guennadi Liakhovetski
2008-06-10  9:43         ` Mark Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1212448437.5446.21.camel@moss.renham \
    --to=bn@niasdigital.com \
    --cc=david-b@pacbell.net \
    --cc=g.liakhovetski@gmx.de \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox