public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Anton Vorontsov <avorontsov@ru.mvista.com>
To: Trent Piepho <tpiepho@freescale.com>
Cc: Grant Likely <grant.likely@secretlab.ca>,
	linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org
Subject: Re: PIXIS gpio controller and gpio flags
Date: Mon, 21 Jul 2008 21:53:57 +0400	[thread overview]
Message-ID: <20080721175357.GA1773@polina.dev.rtsoft.ru> (raw)
In-Reply-To: <Pine.LNX.4.64.0807191352040.27586@t2.domain.actdsltmp>

On Sat, Jul 19, 2008 at 02:08:01PM -0700, Trent Piepho wrote:
> On Fri, 18 Jul 2008, Anton Vorontsov wrote:
> > +int px_gpio_xlate(struct of_gpio_chip *of_gc, struct device_node *np,
> > +               const void *gpio_spec)
> > +{
> > +     if (gpio[1] & PX_GPIO_FLAG_ACTIVE_LOW)
> > +             px_gc->active_low |= pin2mask(*gpio);
> 
> You have a race here.  What if px_gpio_xlate() is called at the same time
> for different gpios?  This is an easy one to fix, since you can use the
> atomic bitops.

Thanks, I'll fix this. But I think spinlock would be less cryptic here,
since we have one, and the xlate is called quite rarely anyway.

> It doesn't look like you have any way to unset the active low flag.  What if
> I unload the leds-gpio driver (or another gpio user) and then try to use the
> gpio with something else?  The active low flag is stuck on!

Why would you want to unset the flags? It is specified in the device
tree, and can't be changed. Specifying different flags for the same GPIO
would be an error (plus, Linux forbids shared gpios, so you simply can't
specify one gpio for several devices).

> It doesn't show
> in sysfs or debugfs either.  That could be very confusing.

It is in the /proc/device-tree. But I agree, it would be great if
/sys/debug/gpio would show active-low gpios. But this would need gpiolib
changes, with which David will not agree, I suppose. But I didn't try.

> I also wonder if it's ok to have the xlate function do flag setting?

Why not? Of course, we can implement of_gpio_is_active_low(device_node,
gpion), but this is just less convenient than handling active-low gpios
transparently (i.e. for pure OF drivers you don't have to do all
this if (active_low) in the drivers themselves).

> of_get_property() just gets the property, it doesn't allocate it.  Same with
> of_get_address() and of_get_pci_address(), they don't actually allocate or
> map an address, they just get the value.  of_get_gpio() doesn't allocate the
> gpio, that gets done later with gpio_request().  It seems like what it's
> supposed to do is just get the translated value of the gpio property.

Yes, it translates gpio value, and its flags, it also "caches" the flag
so that further gpio_ calls could use it. But the flags for the
particular gpio is constant. So each xlate must end up with the same
active-low flag, otherwise you did something wrong.

> Except, your pixis gpio xlate function sets the gpio's flags.  What if one
> wants to just look up a gpio number, but not allocate it?  The flags will
> still get set.

Nothing is allocated.

> Most gpio users, including leds-gpio, can handle gpios being busy.  If
> leds-gpio can't get one of the gpios, it rolls back all the leds it did
> create, doesn't drive the device and returns EBUSY.  Except with
> of_get_gpio() setting the flags, it will change the flags out from under
> whatever had the gpio already allocated!

You're still assuming that something was allocated. It wasn't. The flag
was set, and it should not change. It is irrelevant if request() failed
or not.

Thanks,

-- 
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2

  reply	other threads:[~2008-07-21 17:54 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-14 16:41 [PATCH] leds: implement OpenFirmare GPIO LED driver Anton Vorontsov
2008-07-15  3:10 ` Stephen Rothwell
2008-07-15 12:38   ` Anton Vorontsov
2008-07-15 12:40     ` [PATCH v2] " Anton Vorontsov
2008-07-15 12:54       ` Richard Purdie
2008-07-15 13:24         ` Anton Vorontsov
2008-07-15 13:31           ` Richard Purdie
2008-07-15 14:23             ` Anton Vorontsov
2008-07-15 14:43               ` Richard Purdie
2008-07-15 15:19                 ` [PATCH v3] " Anton Vorontsov
2008-07-16 23:18                   ` Trent Piepho
2008-07-17  4:15                     ` Grant Likely
2008-07-17  5:13                       ` Trent Piepho
2008-07-17 13:55                         ` Anton Vorontsov
2008-07-17 20:01                           ` Trent Piepho
2008-07-17 14:05                       ` Anton Vorontsov
2008-07-17 14:13                         ` Anton Vorontsov
2008-07-17 15:04                           ` Grant Likely
2008-07-17 15:20                             ` Anton Vorontsov
2008-07-17 18:05                               ` Grant Likely
2008-07-17 20:18                                 ` Trent Piepho
2008-07-17 20:49                                   ` Grant Likely
2008-07-17 23:42                                   ` Anton Vorontsov
2008-07-18  5:09                                     ` Grant Likely
2008-07-18  9:20                                     ` Trent Piepho
2008-07-18 10:05                                       ` Anton Vorontsov
2008-07-19 21:08                                         ` PIXIS gpio controller and gpio flags Trent Piepho
2008-07-21 17:53                                           ` Anton Vorontsov [this message]
2008-07-21 21:12                                             ` Trent Piepho
2008-07-23 14:56                                               ` Anton Vorontsov
2008-07-23 23:42                                                 ` Trent Piepho
2008-07-25 16:48                                                   ` [RFC PATCH] of_gpio: implement of_get_gpio_flags() Anton Vorontsov
2008-07-26  8:26                                                     ` Trent Piepho
2008-07-25 20:38                                         ` [PATCH v3] leds: implement OpenFirmare GPIO LED driver Trent Piepho
2008-07-25 21:01                                           ` [PATCH 1/2] leds: make the default trigger name const Trent Piepho
2008-07-27  2:08                                             ` Grant Likely
2008-07-27 13:11                                               ` Stephen Rothwell
2008-07-28  1:56                                                 ` Trent Piepho
2008-07-28  2:02                                                   ` [PATCH v2] " Trent Piepho
2008-07-28  9:53                                                   ` [PATCH 1/2] " Anton Vorontsov
2008-08-29  1:22                                                     ` Trent Piepho
2008-07-25 21:01                                           ` [PATCH 2/2] leds: Support OpenFirmware led bindings Trent Piepho
2008-07-27  2:21                                             ` Grant Likely
2008-07-28  8:31                                               ` Trent Piepho
2008-07-28 17:09                                                 ` Grant Likely
2008-07-28 18:02                                                   ` Anton Vorontsov
2008-07-28 18:06                                                     ` Grant Likely
2008-07-28 18:26                                                     ` Trent Piepho
2008-07-28 18:49                                                       ` Grant Likely
2008-07-28 18:51                                                       ` Anton Vorontsov
2008-07-28 19:11                                                         ` Trent Piepho
2008-07-17 21:29                   ` [PATCH v3] leds: implement OpenFirmare GPIO LED driver Nate Case
2008-07-16 23:22                 ` [PATCH v2] " Trent Piepho
2008-07-17  5:59 ` [PATCH] " Segher Boessenkool
2008-07-17 11:07   ` Anton Vorontsov
2008-07-17 14:58     ` Sean MacLennan
2008-07-17 15:07     ` Grant Likely
2008-07-18  3:35       ` David Gibson
2008-07-18  4:44         ` Grant Likely

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=20080721175357.GA1773@polina.dev.rtsoft.ru \
    --to=avorontsov@ru.mvista.com \
    --cc=grant.likely@secretlab.ca \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=tpiepho@freescale.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