Re: [PATCH] gpio-pca953x: Support NXP PCAL9555A with Agile I/O

[Clemens Gruber <clemens.gruber@xxxxxxxxxxxx>]

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html