From: Martyn Welch <martyn.welch@collabora.co.uk> To: Linus Walleij <linus.walleij@linaro.org> Cc: Arnd Bergmann <arnd@arndb.de>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Mark Rutland <mark.rutland@arm.com>, "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>, Krzysztof Kozlowski <k.kozlowski@samsung.com>, linux-samsung-soc <linux-samsung-soc@vger.kernel.org>, Russell King <linux@arm.linux.org.uk>, Pawel Moll <pawel.moll@arm.com>, Ian Campbell <ijc+devicetree@hellion.org.uk>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Rob Herring <robh+dt@kernel.org>, Kukjin Kim <kgene@kernel.org>, Kumar Gala <galak@codeaurora.org>, Olof Johansson <olof@lixom.net>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org> Subject: Re: [PATCH 2/3] Add support for monitoring gpio switches Date: Wed, 16 Dec 2015 10:11:46 +0000 [thread overview] Message-ID: <567138E2.80505@collabora.co.uk> (raw) In-Reply-To: <CACRpkdb=it+U+3-0mvZ9Pf1cnYT_r1KkFiS=C4YDkqrjoRm+kQ@mail.gmail.com> On 11/12/15 09:08, Linus Walleij wrote: > On Fri, Dec 4, 2015 at 6:31 PM, Martyn Welch > <martyn.welch@collabora.co.uk> wrote: > >> Select Chromebooks have gpio attached to switches used to cause the >> firmware to enter alternative modes of operation and/or control other >> device characteristics (such as write protection on flash devices). This >> patch adds a driver that exposes a read-only interface to allow these >> signals to be read from user space. >> >> This functionality has been generalised to provide support for any device >> with device tree support which needs to identify a gpio as being used for a >> specific task. >> >> Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk> > > If you want to do this thing, also propose a device tree binding document > for "gpio-switch". > > But first (from Documentation/gpio/drivers-on-gpio.txt): > > - gpio-keys: drivers/input/keyboard/gpio_keys.c is used when your GPIO line > can generate interrupts in response to a key press. Also supports debounce. > This one generates input events from gpio. I'm not looking to generate events. > - gpio-keys-polled: drivers/input/keyboard/gpio_keys_polled.c is used when your > GPIO line cannot generate interrupts, so it needs to be periodically polled > by a timer. > Ditto (but using a polled mechanism rather than interrupts) > - extcon-gpio: drivers/extcon/extcon-gpio.c is used when you need to read an > external connector status, such as a headset line for an audio driver or an > HDMI connector. It will provide a better userspace sysfs interface than GPIO. > This appears to be exclusively for monitoring insertion events, or am I missing something? > So you mean none of these apply for this case? > No, I'm looking for a mechanism to identify GPIO as connected to a specific signal, which is provided across multiple devices, but which might be implemented subtly differently on different platforms (i.e. active high/low) and on different GPIO lines. > Second: what you want to do is export a number of GPIOs with certain names > to userspace. This is something very generic and should be implemented > as such, not as something Chromebook-specific. > I'd agree that my first implementation was ChromeBook specific, but I'm fairly sure that my last attempt wasn't. I've mentioned ChromeBooks as an example of an existing use case. > Patches like that has however already been suggested, and I have NACKed > them because the GPIO sysfs ABI is insane, and that is why I am refactoring > the world to create a proper chardev ABI for GPIO instead. See: > http://marc.info/?l=linux-gpio&m=144550276512673&w=2 > I can certainly understand the rationale for the changes that you are proposing, though do worry that it does make it a bit tougher to use from scripting languages. I see that the question of how to provide functionality equivalent to the above was raised and no answer was forthcoming. Is there a plan for supporting the identification of a GPIO line serving a specific purpose? What is the status of the mentioned patch series? Martyn > So for the moment, NACK on this, please participate in creating the > *right* ABI for GPIO instead of trying to shoehorn stuff into the dying > sysfs ABI. > > Yours, > Linus Walleij >
WARNING: multiple messages have this Message-ID (diff)
From: martyn.welch@collabora.co.uk (Martyn Welch) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH 2/3] Add support for monitoring gpio switches Date: Wed, 16 Dec 2015 10:11:46 +0000 [thread overview] Message-ID: <567138E2.80505@collabora.co.uk> (raw) In-Reply-To: <CACRpkdb=it+U+3-0mvZ9Pf1cnYT_r1KkFiS=C4YDkqrjoRm+kQ@mail.gmail.com> On 11/12/15 09:08, Linus Walleij wrote: > On Fri, Dec 4, 2015 at 6:31 PM, Martyn Welch > <martyn.welch@collabora.co.uk> wrote: > >> Select Chromebooks have gpio attached to switches used to cause the >> firmware to enter alternative modes of operation and/or control other >> device characteristics (such as write protection on flash devices). This >> patch adds a driver that exposes a read-only interface to allow these >> signals to be read from user space. >> >> This functionality has been generalised to provide support for any device >> with device tree support which needs to identify a gpio as being used for a >> specific task. >> >> Signed-off-by: Martyn Welch <martyn.welch@collabora.co.uk> > > If you want to do this thing, also propose a device tree binding document > for "gpio-switch". > > But first (from Documentation/gpio/drivers-on-gpio.txt): > > - gpio-keys: drivers/input/keyboard/gpio_keys.c is used when your GPIO line > can generate interrupts in response to a key press. Also supports debounce. > This one generates input events from gpio. I'm not looking to generate events. > - gpio-keys-polled: drivers/input/keyboard/gpio_keys_polled.c is used when your > GPIO line cannot generate interrupts, so it needs to be periodically polled > by a timer. > Ditto (but using a polled mechanism rather than interrupts) > - extcon-gpio: drivers/extcon/extcon-gpio.c is used when you need to read an > external connector status, such as a headset line for an audio driver or an > HDMI connector. It will provide a better userspace sysfs interface than GPIO. > This appears to be exclusively for monitoring insertion events, or am I missing something? > So you mean none of these apply for this case? > No, I'm looking for a mechanism to identify GPIO as connected to a specific signal, which is provided across multiple devices, but which might be implemented subtly differently on different platforms (i.e. active high/low) and on different GPIO lines. > Second: what you want to do is export a number of GPIOs with certain names > to userspace. This is something very generic and should be implemented > as such, not as something Chromebook-specific. > I'd agree that my first implementation was ChromeBook specific, but I'm fairly sure that my last attempt wasn't. I've mentioned ChromeBooks as an example of an existing use case. > Patches like that has however already been suggested, and I have NACKed > them because the GPIO sysfs ABI is insane, and that is why I am refactoring > the world to create a proper chardev ABI for GPIO instead. See: > http://marc.info/?l=linux-gpio&m=144550276512673&w=2 > I can certainly understand the rationale for the changes that you are proposing, though do worry that it does make it a bit tougher to use from scripting languages. I see that the question of how to provide functionality equivalent to the above was raised and no answer was forthcoming. Is there a plan for supporting the identification of a GPIO line serving a specific purpose? What is the status of the mentioned patch series? Martyn > So for the moment, NACK on this, please participate in creating the > *right* ABI for GPIO instead of trying to shoehorn stuff into the dying > sysfs ABI. > > Yours, > Linus Walleij >
next prev parent reply other threads:[~2015-12-16 10:11 UTC|newest] Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-12-04 17:31 Add support for monitoring gpio switches Martyn Welch 2015-12-04 17:31 ` Martyn Welch 2015-12-04 17:31 ` Martyn Welch 2015-12-04 17:31 ` [PATCH 1/3] Device tree binding documentation for gpio-switch Martyn Welch 2015-12-04 17:31 ` Martyn Welch 2015-12-07 17:37 ` Rob Herring 2015-12-07 17:37 ` Rob Herring 2015-12-07 21:10 ` Martyn Welch 2015-12-07 21:10 ` Martyn Welch 2015-12-11 12:39 ` Linus Walleij 2015-12-11 12:39 ` Linus Walleij 2015-12-11 12:39 ` Linus Walleij 2015-12-11 14:06 ` Rob Herring 2015-12-11 14:06 ` Rob Herring 2015-12-11 14:06 ` Rob Herring 2015-12-14 14:28 ` Linus Walleij 2015-12-14 14:28 ` Linus Walleij 2015-12-14 14:28 ` Linus Walleij 2015-12-14 15:45 ` Rob Herring 2015-12-14 15:45 ` Rob Herring 2015-12-14 15:45 ` Rob Herring 2015-12-15 9:09 ` Markus Pargmann 2015-12-15 9:09 ` Markus Pargmann 2016-03-02 16:03 ` Rob Herring 2016-03-02 16:03 ` Rob Herring 2016-03-02 16:03 ` Rob Herring 2016-03-07 8:26 ` Markus Pargmann 2016-03-07 8:26 ` Markus Pargmann 2016-03-07 8:26 ` Markus Pargmann 2015-12-04 17:31 ` [PATCH 2/3] Add support for monitoring gpio switches Martyn Welch 2015-12-04 17:31 ` Martyn Welch 2015-12-04 17:31 ` Martyn Welch 2015-12-04 18:14 ` [PATCH] fix noderef.cocci warnings kbuild test robot 2015-12-04 18:14 ` kbuild test robot 2015-12-04 18:14 ` kbuild test robot 2015-12-04 18:14 ` [PATCH 2/3] Add support for monitoring gpio switches kbuild test robot 2015-12-04 18:14 ` kbuild test robot 2015-12-04 18:14 ` kbuild test robot 2015-12-04 18:57 ` Greg Kroah-Hartman 2015-12-04 18:57 ` Greg Kroah-Hartman 2015-12-05 10:42 ` Martyn Welch 2015-12-05 10:42 ` Martyn Welch 2015-12-11 9:08 ` Linus Walleij 2015-12-11 9:08 ` Linus Walleij 2015-12-11 9:08 ` Linus Walleij 2015-12-16 10:11 ` Martyn Welch [this message] 2015-12-16 10:11 ` Martyn Welch 2015-12-16 10:11 ` Martyn Welch 2015-12-22 9:25 ` Linus Walleij 2015-12-22 9:25 ` Linus Walleij 2015-12-22 9:25 ` Linus Walleij 2015-12-04 17:31 ` [PATCH 3/3] ARM: dts: Addition of binding for gpio switches on peach-pi Martyn Welch 2015-12-04 17:31 ` Martyn Welch
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=567138E2.80505@collabora.co.uk \ --to=martyn.welch@collabora.co.uk \ --cc=arnd@arndb.de \ --cc=devicetree@vger.kernel.org \ --cc=galak@codeaurora.org \ --cc=gregkh@linuxfoundation.org \ --cc=ijc+devicetree@hellion.org.uk \ --cc=k.kozlowski@samsung.com \ --cc=kgene@kernel.org \ --cc=linus.walleij@linaro.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-samsung-soc@vger.kernel.org \ --cc=linux@arm.linux.org.uk \ --cc=mark.rutland@arm.com \ --cc=olof@lixom.net \ --cc=pawel.moll@arm.com \ --cc=robh+dt@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.