All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mehmet Fide <mehmet.fide@gmail.com>
To: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>,
	Jaehoon Chung <jh80.chung@samsung.com>,
	Peng Fan <peng.fan@nxp.com>, Vincent Jardin <vjardin@free.fr>,
	Ye Li <ye.li@nxp.com>, Michal Simek <michal.simek@amd.com>,
	Aristo Chen <aristo.chen@canonical.com>,
	u-boot@lists.u-boot-project.org,
	Mehmet Fide <mehmet.fide@screeningeagle.com>
Subject: Re: [PATCH 1/4] gpio: add a way to parse a GPIO now and request it later
Date: Thu, 10 Sep 2026 16:58:28 +0200	[thread overview]
Message-ID: <20260910145828.1275979-1-mehmet.fide@gmail.com> (raw)
In-Reply-To: <CAFLszTjApvPONDB9bdyuTA8dqbWvgmnavsQD=Xy2nit4FzjNHw@mail.gmail.com>

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

  reply	other threads:[~2026-09-10 14:58 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-28 10:52 [PATCH 0/4] dm: gpio: read GPIOs in of_to_plat(), request them in probe() Mehmet Fide
2026-08-28 10:52 ` [PATCH 1/4] gpio: add a way to parse a GPIO now and request it later Mehmet Fide
2026-09-10 14:06   ` Simon Glass
2026-09-10 14:58     ` Mehmet Fide [this message]
2026-08-28 10:52 ` [PATCH 2/4] regulator: claim the enable GPIO at probe time, not in of_to_plat() Mehmet Fide
2026-09-10 14:08   ` Simon Glass
2026-09-10 14:58     ` Mehmet Fide
2026-08-28 10:52 ` [PATCH 3/4] doc: driver-model: state that of_to_plat() must not probe or claim Mehmet Fide
2026-09-10 14:09   ` Simon Glass
2026-09-10 14:58     ` Mehmet Fide
2026-08-28 10:52 ` [PATCH 4/4] test: dm: check the fixed regulator claims its GPIO at probe time Mehmet Fide
2026-09-10 14:09   ` Simon Glass
2026-09-10 14:58     ` Mehmet Fide
2026-09-10 14:10 ` [0/4] dm: gpio: read GPIOs in of_to_plat(), request them in probe() Simon Glass
2026-09-10 14:58   ` [PATCH 0/4] " Mehmet Fide
2026-09-10 15:08     ` Simon Glass

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260910145828.1275979-1-mehmet.fide@gmail.com \
    --to=mehmet.fide@gmail.com \
    --cc=aristo.chen@canonical.com \
    --cc=jh80.chung@samsung.com \
    --cc=mehmet.fide@screeningeagle.com \
    --cc=michal.simek@amd.com \
    --cc=peng.fan@nxp.com \
    --cc=sjg@chromium.org \
    --cc=trini@konsulko.com \
    --cc=u-boot@lists.u-boot-project.org \
    --cc=vjardin@free.fr \
    --cc=ye.li@nxp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.