lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 05 Dec 2012 22:48:13 +0000
From:	Grant Likely <grant.likely@...retlab.ca>
To:	Peter Ujfalusi <peter.ujfalusi@...com>,
	Linus Walleij <linus.walleij@...aro.org>
Cc:	linux-kernel@...r.kernel.org, linux-omap@...r.kernel.org
Subject: Re: [PATCH] gpio: twl4030: Correct status reporting when the GPIO is used as output

On Wed, 5 Dec 2012 10:49:45 +0100, Peter Ujfalusi <peter.ujfalusi@...com> wrote:
> When the GPIO is configured as output we need to read the GPIODATAOUT*
> register to get correct information. When the GPIO is output the GPIODATAIN*
> registers report 0 all the time (no feedback from output path).
> 
> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@...com>
> ---
>  drivers/gpio/gpio-twl4030.c | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpio/gpio-twl4030.c b/drivers/gpio/gpio-twl4030.c
> index 55b4fe4..e7aa620 100644
> --- a/drivers/gpio/gpio-twl4030.c
> +++ b/drivers/gpio/gpio-twl4030.c
> @@ -191,13 +191,19 @@ static int twl4030_get_gpio_datain(int gpio)
>  	u8 d_bnk = gpio >> 3;
>  	u8 d_off = gpio & 0x7;
>  	u8 base = 0;
> +	int direction;
>  	int ret = 0;
>  
>  	if (unlikely((gpio >= TWL4030_GPIO_MAX)
>  		|| !(gpio_usage_count & BIT(gpio))))
>  		return -EPERM;
>  
> -	base = REG_GPIODATAIN1 + d_bnk;
> +	direction = gpio_twl4030_read(REG_GPIODATADIR1 + d_bnk);
> +	if (direction > 0 && (direction >> d_off) & 0x1)
> +		base = REG_SETGPIODATAOUT1 + d_bnk;
> +	else
> +		base = REG_GPIODATAIN1 + d_bnk;
> +

This is probably quite expensive considering that reads need to go out
the i2c bus. Things like the output state and the pin direction should
be cached by the driver in its private data structure so that you don't
add an additional i2c round trip.

g.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ