public inbox for linux-gpio@vger.kernel.org
 help / color / mirror / Atom feed
From: Kent Gibson <warthog618@gmail.com>
To: Bartosz Golaszewski <brgl@bgdev.pl>
Cc: Linus Walleij <linus.walleij@linaro.org>,
	linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org,
	Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Subject: Re: [PATCH v3 6/6] gpiolib: notify user-space about in-kernel line state changes
Date: Wed, 16 Oct 2024 18:22:12 +0800	[thread overview]
Message-ID: <20241016102212.GA236073@rigel> (raw)
In-Reply-To: <CAMRc=Mefz=EBd6us-eK8kqk8zL0=LsEWUkP3JB7a0M7xcT8z8Q@mail.gmail.com>

On Wed, Oct 16, 2024 at 12:12:10PM +0200, Bartosz Golaszewski wrote:
> On Wed, Oct 16, 2024 at 11:43 AM Kent Gibson <warthog618@gmail.com> wrote:
> >
> > On Wed, Oct 16, 2024 at 11:22:07AM +0200, Bartosz Golaszewski wrote:
> > > On Wed, Oct 16, 2024 at 11:17 AM Kent Gibson <warthog618@gmail.com> wrote:
> > > >
> > > > > >
> > > > >
> > > > > You mean, you get a CHANGED_CONFIG event but the debounce value is not
> > > > > in the associated line info?
> > > > >
> > > >
> > > > Correct.
> > > >
> > >
> > > Ok, let me see.
> > >
> >
> > When setting from userspace the issue is that linereq_set_config() setting the
> > direction will emit, quite possibly before the debounce has been set.  The
> > edge_detector_setup() that does set it can also emit, though only if the
> > hardware supports debounce.  And then there could be a race between the
> > notifier being called and the period being set in the supinfo.
> > (the set will probably win that one)
> >
> > Debounce set from the kernel side is going to be an issue as cdev
> > catches and stores the value from userspace to report in the supinfo - that
> > isn't the case for kernel calls to gpiod_set_config().
> >
> > Seems moving the debounce value out of the desc and into cdev, which seemed a
> > good idea at the time, might come back and bite now if it is no longer
> > restricted to being cdev specific.  Now there is an actual reason to
> > store it in the desc :(.
> >
>
> I'm seeing commit:
>
> commit 9344e34e7992fec95ce6210d95ac01437dd327ab
> Author: Kent Gibson <warthog618@gmail.com>
> Date:   Tue Dec 19 08:41:54 2023 +0800
>
>     gpiolib: cdev: relocate debounce_period_us from struct gpio_desc
>
>     Store the debounce period for a requested line locally, rather than in
>     the debounce_period_us field in the gpiolib struct gpio_desc.
>
>     Add a global tree of lines containing supplemental line information
>     to make the debounce period available to be reported by the
>     GPIO_V2_GET_LINEINFO_IOCTL and the line change notifier.
>
>     Signed-off-by: Kent Gibson <warthog618@gmail.com>
>     Reviewed-by: Andy Shevchenko <andy@kernel.org>
>     Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>
> But it doesn't explain *why* we did this and I don't remember the
> story behind this change.
>
> How bad would it be to go back to storing the debounce setting in the
> descriptor?
>

At the time it was only being used in cdev, and moving it into cdev was
just about not exporting cdev specific stuff to the rest of the kernel.
So it was just tidying up.
But if cdev is now reporting the configuration of the line independent
of whether it was set from userspace or the kernel then it actually
makes more sense for that state to be stored in the desc.

I don't have any objections to that commit being reverted.

Cheers,
Kent.



      reply	other threads:[~2024-10-16 10:22 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-15 10:56 [PATCH v3 0/6] gpio: notify user-space about config changes in the kernel Bartosz Golaszewski
2024-10-15 10:56 ` [PATCH v3 1/6] gpiolib: notify user-space when a driver requests its own desc Bartosz Golaszewski
2024-10-15 10:56 ` [PATCH v3 2/6] gpio: cdev: prepare gpio_desc_to_lineinfo() for being called from atomic Bartosz Golaszewski
2024-10-15 10:56 ` [PATCH v3 3/6] gpiolib: add a per-gpio_device line state notification workqueue Bartosz Golaszewski
2024-10-15 10:56 ` [PATCH v3 4/6] gpio: cdev: put emitting the line state events on a workqueue Bartosz Golaszewski
2024-10-15 10:56 ` [PATCH v3 5/6] gpiolib: switch the line state notifier to atomic Bartosz Golaszewski
2024-10-15 10:56 ` [PATCH v3 6/6] gpiolib: notify user-space about in-kernel line state changes Bartosz Golaszewski
2024-10-16  5:19   ` Kent Gibson
2024-10-16  7:27     ` Kent Gibson
2024-10-16  7:50       ` Bartosz Golaszewski
2024-10-16  8:57         ` Kent Gibson
2024-10-16  9:02           ` Bartosz Golaszewski
2024-10-16  9:08             ` Kent Gibson
2024-10-16  8:37       ` Kent Gibson
2024-10-16  8:52         ` Bartosz Golaszewski
2024-10-16  9:17           ` Kent Gibson
2024-10-16  9:22             ` Bartosz Golaszewski
2024-10-16  9:43               ` Kent Gibson
2024-10-16 10:12                 ` Bartosz Golaszewski
2024-10-16 10:22                   ` Kent Gibson [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=20241016102212.GA236073@rigel \
    --to=warthog618@gmail.com \
    --cc=bartosz.golaszewski@linaro.org \
    --cc=brgl@bgdev.pl \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox