Hi Simon, On 2026-09-10 Simon Glass wrote: > I like this approach. BTW clocks and reset lines have the same problem > so we could deal with those late as needed.
Yes, the same two-phase shape fits them; I kept this series to GPIOs to get the pattern agreed first. > The original index is dropped: gpio_request_by_name() passes 'index > > 0' to gpio_request_tail() so the request label gains an index suffix > when index != 0 You are right. The three callers converted in patch 2 all use index 0, so I never stored it, and the test happened to work because it only checks the function, not the label. v2 stores the index in the struct and passes it to gpio_request_tail() with add_index = index > 0, so both entry points produce the same label, and the test asserts the label through gpio_get_function()'s name pointer. > Note that list_name is a pointer with an implicit 'must outlive the > desc' contract Will document. All current callers pass string literals. > Also gpio_dt_desc reads as a peer of gpio_desc when it is really a > pending/parsed version of one. gpio_desc_parsed, or gpio_dt_spec, > would make the two-phase relationship clearer. What do you think? gpio_dt_spec, then: it says what the thing is (a devicetree specification of a GPIO) rather than what it is not, and Zephyr uses the same name for the same idea, a GPIO described by the devicetree and configured later. > Please note in the kernel-doc that the -ENOENT return for a > not-present @dt is deliberate, so a caller with an optional GPIO can > skip the 'if (dt->present)' check and just tolerate -ENOENT Will do, and patch 2 will use that contract instead of guarding on present in two places (see the reply there). > Please add a gpio_get_function() check between the parse and > the request, mirroring what patch 4 does for the regulator. Yes. test2-gpios index 1 is a4, so the test will assert GPIOF_UNUSED on a4 after the parse and GPIOF_OUTPUT with the expected label after the request. Regards, Mehmet
