| Message ID | 20241015-gpio-notify-in-kernel-events-v3-0-9edf05802271@linaro.org |
|---|---|
| Headers | show |
| Series | gpio: notify user-space about config changes in the kernel | expand |
On Tue, Oct 15, 2024 at 12:56:18PM +0200, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > > We currently only notify user-space about line config changes that are > made from user-space. Any kernel config changes are not signalled. > > Let's improve the situation by emitting the events closer to the source. > To that end let's call the relevant notifier chain from the functions > setting direction, gpiod_set_config(), gpiod_set_consumer_name() and > gpiod_toggle_active_low(). This covers all the options that we can > inform the user-space about. We ignore events which don't have > corresponding flags exported to user-space on purpose - otherwise the > user would see a config-changed event but the associated line-info would > remain unchanged. > > gpiod_direction_output/input() can be called from any context. > Fortunately, we now emit line state events using an atomic notifier > chain, so it's no longer an issue. > > Let's also add non-notifying wrappers around the direction setters in > order to not emit superfluous reconfigure events when requesting the > lines as the initial config should be part of the request notification. > > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > --- > drivers/gpio/gpiolib-cdev.c | 12 +++----- > drivers/gpio/gpiolib.c | 71 ++++++++++++++++++++++++++++++++++++++++----- > drivers/gpio/gpiolib.h | 2 ++ > 3 files changed, 70 insertions(+), 15 deletions(-) > > diff --git a/drivers/gpio/gpiolib-cdev.c b/drivers/gpio/gpiolib-cdev.c > index f8c69ef33888..1296e6cbcef7 100644 > --- a/drivers/gpio/gpiolib-cdev.c > +++ b/drivers/gpio/gpiolib-cdev.c > @@ -196,8 +196,6 @@ static long linehandle_set_config(struct linehandle_state *lh, > if (ret) > return ret; > } > - > - gpiod_line_state_notify(desc, GPIO_V2_LINE_CHANGED_CONFIG); > } > return 0; > } > @@ -363,11 +361,11 @@ static int linehandle_create(struct gpio_device *gdev, void __user *ip) > if (lflags & GPIOHANDLE_REQUEST_OUTPUT) { > int val = !!handlereq.default_values[i]; > > - ret = gpiod_direction_output(desc, val); > + ret = gpiod_direction_output_nonotify(desc, val); > if (ret) > goto out_free_lh; > } else if (lflags & GPIOHANDLE_REQUEST_INPUT) { > - ret = gpiod_direction_input(desc); > + ret = gpiod_direction_input_nonotify(desc); > if (ret) > goto out_free_lh; > } > @@ -1568,8 +1566,6 @@ static long linereq_set_config(struct linereq *lr, void __user *ip) > } > > WRITE_ONCE(line->edflags, edflags); > - > - gpiod_line_state_notify(desc, GPIO_V2_LINE_CHANGED_CONFIG); > } > return 0; > } > @@ -1826,11 +1822,11 @@ static int linereq_create(struct gpio_device *gdev, void __user *ip) > if (flags & GPIO_V2_LINE_FLAG_OUTPUT) { > int val = gpio_v2_line_config_output_value(lc, i); > > - ret = gpiod_direction_output(desc, val); > + ret = gpiod_direction_output_nonotify(desc, val); > if (ret) > goto out_free_linereq; > } else if (flags & GPIO_V2_LINE_FLAG_INPUT) { > - ret = gpiod_direction_input(desc); > + ret = gpiod_direction_input_nonotify(desc); > if (ret) > goto out_free_linereq; > > diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c > index fafa759ce743..4303b6a689af 100644 > --- a/drivers/gpio/gpiolib.c > +++ b/drivers/gpio/gpiolib.c > @@ -2673,6 +2673,18 @@ int gpio_set_debounce_timeout(struct gpio_desc *desc, unsigned int debounce) > * 0 on success, or negative errno on failure. > */ > int gpiod_direction_input(struct gpio_desc *desc) > +{ > + int ret; > + > + ret = gpiod_direction_input_nonotify(desc); > + if (ret == 0) > + gpiod_line_state_notify(desc, GPIO_V2_LINE_CHANGED_CONFIG); > + > + return ret; > +} > +EXPORT_SYMBOL_GPL(gpiod_direction_input); > + > +int gpiod_direction_input_nonotify(struct gpio_desc *desc) > { > int ret = 0; > > @@ -2720,7 +2732,6 @@ int gpiod_direction_input(struct gpio_desc *desc) > > return ret; > } > -EXPORT_SYMBOL_GPL(gpiod_direction_input); > > static int gpiod_direction_output_raw_commit(struct gpio_desc *desc, int value) > { > @@ -2782,8 +2793,15 @@ static int gpiod_direction_output_raw_commit(struct gpio_desc *desc, int value) > */ > int gpiod_direction_output_raw(struct gpio_desc *desc, int value) > { > + int ret; > + > VALIDATE_DESC(desc); > - return gpiod_direction_output_raw_commit(desc, value); > + > + ret = gpiod_direction_output_raw_commit(desc, value); > + if (ret == 0) > + gpiod_line_state_notify(desc, GPIO_V2_LINE_CHANGED_CONFIG); > + > + return ret; > } > EXPORT_SYMBOL_GPL(gpiod_direction_output_raw); > > @@ -2801,6 +2819,18 @@ EXPORT_SYMBOL_GPL(gpiod_direction_output_raw); > * 0 on success, or negative errno on failure. > */ > int gpiod_direction_output(struct gpio_desc *desc, int value) > +{ > + int ret; > + > + ret = gpiod_direction_output_nonotify(desc, value); > + if (ret == 0) > + gpiod_line_state_notify(desc, GPIO_V2_LINE_CHANGED_CONFIG); > + > + return ret; > +} > +EXPORT_SYMBOL_GPL(gpiod_direction_output); > + > +int gpiod_direction_output_nonotify(struct gpio_desc *desc, int value) > { > unsigned long flags; > int ret; > @@ -2863,7 +2893,6 @@ int gpiod_direction_output(struct gpio_desc *desc, int value) > set_bit(FLAG_IS_OUT, &desc->flags); > return ret; > } > -EXPORT_SYMBOL_GPL(gpiod_direction_output); > > /** > * gpiod_enable_hw_timestamp_ns - Enable hardware timestamp in nanoseconds. > @@ -2942,13 +2971,34 @@ EXPORT_SYMBOL_GPL(gpiod_disable_hw_timestamp_ns); > */ > int gpiod_set_config(struct gpio_desc *desc, unsigned long config) > { > + int ret; > + > VALIDATE_DESC(desc); > > CLASS(gpio_chip_guard, guard)(desc); > if (!guard.gc) > return -ENODEV; > > - return gpio_do_set_config(guard.gc, gpio_chip_hwgpio(desc), config); > + ret = gpio_do_set_config(guard.gc, gpio_chip_hwgpio(desc), config); > + if (ret == 0) { > + /* These are the only options we notify the userspace about. */ > + switch (pinconf_to_config_param(config)) { > + case PIN_CONFIG_BIAS_DISABLE: > + case PIN_CONFIG_BIAS_PULL_DOWN: > + case PIN_CONFIG_BIAS_PULL_UP: > + case PIN_CONFIG_DRIVE_OPEN_DRAIN: > + case PIN_CONFIG_DRIVE_OPEN_SOURCE: > + case PIN_CONFIG_DRIVE_PUSH_PULL: > + case PIN_CONFIG_INPUT_DEBOUNCE: > + gpiod_line_state_notify(desc, > + GPIO_V2_LINE_CHANGED_CONFIG); > + break; > + default: > + break; > + } > + } > + > + return ret; > } Ah, the debounce - I forgot about that, and other features that cdev might emulate. What happens if userspace requests a line with debounce that is supported by hardware? Seems to me we'll see both a LINE_REQUESTED and a LINE_CONFIG_CHANGED when the line is requested. Conversely, what if a config change impacts features that don't result in a notification from gpiod_set_config(), like active low, or emulated drive or debounce? Other than those little wrinkles, it all looks good to me. Though I haven't done any testing on it yet - will do as soon as I can. Cheers, Kent. > EXPORT_SYMBOL_GPL(gpiod_set_config); > > @@ -3015,6 +3065,7 @@ void gpiod_toggle_active_low(struct gpio_desc *desc) > { > VALIDATE_DESC_VOID(desc); > change_bit(FLAG_ACTIVE_LOW, &desc->flags); > + gpiod_line_state_notify(desc, GPIO_V2_LINE_CHANGED_CONFIG); > } > EXPORT_SYMBOL_GPL(gpiod_toggle_active_low); > > @@ -3659,9 +3710,15 @@ EXPORT_SYMBOL_GPL(gpiod_cansleep); > */ > int gpiod_set_consumer_name(struct gpio_desc *desc, const char *name) > { > + int ret; > + > VALIDATE_DESC(desc); > > - return desc_set_label(desc, name); > + ret = desc_set_label(desc, name); > + if (ret == 0) > + gpiod_line_state_notify(desc, GPIO_V2_LINE_CHANGED_CONFIG); > + > + return ret; > } > EXPORT_SYMBOL_GPL(gpiod_set_consumer_name); > > @@ -4539,10 +4596,10 @@ int gpiod_configure_flags(struct gpio_desc *desc, const char *con_id, > > /* Process flags */ > if (dflags & GPIOD_FLAGS_BIT_DIR_OUT) > - ret = gpiod_direction_output(desc, > + ret = gpiod_direction_output_nonotify(desc, > !!(dflags & GPIOD_FLAGS_BIT_DIR_VAL)); > else > - ret = gpiod_direction_input(desc); > + ret = gpiod_direction_input_nonotify(desc); > > return ret; > } > diff --git a/drivers/gpio/gpiolib.h b/drivers/gpio/gpiolib.h > index 2799157a1f6b..fc321d281346 100644 > --- a/drivers/gpio/gpiolib.h > +++ b/drivers/gpio/gpiolib.h > @@ -155,6 +155,8 @@ int gpiod_set_array_value_complex(bool raw, bool can_sleep, > int gpiod_set_transitory(struct gpio_desc *desc, bool transitory); > > void gpiod_line_state_notify(struct gpio_desc *desc, unsigned long action); > +int gpiod_direction_output_nonotify(struct gpio_desc *desc, int value); > +int gpiod_direction_input_nonotify(struct gpio_desc *desc); > > struct gpio_desc_label { > struct rcu_head rh; > > -- > 2.43.0 >
On Wed, Oct 16, 2024 at 01:19:44PM +0800, Kent Gibson wrote: > On Tue, Oct 15, 2024 at 12:56:18PM +0200, Bartosz Golaszewski wrote: > > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > > > > - return gpio_do_set_config(guard.gc, gpio_chip_hwgpio(desc), config); > > + ret = gpio_do_set_config(guard.gc, gpio_chip_hwgpio(desc), config); > > + if (ret == 0) { > > + /* These are the only options we notify the userspace about. */ > > + switch (pinconf_to_config_param(config)) { > > + case PIN_CONFIG_BIAS_DISABLE: > > + case PIN_CONFIG_BIAS_PULL_DOWN: > > + case PIN_CONFIG_BIAS_PULL_UP: > > + case PIN_CONFIG_DRIVE_OPEN_DRAIN: > > + case PIN_CONFIG_DRIVE_OPEN_SOURCE: > > + case PIN_CONFIG_DRIVE_PUSH_PULL: > > + case PIN_CONFIG_INPUT_DEBOUNCE: > > + gpiod_line_state_notify(desc, > > + GPIO_V2_LINE_CHANGED_CONFIG); > > + break; > > + default: > > + break; > > + } > > + } > > + > > + return ret; > > } > > Ah, the debounce - I forgot about that, and other features that cdev > might emulate. > > What happens if userspace requests a line with debounce that is > supported by hardware? Seems to me we'll see both a LINE_REQUESTED and a > LINE_CONFIG_CHANGED when the line is requested. > This is problematic for me to test at the moment, as gpiosim doesn't support debounce. Any chance we could make that configurable? Similarly drive. > Conversely, what if a config change impacts features that don't result in a > notification from gpiod_set_config(), like active low, or emulated > drive or debounce? > Bah, drive is emulated in gpiolib itself, so that should be fine. When changing config cdev always calls gpiod_direction_input/output(), so I think that covers the active low case. But I have a test taking a line from input to output|open_drain and I get two change events. The first is the most interesting as it reports input|open_drain, the second then reports output|open_drain. That is due to gpiod_direction_output() calling gpiod_set_config() to set the drive, and later to set the direction, in that order. Given it will be setting the direction, it should inhibit the event from the drive setting? Still haven't tested any debounce changes... Cheers, Kent.
On Wed, Oct 16, 2024 at 9:27 AM Kent Gibson <warthog618@gmail.com> wrote: > > On Wed, Oct 16, 2024 at 01:19:44PM +0800, Kent Gibson wrote: > > On Tue, Oct 15, 2024 at 12:56:18PM +0200, Bartosz Golaszewski wrote: > > > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > > > > > > - return gpio_do_set_config(guard.gc, gpio_chip_hwgpio(desc), config); > > > + ret = gpio_do_set_config(guard.gc, gpio_chip_hwgpio(desc), config); > > > + if (ret == 0) { > > > + /* These are the only options we notify the userspace about. */ > > > + switch (pinconf_to_config_param(config)) { > > > + case PIN_CONFIG_BIAS_DISABLE: > > > + case PIN_CONFIG_BIAS_PULL_DOWN: > > > + case PIN_CONFIG_BIAS_PULL_UP: > > > + case PIN_CONFIG_DRIVE_OPEN_DRAIN: > > > + case PIN_CONFIG_DRIVE_OPEN_SOURCE: > > > + case PIN_CONFIG_DRIVE_PUSH_PULL: > > > + case PIN_CONFIG_INPUT_DEBOUNCE: > > > + gpiod_line_state_notify(desc, > > > + GPIO_V2_LINE_CHANGED_CONFIG); > > > + break; > > > + default: > > > + break; > > > + } > > > + } > > > + > > > + return ret; > > > } > > > > Ah, the debounce - I forgot about that, and other features that cdev > > might emulate. > > > > What happens if userspace requests a line with debounce that is > > supported by hardware? Seems to me we'll see both a LINE_REQUESTED and a > > LINE_CONFIG_CHANGED when the line is requested. > > > > This is problematic for me to test at the moment, as gpiosim doesn't support > debounce. Any chance we could make that configurable? Similarly drive. > > > Conversely, what if a config change impacts features that don't result in a > > notification from gpiod_set_config(), like active low, or emulated > > drive or debounce? > > > > Bah, drive is emulated in gpiolib itself, so that should be fine. > > When changing config cdev always calls gpiod_direction_input/output(), so I > think that covers the active low case. > > But I have a test taking a line from input to output|open_drain and I > get two change events. The first is the most interesting as it reports > input|open_drain, the second then reports output|open_drain. > That is due to gpiod_direction_output() calling gpiod_set_config() to No, it never calls gpiod_set_config() but gpio_set_config() which never emits an event. > set the drive, and later to set the direction, in that order. > Given it will be setting the direction, it should inhibit the event from > the drive setting? I think you're really hitting this: https://github.com/brgl/linux/blob/b4/gpio-notify-in-kernel-events/drivers/gpio/gpiolib.c#L2863 These should be changed to nonotify variants too. Would you mind confirming? Bart > > Still haven't tested any debounce changes... > > Cheers, > Kent.
On Wed, Oct 16, 2024 at 03:27:30PM +0800, Kent Gibson wrote: > On Wed, Oct 16, 2024 at 01:19:44PM +0800, Kent Gibson wrote: > > On Tue, Oct 15, 2024 at 12:56:18PM +0200, Bartosz Golaszewski wrote: > > > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > > > > > > - return gpio_do_set_config(guard.gc, gpio_chip_hwgpio(desc), config); > > > + ret = gpio_do_set_config(guard.gc, gpio_chip_hwgpio(desc), config); > > > + if (ret == 0) { > > > + /* These are the only options we notify the userspace about. */ > > > + switch (pinconf_to_config_param(config)) { > > > + case PIN_CONFIG_BIAS_DISABLE: > > > + case PIN_CONFIG_BIAS_PULL_DOWN: > > > + case PIN_CONFIG_BIAS_PULL_UP: > > > + case PIN_CONFIG_DRIVE_OPEN_DRAIN: > > > + case PIN_CONFIG_DRIVE_OPEN_SOURCE: > > > + case PIN_CONFIG_DRIVE_PUSH_PULL: > > > + case PIN_CONFIG_INPUT_DEBOUNCE: > > > + gpiod_line_state_notify(desc, > > > + GPIO_V2_LINE_CHANGED_CONFIG); > > > + break; > > > + default: > > > + break; > > > + } > > > + } > > > + > > > + return ret; > > > } > > > > Ah, the debounce - I forgot about that, and other features that cdev > > might emulate. > > > > What happens if userspace requests a line with debounce that is > > supported by hardware? Seems to me we'll see both a LINE_REQUESTED and a > > LINE_CONFIG_CHANGED when the line is requested. > > > > This is problematic for me to test at the moment, as gpiosim doesn't support > debounce. Any chance we could make that configurable? Similarly drive. > > > Conversely, what if a config change impacts features that don't result in a > > notification from gpiod_set_config(), like active low, or emulated > > drive or debounce? > > > > Bah, drive is emulated in gpiolib itself, so that should be fine. > > When changing config cdev always calls gpiod_direction_input/output(), so I > think that covers the active low case. > > But I have a test taking a line from input to output|open_drain and I > get two change events. The first is the most interesting as it reports > input|open_drain, the second then reports output|open_drain. > That is due to gpiod_direction_output() calling gpiod_set_config() to > set the drive, and later to set the direction, in that order. > Given it will be setting the direction, it should inhibit the event from > the drive setting? > Ok, I oversimplified, it was actually input -> output|active_low|open_drain and input -> output|open_source fails the same way. > Still haven't tested any debounce changes... > Have now. input -> input|debounce does not report the debounce. Only get the one event and it does not contain any debounce. Similarly input -> input|edge|debounce which exercises a different path through cdev. Cheers, Kent.
On Wed, 16 Oct 2024 10:37:47 +0200, Kent Gibson <warthog618@gmail.com> said: > On Wed, Oct 16, 2024 at 03:27:30PM +0800, Kent Gibson wrote: >> On Wed, Oct 16, 2024 at 01:19:44PM +0800, Kent Gibson wrote: >> > On Tue, Oct 15, 2024 at 12:56:18PM +0200, Bartosz Golaszewski wrote: >> > > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> >> > > >> > > - return gpio_do_set_config(guard.gc, gpio_chip_hwgpio(desc), config); >> > > + ret = gpio_do_set_config(guard.gc, gpio_chip_hwgpio(desc), config); >> > > + if (ret == 0) { >> > > + /* These are the only options we notify the userspace about. */ >> > > + switch (pinconf_to_config_param(config)) { >> > > + case PIN_CONFIG_BIAS_DISABLE: >> > > + case PIN_CONFIG_BIAS_PULL_DOWN: >> > > + case PIN_CONFIG_BIAS_PULL_UP: >> > > + case PIN_CONFIG_DRIVE_OPEN_DRAIN: >> > > + case PIN_CONFIG_DRIVE_OPEN_SOURCE: >> > > + case PIN_CONFIG_DRIVE_PUSH_PULL: >> > > + case PIN_CONFIG_INPUT_DEBOUNCE: >> > > + gpiod_line_state_notify(desc, >> > > + GPIO_V2_LINE_CHANGED_CONFIG); >> > > + break; >> > > + default: >> > > + break; >> > > + } >> > > + } >> > > + >> > > + return ret; >> > > } >> > >> > Ah, the debounce - I forgot about that, and other features that cdev >> > might emulate. >> > >> > What happens if userspace requests a line with debounce that is >> > supported by hardware? Seems to me we'll see both a LINE_REQUESTED and a >> > LINE_CONFIG_CHANGED when the line is requested. >> > >> >> This is problematic for me to test at the moment, as gpiosim doesn't support >> debounce. Any chance we could make that configurable? Similarly drive. >> >> > Conversely, what if a config change impacts features that don't result in a >> > notification from gpiod_set_config(), like active low, or emulated >> > drive or debounce? >> > >> >> Bah, drive is emulated in gpiolib itself, so that should be fine. >> >> When changing config cdev always calls gpiod_direction_input/output(), so I >> think that covers the active low case. >> >> But I have a test taking a line from input to output|open_drain and I >> get two change events. The first is the most interesting as it reports >> input|open_drain, the second then reports output|open_drain. >> That is due to gpiod_direction_output() calling gpiod_set_config() to >> set the drive, and later to set the direction, in that order. >> Given it will be setting the direction, it should inhibit the event from >> the drive setting? >> > > Ok, I oversimplified, it was actually > > input -> output|active_low|open_drain > > and > > input -> output|open_source > > fails the same way. > Does the following help? @@ -2830,7 +2860,7 @@ int gpiod_direction_output(struct gpio_desc *desc, int value) goto set_output_value; /* Emulate open drain by not actively driving the line high */ if (value) { - ret = gpiod_direction_input(desc); + ret = gpiod_direction_input_nonotify(desc); goto set_output_flag; } } else if (test_bit(FLAG_OPEN_SOURCE, &flags)) { @@ -2839,7 +2869,7 @@ int gpiod_direction_output(struct gpio_desc *desc, int value) goto set_output_value; /* Emulate open source by not actively driving the line low */ if (!value) { - ret = gpiod_direction_input(desc); + ret = gpiod_direction_input_nonotify(desc); goto set_output_flag; } } else { >> Still haven't tested any debounce changes... >> > > Have now. > > input -> input|debounce > > does not report the debounce. Only get the one event and it does not > contain any debounce. > You mean, you get a CHANGED_CONFIG event but the debounce value is not in the associated line info? > Similarly > > input -> input|edge|debounce > > which exercises a different path through cdev. > > Cheers, > Kent. > Bart
On Wed, Oct 16, 2024 at 09:50:58AM +0200, Bartosz Golaszewski wrote: > On Wed, Oct 16, 2024 at 9:27 AM Kent Gibson <warthog618@gmail.com> wrote: > > > > On Wed, Oct 16, 2024 at 01:19:44PM +0800, Kent Gibson wrote: > > > On Tue, Oct 15, 2024 at 12:56:18PM +0200, Bartosz Golaszewski wrote: > > > > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > > > > > > > > - return gpio_do_set_config(guard.gc, gpio_chip_hwgpio(desc), config); > > > > + ret = gpio_do_set_config(guard.gc, gpio_chip_hwgpio(desc), config); > > > > + if (ret == 0) { > > > > + /* These are the only options we notify the userspace about. */ > > > > + switch (pinconf_to_config_param(config)) { > > > > + case PIN_CONFIG_BIAS_DISABLE: > > > > + case PIN_CONFIG_BIAS_PULL_DOWN: > > > > + case PIN_CONFIG_BIAS_PULL_UP: > > > > + case PIN_CONFIG_DRIVE_OPEN_DRAIN: > > > > + case PIN_CONFIG_DRIVE_OPEN_SOURCE: > > > > + case PIN_CONFIG_DRIVE_PUSH_PULL: > > > > + case PIN_CONFIG_INPUT_DEBOUNCE: > > > > + gpiod_line_state_notify(desc, > > > > + GPIO_V2_LINE_CHANGED_CONFIG); > > > > + break; > > > > + default: > > > > + break; > > > > + } > > > > + } > > > > + > > > > + return ret; > > > > } > > > > > > Ah, the debounce - I forgot about that, and other features that cdev > > > might emulate. > > > > > > What happens if userspace requests a line with debounce that is > > > supported by hardware? Seems to me we'll see both a LINE_REQUESTED and a > > > LINE_CONFIG_CHANGED when the line is requested. > > > > > > > This is problematic for me to test at the moment, as gpiosim doesn't support > > debounce. Any chance we could make that configurable? Similarly drive. > > > > > Conversely, what if a config change impacts features that don't result in a > > > notification from gpiod_set_config(), like active low, or emulated > > > drive or debounce? > > > > > > > Bah, drive is emulated in gpiolib itself, so that should be fine. > > > > When changing config cdev always calls gpiod_direction_input/output(), so I > > think that covers the active low case. > > > > But I have a test taking a line from input to output|open_drain and I > > get two change events. The first is the most interesting as it reports > > input|open_drain, the second then reports output|open_drain. > > That is due to gpiod_direction_output() calling gpiod_set_config() to > > No, it never calls gpiod_set_config() but gpio_set_config() which > never emits an event. > Depends whether the driver supports drive or not. If it does then line 2858: ret = gpio_set_config(desc, PIN_CONFIG_DRIVE_OPEN_DRAIN); will emit. So your _nonotify function is calling a bunch of functions that can emit. Cheers, Kent.
On Wed, Oct 16, 2024 at 10:57 AM Kent Gibson <warthog618@gmail.com> wrote: > > On Wed, Oct 16, 2024 at 09:50:58AM +0200, Bartosz Golaszewski wrote: > > On Wed, Oct 16, 2024 at 9:27 AM Kent Gibson <warthog618@gmail.com> wrote: > > > > > > On Wed, Oct 16, 2024 at 01:19:44PM +0800, Kent Gibson wrote: > > > > On Tue, Oct 15, 2024 at 12:56:18PM +0200, Bartosz Golaszewski wrote: > > > > > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > > > > > > > > > > - return gpio_do_set_config(guard.gc, gpio_chip_hwgpio(desc), config); > > > > > + ret = gpio_do_set_config(guard.gc, gpio_chip_hwgpio(desc), config); > > > > > + if (ret == 0) { > > > > > + /* These are the only options we notify the userspace about. */ > > > > > + switch (pinconf_to_config_param(config)) { > > > > > + case PIN_CONFIG_BIAS_DISABLE: > > > > > + case PIN_CONFIG_BIAS_PULL_DOWN: > > > > > + case PIN_CONFIG_BIAS_PULL_UP: > > > > > + case PIN_CONFIG_DRIVE_OPEN_DRAIN: > > > > > + case PIN_CONFIG_DRIVE_OPEN_SOURCE: > > > > > + case PIN_CONFIG_DRIVE_PUSH_PULL: > > > > > + case PIN_CONFIG_INPUT_DEBOUNCE: > > > > > + gpiod_line_state_notify(desc, > > > > > + GPIO_V2_LINE_CHANGED_CONFIG); > > > > > + break; > > > > > + default: > > > > > + break; > > > > > + } > > > > > + } > > > > > + > > > > > + return ret; > > > > > } > > > > > > > > Ah, the debounce - I forgot about that, and other features that cdev > > > > might emulate. > > > > > > > > What happens if userspace requests a line with debounce that is > > > > supported by hardware? Seems to me we'll see both a LINE_REQUESTED and a > > > > LINE_CONFIG_CHANGED when the line is requested. > > > > > > > > > > This is problematic for me to test at the moment, as gpiosim doesn't support > > > debounce. Any chance we could make that configurable? Similarly drive. > > > > > > > Conversely, what if a config change impacts features that don't result in a > > > > notification from gpiod_set_config(), like active low, or emulated > > > > drive or debounce? > > > > > > > > > > Bah, drive is emulated in gpiolib itself, so that should be fine. > > > > > > When changing config cdev always calls gpiod_direction_input/output(), so I > > > think that covers the active low case. > > > > > > But I have a test taking a line from input to output|open_drain and I > > > get two change events. The first is the most interesting as it reports > > > input|open_drain, the second then reports output|open_drain. > > > That is due to gpiod_direction_output() calling gpiod_set_config() to > > > > No, it never calls gpiod_set_config() but gpio_set_config() which > > never emits an event. > > > > Depends whether the driver supports drive or not. > > If it does then > line 2858: > > ret = gpio_set_config(desc, PIN_CONFIG_DRIVE_OPEN_DRAIN); > I'm seeing this: gpiod_direction_output_nonotify() gpio_set_config() gpio_set_config_with_argument() gpio_do_set_config() gc->set_config() There's no call to gpiod_line_state_notify() in this path. Bart > will emit. > > So your _nonotify function is calling a bunch of functions that can > emit. > > Cheers, > Kent.
On Wed, Oct 16, 2024 at 11:02:37AM +0200, Bartosz Golaszewski wrote: > On Wed, Oct 16, 2024 at 10:57 AM Kent Gibson <warthog618@gmail.com> wrote: > > > > On Wed, Oct 16, 2024 at 09:50:58AM +0200, Bartosz Golaszewski wrote: > > > On Wed, Oct 16, 2024 at 9:27 AM Kent Gibson <warthog618@gmail.com> wrote: > > > > > > > > On Wed, Oct 16, 2024 at 01:19:44PM +0800, Kent Gibson wrote: > > > > > On Tue, Oct 15, 2024 at 12:56:18PM +0200, Bartosz Golaszewski wrote: > > > > > > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > > > > > > > > > > > > - return gpio_do_set_config(guard.gc, gpio_chip_hwgpio(desc), config); > > > > > > + ret = gpio_do_set_config(guard.gc, gpio_chip_hwgpio(desc), config); > > > > > > + if (ret == 0) { > > > > > > + /* These are the only options we notify the userspace about. */ > > > > > > + switch (pinconf_to_config_param(config)) { > > > > > > + case PIN_CONFIG_BIAS_DISABLE: > > > > > > + case PIN_CONFIG_BIAS_PULL_DOWN: > > > > > > + case PIN_CONFIG_BIAS_PULL_UP: > > > > > > + case PIN_CONFIG_DRIVE_OPEN_DRAIN: > > > > > > + case PIN_CONFIG_DRIVE_OPEN_SOURCE: > > > > > > + case PIN_CONFIG_DRIVE_PUSH_PULL: > > > > > > + case PIN_CONFIG_INPUT_DEBOUNCE: > > > > > > + gpiod_line_state_notify(desc, > > > > > > + GPIO_V2_LINE_CHANGED_CONFIG); > > > > > > + break; > > > > > > + default: > > > > > > + break; > > > > > > + } > > > > > > + } > > > > > > + > > > > > > + return ret; > > > > > > } > > > > > > > > > > Ah, the debounce - I forgot about that, and other features that cdev > > > > > might emulate. > > > > > > > > > > What happens if userspace requests a line with debounce that is > > > > > supported by hardware? Seems to me we'll see both a LINE_REQUESTED and a > > > > > LINE_CONFIG_CHANGED when the line is requested. > > > > > > > > > > > > > This is problematic for me to test at the moment, as gpiosim doesn't support > > > > debounce. Any chance we could make that configurable? Similarly drive. > > > > > > > > > Conversely, what if a config change impacts features that don't result in a > > > > > notification from gpiod_set_config(), like active low, or emulated > > > > > drive or debounce? > > > > > > > > > > > > > Bah, drive is emulated in gpiolib itself, so that should be fine. > > > > > > > > When changing config cdev always calls gpiod_direction_input/output(), so I > > > > think that covers the active low case. > > > > > > > > But I have a test taking a line from input to output|open_drain and I > > > > get two change events. The first is the most interesting as it reports > > > > input|open_drain, the second then reports output|open_drain. > > > > That is due to gpiod_direction_output() calling gpiod_set_config() to > > > > > > No, it never calls gpiod_set_config() but gpio_set_config() which > > > never emits an event. > > > > > > > Depends whether the driver supports drive or not. > > > > If it does then > > line 2858: > > > > ret = gpio_set_config(desc, PIN_CONFIG_DRIVE_OPEN_DRAIN); > > > > I'm seeing this: > > gpiod_direction_output_nonotify() > gpio_set_config() > gpio_set_config_with_argument() > gpio_do_set_config() > gc->set_config() > > There's no call to gpiod_line_state_notify() in this path. > Ah, my bad - thought it was gpiod_set_config(). So it is just the gpiod_direction_input() calls. Cheers, Kent.
On Wed, Oct 16, 2024 at 01:52:49AM -0700, Bartosz Golaszewski wrote: > On Wed, 16 Oct 2024 10:37:47 +0200, Kent Gibson <warthog618@gmail.com> said: > > On Wed, Oct 16, 2024 at 03:27:30PM +0800, Kent Gibson wrote: > >> On Wed, Oct 16, 2024 at 01:19:44PM +0800, Kent Gibson wrote: > >> > On Tue, Oct 15, 2024 at 12:56:18PM +0200, Bartosz Golaszewski wrote: > >> > > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > >> > > > >> > > - return gpio_do_set_config(guard.gc, gpio_chip_hwgpio(desc), config); > >> > > + ret = gpio_do_set_config(guard.gc, gpio_chip_hwgpio(desc), config); > >> > > + if (ret == 0) { > >> > > + /* These are the only options we notify the userspace about. */ > >> > > + switch (pinconf_to_config_param(config)) { > >> > > + case PIN_CONFIG_BIAS_DISABLE: > >> > > + case PIN_CONFIG_BIAS_PULL_DOWN: > >> > > + case PIN_CONFIG_BIAS_PULL_UP: > >> > > + case PIN_CONFIG_DRIVE_OPEN_DRAIN: > >> > > + case PIN_CONFIG_DRIVE_OPEN_SOURCE: > >> > > + case PIN_CONFIG_DRIVE_PUSH_PULL: > >> > > + case PIN_CONFIG_INPUT_DEBOUNCE: > >> > > + gpiod_line_state_notify(desc, > >> > > + GPIO_V2_LINE_CHANGED_CONFIG); > >> > > + break; > >> > > + default: > >> > > + break; > >> > > + } > >> > > + } > >> > > + > >> > > + return ret; > >> > > } > >> > > >> > Ah, the debounce - I forgot about that, and other features that cdev > >> > might emulate. > >> > > >> > What happens if userspace requests a line with debounce that is > >> > supported by hardware? Seems to me we'll see both a LINE_REQUESTED and a > >> > LINE_CONFIG_CHANGED when the line is requested. > >> > > >> > >> This is problematic for me to test at the moment, as gpiosim doesn't support > >> debounce. Any chance we could make that configurable? Similarly drive. > >> > >> > Conversely, what if a config change impacts features that don't result in a > >> > notification from gpiod_set_config(), like active low, or emulated > >> > drive or debounce? > >> > > >> > >> Bah, drive is emulated in gpiolib itself, so that should be fine. > >> > >> When changing config cdev always calls gpiod_direction_input/output(), so I > >> think that covers the active low case. > >> > >> But I have a test taking a line from input to output|open_drain and I > >> get two change events. The first is the most interesting as it reports > >> input|open_drain, the second then reports output|open_drain. > >> That is due to gpiod_direction_output() calling gpiod_set_config() to > >> set the drive, and later to set the direction, in that order. > >> Given it will be setting the direction, it should inhibit the event from > >> the drive setting? > >> > > > > Ok, I oversimplified, it was actually > > > > input -> output|active_low|open_drain > > > > and > > > > input -> output|open_source > > > > fails the same way. > > > > Does the following help? > > @@ -2830,7 +2860,7 @@ int gpiod_direction_output(struct gpio_desc > *desc, int value) > goto set_output_value; > /* Emulate open drain by not actively driving the line high */ > if (value) { > - ret = gpiod_direction_input(desc); > + ret = gpiod_direction_input_nonotify(desc); > goto set_output_flag; > } > } else if (test_bit(FLAG_OPEN_SOURCE, &flags)) { > @@ -2839,7 +2869,7 @@ int gpiod_direction_output(struct gpio_desc > *desc, int value) > goto set_output_value; > /* Emulate open source by not actively driving the line low */ > if (!value) { > - ret = gpiod_direction_input(desc); > + ret = gpiod_direction_input_nonotify(desc); > goto set_output_flag; > } > } else { > That fixes the drive problems. > >> Still haven't tested any debounce changes... > >> > > > > Have now. > > > > input -> input|debounce > > > > does not report the debounce. Only get the one event and it does not > > contain any debounce. > > > > You mean, you get a CHANGED_CONFIG event but the debounce value is not > in the associated line info? > Correct. Cheers, Kent.
On Wed, Oct 16, 2024 at 11:17 AM Kent Gibson <warthog618@gmail.com> wrote: > > > > > Does the following help? > > > > @@ -2830,7 +2860,7 @@ int gpiod_direction_output(struct gpio_desc > > *desc, int value) > > goto set_output_value; > > /* Emulate open drain by not actively driving the line high */ > > if (value) { > > - ret = gpiod_direction_input(desc); > > + ret = gpiod_direction_input_nonotify(desc); > > goto set_output_flag; > > } > > } else if (test_bit(FLAG_OPEN_SOURCE, &flags)) { > > @@ -2839,7 +2869,7 @@ int gpiod_direction_output(struct gpio_desc > > *desc, int value) > > goto set_output_value; > > /* Emulate open source by not actively driving the line low */ > > if (!value) { > > - ret = gpiod_direction_input(desc); > > + ret = gpiod_direction_input_nonotify(desc); > > goto set_output_flag; > > } > > } else { > > > > That fixes the drive problems. > Ok, thanks. > > >> Still haven't tested any debounce changes... > > >> > > > > > > Have now. > > > > > > input -> input|debounce > > > > > > does not report the debounce. Only get the one event and it does not > > > contain any debounce. > > > > > > > You mean, you get a CHANGED_CONFIG event but the debounce value is not > > in the associated line info? > > > > Correct. > Ok, let me see. Bart
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 :(. Cheers, Kent.
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? Bart
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.
We currently only emit events on changed line config to user-space on changes made from user-space. Users have no way of getting notified about in-kernel changes. This series improves the situation and also contains a couple other related improvements. This is a reworked approach which gets and stores as much info (all of it actually, except for the pinctrl state) the moment the event occurrs but moves the actual queueing of the event on the kfifo to a dedicated high-priority, ordered workqueue. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> --- Changes in v3: - don't reach into pinctrl if the USED flag is already set - reword the comment from patch 5 and move it one patch back - don't abandon emitting the event if the GPIO chip is gone by the time the work is executed, just don't reach into pinctrl and return whatever data we already had - Link to v2: https://lore.kernel.org/r/20241010-gpio-notify-in-kernel-events-v2-0-b560411f7c59@linaro.org Changes in v2: - put all line-info events emitting on a workqueue to allow queueing them from atomic context - switch the notifier type used for emitting info events to atomic - add a patch notifying user-space about drivers requesting their own descs - drop patches that were picked up - Link to v1: https://lore.kernel.org/r/20241004-gpio-notify-in-kernel-events-v1-0-8ac29e1df4fe@linaro.org --- Bartosz Golaszewski (6): gpiolib: notify user-space when a driver requests its own desc gpio: cdev: prepare gpio_desc_to_lineinfo() for being called from atomic gpiolib: add a per-gpio_device line state notification workqueue gpio: cdev: put emitting the line state events on a workqueue gpiolib: switch the line state notifier to atomic gpiolib: notify user-space about in-kernel line state changes drivers/gpio/gpiolib-cdev.c | 127 +++++++++++++++++++++++++++++++++----------- drivers/gpio/gpiolib.c | 79 +++++++++++++++++++++++---- drivers/gpio/gpiolib.h | 8 ++- 3 files changed, 172 insertions(+), 42 deletions(-) --- base-commit: b852e1e7a0389ed6168ef1d38eb0bad71a6b11e8 change-id: 20240924-gpio-notify-in-kernel-events-07cd912153e8 Best regards,