From: Brian Norris <briannorris@chromium.org>
To: Julius Werner <jwerner@chromium.org>
Cc: Titouan Ameline <titouan.ameline@gmail.com>,
tzungbi@kernel.org, chrome-platform@lists.linux.dev,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] firmware: google: fix orphaned devices on partial populate failure
Date: Tue, 28 Apr 2026 13:33:27 -0700 [thread overview]
Message-ID: <afEZlycZGgTiD0Ga@google.com> (raw)
In-Reply-To: <CAODwPW8T6o93pQodem-hNrszH_dsa5KMTu0iRY6y8CLJNjfXsA@mail.gmail.com>
On Tue, Apr 28, 2026 at 12:49:35PM -0700, Julius Werner wrote:
> > Given that, would the right approach be to continue the loop on
> > entry-specific errors ( logging a warning), while still aborting and
> > cleaning up on systemic ones like -ENOMEM? Or is the name collision
> > case considered impossible here since names are derived from the
> > tag/index and the table is only parsed once?
>
> I don't think you should hardcode behavior so specific to what the
> called function does. Trying every entry doesn't really hurt even if
> they all fail due to some systemic problem, so if there's any chance
> that other entries might succeed, I think the best option is to just
> always continue the loop and try the next one.
FWIW, of_platform_populate() might be a (highly-used) analog for
comparison. Aside from some top-level errors (such as, "can't even find
the root to start from"), it doesn't actually return errors at all [1].
It just skips individual device failures (including -ENOMEM).
Seems like an OK strategy to me.
Brian
[1] of_platform_bus_create() technically has some recursion-carried
return codes, giving a chance to propagate a failure, but all the return
codes are still 0.
next prev parent reply other threads:[~2026-04-28 20:33 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-26 22:02 [PATCH] firmware: google: fix orphaned devices on partial populate failure Titouan Ameline de Cadeville
2026-04-27 19:03 ` Julius Werner
2026-04-27 21:36 ` Titouan Ameline
2026-04-28 19:49 ` Julius Werner
2026-04-28 20:33 ` Brian Norris [this message]
2026-04-30 8:30 ` Titouan Ameline
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=afEZlycZGgTiD0Ga@google.com \
--to=briannorris@chromium.org \
--cc=chrome-platform@lists.linux.dev \
--cc=jwerner@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=titouan.ameline@gmail.com \
--cc=tzungbi@kernel.org \
/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.