On Wed, Apr 6, 2016 at 5:42 PM, Grygorii Strashko <grygorii.strashko@xxxxxx> wrote: > On 04/06/2016 04:39 PM, Linus Walleij wrote: >>> Of course, there are some question to discuss: >>> 1) [+] It should sync initialization of GPIOchip and GPIOirqchip >>> 2) [+] This approach requires changes in gpiolib/gpio drivers only, from other side >>> It will require to add fixes all over the Kernel if gpiod_to_irq() will >>> start returning -EPROBE_DEFER. >> >> Yes, so it will need to be cross-coordinated with IRQ maintainers >> Marc and TGLX. > > Seems, I have to study how to be more clear :( > This +/- are all about my RFC patch. > My patch limits the scope of problem to GPIO subsystem/drivers only. > As opposite, if we will touch gpiod_to_irq() - it will affect on whole > kernel. OK I get it now, good. >> Yes. Every driver in the kernel need to be audited. > > With my patch only GPIO drivers need to be checked, especially GPIO > drivers which: > - are non-DT based; > - do not use GPIO irq helpers > - can make IRQ functionality optional using Kconfig/sysfs/module parameters Yeah. I mean you have to look at all of them, not patch all of them. It's a lot but not unberably much. < 300 files. >>> 4) irq_ready access synchronization on SMP? atomic? >> >> Uhhh.... I don't even understand the question. > > in my patch the irq_ready is set from _gpiochip_irqchip_add() and > read from gpiod_request() without any kind of protection and those > two functions can be executed in parallel. Aha. Well I don't know if that is really a big problem? Does that really happen in practice? Yours, Linus Walleij -- 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
