Hi Jean-François, On Fri, Apr 20, 2012 at 11:32:00AM -0400, Jean-François Dagenais wrote: > As discussed here: http://ez.analog.com/message/35852, > the 5587 revC and 5588 revB spec sheets contain a mistake > in the GPIO_DAT_STATx register description. > > According to R.Shnell at ADI, as well as my own > observations, it should read: > "GPIO data status (shows GPIO state when read for inputs)". > > This commit changes the get value function accordingly. > > A similar patch for gpio-adp5588 follows. > > Signed-off-by: Jean-François Dagenais <jeff.dagenais@xxxxxxxxx> > Acked-by: Michael Hennerich <michael.hennerich@xxxxxxxxxx> > --- > drivers/input/keyboard/adp5588-keys.c | 7 +++++++ > 1 files changed, 7 insertions(+), 0 deletions(-) > > diff --git a/drivers/input/keyboard/adp5588-keys.c b/drivers/input/keyboard/adp5588-keys.c > index 6412ced..b7a0f1a 100644 > --- a/drivers/input/keyboard/adp5588-keys.c > +++ b/drivers/input/keyboard/adp5588-keys.c > @@ -78,6 +78,13 @@ static int adp5588_gpio_get_value(struct gpio_chip *chip, unsigned off) > unsigned int bank = ADP5588_BANK(kpad->gpiomap[off]); > unsigned int bit = ADP5588_BIT(kpad->gpiomap[off]); > > + mutex_lock(&kpad->gpio_lock); > + if (kpad->dir[bank] & bit) { > + int result = !!(kpad->dat_out[bank] & bit); > + mutex_unlock(&kpad->gpio_lock); > + return result; > + } > + mutex_unlock(&kpad->gpio_lock); > return !!(adp5588_read(kpad->client, GPIO_DAT_STAT1 + bank) & bit); This locking looks wrong as it is possible for adp5588_gpio_get_value() to get scheduled out after checking kpad->dir[bank] and releasing kpad->gpio_lock while another thread executes adp5588_gpio_direction_output() and modifies kpad->dir[bank]. You should keep mutex for the entire duration; something like this: mutex_lock(&kpad->gpio_lock); if (kpad->dir[bank] & bit) val = kpad->dat_out[bank]; else val = adp5588_read(kpad->client, GPIO_DAT_STAT1 + bank); mutex_unlock(&kpad->gpio_lock); return !!(val & bit); Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
