Messages in this thread | | | From | Alexandre Courbot <> | Date | Mon, 15 Jun 2015 11:29:04 +0900 | Subject | Re: [PATCH v2] gpio / ACPI: Add label to the gpio request |
| |
On Mon, Jun 15, 2015 at 7:00 AM, Tobias Diedrich <ranma+kernel@tdiedrich.de> wrote: > In leds-gpio.c create_gpio_led only the legacy path propagates the label > by passing it into devm_gpio_request_one. Similarily gpio_keys_polled.c > also neglects to propagate the name to the gpio subsystem. > > On the newer devicetree/acpi path the label is lost as far as the GPIO > subsystem goes (it is only retained as name in struct gpio_led. > > Amend devm_get_gpiod_from_child to take an additonal (optional) label > argument and propagate it so it will show up in /sys/kernel/debug/gpio. > > So instead of: > > GPIOs 288-511, platform/PRP0001:00, AMD SBX00: > gpio-475 (? ) in hi > gpio-477 (? ) out hi > gpio-478 (? ) out lo > gpio-479 (? ) out hi > > we get the much nicer output: > > GPIOs 288-511, platform/PRP0001:00, AMD SBX00: > gpio-475 (switch1 ) in hi > gpio-477 (led1 ) out hi > gpio-478 (led2 ) out lo > gpio-479 (led3 ) out hi
We want to reuse higher-level information (like the con_id) as much as possible to generate labels, but in the case of devm_get_gpiod_from_child() there is no such information available anyway, so why not.
Acked-by: Alexandre Courbot <acourbot@nvidia.com>
Generally speaking this label thing is almost useless, we should now be able to trace which device requested a GPIO and for what purpose and provide that complete information in debugfs.
| |