linux-kernel - Re: [RFC] generic GPIO parameter API

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.0806030834440.19323@axis700.grange>
Date:	Tue, 3 Jun 2008 08:42:03 +0200 (CEST)
From:	Guennadi Liakhovetski <g.liakhovetski@....de>
To:	Ben Nizette <bn@...sdigital.com>
cc:	David Brownell <david-b@...bell.net>, linux-kernel@...r.kernel.org
Subject: Re: [RFC] generic GPIO parameter API

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.

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

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

Thanks for the comments
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/