Received-SPF: pass (google.com: domain of linux-kernel+bounces-80414-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Precedence: bulk
MIME-Version: 1.0
References: <20240225213423.690561-1-chris.packham@alliedtelesis.co.nz> <20240225213423.690561-2-chris.packham@alliedtelesis.co.nz>
In-Reply-To: <20240225213423.690561-2-chris.packham@alliedtelesis.co.nz>
From: Andy Shevchenko <andy.shevchenko@gmail.com>
Date: Mon, 26 Feb 2024 04:32:06 +0200
Message-ID: <CAHp75Vcntz68xdr20JuXpHjM6vog=FZm2qGYPxOTRsFhmVe32Q@mail.gmail.com>
Subject: Re: [PATCH 1/3] auxdisplay: Add 7 segment LED display driver
To: Chris Packham <chris.packham@alliedtelesis.co.nz>
Cc: ojeda@kernel.org, robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org, 
	conor+dt@kernel.org, andrew@lunn.ch, gregory.clement@bootlin.com, 
	sebastian.hesselbarth@gmail.com, geert@linux-m68k.org, pavel@ucw.cz, 
	lee@kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, 
	linux-arm-kernel@lists.infradead.org, linux-leds@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, Feb 25, 2024 at 11:34=E2=80=AFPM Chris Packham
<chris.packham@alliedtelesis.co.nz> wrote:
>
> Add a driver for a 7 segment LED display. At the moment only one
> character is supported but it should be possible to expand this to
> support more characters and/or 14 segment displays in the future.

(I try to comment only on the things that will remain after rebasing
on top of auxdisplay:for-next)

..

> +config SEG_LED
> +       bool "Generic 7 segment LED display"

Why can't it be a module?

> +       select LINEDISP
> +       help
> +         This driver supports a generic 7 segment LED display made up
> +         of GPIO pins connected to the individual segments.

Checkpatch wants 3+ lines of help, I would add the module name (after
changing it to be tristate, etc).

..

> + * The GPIOs are wired to the 7 segments in a clock wise fashion startin=
g from

clockwise

> + * the top.

..

> + * The decimal point LED presnet on some devices is currently not

present

> + * supported.

..

> +#include <linux/gpio/consumer.h>
> +#include <linux/kernel.h>
> +#include <linux/map_to_7segment.h>
> +#include <linux/module.h>

> +#include <linux/of.h>

This is not used. And actually shouldn't be in a new code like this
with rare exceptions.

> +#include <linux/platform_device.h>

This is rather semirandom, please use IWYU (Include What You Use)
principle. We have, among others, container_of.h, types.h, err.h,
bitmap.h, mod_devicetable.h.

..

With

    sturct device *dev =3D &pdev->dev;

the below code will be neater.

> +       priv =3D devm_kzalloc(&pdev->dev, struct_size(priv, curr, 1), GFP=
_KERNEL);
> +       if (!priv)
> +               return -ENOMEM;
> +       priv->num_char =3D 1;
> +
> +       platform_set_drvdata(pdev, priv);
> +
> +       priv->segment_gpios =3D devm_gpiod_get_array(&pdev->dev, "segment=
", GPIOD_OUT_LOW);
> +       if (IS_ERR(priv->segment_gpios))
> +               return PTR_ERR(priv->segment_gpios);

..

> +static struct platform_driver seg_led_driver =3D {
> +       .probe =3D seg_led_probe,
> +       .remove =3D seg_led_remove,
> +       .driver =3D {
> +               .name =3D "seg-led",
> +               .of_match_table =3D seg_led_of_match,
> +       },
> +};

> +

Redundant blank line.

> +module_platform_driver(seg_led_driver);
> +
> +MODULE_AUTHOR("Chris Packham <chris.packham@alliedtelesis.co.nz>");
> +MODULE_DESCRIPTION("7 segment LED driver");
> +MODULE_LICENSE("GPL");

> +

Seems like a redundant blank line at the end of the file.

--=20
With Best Regards,
Andy Shevchenko