* rtl8xxxu: Testing with 0BDA:8178 (TP-link TL-WN821N with 8192cu)
From: Agustin Martin @ 2016-12-29 16:22 UTC (permalink / raw)
To: linux-wireless
Hi, Jes
Sorry if you already received this feedback, I could not find references.
I am trying a TP-LINK TL-WN821N wifi usb dongle with Realtek 8192cu
(lsusb returns: 0bda:8178 Realtek Semiconductor Corp. RTL8192CU
802.11n WLAN Adapter) and found the same problems described in
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1365844
When using kernel rtl8192cu driver, I can connect to wifi, but soon
the connection is dropped.
Since some time ago (2014) you asked for feedback in that bug and I
did not find further references I decided to try your rtl8xxxu driver.
All tests were carried out in a Debian GNU/Linux jessie box (current
stable release) with kernel 4.7.8 from Debian jessie backports (source
package linux_4.7.8-1~bpo8+1.dsc).
Changed kernel config to
## file: drivers/net/wireless/realtek/rtl8xxxu/Kconfig
##
CONFIG_RTL8XXXU=m
CONFIG_RTL8XXXU_UNTESTED=y
built a kernel (slooow here), installed it and added this line to a
file under /etc/modprobe.d
alias usb:v0BDAp8178d*dc*dsc*dp*icFFiscFFipFFin* rtl8xxxu
If the dongle is initially connected, system loads the rtl8xxxu module
instead of rtl8192cu when booting but seems not to initialize the
dongle, so I have no connection. However, if I disconnect the dongle
and reconnect it again with the system on, everything seems to work
well with no connection dropping. Only minimally tested, but apart
from the boot problem apparently much better than with the built-in
rtl8192cu kernel module.
Thanks for all the work you are putting into this driver
--
Agustin
^ permalink raw reply
* [PATCH] wlcore: fix spelling mistake in wl1271_warning
From: Colin King @ 2016-12-29 20:14 UTC (permalink / raw)
To: Kalle Valo, Shahar Patury, Guy Mishol, linux-wireless, netdev
Cc: linux-kernel
From: Colin Ian King <colin.king@canonical.com>
trivial fix to spelling mistake of function name in wl1271_warning,
should be dynamic_ps_timeout instead of dyanmic_ps_timeout.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/wireless/ti/wlcore/debugfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ti/wlcore/debugfs.c b/drivers/net/wireless/ti/wlcore/debugfs.c
index 7f672f6..58e148d 100644
--- a/drivers/net/wireless/ti/wlcore/debugfs.c
+++ b/drivers/net/wireless/ti/wlcore/debugfs.c
@@ -281,7 +281,7 @@ static ssize_t dynamic_ps_timeout_write(struct file *file,
}
if (value < 1 || value > 65535) {
- wl1271_warning("dyanmic_ps_timeout is not in valid range");
+ wl1271_warning("dynamic_ps_timeout is not in valid range");
return -ERANGE;
}
--
2.10.2
^ permalink raw reply related
* [PATCH] [media] gp8psk: fix spelling mistake: "firmare" -> "firmware"
From: Colin King @ 2016-12-29 20:29 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Larry Finger, Chaoming Li, Kalle Valo,
linux-media, linux-wireless, netdev
Cc: linux-kernel
From: Colin Ian King <colin.king@canonical.com>
trivial fix to spelling mistake in err message
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/media/usb/dvb-usb/gp8psk.c | 2 +-
drivers/net/wireless/realtek/rtlwifi/core.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/usb/dvb-usb/gp8psk.c b/drivers/media/usb/dvb-usb/gp8psk.c
index 2360e7e..26461f2 100644
--- a/drivers/media/usb/dvb-usb/gp8psk.c
+++ b/drivers/media/usb/dvb-usb/gp8psk.c
@@ -161,7 +161,7 @@ static int gp8psk_load_bcm4500fw(struct dvb_usb_device *d)
goto out_free;
}
if (buflen > 64) {
- err("firmare chunk size bigger than 64 bytes.");
+ err("firmware chunk size bigger than 64 bytes.");
goto out_free;
}
diff --git a/drivers/net/wireless/realtek/rtlwifi/core.c b/drivers/net/wireless/realtek/rtlwifi/core.c
index ded1493..732de0a 100644
--- a/drivers/net/wireless/realtek/rtlwifi/core.c
+++ b/drivers/net/wireless/realtek/rtlwifi/core.c
@@ -1532,7 +1532,7 @@ static int rtl_op_set_key(struct ieee80211_hw *hw, enum set_key_cmd cmd,
key_type = AESCMAC_ENCRYPTION;
RT_TRACE(rtlpriv, COMP_SEC, DBG_DMESG, "alg:CMAC\n");
RT_TRACE(rtlpriv, COMP_SEC, DBG_DMESG,
- "HW don't support CMAC encrypiton, use software CMAC encrypiton\n");
+ "HW don't support CMAC encryption, use software CMAC encryption\n");
err = -EOPNOTSUPP;
goto out_unlock;
default:
--
2.10.2
^ permalink raw reply related
* Re: [PATCH] rtlwifi: fix spelling mistake: "contry" -> "country"
From: Larry Finger @ 2016-12-29 20:58 UTC (permalink / raw)
To: Colin King, Chaoming Li, Kalle Valo, linux-wireless, netdev; +Cc: linux-kernel
In-Reply-To: <20161229160029.22117-1-colin.king@canonical.com>
On 12/29/2016 10:00 AM, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> trivial fix to spelling mistake in RT_TRACE message
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Larry
> ---
> drivers/net/wireless/realtek/rtlwifi/regd.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/realtek/rtlwifi/regd.c b/drivers/net/wireless/realtek/rtlwifi/regd.c
> index 6ee6bf8..558c31b 100644
> --- a/drivers/net/wireless/realtek/rtlwifi/regd.c
> +++ b/drivers/net/wireless/realtek/rtlwifi/regd.c
> @@ -440,7 +440,7 @@ int rtl_regd_init(struct ieee80211_hw *hw,
>
> if (rtlpriv->regd.country_code >= COUNTRY_CODE_MAX) {
> RT_TRACE(rtlpriv, COMP_REGD, DBG_DMESG,
> - "rtl: EEPROM indicates invalid contry code, world wide 13 should be used\n");
> + "rtl: EEPROM indicates invalid country code, world wide 13 should be used\n");
>
> rtlpriv->regd.country_code = COUNTRY_CODE_WORLD_WIDE_13;
> }
>
^ permalink raw reply
* Re: [PATCH] [media] gp8psk: fix spelling mistake: "firmare" -> "firmware"
From: VDR User @ 2016-12-29 21:23 UTC (permalink / raw)
To: Colin King
Cc: Mauro Carvalho Chehab, Larry Finger, Chaoming Li, Kalle Valo,
mailing list: linux-media, linux-wireless, netdev,
Linux Kernel Mailing List
In-Reply-To: <20161229202952.27448-1-colin.king@canonical.com>
> - err("firmare chunk size bigger than 64 bytes.");
> + err("firmware chunk size bigger than 64 bytes.");
Yup.
> - "HW don't support CMAC encrypiton, use software CMAC encrypiton\n");
> + "HW don't support CMAC encryption, use software CMAC encryption\n");
Should be: "HW doesn't support CMAC encryption, use software CMAC
encryption\n");
^ permalink raw reply
* [PATCH] staging: wilc1000: Fix endian sparse warning
From: Mike Kofron @ 2016-12-29 21:35 UTC (permalink / raw)
To: Aditya Shankar, Ganesh Krishna, Greg Kroah-Hartman
Cc: Mike Kofron, linux-wireless, devel, linux-kernel
drivers/staging/wilc1000/linux_wlan.c:995:18: warning: restricted __be16 degrades to integer
Signed-off-by: Mike Kofron <mpkofron@gmail.com>
---
drivers/staging/wilc1000/linux_wlan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/wilc1000/linux_wlan.c b/drivers/staging/wilc1000/linux_wlan.c
index e59cab5..f293779 100644
--- a/drivers/staging/wilc1000/linux_wlan.c
+++ b/drivers/staging/wilc1000/linux_wlan.c
@@ -992,7 +992,7 @@ int wilc_mac_xmit(struct sk_buff *skb, struct net_device *ndev)
tx_data->skb = skb;
eth_h = (struct ethhdr *)(skb->data);
- if (eth_h->h_proto == 0x8e88)
+ if (eth_h->h_proto == cpu_to_be16(0x8e88))
netdev_dbg(ndev, "EAPOL transmitted\n");
ih = (struct iphdr *)(skb->data + sizeof(struct ethhdr));
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] [media] gp8psk: fix spelling mistake: "firmare" -> "firmware"
From: Colin Ian King @ 2016-12-29 21:35 UTC (permalink / raw)
To: VDR User
Cc: Mauro Carvalho Chehab, Larry Finger, Chaoming Li, Kalle Valo,
mailing list: linux-media, linux-wireless, netdev,
Linux Kernel Mailing List
In-Reply-To: <CAA7C2qjAk6LqTru2zimRr4_JUYXK+4d8VENpyYXjyE0-eJ+RKQ@mail.gmail.com>
On 29/12/16 21:23, VDR User wrote:
>> - err("firmare chunk size bigger than 64 bytes.");
>> + err("firmware chunk size bigger than 64 bytes.");
>
> Yup.
>
>> - "HW don't support CMAC encrypiton, use software CMAC encrypiton\n");
>> + "HW don't support CMAC encryption, use software CMAC encryption\n");
>
> Should be: "HW doesn't support CMAC encryption, use software CMAC
> encryption\n");
>
Very true, I was so focused on the spelling I overlooked the grammar.
I'll re-send with that fixed.
Colin
^ permalink raw reply
* [PATCH][V2] [media] gp8psk: fix spelling mistake: "firmare" -> "firmware"
From: Colin King @ 2016-12-29 21:38 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Larry Finger, Chaoming Li, Kalle Valo,
linux-media, linux-wireless, netdev
Cc: linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Trivial fix to spelling mistake in err message. Also change "don't" to
"does not".
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/media/usb/dvb-usb/gp8psk.c | 2 +-
drivers/net/wireless/realtek/rtlwifi/core.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/usb/dvb-usb/gp8psk.c b/drivers/media/usb/dvb-usb/gp8psk.c
index 2360e7e..26461f2 100644
--- a/drivers/media/usb/dvb-usb/gp8psk.c
+++ b/drivers/media/usb/dvb-usb/gp8psk.c
@@ -161,7 +161,7 @@ static int gp8psk_load_bcm4500fw(struct dvb_usb_device *d)
goto out_free;
}
if (buflen > 64) {
- err("firmare chunk size bigger than 64 bytes.");
+ err("firmware chunk size bigger than 64 bytes.");
goto out_free;
}
diff --git a/drivers/net/wireless/realtek/rtlwifi/core.c b/drivers/net/wireless/realtek/rtlwifi/core.c
index ded1493..732de0a 100644
--- a/drivers/net/wireless/realtek/rtlwifi/core.c
+++ b/drivers/net/wireless/realtek/rtlwifi/core.c
@@ -1532,7 +1532,7 @@ static int rtl_op_set_key(struct ieee80211_hw *hw, enum set_key_cmd cmd,
key_type = AESCMAC_ENCRYPTION;
RT_TRACE(rtlpriv, COMP_SEC, DBG_DMESG, "alg:CMAC\n");
RT_TRACE(rtlpriv, COMP_SEC, DBG_DMESG,
- "HW don't support CMAC encrypiton, use software CMAC encrypiton\n");
+ "HW does not support CMAC encryption, use software CMAC encryption\n");
err = -EOPNOTSUPP;
goto out_unlock;
default:
--
2.10.2
^ permalink raw reply related
* Re: rtl8xxxu: Testing with 0BDA:8178 (TP-link TL-WN821N with 8192cu)
From: Agustin Martin @ 2016-12-30 0:05 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <CAHMXK7gqy9_PsZLKxTW7821XmGO1VOaD0Ex+gEsdzsXgwGenWg@mail.gmail.com>
2016-12-29 17:22 GMT+01:00 Agustin Martin <agustin6martin@gmail.com>:
> Hi, Jes
>
> Sorry if you already received this feedback, I could not find references.
>
> I am trying a TP-LINK TL-WN821N wifi usb dongle with Realtek 8192cu
> (lsusb returns: 0bda:8178 Realtek Semiconductor Corp. RTL8192CU
> 802.11n WLAN Adapter) and found the same problems described in
>
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1365844
>
> When using kernel rtl8192cu driver, I can connect to wifi, but soon
> the connection is dropped.
>
> Since some time ago (2014) you asked for feedback in that bug and I
> did not find further references I decided to try your rtl8xxxu driver.
>
> All tests were carried out in a Debian GNU/Linux jessie box (current
> stable release) with kernel 4.7.8 from Debian jessie backports (source
> package linux_4.7.8-1~bpo8+1.dsc).
>
> Changed kernel config to
>
> ## file: drivers/net/wireless/realtek/rtl8xxxu/Kconfig
> ##
> CONFIG_RTL8XXXU=m
> CONFIG_RTL8XXXU_UNTESTED=y
>
> built a kernel (slooow here), installed it and added this line to a
> file under /etc/modprobe.d
>
> alias usb:v0BDAp8178d*dc*dsc*dp*icFFiscFFipFFin* rtl8xxxu
>
> If the dongle is initially connected, system loads the rtl8xxxu module
> instead of rtl8192cu when booting but seems not to initialize the
> dongle, so I have no connection. However, if I disconnect the dongle
> and reconnect it again with the system on, everything seems to work
> well with no connection dropping. Only minimally tested, but apart
> from the boot problem apparently much better than with the built-in
> rtl8192cu kernel module.
Hi again Jes, good news,
I do not know what I did wrong before, but I am retesting above kernel
and dongle and things seem to be working from the very beginning, no
problems found after plain boot (just need to enable the network
twice, but that also happemed with the old b/g dongle, may be
something with network manager).
This is not my usual box, it is slow and I do not have it accesible
in a daily basis, but feel free to ask for further testing. Will try
to make my best.
Best regards,
--
Agustin
^ permalink raw reply
* Re: [2/2] ath10k: fix potential memory leak in ath10k_wmi_tlv_op_pull_fw_stats()
From: Kalle Valo @ 2016-12-30 9:11 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless, ath10k
In-Reply-To: <e0909741dfae742197d5f5d60709d225cc179b42.1480974623.git.chunkeey@googlemail.com>
Christian Lamparter <chunkeey@googlemail.com> wrote:
> ath10k_wmi_tlv_op_pull_fw_stats() uses tb = ath10k_wmi_tlv_parse_alloc(...)
> function, which allocates memory. If any of the three error-paths are
> taken, this tb needs to be freed.
>
> Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Patch applied to ath-next branch of ath.git, thanks.
097e46d2ae90 ath10k: fix potential memory leak in ath10k_wmi_tlv_op_pull_fw_stats()
--
https://patchwork.kernel.org/patch/9461627/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [V2] ath10k: fix incorrect txpower set by P2P_DEVICE interface
From: Kalle Valo @ 2016-12-30 9:13 UTC (permalink / raw)
To: Ryan Hsu; +Cc: ath10k, linux-wireless, ryanhsu
In-Reply-To: <1481669719-3423-1-git-send-email-ryanhsu@qca.qualcomm.com>
Ryan Hsu <ryanhsu@qca.qualcomm.com> wrote:
> From: Ryan Hsu <ryanhsu@qca.qualcomm.com>
>
> Ath10k reports the phy capability that supports P2P_DEVICE interface.
>
> When we use the P2P supported wpa_supplicant to start connection, it'll
> create two interfaces, one is wlan0 (vdev_id=0) and one is P2P_DEVICE
> p2p-dev-wlan0 which is for p2p control channel (vdev_id=1).
>
> ath10k_pci mac vdev create 0 (add interface) type 2 subtype 0
> ath10k_add_interface: vdev_id: 0, txpower: 0, bss_power: 0
> ...
> ath10k_pci mac vdev create 1 (add interface) type 2 subtype 1
> ath10k_add_interface: vdev_id: 1, txpower: 0, bss_power: 0
>
> And the txpower in per vif bss_conf will only be set to valid tx power when
> the interface is assigned with channel_ctx.
>
> But this P2P_DEVICE interface will never be used for any connection, so
> that the uninitialized bss_conf.txpower=0 is assinged to the
> arvif->txpower when interface created.
>
> Since the txpower configuration is firmware per physical interface.
> So the smallest txpower of all vifs will be the one limit the tx power
> of the physical device, that causing the low txpower issue on other
> active interfaces.
>
> wlan0: Limiting TX power to 21 (24 - 3) dBm
> ath10k_pci mac vdev_id 0 txpower 21
> ath10k_mac_txpower_recalc: vdev_id: 1, txpower: 0
> ath10k_mac_txpower_recalc: vdev_id: 0, txpower: 21
> ath10k_pci mac txpower 0
>
> This issue only happens when we use the wpa_supplicant that supports
> P2P or if we use the iw tool to create the control P2P_DEVICE interface.
>
> Signed-off-by: Ryan Hsu <ryanhsu@qca.qualcomm.com>
Patch applied to ath-next branch of ath.git, thanks.
88407beb1b14 ath10k: fix incorrect txpower set by P2P_DEVICE interface
--
https://patchwork.kernel.org/patch/9473309/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: ath10k: support dev_coredump for crash dump
From: Kalle Valo @ 2016-12-30 9:14 UTC (permalink / raw)
To: Kalle Valo; +Cc: ath10k, linux-wireless
In-Reply-To: <20161221121921.25119.93932.stgit@potku.adurom.net>
Kalle Valo <kvalo@qca.qualcomm.com> wrote:
> From: Arun Khandavalli <akhandav@qti.qualcomm.com>
>
> Whenever firmware crashes, and both CONFIG_ATH10K_DEBUGFS and
> CONFIG_ALLOW_DEV_COREDUMP are enabled, dump information about the crash via a
> devcoredump device. Dump can be read from userspace for further analysis from:
>
> /sys/class/devcoredump/devcd*/data
>
> As until now we have provided the firmware crash dump file via fw_crash_dump
> debugfs keep it still available but deprecate and a warning print that the user
> should switch to using dev_coredump.
>
> Future improvement would be not to depend on CONFIG_ATH10K_DEBUGFS, as there
> might be systems which want to get the firmware crash dump but not enable
> debugfs. How to handle memory consumption is also something which needs to be
> taken into account.
>
> Signed-off-by: Arun Khandavalli <akhandav@qti.qualcomm.com>
> [kvalo@qca.qualcomm.com: rebase, fixes, improve commit log]
> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Patch applied to ath-next branch of ath.git, thanks.
727000e6af34 ath10k: support dev_coredump for crash dump
--
https://patchwork.kernel.org/patch/9482989/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: ath10k: recal the txpower when removing interface
From: Kalle Valo @ 2016-12-30 9:15 UTC (permalink / raw)
To: Ryan Hsu; +Cc: ath10k, linux-wireless, ryanhsu
In-Reply-To: <1482445906-20421-1-git-send-email-ryanhsu@qca.qualcomm.com>
Ryan Hsu <ryanhsu@qca.qualcomm.com> wrote:
> From: Ryan Hsu <ryanhsu@qca.qualcomm.com>
>
> The txpower is being recalculated when adding interface to make sure
> txpower won't overshoot the spec, and when removing the interface,
> the txpower should again to be recalculated to restore the correct value
> from the active interface list.
>
> Following is one of the scenario
> vdev0 is created as STA and connected: txpower:23
> vdev1 is created as P2P_DEVICE for control interface: txpower:0
> vdev2 is created as p2p go/gc interface: txpower is 21
>
> So the vdev2@txpower:21 will be set to firmware when vdev2 is created.
> When we tear down the vdev2, the txpower needs to be recalculated to
> re-set it to vdev0@txpower:23 as vdev0/vdev1 are the active interface.
>
> ath10k_pci mac vdev 0 peer create 8c:fd:f0:01:62:98
> ath10k_pci mac vdev_id 0 txpower 23
> ... (adding interface)
> ath10k_pci mac vdev create 2 (add interface) type 1 subtype 3
> ath10k_pci mac vdev_id 2 txpower 21
> ath10k_pci mac txpower 21
> ... (removing interface)
> ath10k_pci mac vdev 2 delete (remove interface)
> ath10k_pci vdev 1 txpower 0
> ath10k_pci vdev 0 txpower 23
> ath10k_pci mac txpower 23
>
> Signed-off-by: Ryan Hsu <ryanhsu@qca.qualcomm.com>
Patch applied to ath-next branch of ath.git, thanks.
d679fa1b3c89 ath10k: recal the txpower when removing interface
--
https://patchwork.kernel.org/patch/9486925/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: ath10k: ignore configuring the incorrect board_id
From: Kalle Valo @ 2016-12-30 9:15 UTC (permalink / raw)
To: Ryan Hsu; +Cc: ath10k, linux-wireless, ryanhsu
In-Reply-To: <1482447757-23577-1-git-send-email-ryanhsu@qca.qualcomm.com>
Ryan Hsu <ryanhsu@qca.qualcomm.com> wrote:
> From: Ryan Hsu <ryanhsu@qca.qualcomm.com>
>
> With command to get board_id from otp, in the case of following
>
> boot get otp board id result 0x00000000 board_id 0 chip_id 0
> boot using board name 'bus=pci,bmi-chip-id=0,bmi-board-id=0"
> ...
> failed to fetch board data for bus=pci,bmi-chip-id=0,bmi-board-id=0 from
> ath10k/QCA6174/hw3.0/board-2.bin
>
> The invalid board_id=0 will be used as index to search in the board-2.bin.
>
> Ignore the case with board_id=0, as it means the otp is not carrying
> the board id information.
>
> Signed-off-by: Ryan Hsu <ryanhsu@qca.qualcomm.com>
Patch applied to ath-next branch of ath.git, thanks.
d2e202c06ca4 ath10k: ignore configuring the incorrect board_id
--
https://patchwork.kernel.org/patch/9486941/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: ath10k: Remove passing unused argument for ath10k_mac_tx
From: Kalle Valo @ 2016-12-30 9:16 UTC (permalink / raw)
To: Mohammed Shafi Shajakhan
Cc: ath10k, mohammed, linux-wireless, Mohammed Shafi Shajakhan
In-Reply-To: <1482845555-6076-1-git-send-email-mohammed@qca.qualcomm.com>
Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> wrote:
> From: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
>
> 'ath10k_mac_tx' does not seems to use the per station table
> entry pointer 'sta' (struct ieee80211_sta), hence remove passing
> this unused argument
>
> Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Patch applied to ath-next branch of ath.git, thanks.
a7773b5db155 ath10k: Remove passing unused argument for ath10k_mac_tx
--
https://patchwork.kernel.org/patch/9489231/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: ath10k: Enable advertising support for channel 169, 5Ghz
From: Kalle Valo @ 2016-12-30 9:19 UTC (permalink / raw)
To: Mohammed Shafi Shajakhan
Cc: ath10k, mohammed, linux-wireless, Mohammed Shafi Shajakhan
In-Reply-To: <1482852215-6438-1-git-send-email-mohammed@qca.qualcomm.com>
Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> wrote:
> From: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
>
> Enable advertising support for channel 169, 5Ghz so that
> based on the regulatory domain(country code) this channel
> shall be active for use. For example in countries like India
> this channel shall be available for use with latest regulatory updates
>
> Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Patch applied to ath-next branch of ath.git, thanks.
34c30b0a5e97 ath10k: enable advertising support for channel 169, 5Ghz
--
https://patchwork.kernel.org/patch/9489307/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* wireless-drivers-next open for 4.11
From: Kalle Valo @ 2016-12-30 11:18 UTC (permalink / raw)
To: linux-wireless
Now that the merge window is closed wireless-drivers-next is open for
new features going to 4.11.
wireless-drivers remains open for important fixes for 4.10.
--
Kalle Valo
^ permalink raw reply
* Re: mwifiex: use module_*_driver helper macros
From: Kalle Valo @ 2016-12-30 11:22 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: linux-wireless, Cathy Luo, Nishant Sarmukadam, rajatja,
briannorris, dmitry.torokhov, Amitkumar Karwar
In-Reply-To: <1480597700-2456-1-git-send-email-akarwar@marvell.com>
Amitkumar Karwar <akarwar@marvell.com> wrote:
> After user_rmmod global flag removal, *_init_module() and
> *_cleanup_module() have become just a wrapper functions.
> We will get rid of them with the help of module_*_driver() macros.
>
> For pcie, existing ".init_if" handler has same name as what
> module_pcie_driver() macro will create. Let's rename it to
> avoid conflict.
>
> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Doesn't apply.
fatal: sha1 information is lacking or useless (drivers/net/wireless/marvell/mwifiex/pcie.c).
Applying: mwifiex: use module_*_driver helper macros
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001 mwifiex: use module_*_driver helper macros
Patch set to Changes Requested.
--
https://patchwork.kernel.org/patch/9456135/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [1/2] mwifiex: code rearrangement in pcie.c and sdio.c
From: Kalle Valo @ 2016-12-30 11:24 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: linux-wireless, Cathy Luo, Nishant Sarmukadam, rajatja,
briannorris, dmitry.torokhov, Xinming Hu, Amitkumar Karwar
In-Reply-To: <1480517537-9920-1-git-send-email-akarwar@marvell.com>
Amitkumar Karwar <akarwar@marvell.com> wrote:
> From: Xinming Hu <huxm@marvell.com>
>
> Next patch in this series is going to use mwifiex_read_reg() in remove
> handlers. The changes here are prerequisites to avoid forward
> declarations.
>
> Signed-off-by: Xinming Hu <huxm@marvell.com>
> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Patch 2 doesn't apply.
fatal: sha1 information is lacking or useless (drivers/net/wireless/marvell/mwifiex/pcie.c).
Applying: mwifiex: get rid of global user_rmmod flag
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001 mwifiex: get rid of global user_rmmod flag
2 patches set to Changes Requested.
9454491 [1/2] mwifiex: code rearrangement in pcie.c and sdio.c
9454493 [2/2] mwifiex: get rid of global user_rmmod flag
--
https://patchwork.kernel.org/patch/9454491/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [1/5] mwifiex: get rid of mwifiex_do_flr wrapper
From: Kalle Valo @ 2016-12-30 11:25 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: linux-wireless, Cathy Luo, Nishant Sarmukadam, rajatja,
briannorris, dmitry.torokhov, Xinming Hu, Amitkumar Karwar
In-Reply-To: <1481724651-30397-1-git-send-email-akarwar@marvell.com>
Amitkumar Karwar <akarwar@marvell.com> wrote:
> From: Xinming Hu <huxm@marvell.com>
>
> This patch gets rid of mwifiex_do_flr. We will call
> mwifiex_shutdown_sw() and mwifiex_reinit_sw() directly.
> These two general purpose functions will be useful for
> sdio card reset handler.
>
> Signed-off-by: Xinming Hu <huxm@marvell.com>
> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Patch 3 doesn't apply.
fatal: sha1 information is lacking or useless (drivers/net/wireless/marvell/mwifiex/sdio.c).
Applying: mwifiex: sdio card reset enhancement
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001 mwifiex: sdio card reset enhancement
5 patches set to Changes Requested.
9474231 [1/5] mwifiex: get rid of mwifiex_do_flr wrapper
9474241 [2/5] mwifiex: cleanup in PCIe flr code path
9474235 [3/5] mwifiex: sdio card reset enhancement
9474233 [4/5] mwifiex: get rid of __mwifiex_sdio_remove helper
9474237 [5/5] mwifiex: get rid of global save_adapter and sdio_work
--
https://patchwork.kernel.org/patch/9474231/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [1/2] mwifiex: change width of MAC control variable
From: Kalle Valo @ 2016-12-30 11:26 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: linux-wireless, Cathy Luo, Nishant Sarmukadam, Amitkumar Karwar
In-Reply-To: <1481873145-5381-1-git-send-email-akarwar@marvell.com>
Amitkumar Karwar <akarwar@marvell.com> wrote:
> Firmware has started making use of reserved field.
> Accordingly change curr_pkt_filter from u16 to u32.
>
> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
2 patches applied to wireless-drivers-next.git, thanks.
b82dd3bdf1a1 mwifiex: change width of MAC control variable
d7864cf21235 mwifiex: Enable dynamic bandwidth signalling
--
https://patchwork.kernel.org/patch/9477347/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [1/2] mwifiex: code rearrangement in pcie.c and sdio.c
From: Kalle Valo @ 2016-12-30 11:28 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: linux-wireless@vger.kernel.org, Cathy Luo, Nishant Sarmukadam,
rajatja@google.com, briannorris@google.com,
dmitry.torokhov@gmail.com, Xinming Hu
In-Reply-To: <25e936b31e1e4f3d9db2c2309da9f798@SC-EXCH04.marvell.com>
Amitkumar Karwar <akarwar@marvell.com> writes:
> Hi Kalle,
>
>> Failed to apply:
>>
>> fatal: sha1 information is lacking or useless
>> (drivers/net/wireless/marvell/mwifiex/pcie.c).
>> Applying: mwifiex: get rid of global user_rmmod flag Repository lacks
>> necessary blobs to fall back on 3-way merge.
>> Cannot fall back to three-way merge.
>> Patch failed at 0001 mwifiex: get rid of global user_rmmod flag
>>
>> 2 patches set to Changes Requested.
>>
>> 9454491 [1/2] mwifiex: code rearrangement in pcie.c and sdio.c
>> 9454493 [2/2] mwifiex: get rid of global user_rmmod flag
>>
>> --
>> https://patchwork.kernel.org/patch/9454491/
>>
>> Documentation about submitting wireless patches and checking status
>> from patchwork:
>>
>> https://wireless.wiki.kernel.org/en/developers/documentation/submitting
>> patches
>
>
> These two patches have dependency with other patch series. I want you to consider patches in following order(first being recent).
>
> mwifiex: sdio: fix use after free issue for save_adapter
This applied fine.
> mwifiex: use module_*_driver helper macros
>
> [2/2] mwifiex: get rid of global user_rmmod flag
> [1/2] mwifiex: code rearrangement in pcie.c and sdio.c
>
> [v3,5/5] mwifiex: move pcie_work and related variables inside card -------- This series can be accepted if there are no further concerns/comments from Brian/Dmitry.
> [v3,4/5] mwifiex: wait firmware dump complete during card remove process
> [v3,3/5] mwifiex: get rid of drv_info* adapter variables
> [v3,2/5] mwifiex: do not free firmware dump memory in shutdown_drv
> [v3,1/5] mwifiex: don't wait for main_process in shutdown_drv
But these didn't. Can you please rebase these and resubmit in one
patchset? Less conflicts that way.
--
Kalle Valo
^ permalink raw reply
* Re: iwlegacy: make il3945_mac_ops __ro_after_init
From: Kalle Valo @ 2016-12-30 11:29 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Stanislaw Gruszka, Johannes Berg
In-Reply-To: <20161207063646.30969-1-johannes@sipsolutions.net>
Johannes Berg <johannes@sipsolutions.net> wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> There's no need for this to be only __read_mostly, since
> it's only written in a single way depending on the module
> parameter, so that can be moved into the module's __init
> function, and the ops can be __ro_after_init.
>
> This is a little bit safer since it means the ops can't
> be overwritten (accidentally or otherwise), which would
> otherwise cause an arbitrary function or bad pointer to
> be called.
>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
> Acked-by: Stanislaw Gruszka <sgruszka@redhat.com>
Patch applied to wireless-drivers-next.git, thanks.
ae3cf4764506 iwlegacy: make il3945_mac_ops __ro_after_init
--
https://patchwork.kernel.org/patch/9463999/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: adm80211: return an error if adm8211_alloc_rings() fails
From: Kalle Valo @ 2016-12-30 11:32 UTC (permalink / raw)
To: Dan Carpenter
Cc: Michael Wu, Alexey Khoroshilov, Johannes Berg, linux-wireless,
kernel-janitors
In-Reply-To: <20161207112122.GA5686@elgon.mountain>
Dan Carpenter <dan.carpenter@oracle.com> wrote:
> We accidentally return success when adm8211_alloc_rings() fails but we
> should preserve the error code.
>
> Fixes: cc0b88cf5ecf ("[PATCH] Add adm8211 802.11b wireless driver")
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>
> diff --git a/drivers/net/wireless/admtek/adm8211.c b/drivers/net/wireless/admtek/adm8211.c
> index 2b4a3eb38dfa..098c814e22c8 100644
> --- a/drivers/net/wireless/admtek/adm8211.c
> +++ b/drivers/net/wireless/admtek/adm8211.c
> @@ -1863,7 +1863,8 @@ static int adm8211_probe(struct pci_dev *pdev,
> priv->rx_ring_size = rx_ring_size;
> priv->tx_ring_size = tx_ring_size;
>
> - if (adm8211_alloc_rings(dev)) {
> + err = adm8211_alloc_rings(dev);
> + if (err) {
> printk(KERN_ERR "%s (adm8211): Cannot allocate TX/RX ring\n",
> pci_name(pdev));
> goto err_iounmap;
Patch applied to wireless-drivers-next.git, thanks.
c705a6b3aa78 adm80211: return an error if adm8211_alloc_rings() fails
--
https://patchwork.kernel.org/patch/9464449/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: orinoco: Use shash instead of ahash for MIC calculations
From: Kalle Valo @ 2016-12-30 11:34 UTC (permalink / raw)
To: Andrew Lutomirski
Cc: linux-kernel, linux-usb, linux-wireless, Eric Biggers,
linux-crypto, Herbert Xu, Stephan Mueller, Andy Lutomirski
In-Reply-To: <8818c45b9ec6a04d85fabf9bb437cf119fd23659.1481575835.git.luto@kernel.org>
Andrew Lutomirski <luto@kernel.org> wrote:
> Eric Biggers pointed out that the orinoco driver pointed scatterlists
> at the stack.
>
> Fix it by switching from ahash to shash. The result should be
> simpler, faster, and more correct.
>
> Cc: stable@vger.kernel.org # 4.9 only
> Reported-by: Eric Biggers <ebiggers3@gmail.com>
> Signed-off-by: Andy Lutomirski <luto@kernel.org>
11 patches applied to wireless-drivers-next.git, thanks.
1fef293b8a98 orinoco: Use shash instead of ahash for MIC calculations
a08b98196a36 rt2800: make rx ampdu_factor depend on number of rx chains
e49abb19d1bf rt2800: don't set ht parameters for non-aggregated frames
a51b89698ccc rt2800: set minimum MPDU and PSDU lengths to sane values
8f03a7c6e7f9 rt2800: set MAX_PSDU len according to remote STAs capabilities
8845254112ac rt2800: rename adjust_freq_offset function
bc0077053948 rt2800: warn if doing VCO recalibration for unknow RF chip
24d42ef3b152 rt2800: perform VCO recalibration for RF5592 chip
d96324703ffa rt2x00: merge agc and vco works with link tuner
eb79a8fe94c8 rt2800: replace mdelay by usleep on vco calibration.
31369c323ba0 rt2800: replace msleep() with usleep_range() on channel switch
--
https://patchwork.kernel.org/patch/9471353/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
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