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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxx>
> > ---
> >  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

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Attachment: signature.asc
Description: Digital signature


[Index of Archives]     [Linux SPI]     [Linux Kernel]     [Linux ARM (vger)]     [Linux ARM MSM]     [Linux Omap]     [Linux Arm]     [Linux Tegra]     [Fedora ARM]     [Linux for Samsung SOC]     [eCos]     [Linux Fastboot]     [Gcc Help]     [Git]     [DCCP]     [IETF Announce]     [Security]     [Linux MIPS]     [Yosemite Campsites]

  Powered by Linux