* [PATCH] gpio: export 'debounce' attribute if supported by the gpio chip
@ 2012-12-06 6:32 Guenter Roeck
2012-12-07 8:07 ` Linus Walleij
0 siblings, 1 reply; 14+ messages in thread
From: Guenter Roeck @ 2012-12-06 6:32 UTC (permalink / raw)
To: linux-kernel; +Cc: Grant Likely, Linus Walleij, Guenter Roeck
Create a 'debounce' attribute if debounce is supported by the gpio
chip and a gpio pin is exported.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
---
drivers/gpio/gpiolib.c | 59 ++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 59 insertions(+), 0 deletions(-)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index a971e3d..13ee9a7 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -67,6 +67,7 @@ struct gpio_desc {
#ifdef CONFIG_DEBUG_FS
const char *label;
#endif
+ unsigned debounce;
};
static struct gpio_desc gpio_desc[ARCH_NR_GPIOS];
@@ -215,6 +216,10 @@ static DEFINE_MUTEX(sysfs_lock);
* * is read/write as zero/nonzero
* * also affects existing and subsequent "falling" and "rising"
* /edge configuration
+ * /debounce
+ * * configures debounce time in uS
+ * * available only if debounce is supported by the chip
+ * * is read/write; 0 to disable or debounce time
*/
static ssize_t gpio_direction_show(struct device *dev,
@@ -320,6 +325,55 @@ static ssize_t gpio_value_store(struct device *dev,
static const DEVICE_ATTR(value, 0644,
gpio_value_show, gpio_value_store);
+static ssize_t gpio_debounce_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ const struct gpio_desc *desc = dev_get_drvdata(dev);
+ ssize_t status;
+
+ mutex_lock(&sysfs_lock);
+
+ if (!test_bit(FLAG_EXPORT, &desc->flags))
+ status = -EIO;
+ else
+ status = sprintf(buf, "%u\n", desc->debounce);
+
+ mutex_unlock(&sysfs_lock);
+ return status;
+}
+
+static ssize_t gpio_debounce_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t size)
+{
+ const struct gpio_desc *desc = dev_get_drvdata(dev);
+ unsigned gpio = desc - gpio_desc;
+ ssize_t status;
+
+ mutex_lock(&sysfs_lock);
+
+ if (!test_bit(FLAG_EXPORT, &desc->flags))
+ status = -EIO;
+ else if (test_bit(FLAG_IS_OUT, &desc->flags))
+ status = -EPERM;
+ else {
+ long value;
+
+ status = kstrtoul(buf, 0, &value);
+ if (status == 0) {
+ status = gpio_set_debounce(gpio, value);
+ if (status == 0)
+ status = size;
+ }
+ }
+
+ mutex_unlock(&sysfs_lock);
+ return status;
+}
+
+static const DEVICE_ATTR(debounce, 0644,
+ gpio_debounce_show, gpio_debounce_store);
+
static irqreturn_t gpio_sysfs_irq(int irq, void *priv)
{
struct sysfs_dirent *value_sd = priv;
@@ -741,6 +795,10 @@ int gpio_export(unsigned gpio, bool direction_may_change)
status = device_create_file(dev,
&dev_attr_direction);
+ if (!status && desc->chip->set_debounce)
+ status = device_create_file(dev,
+ &dev_attr_debounce);
+
if (!status && gpio_to_irq(gpio) >= 0
&& (direction_may_change
|| !test_bit(FLAG_IS_OUT,
@@ -1507,6 +1565,7 @@ int gpio_set_debounce(unsigned gpio, unsigned debounce)
might_sleep_if(chip->can_sleep);
+ desc->debounce = debounce;
return chip->set_debounce(chip, gpio, debounce);
fail:
--
1.7.5.4
^ permalink raw reply related [flat|nested] 14+ messages in thread* Re: [PATCH] gpio: export 'debounce' attribute if supported by the gpio chip
2012-12-06 6:32 [PATCH] gpio: export 'debounce' attribute if supported by the gpio chip Guenter Roeck
@ 2012-12-07 8:07 ` Linus Walleij
2012-12-07 14:59 ` Guenter Roeck
0 siblings, 1 reply; 14+ messages in thread
From: Linus Walleij @ 2012-12-07 8:07 UTC (permalink / raw)
To: Guenter Roeck; +Cc: linux-kernel, Grant Likely, Dmitry Torokhov
On Thu, Dec 6, 2012 at 7:32 AM, Guenter Roeck <linux@roeck-us.net> wrote:
> Create a 'debounce' attribute if debounce is supported by the gpio
> chip and a gpio pin is exported.
>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Can you describe the usecase for this?
I have this problem when working as a back-up GPIO maintainer that
I don't really understand the userspace apps doing this.
I would guess something like a userspace app reading a GPIO switch
and needing to set this to avoid key bounces, but it'd be nice to know
if this is really the case.
If this is the usecase I am slightly concerned why these are not used:
drivers/input/keyboard/gpio_keys_polled.c
drivers/input/keyboard/gpio_keys.c
The latter even uses the in-kernel debounce interface.
I'd agree if this is not user input at all but something like a switch
in a factory production line.
So please help me understand this.
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] gpio: export 'debounce' attribute if supported by the gpio chip
2012-12-07 8:07 ` Linus Walleij
@ 2012-12-07 14:59 ` Guenter Roeck
2012-12-07 16:20 ` Guenter Roeck
2012-12-07 16:49 ` Alan Cox
0 siblings, 2 replies; 14+ messages in thread
From: Guenter Roeck @ 2012-12-07 14:59 UTC (permalink / raw)
To: Linus Walleij; +Cc: Guenter Roeck, linux-kernel, Grant Likely, Dmitry Torokhov
On Fri, Dec 07, 2012 at 09:07:28AM +0100, Linus Walleij wrote:
> On Thu, Dec 6, 2012 at 7:32 AM, Guenter Roeck <linux@roeck-us.net> wrote:
>
> > Create a 'debounce' attribute if debounce is supported by the gpio
> > chip and a gpio pin is exported.
> >
> > Signed-off-by: Guenter Roeck <linux@roeck-us.net>
>
> Can you describe the usecase for this?
>
> I have this problem when working as a back-up GPIO maintainer that
> I don't really understand the userspace apps doing this.
>
> I would guess something like a userspace app reading a GPIO switch
> and needing to set this to avoid key bounces, but it'd be nice to know
> if this is really the case.
>
Yes, that is one if the use cases. Button pressed on the chassis/board
requesting user space action. Another is board presence detect pins which
require rebounce support and are handled in user space. Yes, the later should be
handled in the kernel, and most of them are, but there are some which don't need
immediate kernel activity and are handled completely by applications.
There may be other use cases - there are hundreds of gpio pins in the system I
am working on, and I have not looked into all of them.
> If this is the usecase I am slightly concerned why these are not used:
> drivers/input/keyboard/gpio_keys_polled.c
> drivers/input/keyboard/gpio_keys.c
>
> The latter even uses the in-kernel debounce interface.
>
> I'd agree if this is not user input at all but something like a switch
> in a factory production line.
>
I could imagine declaring the activity request buttons to be "input", but for
presence detects it is a bit far fetched and would add too much complexity.
Thanks,
Guenter
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] gpio: export 'debounce' attribute if supported by the gpio chip
2012-12-07 14:59 ` Guenter Roeck
@ 2012-12-07 16:20 ` Guenter Roeck
2012-12-07 16:49 ` Alan Cox
1 sibling, 0 replies; 14+ messages in thread
From: Guenter Roeck @ 2012-12-07 16:20 UTC (permalink / raw)
To: Linus Walleij; +Cc: Guenter Roeck, linux-kernel, Grant Likely, Dmitry Torokhov
On Fri, Dec 07, 2012 at 06:59:55AM -0800, Guenter Roeck wrote:
> On Fri, Dec 07, 2012 at 09:07:28AM +0100, Linus Walleij wrote:
> > On Thu, Dec 6, 2012 at 7:32 AM, Guenter Roeck <linux@roeck-us.net> wrote:
> >
> > > Create a 'debounce' attribute if debounce is supported by the gpio
> > > chip and a gpio pin is exported.
> > >
> > > Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> >
> > Can you describe the usecase for this?
> >
> > I have this problem when working as a back-up GPIO maintainer that
> > I don't really understand the userspace apps doing this.
> >
> > I would guess something like a userspace app reading a GPIO switch
> > and needing to set this to avoid key bounces, but it'd be nice to know
> > if this is really the case.
> >
> Yes, that is one if the use cases. Button pressed on the chassis/board
> requesting user space action. Another is board presence detect pins which
> require rebounce support and are handled in user space. Yes, the later should be
> handled in the kernel, and most of them are, but there are some which don't need
> immediate kernel activity and are handled completely by applications.
>
> There may be other use cases - there are hundreds of gpio pins in the system I
> am working on, and I have not looked into all of them.
>
There are three use cases, all related to each other.
- board present (connector pin)
- board removal request (button)
- board voltage good (connector pin)
Guenter
> > If this is the usecase I am slightly concerned why these are not used:
> > drivers/input/keyboard/gpio_keys_polled.c
> > drivers/input/keyboard/gpio_keys.c
> >
> > The latter even uses the in-kernel debounce interface.
> >
> > I'd agree if this is not user input at all but something like a switch
> > in a factory production line.
> >
> I could imagine declaring the activity request buttons to be "input", but for
> presence detects it is a bit far fetched and would add too much complexity.
>
> Thanks,
> Guenter
>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] gpio: export 'debounce' attribute if supported by the gpio chip
2012-12-07 14:59 ` Guenter Roeck
2012-12-07 16:20 ` Guenter Roeck
@ 2012-12-07 16:49 ` Alan Cox
2012-12-09 9:58 ` anish kumar
2012-12-10 10:04 ` Linus Walleij
1 sibling, 2 replies; 14+ messages in thread
From: Alan Cox @ 2012-12-07 16:49 UTC (permalink / raw)
To: Guenter Roeck
Cc: Linus Walleij, Guenter Roeck, linux-kernel, Grant Likely,
Dmitry Torokhov
> I could imagine declaring the activity request buttons to be "input", but for
> presence detects it is a bit far fetched and would add too much complexity.
Android tries to address this with its switch class driver, but I'm not
sure its actually got anything over making them input devices.
Alan
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] gpio: export 'debounce' attribute if supported by the gpio chip
2012-12-07 16:49 ` Alan Cox
@ 2012-12-09 9:58 ` anish kumar
2012-12-09 11:03 ` Alan Cox
2012-12-10 10:04 ` Linus Walleij
1 sibling, 1 reply; 14+ messages in thread
From: anish kumar @ 2012-12-09 9:58 UTC (permalink / raw)
To: Alan Cox
Cc: Guenter Roeck, Linus Walleij, Guenter Roeck, linux-kernel,
Grant Likely, Dmitry Torokhov
On Fri, 2012-12-07 at 16:49 +0000, Alan Cox wrote:
> > I could imagine declaring the activity request buttons to be "input", but for
> > presence detects it is a bit far fetched and would add too much complexity.
>
> Android tries to address this with its switch class driver, but I'm not
> sure its actually got anything over making them input devices.
Sorry for not understanding the context here.How the debounce sysfs
added by Guenter has anything to do with switch driver in android?
AFAIK android just uses switch driver api to talk to driver to get the
status of the headset and the status of the keys if headset has any.This
API in turn updates the sysfs to let userspace know the status change
using kobject uevent.
Switch driver is replaced by extcon in the mainline.
>
> Alan
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] gpio: export 'debounce' attribute if supported by the gpio chip
2012-12-09 9:58 ` anish kumar
@ 2012-12-09 11:03 ` Alan Cox
2012-12-09 17:07 ` Guenter Roeck
0 siblings, 1 reply; 14+ messages in thread
From: Alan Cox @ 2012-12-09 11:03 UTC (permalink / raw)
To: anish kumar
Cc: Guenter Roeck, Linus Walleij, Guenter Roeck, linux-kernel,
Grant Likely, Dmitry Torokhov
On Sun, 09 Dec 2012 01:58:19 -0800
anish kumar <anish198519851985@gmail.com> wrote:
> On Fri, 2012-12-07 at 16:49 +0000, Alan Cox wrote:
> > > I could imagine declaring the activity request buttons to be "input", but for
> > > presence detects it is a bit far fetched and would add too much complexity.
> >
> > Android tries to address this with its switch class driver, but I'm not
> > sure its actually got anything over making them input devices.
>
> Sorry for not understanding the context here.How the debounce sysfs
> added by Guenter has anything to do with switch driver in android?
The other more general option is to make the input layer do the debounce
and make them all inputs rather than just relying on any gpio layer
support.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] gpio: export 'debounce' attribute if supported by the gpio chip
2012-12-09 11:03 ` Alan Cox
@ 2012-12-09 17:07 ` Guenter Roeck
2012-12-09 22:36 ` Grant Likely
2012-12-10 10:11 ` Linus Walleij
0 siblings, 2 replies; 14+ messages in thread
From: Guenter Roeck @ 2012-12-09 17:07 UTC (permalink / raw)
To: Alan Cox
Cc: anish kumar, Linus Walleij, Guenter Roeck, linux-kernel,
Grant Likely, Dmitry Torokhov
On Sun, Dec 09, 2012 at 11:03:19AM +0000, Alan Cox wrote:
> On Sun, 09 Dec 2012 01:58:19 -0800
> anish kumar <anish198519851985@gmail.com> wrote:
>
> > On Fri, 2012-12-07 at 16:49 +0000, Alan Cox wrote:
> > > > I could imagine declaring the activity request buttons to be "input", but for
> > > > presence detects it is a bit far fetched and would add too much complexity.
> > >
> > > Android tries to address this with its switch class driver, but I'm not
> > > sure its actually got anything over making them input devices.
> >
> > Sorry for not understanding the context here.How the debounce sysfs
> > added by Guenter has anything to do with switch driver in android?
>
> The other more general option is to make the input layer do the debounce
> and make them all inputs rather than just relying on any gpio layer
> support.
>
The gpio pins I am dealing with are provided by an FPGA which is used on various
boards. While the gpio access registers are always the same, the actual usage is
board specific. This means I either need to write ugly code, or use the gpio
subsystem to provide access to the gpio pins. Ugly code is out of the question,
which means I'll need gpio support.
Anyway, I want to keep things simple, not add unnecessary complexity. Having to
go through the input subsystem just to be able to support debounce on a couple
of input pins doesn't really sound simple. Guess I'll have to find another
solution if the patch is not accepted. Maybe I'll add a "debounce" property to
the gpio driver's of properties.
Thanks,
Guenter
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] gpio: export 'debounce' attribute if supported by the gpio chip
2012-12-09 17:07 ` Guenter Roeck
@ 2012-12-09 22:36 ` Grant Likely
2012-12-10 10:11 ` Linus Walleij
1 sibling, 0 replies; 14+ messages in thread
From: Grant Likely @ 2012-12-09 22:36 UTC (permalink / raw)
To: Guenter Roeck
Cc: Alan Cox, anish kumar, Linus Walleij, Guenter Roeck,
Linux Kernel Mailing List, Dmitry Torokhov
On Sun, Dec 9, 2012 at 5:07 PM, Guenter Roeck <groeck-dsl@sbcglobal.net> wrote:
> On Sun, Dec 09, 2012 at 11:03:19AM +0000, Alan Cox wrote:
>> On Sun, 09 Dec 2012 01:58:19 -0800
>> anish kumar <anish198519851985@gmail.com> wrote:
>>
>> > On Fri, 2012-12-07 at 16:49 +0000, Alan Cox wrote:
>> > > > I could imagine declaring the activity request buttons to be "input", but for
>> > > > presence detects it is a bit far fetched and would add too much complexity.
>> > >
>> > > Android tries to address this with its switch class driver, but I'm not
>> > > sure its actually got anything over making them input devices.
>> >
>> > Sorry for not understanding the context here.How the debounce sysfs
>> > added by Guenter has anything to do with switch driver in android?
>>
>> The other more general option is to make the input layer do the debounce
>> and make them all inputs rather than just relying on any gpio layer
>> support.
>>
> The gpio pins I am dealing with are provided by an FPGA which is used on various
> boards. While the gpio access registers are always the same, the actual usage is
> board specific. This means I either need to write ugly code, or use the gpio
> subsystem to provide access to the gpio pins. Ugly code is out of the question,
> which means I'll need gpio support.
>
> Anyway, I want to keep things simple, not add unnecessary complexity. Having to
> go through the input subsystem just to be able to support debounce on a couple
> of input pins doesn't really sound simple. Guess I'll have to find another
> solution if the patch is not accepted. Maybe I'll add a "debounce" property to
> the gpio driver's of properties.
I haven't looked deeply at the patch to give you an answer yet, but
I'd recommend you go with the DT property approach anyway. The gpio
sysfs interface is horribly designed and I'm not keen on adding new
features to it.
g.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] gpio: export 'debounce' attribute if supported by the gpio chip
2012-12-09 17:07 ` Guenter Roeck
2012-12-09 22:36 ` Grant Likely
@ 2012-12-10 10:11 ` Linus Walleij
1 sibling, 0 replies; 14+ messages in thread
From: Linus Walleij @ 2012-12-10 10:11 UTC (permalink / raw)
To: Guenter Roeck
Cc: Alan Cox, anish kumar, Guenter Roeck, linux-kernel, Grant Likely,
Dmitry Torokhov
On Sun, Dec 9, 2012 at 6:07 PM, Guenter Roeck <groeck-dsl@sbcglobal.net> wrote:
> The gpio pins I am dealing with are provided by an FPGA which is used on various
> boards. While the gpio access registers are always the same, the actual usage is
> board specific. This means I either need to write ugly code, or use the gpio
> subsystem to provide access to the gpio pins. Ugly code is out of the question,
> which means I'll need gpio support.
>
> Anyway, I want to keep things simple, not add unnecessary complexity. Having to
> go through the input subsystem just to be able to support debounce on a couple
> of input pins doesn't really sound simple. Guess I'll have to find another
> solution if the patch is not accepted. Maybe I'll add a "debounce" property to
> the gpio driver's of properties.
I would like you to seriously consider both gpio-input and the new
drivers/extcon/extcon-gpio.c driver (maybe adding debounce into that
driver). The latter also has a sysfs interface.
Your usecases seem to be EXTCON_MECHANICAL. If not, new classes
can surely be added.
There is some risk that sysfs makes everything that is a GPIO line
appear as GPIO instead of what it really is, which is not helpful
for userspace which will have to keep track of all the routing of the
electronics.
The latter might be comfortable if you're designing and maintaining the
whole system with firmware and so on, but from a newcomer
examining the system in sysfs it's not helpful, and we're designing
that ABI for a purpose.
(And I share Grant's hesitant stance on extending the GPIO sysfs.)
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] gpio: export 'debounce' attribute if supported by the gpio chip
2012-12-07 16:49 ` Alan Cox
2012-12-09 9:58 ` anish kumar
@ 2012-12-10 10:04 ` Linus Walleij
2012-12-10 18:48 ` Guenter Roeck
1 sibling, 1 reply; 14+ messages in thread
From: Linus Walleij @ 2012-12-10 10:04 UTC (permalink / raw)
To: Alan Cox
Cc: Guenter Roeck, Guenter Roeck, linux-kernel, Grant Likely,
Dmitry Torokhov
On Fri, Dec 7, 2012 at 5:49 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> I could imagine declaring the activity request buttons to be "input", but for
>> presence detects it is a bit far fetched and would add too much complexity.
>
> Android tries to address this with its switch class driver, but I'm not
> sure its actually got anything over making them input devices.
This has actually been merged into the kernel proper as drivers/extcon.
So another poke on Günther if this fulfills the needs?
Yours,
Linus Walleij
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] gpio: export 'debounce' attribute if supported by the gpio chip
2012-12-10 10:04 ` Linus Walleij
@ 2012-12-10 18:48 ` Guenter Roeck
2012-12-10 19:37 ` anish singh
0 siblings, 1 reply; 14+ messages in thread
From: Guenter Roeck @ 2012-12-10 18:48 UTC (permalink / raw)
To: Linus Walleij
Cc: Alan Cox, Guenter Roeck, linux-kernel, Grant Likely,
Dmitry Torokhov
On Mon, Dec 10, 2012 at 11:04:09AM +0100, Linus Walleij wrote:
> On Fri, Dec 7, 2012 at 5:49 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>
> >> I could imagine declaring the activity request buttons to be "input", but for
> >> presence detects it is a bit far fetched and would add too much complexity.
> >
> > Android tries to address this with its switch class driver, but I'm not
> > sure its actually got anything over making them input devices.
>
> This has actually been merged into the kernel proper as drivers/extcon.
>
> So another poke on Günther if this fulfills the needs?
>
I'll look into it. Currently I am hampered by a cold which seems to mug my
brain, and technically by the need to backport extcon to 3.0 (if that is even
possible) since our chip vendor does not yet support a more recent kernel.
Thanks,
Guenter
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] gpio: export 'debounce' attribute if supported by the gpio chip
2012-12-10 18:48 ` Guenter Roeck
@ 2012-12-10 19:37 ` anish singh
2012-12-13 17:08 ` Guenter Roeck
0 siblings, 1 reply; 14+ messages in thread
From: anish singh @ 2012-12-10 19:37 UTC (permalink / raw)
To: Guenter Roeck
Cc: Linus Walleij, Alan Cox, Guenter Roeck, linux-kernel,
Grant Likely, Dmitry Torokhov
On Mon, Dec 10, 2012 at 10:48 AM, Guenter Roeck
<groeck-dsl@sbcglobal.net> wrote:
> On Mon, Dec 10, 2012 at 11:04:09AM +0100, Linus Walleij wrote:
>> On Fri, Dec 7, 2012 at 5:49 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>>
>> >> I could imagine declaring the activity request buttons to be "input", but for
>> >> presence detects it is a bit far fetched and would add too much complexity.
>> >
>> > Android tries to address this with its switch class driver, but I'm not
>> > sure its actually got anything over making them input devices.
>>
>> This has actually been merged into the kernel proper as drivers/extcon.
>>
>> So another poke on Günther if this fulfills the needs?
>>
> I'll look into it. Currently I am hampered by a cold which seems to mug my
> brain, and technically by the need to backport extcon to 3.0 (if that is even
> possible) since our chip vendor does not yet support a more recent kernel.
It is very much possible.I have already tried that and it works.
>
> Thanks,
> Guenter
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] gpio: export 'debounce' attribute if supported by the gpio chip
2012-12-10 19:37 ` anish singh
@ 2012-12-13 17:08 ` Guenter Roeck
0 siblings, 0 replies; 14+ messages in thread
From: Guenter Roeck @ 2012-12-13 17:08 UTC (permalink / raw)
To: anish singh
Cc: Linus Walleij, Alan Cox, linux-kernel, Grant Likely,
Dmitry Torokhov
On Mon, Dec 10, 2012 at 11:37:35AM -0800, anish singh wrote:
> On Mon, Dec 10, 2012 at 10:48 AM, Guenter Roeck
> <groeck-dsl@sbcglobal.net> wrote:
> > On Mon, Dec 10, 2012 at 11:04:09AM +0100, Linus Walleij wrote:
> >> On Fri, Dec 7, 2012 at 5:49 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> >>
> >> >> I could imagine declaring the activity request buttons to be "input", but for
> >> >> presence detects it is a bit far fetched and would add too much complexity.
> >> >
> >> > Android tries to address this with its switch class driver, but I'm not
> >> > sure its actually got anything over making them input devices.
> >>
> >> This has actually been merged into the kernel proper as drivers/extcon.
> >>
> >> So another poke on Günther if this fulfills the needs?
> >>
> > I'll look into it. Currently I am hampered by a cold which seems to mug my
> > brain, and technically by the need to backport extcon to 3.0 (if that is even
> > possible) since our chip vendor does not yet support a more recent kernel.
> It is very much possible.I have already tried that and it works.
Confirmed.
Looks like this is going to work for me, so I won't need the gpio patch. Please
ignore it.
Thanks,
Guenter
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2012-12-13 17:08 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-12-06 6:32 [PATCH] gpio: export 'debounce' attribute if supported by the gpio chip Guenter Roeck
2012-12-07 8:07 ` Linus Walleij
2012-12-07 14:59 ` Guenter Roeck
2012-12-07 16:20 ` Guenter Roeck
2012-12-07 16:49 ` Alan Cox
2012-12-09 9:58 ` anish kumar
2012-12-09 11:03 ` Alan Cox
2012-12-09 17:07 ` Guenter Roeck
2012-12-09 22:36 ` Grant Likely
2012-12-10 10:11 ` Linus Walleij
2012-12-10 10:04 ` Linus Walleij
2012-12-10 18:48 ` Guenter Roeck
2012-12-10 19:37 ` anish singh
2012-12-13 17:08 ` Guenter Roeck
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).