On Thu, 2017-03-09 at 15:45 +0100, Hans de Goede wrote:

quoted

Sounds like a plan!

Since extcon patches are landed already mainstream it might make
sense
to send it as usual to all maintainers.

Ack, so to be clear we should use gpiod_get not gpiod_get_index with
the acpi mapping table, right ? The reason I'm asking is that my
test devices only have the id pin which has index 0 so in my
experience with soc_button_array it will work with both
(the button with index 0 would even work with gpiod_get_index).

TL;DR -- right.


So, now simple and clean example:

_CRS:

GpioIo(...)  { pin #5 }
GpioIo(...)  { pin #3, pin #4, pin #2 }
GpioIo(...)  { pin #15 }

If we assume each line represents one function (connection ID):
"func0"
"func1"
"func2"

we would see that index is needed only when we would like to get access
to pin #4 or pin #2 of "func1".

Was:

gpiod_get_index(..., NULL, <index_in_CRS>);

where index is 0,1, or 2 *with second index assumed 0*!

Now, what we actually is doing we mapping connection ID to the first
index and can use index to access mentioned above pins:

gpiod_get_index(..., "<funcX>", <secondary_index_in_CRS>);

For example, for pin #2 or #4
gpiod_get_index(..., "func1", 2); // pin #2
gpiod_get_index(..., "func1", 1); // pin #4

Thus,
gpiod_get_index(..., "func1", 0); // pin #3


Or just for the first (virtual) column:

gpiod_get(..., "<funcX>");

where pin #5, #3 or #15 is accessible.

-- 
Andy Shevchenko [off-list ref]
Intel Finland Oy