Re: [PATCH] firmware: tegra: bpmp: populate debugfs in the background

[Austin Schuh]

On Fri, Oct 23, 2026 at 1:16 AM Mikko Perttunen <mperttunen@xxxxxxxxxx> wrote:
> Sashiko reports some hard to trigger but worth checking concurrency
> issues.

I couldn't find Sashiko's report, so I went looking myself and found
two, both fixed in v2:

 - The work could run across a system suspend.  Once suspend_noirq sets
   bpmp->suspended, its requests fail with -EAGAIN, and the error path
   removes the whole mirror.  v2 queues it on system_freezable_wq, so
   suspend waits for it.

 - With more than one BPMP, the populations used to run one after the
   other in their probes, and now run at once.  One failing could remove
   the shared root while the other was creating its directory in it.  v2
   holds bpmp_debugfs_root_lock across the whole population.

If you've got a link to Sashiko's report, that would be wonderful.

> This does seem a good idea, but I am a bit concerned about the change to
> what userspace sees. Ideally we'd be able to have userspace stall if the
> debugfs population was still in progress. If that's not possible, at the
> very least userspace should have a way to voluntarily wait for the full
> debugfs to be available.

debugfs has no way to stall a lookup, so v2 fills the mirror in as
.debug-populating and renames it to debug once it is complete.
Userspace either finds no debug directory or a complete one, and can
wait for it by waiting for debug to appear: polling, or inotify on the
parent, since the rename sends IN_MOVED_TO.  On the Orin Nano the rename
lands about 1.3 seconds after the initramfs starts, and before systemd
starts on the root filesystem.

If you'd rather have something explicit as well, I can add a file in
bpmp/ whose read blocks until population is done and returns its result.

> Just inline the work_struct inside tegra_bpmp. In any case the work
> should be synchronously cancelled if the bpmp driver instance is going
> to go away (not that that will happen, but good practice).

Done in v2: the work_struct is in struct tegra_bpmp, and a devm action
calls cancel_work_sync().

Thanks for the review!

Austin