On 09/23/2013 01:53 PM, Linus Walleij wrote: > On Wed, Sep 11, 2013 at 9:43 PM, Stephen Warren <swarren@xxxxxxxxxxxxx> wrote: > >> I believe this situation is exactly what cause the original patch to the >> OMAP driver to be reverted; that patch should have touched the HW >> directly to solve the problem when the IRQ was requested, rather than >> calling into the GPIO subsystem (which also has the side-effect of >> touching the HW in the same way as desired). > > And that has the side-effect that this line, which is now set up > in the HW as an input line, can be gpio_request()ed by some other > code path and set up as output, screwing around with the very > same registers. > > I think the kernel should prevent such things. It might be nice if it could do that. However, that is 100% unrelated to the problem at hand. A driver which only cares about an IRQ should be able to call just IRQ APIs and have the HW work. Since not all IRQs are GPIOs, the thing that causes the HW to work should not involve the GPIO subsystem in any way at all. So, the first issue - making a correctly configured system functionally work without resorting to hacks such as requesting a GPIO to make an IRQ work, is one thing. This issue should be solved purely inside the specific HW driver. Having the kernel detect when two different drivers both request the same resource is entirely another thing. The solution to the first issue must not rely on any solution to this second issue. I'm also not convinced it's possible to solve this second issue given the current kernel APIs, since there's not enough semantic information; requests of GPIOs and IRQs aren't actually tied to a particular driver at present (there's no "struct device *dev" parameter to request_irq or gpio_request) and so the subsystems can't actually tell who is requesting the GPIO/IRQ, and hence can't detect when the same driver, or a different driver, is requesting the same core resource for different purposes. Equally, I am actually not 100% sure we want the core to prevent this. Why shouldn't two different drivers request the same IRQ? Why shouldn't at least one driver, perhaps more, request the pin as a GPIO (assuming it will only read the GPIO value, not flip the pin to output). This exact situation might happen on some Tegra boards where there's a GPIO for VBUS_EN that affects 2 USB ports. It's supposed to be driven open-collector. If an external entity forces it low, it means over-current. Drivers for both ports might want to receive interrupts on both edges, and even request the GPIO for input so they can both tell which level the signal is at, in order to report OC/not-OC back up to higher levels, as soon as any change occurs. -- 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
