On Tue, Mar 22, 2016 at 2:59 PM, Vaibhav Hiremath <vaibhav.hiremath@xxxxxxxxxx> wrote: > On Thursday 17 March 2016 03:48 PM, Linus Walleij wrote: > but recently I came across another usecase of shared gpio, > > Say, for example, we have multiple external I2C peripheral which share > interrupt line over gpio (ofcourse irq line is muxed onto single gpio). > > Now in kernel I would have multiple instances of driver supporting each > peripheral but gpio can not be shared for registering irq. > > Do you suggest MFD driver for such simple usecases ? Should gpiolib > support SHARED gpios, and gpiolib can define all the policies over > configuration I don't see why you would want to use MFD at all. Not shared GPIOs but shared interrupt lines. If you're using device tree is is pretty straight forward: - Make sure the GPIOlib and irqchip portions of the driver are totally orthogonal. (See Documentation/gpio/driver.txt section "GPIO drivers providing IRQs") - Just use the irqchip side of the GPIO - Make sure your consumers check if the IRQ is theirs and return IRQ_HANDLED vs NO_IRQ depending on whether it's theirs or not. It is quite obvious from context that in this case all consumers are using an open drain (if active low) scheme. However since the GPIO is then used as input it has no effect, it is more a question for the consumers to assure their IRQ logic is not using push-pull but rather open drain or you will get a disaster in the totempole... > (input only, what about conflicts, bidirectional mode?) We thought about this, see Documentation/gpio/driver.txt section Locking IRQ usage". When the line is locked for IRQ usage, it cannot be switched to output. 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
