| Message ID | 1437125570-28623-4-git-send-email-mpa@pengutronix.de |
|---|---|
| State | New |
| Headers | show |
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
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
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
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/ | >
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 -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 >
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 -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 {
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(-)