GPIO library doesn't work on devices which don't create "gpioXX" folders

[amrbekhit]

On some microprocessor kernels (such as the Atmel ATSAMA5D4 series), rather than creating a folder names gpioXX to correspond to pin number XX, the name of the folder is the actual "natural" pin name. For example, on the ATSAMA5D4, there are 5 32-bit GPIO banks, A-E. Pin A15 has a pin number 15 (0 * 32 + 15), but the corresponding folder is pioA15. Pin D8 is pin number 104 (3 * 32 + 8) but the corresponding folder is pioD8. Because the c-periphery library is specifically looking for a folder named gpioXX, gpio_open fails and the library basically can't be used on these devices.

[johlim]

I think you must change
"
/* Check if GPIO directory exists */
snprintf(gpio_path, sizeof(gpio_path), "/sys/class/gpio/gpio%d", pin);
"

[vsergeev]

I'm not sure anything general can be done here. The sysfs documentation of the API (https://elixir.bootlin.com/linux/latest/source/Documentation/gpio/sysfs.txt) shows export should take a number N, and the corresponding exported GPIO directory should be named gpioN. Atmel's implementation of the GPIO driver isn't compliant with that API.

If export expects numbers, and the GPIO directories are pin names, then c-periphery would have to keep a table mapping numbers to pin names for every platform like this. That would be quite burdensome, not to mention the challenge of detecting the platform reliably.

If export allows string pin names (like D8), which matches the exported GPIO directory name, then this could technically be implemented in c-periphery with an alternate open function that accepts a string pin name.

But c-periphery should migrate to the new GPIO character device API anyway, which should normalize differences like this across platforms, so I think it may be best to put efforts towards that.