Fedor Pchelkin <pchelkin@xxxxxxxxx> 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
>
