On Wed, Feb 5, 2014 at 3:31 AM, Courtney Cavin <courtney.cavin@xxxxxxxxxxxxxx> wrote: > On Wed, Feb 05, 2014 at 12:08:35AM +0100, Christopher Heiny wrote: >> On 01/23/2014 04:00 PM, Courtney Cavin wrote: >> > Since all the configuration needed for an irq can be provided in other >> > ways, remove all gpio->irq functionality. This cleans up the code quite >> > a bit. >> >> In certain diagnostic modes, we need to be able to release the IRQ so >> the GPIO can be monitored from userspace. This patch removes that >> capability. > > Polling a GPIO from userspace is poor design regardless of the use-case, if > you ask me. It certainly doesn't motivate the extra gpio<->IRQ code. I think Courtney is right here, if you want this kind of stuff for debugging it should be debug-add-on-patches, not part of the normal execution path for the driver. >> As mentioned in previous patch discussions, the polling functionality is >> quite useful during new system integration, so we need to retain that. >> If you have a proposal for where else it could be done, we'd certainly >> entertain a patch that implements that. > > Do you actually have systems that have these hooked up to GPIOs without > IRQ support? > > Regardless, if this is the case, implementing a GPIO polling IRQ chip > should be possible, if extremely ugly. OMG that would be quite horrible. > Linus may have some comments in this area, though. Linus? A driver may rely on polling but a driver may not rely on polling done from userspace. 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
