On Thu, Aug 22, 2013 at 1:10 AM, Stephen Warren <swarren@xxxxxxxxxxxxx> wrote: [Me] >>> check if these in turn reference the interrupt-controller, and >>> if they do, loop over the interrupts used by that child and >>> perform gpio_request() and gpio_direction_input() on these, >>> making them unreachable from the GPIO side. > > What about bindings that require a GPIO to be specified, yet don't allow > an IRQ to be specified, and the driver internally does perform > gpio_to_irq() on it? I don't think one can detect that case. This is still allowed. Consumers that prefer to have a GPIO passed and convert it to IRQ by that call can still do so, they will know what they're doing and will not cause the double-command situation that we're trying to solve. > Isn't it better to have the IRQ chip's .request() operation convert the > IRQ to a GPIO if relevant (which it can do since it has specific > knowledge of the HW) and take ownership of the GPIO at that level? We tried this in the OMAP case, but apart from that the OMAP driver blew up so we had to revert the patches, it also means the same code needs to go into each and every driver instead of solving the dilemma centrally like this. > I vaguely recall seeing patches along those lines before, but there must > have been some other problem pointed out... You bet. It turns out these patches break the case which you just described above, whereas this patch does not. OMAP had drivers that used gpio_to_irq() *and* it had drivers that used the GPIO controller node as interrupt parent. So when they fixes .request() as per above, the latter started working properly whereas the former started breaking. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
