Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220831055811.1936613-1-s.hauer@pengutronix.de> <20220831055811.1936613-2-s.hauer@pengutronix.de>
In-Reply-To: <20220831055811.1936613-2-s.hauer@pengutronix.de>
From:   Andy Shevchenko <andy.shevchenko@gmail.com>
Date:   Wed, 31 Aug 2022 23:50:47 +0300
Message-ID: <CAHp75Vd6LCv1wcxV58Q3Pa=eBRdEK6XusbfeDQtm8+R0hAAyWg@mail.gmail.com>
Subject: Re: [PATCH v2 1/2] gpio: Add gpio latch driver
To:     Sascha Hauer <s.hauer@pengutronix.de>
Cc:     "open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Geert Uytterhoeven <geert@linux-m68k.org>,
        Linus Walleij <linus.walleij@linaro.org>,
        Bartosz Golaszewski <brgl@bgdev.pl>,
        Sascha Hauer <kernel@pengutronix.de>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Wed, Aug 31, 2022 at 9:02 AM Sascha Hauer <s.hauer@pengutronix.de> wrote:
>
> This driver implements a GPIO multiplexer based on latches connected to
> other GPIOs. A set of data GPIOs is connected to the data input of
> multiple latches. The clock input of each latch is driven by another
> set of GPIOs. With two 8-bit latches 10 GPIOs can be multiplexed into
> 16 GPIOs. GPOs might be a better term as in fact the multiplexed pins
> are output only.

I'm still unsure it shouldn't be a part of the (not yet in upstream)
driver that I have mentioned before. But let's leave this apart right
now.

...

> +#include <linux/err.h>
> +#include <linux/module.h>

> +#include <linux/of_device.h>

Why?
It seems you misplaced it instead of mod_devicetable.h.

> +#include <linux/gpio/driver.h>
> +#include <linux/platform_device.h>
> +#include <linux/gpio/consumer.h>

Keep above sorted?

...

> +       struct mutex mutex;
> +       spinlock_t spinlock;

Checkpatch usually complains if locks are not commented. Looking at
the below code, why it's not an (anonymous) union?

...

> +       if (val)
> +               priv->shadow[latch] |= BIT(offset % priv->n_pins);
> +       else
> +               priv->shadow[latch] &= ~BIT(offset % priv->n_pins);

I believe shadow should be defined as unsigned long * and hence normal
bit operations can be applied. For example here is assign_bit().

...

> +       priv->shadow = devm_kcalloc(&pdev->dev, priv->n_ports, sizeof(*priv->shadow),
> +                                   GFP_KERNEL);

bitmap_zalloc()

> +       if (!priv->shadow)
> +               return -ENOMEM;

...

> +       priv->gc.parent = &pdev->dev;

> +       priv->gc.of_node = pdev->dev.of_node;

Redundant as repeating parent above.

...

> +static const struct of_device_id gpio_latch_ids[] = {
> +       {
> +               .compatible     = "gpio-latch",
> +       }, {
> +               /* sentinel */
> +       }

You may compress this to the 2 LoCs.

> +};

-- 
With Best Regards,
Andy Shevchenko