public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jamie Lokier <jamie@shareable.org>
To: Ryan Mallon <ryan@bluewatersys.com>
Cc: "David Brownell" <david-b@pacbell.net>,
	"David Brownell" <dbrownell@users.sourceforge.net>,
	gregkh@suse.de, "linux kernel" <linux-kernel@vger.kernel.org>,
	ext-jani.1.nikula@nokia.com,
	"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: [RFC PATCH] Rework gpio cansleep (was Re: gpiolib and sleeping gpios)
Date: Wed, 23 Jun 2010 23:53:45 +0100	[thread overview]
Message-ID: <20100623225345.GD7058@shareable.org> (raw)
In-Reply-To: <4C21955D.1020502@bluewatersys.com>

Ryan Mallon wrote:
> On 06/23/2010 04:37 PM, David Brownell wrote:
> I'm not. Some gpios, such as those on io expanders, may sleep in their
> implementations of the gpio_(set/get) functions.

I'm having a hard time figuring out where some GPIOs I'm using fit
into this picture.

I have some hardware that is currently using a 2.4.26 kernel, but I
look from time to time at forward-porting all the drivers to 2.6.recent.

It has an I2C driven GPIO expander, with a watchdog reset chip hanging
off the expander.

The watchdog is kept alive off the back end of a timer BH, which means
the I2C GPIO routines are written to be safe in BH context (which
isn't sleepable), but they can't be used in IRQ context because the
necessary spin_lock_irqsave() would turn off interrupts for too long
for other subsystems to function properly.

How should I flag those GPIO routines in your scheme?  They're safe to
use in some non-sleeping contexts, but not safe in irq context.

Thanks,
-- Jamie

  parent reply	other threads:[~2010-06-23 22:53 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-17 21:47 gpiolib and sleeping gpios Ryan Mallon
2010-06-18  5:27 ` Uwe Kleine-König
2010-06-18  6:16 ` David Brownell
2010-06-18 22:01   ` Ryan Mallon
2010-06-19  6:21     ` David Brownell
2010-06-20 21:31       ` Ryan Mallon
2010-06-21  2:40         ` David Brownell
2010-06-21  5:09           ` Uwe Kleine-König
2010-06-23  1:59             ` [RFC PATCH] Rework gpio cansleep (was Re: gpiolib and sleeping gpios) Ryan Mallon
2010-06-23  4:37               ` David Brownell
2010-06-23  4:58                 ` Eric Miao
2010-06-23  9:51                   ` David Brownell
2010-06-23  5:02                 ` Ryan Mallon
2010-06-23  5:26                   ` Eric Miao
2010-06-23  9:39                   ` David Brownell
2010-06-23 19:12                     ` Ryan Mallon
2010-06-24  4:46                       ` [RFC PATCH] Rework gpio cansleep (was Re: gpiolib and sleepinggpios) Jon Povey
2010-06-24  8:20                         ` Lars-Peter Clausen
2010-06-24  8:29                         ` Jani Nikula
2010-06-24 10:31                           ` Lars-Peter Clausen
2010-06-24  6:41                       ` [RFC PATCH] Rework gpio cansleep (was Re: gpiolib and sleeping gpios) Uwe Kleine-König
2010-06-23 22:53                   ` Jamie Lokier [this message]
2010-06-23 23:06                     ` Ryan Mallon
2010-06-24  0:04                       ` Jamie Lokier
2010-06-24  0:10                         ` Ryan Mallon
2010-06-25  7:19                           ` David Brownell
2010-06-24  4:33                         ` [RFC PATCH] Rework gpio cansleep (was Re: gpiolib and sleepinggpios) Jon Povey
2010-06-29  8:29         ` gpiolib and sleeping gpios CoffBeta
2010-06-23 11:53       ` Jani Nikula
2010-06-23 12:40         ` David Brownell
2010-06-23 13:22           ` Jani Nikula
2010-06-23 13:39             ` David Brownell

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=20100623225345.GD7058@shareable.org \
    --to=jamie@shareable.org \
    --cc=akpm@linux-foundation.org \
    --cc=david-b@pacbell.net \
    --cc=dbrownell@users.sourceforge.net \
    --cc=ext-jani.1.nikula@nokia.com \
    --cc=gregkh@suse.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ryan@bluewatersys.com \
    --cc=u.kleine-koenig@pengutronix.de \
    /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