On Thu, Jul 16, 2020 at 01:19:32PM +0300, Andy Shevchenko wrote: > 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. I looked closer to the code, it's using it as IRQ and as a GPIO (to know was it rising or falling). Easier to leave as in your patch. Meanwhile I'm trying to find some information about actual presence / use of VBUS on Intel Galileo Gen 2 and / or Minnowboard v1.0. -- With Best Regards, Andy Shevchenko
