On Mon, Jun 15, 2015 at 4:29 AM, Alexandre Courbot <gnurou@xxxxxxxxx> wrote: > On Mon, Jun 15, 2015 at 7:00 AM, Tobias Diedrich > <ranma+kernel@xxxxxxxxxxxx> 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@xxxxxxxxxx> I don't have the actual v2 patch in my inbox :( Tobias, can you resend a v3 with the ACKs. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html