diff mbox

[3/9] gpio: Allow hogged gpios to be requested

Message ID 1437125570-28623-4-git-send-email-mpa@pengutronix.de (mailing list archive)
State New, archived
Headers show

Commit Message

Markus Pargmann July 17, 2015, 9:32 a.m. UTC
It can be useful to claim hogged gpios later, for example from
userspace. This allows to set defaults for GPIOs using the hogging
mechanism and override the setup later from userspace or a kernel driver.

This patch adds a check for hogged gpios to allow requesting them. If
the gpio is not hogged but marked as requested, it still fails with
-EBUSY.

Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
---
 drivers/gpio/gpiolib.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Comments

Uwe Kleine-König July 17, 2015, 8:27 p.m. UTC | #1
Hello,

On Fri, Jul 17, 2015 at 11:32:44AM +0200, Markus Pargmann wrote:
> It can be useful to claim hogged gpios later, for example from
> userspace. This allows to set defaults for GPIOs using the hogging
> mechanism and override the setup later from userspace or a kernel driver.
> 
> This patch adds a check for hogged gpios to allow requesting them. If
> the gpio is not hogged but marked as requested, it still fails with
> -EBUSY.
> 
> Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
> ---
>  drivers/gpio/gpiolib.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> index bf4bd1d120c3..9f402b159cbe 100644
> --- a/drivers/gpio/gpiolib.c
> +++ b/drivers/gpio/gpiolib.c
> @@ -798,7 +798,8 @@ static int __gpiod_request(struct gpio_desc *desc, const char *label)
>  	 * before IRQs are enabled, for non-sleeping (SOC) GPIOs.
>  	 */
>  
> -	if (test_and_set_bit(FLAG_REQUESTED, &desc->flags) == 0) {
> +	if (test_and_set_bit(FLAG_REQUESTED, &desc->flags) == 0 ||
> +	    test_and_clear_bit(FLAG_IS_HOGGED, &desc->flags) == 1) {
>  		desc_set_label(desc, label ? : "?");
>  		status = 0;
I don't like this patch. IMHO hogging is a "use" of a GPIO that should
prevent it being requested.

While I think it's useful to be able to export some hogged pins I don't
think this should be possible for all hogged pins unconditionally. And
for gpios being used by drivers I'd expect they don't need to be hogged
at all.

I don't have a good idea how to solve that. Adding another property to a
gpio that should be allowd to be exported can hardly count as hardware
description and so doesn't belong in a device tree?!

Please don't consider this objection as a reason for a NACK, only as
starting point for a discussion.

Apart from that: Does this result in hogged gpios being able to be
requested by two additional drivers in parallel? Maybe the IS_HOGGED
flag should be dropped when the gpio is requested?

Best regards
Uwe
Markus Pargmann July 19, 2015, 2:01 p.m. UTC | #2
Hi Uwe,

On Fri, Jul 17, 2015 at 10:27:02PM +0200, Uwe Kleine-König wrote:
> Hello,
> 
> On Fri, Jul 17, 2015 at 11:32:44AM +0200, Markus Pargmann wrote:
> > It can be useful to claim hogged gpios later, for example from
> > userspace. This allows to set defaults for GPIOs using the hogging
> > mechanism and override the setup later from userspace or a kernel driver.
> > 
> > This patch adds a check for hogged gpios to allow requesting them. If
> > the gpio is not hogged but marked as requested, it still fails with
> > -EBUSY.
> > 
> > Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
> > ---
> >  drivers/gpio/gpiolib.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> > index bf4bd1d120c3..9f402b159cbe 100644
> > --- a/drivers/gpio/gpiolib.c
> > +++ b/drivers/gpio/gpiolib.c
> > @@ -798,7 +798,8 @@ static int __gpiod_request(struct gpio_desc *desc, const char *label)
> >  	 * before IRQs are enabled, for non-sleeping (SOC) GPIOs.
> >  	 */
> >  
> > -	if (test_and_set_bit(FLAG_REQUESTED, &desc->flags) == 0) {
> > +	if (test_and_set_bit(FLAG_REQUESTED, &desc->flags) == 0 ||
> > +	    test_and_clear_bit(FLAG_IS_HOGGED, &desc->flags) == 1) {
> >  		desc_set_label(desc, label ? : "?");
> >  		status = 0;
> I don't like this patch. IMHO hogging is a "use" of a GPIO that should
> prevent it being requested.

I disagree with you here. The original patch stated in its description
that it was designed to initialize GPIOs. In my understanding this does
not necessarily mean that a hogged GPIO has to be blocked forever.

It may be a use case for example to initialize multiplexers to known
safe values to work with the system right from the beginning. Later it
may be necessary to change them.

> 
> While I think it's useful to be able to export some hogged pins I don't
> think this should be possible for all hogged pins unconditionally. And
> for gpios being used by drivers I'd expect they don't need to be hogged
> at all.
> 
> I don't have a good idea how to solve that. Adding another property to a
> gpio that should be allowd to be exported can hardly count as hardware
> description and so doesn't belong in a device tree?!
> 
> Please don't consider this objection as a reason for a NACK, only as
> starting point for a discussion.
> 
> Apart from that: Does this result in hogged gpios being able to be
> requested by two additional drivers in parallel? Maybe the IS_HOGGED
> flag should be dropped when the gpio is requested?

The IS_HOGGED flag is cleared at the same time it is tested so only one
consumer can request one hogged GPIO. The GPIO is not considered to be
hogged after it is normally requested.

Best regards,

Markus
Uwe Kleine-König July 20, 2015, 6:32 a.m. UTC | #3
Hello Markus,

On Sun, Jul 19, 2015 at 04:01:42PM +0200, Markus Pargmann wrote:
> On Fri, Jul 17, 2015 at 10:27:02PM +0200, Uwe Kleine-König wrote:
> > On Fri, Jul 17, 2015 at 11:32:44AM +0200, Markus Pargmann wrote:
> > > diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> > > index bf4bd1d120c3..9f402b159cbe 100644
> > > --- a/drivers/gpio/gpiolib.c
> > > +++ b/drivers/gpio/gpiolib.c
> > > @@ -798,7 +798,8 @@ static int __gpiod_request(struct gpio_desc *desc, const char *label)
> > >  	 * before IRQs are enabled, for non-sleeping (SOC) GPIOs.
> > >  	 */
> > >  
> > > -	if (test_and_set_bit(FLAG_REQUESTED, &desc->flags) == 0) {
> > > +	if (test_and_set_bit(FLAG_REQUESTED, &desc->flags) == 0 ||
> > > +	    test_and_clear_bit(FLAG_IS_HOGGED, &desc->flags) == 1) {
> > >  		desc_set_label(desc, label ? : "?");
> > >  		status = 0;
> > I don't like this patch. IMHO hogging is a "use" of a GPIO that should
> > prevent it being requested.
> 
> I disagree with you here. The original patch stated in its description
> that it was designed to initialize GPIOs. In my understanding this does
> not necessarily mean that a hogged GPIO has to be blocked forever.
Assume for a moment I can agree with "not necessarily". But now, what
about the cases where a hogged GPIO should be blocked?
IMHO, if you want to drive the GPIO from userspace anyhow, you don't
need to add a hog for it.

> The IS_HOGGED flag is cleared at the same time it is tested so only one
> consumer can request one hogged GPIO. The GPIO is not considered to be
> hogged after it is normally requested.
You're right here, I missed the and_clear_bit part on the test.

Best regards
Uwe
Markus Pargmann July 20, 2015, 7:51 a.m. UTC | #4
On Mon, Jul 20, 2015 at 08:32:49AM +0200, Uwe Kleine-König wrote:
> Hello Markus,
> 
> On Sun, Jul 19, 2015 at 04:01:42PM +0200, Markus Pargmann wrote:
> > On Fri, Jul 17, 2015 at 10:27:02PM +0200, Uwe Kleine-König wrote:
> > > On Fri, Jul 17, 2015 at 11:32:44AM +0200, Markus Pargmann wrote:
> > > > diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> > > > index bf4bd1d120c3..9f402b159cbe 100644
> > > > --- a/drivers/gpio/gpiolib.c
> > > > +++ b/drivers/gpio/gpiolib.c
> > > > @@ -798,7 +798,8 @@ static int __gpiod_request(struct gpio_desc *desc, const char *label)
> > > >  	 * before IRQs are enabled, for non-sleeping (SOC) GPIOs.
> > > >  	 */
> > > >  
> > > > -	if (test_and_set_bit(FLAG_REQUESTED, &desc->flags) == 0) {
> > > > +	if (test_and_set_bit(FLAG_REQUESTED, &desc->flags) == 0 ||
> > > > +	    test_and_clear_bit(FLAG_IS_HOGGED, &desc->flags) == 1) {
> > > >  		desc_set_label(desc, label ? : "?");
> > > >  		status = 0;
> > > I don't like this patch. IMHO hogging is a "use" of a GPIO that should
> > > prevent it being requested.
> > 
> > I disagree with you here. The original patch stated in its description
> > that it was designed to initialize GPIOs. In my understanding this does
> > not necessarily mean that a hogged GPIO has to be blocked forever.
> Assume for a moment I can agree with "not necessarily". But now, what
> about the cases where a hogged GPIO should be blocked?
> IMHO, if you want to drive the GPIO from userspace anyhow, you don't
> need to add a hog for it.

If I don't use a hog I leave the system in an undefined state until the
userspace can initialize the GPIOs. So all the userspace controlled
GPIOs are undefined when all the drivers probe which can lead to
problems if the GPIOs have any indirect influence on hardware components
which drivers probe before the userspace.
I think it is valid to somehow define a safe state for GPIOs in the
devicetree while you can later change this state from userspace?!

Best regards,

Markus

> 
> > The IS_HOGGED flag is cleared at the same time it is tested so only one
> > consumer can request one hogged GPIO. The GPIO is not considered to be
> > hogged after it is normally requested.
> You're right here, I missed the and_clear_bit part on the test.
> 
> Best regards
> Uwe
> 
> -- 
> Pengutronix e.K.                           | Uwe Kleine-König            |
> Industrial Linux Solutions                 | http://www.pengutronix.de/  |
>
Johan Hovold July 28, 2015, 9:17 a.m. UTC | #5
On Sun, Jul 19, 2015 at 04:01:42PM +0200, Markus Pargmann wrote:
> Hi Uwe,
> 
> On Fri, Jul 17, 2015 at 10:27:02PM +0200, Uwe Kleine-König wrote:
> > Hello,
> > 
> > On Fri, Jul 17, 2015 at 11:32:44AM +0200, Markus Pargmann wrote:
> > > It can be useful to claim hogged gpios later, for example from
> > > userspace. This allows to set defaults for GPIOs using the hogging
> > > mechanism and override the setup later from userspace or a kernel driver.
> > > 
> > > This patch adds a check for hogged gpios to allow requesting them. If
> > > the gpio is not hogged but marked as requested, it still fails with
> > > -EBUSY.
> > > 
> > > Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
> > > ---
> > >  drivers/gpio/gpiolib.c | 3 ++-
> > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> > > index bf4bd1d120c3..9f402b159cbe 100644
> > > --- a/drivers/gpio/gpiolib.c
> > > +++ b/drivers/gpio/gpiolib.c
> > > @@ -798,7 +798,8 @@ static int __gpiod_request(struct gpio_desc *desc, const char *label)
> > >  	 * before IRQs are enabled, for non-sleeping (SOC) GPIOs.
> > >  	 */
> > >  
> > > -	if (test_and_set_bit(FLAG_REQUESTED, &desc->flags) == 0) {
> > > +	if (test_and_set_bit(FLAG_REQUESTED, &desc->flags) == 0 ||
> > > +	    test_and_clear_bit(FLAG_IS_HOGGED, &desc->flags) == 1) {
> > >  		desc_set_label(desc, label ? : "?");
> > >  		status = 0;
> > I don't like this patch. IMHO hogging is a "use" of a GPIO that should
> > prevent it being requested.
> 
> I disagree with you here. The original patch stated in its description
> that it was designed to initialize GPIOs. In my understanding this does
> not necessarily mean that a hogged GPIO has to be blocked forever.

IIRC, this use case was discussed but was rejected by Linus when hogs
were added:

	https://lkml.kernel.org/r/CACRpkdZcNcPBYQM438CZJx1gYst9BFBSTj-3Qv2aPGF9pdWa5g@mail.gmail.com

Linus?

Johan
Markus Pargmann July 29, 2015, 6:52 a.m. UTC | #6
On Tue, Jul 28, 2015 at 11:17:53AM +0200, Johan Hovold wrote:
> On Sun, Jul 19, 2015 at 04:01:42PM +0200, Markus Pargmann wrote:
> > Hi Uwe,
> > 
> > On Fri, Jul 17, 2015 at 10:27:02PM +0200, Uwe Kleine-König wrote:
> > > Hello,
> > > 
> > > On Fri, Jul 17, 2015 at 11:32:44AM +0200, Markus Pargmann wrote:
> > > > It can be useful to claim hogged gpios later, for example from
> > > > userspace. This allows to set defaults for GPIOs using the hogging
> > > > mechanism and override the setup later from userspace or a kernel driver.
> > > > 
> > > > This patch adds a check for hogged gpios to allow requesting them. If
> > > > the gpio is not hogged but marked as requested, it still fails with
> > > > -EBUSY.
> > > > 
> > > > Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
> > > > ---
> > > >  drivers/gpio/gpiolib.c | 3 ++-
> > > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> > > > index bf4bd1d120c3..9f402b159cbe 100644
> > > > --- a/drivers/gpio/gpiolib.c
> > > > +++ b/drivers/gpio/gpiolib.c
> > > > @@ -798,7 +798,8 @@ static int __gpiod_request(struct gpio_desc *desc, const char *label)
> > > >  	 * before IRQs are enabled, for non-sleeping (SOC) GPIOs.
> > > >  	 */
> > > >  
> > > > -	if (test_and_set_bit(FLAG_REQUESTED, &desc->flags) == 0) {
> > > > +	if (test_and_set_bit(FLAG_REQUESTED, &desc->flags) == 0 ||
> > > > +	    test_and_clear_bit(FLAG_IS_HOGGED, &desc->flags) == 1) {
> > > >  		desc_set_label(desc, label ? : "?");
> > > >  		status = 0;
> > > I don't like this patch. IMHO hogging is a "use" of a GPIO that should
> > > prevent it being requested.
> > 
> > I disagree with you here. The original patch stated in its description
> > that it was designed to initialize GPIOs. In my understanding this does
> > not necessarily mean that a hogged GPIO has to be blocked forever.
> 
> IIRC, this use case was discussed but was rejected by Linus when hogs
> were added:
> 
> 	https://lkml.kernel.org/r/CACRpkdZcNcPBYQM438CZJx1gYst9BFBSTj-3Qv2aPGF9pdWa5g@mail.gmail.com

I see. Yes I really would like to have this 'initial settings' feature.
Any suggestions for a better way?

Best regards,

Markus

> 
> Linus?
> 
> Johan
>
Linus Walleij Aug. 10, 2015, 9:20 a.m. UTC | #7
On Tue, Jul 28, 2015 at 11:17 AM, Johan Hovold <johan@kernel.org> wrote:
> On Sun, Jul 19, 2015 at 04:01:42PM +0200, Markus Pargmann wrote:

>> > I don't like this patch. IMHO hogging is a "use" of a GPIO that should
>> > prevent it being requested.
>>
>> I disagree with you here. The original patch stated in its description
>> that it was designed to initialize GPIOs. In my understanding this does
>> not necessarily mean that a hogged GPIO has to be blocked forever.
>
> IIRC, this use case was discussed but was rejected by Linus when hogs
> were added:
>
>         https://lkml.kernel.org/r/CACRpkdZcNcPBYQM438CZJx1gYst9BFBSTj-3Qv2aPGF9pdWa5g@mail.gmail.com
>
> Linus?

Yeah that is true. But maybe I softened up a bit.

Basically I want to avoid having two very similar mechanisms.

But that is maybe more of a question of how the code is
arranged and named than what it is called. It would be nicer
if this was referring to initial values rather than hogging,
the mechanism inside the kernel could be the same.

But then there is the path where something that is initially
a hog is turned into a userspace GPIO. Then it is essentially
not a hog anymore, so this property is not static.

Yours,
Linus Walleij
diff mbox

Patch

diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index bf4bd1d120c3..9f402b159cbe 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -798,7 +798,8 @@  static int __gpiod_request(struct gpio_desc *desc, const char *label)
 	 * before IRQs are enabled, for non-sleeping (SOC) GPIOs.
 	 */
 
-	if (test_and_set_bit(FLAG_REQUESTED, &desc->flags) == 0) {
+	if (test_and_set_bit(FLAG_REQUESTED, &desc->flags) == 0 ||
+	    test_and_clear_bit(FLAG_IS_HOGGED, &desc->flags) == 1) {
 		desc_set_label(desc, label ? : "?");
 		status = 0;
 	} else {