Hi!
On 16/10/12 00:05, Ryan Mallon wrote:
>>> This looks broken. If gbc was re-alloced above (index < 0) then
>>> gbc->remap == NULL and this will oops?
>>
>> No, because I took care that even though index can be < 0, the resulting
>> pointer is never dereferenced for -1.
>
> Ah, I see. I think i
On 16/10/12 04:20, Roland Stigge wrote:
> Hi Ryan,
>
> thank you for your feedback, I will include it, except for some points
> noted below:
>>> + gbc->mask |= BIT(bit);
>>> +
>>> + /* collect gpios that are specified together, represented by
>>> +* neighboring bit
On Fri, Oct 12, 2012 at 9:11 PM, Roland Stigge wrote:
> +#define NR_GPIO_BLOCKS 16
> +
> +static struct gpio_block *gpio_block[NR_GPIO_BLOCKS];
16 looks quite arbitrary, as noted elsewhere please use a list.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux
Hi Ryan,
thank you for your feedback, I will include it, except for some points
noted below:
On 10/15/2012 07:20 AM, Ryan Mallon wrote:
>> +The above described interface concentrates on handling single GPIOs.
>> However,
>> +in applications where it is critical to set several GPIOs at once, thi
On 13/10/12 06:11, Roland Stigge wrote:
> The recurring task of providing simultaneous access to GPIO lines (especially
> for bit banging protocols) needs an appropriate API.
>
> This patch adds a kernel internal "Block GPIO" API that enables simultaneous
> access to several GPIOs. This is done by
The recurring task of providing simultaneous access to GPIO lines (especially
for bit banging protocols) needs an appropriate API.
This patch adds a kernel internal "Block GPIO" API that enables simultaneous
access to several GPIOs. This is done by abstracting GPIOs to an n-bit word:
Once requeste
6 matches
Mail list logo
