On Mon, 2018-07-09 at 15:13 +0200, Linus Walleij wrote: > On Tue, Jul 3, 2018 at 2:38 AM Andy Shevchenko > <andriy.shevchenko@xxxxxxxxxxxxxxx> wrote: > > > In case we try to lock GPIO pin as IRQ when something going wrong > > we print a misleading message. > > > > Correct this by checking an error code from ->get_direction() in > > gpiochip_lock_as_irq() and printing a corresponding message. > > > > Note, this doesn't change overall behavior because error code used > > to > > be recognized as direction output which anyway led to an abortion of > > request. > > > > Fixes: 9c10280d85c1 ("gpio: flush direction status in > > gpiochip_lock_as_irq()") > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> > > Cc: Mika Westerberg <mika.westerberg@xxxxxxxxxxxxxxx> > > OK per followup I stripped the Fixes tag and the last paragraph and > applied. Thanks! > I am a bit worried that there might be platforms that have survived > by igoring any error code from get direction (interpreting it as > "input) but they will hopefully notice ... thanks to the new error > print. And then suddenly they might get no interrupt b/c pin, for example, still an output (should be caught by other API calls I think, though failing earlier is better for my opinion). > > Did you look around to see if some driver might be returning > error codes from get_direction()? I suspect mostly I2C-based > expanders and if it's an error it's an error and this is the right > thing to > do but you never know what people are doing... In the GPIO/pinctrl folders: both tegras, bcm2835, stm32 and most of Intel. In the drivers: i2c-mux-ltc4306. So, not many. -- Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> Intel Finland Oy -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html