rtl8xxxu: Fix for agressive power saving by rtl8723bu wireless IC
Subsystems (3)
PATCH v2 1/1 rtl8xxxu: Fix for agressive power saving by rtl8723bu wireless IC
The rtl8723bu wireless IC shows evidence of a more agressive approach to power saving, powering down its RF side when there is no wireless interfacing but leaving USB interfacing intact. This makes the wireless IC more suitable for use in devices which need to keep their power use as low as practical, such as tablets and Surface Pro type devices.
In effect this means that a full initialisation must be performed whenever a wireless interface is brought up. It also means that interpretations of power status from general wireless registers should not be relied on to influence an init sequence.
The patch works by forcing a fuller initialisation and forcing it to occur more often in code paths (such as occurs during a low level authentication that initiates wireless interfacing).
The initialisation sequence is now more consistent with code based directly on vendor code. For example while the vendor derived code interprets a register as indcating a particular powered state, it does not use this information to influence its init sequence.
Only devices that use the rtl8723bu driver are affected by this patch.
With this patch wpa_supplicant reliably and consistently connects with an AP. Before a workaround such as executing rmmod and modprobe before each call to wpa_supplicant worked with some distributions.
--- drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-)
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c +12 -4
@@ -3900,7 +3900,7 @@ static int rtl8xxxu_init_device(struct ieee80211_hw *hw)* Fix 92DU-VC S3 hang with the reason is that secondary mac is not * initialized. First MAC returns 0xea, second MAC returns 0x00 */ -if (val8 ==0xea ) +if (val8 ==0xea || priv->fops == &rtl8723bu_fops) macpower = false;else macpower = true;
@@ -5779,6 +5779,12 @@ static int rtl8xxxu_start(struct ieee80211_hw *hw) ret =0 ; +if (priv->fops == &rtl8723bu_fops) { + ret =rtl8xxxu_init_device (hw); +if (ret) + goto error_out; + } +init_usb_anchor (&priv->rx_anchor);init_usb_anchor (&priv->tx_anchor);init_usb_anchor (&priv->int_anchor);
@@ -6080,9 +6086,11 @@ static int rtl8xxxu_probe(struct usb_interface *interface, goto exit; } - ret =rtl8xxxu_init_device (hw); -if (ret) - goto exit; +if (priv->fops != &rtl8723bu_fops) { + ret =rtl8xxxu_init_device (hw); +if (ret) + goto exit; + } hw->wiphy->max_scan_ssids =1 ; hw->wiphy->max_scan_ie_len =IEEE80211_MAX_DATA_LEN ;
Signature · 1 line
2.10.1
Review static int rtl8xxxu_start(struct ieee80211_hw *hw) · line 5782
Quoted 5 lines · John Heenan
(quoted diff) +1
-0@@ -5779,6 +5779,12 @@ static int rtl8xxxu_start(struct ieee80211_hw *hw) ret =3D 0; + if(priv->fops =3D=3D &rtl8723bu_fops) {
OK, let me be the first. Documentation/CodingStyle also says to use space between "if" and "(" ;)
Review static int rtl8xxxu_probe(struct usb_interface *in=
Quoted 1 line
(quoted diff) +0
-0@@ -6080,9 +6086,11 @@ static int rtl8xxxu_probe(struct usb_interface *in=
terface,
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c static int rtl8xxxu_probe(struct usb_interface *interface,
Quoted 7 lines
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c +1
-3goto exit; } - ret =3D rtl8xxxu_init_device(hw); -if (ret) - goto exit; +if (priv->fops !=3D &rtl8723bu_fops) {
Same here.
I reviewed style only.
--=20
Rafa=C5=82
Quoted 75 lines · John Heenan
The rtl8723bu wireless IC shows evidence of a more agressive approach to power saving, powering down its RF side when there is no wireless interfacing but leaving USB interfacing intact. This makes the wireless IC more suitable for use in devices which need to keep their power use as low as practical, such as tablets and Surface Pro type devices.
In effect this means that a full initialisation must be performed whenever a wireless interface is brought up. It also means that interpretations of power status from general wireless registers should not be relied on to influence an init sequence.
The patch works by forcing a fuller initialisation and forcing it to occur more often in code paths (such as occurs during a low level authentication that initiates wireless interfacing).
The initialisation sequence is now more consistent with code based directly on vendor code. For example while the vendor derived code interprets a register as indcating a particular powered state, it does not use this information to influence its init sequence.
Only devices that use the rtl8723bu driver are affected by this patch.
With this patch
wpa_supplicantreliably and consistently connects with an AP. Before a workaround such as executing rmmod and modprobe before each call towpa_supplicantworked with some distributions.Signed-off-by John Heenan <[email protected]>--- drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-)drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c +12
-4@@ -3900,7 +3900,7 @@ static int rtl8xxxu_init_device(struct ieee80211_hw *hw)* Fix 92DU-VC S3 hang with the reason is that secondary mac is not * initialized. First MAC returns 0xea, second MAC returns 0x00 */ -if (val8 ==0xea ) +if (val8 ==0xea || priv->fops == &rtl8723bu_fops) macpower = false;else macpower = true;@@ -5779,6 +5779,12 @@ static int rtl8xxxu_start(struct ieee80211_hw *hw) ret =0 ; +if (priv->fops == &rtl8723bu_fops) { + ret =rtl8xxxu_init_device (hw); +if (ret) + goto error_out; + } +init_usb_anchor (&priv->rx_anchor);init_usb_anchor (&priv->tx_anchor);init_usb_anchor (&priv->int_anchor);@@ -6080,9 +6086,11 @@ static int rtl8xxxu_probe(struct usb_interface *interface, goto exit; } - ret =rtl8xxxu_init_device (hw); -if (ret) - goto exit; +if (priv->fops != &rtl8723bu_fops) { + ret =rtl8xxxu_init_device (hw); +if (ret) + goto exit; + } hw->wiphy->max_scan_ssids =1 ; hw->wiphy->max_scan_ie_len =IEEE80211_MAX_DATA_LEN ;Signature · 1 line
2.10.1
I've been trying similar modifications, testing them with the 8192eu and cu. Basically I moved all the usb stuff out of start and stop and into probe and disconnect. I moved the call to rtl8xxxu_init_device() from probe to start.
Doing wpa_supplicant restart tests, the 8192cu still works everytime as it did before. The 8192eu now works at least 50% of the time, and when it fails it's now during the 4-way handshake phase which may be a separate issue confined to the 8192eu only.
Note these results rely on changing the macpower test to this -
if(val8 == 0xea || val8 == 0xff)
which is different again from what you are using so I'm of the opinion we need to come up with a different way of telling whether the mac is powered.
Quoted 22 lines · John Heenan
The rtl8723bu wireless IC shows evidence of a more agressive approach to power saving, powering down its RF side when there is no wireless interfacing but leaving USB interfacing intact. This makes the wireless IC more suitable for use in devices which need to keep their power use as low as practical, such as tablets and Surface Pro type devices.
In effect this means that a full initialisation must be performed whenever a wireless interface is brought up. It also means that interpretations of power status from general wireless registers should not be relied on to influence an init sequence.
The patch works by forcing a fuller initialisation and forcing it to occur more often in code paths (such as occurs during a low level authentication that initiates wireless interfacing).
The initialisation sequence is now more consistent with code based directly on vendor code. For example while the vendor derived code interprets a register as indcating a particular powered state, it does not use this information to influence its init sequence.
Only devices that use the rtl8723bu driver are affected by this patch.
Quoted 9 lines
With this patch
wpa_supplicantreliably and consistently connects with an AP. Before a workaround such as executing rmmod and modprobe before each call towpa_supplicantworked with some distributions.Signed-off-by John Heenan <[email protected]>--- drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-)
I am at Linux Plumbers this week, so my response time is slow. Next week I am on PTO, so I will not respond.
First of all, why do you keep CC'ing multiple mailing lists that do not matter? This discussion belongs on linux-wireless not on netdev or lkml. CC'ing Kalle directly is not going to get him to apply this broken patch for you.
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c static int rtl8xxxu_init_device(struct ieee80211_hw *hw) · line 3906
Quoted 13 lines
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c +1
-1@@ -3900,7 +3900,7 @@ static int rtl8xxxu_init_device(struct ieee80211_hw *hw)* Fix 92DU-VC S3 hang with the reason is that secondary mac is not * initialized. First MAC returns 0xea, second MAC returns 0x00 */ -if (val8 ==0xea ) +if (val8 ==0xea || priv->fops == &rtl8723bu_fops) macpower = false;else macpower = true;
Why oh why do you insist on not using the *standard* way of coping with this? 'priv-rtl_chip' is used everywhere else, but you just have to do something awful like this?
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c static int rtl8xxxu_start(struct ieee80211_hw *hw) · line 5790
Quoted 13 lines
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c +6
-0@@ -5779,6 +5779,12 @@ static int rtl8xxxu_start(struct ieee80211_hw *hw) ret =0 ; +if (priv->fops == &rtl8723bu_fops) { + ret =rtl8xxxu_init_device (hw); +if (ret) + goto error_out; + } +init_usb_anchor (&priv->rx_anchor);init_usb_anchor (&priv->tx_anchor);init_usb_anchor (&priv->int_anchor);
Read Documentation/CodingStyle - as others already pointed you at.
Quoted 5 lines
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c +0
-1@@ -6080,9 +6086,11 @@ static int rtl8xxxu_probe(struct usb_interface *interface, goto exit; } - ret =rtl8xxxu_init_device (hw);
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c static int rtl8xxxu_probe(struct usb_interface *interface, · line 6096
Quoted 10 lines
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c +5
-2-if (ret) - goto exit; +if (priv->fops != &rtl8723bu_fops) { + ret =rtl8xxxu_init_device (hw); +if (ret) + goto exit; + } hw->wiphy->max_scan_ssids =1 ; hw->wiphy->max_scan_ie_len =IEEE80211_MAX_DATA_LEN ;
Again coding style violation.
Second, I am NOT going to accept any patches that fundamentally changes the init sequence of the code for just one device.
I already told you I want to find out *why* this matters, and what part of rtl8xxxu_init_device() is the culprit. I want to understand the actual problem, not just blindly move stuff around.
Jes