Re: Locking in the (now generic) GPIO infrastructure?

[David Brownell]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/