Hello Pavel,



On Fri, 24 Sept 2021 at 06:41, Cédric Le Goater [off-list ref] wrote:

On 9/21/21 06:39, Andrew Jeffery wrote:

quoted

Without these patches the driver limits the number of pins exposed on
the gpiochip to the number of pins specified as GPIO in the devicetree,
but doesn't map between the GPIO and pin number spaces. The result is
that specifying offset or interleaved GPIOs in the devicetree gives
unexpected behaviour in userspace.

By always exposing all pins as GPIOs the patches resolve the lack of
mapping between GPIO offsets and pins on the package in the driver by
ensuring we always have a 1-to-1 mapping.

The issue is primarily addressed by patch 1/2. Patch 2/2 makes it
possible to not expose any pins as LEDs (and therefore make them all
accessible as GPIOs). This has a follow-on effect of allowing the driver
to bind to a device instantiated at runtime without requiring a
description in the devicetree.

I've tested the series under qemu to inspect the various interactions
between LEDs vs GPIOs as well as conflicting GPIO requests.

quoted

Please review!

This is simpler than the 'ngpio' business we had before.

Reviewed-by: Cédric Le Goater <clg@kaod.org>

I saw that you recently merged some LED patches. I was wondering if
you could consider this series for v5.18. It still applies cleanly,
and we've been running it for a while now, so it's very well tested.

Cheers,

Joel

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel