linux-kernel - Re: [PATCH 1/6 v14] gpio: Add a block GPIO API to gpiolib

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]

Message-ID: <51053268.2000002@antcom.de>
Date:	Sun, 27 Jan 2013 14:58:00 +0100
From:	Roland Stigge <stigge@...com.de>
To:	Stijn Devriendt <highguy@...il.com>
CC:	gregkh@...uxfoundation.org, grant.likely@...retlab.ca,
	linus.walleij@...aro.org, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, w.sang@...gutronix.de,
	jbe@...gutronix.de, plagnioj@...osoft.com,
	broonie@...nsource.wolfsonmicro.com, daniel-gl@....net,
	rmallon@...il.com, sr@...x.de, wg@...ndegger.com,
	mark.rutland@....com, nicolas.ferre@...el.com
Subject: Re: [PATCH 1/6 v14] gpio: Add a block GPIO API to gpiolib

On 27/01/13 14:19, Stijn Devriendt wrote:
>> +Block GPIO
>> +----------
>> +
>> +The above described interface concentrates on handling single GPIOs.  However,
>> +in applications where it is critical to set several GPIOs at once, this
>> +interface doesn't work well, e.g. bit-banging protocols via grouped GPIO lines.
>> +Consider a GPIO controller that is connected via a slow I2C line. When
>> +switching two or more GPIOs one after another, there can be considerable time
>> +between those events. This is solved by an interface called Block GPIO:
>> +
>> +struct gpio_block *gpio_block_create(unsigned int *gpios, size_t size,
>> +                                    const char *name);
>> +
>> +This creates a new block of GPIOs as a list of GPIO numbers with the specified
>> +size which are accessible via the returned struct gpio_block and the accessor
>> +functions described below. Please note that you need to request the GPIOs
>> +separately via gpio_request(). Similarly, the direction of the used GPIOs need
>> +to be set by the user before using the block.
> 
> Is there anything holding you back from letting gpio_block_create() do
> the request
> for all the pins?

It's analoguous to plain GPIOs: They exist, but are not requested (by
whom?) by default.

> Also, wouldn't it make sense to have a gpio_block_direction_input()
> and _output()
> variant? On the other hand, for things like I2C and SPI emulation,
> some pins will
> naturally be always output (like clock lines) while other could be
> switched between
> in and output (like the i2c data line).

Right. Current implementation emphasizes on switching, not direction or
other convenience functions, which could be added, nevertheless.

Roland
--
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/