linux-gpio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Bartosz Golaszewski <brgl@bgdev.pl>
Cc: Koichiro Den <koichiro.den@canonical.com>,
	linux-gpio@vger.kernel.org,  linus.walleij@linaro.org,
	maciej.borzecki@canonical.com,  linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 09/10] gpio: aggregator: cancel deferred probe for devices created via configfs
Date: Wed, 12 Feb 2025 16:49:07 +0100	[thread overview]
Message-ID: <CAMuHMdU24x9pxEjBHTKxySxwr-L+iKXSUNFxpM9hvaSTNAWDuQ@mail.gmail.com> (raw)
In-Reply-To: <CAMRc=Meb633zVgemPSeNtnm8oJmk=njcr2CQQbD5UJd=tBC5Zg@mail.gmail.com>

Hi Bartosz,

On Tue, 4 Feb 2025 at 14:14, Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> On Mon, Feb 3, 2025 at 4:12 AM Koichiro Den <koichiro.den@canonical.com> wrote:
> > For aggregators initialized via configfs, write 1 to 'live' waits for
> > probe completion and returns an error if the probe fails, unlike the
> > legacy sysfs interface, which is asynchronous.
> >
> > Since users control the liveness of the aggregator device and might be
> > editting configurations while 'live' is 0, deferred probing is both
> > unnatural and unsafe.
> >
> > Cancel deferred probe for purely configfs-based aggregators when probe
> > fails.
> >
> > Signed-off-by: Koichiro Den <koichiro.den@canonical.com>

> > --- a/drivers/gpio/gpio-aggregator.c
> > +++ b/drivers/gpio/gpio-aggregator.c
> > @@ -1313,7 +1313,6 @@ static struct attribute *gpio_aggregator_attrs[] = {
> >  };
> >  ATTRIBUTE_GROUPS(gpio_aggregator);
> >
> > -
> >  /*
> >   *  GPIO Aggregator platform device
> >   */
> > @@ -1342,8 +1341,22 @@ static int gpio_aggregator_probe(struct platform_device *pdev)
> >
> >         for (i = 0; i < n; i++) {
> >                 descs[i] = devm_gpiod_get_index(dev, NULL, i, GPIOD_ASIS);
> > -               if (IS_ERR(descs[i]))
> > +               if (IS_ERR(descs[i])) {
> > +                       /*
> > +                        * Deferred probing is not suitable when the aggregator
> > +                        * is created by userspace. They should just retry later
> > +                        * whenever they like. For device creation via sysfs,
> > +                        * error is propagated without overriding for backward
> > +                        * compatibility. .prevent_deferred_probe is kept unset
> > +                        * for other cases.
> > +                        */
> > +                       if (!init_via_sysfs && !dev_of_node(dev) &&
> > +                           descs[i] == ERR_PTR(-EPROBE_DEFER)) {
> > +                               pr_warn("Deferred probe canceled for creation by userspace.\n");
> > +                               return -ENODEV;
> > +                       }
> >                         return PTR_ERR(descs[i]);
> > +               }
> >         }
> >
> >         features = (uintptr_t)device_get_match_data(dev);
>
> Geert, what do you think about making the sysfs interface synchronous
> instead? I would argue it's actually more logical as the user will
> instinctively expect the aggregator to be ready after write() to
> new_device returns.

On one hand, I agree that it would make some scenarios simpler, and
let us propagate an error code to the sysfs writer in case of failure.

On the other hand, it would change user behavior. Currently people can
configure a GPIO aggregator, and load the driver module for the parent
gpiochip later, relying on deferred probing to bring up everything
when it is ready.

I2C's new_device is also synchronous.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

  reply	other threads:[~2025-02-12 15:49 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-03  3:12 [PATCH v2 00/10] Introduce configfs-based interface for gpio-aggregator Koichiro Den
2025-02-03  3:12 ` [PATCH v2 01/10] gpio: aggregator: reorder functions to prepare for configfs introduction Koichiro Den
2025-02-11 15:48   ` Geert Uytterhoeven
2025-02-03  3:12 ` [PATCH v2 02/10] gpio: aggregator: introduce basic configfs interface Koichiro Den
2025-02-04 12:48   ` Bartosz Golaszewski
2025-02-04 14:41     ` Koichiro Den
2025-02-05 13:39       ` Koichiro Den
2025-02-12 13:48   ` Geert Uytterhoeven
2025-02-13 14:12     ` Koichiro Den
2025-02-13 14:31       ` Geert Uytterhoeven
2025-02-03  3:12 ` [PATCH v2 03/10] gpio: aggregator: add read-only 'dev_name' configfs attribute Koichiro Den
2025-02-04 12:49   ` Bartosz Golaszewski
2025-02-04 14:44     ` Koichiro Den
2025-02-12 14:20   ` Geert Uytterhoeven
2025-02-13 14:13     ` Koichiro Den
2025-02-03  3:12 ` [PATCH v2 04/10] gpio: aggregator: add read-write 'name' attribute Koichiro Den
2025-02-12 14:27   ` Geert Uytterhoeven
2025-02-13 14:13     ` Koichiro Den
2025-02-03  3:12 ` [PATCH v2 05/10] gpio: aggregator: expose custom line names to forwarder gpio_chip Koichiro Den
2025-02-12 14:44   ` Geert Uytterhoeven
2025-02-13 14:13     ` Koichiro Den
2025-02-03  3:12 ` [PATCH v2 06/10] gpio: aggregator: rename 'name' to 'key' in aggr_parse() Koichiro Den
2025-02-12 14:45   ` Geert Uytterhoeven
2025-02-03  3:12 ` [PATCH v2 07/10] gpio: aggregator: clean up gpio_aggregator_free() Koichiro Den
2025-02-12 14:47   ` Geert Uytterhoeven
2025-02-03  3:12 ` [PATCH v2 08/10] gpio: aggregator: expoose aggregator created via legacy sysfs to configfs Koichiro Den
2025-02-04 13:12   ` Bartosz Golaszewski
2025-02-04 14:47     ` Koichiro Den
2025-02-12 15:36   ` Geert Uytterhoeven
2025-02-13 14:15     ` Koichiro Den
2025-02-03  3:12 ` [PATCH v2 09/10] gpio: aggregator: cancel deferred probe for devices created via configfs Koichiro Den
2025-02-04 13:14   ` Bartosz Golaszewski
2025-02-12 15:49     ` Geert Uytterhoeven [this message]
2025-02-16 13:15       ` Koichiro Den
2025-02-16 15:58         ` Bartosz Golaszewski
2025-02-17 12:52           ` Koichiro Den
2025-02-03  3:12 ` [PATCH v2 10/10] Documentation: gpio: document configfs interface for gpio-aggregator Koichiro Den
2025-02-12 15:55   ` Geert Uytterhoeven
2025-02-13 14:17     ` Koichiro Den
2025-02-12 13:14 ` [PATCH v2 00/10] Introduce configfs-based " Geert Uytterhoeven
2025-02-13 14:09   ` Koichiro Den

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=CAMuHMdU24x9pxEjBHTKxySxwr-L+iKXSUNFxpM9hvaSTNAWDuQ@mail.gmail.com \
    --to=geert@linux-m68k.org \
    --cc=brgl@bgdev.pl \
    --cc=koichiro.den@canonical.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maciej.borzecki@canonical.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 NNTP newsgroup(s).