Re: question about firmware caching and relying on it (CONFIG_FW_CACHE)

[Luis Chamberlain]

On Mon, Feb 03, 2025 at 09:19:59AM +0100, Greg Kroah-Hartman wrote:
> On Sun, Feb 02, 2025 at 12:54:07PM -0800, Linus Torvalds wrote:
> > Greg, Luis, can you explain that odd uevent message / netlink issue?
> 
> There was reports from Android devices that the uevent was causing the
> system to wake up from the netlink messages that were sent when going to
> sleep and so it would get caught in a loop and never actually go to
> sleep.  I can't remember any more than that, maybe Mark can recall the
> specifics and dig up the Android bug reports for it?

Nope, the only thing that my spidy senses tells me is that it would be
great to know if the uevent flood was caused by the uevent flood which
caused the same udev duplicate messages to load modules per-cpu. Linus
had a nice fix to make these idempotent via commit 9b9879fc03275ffe
("modules: catch concurrent module loads, treat them as idempotent")
on the module load path, so I'm wondering if uvents could likely could
trigger floods to delays suspend.

Provided Mark Salyzyn hasn't moved on (from commit 030cc787c30e
("firmware_class: make firmware caching configurable") it would
be great if he could enable the FW_CACHE and re-test. At the very least
hopefully kernel-team-android can redirect this to the appropriate folks
to verify.

One of the reasons to *not* want the fw cache is for firmware images
which are *huge*, like those which may be used on remote procs. But we
we already have an internal FW_OPT_NOCACHE and remote-proc stuff likely
already uses request_firmware_into_buf() which uses FW_OPT_NOCACHE.

  Luis