On Mon, Jul 27, 2015 at 12:07:14PM +0200, Linus Walleij wrote: > OK so should we not do this change and always use the latched IRQs if > available on the hardware? I don't see why we would need a device tree > property for this. > > I would more think something like, if the compatible string is so and > so, our hardware supports latching, and then we just use it. That is more > helpful than adding extra flags.
Sounds good, if somebody does not want latching, he can just specify the pca9555 compatible string. Then, no GPIO_INPUT_LATCH flag is necessary. > I'd say mask off all IRQs in probe and mask them on selectively as the > irqchip portions request IRQs. Should work, right? I think so, yes. I'll give it a try! > OK so implement it on a first-come-first-served order. > > Add a bool open_drain state to your state container, set it to true > when the first consumer requests open drain, but noone else has > yet requested any pins. So logic: > > request(req_open_drain): > if (req_open_drain && any_pins_requested && !state->open_drain) > print_verbose_error > if (!any_pins_requested) > state->open_drain = true; > increase_requested_pins > ... > > So the API should assume we can request this per-pin (since such controllers > exist) and then the driver will impose this limitation for the PCA953x > and deny consumers to configure conflicting modes. OK, will do! > > Too keep track of how many pins are currently requested you can use > a bitmask or <linux/kref.h> if you want to be fancy but I think some simple > solution should be OK. Thank you very much for your feedback. I'll come back with a RFC patch series. > > Yours, > Linus Walleij Regards, Clemens Gruber -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
