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

[Ben Dooks]

On Wed, Jun 04, 2008 at 01:00:19PM +0200, Leon Woestenberg wrote:
> Hello,
> 
> compare void gpio_line_set() in
> 
> arch/arm/plat-iop/gpio.c:
> void gpio_line_set(int line, int value)
> {
> 	unsigned long flags;
> 
> 	local_irq_save(flags);
> 	if (value == GPIO_LOW) {
> 		*IOP3XX_GPOD &= ~(1 << line);
> 	} else if (value == GPIO_HIGH) {
> 		*IOP3XX_GPOD |= 1 << line;
> 	}
> 	local_irq_restore(flags);
> }
> 
> with
> 
> 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);
> }

Yes, that looks rather buggy to me, and also sub-optimal to boot. The
u8 line should be changed to just 'unsigned' having the compiler truncate
to 8bit isn't useful when then used with a shift.

static inline void gpio_line_set(unsigned line, int value)
{
	unsigned long flags;
	unsigned regval;

	local_irq_save(flags);

	regval = *IXP4XX_GPIO_GPOUTR;

	if (value == IXP4XX_GPIO_HIGH)
		regval |= (1 << line);
	else if (value == IXP4XX_GPIO_LOW)
	   	regval &= ~(1 << line);

	*IXP4XX_GPIO_GPOUTR = regval;
	local_irq_restore(flags);
}
 
> 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?
> 
> Documentation/gpio.txt does not really mention the locking mechanism
> assumed to modify GPIO lines.

I think it depends on whether gpiolib is being used or not, there may
be some locking in there.

-- 
Ben

Q:      What's a light-year?
A:      One-third less calories than a regular year.

--
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/