diff mbox

[v2,4/4] ath10k: Enable sta idle power save

Message ID 1523966821-21903-5-git-send-email-pillair@codeaurora.org (mailing list archive)
State New, archived
Headers show

Commit Message

Rakesh Pillai April 17, 2018, 12:07 p.m. UTC
From: Govind Singh <govinds@codeaurora.org>

Enable sta power save in fw for the targets that
supports idle power save. The idle ps enable command
will be ignored by the firmware which does not support
this feature.

Signed-off-by: Govind Singh <govinds@codeaurora.org>
Signed-off-by: Rakesh Pillai <pillair@codeaurora.org>
---
 drivers/net/wireless/ath/ath10k/mac.c | 7 +++++++
 1 file changed, 7 insertions(+)

Comments

Sebastian Gottschall April 18, 2018, 7:06 a.m. UTC | #1
from my point of view powersave should be optional and not forced.

consider :
iw dev <devname> set power_save on/off

so there is already a config option made for that purpose,

Sebastian

Am 17.04.2018 um 14:07 schrieb pillair@codeaurora.org:
> From: Govind Singh <govinds@codeaurora.org>
>
> Enable sta power save in fw for the targets that
> supports idle power save. The idle ps enable command
> will be ignored by the firmware which does not support
> this feature.
>
> Signed-off-by: Govind Singh <govinds@codeaurora.org>
> Signed-off-by: Rakesh Pillai <pillair@codeaurora.org>
> ---
>   drivers/net/wireless/ath/ath10k/mac.c | 7 +++++++
>   1 file changed, 7 insertions(+)
>
> diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
> index 7e02ca02b28e..1d9222af1bb2 100644
> --- a/drivers/net/wireless/ath/ath10k/mac.c
> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> @@ -4679,6 +4679,13 @@ static int ath10k_start(struct ieee80211_hw *hw)
>   		}
>   	}
>   
> +	param = ar->wmi.pdev_param->idle_ps_config;
> +	ret = ath10k_wmi_pdev_set_param(ar, param, 1);
> +	if (ret && ret != -EOPNOTSUPP) {
> +		ath10k_warn(ar, "failed to enable idle_ps_config: %d\n", ret);
> +		goto err_core_stop;
> +	}
> +
>   	__ath10k_set_antenna(ar, ar->cfg_tx_chainmask, ar->cfg_rx_chainmask);
>   
>   	/*
Govind Singh April 18, 2018, 1:07 p.m. UTC | #2
On 2018-04-18 12:36, Sebastian Gottschall wrote:
> from my point of view powersave should be optional and not forced.
> 
> consider :
> iw dev <devname> set power_save on/off
> 
> so there is already a config option made for that purpose,
> 
> Sebastian
> 
> Am 17.04.2018 um 14:07 schrieb pillair@codeaurora.org:
>> From: Govind Singh <govinds@codeaurora.org>
>> 
>> Enable sta power save in fw for the targets that
>> supports idle power save. The idle ps enable command
>> will be ignored by the firmware which does not support
>> this feature.
>> 
>> Signed-off-by: Govind Singh <govinds@codeaurora.org>
>> Signed-off-by: Rakesh Pillai <pillair@codeaurora.org>
>> ---
>>   drivers/net/wireless/ath/ath10k/mac.c | 7 +++++++
>>   1 file changed, 7 insertions(+)
>> 
>> diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
>> b/drivers/net/wireless/ath/ath10k/mac.c
>> index 7e02ca02b28e..1d9222af1bb2 100644
>> --- a/drivers/net/wireless/ath/ath10k/mac.c
>> +++ b/drivers/net/wireless/ath/ath10k/mac.c
>> @@ -4679,6 +4679,13 @@ static int ath10k_start(struct ieee80211_hw 
>> *hw)
>>   		}
>>   	}
>>   +	param = ar->wmi.pdev_param->idle_ps_config;
>> +	ret = ath10k_wmi_pdev_set_param(ar, param, 1);
>> +	if (ret && ret != -EOPNOTSUPP) {
>> +		ath10k_warn(ar, "failed to enable idle_ps_config: %d\n", ret);
>> +		goto err_core_stop;
>> +	}
>> +
>>   	__ath10k_set_antenna(ar, ar->cfg_tx_chainmask, 
>> ar->cfg_rx_chainmask);
>>     	/*

Thanks Sebastian for your review. Agree this should not be forced with 
in driver.

I will check if i can set the idle ps at the end of 
ath10k_mac_vif_setup_ps by checking arvif->ps.
I will update the patch accordingly.


BR,
Govind
Kalle Valo April 18, 2018, 1:16 p.m. UTC | #3
(fixing top posting)

govinds@codeaurora.org writes:

> On 2018-04-18 12:36, Sebastian Gottschall wrote:
>> from my point of view powersave should be optional and not forced.
>>
>> consider :
>> iw dev <devname> set power_save on/off
>>
>> so there is already a config option made for that purpose,
>
> Thanks Sebastian for your review. Agree this should not be forced with
> in driver.
>
> I will check if i can set the idle ps at the end of
> ath10k_mac_vif_setup_ps by checking arvif->ps.
> I will update the patch accordingly.

So what power save is this exactly? I assumed it's some bus level power
save (turning of clocks etc) but is it actually 802.11 power save?
Arend van Spriel April 18, 2018, 2:44 p.m. UTC | #4
On 4/18/2018 3:16 PM, Kalle Valo wrote:
> (fixing top posting)
>
> govinds@codeaurora.org writes:
>
>> On 2018-04-18 12:36, Sebastian Gottschall wrote:
>>> from my point of view powersave should be optional and not forced.
>>>
>>> consider :
>>> iw dev <devname> set power_save on/off
>>>
>>> so there is already a config option made for that purpose,
>>
>> Thanks Sebastian for your review. Agree this should not be forced with
>> in driver.
>>
>> I will check if i can set the idle ps at the end of
>> ath10k_mac_vif_setup_ps by checking arvif->ps.
>> I will update the patch accordingly.
>
> So what power save is this exactly? I assumed it's some bus level power
> save (turning of clocks etc) but is it actually 802.11 power save?

I also suspected bus level power save and I would say runtime-pm 
framework should be considered for that.

Regards,
Arend
Govind Singh April 19, 2018, 4:32 a.m. UTC | #5
On 2018-04-18 18:46, Kalle Valo wrote:
> (fixing top posting)
> 
> govinds@codeaurora.org writes:
> 
>> On 2018-04-18 12:36, Sebastian Gottschall wrote:
>>> from my point of view powersave should be optional and not forced.
>>> 
>>> consider :
>>> iw dev <devname> set power_save on/off
>>> 
>>> so there is already a config option made for that purpose,
>> 
>> Thanks Sebastian for your review. Agree this should not be forced with
>> in driver.
>> 
>> I will check if i can set the idle ps at the end of
>> ath10k_mac_vif_setup_ps by checking arvif->ps.
>> I will update the patch accordingly.
> 
> So what power save is this exactly? I assumed it's some bus level power
> save (turning of clocks etc) but is it actually 802.11 power save?

Yes this is WIFI chip set level power-save(based on idleness) and not 
related to protocol power save.
FW will turn off/scale down the resources(clock/rails) based on 
opportunity(when ever idle mode is detected).
This power save is mostly done in disconnected state. I am not really 
sure when framework/user-space
triggers power-save config(iw dev <devname> set power_save on/off).
Then doing this from user-space will be unnecessarily toggling this 
config or may not be setting at disconnected state.

May be you can suggest better here.

BR,
Govind
Kalle Valo April 19, 2018, 4:36 p.m. UTC | #6
govinds@codeaurora.org writes:

> On 2018-04-18 18:46, Kalle Valo wrote:
>> (fixing top posting)
>>
>> govinds@codeaurora.org writes:
>>
>>> On 2018-04-18 12:36, Sebastian Gottschall wrote:
>>>> from my point of view powersave should be optional and not forced.
>>>>
>>>> consider :
>>>> iw dev <devname> set power_save on/off
>>>>
>>>> so there is already a config option made for that purpose,
>>>
>>> Thanks Sebastian for your review. Agree this should not be forced with
>>> in driver.
>>>
>>> I will check if i can set the idle ps at the end of
>>> ath10k_mac_vif_setup_ps by checking arvif->ps.
>>> I will update the patch accordingly.
>>
>> So what power save is this exactly? I assumed it's some bus level power
>> save (turning of clocks etc) but is it actually 802.11 power save?
>
> Yes this is WIFI chip set level power-save(based on idleness) and not
> related to protocol power save. FW will turn off/scale down the
> resources(clock/rails) based on opportunity(when ever idle mode is
> detected). This power save is mostly done in disconnected state. I am
> not really sure when framework/user-space triggers power-save
> config(iw dev <devname> set power_save on/off). Then doing this from
> user-space will be unnecessarily toggling this config or may not be
> setting at disconnected state.

I think that 'set power_save' commands affects struct
ieee80211_bss_conf::ps parameter and I don't think it should be used in
this case. We already have ath10k_config_ps() for 802.11 level of power
saving.

Arend again proposed runtime-pm with which I'm not very familiar. But
why would we want to disable this? Doesn't it make sense to have this
feature always enabled to save power? wcn3990 is a chip for a mobile
device anyway.
Adrian Chadd April 19, 2018, 5 p.m. UTC | #7
Hi,

My 2c here.

As much as I like power save stuff, I've been bitten enough times by
these wifi chips kinda implementing
mostly-ok-but-not-that-particular-time power savings stuff and so have
had to make it configurable chip by chip.

A good example is active state power management in various runtime and
idle modes on different chips, how it intersects with things like
bluetooth, btcoex, is the bios buggy, etc, etc.

So I'd at least like a way to control that feature as a module load
and/or debugfs entry to aide users trying to figure out why chips
disappear or behave erratically. I'm ok with it being turned on but
I'm not ok with a debugging step being "oh yeah, so just go comment
this out and recompile", especially if people are debugging on an
embedded target where it's not easily self hosted or easy to rebuild
things.




-adrian
Sebastian Gottschall April 20, 2018, 7:21 a.m. UTC | #8
>> Yes this is WIFI chip set level power-save(based on idleness) and not
>> related to protocol power save. FW will turn off/scale down the
>> resources(clock/rails) based on opportunity(when ever idle mode is
>> detected). This power save is mostly done in disconnected state. I am
>> not really sure when framework/user-space triggers power-save
>> config(iw dev <devname> set power_save on/off). Then doing this from
>> user-space will be unnecessarily toggling this config or may not be
>> setting at disconnected state.
> I think that 'set power_save' commands affects struct
> ieee80211_bss_conf::ps parameter and I don't think it should be used in
> this case. We already have ath10k_config_ps() for 802.11 level of power
> saving.
>
> Arend again proposed runtime-pm with which I'm not very familiar. But
> why would we want to disable this? Doesn't it make sense to have this
> feature always enabled to save power? wcn3990 is a chip for a mobile
> device anyway.
it might be made for mobile devices but who knows how it is used by the 
market.

Sebastian
>
Arend van Spriel April 20, 2018, 8:16 a.m. UTC | #9
On 4/20/2018 9:21 AM, Sebastian Gottschall wrote:
>
>>> Yes this is WIFI chip set level power-save(based on idleness) and not
>>> related to protocol power save. FW will turn off/scale down the
>>> resources(clock/rails) based on opportunity(when ever idle mode is
>>> detected). This power save is mostly done in disconnected state. I am
>>> not really sure when framework/user-space triggers power-save
>>> config(iw dev <devname> set power_save on/off). Then doing this from
>>> user-space will be unnecessarily toggling this config or may not be
>>> setting at disconnected state.
>> I think that 'set power_save' commands affects struct
>> ieee80211_bss_conf::ps parameter and I don't think it should be used in
>> this case. We already have ath10k_config_ps() for 802.11 level of power
>> saving.
>>
>> Arend again proposed runtime-pm with which I'm not very familiar. But
>> why would we want to disable this? Doesn't it make sense to have this
>> feature always enabled to save power? wcn3990 is a chip for a mobile
>> device anyway.
> it might be made for mobile devices but who knows how it is used by the
> market.

Reading the explanation above it does not make sense to use runtime-pm. 
That would only come into play if the host driver would actually control 
the resources being turned off/scaled down.

So this is purely reducing power-consumption of the chip. However, it 
would be good to know the consequences in terms of responsiveness to 
firmware commands for instance when requesting a scan operation. Another 
thing to consider is to provide user-space with possibility to change 
this configuration (maybe through debugfs?).

Regards,
Arend
Govind Singh April 20, 2018, 12:43 p.m. UTC | #10
On 2018-04-20 13:46, Arend van Spriel wrote:
> On 4/20/2018 9:21 AM, Sebastian Gottschall wrote:
>> 
>>>> Yes this is WIFI chip set level power-save(based on idleness) and 
>>>> not
>>>> related to protocol power save. FW will turn off/scale down the
>>>> resources(clock/rails) based on opportunity(when ever idle mode is
>>>> detected). This power save is mostly done in disconnected state. I 
>>>> am
>>>> not really sure when framework/user-space triggers power-save
>>>> config(iw dev <devname> set power_save on/off). Then doing this from
>>>> user-space will be unnecessarily toggling this config or may not be
>>>> setting at disconnected state.
>>> I think that 'set power_save' commands affects struct
>>> ieee80211_bss_conf::ps parameter and I don't think it should be used 
>>> in
>>> this case. We already have ath10k_config_ps() for 802.11 level of 
>>> power
>>> saving.
>>> 
>>> Arend again proposed runtime-pm with which I'm not very familiar. But
>>> why would we want to disable this? Doesn't it make sense to have this
>>> feature always enabled to save power? wcn3990 is a chip for a mobile
>>> device anyway.
>> it might be made for mobile devices but who knows how it is used by 
>> the
>> market.

I guess having this enabled by default is safe as 
WMI_PDEV_PARAM_UNSUPPORTED
protects for those version which does not support this pdev param.


> Reading the explanation above it does not make sense to use
> runtime-pm. That would only come into play if the host driver would
> actually control the resources being turned off/scaled down.
> 
> So this is purely reducing power-consumption of the chip. However, it
> would be good to know the consequences in terms of responsiveness to
> firmware commands for instance when requesting a scan operation.

Exit latency is around 8-10 ms, so i guess this delta should be ok.

> Another thing to consider is to provide user-space with possibility to
> change this configuration (maybe through debugfs?).


In case any one wants to measure power no's with/without this config, 
just giving
provision to disable may be useful.


BR,
Govind
Kalle Valo April 23, 2018, 3:50 p.m. UTC | #11
Arend van Spriel <arend.vanspriel@broadcom.com> writes:

> On 4/20/2018 9:21 AM, Sebastian Gottschall wrote:
>>
>>>> Yes this is WIFI chip set level power-save(based on idleness) and not
>>>> related to protocol power save. FW will turn off/scale down the
>>>> resources(clock/rails) based on opportunity(when ever idle mode is
>>>> detected). This power save is mostly done in disconnected state. I am
>>>> not really sure when framework/user-space triggers power-save
>>>> config(iw dev <devname> set power_save on/off). Then doing this from
>>>> user-space will be unnecessarily toggling this config or may not be
>>>> setting at disconnected state.
>>> I think that 'set power_save' commands affects struct
>>> ieee80211_bss_conf::ps parameter and I don't think it should be used in
>>> this case. We already have ath10k_config_ps() for 802.11 level of power
>>> saving.
>>>
>>> Arend again proposed runtime-pm with which I'm not very familiar. But
>>> why would we want to disable this? Doesn't it make sense to have this
>>> feature always enabled to save power? wcn3990 is a chip for a mobile
>>> device anyway.
>>
>> it might be made for mobile devices but who knows how it is used by the
>> market.

Sure, and this does parameter prevent that. You can still connect
wcn3990 to any power source you want, but the driver is just optimised
power consumption in focus.

> Reading the explanation above it does not make sense to use
> runtime-pm. That would only come into play if the host driver would
> actually control the resources being turned off/scaled down.

Exactly.

> So this is purely reducing power-consumption of the chip. However, it
> would be good to know the consequences in terms of responsiveness to
> firmware commands for instance when requesting a scan operation.
> Another thing to consider is to provide user-space with possibility to
> change this configuration (maybe through debugfs?).

Adrian was also commenting something similar about adding a debugfs
interface but I don't really see the point right now while we are adding
initial wcn3990 support. If someone wants to run measurements with and
without this parameter it's very easy to edit it out from the sources.
Later on we can consider making it dynamic if there's really the need
for that, but I'm very skeptic that anyone would even need that.
Sebastian Gottschall April 23, 2018, 4:17 p.m. UTC | #12
just for your notice. 10.4.3.5.3-0057 on 9984 which was just released 
crashes in vht160 operation mode immediatly after first station associates
last known working stable fw so far is 10.4-3.4-00104. the whole 
10.4.3.5.3 series seem to be seriously broken or the api has been 
changed in a way
which is unsupported by ath10k (which i think is the cause of the problem)
it would be good to know what has been changed.

[   54.170242] ath10k_pci 0001:03:00.0: firmware crashed! (uuid n/a)
[   54.176337] ath10k_pci 0001:03:00.0: qca9984/qca9994 hw1.0 target 
0x01000000 chip_id 0x00000000 sub 168c:cafe
[   54.186237] ath10k_pci 0001:03:00.0: kconfig debug 1 debugfs 1 
tracing 0 dfs 0 testmode 0
[   54.195264] ath10k_pci 0001:03:00.0: firmware ver 10.4-3.5.3-00057 
api 5 features 
no-p2p,mfp,peer-flow-ctrl,btcoex-param,allows-mesh-bcast,no-ps crc32 
f10fd4d3
[   54.209521] ath10k_pci 0001:03:00.0: board_file api 1 bmi_id N/A 
crc32 31ab2fd1
[   54.216823] ath10k_pci 0001:03:00.0: htt-ver 2.2 wmi-op 6 htt-op 4 
cal otp max-sta 512 raw 0 hwcrypto 1
[   54.228223] ath10k_pci 0001:03:00.0: firmware register dump:
[   54.233879] ath10k_pci 0001:03:00.0: [00]: 0x0000000A 0x000015B3 
0x0A0014F9 0x00975B31
[   54.241778] ath10k_pci 0001:03:00.0: [04]: 0x0A0014F9 0x00060B30 
0x0000001D 0x004461F0
[   54.249685] ath10k_pci 0001:03:00.0: [08]: 0x0042E980 0x0045E028 
0x000EE6CC 0x00000001
[   54.257591] ath10k_pci 0001:03:00.0: [12]: 0x00000009 0x00000000 
0x00973ABC 0x00973AD2
[   54.265498] ath10k_pci 0001:03:00.0: [16]: 0x00973AB0 0x009C378C 
0x009606CA 0x00000000
[   54.273406] ath10k_pci 0001:03:00.0: [20]: 0x409C9609 0x0040673C 
0x00400000 0x0000000E
[   54.281304] ath10k_pci 0001:03:00.0: [24]: 0x809805BF 0x0040679C 
0x00000095 0xC09C9609
[   54.289210] ath10k_pci 0001:03:00.0: [28]: 0x809CBCC5 0x004068BC 
0x00000000 0x00009026
[   54.297115] ath10k_pci 0001:03:00.0: [32]: 0x809B7303 0x004068EC 
0x000EE6CC 0x0042B988
[   54.305025] ath10k_pci 0001:03:00.0: [36]: 0x809B3A46 0x0040692C 
0x00000002 0x0042B988
[   54.312935] ath10k_pci 0001:03:00.0: [40]: 0x809B3123 0x0040695C 
0x00406980 0x00423B7C
[   54.320834] ath10k_pci 0001:03:00.0: [44]: 0x8096EE0E 0x0040697C 
0x000EE6C0 0x00000001
[   54.328740] ath10k_pci 0001:03:00.0: [48]: 0x8096F883 0x00406A2C 
0x0042D570 0x004241A4
[   54.336646] ath10k_pci 0001:03:00.0: [52]: 0x80963A26 0x00406A4C 
0x0042D570 0x00405528
[   54.344552] ath10k_pci 0001:03:00.0: [56]: 0x80960E80 0x00406A9C 
0x0000000D 0x00400000
[   54.352458] ath10k_pci 0001:03:00.0: Copy Engine register dump:
[   54.358371] ath10k_pci 0001:03:00.0: [00]: 0x0004a000  15  15 3   3
[   54.364809] ath10k_pci 0001:03:00.0: [01]: 0x0004a400  23  23 90  91
[   54.371240] ath10k_pci 0001:03:00.0: [02]: 0x0004a800   0   0 63   0
[   54.377679] ath10k_pci 0001:03:00.0: [03]: 0x0004ac00  12  12 13  12
[   54.384118] ath10k_pci 0001:03:00.0: [04]: 0x0004b000  19  19 59  19
[   54.390548] ath10k_pci 0001:03:00.0: [05]: 0x0004b400  24  24 55  56
[   54.396986] ath10k_pci 0001:03:00.0: [06]: 0x0004b800  23  23 23  23
[   54.403425] ath10k_pci 0001:03:00.0: [07]: 0x0004bc00   1   1 1   1
[   54.409857] ath10k_pci 0001:03:00.0: [08]: 0x0004c000   0   0 127   0
[   54.416295] ath10k_pci 0001:03:00.0: [09]: 0x0004c400   1   1 1   1
[   54.422736] ath10k_pci 0001:03:00.0: [10]: 0x0004c800   0   0 0   0
[   54.429171] ath10k_pci 0001:03:00.0: [11]: 0x0004cc00   0   0 0   0
[   57.191977] ath10k_pci 0001:03:00.0: failed to setup peer SMPS for 
vdev 0: -11
[   57.199187] ath10k_pci 0001:03:00.0: failed to associate station 
14:91:82:b9:16:d4 for vdev 0: -11
[   60.231976] ath10k_pci 0001:03:00.0: failed to delete peer 
14:91:82:b9:16:d4 for vdev 0: -11
[   60.240441] ath10k_pci 0001:03:00.0: found sta peer 14:91:82:b9:16:d4 
(ptr ede98200 id 3) entry on vdev 0 after it was supposedly removed
[   60.252989] ath10k_pci 0001:03:00.0: failed to read temperature -11
Adrian Chadd April 23, 2018, 4:41 p.m. UTC | #13
On 23 April 2018 at 08:50, Kalle Valo <kvalo@codeaurora.org> wrote:

>
> Adrian was also commenting something similar about adding a debugfs
> interface but I don't really see the point right now while we are adding
> initial wcn3990 support. If someone wants to run measurements with and
> without this parameter it's very easy to edit it out from the sources.
> Later on we can consider making it dynamic if there's really the need
> for that, but I'm very skeptic that anyone would even need that.

Hi!

We have at ${WORK}, because we've found various devices (atheros and
qualcomm and QCA and otherwise) have this nasty habit of trying to
guess when a good time to clock-gate down is, but we're busy doing low
latency audio/video.

10, 20ms may not be a lot of latency for bulk data but that's a half
to one of a video frame in my world. :-)



-adrian
Kalle Valo April 24, 2018, 5:27 a.m. UTC | #14
Sebastian Gottschall <s.gottschall@dd-wrt.com> writes:

> just for your notice. 10.4.3.5.3-0057 on 9984 which was just released
> crashes in vht160 operation mode immediatly after first station
> associates
> last known working stable fw so far is 10.4-3.4-00104. the whole
> 10.4.3.5.3 series seem to be seriously broken or the api has been
> changed in a way
> which is unsupported by ath10k (which i think is the cause of the problem)
> it would be good to know what has been changed.

At least I was not informed any changes in the firmware interface. What
version of ath10k are you using? Do you have any custom patches on
ath10k?
Kalle Valo April 24, 2018, 5:35 a.m. UTC | #15
Adrian Chadd <adrian@freebsd.org> writes:

> On 23 April 2018 at 08:50, Kalle Valo <kvalo@codeaurora.org> wrote:
>
>>
>> Adrian was also commenting something similar about adding a debugfs
>> interface but I don't really see the point right now while we are adding
>> initial wcn3990 support. If someone wants to run measurements with and
>> without this parameter it's very easy to edit it out from the sources.
>> Later on we can consider making it dynamic if there's really the need
>> for that, but I'm very skeptic that anyone would even need that.
>
> Hi!
>
> We have at ${WORK}, because we've found various devices (atheros and
> qualcomm and QCA and otherwise) have this nasty habit of trying to
> guess when a good time to clock-gate down is, but we're busy doing low
> latency audio/video.
>
> 10, 20ms may not be a lot of latency for bulk data but that's a half
> to one of a video frame in my world. :-)

Sure, I get that. But we should discuss making a setting like this
dynamic once we have a test case and numbers showing that it's needed,
otherwise it's just unnecessary cruft.
diff mbox

Patch

diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 7e02ca02b28e..1d9222af1bb2 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -4679,6 +4679,13 @@  static int ath10k_start(struct ieee80211_hw *hw)
 		}
 	}
 
+	param = ar->wmi.pdev_param->idle_ps_config;
+	ret = ath10k_wmi_pdev_set_param(ar, param, 1);
+	if (ret && ret != -EOPNOTSUPP) {
+		ath10k_warn(ar, "failed to enable idle_ps_config: %d\n", ret);
+		goto err_core_stop;
+	}
+
 	__ath10k_set_antenna(ar, ar->cfg_tx_chainmask, ar->cfg_rx_chainmask);
 
 	/*