On Thu, Jul 16, 2020 at 11:49 AM Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: > > On Thu, Jul 2, 2020 at 4:57 PM Andy Shevchenko > <andriy.shevchenko@xxxxxxxxxxxxxxx> wrote: > > > > Andy: your input would be appreciated, this kind of code > > > customizing random embedded Intel systems is deep water for > > > me, so this is just a rough guess on how it should be done. > > > > Linus, I have set up the device (it's actually available as Minnowboard v1) and > > will look at this. > > OK whenever you have time, there is no hurry. > > > For time being there is a patch you need to fold into this (sorry, it's mangled): > > > > (Explanation: GPIO will be locked with request_irq() call) > > I do not understand this, sadly. gpiod_lock_as_irq() will be called > indeed, but we are requesting it as input and keeping it as such > so this should be fine? When you clean up GPIO at the same time you don't need to carry this memory and resource for the entire lifetime of the driver. When you lock it as IRQ the resource is not available to use by others anyway and will be requested whenever IRQ is requested. That's how I understand it. And to me it makes sense from a flexibility point of view and debugging perspective. -- With Best Regards, Andy Shevchenko
