This series adds a driver for a 7 segment LED display.

At this point I've decided not to pursue supporting >1 character. I had
a look at what would be required to add a devm_fwnode_gpiod_get_array()
and got bogged down in OF and ACPI code for counting GPIOs.
--
[1] - https://lore.kernel.org/lkml/2a8d19ee-b18b-4b7c-869f-7d601cea30b6@alliedtelesis.co.nz/

Chris Packham (4):
  auxdisplay: Add 7 segment LED display driver
  dt-bindings: auxdisplay: Add bindings for generic 7 segment LED
  ARM: dts: marvell: Add 7 segment LED display on x530
  ARM: dts: marvell: Indicate USB activity on x530

 .../auxdisplay/generic-gpio-7seg.yaml         |  40 ++++++
 .../boot/dts/marvell/armada-385-atl-x530.dts  |  22 +++-
 drivers/auxdisplay/Kconfig                    |  10 ++
 drivers/auxdisplay/Makefile                   |   1 +
 drivers/auxdisplay/seg-led.c                  | 119 ++++++++++++++++++
 5 files changed, 191 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/auxdisplay/generic-gpio-7seg.yaml
 create mode 100644 drivers/auxdisplay/seg-led.c

-- 
2.43.2

On Tue, Feb 27, 2024 at 11:22 PM Chris Packham
<chris.packham@alliedtelesis.co.nz> wrote:
>
> This series adds a driver for a 7 segment LED display.
>
> At this point I've decided not to pursue supporting >1 character. I had
> a look at what would be required to add a devm_fwnode_gpiod_get_array()
> and got bogged down in OF and ACPI code for counting GPIOs.

Out of curiosity, why did it happen? gpiod_count() works in an agnostic way.

-- 
With Best Regards,
Andy Shevchenko

On 28/02/24 13:05, Andy Shevchenko wrote:
> On Tue, Feb 27, 2024 at 11:22 PM Chris Packham
> <chris.packham@alliedtelesis.co.nz> wrote:
>> This series adds a driver for a 7 segment LED display.
>>
>> At this point I've decided not to pursue supporting >1 character. I had
>> a look at what would be required to add a devm_fwnode_gpiod_get_array()
>> and got bogged down in OF and ACPI code for counting GPIOs.
> Out of curiosity, why did it happen? gpiod_count() works in an agnostic way.
>
At first I though I could create a fwnode_gpiod_count() out of the body 
of gpiod_count(). But both of_gpio_get_count() and acpi_gpio_count() 
take the dev not the fwnode. It looks like gpiod_count() (and 
of_gpio_spi_cs_get_count()) could probably be re-written (or abstracted) 
to take the device_node instead of the device. I started looking at 
acpi_gpio_count() but I couldn't quite see how I could adapt this.

I'm definitely not saying it can't be done. Just that you probably don't 
want an occasional contributor like me messing with some of these core 
device abstractions.

On Wed, Feb 28, 2024 at 12:25:30AM +0000, Chris Packham wrote:
> 
> On 28/02/24 13:05, Andy Shevchenko wrote:
> > On Tue, Feb 27, 2024 at 11:22 PM Chris Packham
> > <chris.packham@alliedtelesis.co.nz> wrote:
> >> This series adds a driver for a 7 segment LED display.
> >>
> >> At this point I've decided not to pursue supporting >1 character. I had
> >> a look at what would be required to add a devm_fwnode_gpiod_get_array()
> >> and got bogged down in OF and ACPI code for counting GPIOs.
> > Out of curiosity, why did it happen? gpiod_count() works in an agnostic way.
> >
> At first I though I could create a fwnode_gpiod_count() out of the body 
> of gpiod_count(). But both of_gpio_get_count() and acpi_gpio_count() 
> take the dev not the fwnode. It looks like gpiod_count() (and 
> of_gpio_spi_cs_get_count()) could probably be re-written (or abstracted) 
> to take the device_node instead of the device. I started looking at 
> acpi_gpio_count() but I couldn't quite see how I could adapt this.
> 
> I'm definitely not saying it can't be done. Just that you probably don't 
> want an occasional contributor like me messing with some of these core 
> device abstractions.

I just sent a series. With it you may split gpiod_count() to
fwnode_gpio_count() and gpiod_count() that uses the former.
I believe you may do that easily as it won't require any special
knowledge.

-- 
With Best Regards,
Andy Shevchenko