[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 6 Jun 2008 05:53:47 -0700
From: David Brownell <david-b@...bell.net>
To: "Leon Woestenberg" <leon.woestenberg@...il.com>
Cc: LAK <linux-arm-kernel@...ts.arm.linux.org.uk>,
"Linux Kernel list" <linux-kernel@...r.kernel.org>
Subject: Re: Locking in the (now generic) GPIO infrastructure?
On Wednesday 04 June 2008, Leon Woestenberg wrote:
> include/asm-arm/arch-ixp4xx/platform.h:
> static inline void gpio_line_set(u8 line, int value)
> {
> if (value == IXP4XX_GPIO_HIGH)
> *IXP4XX_GPIO_GPOUTR |= (1 << line);
> else if (value == IXP4XX_GPIO_LOW)
> *IXP4XX_GPIO_GPOUTR &= ~(1 << line);
> }
>
> Under a Linux kernel where multiple drivers are accessing GPIO, the
> latter does not seem safe against preemption (assuming the memory
> read-modify-write is not atomic).
>
> Shouldn't GPIO access be protected against concurrent access here?
Well, against an IRQ in the middle of those read/modify/write
sequences hidden by the "|=" and "&=" syntax. Last I knew,
no XScale CPUs support on-chip SMP.
> Documentation/gpio.txt does not really mention the locking mechanism
> assumed to modify GPIO lines.
That function isn't part of the GPIO interface, despite
its gpio_* prefix, so that's not relevant.
It resembles gpio_set_value() though. That can use at
most spinlocks to establish its atomicity guarantee; it's
described as "spinlock-safe", and in distinction to the
gpio_set_value_cansleep() call which could use a mutex or
other sleeping synch primitive.
--
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/
Powered by blists - more mailing lists