On Fri, 26 Sept 2025 at 17:32, Jon Hunter [off-list ref] wrote:

On 25/09/2025 23:31, Saravana Kannan wrote:

...

quoted

quoted

I have been doing more testing and do see a lot of "tegra-bpmp bpmp:
sync_state() pending due to" on our platforms for basically are driver
that is built as a module.

It being "built as a module" is not reason enough for this warning to
happen though. One of the main points of fw_devlink is for things to
work just as well with modules.

In this particular system, do you never plan to load the modules? Or
is the module load just missing this timeout by a few seconds or
something?

We absolutely do load the drivers. Initially, I observed cases where
drivers are missing, but doing more testing with the necessary drivers
present, I still see such messages. A lot of our test infrastructure is
set up to use NFS for mounting to the rootfs and so I am wondering if
that can also be a factor?

quoted

If these can be turned off, why not turn these off using the sysfs
file or the timeout commandline option to turn them off? You are
burning power by leaving these on. A warning seems appropriate to me.

Again the drivers get loaded, so that shouldn't be the case.

I realized that we also have an orthogonal, but related problem.

In fact, the genpd in question actually may already have been
powered-off, completely defeating the purpose of the printed warning
that we are discussing.

In genpd we enable the ->sync_state() support, no matter whether the
genpd is powered-on or powered-off at initialization. Although, it's
only when a genpd is powered-on at init, when we prevent it from being
powered-off until the ->sync_state() callback gets invoked. Ideally,
we should be able to skip enabling the ->sync_state() support for
genpd in these cases, possibly silencing some of these prints. I will
have a look at this and get back to you.

Kind regards
Uffe