[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aa24adf30a1e4944acefa4effff46dfd@realtek.com>
Date: Wed, 4 Jun 2025 01:28:49 +0000
From: Ping-Ke Shih <pkshih@...ltek.com>
To: Fedor Pchelkin <pchelkin@...ras.ru>
CC: Zong-Zhe Yang <kevin_yang@...ltek.com>,
"linux-wireless@...r.kernel.org"
<linux-wireless@...r.kernel.org>,
"linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>,
"lvc-project@...uxtesting.org"
<lvc-project@...uxtesting.org>
Subject: RE: [PATCH rtw-next] wifi: rtw89: sar: drop assertion from rtw89_sar_set_src()
Fedor Pchelkin <pchelkin@...ras.ru> wrote:
> Urgh, this one wasn't caught as my system doesn't have any SAR available
> from ACPI. But it would be falsely triggered, too. If I saw it earlier,
> I'd better prepared this as a followup patch in a series though..
>
Good catch.
There are two consumers. One is rtw89_apply_sar_acpi() which should not
assert wiphy_lock, but the other rtw89_apply_sar_common() can be. As I know,
the assertion is added for the latter one initially.
Another way is to assert the lock under condition of
test_bit(RTW89_FLAG_PROBE_DONE, rtwdev->flags)
> drivers/net/wireless/realtek/rtw89/sar.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/net/wireless/realtek/rtw89/sar.c b/drivers/net/wireless/realtek/rtw89/sar.c
> index 33a4b5c23fe7..3f57881b74e6 100644
> --- a/drivers/net/wireless/realtek/rtw89/sar.c
> +++ b/drivers/net/wireless/realtek/rtw89/sar.c
> @@ -199,7 +199,6 @@ struct rtw89_sar_handler rtw89_sar_handlers[RTW89_SAR_SOURCE_NR] = {
> typeof(_dev) _d = (_dev); \
> BUILD_BUG_ON(!rtw89_sar_handlers[_s].descr_sar_source); \
> BUILD_BUG_ON(!rtw89_sar_handlers[_s].query_sar_config); \
> - lockdep_assert_wiphy(_d->hw->wiphy); \
> _d->sar._cfg_name = *(_cfg_data); \
> _d->sar.src = _s; \
> } while (0)
> --
> 2.49.0
>
Powered by blists - more mailing lists