Linux-GPIO Archive mirror
 help / color / mirror / Atom feed
From: Bartosz Golaszewski <brgl@kernel.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>,
	Linus Walleij <linusw@kernel.org>,
	 Mika Westerberg <mika.westerberg@linux.intel.com>,
	 Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	linux-gpio@vger.kernel.org,  linux-kernel@vger.kernel.org
Subject: Re: [PATCH] gpiolib: fix hogs with multiple lines
Date: Thu, 26 Mar 2026 14:54:35 +0100	[thread overview]
Message-ID: <CAMRc=MfHDVLE51WF9UdBbJOQ0mktO3tQYZ4=zXa6WPWV0bMq6Q@mail.gmail.com> (raw)
In-Reply-To: <CAMuHMdVpQ_HmqXqB=MwJJYbNKgNvrb0ZdbNbiiz=CXK1qECBEQ@mail.gmail.com>

On Wed, Mar 25, 2026 at 7:42 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Bartosz,
>
> On Wed, 25 Mar 2026 at 11:18, Bartosz Golaszewski
> <bartosz.golaszewski@oss.qualcomm.com> wrote:
> > After moving GPIO hog handling into GPIOLIB core, we accidentally stopped
> > supporting devicetree hog definitions with multiple lines like so:
> >
> >         hog {
> >                 gpio-hog;
> >                 gpios = <3 0>, <4 GPIO_ACTIVE_LOW>;
> >                 output-high;
> >                 line-name = "foo";
> >         };
> >
> > Restore this functionality to fix reported regressions.
> >
> > Fixes: d1d564ec4992 ("gpio: move hogs into GPIO core")
> > Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
> > Closes: https://lore.kernel.org/all/CAMuHMdX6RuZXAozrF5m625ZepJTVVr4pcyKczSk12MedWvoejw@mail.gmail.com/
> > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
>
> Thanks, that fixes the issue I saw on Marzen
> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
>
> > --- a/drivers/gpio/gpiolib.c
> > +++ b/drivers/gpio/gpiolib.c
> > @@ -938,12 +938,12 @@ int gpiochip_add_hog(struct gpio_chip *gc, struct fwnode_handle *fwnode)
> >         struct fwnode_handle *gc_node = dev_fwnode(&gc->gpiodev->dev);
> >         struct fwnode_reference_args gpiospec;
> >         enum gpiod_flags dflags;
> > +       const char *name = NULL;
> >         struct gpio_desc *desc;
> >         unsigned long lflags;
> > -       const char *name;
> > +       size_t num_hogs;
> >         int ret, argc;
> > -       u32 gpios[3]; /* We support up to three-cell bindings. */
> > -       u32 cells;
> > +       u32 cells = 0;
>
> Shouldn't the default be 2?
>

For DT I suppose there's no real "default" but it does make sense to
set it to 2 for the generic fwnode path.

> >
> >         lflags = GPIO_LOOKUP_FLAGS_DEFAULT;
> >         dflags = GPIOD_ASIS;
> > @@ -952,43 +952,21 @@ int gpiochip_add_hog(struct gpio_chip *gc, struct fwnode_handle *fwnode)
> >         argc = fwnode_property_count_u32(fwnode, "gpios");
> >         if (argc < 0)
> >                 return argc;
> > -       if (argc > 3)
> > +
> > +       ret = fwnode_property_read_u32(gc_node, "#gpio-cells", &cells);
>
> Should this call be protected by is_of_node(), like in the old code?
>

Not necessarily. We may end up using it with software nodes for
instance. I'd keep it global.

> > +       if ((ret && is_of_node(fwnode)) || (!ret && (argc % cells)))
> >                 return -EINVAL;
> >
> > +       num_hogs = ret ? 1 : (argc / cells);
>
> While you avoid modulo and division by zero due to the check for ret,
> using a default would let you always validate argc against cells,
> and remove the need for special casing num_hogs.
>
> > +
> > +       u32 *gpios __free(kfree) = kcalloc(argc, sizeof(u32), GFP_KERNEL);
>
> kzalloc_objs()?
>

True.

Bart

      reply	other threads:[~2026-03-26 13:54 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-25 10:18 [PATCH] gpiolib: fix hogs with multiple lines Bartosz Golaszewski
2026-03-25 12:26 ` Andy Shevchenko
2026-03-25 18:41 ` Geert Uytterhoeven
2026-03-26 13:54   ` Bartosz Golaszewski [this message]

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='CAMRc=MfHDVLE51WF9UdBbJOQ0mktO3tQYZ4=zXa6WPWV0bMq6Q@mail.gmail.com' \
    --to=brgl@kernel.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=bartosz.golaszewski@oss.qualcomm.com \
    --cc=geert@linux-m68k.org \
    --cc=linusw@kernel.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mika.westerberg@linux.intel.com \
    /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 read-only IMAP folder(s) and NNTP newsgroup(s).