Messages in this thread | | | From | Andy Shevchenko <> | Date | Wed, 31 Aug 2022 23:50:47 +0300 | Subject | Re: [PATCH v2 1/2] gpio: Add gpio latch driver |
| |
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
| |