On Mon, Jan 21, 2019 at 6:07 PM Bartosz Golaszewski <brgl@xxxxxxxx> wrote: > Thank you for your review. While I think you're right about the issue > being present in this driver, I'm not sure it's really a problem. Do > we actually require every gpio-controller to also be a stand-alone > interrupt-controller? Absolutely not :D Just GPIO is fine. > The binding document for the GPIO module doesn't > mention this - it only requires the gpio-controller property. Without > the "interrupt-controller" property dtc will bail-out if anyone uses > this node as the interrupt parent. > > If I'm wrong and we do require it, then I think we need to update > Documentation/devicetree/bindings/gpio/gpio.txt. What is weird is if a driver with DT bindings not mentioning IRQ and only probing from DT start implementing IRQ support, that becomes quite inconsistent. So then max77650_gpio_to_irq() should just return -ENOTSUPP or something for now, then it's fine. We can add the (complicated) IRQ handling later. I am trying to eat my own dogfood here, I was sweating all last night trying to implement a hierarchical IRQ controller. There is no running away from that now. :/ Apparently doing hierarchical IRQs demand that all irq controllers up to the top-level SoC IRQ controller support hierarchical interrupts using the v2 version of the irqdomain API, and currently it seems like the ARM GIC seems like the only top level IRQ controller that can do that. Yours, Linus Walleij
