From: Trent Piepho <tpiepho@freescale.com>
To: Ben Nizette <bn@niasdigital.com>
Cc: David Brownell <david-b@pacbell.net>,
lkml <linux-kernel@vger.kernel.org>,
hartleys <hartleys@visionengravers.com>,
Mike Frysinger <vapier.adi@gmail.com>,
Bryan Wu <cooloney@kernel.org>
Subject: Re: [patch/rfc 2.6.25-git] gpio: sysfs interface
Date: Tue, 29 Apr 2008 11:15:30 -0700 (PDT) [thread overview]
Message-ID: <Pine.LNX.4.64.0804291022190.15041@t2.domain.actdsltmp> (raw)
In-Reply-To: <1209472526.311.50.camel@moss.renham>
On Tue, 29 Apr 2008, Ben Nizette wrote:
> On Mon, 2008-04-28 at 22:48 -0700, Trent Piepho wrote:
>> On Mon, 28 Apr 2008, David Brownell wrote:
>>> On Monday 28 April 2008, Trent Piepho wrote:
>>>> I liked it better they way I had it, "label:N".
>>>
>>> Those labels may not be available though; or valid in pathnames.
>>
>> So just fall back to "gpio" if there is no label? The only character that's
>> not valid in a pathname is '/', so that's trivial to check for.
>>
>> const char *label = chip->label && !strchr(chip->label, '/') ?
>> chip->label : "gpio"; /* or "generic" or "unknown", or ...*/
>>
>> This means you don't need a file with number to device assignents. It makes
>> shell scripting a lot easier too. Say I want the first gpio on a pca9557 gpio
>> expander? It's will be something like: /sys/class/gpio/pca9557-0:0
>>
>> You don't have to worry about dynamic assigments. You don't have to resort to
>> convoluted shell script code to extract the proper range from a mapping file
>> and then construct the name.
>
> Sorry if I'm being dense; how do you want this bit to work? As I see
> it, there are a few options:
>
> 1) Have the files named as you suggest and all of them always present,
> albeit read-only until export. Very easy to use, easy to discover which
> file is which, a decent bit of memory usage having them all listed.
Well, is it really that much? There are 579 files under /sys/class/tty. But
suppose it is too much (why isn't tty too much then?), then we can do 3.
> 3) Have the files named as you suggest, explicit export/request but
> better parsing behind the control file so something like
> echo "export pca9557-0:5" > control
> works. Very very nice for the user, big heavy back end.
The back end doesn't seem that big to me. Here's code for it. If anything,
the parsing code is simpler than what David has. It's certainly not huge.
David's code for parsing the control file plus code for generating a mapping
range file would certainly be larger.
/* Format: -?(chiplabel:)?number
* The optional leading - unexports the gpio, without it the gpio is exported.
* The optional chip label followed by a : gives you the Nth gpio of that
* chip. With no label you get gpio "number".
*/
static ssize_t control_store(struct class *class, const char *buf, size_t len)
{
const char *numstr;
unsigned long num;
int mode = 0;
if (buf[0] == '-') { /* un-export? */
mode = 1;
buf++;
}
numstr = strrchr(buf, ':');
/* Get GPIO number */
if (strict_strtoul(numstr ? numstr + 1 : buf, 0, &num))
return -EINVAL;
/* Match chip label, if one was specified */
if (numstr) {
/* No + 1 in len to not include the ':' at the end */
int i, len = numstr - buf;
const struct gpio_chip *chip = NULL;
for (i = 0; gpio_is_valid(i); i++) {
if (chip == gpio_desc[i].chip)
continue;
chip = gpio_desc[i].chip;
if (!chip)
continue;
if (!strncmp(buf, chip->label, len) &&
chip->label[len] == '\0')
goto found_chip;
}
return -EINVAL;
found_chip:
if (num >= chip->ngpio)
return -EINVAL;
num += chip->base;
}
if (mode) {
/* Unexport */
if (!gpio_is_valid(num))
return -EINVAL;
if (!test_and_clear_bit(FLAG_SYSFS, &gpio_desc[num].flags))
return -EINVAL;
gpio_free(num);
} else {
/* Export */
int status = gpio_request(num, "sysfs");
if (status < 0)
return status;
status = gpio_export(num);
if (status < 0) {
gpio_free(num);
return status;
}
set_bit(FLAG_SYSFS, &gpio_desc[num].flags);
}
return len;
}
next prev parent reply other threads:[~2008-04-29 18:19 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-28 19:39 David Brownell
2008-04-28 20:46 ` Andrew Morton
2008-04-28 23:28 ` David Brownell
2008-04-29 2:54 ` Andrew Morton
2008-04-29 3:42 ` Greg KH
2008-04-29 18:45 ` David Brownell
2008-04-29 19:09 ` Andrew Morton
2008-05-02 20:36 ` Pavel Machek
2008-05-17 22:14 ` David Brownell
2008-05-18 0:36 ` [patch 2.6.26-rc2-git] " David Brownell
2008-05-20 7:17 ` Andrew Morton
2008-05-18 4:55 ` [patch/rfc 2.6.25-git] " Ben Nizette
2008-05-19 22:39 ` Pavel Machek
2008-05-20 1:26 ` David Brownell
2008-05-20 8:02 ` Pavel Machek
2008-04-28 23:01 ` Ben Nizette
2008-04-29 0:44 ` David Brownell
2008-04-29 1:58 ` Ben Nizette
2008-04-29 3:44 ` David Brownell
2008-04-29 4:47 ` Ben Nizette
2008-04-29 21:28 ` David Brownell
2008-04-29 6:17 ` Trent Piepho
2008-04-29 22:39 ` David Brownell
2008-04-28 23:09 ` Trent Piepho
2008-04-29 0:45 ` David Brownell
2008-04-29 5:48 ` Trent Piepho
2008-04-29 12:35 ` Ben Nizette
2008-04-29 18:15 ` Trent Piepho [this message]
2008-04-29 21:56 ` David Brownell
2008-04-30 0:49 ` Trent Piepho
2008-04-30 17:49 ` David Brownell
2008-04-29 21:55 ` David Brownell
2008-04-29 23:29 ` Ben Nizette
2008-04-30 1:04 ` David Brownell
2008-04-30 2:08 ` Ben Nizette
2008-04-30 3:13 ` Trent Piepho
2008-04-30 10:33 ` Ben Nizette
2008-04-30 17:42 ` David Brownell
2008-04-30 21:34 ` [patch/rfc 2.6.25-git v2] " David Brownell
2008-04-30 22:47 ` Trent Piepho
2008-04-30 23:14 ` Ben Nizette
2008-05-01 2:12 ` David Brownell
2008-05-01 2:08 ` David Brownell
2008-05-01 3:41 ` Trent Piepho
2008-05-01 4:35 ` David Brownell
2008-05-01 21:16 ` Trent Piepho
2008-05-03 2:58 ` David Brownell
2008-05-03 3:05 ` David Brownell
2008-04-30 23:28 ` Ben Nizette
2008-05-01 21:40 ` David Brownell
2008-04-29 0:47 ` [patch/rfc 2.6.25-git] " Ben Nizette
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=Pine.LNX.4.64.0804291022190.15041@t2.domain.actdsltmp \
--to=tpiepho@freescale.com \
--cc=bn@niasdigital.com \
--cc=cooloney@kernel.org \
--cc=david-b@pacbell.net \
--cc=hartleys@visionengravers.com \
--cc=linux-kernel@vger.kernel.org \
--cc=vapier.adi@gmail.com \
/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
all inboxes | Powered by JetHome®