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: <1212530564.5446.70.camel@moss.renham>
Date:	Wed, 04 Jun 2008 08:02:44 +1000
From:	Ben Nizette <bn@...sdigital.com>
To:	Guennadi Liakhovetski <g.liakhovetski@....de>
Cc:	David Brownell <david-b@...bell.net>, linux-kernel@...r.kernel.org
Subject: Re: [RFC] generic GPIO parameter API


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