gpiolib: notify user-space about line state changes triggered by kernel
PATCH v2 1/1 gpiolib: notify user-space about line state changes triggered by kernel
From: Bartosz Golaszewski <[email protected]>
We currently only emit CHANGED_CONFIG events when the user-space changes GPIO config. We won't be notified if changes come from in-kernel. Let's call the notifier chain whenever kernel users change direction or any of the active-low, debounce or consumer name settings. We don't notify the user-space about the persistence as the uAPI has no notion of it.
---
v1 -> v2:
- use the gpiod_line_state_notify() helper
- reorder the code in gpiod_set_debounce() for better readability
drivers/gpio/gpiolib.c | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-)
drivers/gpio/gpiolib.c +14 -2
@@ -2439,6 +2439,7 @@ int gpiod_direction_input(struct gpio_desc *desc) }if (ret ==0 ) {clear_bit (FLAG_IS_OUT , &desc->flags); +gpiod_line_state_notify (desc,GPIO_V2_LINE_CHANGED_CONFIG ); ret =gpio_set_bias (desc); }
@@ -2484,8 +2485,10 @@ static int gpiod_direction_output_raw_commit(struct gpio_desc *desc, int value) gc->set (gc,gpio_chip_hwgpio (desc), val); } -if (!ret) +if (!ret) {set_bit (FLAG_IS_OUT , &desc->flags); +gpiod_line_state_notify (desc,GPIO_V2_LINE_CHANGED_CONFIG ); + }trace_gpio_value (desc_to_gpio (desc),0 , val);trace_gpio_direction (desc_to_gpio (desc),0 , ret);return ret;
@@ -2672,9 +2675,16 @@ EXPORT_SYMBOL_GPL(gpiod_set_config);int gpiod_set_debounce (struct gpio_desc *desc,unsigned int debounce) {unsigned long config; +int ret; config =pinconf_to_config_packed (PIN_CONFIG_INPUT_DEBOUNCE , debounce); -return gpiod_set_config (desc, config); + ret =gpiod_set_config (desc, config); +if (ret) +return ret; + +gpiod_line_state_notify (desc,GPIO_V2_LINE_CHANGED_CONFIG ); + +return 0 ; }EXPORT_SYMBOL_GPL (gpiod_set_debounce);
@@ -2723,6 +2733,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);
@@ -3330,6 +3341,7 @@ int gpiod_set_consumer_name(struct gpio_desc *desc, const char *name)kfree_const (desc->label);desc_set_label (desc, name); +gpiod_line_state_notify (desc,GPIO_V2_LINE_CHANGED_CONFIG );return 0 ; }
Signature · 1 line
2.39.2
Quoted 22 lines · Bartosz Golaszewski
From: Bartosz Golaszewski <[email protected]>
We currently only emit
CHANGED_CONFIGevents when the user-space changes GPIO config. We won't be notified if changes come from in-kernel. Let's call the notifier chain whenever kernel users change direction or any of the active-low, debounce or consumer name settings. We don't notify the user-space about the persistence as the uAPI has no notion of it.Signed-off-by Bartosz Golaszewski <[email protected]>---
v1 -> v2:
- use thegpiod_line_state_notify()helper
- reorder the code ingpiod_set_debounce()for better readabilitydrivers/gpio/gpiolib.c | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-)drivers/gpio/gpiolib.c +0
-0
drivers/gpio/gpiolib.c int gpiod_direction_input(struct gpio_desc *desc) · line 2445
Quoted 7 lines
drivers/gpio/gpiolib.c +1
-0@@ -2439,6 +2439,7 @@ int gpiod_direction_input(struct gpio_desc *desc) }if (ret ==0 ) {clear_bit (FLAG_IS_OUT , &desc->flags); +gpiod_line_state_notify (desc,GPIO_V2_LINE_CHANGED_CONFIG ); ret =gpio_set_bias (desc); }
gpiod_direction_input() is called by cdev when a line is requested. So requesting a line now creates two events - REQUESTED and HANGED_CONFIG? Even worse - it calls gpiod_direction_input() first, so we will get CHANGED_CONFIG then REQUESTED??
And a config change from cdev can call this and then generate a CHANGED_CONFIG event itself, so again double events.
Same for output and probably debounce too (that one is a bit more convoluted).
Cheers,
Kent.
Quoted 49 lines
drivers/gpio/gpiolib.c +13
-2@@ -2484,8 +2485,10 @@ static int gpiod_direction_output_raw_commit(struct gpio_desc *desc, int value) gc->set (gc,gpio_chip_hwgpio (desc), val); } -if (!ret) +if (!ret) {set_bit (FLAG_IS_OUT , &desc->flags); +gpiod_line_state_notify (desc,GPIO_V2_LINE_CHANGED_CONFIG ); + }trace_gpio_value (desc_to_gpio (desc),0 , val);trace_gpio_direction (desc_to_gpio (desc),0 , ret);return ret;@@ -2672,9 +2675,16 @@ EXPORT_SYMBOL_GPL(gpiod_set_config);int gpiod_set_debounce (struct gpio_desc *desc,unsigned int debounce) {unsigned long config; +int ret; config =pinconf_to_config_packed (PIN_CONFIG_INPUT_DEBOUNCE , debounce); -return gpiod_set_config (desc, config); + ret =gpiod_set_config (desc, config); +if (ret) +return ret; + +gpiod_line_state_notify (desc,GPIO_V2_LINE_CHANGED_CONFIG ); + +return 0 ; }EXPORT_SYMBOL_GPL (gpiod_set_debounce);@@ -2723,6 +2733,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);@@ -3330,6 +3341,7 @@ int gpiod_set_consumer_name(struct gpio_desc *desc, const char *name)kfree_const (desc->label);desc_set_label (desc, name); +gpiod_line_state_notify (desc,GPIO_V2_LINE_CHANGED_CONFIG );return 0 ; }Signature · 1 line
2.39.2
Quoted 37 lines · Kent Gibson
Quoted 22 lines · Bartosz Golaszewski
From: Bartosz Golaszewski <[email protected]>
We currently only emit
CHANGED_CONFIGevents when the user-space changes GPIO config. We won't be notified if changes come from in-kernel. Let's call the notifier chain whenever kernel users change direction or any of the active-low, debounce or consumer name settings. We don't notify the user-space about the persistence as the uAPI has no notion of it.Signed-off-by Bartosz Golaszewski <[email protected]>---
v1 -> v2:
- use thegpiod_line_state_notify()helper
- reorder the code ingpiod_set_debounce()for better readabilitydrivers/gpio/gpiolib.c | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-)drivers/gpio/gpiolib.c +0
-0drivers/gpio/gpiolib.c int gpiod_direction_input(struct gpio_desc *desc) · line 2445
Quoted 7 lines
drivers/gpio/gpiolib.c +1
-0@@ -2439,6 +2439,7 @@ int gpiod_direction_input(struct gpio_desc *desc) }if (ret ==0 ) {clear_bit (FLAG_IS_OUT , &desc->flags); +gpiod_line_state_notify (desc,GPIO_V2_LINE_CHANGED_CONFIG ); ret =gpio_set_bias (desc); }
gpiod_direction_input()is called by cdev when a line is requested. So requesting a line now creates two events - REQUESTED andHANGED_CONFIG? Even worse - it callsgpiod_direction_input()first, so we will getCHANGED_CONFIGthen REQUESTED??
Quoted 5 lines
And a config change from cdev can call this and then generate a
CHANGED_CONFIGevent itself, so again double events.Same for output and probably debounce too (that one is a bit more convoluted).
Ah, should have tested it with user-space too...
Back to the drawing board I guess. May be the reason why we're not doing it in the first place yet.
Bart
Quoted 53 lines
Cheers,
Kent.Quoted 49 lines
drivers/gpio/gpiolib.c +13
-3@@ -2484,8 +2485,10 @@ static int gpiod_direction_output_raw_commit(struct gpio_desc *desc, int value) gc->set (gc,gpio_chip_hwgpio (desc), val); } -if (!ret) +if (!ret) {set_bit (FLAG_IS_OUT , &desc->flags); +gpiod_line_state_notify (desc,GPIO_V2_LINE_CHANGED_CONFIG ); + }trace_gpio_value (desc_to_gpio (desc),0 , val);trace_gpio_direction (desc_to_gpio (desc),0 , ret);return ret;@@ -2672,9 +2675,16 @@ EXPORT_SYMBOL_GPL(gpiod_set_config);int gpiod_set_debounce (struct gpio_desc *desc,unsigned int debounce) {unsigned long config; +int ret; config =pinconf_to_config_packed (PIN_CONFIG_INPUT_DEBOUNCE , debounce); -return gpiod_set_config (desc, config); + ret =gpiod_set_config (desc, config); +if (ret) +return ret; + +gpiod_line_state_notify (desc,GPIO_V2_LINE_CHANGED_CONFIG ); + +return 0 ; }EXPORT_SYMBOL_GPL (gpiod_set_debounce);@@ -2723,6 +2733,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);@@ -3330,6 +3341,7 @@ int gpiod_set_consumer_name(struct gpio_desc *desc, const char *name)kfree_const (desc->label);desc_set_label (desc, name); +gpiod_line_state_notify (desc,GPIO_V2_LINE_CHANGED_CONFIG );return 0 ; } --2.39.2
Quoted 41 lines · Bartosz Golaszewski
Quoted 40 lines · Kent Gibson
Quoted 22 lines · Bartosz Golaszewski
From: Bartosz Golaszewski <[email protected]>
We currently only emit
CHANGED_CONFIGevents when the user-space changes GPIO config. We won't be notified if changes come from in-kernel. Let's call the notifier chain whenever kernel users change direction or any of the active-low, debounce or consumer name settings. We don't notify the user-space about the persistence as the uAPI has no notion of it.Signed-off-by Bartosz Golaszewski <[email protected]>---
v1 -> v2:
- use thegpiod_line_state_notify()helper
- reorder the code ingpiod_set_debounce()for better readabilitydrivers/gpio/gpiolib.c | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-)drivers/gpio/gpiolib.c +0
-0drivers/gpio/gpiolib.c int gpiod_direction_input(struct gpio_desc *desc) · line 2445
Quoted 7 lines
drivers/gpio/gpiolib.c +1
-0@@ -2439,6 +2439,7 @@ int gpiod_direction_input(struct gpio_desc *desc) }if (ret ==0 ) {clear_bit (FLAG_IS_OUT , &desc->flags); +gpiod_line_state_notify (desc,GPIO_V2_LINE_CHANGED_CONFIG ); ret =gpio_set_bias (desc); }
gpiod_direction_input()is called by cdev when a line is requested. So requesting a line now creates two events - REQUESTED andHANGED_CONFIG? Even worse - it callsgpiod_direction_input()first, so we will getCHANGED_CONFIGthen REQUESTED??And a config change from cdev can call this and then generate a
CHANGED_CONFIGevent itself, so again double events.
Quoted 8 lines
Quoted 2 lines
Same for output and probably debounce too (that one is a bit more convoluted).
Ah, should have tested it with user-space too...
Back to the drawing board I guess. May be the reason why we're not doing it in the first place yet.
I think we were only looking at it from the userspace PoV, so what constitutes a "change" is only well defined when driven from userspace. This might be difficult to generalise without redefining what "changed" means, or providing cdev with a separate gpiolib API so you can tell whether the change is actually part of a cdev request, or ...
So, yeah - more thought required.
Got a use case that requires this, or just a nice to have?
Cheers,
Kent.
Quoted 58 lines · Kent Gibson
Quoted 41 lines · Bartosz Golaszewski
Quoted 40 lines · Kent Gibson
Quoted 22 lines · Bartosz Golaszewski
From: Bartosz Golaszewski <[email protected]>
We currently only emit
CHANGED_CONFIGevents when the user-space changes GPIO config. We won't be notified if changes come from in-kernel. Let's call the notifier chain whenever kernel users change direction or any of the active-low, debounce or consumer name settings. We don't notify the user-space about the persistence as the uAPI has no notion of it.Signed-off-by Bartosz Golaszewski <[email protected]>---
v1 -> v2:
- use thegpiod_line_state_notify()helper
- reorder the code ingpiod_set_debounce()for better readabilitydrivers/gpio/gpiolib.c | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-)drivers/gpio/gpiolib.c +0
-0drivers/gpio/gpiolib.c int gpiod_direction_input(struct gpio_desc *desc) · line 2445
Quoted 7 lines
drivers/gpio/gpiolib.c +1
-0@@ -2439,6 +2439,7 @@ int gpiod_direction_input(struct gpio_desc *desc) }if (ret ==0 ) {clear_bit (FLAG_IS_OUT , &desc->flags); +gpiod_line_state_notify (desc,GPIO_V2_LINE_CHANGED_CONFIG ); ret =gpio_set_bias (desc); }
gpiod_direction_input()is called by cdev when a line is requested. So requesting a line now creates two events - REQUESTED andHANGED_CONFIG? Even worse - it callsgpiod_direction_input()first, so we will getCHANGED_CONFIGthen REQUESTED??And a config change from cdev can call this and then generate a
CHANGED_CONFIGevent itself, so again double events.Quoted 8 lines
Quoted 2 lines
Same for output and probably debounce too (that one is a bit more convoluted).
Ah, should have tested it with user-space too...
Back to the drawing board I guess. May be the reason why we're not doing it in the first place yet.
I think we were only looking at it from the userspace PoV, so what constitutes a "change" is only well defined when driven from userspace. This might be difficult to generalise without redefining what "changed" means, or providing cdev with a separate gpiolib API so you can tell whether the change is actually part of a cdev request, or ...
Quoted 4 lines
So, yeah - more thought required.
Got a use case that requires this, or just a nice to have?
I'm extending the virtual consumer driver and wanted to test from user-spaces things like changing direction and other settings. I figured it would make more sense to notify about all changes no matter the source.
Bart