gpio: mockup: improve the user-space testing interface
Subsystems (3)
v5 cover gpio: mockup: improve the user-space testing interface
From: Bartosz Golaszewski <[email protected]>
Hi Marc,
please take a look at another, much simpler approach. The only change in irq_sim is calling the irqd_set_trigger_type() in irq_set_type(). We don't care about the actual type - we simply store it and any interested user (for example gpio-mockup in this series) can retrieve it using irq_get_trigger_type() and interpret it on its own.
v1 -> v2:
- instead of providing the irq_sim_get_type() helper, move the irq type logic into the simulator and provide a helper that allows users to specify the type of the fired interrupt
v2 -> v3:
- switch back to having irq_sim_type() and put the line state logic into the GPIO testing module
v3 -> v4:
- drop irq_sim_get_type() and use a notifier chain instead so that any change in type configuration can be pushed out to interested users
- change the locking mechanism in gpio-mockup to a spinlock as we can't take a mutex when a hardirq-safe spinlock in irq_desc is being held when the irq_set_type() callback is called
- refuse to set any other type than falling or rising edge in irq_set_config
v4 -> v5:
- drop the notifier, use irqd_set_trigger_type() instead
Bartosz Golaszewski (7):
irq/irq_sim: add irq_set_type() callback
gpio: mockup: add locking
gpio: mockup: implement get_multiple()
gpio: mockup: don't create the debugfs link named after the label
gpio: mockup: change the type of 'offset' to unsigned int
gpio: mockup: change the signature of unlocked get/set helpers
gpio: mockup: rework debugfs interface
drivers/gpio/gpio-mockup.c | 189 +++++++++++++++++++++++++++++++------ kernel/irq/irq_sim.c | 8 ++ 2 files changed, 170 insertions(+), 27 deletions(-)
Signature · 1 line
2.20.1
PATCH v5 1/7 irq/irq_sim: add irq_set_type() callback
From: Bartosz Golaszewski <[email protected]>
Implement the irq_set_type() callback and call irqd_set_trigger_type() internally so that users interested in the configured trigger type can later retrieve it using irqd_get_trigger_type().
--- kernel/irq/irq_sim.c | 8 ++++++++ 1 file changed, 8 insertions(+)
kernel/irq/irq_sim.c +8 -0
@@ -25,10 +25,18 @@ static void irq_sim_irqunmask(struct irq_data *data) irq_ctx->enabled = true; } +static int irq_sim_set_type (struct irq_data *data,unsigned int type) +{ +irqd_set_trigger_type (data, type); + +return 0 ; +} +static struct irq_chip irq_sim_irqchip = { .name ="irq_sim" , .irq_mask = irq_sim_irqmask, .irq_unmask = irq_sim_irqunmask, + .irq_set_type = irq_sim_set_type, };static void irq_sim_handle_irq (struct irq_work *work)
Signature · 1 line
2.20.1
Re: [PATCH v5 1/7] irq/irq_sim: add irq_set_type() callback
Quoted 16 lines · On Mon, 18 Feb 2019 17:41:32 +0100 Bartosz Golaszewski <[email protected]> wrote:
From: Bartosz Golaszewski <[email protected]>
Implement the
irq_set_type()callback and callirqd_set_trigger_type()internally so that users interested in the configured trigger type can later retrieve it usingirqd_get_trigger_type().Signed-off-by Bartosz Golaszewski <[email protected]>--- kernel/irq/irq_sim.c | 8 ++++++++ 1 file changed, 8 insertions(+)kernel/irq/irq_sim.c +0
-0
kernel/irq/irq_sim.c static void irq_sim_irqunmask(struct irq_data *data) · line 32
Quoted 8 lines
kernel/irq/irq_sim.c +5
-0@@ -25,10 +25,18 @@ static void irq_sim_irqunmask(struct irq_data *data) irq_ctx->enabled = true; } +static int irq_sim_set_type (struct irq_data *data,unsigned int type) +{ +irqd_set_trigger_type (data, type); + +return 0 ;
You keep ignoring the requirement for sanitization of the trigger type. Frankly, I'm getting tired of fighting over 3 lines of incorrect code.
I guess that despite all the noise, you don't really want this code in after all.
M.
Signature · 1 line
Without deviation from the norm, progress is not possible.
Re: [PATCH v5 1/7] irq/irq_sim: add irq_set_type() callback
wt., 19 lut 2019 o 13:25 Marc Zyngier <[email protected]> napisał(a):
Quoted 23 lines
Quoted 19 lines · On Mon, 18 Feb 2019 17:41:32 +0100 Bartosz Golaszewski <[email protected]> wrote:
From: Bartosz Golaszewski <[email protected]>
Implement the
irq_set_type()callback and callirqd_set_trigger_type()internally so that users interested in the configured trigger type can later retrieve it usingirqd_get_trigger_type().Signed-off-by Bartosz Golaszewski <[email protected]>--- kernel/irq/irq_sim.c | 8 ++++++++ 1 file changed, 8 insertions(+)kernel/irq/irq_sim.c +0
-0@@ -25,10 +25,18 @@ static void irq_sim_irqunmask(struct irq_data *data) irq_ctx->enabled = true; }
Quoted 9 lines
kernel/irq/irq_sim.c static void irq_sim_irqunmask(struct irq_data *data) · line 32
Quoted 5 lines
kernel/irq/irq_sim.c +5
-0+static int irq_sim_set_type (struct irq_data *data,unsigned int type) +{ +irqd_set_trigger_type (data, type); + +return 0 ;You keep ignoring the requirement for sanitization of the trigger type. Frankly, I'm getting tired of fighting over 3 lines of incorrect code.
It used to be there in previous versions, but I removed it on purpose in v5. I understand why we needed that earlier, but if we now moved *all* the logic behind the trigger type to the users of this API and we're now simply storing any config we get, then why would we impose any limits on it here? We don't do this now and this patch doesn't change the current behavior. I really don't understand how not rejecting certain trigger types makes this patch incorrect.
Quoted 3 lines
I guess that despite all the noise, you don't really want this code in after all.
I do want and need this, but I really can't figure out from your reviews how you imagine the correct solution. You said previously that the irq_set_type callback should push the configuration to wherever it's needed. I believe the above patch does this. Should we then limit the supported trigger types? That would mean that irq_sim would need to know what users support. It seems inverted to me, but if you think it's right, then my question is: will accepting only IRQ_TYPE_NONE, IRQ_TYPE_EDGE_RISING and IRQ_TYPE_EDGE_FALLING in the above function be enough for you to accept it? Is the rest fine?
Thanks,
Bartosz
Re: [PATCH v5 1/7] irq/irq_sim: add irq_set_type() callback
Quoted 34 lines · On Tue, 19 Feb 2019 14:20:03 +0100 Bartosz Golaszewski <[email protected]> wrote:
wt., 19 lut 2019 o 13:25 Marc Zyngier <[email protected]> napisał(a):
Quoted 23 lines
Quoted 19 lines · On Mon, 18 Feb 2019 17:41:32 +0100 Bartosz Golaszewski <[email protected]> wrote:
From: Bartosz Golaszewski <[email protected]>
Implement the
irq_set_type()callback and callirqd_set_trigger_type()internally so that users interested in the configured trigger type can later retrieve it usingirqd_get_trigger_type().Signed-off-by Bartosz Golaszewski <[email protected]>--- kernel/irq/irq_sim.c | 8 ++++++++ 1 file changed, 8 insertions(+)kernel/irq/irq_sim.c +0
-0@@ -25,10 +25,18 @@ static void irq_sim_irqunmask(struct irq_data *data) irq_ctx->enabled = true; }Quoted 9 lines
kernel/irq/irq_sim.c static void irq_sim_irqunmask(struct irq_data *data) · line 32
Quoted 5 lines
kernel/irq/irq_sim.c +5
-0+static int irq_sim_set_type (struct irq_data *data,unsigned int type) +{ +irqd_set_trigger_type (data, type); + +return 0 ;You keep ignoring the requirement for sanitization of the trigger type. Frankly, I'm getting tired of fighting over 3 lines of incorrect code.
Quoted 7 lines
It used to be there in previous versions, but I removed it on purpose in v5. I understand why we needed that earlier, but if we now moved *all* the logic behind the trigger type to the users of this API and we're now simply storing any config we get, then why would we impose any limits on it here? We don't do this now and this patch doesn't change the current behavior. I really don't understand how not rejecting certain trigger types makes this patch incorrect.
You expose a new set_type callback. Only a set of valid values can be handled by the users of this interface. At least your mockup gpio only handles a narrow set of configuration. Not rejecting erroneous values is a bug. This isn't a new requirement; this is how the irqchip API works, as drivers do expect such a failure if requiring an invalid type.
Quoted 8 lines
Quoted 3 lines
I guess that despite all the noise, you don't really want this code in after all.
I do want and need this, but I really can't figure out from your reviews how you imagine the correct solution. You said previously that the
irq_set_typecallback should push the configuration to wherever it's needed.
Yes. But it doesn't mean it should accept something that cannot be handled by the irqchip. If you push it to the code that does the handling, it still has to return an error if the backing code decides that this is not a supported configuration.
At the end of the day, where you store it is irrelevant for the problem at hand. There is an API, and you need to implement it correctly.
Quoted 6 lines
I believe the above patch does this. Should we then limit the supported trigger types? That would mean that
irq_simwould need to know what users support. It seems inverted to me, but if you think it's right, then my question is: will accepting onlyIRQ_TYPE_NONE,IRQ_TYPE_EDGE_RISINGandIRQ_TYPE_EDGE_FALLINGin the above function be enough for you to accept it? Is the rest fine?
IRQ_TYPE_NONE doesn't mean anything, apart from "whatever defaults were there because I have no clue". In your case, I really don't see the point. The EDGE settings are what you handle, and are the only values that should be accepted.
As for the rest of the patches, I haven't looked at them, and probably won't (if only because I'm on holiday and would like to do something else...). All I'm asking from you is to give me a correct patch #1. Once I see that, I'll gladly ack it.
M.
Signature · 1 line
Without deviation from the norm, progress is not possible.
Re: [PATCH v5 1/7] irq/irq_sim: add irq_set_type() callback
wt., 19 lut 2019 o 14:40 Marc Zyngier <[email protected]> napisał(a):
Quoted 77 lines
Quoted 34 lines · On Tue, 19 Feb 2019 14:20:03 +0100 Bartosz Golaszewski <[email protected]> wrote:
wt., 19 lut 2019 o 13:25 Marc Zyngier <[email protected]> napisał(a):
Quoted 23 lines
Quoted 19 lines · On Mon, 18 Feb 2019 17:41:32 +0100 Bartosz Golaszewski <[email protected]> wrote:
From: Bartosz Golaszewski <[email protected]>
Implement the
irq_set_type()callback and callirqd_set_trigger_type()internally so that users interested in the configured trigger type can later retrieve it usingirqd_get_trigger_type().Signed-off-by Bartosz Golaszewski <[email protected]>--- kernel/irq/irq_sim.c | 8 ++++++++ 1 file changed, 8 insertions(+)kernel/irq/irq_sim.c +0
-0@@ -25,10 +25,18 @@ static void irq_sim_irqunmask(struct irq_data *data) irq_ctx->enabled = true; }Quoted 9 lines
kernel/irq/irq_sim.c static void irq_sim_irqunmask(struct irq_data *data) · line 32
Quoted 5 lines
kernel/irq/irq_sim.c +5
-0+static int irq_sim_set_type (struct irq_data *data,unsigned int type) +{ +irqd_set_trigger_type (data, type); + +return 0 ;You keep ignoring the requirement for sanitization of the trigger type. Frankly, I'm getting tired of fighting over 3 lines of incorrect code.
Quoted 7 lines
It used to be there in previous versions, but I removed it on purpose in v5. I understand why we needed that earlier, but if we now moved *all* the logic behind the trigger type to the users of this API and we're now simply storing any config we get, then why would we impose any limits on it here? We don't do this now and this patch doesn't change the current behavior. I really don't understand how not rejecting certain trigger types makes this patch incorrect.
You expose a new
set_typecallback. Only a set of valid values can be handled by the users of this interface. At least your mockup gpio only handles a narrow set of configuration. Not rejecting erroneous values is a bug. This isn't a new requirement; this is how the irqchip API works, as drivers do expect such a failure if requiring an invalid type.Quoted 8 lines
Quoted 3 lines
I guess that despite all the noise, you don't really want this code in after all.
I do want and need this, but I really can't figure out from your reviews how you imagine the correct solution. You said previously that the
irq_set_typecallback should push the configuration to wherever it's needed.Yes. But it doesn't mean it should accept something that cannot be handled by the irqchip. If you push it to the code that does the handling, it still has to return an error if the backing code decides that this is not a supported configuration.
At the end of the day, where you store it is irrelevant for the problem at hand. There is an API, and you need to implement it correctly.
Quoted 6 lines
I believe the above patch does this. Should we then limit the supported trigger types? That would mean that
irq_simwould need to know what users support. It seems inverted to me, but if you think it's right, then my question is: will accepting onlyIRQ_TYPE_NONE,IRQ_TYPE_EDGE_RISINGandIRQ_TYPE_EDGE_FALLINGin the above function be enough for you to accept it? Is the rest fine?
Quoted 5 lines
IRQ_TYPE_NONEdoesn't mean anything, apart from "whatever defaults were there because I have no clue". In your case, I really don't see the point. The EDGE settings are what you handle, and are the only values that should be accepted.
Right, irq_set_type() isn't even called if there's no trigger set.
Quoted 5 lines
As for the rest of the patches, I haven't looked at them, and probably won't (if only because I'm on holiday and would like to do something else...). All I'm asking from you is to give me a correct patch #1. Once I see that, I'll gladly ack it.
Thanks,
Bartosz
PATCH v5 2/7 gpio: mockup: add locking
In reply to Bartosz GolaszewskiFrom: Bartosz Golaszewski <[email protected]>
While no user reported any race condition problems with gpio-mockup, let's be on the safe side and use a mutex when performing any changes on the dummy chip structures.
--- drivers/gpio/gpio-mockup.c | 50 ++++++++++++++++++++++++++++++++------ 1 file changed, 43 insertions(+), 7 deletions(-)
drivers/gpio/gpio-mockup.c +43 -7
@@ -54,6 +54,7 @@ struct gpio_mockup_chip {struct gpio_mockup_line_status *lines;struct irq_sim irqsim;struct dentry *dbg_dir; +struct mutex lock; };struct gpio_mockup_dbgfs_private {
@@ -82,29 +83,53 @@ static int gpio_mockup_range_ngpio(unsigned int index)return gpio_mockup_ranges[index *2 +1 ]; } -static int gpio_mockup_get (struct gpio_chip *gc,unsigned int offset) +static int __gpio_mockup_get (struct gpio_chip *gc,unsigned int offset) {struct gpio_mockup_chip *chip =gpiochip_get_data (gc);return chip->lines[offset].value; } -static void gpio_mockup_set (struct gpio_chip *gc, -unsigned int offset,int value) +static int gpio_mockup_get (struct gpio_chip *gc,unsigned int offset) +{ +struct gpio_mockup_chip *chip =gpiochip_get_data (gc); +int val; + +mutex_lock (&chip->lock); + val =__gpio_mockup_get (gc, offset); +mutex_unlock (&chip->lock); + +return val; +} + +static void __gpio_mockup_set (struct gpio_chip *gc, +unsigned int offset,int value) {struct gpio_mockup_chip *chip =gpiochip_get_data (gc); chip->lines[offset].value = !!value; } +static void gpio_mockup_set (struct gpio_chip *gc, +unsigned int offset,int value) +{ +struct gpio_mockup_chip *chip =gpiochip_get_data (gc); + +mutex_lock (&chip->lock); +__gpio_mockup_set (gc, offset, value); +mutex_unlock (&chip->lock); +} +static void gpio_mockup_set_multiple (struct gpio_chip *gc,unsigned long *mask,unsigned long *bits) { +struct gpio_mockup_chip *chip =gpiochip_get_data (gc);unsigned int bit; +mutex_lock (&chip->lock);for_each_set_bit (bit, mask, gc->ngpio) -gpio_mockup_set (gc, bit,test_bit (bit, bits)); - +__gpio_mockup_set (gc, bit,test_bit (bit, bits)); +mutex_unlock (&chip->lock); } static int gpio_mockup_dirout(struct gpio_chip *gc,
@@ -112,8 +137,10 @@ static int gpio_mockup_dirout(struct gpio_chip *gc, {struct gpio_mockup_chip *chip =gpiochip_get_data (gc); -gpio_mockup_set (gc, offset, value); +mutex_lock (&chip->lock); chip->lines[offset].dir =GPIO_MOCKUP_DIR_OUT ; +__gpio_mockup_set (gc, offset, value); +mutex_unlock (&chip->lock);return 0 ; }
@@ -122,7 +149,9 @@ static int gpio_mockup_dirin(struct gpio_chip *gc, unsigned int offset) {struct gpio_mockup_chip *chip =gpiochip_get_data (gc); +mutex_lock (&chip->lock); chip->lines[offset].dir =GPIO_MOCKUP_DIR_IN ; +mutex_unlock (&chip->lock);return 0 ; }
@@ -130,8 +159,13 @@ static int gpio_mockup_dirin(struct gpio_chip *gc, unsigned int offset)static int gpio_mockup_get_direction (struct gpio_chip *gc,unsigned int offset) {struct gpio_mockup_chip *chip =gpiochip_get_data (gc); +int direction; -return !chip->lines[offset].dir; +mutex_lock (&chip->lock); + direction = !chip->lines[offset].dir; +mutex_unlock (&chip->lock); + +return direction; }static int gpio_mockup_to_irq (struct gpio_chip *gc,unsigned int offset)
@@ -283,6 +317,8 @@ static int gpio_mockup_probe(struct platform_device *pdev)return -ENOMEM ; } +mutex_init (&chip->lock); + gc = &chip->gc; gc->base = base; gc->ngpio = ngpio;
Signature · 1 line
2.20.1
PATCH v5 3/7 gpio: mockup: implement get_multiple()
In reply to Bartosz GolaszewskiFrom: Bartosz Golaszewski <[email protected]>
We already support set_multiple(). Implement get_multiple() as well.
--- drivers/gpio/gpio-mockup.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+)
drivers/gpio/gpio-mockup.c +17 -0
@@ -102,6 +102,22 @@ static int gpio_mockup_get(struct gpio_chip *gc, unsigned int offset)return val; } +static int gpio_mockup_get_multiple (struct gpio_chip *gc, +unsigned long *mask,unsigned long *bits) +{ +struct gpio_mockup_chip *chip =gpiochip_get_data (gc); +unsigned int bit, val; + +mutex_lock (&chip->lock); +for_each_set_bit (bit, mask, gc->ngpio) { + val =__gpio_mockup_get (gc, bit); +__assign_bit (bit, bits, val); + } +mutex_unlock (&chip->lock); + +return 0 ; +} +static void __gpio_mockup_set (struct gpio_chip *gc,unsigned int offset,int value) {
@@ -327,6 +343,7 @@ static int gpio_mockup_probe(struct platform_device *pdev) gc->parent = dev; gc->get = gpio_mockup_get; gc->set = gpio_mockup_set; + gc->get_multiple = gpio_mockup_get_multiple; gc->set_multiple = gpio_mockup_set_multiple; gc->direction_output = gpio_mockup_dirout; gc->direction_input = gpio_mockup_dirin;
Signature · 1 line
2.20.1
PATCH v5 4/7 gpio: mockup: don't create the debugfs link named after the label
In reply to Bartosz GolaszewskiFrom: Bartosz Golaszewski <[email protected]>
User-space tests no longer use it and we're breaking the interface anyway.
--- drivers/gpio/gpio-mockup.c | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-)
drivers/gpio/gpio-mockup.c +1 -5
@@ -234,7 +234,7 @@ static void gpio_mockup_debugfs_setup(struct device *dev, struct gpio_mockup_chip *chip) {struct gpio_mockup_dbgfs_private *priv; -struct dentry *evfile, *link; +struct dentry *evfile;struct gpio_chip *gc;const char *devname;char *name;
@@ -247,10 +247,6 @@ static void gpio_mockup_debugfs_setup(struct device *dev,if (IS_ERR_OR_NULL (chip->dbg_dir)) goto err; - link =debugfs_create_symlink (gc->label, gpio_mockup_dbg_dir, devname); -if (IS_ERR_OR_NULL (link)) - goto err; -for (i =0 ; i < gc->ngpio; i++) { name =devm_kasprintf (dev,GFP_KERNEL ,"%d" , i);if (!name)
Signature · 1 line
2.20.1
PATCH v5 5/7 gpio: mockup: change the type of 'offset' to unsigned int
In reply to Bartosz GolaszewskiFrom: Bartosz Golaszewski <[email protected]>
This field can never be negative.
--- drivers/gpio/gpio-mockup.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpio/gpio-mockup.c +1 -1
@@ -60,7 +60,7 @@ struct gpio_mockup_chip {struct gpio_mockup_dbgfs_private {struct gpio_mockup_chip *chip;struct gpio_desc *desc; -int offset; +unsigned int offset; };static int gpio_mockup_ranges[GPIO_MOCKUP_MAX_RANGES ];
Signature · 1 line
2.20.1
PATCH v5 6/7 gpio: mockup: change the signature of unlocked get/set helpers
In reply to Bartosz GolaszewskiFrom: Bartosz Golaszewski <[email protected]>
The unlocked variants only get called from places where we already have the pointer to the underlying gpio_mockup_chip structure, so take it as parameter instead of struct gpio_chip.
--- drivers/gpio/gpio-mockup.c | 19 ++++++++----------- 1 file changed, 8 insertions(+), 11 deletions(-)
drivers/gpio/gpio-mockup.c +8 -11
@@ -83,10 +83,9 @@ static int gpio_mockup_range_ngpio(unsigned int index)return gpio_mockup_ranges[index *2 +1 ]; } -static int __gpio_mockup_get (struct gpio_chip *gc,unsigned int offset) +static int __gpio_mockup_get (struct gpio_mockup_chip *chip, +unsigned int offset) { -struct gpio_mockup_chip *chip =gpiochip_get_data (gc); -return chip->lines[offset].value; }
@@ -96,7 +95,7 @@ static int gpio_mockup_get(struct gpio_chip *gc, unsigned int offset)int val;mutex_lock (&chip->lock); - val =__gpio_mockup_get (gc, offset); + val =__gpio_mockup_get (chip, offset);mutex_unlock (&chip->lock);return val;
@@ -110,7 +109,7 @@ static int gpio_mockup_get_multiple(struct gpio_chip *gc,mutex_lock (&chip->lock);for_each_set_bit (bit, mask, gc->ngpio) { - val =__gpio_mockup_get (gc, bit); + val =__gpio_mockup_get (chip, bit);__assign_bit (bit, bits, val); }mutex_unlock (&chip->lock);
@@ -118,11 +117,9 @@ static int gpio_mockup_get_multiple(struct gpio_chip *gc,return 0 ; } -static void __gpio_mockup_set (struct gpio_chip *gc, +static void __gpio_mockup_set (struct gpio_mockup_chip *chip,unsigned int offset,int value) { -struct gpio_mockup_chip *chip =gpiochip_get_data (gc); - chip->lines[offset].value = !!value; }
@@ -132,7 +129,7 @@ static void gpio_mockup_set(struct gpio_chip *gc,struct gpio_mockup_chip *chip =gpiochip_get_data (gc);mutex_lock (&chip->lock); -__gpio_mockup_set (gc, offset, value); +__gpio_mockup_set (chip, offset, value);mutex_unlock (&chip->lock); }
@@ -144,7 +141,7 @@ static void gpio_mockup_set_multiple(struct gpio_chip *gc,mutex_lock (&chip->lock);for_each_set_bit (bit, mask, gc->ngpio) -__gpio_mockup_set (gc, bit,test_bit (bit, bits)); +__gpio_mockup_set (chip, bit,test_bit (bit, bits));mutex_unlock (&chip->lock); }
@@ -155,7 +152,7 @@ static int gpio_mockup_dirout(struct gpio_chip *gc,mutex_lock (&chip->lock); chip->lines[offset].dir =GPIO_MOCKUP_DIR_OUT ; -__gpio_mockup_set (gc, offset, value); +__gpio_mockup_set (chip, offset, value);mutex_unlock (&chip->lock);return 0 ;
Signature · 1 line
2.20.1
PATCH v5 7/7 gpio: mockup: rework debugfs interface
In reply to Bartosz GolaszewskiFrom: Bartosz Golaszewski <[email protected]>
Modify the way the debugfs interface works in gpio-mockup. Introduce the concept of dummy pull config which will keep the mockup lines in known state. The pull values can be modified by writing to the debugfs files corresponding to lines. Lines in input mode always report the current pull value, lines in output mode change the line value but it will revert back to the one specified by current pull when released.
--- drivers/gpio/gpio-mockup.c | 117 ++++++++++++++++++++++++++++++++----- 1 file changed, 103 insertions(+), 14 deletions(-)
drivers/gpio/gpio-mockup.c +103 -14
@@ -47,6 +47,7 @@ enum {struct gpio_mockup_line_status {int dir;int value; +int pull; };struct gpio_mockup_chip {
@@ -188,15 +189,56 @@ static int gpio_mockup_to_irq(struct gpio_chip *gc, unsigned int offset)return irq_sim_irqnum (&chip->irqsim, offset); } -static ssize_t gpio_mockup_event_write (struct file *file, -const char __user *usr_buf, -size_t size,loff_t *ppos) +static void gpio_mockup_free (struct gpio_chip *gc,unsigned int offset) +{ +struct gpio_mockup_chip *chip =gpiochip_get_data (gc); + +__gpio_mockup_set (chip, offset, chip->lines[offset].pull); +} + +static ssize_t gpio_mockup_debugfs_read (struct file *file, +char __user *usr_buf, +size_t size,loff_t *ppos) {struct gpio_mockup_dbgfs_private *priv;struct gpio_mockup_chip *chip;struct seq_file *sfile; +struct gpio_chip *gc; +char buf[3 ]; +int val, rv; + +if (*ppos !=0 ) +return 0 ; + + sfile = file->private_data; + priv = sfile->private; + chip = priv->chip; + gc = &chip->gc; + + val =gpio_mockup_get (gc, priv->offset); +snprintf (buf,sizeof (buf),"%d\n" , val); + + rv =copy_to_user (usr_buf, buf,sizeof (buf)); +if (rv) +return rv; + +return sizeof (buf) -1 ; +} + +static ssize_t gpio_mockup_debugfs_write (struct file *file, +const char __user *usr_buf, +size_t size,loff_t *ppos) +{ +struct gpio_mockup_dbgfs_private *priv; +int rv, val, curr, irq, irq_type; +struct gpio_mockup_chip *chip; +struct seq_file *sfile;struct gpio_desc *desc; -int rv, val; +struct gpio_chip *gc; +struct irq_sim *sim; + +if (*ppos !=0 ) +return -EINVAL ; rv =kstrtoint_from_user (usr_buf, size,0 , &val);if (rv)
@@ -206,24 +248,70 @@ static ssize_t gpio_mockup_event_write(struct file *file, sfile = file->private_data; priv = sfile->private; - desc = priv->desc; chip = priv->chip; + gc = &chip->gc; + desc = &gc->gpiodev->descs[priv->offset]; + sim = &chip->irqsim; + +mutex_lock (&chip->lock); + +if (test_bit (FLAG_REQUESTED , &desc->flags) && + !test_bit (FLAG_IS_OUT , &desc->flags)) { + curr =__gpio_mockup_get (chip, priv->offset); +if (curr == val) + goto out; -gpiod_set_value_cansleep (desc, val); -irq_sim_fire (&chip->irqsim, priv->offset); + irq =irq_sim_irqnum (sim, priv->offset); + irq_type =irq_get_trigger_type (irq); + +if ((val ==1 && (irq_type &IRQ_TYPE_EDGE_RISING )) || + (val ==0 && (irq_type &IRQ_TYPE_EDGE_FALLING ))) +irq_sim_fire (sim, priv->offset); + } + +/* Change the value unless we're actively driving the line. */ +if (!test_bit (FLAG_REQUESTED , &desc->flags) || + !test_bit (FLAG_IS_OUT , &desc->flags)) +__gpio_mockup_set (chip, priv->offset, val); + +out: + chip->lines[priv->offset].pull = val; +mutex_unlock (&chip->lock);return size; } -static int gpio_mockup_event_open (struct inode *inode,struct file *file) +static int gpio_mockup_debugfs_open (struct inode *inode,struct file *file) {return single_open (file,NULL , inode->i_private); } -static const struct file_operations gpio_mockup_event_ops = { +/* +* Each mockup chip is represented by a directory named after the chip's device +* name under /sys/kernel/debug/gpio-mockup/. Each line is represented by +* a file using the line's offset as the name under the chip's directory. +* +* Reading from the line's file yields the current *value*, writing to the +* line's file changes the current *pull*. Default pull for mockup lines is +* down. +* +* Examples: +* - when a line pulled down is requested in output mode and driven high, its +* value will return to 0 once it's released +* - when the line is requested in output mode and driven high, writing 0 to +* the corresponding debugfs file will change the pull to down but the +* reported value will still be 1 until the line is released +* - line requested in input mode always reports the same value as its pull +* configuration +* - when the line is requested in input mode and monitored for events, writing +* the same value to the debugfs file will be a noop, while writing the +* opposite value will generate a dummy interrupt with an appropriate edge +*/ +static const struct file_operations gpio_mockup_debugfs_ops = { .owner =THIS_MODULE , - .open = gpio_mockup_event_open, - .write = gpio_mockup_event_write, + .open = gpio_mockup_debugfs_open, + .read = gpio_mockup_debugfs_read, + .write = gpio_mockup_debugfs_write, .llseek = no_llseek, };
@@ -258,7 +346,7 @@ static void gpio_mockup_debugfs_setup(struct device *dev, priv->desc = &gc->gpiodev->descs[i]; evfile =debugfs_create_file (name,0200 , chip->dbg_dir, priv, - &gpio_mockup_event_ops); + &gpio_mockup_debugfs_ops);if (IS_ERR_OR_NULL (evfile)) goto err; }
@@ -266,7 +354,7 @@ static void gpio_mockup_debugfs_setup(struct device *dev,return ; err: -dev_err (dev,"error creating debugfs event files\n" ); +dev_err (dev,"error creating debugfs files\n" ); } static int gpio_mockup_name_lines(struct device *dev,
@@ -342,6 +430,7 @@ static int gpio_mockup_probe(struct platform_device *pdev) gc->direction_input = gpio_mockup_dirin; gc->get_direction = gpio_mockup_get_direction; gc->to_irq = gpio_mockup_to_irq; + gc->free = gpio_mockup_free; chip->lines =devm_kcalloc (dev, gc->ngpio,sizeof (*chip->lines),GFP_KERNEL );
@@ -415,7 +504,7 @@ static int __init gpio_mockup_init(void)return -EINVAL ; } - gpio_mockup_dbg_dir =debugfs_create_dir ("gpio-mockup-event" ,NULL ); + gpio_mockup_dbg_dir =debugfs_create_dir ("gpio-mockup" ,NULL );if (IS_ERR_OR_NULL (gpio_mockup_dbg_dir))gpio_mockup_err ("error creating debugfs directory\n" );
Signature · 1 line
2.20.1