[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <c384c5ea0806040400j35236d5fo3854ce2ed30cd755@mail.gmail.com>
Date: Wed, 4 Jun 2008 13:00:19 +0200
From: "Leon Woestenberg" <leon.woestenberg@...il.com>
To: LAK <linux-arm-kernel@...ts.arm.linux.org.uk>,
"Linux Kernel list" <linux-kernel@...r.kernel.org>
Subject: Locking in the (now generic) GPIO infrastructure?
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);
}
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.
And I think I am running into an issue with this under -rt kernels,
but that needs more analysis from my side.
Regards,
--
Leon
--
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