linux-kernel - Re: [PATCH RFC 1/2] 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]

Date:	Fri, 28 Sep 2012 10:51:46 +0200
From:	Roland Stigge <stigge@...com.de>
To:	Jean-Christophe PLAGNIOL-VILLARD <plagnioj@...osoft.com>
CC:	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
Subject: Re: [PATCH RFC 1/2] gpio: Add a block GPIO API to gpiolib

Hi!

On 09/28/2012 09:51 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
>> Right - will add checking for the request state of the respective GPIOs.
>>
>> The list of GPIOs to handle is defined by the offset (specified GPIO)
>> and bitmapped list.
>>
>> If it looks more natural, I can change this to a list of ints specifying
>> GPIOs directly.
> you pass the correctly information to the gpiolib
> 
> as if you do not request the gpio the gpiolib will auto request the gpios
> so you api will be 
> int gpio_get_block(unsigned int *gpios, u8* values, size_t size);
> 
> return an error
> 
> int gpio_set_block(unsigned int *gpios, u8* set, size_t size);
> 
> so you do not care about the banks you work on the gpiolib framework will call
> each gpio_chip seperatly. If the set_block get_block is not availlable the
> gpiolib could fallback to get/set
> 
> inside of the gpiolib that you call each bank with a bitmapped list is correct
> but not in the public gpiolib API

Good idea! Talking about the public API (your above gpio_set_block()):
*gpios is a list of GPIOs, but set is still bitmapped (mapped onto the
list specified in *gpios)? To prevent confusion about what the size
argument means (number of gpios in *gpios _or_ number of bytes in the
bitmap *set) - wouldn't it be clearer to have a "bool *set" and "bool
*values" list?

>>> And how you can hope to describe this via DT
>>
>> Haven't had planned that yet. Finally, this interface should just be
>> another view on the GPIOs already requested / assigned. Or which
>> additional info do you mean?
> how do you plan to give the gpio base vai DT to the driver as via DT we just
> pass the list of GPIO to work on

Right. If I understand correctly, with the above discussed changes, this
"GPIO base" issue is gone...

Thanks for your feedback!

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/