linux-leds.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Jeffery <andrew@aj.id.au>
To: linux-leds@vger.kernel.org, linux-gpio@vger.kernel.org
Cc: clg@kaod.org, robh+dt@kernel.org, joel@jms.id.au, pavel@ucw.cz,
	linus.walleij@linaro.org, devicetree@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org,
	andy.shevchenko@gmail.com
Subject: [PATCH 0/2] leds: pca955x: Expose GPIOs for all pins
Date: Tue, 21 Sep 2021 14:09:34 +0930	[thread overview]
Message-ID: <20210921043936.468001-1-andrew@aj.id.au> (raw)

Hello,

This is a rework of a Rube Goldberg-inspired RFC I posted previously:

https://lore.kernel.org/lkml/20210723075858.376378-1-andrew@aj.id.au/

This time around there's a lot less Rube - the series:

1. Contains no (ab)use of pinctrl
2. Always exposes all pins as GPIOs
3. Internally tracks the active pins

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.

Please review!

Andrew

Andrew Jeffery (2):
  leds: pca955x: Make the gpiochip always expose all pins
  leds: pca955x: Allow zero LEDs to be specified

 drivers/leds/leds-pca955x.c | 65 +++++++++++++++++++------------------
 1 file changed, 34 insertions(+), 31 deletions(-)


base-commit: 239f32b4f161c1584cd4b386d6ab8766432a6ede
-- 
2.30.2


             reply	other threads:[~2021-09-21  4:39 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-21  4:39 Andrew Jeffery [this message]
2021-09-21  4:39 ` [PATCH 1/2] leds: pca955x: Make the gpiochip always expose all pins Andrew Jeffery
2021-11-01  2:07   ` Andrew Jeffery
2021-11-09 11:03   ` Linus Walleij
2021-11-16  2:44     ` Joel Stanley
2021-09-21  4:39 ` [PATCH 2/2] leds: pca955x: Allow zero LEDs to be specified Andrew Jeffery
2021-09-21 12:10 ` [PATCH 0/2] leds: pca955x: Expose GPIOs for all pins Andy Shevchenko
2021-09-23 21:48 ` Linus Walleij
2021-09-24  3:49 ` Joel Stanley
     [not found] ` <d2b85ad7-aef7-6088-03f5-cbd6e0bcab5d@kaod.org>
2022-02-21  7:33   ` Joel Stanley
2022-03-02  8:54     ` Pavel Machek
2022-03-03  0:30       ` Andrew Jeffery

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210921043936.468001-1-andrew@aj.id.au \
    --to=andrew@aj.id.au \
    --cc=andy.shevchenko@gmail.com \
    --cc=clg@kaod.org \
    --cc=devicetree@vger.kernel.org \
    --cc=joel@jms.id.au \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-aspeed@lists.ozlabs.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=robh+dt@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).