* [PATCH v2 02/12] mwifiex: complete blocked power save handshake in main process
From: Xinming Hu @ 2016-11-01 12:08 UTC (permalink / raw)
To: Linux Wireless
Cc: Kalle Valo, Brian Norris, Dmitry Torokhov, Amitkumar Karwar,
Cathy Luo, Shengzhen Li, Xinming Hu
In-Reply-To: <1478002098-14189-1-git-send-email-huxinming820@marvell.com>
From: Shengzhen Li <szli@marvell.com>
Power save handshake with firmware might be blocked by on-going
data transfer.
this patch check the PS status in main process and complete
previous blocked PS handshake.
this patch also remove redudant check before call
mwifiex_check_ps_cond fuction.
---
v2: 1. remove redudant check(Brain)
3. reorgnized to follow tx_hw_pending patch
---
Signed-off-by: Cathy Luo <cluo@marvell.com>
Signed-off-by: Shengzhen Li <szli@marvell.com>
Signed-off-by: Xinming Hu <huxm@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
drivers/net/wireless/marvell/mwifiex/main.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/main.c b/drivers/net/wireless/marvell/mwifiex/main.c
index 2478ccd..d700c44 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.c
+++ b/drivers/net/wireless/marvell/mwifiex/main.c
@@ -308,6 +308,9 @@ process_start:
/* We have tried to wakeup the card already */
if (adapter->pm_wakeup_fw_try)
break;
+ if (adapter->ps_state == PS_STATE_PRE_SLEEP)
+ mwifiex_check_ps_cond(adapter);
+
if (adapter->ps_state != PS_STATE_AWAKE)
break;
if (adapter->tx_lock_flag) {
@@ -355,10 +358,8 @@ process_start:
/* Check if we need to confirm Sleep Request
received previously */
- if (adapter->ps_state == PS_STATE_PRE_SLEEP) {
- if (!adapter->cmd_sent && !adapter->curr_cmd)
- mwifiex_check_ps_cond(adapter);
- }
+ if (adapter->ps_state == PS_STATE_PRE_SLEEP)
+ mwifiex_check_ps_cond(adapter);
/* * The ps_state may have been changed during processing of
* Sleep Request event.
--
1.8.1.4
^ permalink raw reply related
* [PATCH v2 01/12] mwifiex: check tx_hw_pending before downloading sleep confirm
From: Xinming Hu @ 2016-11-01 12:08 UTC (permalink / raw)
To: Linux Wireless
Cc: Kalle Valo, Brian Norris, Dmitry Torokhov, Amitkumar Karwar,
Cathy Luo, Shengzhen Li, Xinming Hu
From: Shengzhen Li <szli@marvell.com>
We may get SLEEP event from firmware even if TXDone interrupt
for last Tx packet is still pending. In this case, we may
end up accessing PCIe memory for handling TXDone after power
save handshake is completed. This causes kernel crash with
external abort.
This patch will only allow downloading sleep confirm
when no tx done interrupt is pending in the hardware.
---
v2: address format issues(Brain)
---
Signed-off-by: Cathy Luo <cluo@marvell.com>
Signed-off-by: Shengzhen Li <szli@marvell.com>
Signed-off-by: Xinming Hu <huxm@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
drivers/net/wireless/marvell/mwifiex/cmdevt.c | 5 +++--
drivers/net/wireless/marvell/mwifiex/init.c | 1 +
drivers/net/wireless/marvell/mwifiex/main.h | 1 +
drivers/net/wireless/marvell/mwifiex/pcie.c | 5 +++++
4 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/cmdevt.c b/drivers/net/wireless/marvell/mwifiex/cmdevt.c
index 5347728..25a7475 100644
--- a/drivers/net/wireless/marvell/mwifiex/cmdevt.c
+++ b/drivers/net/wireless/marvell/mwifiex/cmdevt.c
@@ -1118,13 +1118,14 @@ mwifiex_cancel_pending_ioctl(struct mwifiex_adapter *adapter)
void
mwifiex_check_ps_cond(struct mwifiex_adapter *adapter)
{
- if (!adapter->cmd_sent &&
+ if (!adapter->cmd_sent && !atomic_read(&adapter->tx_hw_pending) &&
!adapter->curr_cmd && !IS_CARD_RX_RCVD(adapter))
mwifiex_dnld_sleep_confirm_cmd(adapter);
else
mwifiex_dbg(adapter, CMD,
- "cmd: Delay Sleep Confirm (%s%s%s)\n",
+ "cmd: Delay Sleep Confirm (%s%s%s%s)\n",
(adapter->cmd_sent) ? "D" : "",
+ atomic_read(&adapter->tx_hw_pending) ? "T" : "",
(adapter->curr_cmd) ? "C" : "",
(IS_CARD_RX_RCVD(adapter)) ? "R" : "");
}
diff --git a/drivers/net/wireless/marvell/mwifiex/init.c b/drivers/net/wireless/marvell/mwifiex/init.c
index 82839d9..b36cb3f 100644
--- a/drivers/net/wireless/marvell/mwifiex/init.c
+++ b/drivers/net/wireless/marvell/mwifiex/init.c
@@ -270,6 +270,7 @@ static void mwifiex_init_adapter(struct mwifiex_adapter *adapter)
adapter->adhoc_11n_enabled = false;
mwifiex_wmm_init(adapter);
+ atomic_set(&adapter->tx_hw_pending, 0);
sleep_cfm_buf = (struct mwifiex_opt_sleep_confirm *)
adapter->sleep_cfm->data;
diff --git a/drivers/net/wireless/marvell/mwifiex/main.h b/drivers/net/wireless/marvell/mwifiex/main.h
index d61fe3a..7f67f23 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.h
+++ b/drivers/net/wireless/marvell/mwifiex/main.h
@@ -857,6 +857,7 @@ struct mwifiex_adapter {
atomic_t rx_pending;
atomic_t tx_pending;
atomic_t cmd_pending;
+ atomic_t tx_hw_pending;
struct workqueue_struct *workqueue;
struct work_struct main_work;
struct workqueue_struct *rx_workqueue;
diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c
index 063c707..4aa5d91 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -516,6 +516,7 @@ static int mwifiex_pcie_enable_host_int(struct mwifiex_adapter *adapter)
}
}
+ atomic_set(&adapter->tx_hw_pending, 0);
return 0;
}
@@ -689,6 +690,7 @@ static void mwifiex_cleanup_txq_ring(struct mwifiex_adapter *adapter)
card->tx_buf_list[i] = NULL;
}
+ atomic_set(&adapter->tx_hw_pending, 0);
return;
}
@@ -1126,6 +1128,7 @@ static int mwifiex_pcie_send_data_complete(struct mwifiex_adapter *adapter)
-1);
else
mwifiex_write_data_complete(adapter, skb, 0, 0);
+ atomic_dec(&adapter->tx_hw_pending);
}
card->tx_buf_list[wrdoneidx] = NULL;
@@ -1218,6 +1221,7 @@ mwifiex_pcie_send_data(struct mwifiex_adapter *adapter, struct sk_buff *skb,
wrindx = (card->txbd_wrptr & reg->tx_mask) >> reg->tx_start_ptr;
buf_pa = MWIFIEX_SKB_DMA_ADDR(skb);
card->tx_buf_list[wrindx] = skb;
+ atomic_inc(&adapter->tx_hw_pending);
if (reg->pfu_enabled) {
desc2 = card->txbd_ring[wrindx];
@@ -1295,6 +1299,7 @@ mwifiex_pcie_send_data(struct mwifiex_adapter *adapter, struct sk_buff *skb,
done_unmap:
mwifiex_unmap_pci_memory(adapter, skb, PCI_DMA_TODEVICE);
card->tx_buf_list[wrindx] = NULL;
+ atomic_dec(&adapter->tx_hw_pending);
if (reg->pfu_enabled)
memset(desc2, 0, sizeof(*desc2));
else
--
1.8.1.4
^ permalink raw reply related
* [PATCH 1/2] Documentation: devicetree: Add bindings info for rfkill-regulator
From: Paul Cercueil @ 2016-11-01 10:58 UTC (permalink / raw)
To: Johannes Berg, David S . Miller, Rob Herring, Mark Rutland,
netdev, devicetree, linux-kernel, linux-wireless
Cc: Maarten ter Huurne, Paul Cercueil
This document gives information about how to write a devicetree
node that corresponds to the rfkill-regulator driver.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
---
.../devicetree/bindings/net/rfkill-regulator.txt | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/rfkill-regulator.txt
diff --git a/Documentation/devicetree/bindings/net/rfkill-regulator.txt b/Documentation/devicetree/bindings/net/rfkill-regulator.txt
new file mode 100644
index 0000000..aac2fe1
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/rfkill-regulator.txt
@@ -0,0 +1,18 @@
+Device tree bindings for the rfkill-regulator driver
+
+Required properties:
+ - compatible: should be "rfkill-regulator"
+ - rfkill-name: the name of this rfkill device
+ - rfkill-type: the type of this rfkill device;
+ must correspond to a valid rfkill_type from <uapi/linux/rfkill.h>
+ - vrfkill-supply: phandle to a regulator
+
+Example:
+
+ wlan-rfkill {
+ compatible = "rfkill-regulator";
+ rfkill-name = "WLAN power switch";
+ rfkill-type = <1>;
+
+ vrfkill-supply = <&wlan_power>;
+ };
--
2.9.3
^ permalink raw reply related
* [PATCH 2/2] net: rfkill-regulator: Add devicetree support
From: Paul Cercueil @ 2016-11-01 10:58 UTC (permalink / raw)
To: Johannes Berg, David S . Miller, Rob Herring, Mark Rutland,
netdev, devicetree, linux-kernel, linux-wireless
Cc: Maarten ter Huurne, Paul Cercueil
In-Reply-To: <20161101105840.24313-1-paul@crapouillou.net>
This commit adds the support for probing the rfkill-regulator
from devicetree.
Information about the devicetree bindings can be found here:
Documentation/devicetree/bindings/net/rfkill-regulator.txt
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
---
net/rfkill/rfkill-regulator.c | 43 ++++++++++++++++++++++++++++++++-----------
1 file changed, 32 insertions(+), 11 deletions(-)
diff --git a/net/rfkill/rfkill-regulator.c b/net/rfkill/rfkill-regulator.c
index 50cd26a..29ded4c 100644
--- a/net/rfkill/rfkill-regulator.c
+++ b/net/rfkill/rfkill-regulator.c
@@ -13,6 +13,7 @@
*/
#include <linux/module.h>
+#include <linux/of.h>
#include <linux/err.h>
#include <linux/slab.h>
#include <linux/platform_device.h>
@@ -60,24 +61,38 @@ static struct rfkill_ops rfkill_regulator_ops = {
static int rfkill_regulator_probe(struct platform_device *pdev)
{
struct rfkill_regulator_platform_data *pdata = pdev->dev.platform_data;
+ struct device_node *node = pdev->dev.of_node;
struct rfkill_regulator_data *rfkill_data;
struct regulator *vcc;
struct rfkill *rf_kill;
+ const char *name;
+ u32 type;
int ret = 0;
- if (pdata == NULL) {
+ if (pdata) {
+ if (!pdata->name || !pdata->type) {
+ dev_err(&pdev->dev, "invalid name or type in platform data\n");
+ return -EINVAL;
+ }
+
+ name = pdata->name;
+ type = pdata->type;
+ } else if (node) {
+ ret = of_property_read_u32(node, "rfkill-type", &type);
+ if (ret < 0)
+ return ret;
+
+ ret = of_property_read_string(node, "rfkill-name", &name);
+ if (ret < 0)
+ return ret;
+ } else {
dev_err(&pdev->dev, "no platform data\n");
return -ENODEV;
}
- if (pdata->name == NULL || pdata->type == 0) {
- dev_err(&pdev->dev, "invalid name or type in platform data\n");
- return -EINVAL;
- }
-
vcc = regulator_get_exclusive(&pdev->dev, "vrfkill");
if (IS_ERR(vcc)) {
- dev_err(&pdev->dev, "Cannot get vcc for %s\n", pdata->name);
+ dev_err(&pdev->dev, "Cannot get vcc for %s\n", name);
ret = PTR_ERR(vcc);
goto out;
}
@@ -88,9 +103,8 @@ static int rfkill_regulator_probe(struct platform_device *pdev)
goto err_data_alloc;
}
- rf_kill = rfkill_alloc(pdata->name, &pdev->dev,
- pdata->type,
- &rfkill_regulator_ops, rfkill_data);
+ rf_kill = rfkill_alloc(name, &pdev->dev, type,
+ &rfkill_regulator_ops, rfkill_data);
if (rf_kill == NULL) {
ret = -ENOMEM;
goto err_rfkill_alloc;
@@ -110,7 +124,7 @@ static int rfkill_regulator_probe(struct platform_device *pdev)
}
platform_set_drvdata(pdev, rfkill_data);
- dev_info(&pdev->dev, "%s initialized\n", pdata->name);
+ dev_info(&pdev->dev, "%s initialized\n", name);
return 0;
@@ -137,11 +151,18 @@ static int rfkill_regulator_remove(struct platform_device *pdev)
return 0;
}
+static const struct of_device_id rfkill_regulator_of_match[] = {
+ { .compatible = "rfkill-regulator" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, rfkill_regulator_of_match);
+
static struct platform_driver rfkill_regulator_driver = {
.probe = rfkill_regulator_probe,
.remove = rfkill_regulator_remove,
.driver = {
.name = "rfkill-regulator",
+ .of_match_table = of_match_ptr(rfkill_regulator_of_match),
},
};
--
2.9.3
^ permalink raw reply related
* RE: [PATCH 01/12] mwifiex: fix power save issue when suspend
From: Xinming Hu @ 2016-11-01 10:26 UTC (permalink / raw)
To: Brian Norris, Xinming Hu
Cc: Linux Wireless, Kalle Valo, Dmitry Torokhov, Amitkumar Karwar,
Cathy Luo, Shengzhen Li
In-Reply-To: <20161031235712.GA101079@google.com>
SGkgQnJpYW4sDQoNClRoYW5rcyBmb3IgcmV2aWV3LCB3ZSB3aWxsIGFkZHJlc3MgeW91ciBjb21t
ZW50cyBpbiB1cGRhdGVkIHZlcnNpb24uDQpTaW5jZSB3ZSBoYXZlIGFuIGVuaGFuY2VkIHZlcmlz
b24gZm9yIEZST01MSVNUOiBtd2lmaWV4OiBmaXggY29ybmVyIGNhc2UsIA0KdGhhdCBpcyBodHRw
czovL3BhdGNod29yay5rZXJuZWwub3JnL3BhdGNoLzk0MDUxMTkvICwNCnRoZSB1cGRhdGVkIHBh
dGNoIHdpbGwgYmUgcmVvcmdhbml6ZWQgdG8gZm9sbG93IGFib3ZlIHBhdGNoLg0KDQo+IC0tLS0t
T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGxpbnV4LXdpcmVsZXNzLW93bmVyQHZnZXIu
a2VybmVsLm9yZw0KPiBbbWFpbHRvOmxpbnV4LXdpcmVsZXNzLW93bmVyQHZnZXIua2VybmVsLm9y
Z10gT24gQmVoYWxmIE9mIEJyaWFuIE5vcnJpcw0KPiBTZW50OiAyMDE2xOoxMdTCMcjVIDc6NTcN
Cj4gVG86IFhpbm1pbmcgSHUNCj4gQ2M6IExpbnV4IFdpcmVsZXNzOyBLYWxsZSBWYWxvOyBEbWl0
cnkgVG9yb2tob3Y7IEFtaXRrdW1hciBLYXJ3YXI7IENhdGh5IEx1bzsNCj4gU2hlbmd6aGVuIExp
DQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggMDEvMTJdIG13aWZpZXg6IGZpeCBwb3dlciBzYXZlIGlz
c3VlIHdoZW4gc3VzcGVuZA0KPiANCj4gSGksDQo+IA0KPiBPbiBNb24sIE9jdCAzMSwgMjAxNiBh
dCAwNDowMjowOVBNICswODAwLCBYaW5taW5nIEh1IHdyb3RlOg0KPiA+IEZyb206IFNoZW5nemhl
biBMaSA8c3psaUBtYXJ2ZWxsLmNvbT4NCj4gPg0KPiA+IFRoaXMgcGF0Y2ggZml4ZXMgYSBjb3Ju
ZXIgY2FzZSBmb3IgIkZST01MSVNUOiBtd2lmaWV4OiBmaXggY29ybmVyIGNhc2UNCj4gDQo+IFVw
c3RyZWFtIHBhdGNoZXMgZG9uJ3Qgbm9ybWFsbHkgZ2V0IGEgJ0ZST01MSVNUJyB0YWcgd2hpbGUg
eW91J3JlIHNlbmRpbmcNCj4gdGhlbSB0byB0aGUgbWFpbGluZyBsaXN0IDopIFRoYXQgZGVzaWdu
YXRpb24gaXMgdXNlZCBmb3IgQ2hyb21lIE9TIHRyZWVzLCBzbyB3ZQ0KPiBrbm93IHdoZXJlIHRv
IGZpbmQgdGhlIHBhdGNoIHNvdXJjZS4gQnV0IHRoZSB1cHN0cmVhbSBtYWlsaW5nIGxpc3QgKmlz
KiB0aGUNCj4gc291cmNlLg0KPiANCj4gPiBwb3dlciBzYXZlIGlzc3VlIiwgbWFpbiBwcm9jZXNz
IHdpbGwgY2hlY2sgdGhlIHBvd2VyIHNhdmUgY29uZGl0aW9uIGluDQo+ID4gUFNfUFJFX1NMRUVQ
IHN0YXR1cyBzbyB0aGUgc2xlZXAgaGFuZHNoYWtlIGNvdWxkIGNvbnRpbnVlLg0KPiA+DQo+ID4g
U2lnbmVkLW9mZi1ieTogQ2F0aHkgTHVvIDxjbHVvQG1hcnZlbGwuY29tPg0KPiA+IFNpZ25lZC1v
ZmYtYnk6IFNoZW5nemhlbiBMaSA8c3psaUBtYXJ2ZWxsLmNvbT4NCj4gPiBTaWduZWQtb2ZmLWJ5
OiBBbWl0a3VtYXIgS2Fyd2FyIDxha2Fyd2FyQG1hcnZlbGwuY29tPg0KPiA+DQo+ID4gQlVHPWNo
cm9tZS1vcy1wYXJ0bmVyOjU4MTY0DQo+ID4gVEVTVD1zdHJlc3MgV2lmaSB3LyBwb3dlcl9zYXZl
IGVuYWJsZWQNCj4gPg0KPiA+IENoYW5nZS1JZDogSTVhMzZkOWVhZWI3ZmU1ZmFhY2NjNTMzZTBk
MWJhMWYzMjUzNjY2ZGMNCj4gDQo+IEluIHRoZSBzYW1lIHZlaW46IHdoaWxlIEknbSBoYXBweSB0
byBoYXZlIHRoZSBCVUc9LCBURVNUPSwgYW5kIEdlcnJpdA0KPiBDaGFuZ2UtSUQgZm9yIG91ciBD
aHJvbWUgT1MgdHJlZSwgSSBkb24ndCB0aGluayB1cHN0cmVhbSByZXZpZXdlcnMgdHlwaWNhbGx5
DQo+IGNhcmUgYWJvdXQgdGhvc2UuIFBsZWFzZSByZW1vdmUgdGhvc2UgZnJvbSB1cHN0cmVhbSBz
dWJtaXNzaW9ucyBsaWtlIHRoaXMuDQo+IA0KPiAoU2FtZSBhcHBsaWVzIHRvIHRoZSByZXN0IG9m
IHRoaXMgc2VyaWVzLiBBbHNvLCBjb25zaWRlciBydW5uaW5nDQo+IHNjcmlwdHMvY2hlY2twYXRj
aC5wbC4gSXQgd2lsbCBhdCBsZWFzdCByZW1pbmQgeW91IGFib3V0IHJlbW92aW5nIHRoZSBHZXJy
aXQNCj4gQ2hhbmdlLUlELikNCj4gDQo+ID4gLS0tDQo+ID4gIGRyaXZlcnMvbmV0L3dpcmVsZXNz
L21hcnZlbGwvbXdpZmlleC9jbWRldnQuYyB8IDMgKystDQo+ID4gIGRyaXZlcnMvbmV0L3dpcmVs
ZXNzL21hcnZlbGwvbXdpZmlleC9tYWluLmMgICB8IDUgKysrKysNCj4gPiAgMiBmaWxlcyBjaGFu
Z2VkLCA3IGluc2VydGlvbnMoKyksIDEgZGVsZXRpb24oLSkNCj4gPg0KPiA+IGRpZmYgLS1naXQg
YS9kcml2ZXJzL25ldC93aXJlbGVzcy9tYXJ2ZWxsL213aWZpZXgvY21kZXZ0LmMNCj4gPiBiL2Ry
aXZlcnMvbmV0L3dpcmVsZXNzL21hcnZlbGwvbXdpZmlleC9jbWRldnQuYw0KPiA+IGluZGV4IDUz
NDc3MjguLjkwNzViZTUgMTAwNjQ0DQo+ID4gLS0tIGEvZHJpdmVycy9uZXQvd2lyZWxlc3MvbWFy
dmVsbC9td2lmaWV4L2NtZGV2dC5jDQo+ID4gKysrIGIvZHJpdmVycy9uZXQvd2lyZWxlc3MvbWFy
dmVsbC9td2lmaWV4L2NtZGV2dC5jDQo+ID4gQEAgLTExMjMsOCArMTEyMyw5IEBAIG13aWZpZXhf
Y2hlY2tfcHNfY29uZChzdHJ1Y3QgbXdpZmlleF9hZGFwdGVyDQo+ICphZGFwdGVyKQ0KPiA+ICAJ
CW13aWZpZXhfZG5sZF9zbGVlcF9jb25maXJtX2NtZChhZGFwdGVyKTsNCj4gPiAgCWVsc2UNCj4g
PiAgCQltd2lmaWV4X2RiZyhhZGFwdGVyLCBDTUQsDQo+ID4gLQkJCSAgICAiY21kOiBEZWxheSBT
bGVlcCBDb25maXJtICglcyVzJXMpXG4iLA0KPiA+ICsJCQkgICAgImNtZDogRGVsYXkgU2xlZXAg
Q29uZmlybSAoJXMlcyVzJXMpXG4iLA0KPiA+ICAJCQkgICAgKGFkYXB0ZXItPmNtZF9zZW50KSA/
ICJEIiA6ICIiLA0KPiA+ICsJCQkgICAgKGFkYXB0ZXItPmRhdGFfc2VudCkgPyAiVCIgOiAiIiwN
Cj4gPiAgCQkJICAgIChhZGFwdGVyLT5jdXJyX2NtZCkgPyAiQyIgOiAiIiwNCj4gPiAgCQkJICAg
IChJU19DQVJEX1JYX1JDVkQoYWRhcHRlcikpID8gIlIiIDogIiIpOyAgfSBkaWZmIC0tZ2l0DQo+
ID4gYS9kcml2ZXJzL25ldC93aXJlbGVzcy9tYXJ2ZWxsL213aWZpZXgvbWFpbi5jDQo+ID4gYi9k
cml2ZXJzL25ldC93aXJlbGVzcy9tYXJ2ZWxsL213aWZpZXgvbWFpbi5jDQo+ID4gaW5kZXggMjQ3
OGNjZC4uZjU1OWVhZCAxMDA2NDQNCj4gPiAtLS0gYS9kcml2ZXJzL25ldC93aXJlbGVzcy9tYXJ2
ZWxsL213aWZpZXgvbWFpbi5jDQo+ID4gKysrIGIvZHJpdmVycy9uZXQvd2lyZWxlc3MvbWFydmVs
bC9td2lmaWV4L21haW4uYw0KPiA+IEBAIC0zMDgsNiArMzA4LDExIEBAIHByb2Nlc3Nfc3RhcnQ6
DQo+ID4gIAkJCS8qIFdlIGhhdmUgdHJpZWQgdG8gd2FrZXVwIHRoZSBjYXJkIGFscmVhZHkgKi8N
Cj4gPiAgCQkJaWYgKGFkYXB0ZXItPnBtX3dha2V1cF9md190cnkpDQo+ID4gIAkJCQlicmVhazsN
Cj4gPiArCQkJaWYgKGFkYXB0ZXItPnBzX3N0YXRlID09IFBTX1NUQVRFX1BSRV9TTEVFUCkgew0K
PiA+ICsJCQkJaWYgKCFhZGFwdGVyLT5jbWRfc2VudCAmJiAhYWRhcHRlci0+Y3Vycl9jbWQpDQo+
IA0KPiBUaGUgZW50aXJlICdpZicgY29uZGl0aW9uIGlzIHVubmVjZXNzYXJ5LiBUaGF0J3MgYWxs
IGNoZWNrZWQgYWxyZWFkeSB3aXRoaW4NCj4gbXdpZmlleF9jaGVja19wc19jb25kKCkuDQo+IA0K
PiBCcmlhbg0KPiANCj4gPiArCQkJCQltd2lmaWV4X2NoZWNrX3BzX2NvbmQoYWRhcHRlcik7DQo+
ID4gKwkJCX0NCj4gPiArDQo+ID4gIAkJCWlmIChhZGFwdGVyLT5wc19zdGF0ZSAhPSBQU19TVEFU
RV9BV0FLRSkNCj4gPiAgCQkJCWJyZWFrOw0KPiA+ICAJCQlpZiAoYWRhcHRlci0+dHhfbG9ja19m
bGFnKSB7DQo+ID4gLS0NCj4gPiAxLjguMS40DQo+ID4NCg0KQmVzdCBSZWdhcmRzLA0KU2ltb24N
Cg==
^ permalink raw reply
* RE: [PATCH 02/12] mwifiex: check tx_hw_pending before downloading sleep confirm
From: Xinming Hu @ 2016-11-01 10:24 UTC (permalink / raw)
To: Brian Norris, Xinming Hu
Cc: Linux Wireless, Kalle Valo, Dmitry Torokhov, Amitkumar Karwar,
Cathy Luo, Shengzhen Li
In-Reply-To: <20161101001437.GB101079@google.com>
SGkgQnJhaW4sDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogbGludXgt
d2lyZWxlc3Mtb3duZXJAdmdlci5rZXJuZWwub3JnDQo+IFttYWlsdG86bGludXgtd2lyZWxlc3Mt
b3duZXJAdmdlci5rZXJuZWwub3JnXSBPbiBCZWhhbGYgT2YgQnJpYW4gTm9ycmlzDQo+IFNlbnQ6
IDIwMTbE6jEx1MIxyNUgODoxNQ0KPiBUbzogWGlubWluZyBIdQ0KPiBDYzogTGludXggV2lyZWxl
c3M7IEthbGxlIFZhbG87IERtaXRyeSBUb3Jva2hvdjsgQW1pdGt1bWFyIEthcndhcjsgQ2F0aHkg
THVvOw0KPiBTaGVuZ3poZW4gTGkNCj4gU3ViamVjdDogUmU6IFtQQVRDSCAwMi8xMl0gbXdpZmll
eDogY2hlY2sgdHhfaHdfcGVuZGluZyBiZWZvcmUgZG93bmxvYWRpbmcNCj4gc2xlZXAgY29uZmly
bQ0KPiANCj4gT24gTW9uLCBPY3QgMzEsIDIwMTYgYXQgMDQ6MDI6MTBQTSArMDgwMCwgWGlubWlu
ZyBIdSB3cm90ZToNCj4gPiBGcm9tOiBTaGVuZ3poZW4gTGkgPHN6bGlAbWFydmVsbC5jb20+DQo+
ID4NCj4gPiBUaGlzIHBhdGNoIHdpbGwgb25seSBhbGxvdyBkb3dubG9hZGluZyBzbGVlcCBjb25m
aXJtIHdoZW4gbm8gdHggZG9uZQ0KPiA+IGludGVycnVwdCBpcyBwZW5kaW5nIGluIHRoZSBoYXJk
d2FyZS4NCj4gPg0KPiA+IFNpZ25lZC1vZmYtYnk6IENhdGh5IEx1byA8Y2x1b0BtYXJ2ZWxsLmNv
bT4NCj4gPiBTaWduZWQtb2ZmLWJ5OiBTaGVuZ3poZW4gTGkgPHN6bGlAbWFydmVsbC5jb20+DQo+
ID4NCj4gPiBDaGFuZ2UtSWQ6IEk2ZDY5NTViNGEyZGUwYWQ3OTFjYTI4ZjBmNjM1ZDYzNmEyYzdl
NDA2DQo+IA0KPiANCj4gXl4gUmVtb3ZlIHRoaXMNCj4gDQoNCk9rLCB3aWxsIHJlbW92ZSBpbiB1
cGRhdGVkIHZlcnNpb24hDQoNCj4gPiAtLS0NCj4gPiAgZHJpdmVycy9uZXQvd2lyZWxlc3MvbWFy
dmVsbC9td2lmaWV4L2NtZGV2dC5jIHwgNCArKy0tDQo+ID4gIGRyaXZlcnMvbmV0L3dpcmVsZXNz
L21hcnZlbGwvbXdpZmlleC9pbml0LmMgICB8IDEgKw0KPiA+ICBkcml2ZXJzL25ldC93aXJlbGVz
cy9tYXJ2ZWxsL213aWZpZXgvbWFpbi5oICAgfCAxICsNCj4gPiAgZHJpdmVycy9uZXQvd2lyZWxl
c3MvbWFydmVsbC9td2lmaWV4L3BjaWUuYyAgIHwgNSArKysrKw0KPiA+ICA0IGZpbGVzIGNoYW5n
ZWQsIDkgaW5zZXJ0aW9ucygrKSwgMiBkZWxldGlvbnMoLSkNCj4gPg0KPiA+IGRpZmYgLS1naXQg
YS9kcml2ZXJzL25ldC93aXJlbGVzcy9tYXJ2ZWxsL213aWZpZXgvY21kZXZ0LmMNCj4gPiBiL2Ry
aXZlcnMvbmV0L3dpcmVsZXNzL21hcnZlbGwvbXdpZmlleC9jbWRldnQuYw0KPiA+IGluZGV4IDkw
NzViZTUuLjI1YTc0NzUgMTAwNjQ0DQo+ID4gLS0tIGEvZHJpdmVycy9uZXQvd2lyZWxlc3MvbWFy
dmVsbC9td2lmaWV4L2NtZGV2dC5jDQo+ID4gKysrIGIvZHJpdmVycy9uZXQvd2lyZWxlc3MvbWFy
dmVsbC9td2lmaWV4L2NtZGV2dC5jDQo+ID4gQEAgLTExMTgsMTQgKzExMTgsMTQgQEAgbXdpZmll
eF9jYW5jZWxfcGVuZGluZ19pb2N0bChzdHJ1Y3QNCj4gPiBtd2lmaWV4X2FkYXB0ZXIgKmFkYXB0
ZXIpICB2b2lkICBtd2lmaWV4X2NoZWNrX3BzX2NvbmQoc3RydWN0DQo+ID4gbXdpZmlleF9hZGFw
dGVyICphZGFwdGVyKSAgew0KPiA+IC0JaWYgKCFhZGFwdGVyLT5jbWRfc2VudCAmJg0KPiA+ICsJ
aWYgKCFhZGFwdGVyLT5jbWRfc2VudCAmJiAhYXRvbWljX3JlYWQoJmFkYXB0ZXItPnR4X2h3X3Bl
bmRpbmcpICYmDQo+IA0KPiBIb3cgaXMgdGhpcyBkaWZmZXJlbnQgZnJvbSB0aGUgZm9sbG93aW5n
Pw0KPiANCj4gaHR0cHM6Ly9wYXRjaHdvcmsua2VybmVsLm9yZy9wYXRjaC85Mzg5NDg1Lw0KPiAN
Cj4gQW5kIHBhcml0dWNsYXJseSwgdGhleSBjb25mbGljdCBvbiB0aGlzIGxpbmUsIHNvIHlvdSBu
ZWVkIHRvIHJlc29sdmUgdGhhdA0KPiBzb21laG93Li4uDQo+IA0KPiBBbmQgaWYgdGhlIGxpbmtl
ZCBwYXRjaCBzZXJ2ZXMgdGhlIHNhbWUgcHVycG9zZSwgdGhlbiBJJ2QgcmF0aGVyIHRha2UgaXQs
IHNpbmNlDQo+IGl0J3MgbXVjaCBzaW1wbGVyLg0KPiANCj4gQnJpYW4NCj4gDQoNClRoaXMgcGF0
Y2ggaXMgYW4gZW5oYW5jZWQgdmVyc2lvbiBjb21wYXJlZCB3aXRoIGh0dHBzOi8vcGF0Y2h3b3Jr
Lmtlcm5lbC5vcmcvcGF0Y2gvOTM4OTQ4NS8gLCANCk13aWZpZXggcGNpZSB0cnkgdG8gImFnZ3Jl
Z2F0ZSIgdHggcmluZyBidWZmZXJzLCBiZWZvcmUgbm90aWZ5IGZpcm13YXJlIGRhdGEgcmVhZHku
DQpkYXRhX3NlbnQgd2lsbCBvbmx5IGJlIHNldCB0cnVlIHdoZW4gcGNpZSBhZ2dyZWdhdGlvbiBp
cyBkb25lLg0KRHVyaW5nIHRoZSAicGNpZSBhZ2dyZWdhdGlvbiIgc3RhZ2UsIGRhdGFfc2VudCBp
cyBub3Qgc2V0LCBkcml2ZXIgc3RpbGwgYmUgYWJsZSB0byBkb3dubG9hZCBzbGVlcCBjb25maXJt
IGluIGFub3RoZXIgdGhyZWFkLCANCkluIHRoaXMgY2FzZSwgd2Ugd2lsbCBzdGlsbCBtZWV0IGtl
cm5lbCBjcmFzaCBjYXVzZWQgYnkgY29uY3VycmVudCBleGVjdXRpb24gYmV0d2VlbiBQTSBoYW5k
c2hha2UgYW5kIHByb2Nlc3NpbmcgdHggZG9uZSBpbnRlcnJ1cHQuIA0KdHhfaHdfcGVuZGluZyB3
aWxsIGJlIGEgYmV0dGVyIHNvbHV0aW9uIHRvIG1hdGNoIHRoaXMgY2FzZS4gDQoNCj4gPiAgCSAg
ICAhYWRhcHRlci0+Y3Vycl9jbWQgJiYgIUlTX0NBUkRfUlhfUkNWRChhZGFwdGVyKSkNCj4gPiAg
CQltd2lmaWV4X2RubGRfc2xlZXBfY29uZmlybV9jbWQoYWRhcHRlcik7DQo+ID4gIAllbHNlDQo+
ID4gIAkJbXdpZmlleF9kYmcoYWRhcHRlciwgQ01ELA0KPiA+ICAJCQkgICAgImNtZDogRGVsYXkg
U2xlZXAgQ29uZmlybSAoJXMlcyVzJXMpXG4iLA0KPiA+ICAJCQkgICAgKGFkYXB0ZXItPmNtZF9z
ZW50KSA/ICJEIiA6ICIiLA0KPiA+IC0JCQkgICAgKGFkYXB0ZXItPmRhdGFfc2VudCkgPyAiVCIg
OiAiIiwNCj4gPiArCQkJICAgIGF0b21pY19yZWFkKCZhZGFwdGVyLT50eF9od19wZW5kaW5nKSA/
ICJUIiA6ICIiLA0KPiA+ICAJCQkgICAgKGFkYXB0ZXItPmN1cnJfY21kKSA/ICJDIiA6ICIiLA0K
PiA+ICAJCQkgICAgKElTX0NBUkRfUlhfUkNWRChhZGFwdGVyKSkgPyAiUiIgOiAiIik7ICB9IGRp
ZmYgLS1naXQNCj4gPiBhL2RyaXZlcnMvbmV0L3dpcmVsZXNzL21hcnZlbGwvbXdpZmlleC9pbml0
LmMNCj4gPiBiL2RyaXZlcnMvbmV0L3dpcmVsZXNzL21hcnZlbGwvbXdpZmlleC9pbml0LmMNCj4g
PiBpbmRleCA4MjgzOWQ5Li5iMzZjYjNmIDEwMDY0NA0KPiA+IC0tLSBhL2RyaXZlcnMvbmV0L3dp
cmVsZXNzL21hcnZlbGwvbXdpZmlleC9pbml0LmMNCj4gPiArKysgYi9kcml2ZXJzL25ldC93aXJl
bGVzcy9tYXJ2ZWxsL213aWZpZXgvaW5pdC5jDQo+ID4gQEAgLTI3MCw2ICsyNzAsNyBAQCBzdGF0
aWMgdm9pZCBtd2lmaWV4X2luaXRfYWRhcHRlcihzdHJ1Y3QNCj4gbXdpZmlleF9hZGFwdGVyICph
ZGFwdGVyKQ0KPiA+ICAJYWRhcHRlci0+YWRob2NfMTFuX2VuYWJsZWQgPSBmYWxzZTsNCj4gPg0K
PiA+ICAJbXdpZmlleF93bW1faW5pdChhZGFwdGVyKTsNCj4gPiArCWF0b21pY19zZXQoJmFkYXB0
ZXItPnR4X2h3X3BlbmRpbmcsIDApOw0KPiA+DQo+ID4gIAlzbGVlcF9jZm1fYnVmID0gKHN0cnVj
dCBtd2lmaWV4X29wdF9zbGVlcF9jb25maXJtICopDQo+ID4gIAkJCQkJYWRhcHRlci0+c2xlZXBf
Y2ZtLT5kYXRhOw0KPiA+IGRpZmYgLS1naXQgYS9kcml2ZXJzL25ldC93aXJlbGVzcy9tYXJ2ZWxs
L213aWZpZXgvbWFpbi5oDQo+ID4gYi9kcml2ZXJzL25ldC93aXJlbGVzcy9tYXJ2ZWxsL213aWZp
ZXgvbWFpbi5oDQo+ID4gaW5kZXggZDYxZmUzYS4uN2Y2N2YyMyAxMDA2NDQNCj4gPiAtLS0gYS9k
cml2ZXJzL25ldC93aXJlbGVzcy9tYXJ2ZWxsL213aWZpZXgvbWFpbi5oDQo+ID4gKysrIGIvZHJp
dmVycy9uZXQvd2lyZWxlc3MvbWFydmVsbC9td2lmaWV4L21haW4uaA0KPiA+IEBAIC04NTcsNiAr
ODU3LDcgQEAgc3RydWN0IG13aWZpZXhfYWRhcHRlciB7DQo+ID4gIAlhdG9taWNfdCByeF9wZW5k
aW5nOw0KPiA+ICAJYXRvbWljX3QgdHhfcGVuZGluZzsNCj4gPiAgCWF0b21pY190IGNtZF9wZW5k
aW5nOw0KPiA+ICsJYXRvbWljX3QgdHhfaHdfcGVuZGluZzsNCj4gPiAgCXN0cnVjdCB3b3JrcXVl
dWVfc3RydWN0ICp3b3JrcXVldWU7DQo+ID4gIAlzdHJ1Y3Qgd29ya19zdHJ1Y3QgbWFpbl93b3Jr
Ow0KPiA+ICAJc3RydWN0IHdvcmtxdWV1ZV9zdHJ1Y3QgKnJ4X3dvcmtxdWV1ZTsgZGlmZiAtLWdp
dA0KPiA+IGEvZHJpdmVycy9uZXQvd2lyZWxlc3MvbWFydmVsbC9td2lmaWV4L3BjaWUuYw0KPiA+
IGIvZHJpdmVycy9uZXQvd2lyZWxlc3MvbWFydmVsbC9td2lmaWV4L3BjaWUuYw0KPiA+IGluZGV4
IDA2M2M3MDcuLjRhYTVkOTEgMTAwNjQ0DQo+ID4gLS0tIGEvZHJpdmVycy9uZXQvd2lyZWxlc3Mv
bWFydmVsbC9td2lmaWV4L3BjaWUuYw0KPiA+ICsrKyBiL2RyaXZlcnMvbmV0L3dpcmVsZXNzL21h
cnZlbGwvbXdpZmlleC9wY2llLmMNCj4gPiBAQCAtNTE2LDYgKzUxNiw3IEBAIHN0YXRpYyBpbnQg
bXdpZmlleF9wY2llX2VuYWJsZV9ob3N0X2ludChzdHJ1Y3QNCj4gbXdpZmlleF9hZGFwdGVyICph
ZGFwdGVyKQ0KPiA+ICAJCX0NCj4gPiAgCX0NCj4gPg0KPiA+ICsJYXRvbWljX3NldCgmYWRhcHRl
ci0+dHhfaHdfcGVuZGluZywgMCk7DQo+ID4gIAlyZXR1cm4gMDsNCj4gPiAgfQ0KPiA+DQo+ID4g
QEAgLTY4OSw2ICs2OTAsNyBAQCBzdGF0aWMgdm9pZCBtd2lmaWV4X2NsZWFudXBfdHhxX3Jpbmco
c3RydWN0DQo+IG13aWZpZXhfYWRhcHRlciAqYWRhcHRlcikNCj4gPiAgCQljYXJkLT50eF9idWZf
bGlzdFtpXSA9IE5VTEw7DQo+ID4gIAl9DQo+ID4NCj4gPiArCWF0b21pY19zZXQoJmFkYXB0ZXIt
PnR4X2h3X3BlbmRpbmcsIDApOw0KPiA+ICAJcmV0dXJuOw0KPiA+ICB9DQo+ID4NCj4gPiBAQCAt
MTEyNiw2ICsxMTI4LDcgQEAgc3RhdGljIGludCBtd2lmaWV4X3BjaWVfc2VuZF9kYXRhX2NvbXBs
ZXRlKHN0cnVjdA0KPiBtd2lmaWV4X2FkYXB0ZXIgKmFkYXB0ZXIpDQo+ID4gIAkJCQkJCQkgICAg
LTEpOw0KPiA+ICAJCQllbHNlDQo+ID4gIAkJCQltd2lmaWV4X3dyaXRlX2RhdGFfY29tcGxldGUo
YWRhcHRlciwgc2tiLCAwLCAwKTsNCj4gPiArCQkJYXRvbWljX2RlYygmYWRhcHRlci0+dHhfaHdf
cGVuZGluZyk7DQo+ID4gIAkJfQ0KPiA+DQo+ID4gIAkJY2FyZC0+dHhfYnVmX2xpc3Rbd3Jkb25l
aWR4XSA9IE5VTEw7IEBAIC0xMjE4LDYgKzEyMjEsNyBAQA0KPiA+IG13aWZpZXhfcGNpZV9zZW5k
X2RhdGEoc3RydWN0IG13aWZpZXhfYWRhcHRlciAqYWRhcHRlciwgc3RydWN0IHNrX2J1ZmYNCj4g
KnNrYiwNCj4gPiAgCQl3cmluZHggPSAoY2FyZC0+dHhiZF93cnB0ciAmIHJlZy0+dHhfbWFzaykg
Pj4gcmVnLT50eF9zdGFydF9wdHI7DQo+ID4gIAkJYnVmX3BhID0gTVdJRklFWF9TS0JfRE1BX0FE
RFIoc2tiKTsNCj4gPiAgCQljYXJkLT50eF9idWZfbGlzdFt3cmluZHhdID0gc2tiOw0KPiA+ICsJ
CWF0b21pY19pbmMoJmFkYXB0ZXItPnR4X2h3X3BlbmRpbmcpOw0KPiA+DQo+ID4gIAkJaWYgKHJl
Zy0+cGZ1X2VuYWJsZWQpIHsNCj4gPiAgCQkJZGVzYzIgPSBjYXJkLT50eGJkX3Jpbmdbd3JpbmR4
XTsNCj4gPiBAQCAtMTI5NSw2ICsxMjk5LDcgQEAgbXdpZmlleF9wY2llX3NlbmRfZGF0YShzdHJ1
Y3QgbXdpZmlleF9hZGFwdGVyDQo+ID4gKmFkYXB0ZXIsIHN0cnVjdCBza19idWZmICpza2IsDQo+
ID4gIGRvbmVfdW5tYXA6DQo+ID4gIAltd2lmaWV4X3VubWFwX3BjaV9tZW1vcnkoYWRhcHRlciwg
c2tiLCBQQ0lfRE1BX1RPREVWSUNFKTsNCj4gPiAgCWNhcmQtPnR4X2J1Zl9saXN0W3dyaW5keF0g
PSBOVUxMOw0KPiA+ICsJYXRvbWljX2RlYygmYWRhcHRlci0+dHhfaHdfcGVuZGluZyk7DQo+ID4g
IAlpZiAocmVnLT5wZnVfZW5hYmxlZCkNCj4gPiAgCQltZW1zZXQoZGVzYzIsIDAsIHNpemVvZigq
ZGVzYzIpKTsNCj4gPiAgCWVsc2UNCj4gPiAtLQ0KPiA+IDEuOC4xLjQNCj4gPg0KDQpCZXN0IFJl
Z2FyZHMsDQpYaW5taW5nDQoNCg==
^ permalink raw reply
* Re: [PATCH v2] rtl8xxxu: Fix for agressive power saving by rtl8723bu wireless IC
From: Barry Day @ 2016-11-01 9:54 UTC (permalink / raw)
To: John Heenan; +Cc: Jes Sorensen, Kalle Valo, linux-wireless
In-Reply-To: <20161101072447.GA21575@cube>
On Tue, Nov 01, 2016 at 05:24:47PM +1000, John Heenan wrote:
> 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.
>
> Signed-off-by: John Heenan <john@zgus.com>
> ---
> drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 16 ++++++++++++----
> 1 file changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> index 04141e5..ab2f2ef 100644
> --- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> +++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> @@ -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;
> --
> 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.
^ permalink raw reply
* "silent" TL-WDN4200 (RT593 usb) devices
From: Jonas Gorski @ 2016-11-01 9:33 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
Cc: Stanislaw Gruszka, Helmut Schaa, Gabor Juhos
[-- Attachment #1: Type: text/plain, Size: 916 bytes --]
Hi,
I have a bunch of rt5393 based TL-WDN4200 devices of which only one is
working as expected, and the rest fail to tx with rt2800-usb, using
latest master of lede (but also older verions). They are working fine
with the windows drivers.
Symptoms are:
1. Scanning works fine (so RX seems to work)
2. Trying to assoc in STA mode will time out
3. In AP mode it won't show up on scan by other devices
I tried listening with tcpdump (from an ath9k card, with encryption
disabled), but didn't see anything on the air from the non-working
sticks.
I also tried comparing the rt3593 ralink driver with rt2x00, and
couldn't find any differences on a first glance, so I'm a bit stumped.
Any pointers what else I can try/test would be good.
For comparison, I attached the eeprom contents from a working and a
non working stick, in hope it will help. If needed, I can try to
create a usb trace on windows.
Regards
Jonas
[-- Attachment #2: nonworking.txt --]
[-- Type: text/plain, Size: 2304 bytes --]
0: 0x3573 0x0100 0xdee8 0x2027
4: 0xafd4 0x0000 0x0000 0x0000
8: 0xffff 0xffff 0xffff 0xffff
12: 0xffff 0xffff 0xffff 0x0000
16: 0x0000 0x0000 0x0000 0x0000
20: 0x0000 0x0000 0x0000 0x0000
24: 0x0000 0x0000 0x0d33 0x008e
28: 0x0033 0x0000 0x0000 0x0601
32: 0xffff 0x0116 0x0124 0x5555
36: 0xbbd9 0xffbb 0x0a0a 0x0808
40: 0x0000 0x0000 0x0000 0x0000
44: 0x0000 0x0000 0x0000 0x0000
48: 0x0d0d 0x0e0d 0x0e0e 0x0f0e
52: 0x100f 0x1010 0x1010 0x0d0d
56: 0x0e0d 0x0e0e 0x0e0e 0x0f0f
60: 0x0f0f 0x0e0e 0x0d0d 0x0e0e
64: 0x0f0f 0x1010 0x1111 0x1212
68: 0x1111 0xb8c9 0x88a1 0x6871
72: 0x4555 0x0130 0x0500 0x0d0d
76: 0x0c0d 0x0c0c 0x0b0b 0x0b0b
80: 0x0a0a 0x0607 0x0606 0x0506
84: 0x0505 0x0405 0x0404 0x0303
88: 0x0303 0x0202 0x0101 0x0101
92: 0x0001 0x0000 0x0000 0x0000
96: 0x0000 0x0000 0x0000 0x0000
100: 0x0000 0x0707 0x0707 0x0707
104: 0x0707 0x0707 0x0707 0x0606
108: 0x0606 0x0606 0x0606 0x0606
112: 0x0506 0x0505 0x0505 0x0505
116: 0x0505 0x0505 0x0005 0x0000
120: 0x0000 0x0000 0x0000 0x0000
124: 0x0000 0x0000 0x0000 0x0808
128: 0x0808 0x0808 0x0808 0x0808
132: 0x0808 0x0808 0x0808 0x0808
136: 0x0808 0x0808 0x0808 0x0808
140: 0x0808 0x0808 0x0808 0x0808
144: 0x0008 0x0000 0x0000 0x0000
148: 0x0000 0x0000 0x0000 0x0000
152: 0x0000 0x0000 0xb8c9 0x88a2
156: 0x6571 0x4355 0x0135 0x0000
160: 0xac66 0x0668 0x68ac 0x8ac6
164: 0xac66 0x0668 0x68ac 0x0006
168: 0xac00 0x0668 0x68ac 0x8ac6
172: 0xac66 0x0668 0x68ac 0x0006
176: 0xac00 0x0668 0x68ac 0x8ac6
180: 0xac66 0x0668 0x68ac 0x0006
184: 0xac00 0x0668 0x68ac 0x8ac6
188: 0xac66 0x0668 0x68ac 0x0006
192: 0x0000 0x0000 0x0000 0x0000
196: 0x0000 0x0000 0x0000 0xffff
200: 0xffff 0xffff 0xffff 0xffff
204: 0xffff 0xffff 0xffff 0xffff
208: 0xffff 0xffff 0xffff 0xffff
212: 0xffff 0xffff 0xffff 0xffff
216: 0xffff 0xffff 0xffff 0xffff
220: 0xffff 0xffff 0xffff 0xffff
224: 0xffff 0xffff 0xffff 0xffff
228: 0xffff 0xffff 0xffff 0xffff
232: 0xffff 0xffff 0xffff 0xffff
236: 0xffff 0xffff 0xffff 0xffff
240: 0xffff 0xffff 0xffff 0xffff
244: 0xffff 0xffff 0xffff 0xffff
248: 0xffff 0xffff 0xffff 0xffff
252: 0xffff 0xffff 0xffff 0xffff
[-- Attachment #3: working.txt --]
[-- Type: text/plain, Size: 2304 bytes --]
0: 0x3573 0x0100 0xdee8 0x1d27
4: 0x1137 0x0000 0x0000 0x0000
8: 0xffff 0xffff 0xffff 0xffff
12: 0xffff 0xffff 0xffff 0x0000
16: 0x0000 0x0000 0x0000 0x0000
20: 0x0000 0x0000 0x0000 0x0000
24: 0x0000 0x0000 0x0d33 0x008e
28: 0x0033 0x0000 0x0000 0x0601
32: 0xffff 0x0116 0x0128 0x5555
36: 0xbbd9 0xffbb 0x0a0a 0x0808
40: 0x0000 0x0000 0x0000 0x0000
44: 0x0000 0x0000 0x0000 0x0000
48: 0x0c0c 0x0d0c 0x0d0d 0x0e0d
52: 0x0f0e 0x0f0f 0x0f0f 0x0d0d
56: 0x0e0e 0x0f0f 0x0f0f 0x1010
60: 0x1010 0x0f0f 0x0f0f 0x1010
64: 0x1111 0x1212 0x1313 0x1314
68: 0x1213 0xb8c9 0x88a1 0x6871
72: 0x4555 0x0130 0x0500 0x0d0d
76: 0x0c0d 0x0c0c 0x0b0b 0x0a0b
80: 0x0a0a 0x0606 0x0506 0x0505
84: 0x0404 0x0404 0x0303 0x0203
88: 0x0202 0x0101 0x0000 0x0000
92: 0x0000 0x0000 0x0000 0x0000
96: 0x0000 0x0000 0x0000 0x0000
100: 0x0000 0x0404 0x0404 0x0404
104: 0x0404 0x0404 0x0404 0x0303
108: 0x0303 0x0303 0x0303 0x0303
112: 0x0303 0x0303 0x0303 0x0303
116: 0x0303 0x0303 0x0003 0x0000
120: 0x0000 0x0000 0x0000 0x0000
124: 0x0000 0x0000 0x0000 0x0505
128: 0x0505 0x0505 0x0505 0x0505
132: 0x0505 0x0606 0x0606 0x0606
136: 0x0606 0x0606 0x0706 0x0707
140: 0x0707 0x0707 0x0707 0x0707
144: 0x0007 0x0000 0x0000 0x0000
148: 0x0000 0x0000 0x0000 0x0000
152: 0x0000 0x0000 0xb8c9 0x88a2
156: 0x6571 0x4355 0x0135 0x0000
160: 0xac66 0x0668 0x68ac 0x8ac6
164: 0xac66 0x0668 0x68ac 0x0006
168: 0xac00 0x0668 0x68ac 0x8ac6
172: 0xac66 0x0668 0x68ac 0x0006
176: 0xac00 0x0668 0x68ac 0x8ac6
180: 0xac66 0x0668 0x68ac 0x0006
184: 0xac00 0x0668 0x68ac 0x8ac6
188: 0xac66 0x0668 0x68ac 0x0006
192: 0x0000 0x0000 0x0000 0x0000
196: 0x0000 0x0000 0x0000 0xffff
200: 0xffff 0xffff 0xffff 0xffff
204: 0xffff 0xffff 0xffff 0xffff
208: 0xffff 0xffff 0xffff 0xffff
212: 0xffff 0xffff 0xffff 0xffff
216: 0xffff 0xffff 0xffff 0xffff
220: 0xffff 0xffff 0xffff 0xffff
224: 0xffff 0xffff 0xffff 0xffff
228: 0xffff 0xffff 0xffff 0xffff
232: 0xffff 0xffff 0xffff 0xffff
236: 0xffff 0xffff 0xffff 0xffff
240: 0xffff 0xffff 0xffff 0xffff
244: 0xffff 0xffff 0xffff 0xffff
248: 0xffff 0xffff 0xffff 0xffff
252: 0xffff 0xffff 0xffff 0xffff
^ permalink raw reply
* Re: [PATCH v2] rtl8xxxu: Fix for agressive power saving by rtl8723bu wireless IC
From: Rafał Miłecki @ 2016-11-01 7:31 UTC (permalink / raw)
To: John Heenan
Cc: Jes Sorensen, Kalle Valo, linux-wireless@vger.kernel.org,
Network Development, Linux Kernel Mailing List
In-Reply-To: <20161101072447.GA21575@cube>
On 1 November 2016 at 08:24, John Heenan <john@zgus.com> wrote:
> @@ -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 "(" ;)
> @@ -6080,9 +6086,11 @@ static int rtl8xxxu_probe(struct usb_interface *in=
terface,
> goto 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
^ permalink raw reply
* [PATCH v2] rtl8xxxu: Fix for agressive power saving by rtl8723bu wireless IC
From: John Heenan @ 2016-11-01 7:24 UTC (permalink / raw)
To: Jes Sorensen, Kalle Valo, linux-wireless, netdev; +Cc: linux-kernel
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.
Signed-off-by: John Heenan <john@zgus.com>
---
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
index 04141e5..ab2f2ef 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -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;
--
2.10.1
^ permalink raw reply related
* Re: [PATCH] rtl8xxxu: Fix for agressive power saving by rtl8723bu wireless IC
From: John Heenan @ 2016-11-01 7:24 UTC (permalink / raw)
To: Jes Sorensen; +Cc: Kalle Valo, linux-wireless, netdev, linux-kernel
In-Reply-To: <CAAye0QNtcb28q1HY-xAr=bQ0s_nEQuv1TM+Ax5i99Eds7xOb=Q@mail.gmail.com>
I have a prepared another patch that is not USB VID/PID dependent for
rtl8723bu devices. It is more elegant. I will send it after this
email.
If I have more patches is it preferable I just put them on github only
and notify a link address until there might be some resolution?
What I meant below about not finding a matching function is that I
cannot find matching actions to take on any function calls in
rtl8xxxu_stop as for rtl8xxxu_start.
The function that is called later and potentially more than once for
rtl8723bu devices is rtl8xxxu_init_device. There is no corresponding
rtl8xxxu_deinit_device function.
enable_rf is called in rtl8xxxu_start, not in the delayed call to
rtl8xxxu_init_device. The corresponding disable_rf is called in
rtl8xxxu_stop. So no matching issue here. However please see below for
another potential issue.
power_on is called in rtl8xxxu_init_device. power_off is called in
rtl8xxxu_disconnect. Does not appear to be an issue if calling
power_on has no real effect if already on.
The following should be looked at though. For all devices enable_rf is
only called once. For the proposed patch the first call to
rtl8xxxu_init_device is called after the single call to enable_rf for
rtl8723bu devices. Without the patch enable_rf is called after
rtl8xxxu_init_device for all devices
Perhaps enable_rf just configures RF modes to start up when RF is
powered on or if called after power_on then enters requested RF modes.
So I cannot see appropriate additional matching action to take.
Below is some background for anyone interested
rtl8xxxu_start and rtl8xxxu_stop are assigned to rtl8xxxu_ops.
rtl8xxxu_probe assigns rtl8xxxu_ops to its driver layer with
ieee80211_register_hw.
rtl8xxxu_disconnect unassigns rtl8xxxu_ops from its driver layer with
ieee80211_unregister_hw.
rtl8xxxu_probe and rtl8xxxu_disconnect are USB driver functions
John Heenan
On 1 November 2016 at 08:15, John Heenan <john@zgus.com> wrote:
> On 1 November 2016 at 07:25, Jes Sorensen <Jes.Sorensen@redhat.com> wrote:
>> John Heenan <john@zgus.com> writes:
>
>>
>>> @@ -5776,9 +5781,17 @@ static int rtl8xxxu_start(struct ieee80211_hw *hw)
>>> struct rtl8xxxu_tx_urb *tx_urb;
>>> unsigned long flags;
>>> int ret, i;
>>> + struct usb_device_descriptor *udesc = &priv->udev->descriptor;
>>>
>>> ret = 0;
>>>
>>> + if(udesc->idVendor == USB_VENDOR_ID_REALTEK
>>> + && udesc->idProduct == USB_PRODUCT_ID_RTL8723BU) {
>>> + ret = rtl8xxxu_init_device(hw);
>>> + if (ret)
>>> + goto error_out;
>>> + }
>>> +
>>
>> As mentioned previously, if this is to be changed here, it has to be
>> matched in the _stop section too.
>
> I looked at this and could not find a matching function. I will have a
> look again.
>
^ permalink raw reply
* Re: pull-request: wireless-drivers-next 2016-10-30
From: Kalle Valo @ 2016-11-01 5:25 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20161031.153809.270896325416087100.davem@davemloft.net>
David Miller <davem@davemloft.net> writes:
> From: Kalle Valo <kvalo@codeaurora.org>
> Date: Sun, 30 Oct 2016 11:20:46 +0200
>
>> few fixes for 4.9. I tagged this on the plane over a slow mosh
>> connection while travelling to Plumbers so I might have done something
>> wrong, please check more carefully than usually. For example I had to
>> redo the signed tag because of some whitespace damage.
>>
>> Please let me know if there are any problems.
>
> Your subject line says "-next" but clearly these are bug fixes for 'net'
> so that's where I pulled this into.
Correct, that -next was a mistake. Sorry about that.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] rtl8xxxu: Fix for agressive power saving by rtl8723bu wireless IC
From: Joe Perches @ 2016-11-01 3:01 UTC (permalink / raw)
To: John Heenan, Jes Sorensen
Cc: Kalle Valo, linux-wireless, netdev, linux-kernel
In-Reply-To: <CAAye0QNtcb28q1HY-xAr=bQ0s_nEQuv1TM+Ax5i99Eds7xOb=Q@mail.gmail.com>
On Tue, 2016-11-01 at 08:15 +1000, John Heenan wrote:
> > On 1 November 2016 at 07:25, Jes Sorensen <Jes.Sorensen@redhat.com> wrote:
> > > > John Heenan <john@zgus.com> writes:
> > > 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.
> > >
> > > The rtl8723bu device has a unique USB VID and PID. This is taken
> > > advantage of for the patch to ensure only rtl8723bu devices 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.
> > >
> > > > > > Signed-off-by: John Heenan <john@zgus.com>
> > > ---
> > > .../net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 24 ++++++++++++++++++----
> > > 1 file changed, 20 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> > > index 04141e5..f36e674 100644
> > > --- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> > > +++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> > > @@ -79,6 +79,8 @@ MODULE_PARM_DESC(dma_agg_pages, "Set DMA aggregation pages (range 1-127, 0 to di
> > > #define RTL8XXXU_TX_URB_LOW_WATER 25
> > > #define RTL8XXXU_TX_URB_HIGH_WATER 32
> > >
> > > +#define USB_PRODUCT_ID_RTL8723BU 0xb720
> > > +
> >
> > Absolutely not! You have no guarantee that this is the only id used for
> > 8723bu devices, and adding a #define for each is not going to happen.
>
> Thanks for you reply.
>
> I have no problem with that. However the patch does get the point
> across in a minimalist and efficient way of what the issues are.
>
> Currently there is no property available to determine the information required.
>
> >
> > > static int rtl8xxxu_submit_rx_urb(struct rtl8xxxu_priv *priv,
> > > struct rtl8xxxu_rx_urb *rx_urb);
> > >
> > > @@ -3892,6 +3894,7 @@ static int rtl8xxxu_init_device(struct ieee80211_hw *hw)
> > > u8 val8;
> > > u16 val16;
> > > u32 val32;
> > > + struct usb_device_descriptor *udesc = &priv->udev->descriptor;
> >
> > Indentaiton
>
> OK. Missed that one.
>
> >
> > > /* Check if MAC is already powered on */
> > > val8 = rtl8xxxu_read8(priv, REG_CR);
> > > @@ -3900,7 +3903,9 @@ 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
> > > + || (udesc->idVendor == USB_VENDOR_ID_REALTEK
> > > + && udesc->idProduct == USB_PRODUCT_ID_RTL8723BU))
> > > macpower = false;
> > > else
> > > macpower = true;
> >
> > Please respect proper kernel coding style!
>
> I don't know what you mean. Your code has real tabs. My code has real
> tabs. The kernel style goes on about tabs being 8 spaces. So do you
> want: real tabs or real spaces?
>
> You said no lines over 80 columns long. This is what i have done.
Typical kernel style would be:
if (val == 0xea ||
(udesc->idVendor == USB_VENDOR_ID_REALTEK &&
udesc->idProduct == USB_PRODUCT_ID_RTL8723BU))
macpower = false;
else
macpower = true;
ie: logical continuations at EOL and indentation aligned to parentheses
using as many leading tabs as possible, then spaces where necessary
or maybe:
macpower = !(val == 0xea ||
(idesc->idVendor == USB_VENDOR_ID_REALTEK &&
udesc->idProduct == USB_PRODUCT_ID_RTL8723BU));
but the first one seems easier to read.
> > > @@ -6080,9 +6093,12 @@ static int rtl8xxxu_probe(struct usb_interface *interface,
> > > goto exit;
> > > }
> > >
> > > - ret = rtl8xxxu_init_device(hw);
> > > - if (ret)
> > > + if(!(id->idVendor == USB_VENDOR_ID_REALTEK
> > > + && id->idProduct == USB_PRODUCT_ID_RTL8723BU)) {
> > > + ret = rtl8xxxu_init_device(hw);
> > > + if (ret)
> > > goto exit;
> > > + }
> >
> > Again, this coding style abuse will never go into this driver,
>
> As above, what abuse? I am not being facetious. Just puzzled.
Same logical continuation and indentation alignment.
> Again have a nice day!
That's pleasant of you but Jen's rarely seems pleasant in return via
email. I trust he's more personable over a beer though. Perhaps one
day we'll all have one together.
^ permalink raw reply
* Re: [PATCH 02/12] mwifiex: check tx_hw_pending before downloading sleep confirm
From: Brian Norris @ 2016-11-01 0:14 UTC (permalink / raw)
To: Xinming Hu
Cc: Linux Wireless, Kalle Valo, Dmitry Torokhov, Amitkumar Karwar,
Cathy Luo, Shengzhen Li
In-Reply-To: <1477900940-10549-2-git-send-email-huxinming820@marvell.com>
On Mon, Oct 31, 2016 at 04:02:10PM +0800, Xinming Hu wrote:
> From: Shengzhen Li <szli@marvell.com>
>
> This patch will only allow downloading sleep confirm
> when no tx done interrupt is pending in the hardware.
>
> Signed-off-by: Cathy Luo <cluo@marvell.com>
> Signed-off-by: Shengzhen Li <szli@marvell.com>
>
> Change-Id: I6d6955b4a2de0ad791ca28f0f635d636a2c7e406
^^ Remove this
> ---
> drivers/net/wireless/marvell/mwifiex/cmdevt.c | 4 ++--
> drivers/net/wireless/marvell/mwifiex/init.c | 1 +
> drivers/net/wireless/marvell/mwifiex/main.h | 1 +
> drivers/net/wireless/marvell/mwifiex/pcie.c | 5 +++++
> 4 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/marvell/mwifiex/cmdevt.c b/drivers/net/wireless/marvell/mwifiex/cmdevt.c
> index 9075be5..25a7475 100644
> --- a/drivers/net/wireless/marvell/mwifiex/cmdevt.c
> +++ b/drivers/net/wireless/marvell/mwifiex/cmdevt.c
> @@ -1118,14 +1118,14 @@ mwifiex_cancel_pending_ioctl(struct mwifiex_adapter *adapter)
> void
> mwifiex_check_ps_cond(struct mwifiex_adapter *adapter)
> {
> - if (!adapter->cmd_sent &&
> + if (!adapter->cmd_sent && !atomic_read(&adapter->tx_hw_pending) &&
How is this different from the following?
https://patchwork.kernel.org/patch/9389485/
And parituclarly, they conflict on this line, so you need to resolve
that somehow...
And if the linked patch serves the same purpose, then I'd rather take
it, since it's much simpler.
Brian
> !adapter->curr_cmd && !IS_CARD_RX_RCVD(adapter))
> mwifiex_dnld_sleep_confirm_cmd(adapter);
> else
> mwifiex_dbg(adapter, CMD,
> "cmd: Delay Sleep Confirm (%s%s%s%s)\n",
> (adapter->cmd_sent) ? "D" : "",
> - (adapter->data_sent) ? "T" : "",
> + atomic_read(&adapter->tx_hw_pending) ? "T" : "",
> (adapter->curr_cmd) ? "C" : "",
> (IS_CARD_RX_RCVD(adapter)) ? "R" : "");
> }
> diff --git a/drivers/net/wireless/marvell/mwifiex/init.c b/drivers/net/wireless/marvell/mwifiex/init.c
> index 82839d9..b36cb3f 100644
> --- a/drivers/net/wireless/marvell/mwifiex/init.c
> +++ b/drivers/net/wireless/marvell/mwifiex/init.c
> @@ -270,6 +270,7 @@ static void mwifiex_init_adapter(struct mwifiex_adapter *adapter)
> adapter->adhoc_11n_enabled = false;
>
> mwifiex_wmm_init(adapter);
> + atomic_set(&adapter->tx_hw_pending, 0);
>
> sleep_cfm_buf = (struct mwifiex_opt_sleep_confirm *)
> adapter->sleep_cfm->data;
> diff --git a/drivers/net/wireless/marvell/mwifiex/main.h b/drivers/net/wireless/marvell/mwifiex/main.h
> index d61fe3a..7f67f23 100644
> --- a/drivers/net/wireless/marvell/mwifiex/main.h
> +++ b/drivers/net/wireless/marvell/mwifiex/main.h
> @@ -857,6 +857,7 @@ struct mwifiex_adapter {
> atomic_t rx_pending;
> atomic_t tx_pending;
> atomic_t cmd_pending;
> + atomic_t tx_hw_pending;
> struct workqueue_struct *workqueue;
> struct work_struct main_work;
> struct workqueue_struct *rx_workqueue;
> diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c
> index 063c707..4aa5d91 100644
> --- a/drivers/net/wireless/marvell/mwifiex/pcie.c
> +++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
> @@ -516,6 +516,7 @@ static int mwifiex_pcie_enable_host_int(struct mwifiex_adapter *adapter)
> }
> }
>
> + atomic_set(&adapter->tx_hw_pending, 0);
> return 0;
> }
>
> @@ -689,6 +690,7 @@ static void mwifiex_cleanup_txq_ring(struct mwifiex_adapter *adapter)
> card->tx_buf_list[i] = NULL;
> }
>
> + atomic_set(&adapter->tx_hw_pending, 0);
> return;
> }
>
> @@ -1126,6 +1128,7 @@ static int mwifiex_pcie_send_data_complete(struct mwifiex_adapter *adapter)
> -1);
> else
> mwifiex_write_data_complete(adapter, skb, 0, 0);
> + atomic_dec(&adapter->tx_hw_pending);
> }
>
> card->tx_buf_list[wrdoneidx] = NULL;
> @@ -1218,6 +1221,7 @@ mwifiex_pcie_send_data(struct mwifiex_adapter *adapter, struct sk_buff *skb,
> wrindx = (card->txbd_wrptr & reg->tx_mask) >> reg->tx_start_ptr;
> buf_pa = MWIFIEX_SKB_DMA_ADDR(skb);
> card->tx_buf_list[wrindx] = skb;
> + atomic_inc(&adapter->tx_hw_pending);
>
> if (reg->pfu_enabled) {
> desc2 = card->txbd_ring[wrindx];
> @@ -1295,6 +1299,7 @@ mwifiex_pcie_send_data(struct mwifiex_adapter *adapter, struct sk_buff *skb,
> done_unmap:
> mwifiex_unmap_pci_memory(adapter, skb, PCI_DMA_TODEVICE);
> card->tx_buf_list[wrindx] = NULL;
> + atomic_dec(&adapter->tx_hw_pending);
> if (reg->pfu_enabled)
> memset(desc2, 0, sizeof(*desc2));
> else
> --
> 1.8.1.4
>
^ permalink raw reply
* Re: [PATCH 01/12] mwifiex: fix power save issue when suspend
From: Brian Norris @ 2016-10-31 23:57 UTC (permalink / raw)
To: Xinming Hu
Cc: Linux Wireless, Kalle Valo, Dmitry Torokhov, Amitkumar Karwar,
Cathy Luo, Shengzhen Li
In-Reply-To: <1477900940-10549-1-git-send-email-huxinming820@marvell.com>
Hi,
On Mon, Oct 31, 2016 at 04:02:09PM +0800, Xinming Hu wrote:
> From: Shengzhen Li <szli@marvell.com>
>
> This patch fixes a corner case for "FROMLIST: mwifiex: fix corner case
Upstream patches don't normally get a 'FROMLIST' tag while you're
sending them to the mailing list :) That designation is used for Chrome
OS trees, so we know where to find the patch source. But the upstream
mailing list *is* the source.
> power save issue", main process will check the power save condition in
> PS_PRE_SLEEP status so the sleep handshake could continue.
>
> Signed-off-by: Cathy Luo <cluo@marvell.com>
> Signed-off-by: Shengzhen Li <szli@marvell.com>
> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
>
> BUG=chrome-os-partner:58164
> TEST=stress Wifi w/ power_save enabled
>
> Change-Id: I5a36d9eaeb7fe5faaccc533e0d1ba1f3253666dc
In the same vein: while I'm happy to have the BUG=, TEST=, and Gerrit
Change-ID for our Chrome OS tree, I don't think upstream reviewers
typically care about those. Please remove those from upstream
submissions like this.
(Same applies to the rest of this series. Also, consider running
scripts/checkpatch.pl. It will at least remind you about removing the
Gerrit Change-ID.)
> ---
> drivers/net/wireless/marvell/mwifiex/cmdevt.c | 3 ++-
> drivers/net/wireless/marvell/mwifiex/main.c | 5 +++++
> 2 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/marvell/mwifiex/cmdevt.c b/drivers/net/wireless/marvell/mwifiex/cmdevt.c
> index 5347728..9075be5 100644
> --- a/drivers/net/wireless/marvell/mwifiex/cmdevt.c
> +++ b/drivers/net/wireless/marvell/mwifiex/cmdevt.c
> @@ -1123,8 +1123,9 @@ mwifiex_check_ps_cond(struct mwifiex_adapter *adapter)
> mwifiex_dnld_sleep_confirm_cmd(adapter);
> else
> mwifiex_dbg(adapter, CMD,
> - "cmd: Delay Sleep Confirm (%s%s%s)\n",
> + "cmd: Delay Sleep Confirm (%s%s%s%s)\n",
> (adapter->cmd_sent) ? "D" : "",
> + (adapter->data_sent) ? "T" : "",
> (adapter->curr_cmd) ? "C" : "",
> (IS_CARD_RX_RCVD(adapter)) ? "R" : "");
> }
> diff --git a/drivers/net/wireless/marvell/mwifiex/main.c b/drivers/net/wireless/marvell/mwifiex/main.c
> index 2478ccd..f559ead 100644
> --- a/drivers/net/wireless/marvell/mwifiex/main.c
> +++ b/drivers/net/wireless/marvell/mwifiex/main.c
> @@ -308,6 +308,11 @@ process_start:
> /* We have tried to wakeup the card already */
> if (adapter->pm_wakeup_fw_try)
> break;
> + if (adapter->ps_state == PS_STATE_PRE_SLEEP) {
> + if (!adapter->cmd_sent && !adapter->curr_cmd)
The entire 'if' condition is unnecessary. That's all checked already
within mwifiex_check_ps_cond().
Brian
> + mwifiex_check_ps_cond(adapter);
> + }
> +
> if (adapter->ps_state != PS_STATE_AWAKE)
> break;
> if (adapter->tx_lock_flag) {
> --
> 1.8.1.4
>
^ permalink raw reply
* Re: [PATCH] rtl8xxxu: Fix for agressive power saving by rtl8723bu wireless IC
From: Barry Day @ 2016-10-31 23:47 UTC (permalink / raw)
To: Jes Sorensen; +Cc: John Heenan, Kalle Valo, linux-wireless
In-Reply-To: <wrfjoa20qgyt.fsf@redhat.com>
On Mon, Oct 31, 2016 at 06:41:30PM -0400, Jes Sorensen wrote:
> Barry Day <briselec@gmail.com> writes:
> > On Mon, Oct 31, 2016 at 05:25:12PM -0400, Jes Sorensen wrote:
> >> As mentioned previously, if this is to be changed here, it has to be
> >> matched in the _stop section too. It also has to be investigated exactly
> >> why this matters for 8723bu. It is possible this matters for other
> >> devices, but we need to find out exactly what causes this not moving a
> >> major block of init code around like this.
> >
> > I've tested this on the 8192e and 8192c. The same problems occurs with the
> > 8192e but not the 8192c. Stopping and restarting wpa_supplicant had
> > no affect on the 8192c ability to connect to an AP.
>
> Which version of the driver? I did push in some changes for 8192eu
> recently that fixed the issue with 8192eu driver reloading, and I would
> be interested in knowing if this didn't fix the problem for you?
>
> Second, could we please keep this on the linux-wireless list where it
> belongs. Everybody else doesn't necessarily want to receive a copy via
> netdev and linux-kernel
>
> Jes
The tests were done with the latest version of rtl8xxxu-devel. I haven't
noticed any occurence of the previous issue with the 8192eu.
^ permalink raw reply
* Re: [PATCH] rtl8xxxu: Fix for agressive power saving by rtl8723bu wireless IC
From: Jes Sorensen @ 2016-10-31 22:41 UTC (permalink / raw)
To: Barry Day; +Cc: John Heenan, Kalle Valo, linux-wireless
In-Reply-To: <20161031222045.GA14900@testbox>
Barry Day <briselec@gmail.com> writes:
> On Mon, Oct 31, 2016 at 05:25:12PM -0400, Jes Sorensen wrote:
>> As mentioned previously, if this is to be changed here, it has to be
>> matched in the _stop section too. It also has to be investigated exactly
>> why this matters for 8723bu. It is possible this matters for other
>> devices, but we need to find out exactly what causes this not moving a
>> major block of init code around like this.
>
> I've tested this on the 8192e and 8192c. The same problems occurs with the
> 8192e but not the 8192c. Stopping and restarting wpa_supplicant had
> no affect on the 8192c ability to connect to an AP.
Which version of the driver? I did push in some changes for 8192eu
recently that fixed the issue with 8192eu driver reloading, and I would
be interested in knowing if this didn't fix the problem for you?
Second, could we please keep this on the linux-wireless list where it
belongs. Everybody else doesn't necessarily want to receive a copy via
netdev and linux-kernel
Jes
^ permalink raw reply
* Re: [PATCH] rtl8xxxu: Fix for agressive power saving by rtl8723bu wireless IC
From: Barry Day @ 2016-10-31 22:20 UTC (permalink / raw)
To: Jes Sorensen
Cc: John Heenan, Kalle Valo, linux-wireless, netdev, linux-kernel
In-Reply-To: <wrfj1sywrz2f.fsf@redhat.com>
On Mon, Oct 31, 2016 at 05:25:12PM -0400, Jes Sorensen wrote:
> As mentioned previously, if this is to be changed here, it has to be
> matched in the _stop section too. It also has to be investigated exactly
> why this matters for 8723bu. It is possible this matters for other
> devices, but we need to find out exactly what causes this not moving a
> major block of init code around like this.
>
I've tested this on the 8192e and 8192c. The same problems occurs with the
8192e but not the 8192c. Stopping and restarting wpa_supplicant had
no affect on the 8192c ability to connect to an AP.
^ permalink raw reply
* Re: [PATCH] rtl8xxxu: Fix for agressive power saving by rtl8723bu wireless IC
From: John Heenan @ 2016-10-31 22:15 UTC (permalink / raw)
To: Jes Sorensen; +Cc: Kalle Valo, linux-wireless, netdev, linux-kernel
In-Reply-To: <wrfj1sywrz2f.fsf@redhat.com>
On 1 November 2016 at 07:25, Jes Sorensen <Jes.Sorensen@redhat.com> wrote:
> John Heenan <john@zgus.com> writes:
>> 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.
>>
>> The rtl8723bu device has a unique USB VID and PID. This is taken
>> advantage of for the patch to ensure only rtl8723bu devices 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.
>>
>> Signed-off-by: John Heenan <john@zgus.com>
>> ---
>> .../net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 24 ++++++++++++++++++----
>> 1 file changed, 20 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
>> index 04141e5..f36e674 100644
>> --- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
>> +++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
>> @@ -79,6 +79,8 @@ MODULE_PARM_DESC(dma_agg_pages, "Set DMA aggregation pages (range 1-127, 0 to di
>> #define RTL8XXXU_TX_URB_LOW_WATER 25
>> #define RTL8XXXU_TX_URB_HIGH_WATER 32
>>
>> +#define USB_PRODUCT_ID_RTL8723BU 0xb720
>> +
>
> Absolutely not! You have no guarantee that this is the only id used for
> 8723bu devices, and adding a #define for each is not going to happen.
Thanks for you reply.
I have no problem with that. However the patch does get the point
across in a minimalist and efficient way of what the issues are.
Currently there is no property available to determine the information required.
>
>> static int rtl8xxxu_submit_rx_urb(struct rtl8xxxu_priv *priv,
>> struct rtl8xxxu_rx_urb *rx_urb);
>>
>> @@ -3892,6 +3894,7 @@ static int rtl8xxxu_init_device(struct ieee80211_hw *hw)
>> u8 val8;
>> u16 val16;
>> u32 val32;
>> + struct usb_device_descriptor *udesc = &priv->udev->descriptor;
>
> Indentaiton
OK. Missed that one.
>
>> /* Check if MAC is already powered on */
>> val8 = rtl8xxxu_read8(priv, REG_CR);
>> @@ -3900,7 +3903,9 @@ 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
>> + || (udesc->idVendor == USB_VENDOR_ID_REALTEK
>> + && udesc->idProduct == USB_PRODUCT_ID_RTL8723BU))
>> macpower = false;
>> else
>> macpower = true;
>
> Please respect proper kernel coding style!
I don't know what you mean. Your code has real tabs. My code has real
tabs. The kernel style goes on about tabs being 8 spaces. So do you
want: real tabs or real spaces?
You said no lines over 80 columns long. This is what i have done.
>
>> @@ -5776,9 +5781,17 @@ static int rtl8xxxu_start(struct ieee80211_hw *hw)
>> struct rtl8xxxu_tx_urb *tx_urb;
>> unsigned long flags;
>> int ret, i;
>> + struct usb_device_descriptor *udesc = &priv->udev->descriptor;
>>
>> ret = 0;
>>
>> + if(udesc->idVendor == USB_VENDOR_ID_REALTEK
>> + && udesc->idProduct == USB_PRODUCT_ID_RTL8723BU) {
>> + ret = rtl8xxxu_init_device(hw);
>> + if (ret)
>> + goto error_out;
>> + }
>> +
>
> As mentioned previously, if this is to be changed here, it has to be
> matched in the _stop section too.
I looked at this and could not find a matching function. I will have a
look again.
> It also has to be investigated exactly
> why this matters for 8723bu. It is possible this matters for other
> devices, but we need to find out exactly what causes this not moving a
> major block of init code around like this.
I have no problem with this.
Given what you said yesterday we are not going to get definitive
answers. It is going to have to be trial and error while tracing
through what vendor code does.
Apparently as far as Realtek are concerned, we are nobodies and they
want nothing to do with us.
>
>> init_usb_anchor(&priv->rx_anchor);
>> init_usb_anchor(&priv->tx_anchor);
>> init_usb_anchor(&priv->int_anchor);
>> @@ -6080,9 +6093,12 @@ static int rtl8xxxu_probe(struct usb_interface *interface,
>> goto exit;
>> }
>>
>> - ret = rtl8xxxu_init_device(hw);
>> - if (ret)
>> + if(!(id->idVendor == USB_VENDOR_ID_REALTEK
>> + && id->idProduct == USB_PRODUCT_ID_RTL8723BU)) {
>> + ret = rtl8xxxu_init_device(hw);
>> + if (ret)
>> goto exit;
>> + }
>
> Again, this coding style abuse will never go into this driver,
As above, what abuse? I am not being facetious. Just puzzled.
> Jes
Again have a nice day!
John
^ permalink raw reply
* Re: [PATCH] rtl8xxxu: Fix for agressive power saving by rtl8723bu wireless IC
From: Jes Sorensen @ 2016-10-31 21:25 UTC (permalink / raw)
To: John Heenan; +Cc: Kalle Valo, linux-wireless, netdev, linux-kernel
In-Reply-To: <20161031183522.GA13315@cube>
John Heenan <john@zgus.com> writes:
> 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.
>
> The rtl8723bu device has a unique USB VID and PID. This is taken
> advantage of for the patch to ensure only rtl8723bu devices 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.
>
> Signed-off-by: John Heenan <john@zgus.com>
> ---
> .../net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 24 ++++++++++++++++++----
> 1 file changed, 20 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> index 04141e5..f36e674 100644
> --- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> +++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> @@ -79,6 +79,8 @@ MODULE_PARM_DESC(dma_agg_pages, "Set DMA aggregation pages (range 1-127, 0 to di
> #define RTL8XXXU_TX_URB_LOW_WATER 25
> #define RTL8XXXU_TX_URB_HIGH_WATER 32
>
> +#define USB_PRODUCT_ID_RTL8723BU 0xb720
> +
Absolutely not! You have no guarantee that this is the only id used for
8723bu devices, and adding a #define for each is not going to happen.
> static int rtl8xxxu_submit_rx_urb(struct rtl8xxxu_priv *priv,
> struct rtl8xxxu_rx_urb *rx_urb);
>
> @@ -3892,6 +3894,7 @@ static int rtl8xxxu_init_device(struct ieee80211_hw *hw)
> u8 val8;
> u16 val16;
> u32 val32;
> + struct usb_device_descriptor *udesc = &priv->udev->descriptor;
Indentaiton
> /* Check if MAC is already powered on */
> val8 = rtl8xxxu_read8(priv, REG_CR);
> @@ -3900,7 +3903,9 @@ 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
> + || (udesc->idVendor == USB_VENDOR_ID_REALTEK
> + && udesc->idProduct == USB_PRODUCT_ID_RTL8723BU))
> macpower = false;
> else
> macpower = true;
Please respect proper kernel coding style!
> @@ -5776,9 +5781,17 @@ static int rtl8xxxu_start(struct ieee80211_hw *hw)
> struct rtl8xxxu_tx_urb *tx_urb;
> unsigned long flags;
> int ret, i;
> + struct usb_device_descriptor *udesc = &priv->udev->descriptor;
>
> ret = 0;
>
> + if(udesc->idVendor == USB_VENDOR_ID_REALTEK
> + && udesc->idProduct == USB_PRODUCT_ID_RTL8723BU) {
> + ret = rtl8xxxu_init_device(hw);
> + if (ret)
> + goto error_out;
> + }
> +
As mentioned previously, if this is to be changed here, it has to be
matched in the _stop section too. It also has to be investigated exactly
why this matters for 8723bu. It is possible this matters for other
devices, but we need to find out exactly what causes this not moving a
major block of init code around like this.
> init_usb_anchor(&priv->rx_anchor);
> init_usb_anchor(&priv->tx_anchor);
> init_usb_anchor(&priv->int_anchor);
> @@ -6080,9 +6093,12 @@ static int rtl8xxxu_probe(struct usb_interface *interface,
> goto exit;
> }
>
> - ret = rtl8xxxu_init_device(hw);
> - if (ret)
> + if(!(id->idVendor == USB_VENDOR_ID_REALTEK
> + && id->idProduct == USB_PRODUCT_ID_RTL8723BU)) {
> + ret = rtl8xxxu_init_device(hw);
> + if (ret)
> goto exit;
> + }
Again, this coding style abuse will never go into this driver,
Jes
^ permalink raw reply
* Re: Backwards 11ac
From: James Cloos @ 2016-10-31 21:02 UTC (permalink / raw)
To: linux-wireless; +Cc: Sebastian Gottschall
In-Reply-To: <89dd7bd2-f6de-ea90-79ee-65d73d264522@dd-wrt.com>
>>>>> "SG" == Sebastian Gottschall <s.gottschall@dd-wrt.com> writes:
JC>> Thanks for that info, but there is still the issue that download
JC>> bandwidth is limited to around 6 Mbps whereas upload bandwidth is around
JC>> 50 Mbps
SG> thats unusual. i do not suffer from this issue with the latest driver
SG> code and also never had it. but as i said. the visual tx rate doesnt
SG> matter and isnt a reason for any issue here.
SG> its just a number
Those numbers above are actual throughput, tested via rsync/ssh. Even
adding in the rsync, ssh, tcp and ip overheads that is still worse than
the 11n-40 on the 2.4 band. And of course backwards.
Does anyone have any explanation for the backwards bandwidth or solution
for how to fix it?
-JimC
--
James Cloos <cloos@jhcloos.com> OpenPGP: 0x997A9F17ED7DAEA6
^ permalink raw reply
* Re: pull-request: wireless-drivers-next 2016-10-30
From: David Miller @ 2016-10-31 19:38 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <87insaw5u9.fsf@kamboji.qca.qualcomm.com>
From: Kalle Valo <kvalo@codeaurora.org>
Date: Sun, 30 Oct 2016 11:20:46 +0200
> few fixes for 4.9. I tagged this on the plane over a slow mosh
> connection while travelling to Plumbers so I might have done something
> wrong, please check more carefully than usually. For example I had to
> redo the signed tag because of some whitespace damage.
>
> Please let me know if there are any problems.
Your subject line says "-next" but clearly these are bug fixes for 'net'
so that's where I pulled this into.
Thanks.
^ permalink raw reply
* Re: Backwards 11ac
From: James Cloos @ 2016-10-31 18:35 UTC (permalink / raw)
To: linux-wireless; +Cc: Sebastian Gottschall
In-Reply-To: <f8094de7-1357-a9d0-fee3-b28e06dd3bc7@dd-wrt.com>
>>>>> "SG" == Sebastian Gottschall <s.gottschall@dd-wrt.com> writes:
SG> ath10k cannot show tx rates right now in a easy way. since tx rate
SG> handling is done by the cards own firmware and not by the mac80211
SG> wireless stack
Thanks for that info, but there is still the issue that download
bandwidth is limited to around 6 Mbps whereas upload bandwidth is around
50 Mbps.
-JimC
--
James Cloos <cloos@jhcloos.com> OpenPGP: 0x997A9F17ED7DAEA6
^ permalink raw reply
* [PATCH] rtl8xxxu: Fix for agressive power saving by rtl8723bu wireless IC
From: John Heenan @ 2016-10-31 18:35 UTC (permalink / raw)
To: Jes Sorensen, Kalle Valo, linux-wireless, netdev; +Cc: linux-kernel
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.
The rtl8723bu device has a unique USB VID and PID. This is taken
advantage of for the patch to ensure only rtl8723bu devices 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.
Signed-off-by: John Heenan <john@zgus.com>
---
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 24 ++++++++++++++++++----
1 file changed, 20 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
index 04141e5..f36e674 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -79,6 +79,8 @@ MODULE_PARM_DESC(dma_agg_pages, "Set DMA aggregation pages (range 1-127, 0 to di
#define RTL8XXXU_TX_URB_LOW_WATER 25
#define RTL8XXXU_TX_URB_HIGH_WATER 32
+#define USB_PRODUCT_ID_RTL8723BU 0xb720
+
static int rtl8xxxu_submit_rx_urb(struct rtl8xxxu_priv *priv,
struct rtl8xxxu_rx_urb *rx_urb);
@@ -3892,6 +3894,7 @@ static int rtl8xxxu_init_device(struct ieee80211_hw *hw)
u8 val8;
u16 val16;
u32 val32;
+ struct usb_device_descriptor *udesc = &priv->udev->descriptor;
/* Check if MAC is already powered on */
val8 = rtl8xxxu_read8(priv, REG_CR);
@@ -3900,7 +3903,9 @@ 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
+ || (udesc->idVendor == USB_VENDOR_ID_REALTEK
+ && udesc->idProduct == USB_PRODUCT_ID_RTL8723BU))
macpower = false;
else
macpower = true;
@@ -5776,9 +5781,17 @@ static int rtl8xxxu_start(struct ieee80211_hw *hw)
struct rtl8xxxu_tx_urb *tx_urb;
unsigned long flags;
int ret, i;
+ struct usb_device_descriptor *udesc = &priv->udev->descriptor;
ret = 0;
+ if(udesc->idVendor == USB_VENDOR_ID_REALTEK
+ && udesc->idProduct == USB_PRODUCT_ID_RTL8723BU) {
+ 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 +6093,12 @@ static int rtl8xxxu_probe(struct usb_interface *interface,
goto exit;
}
- ret = rtl8xxxu_init_device(hw);
- if (ret)
+ if(!(id->idVendor == USB_VENDOR_ID_REALTEK
+ && id->idProduct == USB_PRODUCT_ID_RTL8723BU)) {
+ 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;
@@ -6191,7 +6207,7 @@ static struct usb_device_id dev_table[] = {
/* Tested by Myckel Habets */
{USB_DEVICE_AND_INTERFACE_INFO(0x2357, 0x0109, 0xff, 0xff, 0xff),
.driver_info = (unsigned long)&rtl8192eu_fops},
-{USB_DEVICE_AND_INTERFACE_INFO(USB_VENDOR_ID_REALTEK, 0xb720, 0xff, 0xff, 0xff),
+{USB_DEVICE_AND_INTERFACE_INFO(USB_VENDOR_ID_REALTEK, USB_PRODUCT_ID_RTL8723BU, 0xff, 0xff, 0xff),
.driver_info = (unsigned long)&rtl8723bu_fops},
#ifdef CONFIG_RTL8XXXU_UNTESTED
/* Still supported by rtlwifi */
--
2.10.1
^ permalink raw reply related
* [PATCH RESEND v2] cfg80211: add bitrate for 20MHz MCS 9
From: Thomas Pedersen @ 2016-10-31 18:28 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Thomas Pedersen
Some drivers (ath10k) report MCS 9 @ 20MHz, which
technically isn't defined. To get more meaningful value
than 0 out of this however, just extrapolate a bitrate
from ratio of MCS 7 and 9 in channels where it is allowed.
Signed-off-by: Thomas Pedersen <twp@qca.qualcomm.com>
---
v2: add MCS 9 bitrate instead of capping at MCS 8
---
net/wireless/util.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/wireless/util.c b/net/wireless/util.c
index 32060f8..30fc320 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -1163,7 +1163,7 @@ static u32 cfg80211_calculate_bitrate_vht(struct rate_info *rate)
58500000,
65000000,
78000000,
- 0,
+ 86500000,
},
{ 13500000,
27000000,
--
2.10.0.297.gf6727b0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox