linux-kernel - RE: [PATCH v2] wifi: rtw89: Print just once for unknown C2H classes

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: <d0f6162ab34440cab0c11667be092609@realtek.com>
Date: Fri, 1 Aug 2025 00:30:51 +0000
From: Ping-Ke Shih <pkshih@...ltek.com>
To: Sean Anderson <sean.anderson@...ux.dev>,
        "linux-wireless@...r.kernel.org"
	<linux-wireless@...r.kernel.org>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Bitterblue
 Smith" <rtl8821cerfe2@...il.com>
Subject: RE: [PATCH v2] wifi: rtw89: Print just once for unknown C2H classes

Sean Anderson <sean.anderson@...ux.dev> wrote:
> On 7/29/25 20:36, Ping-Ke Shih wrote:
> > Sean Anderson <sean.anderson@...ux.dev> wrote:
> >> There are more unsupported functions than just LOWRT_RTY. Improve on
> >> commit 3b66519b023b ("wifi: rtw89: phy: add dummy c2h handler to avoid
> >> warning message") by printing a message just once when we first
> >> encounter an unsupported class.
> >
> > Once I encounter an unsupported class/func, I'll check firmware team if the
> > C2H events can be ignored. If so, I add a dummy function to avoid the message.
> > If not, I should add code to handle the event.
> >
> > Do you want to see the message even though it only appears once?
> 
> I mean, maybe it should just be a debug? Are these messages useful for anyone
> other than the developers?

Yes, this could just be a debug. However, developers normally don't turn on
debug mask, so using rtw89_info is to clearly remind developers to pay
attention on this lack of C2H handler. And, I suppose developers must handle
this when they see flooding messages.

> 
> Maybe we should just print only the very first unsupported message at info level
> and print the rest at debug.

I'm afraid developers will ignore or miss the messages. To reduce messages
is fine to me , but more important is to look up vendor driver to see if
the C2H handler is necessary.