From: Tzung-Bi Shih <tzungbi@kernel.org>
To: Bartosz Golaszewski <brgl@kernel.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
Linus Walleij <linusw@kernel.org>, Shuah Khan <shuah@kernel.org>,
linux-kernel@vger.kernel.org, linux-gpio@vger.kernel.org,
linux-kselftest@vger.kernel.org
Subject: Re: [PATCH v4 1/6] gpio: Access `gpio_bus_type` in gpiochip_setup_dev()
Date: Thu, 12 Mar 2026 04:52:54 +0000 [thread overview]
Message-ID: <abJGpo7t5KCvyGE1@google.com> (raw)
In-Reply-To: <CAMRc=McmrJLWGoXjKaqGuCWpLZU4mmcrgs9ESAaL8kG=_R89cw@mail.gmail.com>
On Wed, Mar 11, 2026 at 07:36:51AM -0700, Bartosz Golaszewski wrote:
> On Wed, 11 Mar 2026 12:44:31 +0100, Geert Uytterhoeven
> <geert@linux-m68k.org> said:
> > Hi Tzung-Bi,
> >
> > On Mon, 23 Feb 2026 at 07:17, Tzung-Bi Shih <tzungbi@kernel.org> wrote:
> >> To make the intent clear, access `gpio_bus_type` only when it's ready in
> >> gpiochip_setup_dev().
> >>
> >> Reviewed-by: Linus Walleij <linusw@kernel.org>
> >> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
> >
> > Thanks for your patch, which is now commit cc11f4ef666fbca0 ("gpio:
> > Access `gpio_bus_type` in gpiochip_setup_dev()") in gpio/gpio/for-next.
> >
> >> --- a/drivers/gpio/gpiolib.c
> >> +++ b/drivers/gpio/gpiolib.c
> >> @@ -901,6 +901,8 @@ static int gpiochip_setup_dev(struct gpio_device *gdev)
> >> struct fwnode_handle *fwnode = dev_fwnode(&gdev->dev);
> >> int ret;
> >>
> >> + gdev->dev.bus = &gpio_bus_type;
> >> +
> >> /*
> >> * If fwnode doesn't belong to another device, it's safe to clear its
> >> * initialized flag.
> >> @@ -1082,7 +1084,6 @@ int gpiochip_add_data_with_key(struct gpio_chip *gc, void *data,
> >> * then make sure they get free():ed there.
> >> */
> >> gdev->dev.type = &gpio_dev_type;
> >> - gdev->dev.bus = &gpio_bus_type;
> >> gdev->dev.parent = gc->parent;
> >> device_set_node(&gdev->dev, gpiochip_choose_fwnode(gc));
> >>
> >
> > Postponing this assignment does have an impact on early
> > messages. E.g. on RBTX4927:
> >
> > -gpio gpiochip0: Static allocation of GPIO base is deprecated, use
> > dynamic allocation.
> > + gpiochip0: Static allocation of GPIO base is deprecated, use
> > dynamic allocation.
> >
> > Or with CONFIG_DEBUG_GPIO=y, e.g. on BeagleBone black:
> >
> > -gpio gpiochip0: (gpio-0-31): created GPIO range 0->7 ==>
> > 44e10800.pinmux PIN 0->7
> > -gpio gpiochip0: (gpio-0-31): created GPIO range 8->11 ==>
> > 44e10800.pinmux PIN 90->93
> > -gpio gpiochip0: (gpio-0-31): created GPIO range 12->27 ==>
> > 44e10800.pinmux PIN 12->27
> > -gpio gpiochip0: (gpio-0-31): created GPIO range 28->31 ==>
> > 44e10800.pinmux PIN 30->33
> > + gpiochip0: (gpio-0-31): created GPIO range 0->7 ==>
> > 44e10800.pinmux PIN 0->7
> > + gpiochip0: (gpio-0-31): created GPIO range 8->11 ==>
> > 44e10800.pinmux PIN 90->93
> > + gpiochip0: (gpio-0-31): created GPIO range 12->27 ==>
> > 44e10800.pinmux PIN 12->27
> > + gpiochip0: (gpio-0-31): created GPIO range 28->31 ==>
> > 44e10800.pinmux PIN 30->33
> > [...]
> >
> > Note the spaces at the beginning of the printed lines.
> > Reverting the commit re-adds the "gpio" prefix.
Thanks for catching this.
> >
>
> As per the comment in gpiochip_add_data_with_key(): we may end up with
> a functional chip before gpiochip_setup_dev() is called and so before we
> assign the bus type.
>
> dev_printk() helpers only read the name field of the bus type so it should
> be safe, I don't see anyone else accessing it before we register it.
>
> I think it makes sense to revert this commit. Tzung-Bi: what do you think?
That makes sense. I agree, let's revert it.
next prev parent reply other threads:[~2026-03-12 4:52 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-23 6:17 [PATCH v4 0/6] gpio: Refactor and add selftest Tzung-Bi Shih
2026-02-23 6:17 ` [PATCH v4 1/6] gpio: Access `gpio_bus_type` in gpiochip_setup_dev() Tzung-Bi Shih
2026-03-11 11:44 ` Geert Uytterhoeven
2026-03-11 14:36 ` Bartosz Golaszewski
2026-03-12 4:52 ` Tzung-Bi Shih [this message]
2026-02-23 6:17 ` [PATCH v4 2/6] gpio: Remove redundant check for struct gpio_chip Tzung-Bi Shih
2026-02-23 6:17 ` [PATCH v4 3/6] gpio: sysfs: " Tzung-Bi Shih
2026-02-23 6:17 ` [PATCH v4 4/6] gpio: Ensure struct gpio_chip for gpiochip_setup_dev() Tzung-Bi Shih
2026-02-27 21:36 ` Marek Szyprowski
2026-02-28 10:03 ` Bartosz Golaszewski
2026-02-28 13:20 ` Tzung-Bi Shih
2026-02-23 6:17 ` [PATCH v4 5/6] gpio: cdev: Don't check struct gpio_chip in gpio_chrdev_open() Tzung-Bi Shih
2026-02-23 6:17 ` [PATCH v4 6/6] selftests: gpio: Add gpio-cdev-uaf tests Tzung-Bi Shih
2026-02-25 10:26 ` [PATCH v4 0/6] gpio: Refactor and add selftest Bartosz Golaszewski
2026-02-26 12:44 ` Tzung-Bi Shih
2026-02-27 9:10 ` Bartosz Golaszewski
2026-02-27 9:08 ` Bartosz Golaszewski
2026-02-27 9:22 ` Linus Walleij
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=abJGpo7t5KCvyGE1@google.com \
--to=tzungbi@kernel.org \
--cc=brgl@kernel.org \
--cc=geert@linux-m68k.org \
--cc=linusw@kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=shuah@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.