linux-kernel - Re: [PATCH] driver core: fw_devlink: Don't warn in fw_devlink_dev_sync

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAPDyKFrKP2bdpKTHzqDdhEpRAjYu+PFd2Bst=-WPddByxcAX_w@mail.gmail.com>
Date: Thu, 25 Sep 2025 16:26:35 +0200
From: Ulf Hansson <ulf.hansson@...aro.org>
To: Diederik de Haas <didi.debian@...ow.org>
Cc: Saravana Kannan <saravanak@...gle.com>, "Rafael J . Wysocki" <rafael@...nel.org>, 
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>, linux-pm@...r.kernel.org, 
	Geert Uytterhoeven <geert@...ux-m68k.org>, 
	Nicolas Frattaroli <nicolas.frattaroli@...labora.com>, Heiko Stuebner <heiko@...ech.de>, 
	Sebastian Reichel <sebastian.reichel@...labora.com>, Sebin Francis <sebin.francis@...com>, 
	Tomi Valkeinen <tomi.valkeinen@...asonboard.com>, Jon Hunter <jonathanh@...dia.com>, 
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] driver core: fw_devlink: Don't warn in fw_devlink_dev_sync_state()

On Thu, 25 Sept 2025 at 15:59, Diederik de Haas <didi.debian@...ow.org> wrote:
>
> Hi,
>
> On Thu Sep 25, 2025 at 1:59 PM CEST, Ulf Hansson wrote:
> > Due to the wider deployment of the ->sync_state() support, for PM domains
> > for example, we are receiving reports about the messages that are being
> > logged in fw_devlink_dev_sync_state(). In particular as they are at the
> > warning level, which doesn't seem correct.
> >
> > Even if it certainly is useful to know that the ->sync_state() condition
> > could not be met, there may be nothing wrong with it. For example, a driver
> > may be built as module and are still waiting to be initialized/probed.
>
> "there may be nothing wrong with it" doesn't sound very convincing.
> So there *can* be something wrong with it, so warning sounds
> appropriate? If there is (certainly) something wrong with it, I expect
> an error.

Sorry if I was too vague. See more below.

> FWIW: most of my drivers/modules are built as modules.
> I do seem to run into 'problems' more then average because of that, but
> to me it just signals there is something wrong ... which should be
> fixed. Not silenced.

Well, why is it wrong to have drivers being built as modules? They
just happen to be probed at some point later, then why should we have
warnings printed in the log due to this?

>
> You're the expert, but I'm not so sure this is an improvement.
> I do regularly check dmesg level 0, 1, 2, 3 and 4, hence it landed on my
> radar. I do not regularly check all the dmesg msgs, so this change would
> result it dropping off my (immediate) radar.

I personally don't have a strong opinion about the log level here, but
the reports I have received so far, clearly indicated to me that we
should not be using the warn level for these messages.

In the end, it seems like these prints are not as straight-forward
when it comes to deciding what level to log things on.

Let's see what other people think about it.

[...]

Kind regards
Uffe