On Mon, Apr 12, 2021 at 07:16:53PM +0200, Henning Schild wrote: > Am Mon, 12 Apr 2021 19:59:05 +0300 > schrieb Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx>: > > On Mon, Apr 12, 2021 at 06:40:01PM +0200, Henning Schild wrote: > > > Tan or Andy, > > > > > > maybe you can point me to a user of that patch. I guess there might > > > be an out-of-tree driver or userland code on how to use the GPIOs > > > from there. > > > > I'm confused. User of this patch is pinctrl-broxton driver. > > It's in upstream. > > Should this appear in /sys/class/gpio as chip so that pins can be > exported? No. Sysfs interface is deprecated. It should appear as /dev/gpiochip0 or so. > That is what i tried and failed with. > > > Using GPIOs from it is something as done in a few drivers already > > (Assuming we have no resources described in the ACPI). I.e. you need > > to register in board file the GPIO mapping table with help of > > devm_acpi_dev_add_driver_gpios() and use one of gpiod_get() family of > > functions to request it. > > > > In case of LEDs you simple describe GPIO device name in lookup table > > and that's it. The drivers/platform/x86/pcengines-apuv2.c not the > > best but will give you an idea how to use "leds-gpio" driver in board > > files. > > I am aware of that driver and had a look at it. In order to figure out > the arguments for the macros/functions i was hoping for userland gpio > "export", but maybe that does not work here ... > For now i will assume that it does not show up in sysfs and can maybe > still be used, and try to build on top. Just switch to use libgpiod and associated tools / bindings in user space. Sysfs ABI is not being developed anymore. -- With Best Regards, Andy Shevchenko
