On 16/06/2025 04:42, Ping-Ke Shih wrote:
> Bitterblue Smith <rtl8821cerfe2@xxxxxxxxx> wrote:
>> Disable rtw89_mac_send_rpwm() for USB and SDIO because it is called in
>> atomic context and accessing hardware registers results in "scheduling
>> while atomic" errors.
>>
>> Disable rtw89_mac_power_mode_change() because it prints an error message
>> when rtw89_mac_send_rpwm() is disabled.
>>
>> Modify rtw89_ps_power_mode_change() to call
>> rtw89_ps_power_mode_change_with_hci() only for PCI because the latter
>> is probably relevant only for PCI and also because it calls
>> napi_schedule(), which results in dereferencing a null pointer with USB.
>>
>> For USB and SDIO rtw89_ps_power_mode_change() probably needs to call
>> rtw89_mac_power_mode_change() instead, in case deep power saving is ever
>> enabled for USB or SDIO.
>>
>> Signed-off-by: Bitterblue Smith <rtl8821cerfe2@xxxxxxxxx>
>> ---
>> v2:
>> - Disable deep power saving for SDIO also.
>> - Don't disable rtw89_ps_power_mode_change() for USB/SDIO.
>> - Disable rtw89_mac_power_mode_change() for USB/SDIO.
>> - Call rtw89_ps_power_mode_change_with_hci() only for PCI and call
>> rtw89_mac_power_mode_change() for USB/SDIO.
>> - Update the commit message.
>> ---
>> drivers/net/wireless/realtek/rtw89/mac.c | 6 ++++++
>> drivers/net/wireless/realtek/rtw89/ps.c | 3 ++-
>> 2 files changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/wireless/realtek/rtw89/mac.c b/drivers/net/wireless/realtek/rtw89/mac.c
>> index 7f3c816d4704..2cebde9e9229 100644
>> --- a/drivers/net/wireless/realtek/rtw89/mac.c
>> +++ b/drivers/net/wireless/realtek/rtw89/mac.c
>> @@ -1336,6 +1336,9 @@ static void rtw89_mac_send_rpwm(struct rtw89_dev *rtwdev,
>> {
>> u16 request;
>>
>> + if (rtwdev->hci.type != RTW89_HCI_TYPE_PCIE)
>> + return;
>> +
>
> I think we can just return RTW89_PS_MODE_NONE in rtw89_update_ps_mode()
> for hci.type != RTW89_HCI_TYPE_PCIE.
>
Yes, that works.
> If not, I would like to define a 'rtwdev->hci.can_deep_ps' for the purpose
> to disable deep PS temporarily. Sometime we can support it by just removing
> this flag simply. But not very prefer this way though.
>
