On Fri, 7 Dec 2012 11:06:34 +0900, Alex Courbot wrote:
> On Thursday 06 December 2012 22:42:59 Grant Likely wrote:
> > how about "gpio_chip_hwnum()" to somewhat match irqdomain convention?
>
> Sure, matching existing interfaces is better. "git grep hwnum" does not seem
> to reveal much related t
On Fri, Dec 07, 2012 at 04:02:02PM +0900, Alex Courbot wrote:
> Hi Guenter,
>
> On Friday 07 December 2012 10:49:47 Guenter Roeck wrote:
> > My own idea for a solution was to keep integer based handles, but replace
> > gpio_desc[] with a hash table. But ultimately I don't really care how
> > it is
On Fri, Dec 7, 2012 at 3:06 AM, Alex Courbot wrote:
> On Thursday 06 December 2012 22:42:59 Grant Likely wrote:
>> how about "gpio_chip_hwnum()" to somewhat match irqdomain convention?
>
> Sure, matching existing interfaces is better. "git grep hwnum" does not seem
> to reveal much related to irqd
Hi Guenter,
On Friday 07 December 2012 10:49:47 Guenter Roeck wrote:
> My own idea for a solution was to keep integer based handles, but replace
> gpio_desc[] with a hash table. But ultimately I don't really care how
> it is done.
>
> Do you have a solution for gpiochip_find_base() in mind, and h
On Thu, Dec 06, 2012 at 04:45:18PM +0900, Alexandre Courbot wrote:
> With the current API, GPIOs are manipulated through an integer which
> represents their unique number across the system. This poses problems in
> terms of portability, scalability and flexibility: for instance, the
> number of val
On Thursday 06 December 2012 22:42:59 Grant Likely wrote:
> how about "gpio_chip_hwnum()" to somewhat match irqdomain convention?
Sure, matching existing interfaces is better. "git grep hwnum" does not seem
to reveal much related to irqdomain though?
> I've only lightly scanned this patch, but I
On Thu, Dec 6, 2012 at 8:45 AM, Alexandre Courbot wrote:
> With the current API, GPIOs are manipulated through an integer which
> represents their unique number across the system. This poses problems in
> terms of portability, scalability and flexibility: for instance, the
> number of valid GPIOs
On Thu, 6 Dec 2012 16:45:18 +0900, Alexandre Courbot
wrote:
> With the current API, GPIOs are manipulated through an integer which
> represents their unique number across the system. This poses problems in
> terms of portability, scalability and flexibility: for instance, the
> number of valid GP
With the current API, GPIOs are manipulated through an integer which
represents their unique number across the system. This poses problems in
terms of portability, scalability and flexibility: for instance, the
number of valid GPIOs for a given system is fixed at system time, and a
large array of t
Just a RFC to check if the direction seems good before going onward with more
serious work. This patch introduces a set of gpiod_* functions that work like
their gpio_* counterparts, but use opaque descriptors instead of integers.
The current integer-based GPIO namespace is bad because it allows G
10 matches
Mail list logo
