* Re: rtl8723be on Fedora27
From: Rákosi Gergely @ 2017-11-18 7:50 UTC (permalink / raw)
To: rosenp, linux-wireless
In-Reply-To: <1510981609.5145.0.camel@gmail.com>
Hello,
I put in to blacklist the module rtlwifi and rtl8723be, and now I get:
- kde's networkmanager did not recognize wireless devices
- in the messages log there are the following :
"registered new interface driver rtl8xxxu
Bluetooth: hci0: rtl : Direct firmware load for
rtl_bt/rtl8723b_config.bin failed with error -2
- ifconfig give no wireless devices (wlp2s0 or wlan0)
If I blacklist only rtlwifi then load the rtl8723be module like normal.
Thanks,
Geri
2017-11-18 06:06 keltezéssel, rosenp@gmail.com írta:
> On Fri, 2017-11-17 at 09:16 +0100, Rákosi Gergely wrote:
>> Hello,
>>
>> I'm trying to use rtl8723be wifi on Fedora27 but I still get
>> continuosly
>> disconnection. The error in the dmesg is "Init MAC failed"
>> I tried with the following module options too : "fwlps=0 swlps=0" and
>> the variant of "ant_sel=1 or 2 or 0"
>> I downloaded the git files from your repo, and do the usual make,make
>> install, and modprobe stuffs, and then restart the notebook, but I
>> get
>> the same result.
>>
> Could try blacklisting rtlwifi. That way it uses rtl8xxxu.
>> Thanks your help,
>> Regards,
>> Gergely
^ permalink raw reply
* Re: rtl8723be on Fedora27
From: Larry Finger @ 2017-11-18 15:19 UTC (permalink / raw)
To: rosenp, Rákosi Gergely, linux-wireless
In-Reply-To: <1510981609.5145.0.camel@gmail.com>
On 11/17/2017 11:06 PM, rosenp@gmail.com wrote:
> On Fri, 2017-11-17 at 09:16 +0100, Rákosi Gergely wrote:
>> Hello,
>>
>> I'm trying to use rtl8723be wifi on Fedora27 but I still get
>> continuosly
>> disconnection. The error in the dmesg is "Init MAC failed"
>> I tried with the following module options too : "fwlps=0 swlps=0" and
>> the variant of "ant_sel=1 or 2 or 0"
>> I downloaded the git files from your repo, and do the usual make,make
>> install, and modprobe stuffs, and then restart the notebook, but I
>> get
>> the same result.
>>
>
> Could try blacklisting rtlwifi. That way it uses rtl8xxxu.
Ignore this suggestion. The RTL8723BE is NOT supported by rtl8xxxu. By the way,
that "u" means that the driver is for USB devices. The "E" at the end of yours
means PCIe!
Larry
^ permalink raw reply
* Re: rtl8723be on Fedora27
From: Larry Finger @ 2017-11-18 15:40 UTC (permalink / raw)
To: Rákosi Gergely, rosenp, linux-wireless
In-Reply-To: <21a2cc76-ed4e-22a2-3eb2-1f4b8df348fd@gmail.com>
On 11/18/2017 01:50 AM, Rákosi Gergely wrote:
> Hello,
>
> I put in to blacklist the module rtlwifi and rtl8723be, and now I get:
> - kde's networkmanager did not recognize wireless devices
> - in the messages log there are the following :
> "registered new interface driver rtl8xxxu
> Bluetooth: hci0: rtl : Direct firmware load for
> rtl_bt/rtl8723b_config.bin failed with error -2
> - ifconfig give no wireless devices (wlp2s0 or wlan0)
>
> If I blacklist only rtlwifi then load the rtl8723be module like normal.
That is exactly what is expected. You can ignore that missing
rtl_bt/rtl8723b_config.bin. The BT part of the RTL8723BE does not need a
"config.bin". A patch was sent to the BT group to get rid of that message, but
it seems to be lost somewhere.
Larry
^ permalink raw reply
* Re: rtl8723be on Fedora27
From: Larry Finger @ 2017-11-18 15:52 UTC (permalink / raw)
To: Rákosi Gergely, linux-wireless
In-Reply-To: <c6662534-db2f-61dc-142e-8015984c6813@gmail.com>
On 11/17/2017 06:22 PM, Rákosi Gergely wrote:
> Hello Larry,
>
> First of all, thanks your help.
> Lets see...here is the kernel version: 4.13.12-300
> The machine is an Asus ROG 553VE
>
> The firmware which loading in the dmesg is : rtlwifi/rtl8723befw_36.bin
> The output of md5sum is : 1850c1308fbcd95e9f6a7f58ede1e35f
In mailing lists like this, top posting is not recommended. Please read
http://www.idallen.com/topposting.html for a good explanation why top posting is
not good, particularly for complicated threads.
You have the correct firmware. By the way, the code in 4.13.12 should be better
that rtlwifi_new. That latter repo is deliberately kept a little bit behind just
in case there is a regression.
With NO options in the loading, please run the following:
iw dev
You should only see one device. On the "Interface" line, note what your system
calls the wifi device. Substitute that for the "wlan0" in the next command:
sudo iw dev wlan0 scan | egrep "SSID|signal"
Post that output. In addition, copy the dmesg output to some pastebin and post
the link as well.
Larry
^ permalink raw reply
* [PATCH v2] iw: add command to register and dump mgmt frames
From: Sergey Matyukevich @ 2017-11-18 18:20 UTC (permalink / raw)
To: Johannes Berg, linux-wireless; +Cc: Igor Mitsyanko, Sergey Matyukevich
Add debug command to receive and print selected management frames.
Frames are selected by their type and pattern containing the first
several bytes of the frame that should match.
Note that Linux wireless core does not support multiple listeners
for management frames. So this debug command can be used together
with hostapd or other wireless software only in the case if it
subscribes for different set of management frames.
Format:
$ iw dev <devname> frame <type> <pattern> [frame <type> <pattern>]* [count <frames>]
Example:
$ iw dev wlan0 mgmt dump frame 40 00 frame 40 01:02 count 10
Frame type is supplied as hex w/o leading 0x. Frame pattern is supplied
as hex pattern of the form aa:bb:cc w/o leading 0x as well.
Count is a number of frames to receive.
Signed-off-by: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>
-------
Changes v1->v2:
- fix rssi type
- rename command to avoid confusion: dump rather than capture
- add note to commit message: multiple mgmt frame listeners are not supported
---
Makefile | 2 +-
mgmt.c | 150 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 151 insertions(+), 1 deletion(-)
create mode 100644 mgmt.c
diff --git a/Makefile b/Makefile
index e61825e..38d782d 100644
--- a/Makefile
+++ b/Makefile
@@ -17,7 +17,7 @@ OBJS = iw.o genl.o event.o info.o phy.o \
interface.o ibss.o station.o survey.o util.o ocb.o \
mesh.o mpath.o mpp.o scan.o reg.o version.o \
reason.o status.o connect.o link.o offch.o ps.o cqm.o \
- bitrate.o wowlan.o coalesce.o roc.o p2p.o vendor.o
+ bitrate.o wowlan.o coalesce.o roc.o p2p.o vendor.o mgmt.o
OBJS += sections.o
OBJS-$(HWSIM) += hwsim.o
diff --git a/mgmt.c b/mgmt.c
new file mode 100644
index 0000000..60f544b
--- /dev/null
+++ b/mgmt.c
@@ -0,0 +1,150 @@
+#include <string.h>
+#include <errno.h>
+
+#include <netlink/genl/genl.h>
+#include <netlink/genl/family.h>
+#include <netlink/genl/ctrl.h>
+#include <netlink/msg.h>
+#include <netlink/attr.h>
+
+#include "nl80211.h"
+#include "iw.h"
+
+SECTION(mgmt);
+
+static int seq_handler(struct nl_msg *msg, void *arg)
+{
+ return NL_OK;
+}
+
+static int dump_mgmt_frame(struct nl_msg *msg, void *arg)
+{
+ struct genlmsghdr *gnlh = nlmsg_data(nlmsg_hdr(msg));
+ struct nlattr *tb_msg[NL80211_ATTR_MAX + 1];
+
+ nla_parse(tb_msg, NL80211_ATTR_MAX, genlmsg_attrdata(gnlh, 0),
+ genlmsg_attrlen(gnlh, 0), NULL);
+
+ if (tb_msg[NL80211_ATTR_WIPHY_FREQ]) {
+ uint32_t freq = nla_get_u32(tb_msg[NL80211_ATTR_WIPHY_FREQ]);
+ printf("freq %u MHz\n", freq);
+ }
+
+ if (tb_msg[NL80211_ATTR_RX_SIGNAL_DBM]) {
+ /* nl80211_send_mgmt sends signed dBm value as u32 */
+ int dbm = nla_get_u32(tb_msg[NL80211_ATTR_RX_SIGNAL_DBM]);
+ printf("rssi %d dBm\n", dbm);
+ }
+
+ if (tb_msg[NL80211_ATTR_FRAME]) {
+ int len = nla_len(tb_msg[NL80211_ATTR_FRAME]);
+ uint8_t *data = nla_data(tb_msg[NL80211_ATTR_FRAME]);
+ iw_hexdump("mgmt", data, len);
+ }
+
+ return 0;
+}
+
+static int register_mgmt_frame(struct nl80211_state *state,
+ struct nl_msg *msg, int argc, char **argv,
+ enum id_input id)
+{
+ unsigned int type;
+ unsigned char *match;
+ size_t match_len;
+ int ret;
+
+ ret = sscanf(argv[0], "%x", &type);
+ if (ret != 1) {
+ printf("invalid frame type: %s\n", argv[0]);
+ return 2;
+ }
+
+ match = parse_hex(argv[1], &match_len);
+ if (!match) {
+ printf("invalid frame pattern: %s\n", argv[1]);
+ return 2;
+ }
+
+ NLA_PUT_U16(msg, NL80211_ATTR_FRAME_TYPE, type);
+ NLA_PUT(msg, NL80211_ATTR_FRAME_MATCH, match_len, match);
+
+ return 0;
+
+nla_put_failure:
+ return -ENOBUFS;
+}
+
+static int handle_mgmt_reg(struct nl80211_state *state,
+ struct nl_msg *msg, int argc,
+ char **argv, enum id_input id)
+{
+ return register_mgmt_frame(state, msg, argc, argv, id);
+}
+
+HIDDEN(mgmt, reg, "", NL80211_CMD_REGISTER_FRAME, 0, CIB_NETDEV, handle_mgmt_reg);
+
+static int handle_mgmt_dump(struct nl80211_state *state,
+ struct nl_msg *msg, int argc,
+ char **argv, enum id_input id)
+{
+ struct nl_cb *mgmt_cb;
+ char *ndev = argv[0];
+ int mgmt_argc = 5;
+ char **mgmt_argv;
+ unsigned int count = 0;
+ int err = 0;
+ int i;
+
+ mgmt_argv = calloc(mgmt_argc, sizeof(char*));
+ if (!mgmt_argv)
+ return -ENOMEM;
+
+ mgmt_argv[0] = ndev;
+ mgmt_argv[1] = "mgmt";
+ mgmt_argv[2] = "reg";
+
+ for (i = 3; i < argc; i += 3) {
+ if (strcmp(argv[i], "count") == 0) {
+ count = 1 + atoi(argv[i + 1]);
+ break;
+ }
+
+ if (strcmp(argv[i], "frame") != 0) {
+ err = 1;
+ goto out;
+ }
+
+ mgmt_argv[3] = argv[i + 1];
+ mgmt_argv[4] = argv[i + 2];
+
+ err = handle_cmd(state, II_NETDEV, mgmt_argc, mgmt_argv);
+ if (err)
+ goto out;
+ }
+
+ mgmt_cb = nl_cb_alloc(iw_debug ? NL_CB_DEBUG : NL_CB_DEFAULT);
+ if (!mgmt_cb) {
+ err = 1;
+ goto out;
+ }
+
+ /* need to turn off sequence number checking */
+ nl_cb_set(mgmt_cb, NL_CB_SEQ_CHECK, NL_CB_CUSTOM, seq_handler, NULL);
+ nl_cb_set(mgmt_cb, NL_CB_VALID, NL_CB_CUSTOM, dump_mgmt_frame, NULL);
+
+ while (--count)
+ nl_recvmsgs(state->nl_sock, mgmt_cb);
+
+ nl_cb_put(mgmt_cb);
+out:
+ free(mgmt_argv);
+ return err;
+}
+
+COMMAND(mgmt, dump, "frame <type as hex ab> <pattern as hex ab:cd:..> [frame <type> <pattern>]* [count <frames>]",
+ 0, 0, CIB_NETDEV, handle_mgmt_dump,
+ "Register for receiving certain mgmt frames and print them.\n"
+ "Frames are selected by their type and pattern containing\n"
+ "the first several bytes of the frame that should match.\n\n"
+ "Example: iw dev wlan0 mgmt dump frame 40 00 frame 40 01:02 count 10\n");
--
2.11.0
^ permalink raw reply related
* Re: rtl8821ae dbi read question
From: Nik Nyby @ 2017-11-19 0:39 UTC (permalink / raw)
To: Larry Finger, linux-wireless, pkshih
In-Reply-To: <41409929-78bb-f00b-74e5-b70d6d157c52@lwfinger.net>
On 11/06/2017 08:52 AM, Larry Finger wrote:
>
> Your results seem to indicate that aspm, which is support_aspm
> internally, is not being set to zero. The first executable statement in
> enable_aspm is
>
> if (!ppsc->support_aspm)
> return;
>
> That statement should disable the entire routine; however, you still
> need to disable the call to this routine. It is possible that the timing
> is messed up when built into the kernel. Building as a module will be
> instructive.
>
> Larry
>
FYI, when building this driver as a module, I'm not seeing my unstable
connection problem anymore, with the aspm=0 config set in
/etc/modprobe.d/. Thanks for your help with this.
^ permalink raw reply
* Marvell Mwifiex wireless driver: mwifiex_pcie broken on Marvell ESPRESSOBin
From: Ellie Reeves @ 2017-11-19 15:15 UTC (permalink / raw)
Cc: linux-wireless, amitkarwar, nishants, gbhat, huxm
Hello,
I noticed the Marvell Mwifiex wireless driver ended up broken since
kernel 4.13.0, and it is still the case with 4.14.0 on the Marvell
ESPRESSOBin, soled by Globalscale Technology. I bought the official
wireless card from them at the same time as the board. However since
kernel 4.13.0, wifi as provided via mwifiex_pcie module stopped working.
I don't have much info on the userspace side, as all that happens is the
wireless interface is never brought up and stays in 'NO-CARRIER' state
according to 'ip a'. However on kernel side, I hope I have some info
that are more useful ! :) This was logged via systemd-journald with
debug turned on in mwifiex driver. I am willing to try anything to get
this kernel working, as it's a lts kernel contrary to 4.12.12 on which
I'm forced to run for now.
https://gist.githubusercontent.com/mk-fg/27c2505fd3bffcf0af87777aaafb71fe/raw/fda70ff9f8eaab248a104e03922323cf2f4754bf/tmp.txt
I hope these info will be useful in debugging. I'm new to all these
kernel stuff, so I may have posted to the wrong place or in a wrong way,
if so, please let me know.
Thanks in advance
--
Ellie Reeves
^ permalink raw reply
* pull-request: iwlwifi 2017-11-19
From: Luca Coelho @ 2017-11-20 11:02 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, linuxwifi
[-- Attachment #1: Type: text/plain, Size: 2292 bytes --]
Hi Kalle,
Here is my first set of fixes for 4.15. More details in the tag
description.
I have based it on wireless-drivers-next.git, because you didn't update
wireless-drivers.git yet. Let me know if you want me to rebase once
you update.
I have sent this out before and kbuildbot didn't find any issues.
Please let me know if there are any issues.
Cheers,
Luca.
The following changes since commit fdd0bd88ceaecf729db103ac8836af5805dd2dc1:
brcmfmac: add CLM download support (2017-11-11 03:04:09 +0200)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes.git tags/iwlwifi-for-kalle-2017-11-19
for you to fetch changes up to c2c48ddfc8b03b9ecb51d2832b586497b37531bc:
iwlwifi: fix firmware names for 9000 and A000 series hw (2017-11-16 10:40:15 +0200)
----------------------------------------------------------------
iwlwifi: first set of fixes for 4.15
* Support new FW API version of scan cmd (used in FW version 34);
* Add a bunch of PCI IDs and fix configuration structs for A000
devices;
* Fix the exported firmware name strings for 9000 and A000 devices;
----------------------------------------------------------------
Luca Coelho (2):
iwlwifi: mvm: support version 7 of the SCAN_REQ_UMAC FW command
iwlwifi: fix PCI IDs and configuration mapping for 9000 series
Thomas Backlund (1):
iwlwifi: fix firmware names for 9000 and A000 series hw
drivers/net/wireless/intel/iwlwifi/cfg/9000.c | 73 +++++++++++++++++++++++++++++++++++++++++++++++++-------
drivers/net/wireless/intel/iwlwifi/cfg/a000.c | 10 ++++----
drivers/net/wireless/intel/iwlwifi/fw/api/scan.h | 59 +++++++++++++++++++++++++++++++++++----------
drivers/net/wireless/intel/iwlwifi/fw/file.h | 1 +
drivers/net/wireless/intel/iwlwifi/iwl-config.h | 5 ++++
drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 6 +++++
drivers/net/wireless/intel/iwlwifi/mvm/scan.c | 86 ++++++++++++++++++++++++++++++++++++++++++++++++++----------------
drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 132 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++----------------------
8 files changed, 296 insertions(+), 76 deletions(-)
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: AP6335 with mainline kernel
From: Arend van Spriel @ 2017-11-20 11:03 UTC (permalink / raw)
To: Vanessa Maegima, van.ayumi@gmail.com
Cc: linux-wireless@vger.kernel.org, embed3d@gmail.com
In-Reply-To: <1510932224.22506.0.camel@nxp.com>
On 17-11-17 16:24, Vanessa Maegima wrote:
> Hi Arend,
>
> On Sex, 2017-11-17 at 13:55 +0100, Arend van Spriel wrote:
>> On 11/17/2017 12:08 PM, Vanessa Maegima wrote:
>>>
>>> Hi Arend,
>>>
>>> On Sex, 2017-11-10 at 20:58 +0100, Arend van Spriel wrote:
>>>>
>>>> On 10-11-17 13:43, Vanessa Maegima wrote:
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> On Qui, 2017-09-21 at 12:30 -0300, Vanessa Ayumi Maegima wrote:
>>>>>>
>>>>>>
>>>>>> Hi Arend,
>>>>>>
>>>>>> On Thu, Sep 21, 2017 at 4:26 AM, Arend van Spriel
>>>>>> <arend.vanspriel@broadcom.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 20-09-17 21:33, Vanessa Ayumi Maegima wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I am trying to enable Wifi on imx7d-pico using mainline
>>>>>>>> kernel.
>>>>>>>> imx7d-pico
>>>>>>>> has an AP6335 chip.
>>>>>>>>
>>>>>>>> I am facing some issues related to the nvram file. I am
>>>>>>>> using
>>>>>>>> the
>>>>>>>> firmware
>>>>>>>> provided by Buildroot (brcmfmac4339-sdio.bin). I get the
>>>>>>>> following error:
>>>>>>>>
>>>>>>>> [ 8.630380] brcmfmac: brcmf_sdio_htclk: HT Avail
>>>>>>>> timeout
>>>>>>>> (1000000):
>>>>>>>> clkctl 0x50
>>>>>>>>
>>>>>>>> I have tried to use the firmware and nvram provided by
>>>>>>>> TechNexion
>>>>>>>> but I
>>>>>>>> get
>>>>>>>> the same error.
>>>>>>>>
>>>>>>>> Is there anyone that could enable Wifi on AP6335 using
>>>>>>>> kernel
>>>>>>>> mainline?
>>>>>>>> What nvram file was used?
>>>>>>>>
>>>>>>>> I am able to use Wifi on the board if I use the firmware,
>>>>>>>> nvram
>>>>>>>> file and
>>>>>>>> kernel
>>>>>>>> provided by TechNexion. They use a 4.1 kernel from NXP
>>>>>>>> with
>>>>>>>> the
>>>>>>>> bcmdhd
>>>>>>>> driver.
>>>>>>>>
>>>>>>>> So I know that the hardware is functional.
>>>>>>>>
>>>>>>>> Any suggestions as how to get it working with a 4.13 and
>>>>>>>> brcmfmac
>>>>>>>> driver
>>>>>>>> is
>>>>>>>> appreciated.
>>>>>>> So the nvram file is specific to the wifi chipset on your
>>>>>>> platform
>>>>>>> so best
>>>>>>> to stick with the provided one. The "HT Avail timeout" most
>>>>>>> often
>>>>>>> is an
>>>>>>> indication that the firmware crashed. So getting more debug
>>>>>>> output
>>>>>>> would
>>>>>>> help us understand how it ended up like that. Can you build
>>>>>>> the
>>>>>>> brcmfmac
>>>>>>> with CONFIG_BRCMDBG and load the driver using:
>>>>>>>
>>>>>>> $ insmod brcmfmac.ko debug=0x1416
>>>>>> Thanks for the reply!
>>>>>>
>>>>>> Here is the log (using 4.14-rc1):
>>>>>>
>>>>>> # dmesg | grep brcmfmac
>>>>>> [ 19.297206] brcmfmac: brcmfmac_module_init No platform
>>>>>> data
>>>>>> available.
>>>>>> [ 19.307075] brcmfmac: brcmf_sdio_probe Enter
>>>>>> [ 19.308384] brcmfmac: F1 signature read
>>>>>> @0x18000000=0x16224335
>>>>>> [ 19.309026] brcmfmac: brcmf_chip_recognition found AXI
>>>>>> chip:
>>>>>> BCM4339, rev=2
>>>>>> [ 19.317115] brcmfmac: brcmf_chip_cores_check [1 ] core
>>>>>> 0x800:46
>>>>>> base 0x18000000 wrap 0x18100000
>>>>>> [ 19.317141] brcmfmac: brcmf_chip_cores_check [2 ] core
>>>>>> 0x812:46
>>>>>> base 0x18001000 wrap 0x18101000
>>>>>> [ 19.317165] brcmfmac: brcmf_chip_cores_check [3 ] core
>>>>>> 0x83e:4
>>>>>> base 0x18002000 wrap 0x18102000
>>>>>> [ 19.317188] brcmfmac: brcmf_chip_cores_check [4 ] core
>>>>>> 0x83c:4
>>>>>> base 0x18003000 wrap 0x18103000
>>>>>> [ 19.317210] brcmfmac: brcmf_chip_cores_check [5 ] core
>>>>>> 0x81a:20
>>>>>> base 0x18004000 wrap 0x18104000
>>>>>> [ 19.317233] brcmfmac: brcmf_chip_cores_check [6 ] core
>>>>>> 0x829:21
>>>>>> base 0x18005000 wrap 0x18105000
>>>>>> [ 19.317256] brcmfmac: brcmf_chip_cores_check [7 ] core
>>>>>> 0x135:0
>>>>>> base 0x00000000 wrap 0x18109000
>>>>>> [ 19.317279] brcmfmac: brcmf_chip_cores_check [8 ] core
>>>>>> 0x240:0
>>>>>> base 0x00000000 wrap 0x00000000
>>>>>> [ 19.317298] brcmfmac: brcmf_chip_set_passive Enter
>>>>>> [ 19.322232] brcmfmac: brcmf_chip_get_raminfo RAM:
>>>>>> base=0x180000
>>>>>> size=786432 (0xc0000) sr=0 (0x0)
>>>>>> [ 19.322457] brcmfmac: brcmf_chip_setup ccrev=46,
>>>>>> pmurev=23,
>>>>>> pmucaps=0x39cc5f17
>>>>>> [ 19.322481] brcmfmac: brcmf_get_module_param Enter, bus=0,
>>>>>> chip=17209, rev=2
>>>>>> [ 19.322504] brcmfmac: brcmf_sdiod_sgtable_alloc nents=35
>>>>>> [ 19.322531] brcmfmac: brcmf_sdio_kso_init Enter
>>>>>> [ 19.322618] brcmfmac: brcmf_sdio_drivestrengthinit No SDIO
>>>>>> driver
>>>>>> strength init needed for chip 43
>>>>>> 39 rev 2 pmurev 23
>>>>>> [ 19.323235] brcmfmac: brcmf_attach Enter
>>>>>> [ 19.323725] brcmfmac: brcmf_proto_attach Enter
>>>>>> [ 19.323769] brcmfmac: brcmf_fweh_register event handler
>>>>>> registered
>>>>>> for PSM_WATCHDOG
>>>>>> [ 19.324306] brcmfmac: brcmf_sdio_probe completed!!
>>>>>> [ 19.324337] brcmfmac: brcmf_fw_map_chip_to_name: using
>>>>>> brcm/brcmfmac4339-sdio.bin for chip 0x00433
>>>>>> 9(17209) rev 0x000002
>>>>>> [ 19.335353] brcmfmac: brcmf_fw_get_firmwares_pcie enter:
>>>>>> dev=mmc0:0001:1
>>>>>> [ 19.351787] brcmfmac: brcmf_fw_request_code_done enter:
>>>>>> dev=mmc0:0001:1
>>>>>> [ 19.353202] brcmfmac: brcmf_fw_request_nvram_done enter:
>>>>>> dev=mmc0:0001:1
>>>>>> [ 19.353424] brcmfmac: brcmf_sdio_firmware_callback Enter:
>>>>>> dev=mmc0:0001:1, err=0
>>>>>> [ 19.353814] brcmfmac: brcmf_sdio_download_code_file Enter
>>>>>> [ 19.388586] brcmfmac: brcmf_sdio_verifymemory Compare RAM
>>>>>> dl &
>>>>>> ul
>>>>>> at 0x00180000; size=493599
>>>>>> [ 19.546675] brcmfmac: brcmf_sdio_download_nvram Enter
>>>>>> [ 19.547432] brcmfmac: brcmf_sdio_verifymemory Compare RAM
>>>>>> dl &
>>>>>> ul
>>>>>> at 0x0023f730; size=2256
>>>>>> [ 19.548665] brcmfmac: brcmf_chip_set_active Enter
>>>>>> [ 20.562974] brcmfmac: brcmf_sdio_htclk: HT Avail timeout
>>>>>> (1000000):
>>>>>> clkctl 0x50
>>>>>> [ 20.570490] brcmfmac: brcmf_sdio_firmware_callback failed:
>>>>>> dev=mmc0:0001:1, err=0
>>>>>> [ 20.570739] brcmfmac: brcmf_sdio_remove Enter
>>>>>> [ 20.570775] brcmfmac: brcmf_detach Enter
>>>>>> [ 20.610414] brcmfmac: brcmf_bus_change_state 0 -> 0
>>>>>> [ 20.610441] brcmfmac: brcmf_sdio_bus_stop Enter
>>>>>> [ 21.622477] brcmfmac: brcmf_sdio_htclk: HT Avail timeout
>>>>>> (1000000):
>>>>>> clkctl 0x50
>>>>>> [ 21.630912] brcmfmac: brcmf_proto_detach Enter
>>>>>> [ 21.630967] brcmfmac: brcmf_fweh_unregister event handler
>>>>>> cleared
>>>>>> for PSM_WATCHDOG
>>>>>> [ 22.642457] brcmfmac: brcmf_sdio_htclk: HT Avail timeout
>>>>>> (1000000):
>>>>>> clkctl 0x50
>>>>>> [ 22.680131] brcmfmac: brcmf_chip_set_passive Enter
>>>>>> [ 22.682580] brcmfmac: brcmf_sdio_remove Disconnected
>>>>>>
>>>>> Any suggestions on this?
>>>> Sorry for not getting back to your earlier email. Thanks for the
>>>> reminder. So you tried different firmwares, right? Can you
>>>> provide
>>>> output of the following command:
>>>>
>>>> $ strings firmware.bin | tail -1
>>>>
>>>> for the firmwares you tried.
>>>>
>>>> Regards,
>>>> Arend
>>> Thanks for the reply!
>>>
>>> Here's the output:
>>>
>>> For Technexion firmware:
>>>
>>> # strings /lib/firmware/brcm/brcmfmac4339-sdio.bin | tail -1
>>> 4339a0-roml/sdio-ag-pool-p2p-pno-pktfilter-keepalive-aoe-sr-mchan-
>>> proptxstatus-lpc-tdls-autoabn-txbf-
>>> rcc-wepso-okc-ndoe Version: 6.37.32.28 CRC: 3075f12e Date: Thu
>>> 2014-04-
>>> 03 12:15:31 CST FWID 01-4ae4ad
>>> 03
>>>
>>> For linux-firmware and Buildroot firmware:
>>>
>>> # strings /lib/firmware/brcm/brcmfmac4339-sdio.bin | tail -1
>>> 4339a0-roml/sdio-ag-pool-autoabn-lpc Version: 6.37.34.28 CRC:
>>> a696897b
>>> Date: Thu 2014-08-28 18:40:12
>>> PDT FWID 01-a13120fc
>>>
>>> In both cases, I am using the nvram provided by Technexion.
>> That should be fine.
>>
>> Can you try the patch below. It would give me more info on state of
>> firmware.
>>
>> Regards,
>> Arend
>>
>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
>> b/drivers/ne
>> index f355612..631c5cb 100644
>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
>> @@ -828,8 +828,27 @@ static int brcmf_sdio_htclk(struct brcmf_sdio
>> *bus,
>> bool on,
>> return -EBADE;
>> }
>> if (!SBSDIO_CLKAV(clkctl, bus->alp_only)) {
>> + struct brcmf_core *pmu =
>> brcmf_chip_get_pmu(bus->ci);
>> + u32 regaddr;
>> + u32 val;
>> +
>> brcmf_err("HT Avail timeout (%d): clkctl
>> 0x%02x\n",
>> PMU_MAX_TRANSITION_DLY, clkctl);
>> +
>> + /* DEBUG INFO */
>> + regaddr = CORE_CC_REG(pmu->base, pmucontrol);
>> + val = brcmf_sdiod_regrl(bus->sdiodev,
>> regaddr,
>> &err);
>> + brcmf_err(" pmucontrol = %08x\n", val);
>> + regaddr = CORE_CC_REG(pmu->base, pmustatus);
>> + val = brcmf_sdiod_regrl(bus->sdiodev,
>> regaddr,
>> &err);
>> + brcmf_err(" pmustatus = %08x\n", val);
>> + regaddr = CORE_CC_REG(pmu->base,
>> min_res_mask);
>> + val = brcmf_sdiod_regrl(bus->sdiodev,
>> regaddr,
>> &err);
>> + brcmf_err(" min_res_mask = %08x\n", val);
>> + regaddr = CORE_CC_REG(pmu->base,
>> max_res_mask);
>> + val = brcmf_sdiod_regrl(bus->sdiodev,
>> regaddr,
>> &err);
>> + brcmf_err(" max_res_mask = %08x\n", val);
>> +
>> return -EBADE;
>> }
>>
>>
>
> Here's the output for both firmwares:
>
> Technexion:
> # dmesg | grep brcmfmac
> [ 5.307067] brcmfmac: brcmf_fw_map_chip_to_name: using
> brcm/brcmfmac4339-sdio.bin for chip 0x00433
> 9(17209) rev 0x000002
> [ 6.400792] brcmfmac: brcmf_sdio_htclk: HT Avail timeout (1000000):
> clkctl 0x50
> [ 6.408444] brcmfmac: brcmf_sdio_htclk: pmucontrol = 01774381
> [ 6.415595] brcmfmac: brcmf_sdio_htclk: pmustatus = 0000002a
> [ 6.421915] brcmfmac: brcmf_sdio_htclk: min_res_mask = 0fcaff77
> [ 6.428124] brcmfmac: brcmf_sdio_htclk: max_res_mask = 0fceff77
> [ 7.482668] brcmfmac: brcmf_sdio_htclk: HT Avail timeout (1000000):
> clkctl 0x50
> [ 7.490214] brcmfmac: brcmf_sdio_htclk: pmucontrol = 01774381
> [ 7.496414] brcmfmac: brcmf_sdio_htclk: pmustatus = 0000002a
> [ 7.503873] brcmfmac: brcmf_sdio_htclk: min_res_mask = 0fcaff77
> [ 7.510182] brcmfmac: brcmf_sdio_htclk: max_res_mask = 0fceff77
> # strings /lib/firmware/brcm/brcmfmac4339-sdio.bin | tail -1
> 4339a0-roml/sdio-ag-pool-p2p-pno-pktfilter-keepalive-aoe-sr-mchan-
> proptxstatus-lpc-tdls-autoabn-txbf-
> rcc-wepso-okc-ndoe Version: 6.37.32.28 CRC: 3075f12e Date: Thu 2014-04-
> 03 12:15:31 CST FWID 01-4ae4ad
> 03
>
> Buildroot:
> # dmesg | grep brcmfmac
> [ 5.343118] brcmfmac: brcmf_fw_map_chip_to_name: using
> brcm/brcmfmac4339-sdio.bin for chip 0x00433
> 9(17209) rev 0x000002
> [ 6.420070] brcmfmac: brcmf_sdio_htclk: HT Avail timeout (1000000):
> clkctl 0x50
> [ 6.427722] brcmfmac: brcmf_sdio_htclk: pmucontrol = 01774381
> [ 6.434865] brcmfmac: brcmf_sdio_htclk: pmustatus = 0000002a
> [ 6.441174] brcmfmac: brcmf_sdio_htclk: min_res_mask = 0fcaff77
> [ 6.447379] brcmfmac: brcmf_sdio_htclk: max_res_mask = 0fceff77
> [ 7.502653] brcmfmac: brcmf_sdio_htclk: HT Avail timeout (1000000):
> clkctl 0x50
> [ 7.510200] brcmfmac: brcmf_sdio_htclk: pmucontrol = 01774381
> [ 7.516398] brcmfmac: brcmf_sdio_htclk: pmustatus = 0000002a
> [ 7.523826] brcmfmac: brcmf_sdio_htclk: min_res_mask = 0fcaff77
> [ 7.530117] brcmfmac: brcmf_sdio_htclk: max_res_mask = 0fceff77
> # strings /lib/firmware/brcm/brcmfmac4339-sdio.bin | tail -1
> 4339a0-roml/sdio-ag-pool-autoabn-lpc Version: 6.37.34.28 CRC: a696897b
> Date: Thu 2014-08-28 18:40:12
> PDT FWID 01-a13120fc
Thanks for the info. The pmustatus indeed shows there is no HT clock for
the backplane. Will have to discuss with h/w guys. Meanwhile, can you
try the patch below. It will create a memory dump of the device using
the dev_coredump framework, ie. under /sys/class/devcoredump/. It will
probably create two dumps as the error occurs twice during probe. Just
sent me the first or put it somewhere on internet so I can download it
and have a look at it.
Thanks,
Arend
^ permalink raw reply
* Re: AP6335 with mainline kernel
From: Arend van Spriel @ 2017-11-20 11:12 UTC (permalink / raw)
To: Vanessa Maegima, van.ayumi@gmail.com
Cc: linux-wireless@vger.kernel.org, embed3d@gmail.com
In-Reply-To: <d9a80a75-b3d4-d78e-a5bf-ab31732f040d@broadcom.com>
On 20-11-17 12:03, Arend van Spriel wrote:
> On 17-11-17 16:24, Vanessa Maegima wrote:
>> Hi Arend,
>>
>> On Sex, 2017-11-17 at 13:55 +0100, Arend van Spriel wrote:
>>> On 11/17/2017 12:08 PM, Vanessa Maegima wrote:
>>>>
>>>> Hi Arend,
>>>>
>>>> On Sex, 2017-11-10 at 20:58 +0100, Arend van Spriel wrote:
>>>>>
>>>>> On 10-11-17 13:43, Vanessa Maegima wrote:
>>>>>>
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> On Qui, 2017-09-21 at 12:30 -0300, Vanessa Ayumi Maegima wrote:
>>>>>>>
>>>>>>>
>>>>>>> Hi Arend,
>>>>>>>
>>>>>>> On Thu, Sep 21, 2017 at 4:26 AM, Arend van Spriel
>>>>>>> <arend.vanspriel@broadcom.com> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 20-09-17 21:33, Vanessa Ayumi Maegima wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I am trying to enable Wifi on imx7d-pico using mainline
>>>>>>>>> kernel.
>>>>>>>>> imx7d-pico
>>>>>>>>> has an AP6335 chip.
>>>>>>>>>
>>>>>>>>> I am facing some issues related to the nvram file. I am
>>>>>>>>> using
>>>>>>>>> the
>>>>>>>>> firmware
>>>>>>>>> provided by Buildroot (brcmfmac4339-sdio.bin). I get the
>>>>>>>>> following error:
>>>>>>>>>
>>>>>>>>> [ 8.630380] brcmfmac: brcmf_sdio_htclk: HT Avail
>>>>>>>>> timeout
>>>>>>>>> (1000000):
>>>>>>>>> clkctl 0x50
>>>>>>>>>
>>>>>>>>> I have tried to use the firmware and nvram provided by
>>>>>>>>> TechNexion
>>>>>>>>> but I
>>>>>>>>> get
>>>>>>>>> the same error.
>>>>>>>>>
>>>>>>>>> Is there anyone that could enable Wifi on AP6335 using
>>>>>>>>> kernel
>>>>>>>>> mainline?
>>>>>>>>> What nvram file was used?
>>>>>>>>>
>>>>>>>>> I am able to use Wifi on the board if I use the firmware,
>>>>>>>>> nvram
>>>>>>>>> file and
>>>>>>>>> kernel
>>>>>>>>> provided by TechNexion. They use a 4.1 kernel from NXP
>>>>>>>>> with
>>>>>>>>> the
>>>>>>>>> bcmdhd
>>>>>>>>> driver.
>>>>>>>>>
>>>>>>>>> So I know that the hardware is functional.
>>>>>>>>>
>>>>>>>>> Any suggestions as how to get it working with a 4.13 and
>>>>>>>>> brcmfmac
>>>>>>>>> driver
>>>>>>>>> is
>>>>>>>>> appreciated.
>>>>>>>> So the nvram file is specific to the wifi chipset on your
>>>>>>>> platform
>>>>>>>> so best
>>>>>>>> to stick with the provided one. The "HT Avail timeout" most
>>>>>>>> often
>>>>>>>> is an
>>>>>>>> indication that the firmware crashed. So getting more debug
>>>>>>>> output
>>>>>>>> would
>>>>>>>> help us understand how it ended up like that. Can you build
>>>>>>>> the
>>>>>>>> brcmfmac
>>>>>>>> with CONFIG_BRCMDBG and load the driver using:
>>>>>>>>
>>>>>>>> $ insmod brcmfmac.ko debug=0x1416
>>>>>>> Thanks for the reply!
>>>>>>>
>>>>>>> Here is the log (using 4.14-rc1):
>>>>>>>
>>>>>>> # dmesg | grep brcmfmac
>>>>>>> [ 19.297206] brcmfmac: brcmfmac_module_init No platform
>>>>>>> data
>>>>>>> available.
>>>>>>> [ 19.307075] brcmfmac: brcmf_sdio_probe Enter
>>>>>>> [ 19.308384] brcmfmac: F1 signature read
>>>>>>> @0x18000000=0x16224335
>>>>>>> [ 19.309026] brcmfmac: brcmf_chip_recognition found AXI
>>>>>>> chip:
>>>>>>> BCM4339, rev=2
>>>>>>> [ 19.317115] brcmfmac: brcmf_chip_cores_check [1 ] core
>>>>>>> 0x800:46
>>>>>>> base 0x18000000 wrap 0x18100000
>>>>>>> [ 19.317141] brcmfmac: brcmf_chip_cores_check [2 ] core
>>>>>>> 0x812:46
>>>>>>> base 0x18001000 wrap 0x18101000
>>>>>>> [ 19.317165] brcmfmac: brcmf_chip_cores_check [3 ] core
>>>>>>> 0x83e:4
>>>>>>> base 0x18002000 wrap 0x18102000
>>>>>>> [ 19.317188] brcmfmac: brcmf_chip_cores_check [4 ] core
>>>>>>> 0x83c:4
>>>>>>> base 0x18003000 wrap 0x18103000
>>>>>>> [ 19.317210] brcmfmac: brcmf_chip_cores_check [5 ] core
>>>>>>> 0x81a:20
>>>>>>> base 0x18004000 wrap 0x18104000
>>>>>>> [ 19.317233] brcmfmac: brcmf_chip_cores_check [6 ] core
>>>>>>> 0x829:21
>>>>>>> base 0x18005000 wrap 0x18105000
>>>>>>> [ 19.317256] brcmfmac: brcmf_chip_cores_check [7 ] core
>>>>>>> 0x135:0
>>>>>>> base 0x00000000 wrap 0x18109000
>>>>>>> [ 19.317279] brcmfmac: brcmf_chip_cores_check [8 ] core
>>>>>>> 0x240:0
>>>>>>> base 0x00000000 wrap 0x00000000
>>>>>>> [ 19.317298] brcmfmac: brcmf_chip_set_passive Enter
>>>>>>> [ 19.322232] brcmfmac: brcmf_chip_get_raminfo RAM:
>>>>>>> base=0x180000
>>>>>>> size=786432 (0xc0000) sr=0 (0x0)
>>>>>>> [ 19.322457] brcmfmac: brcmf_chip_setup ccrev=46,
>>>>>>> pmurev=23,
>>>>>>> pmucaps=0x39cc5f17
>>>>>>> [ 19.322481] brcmfmac: brcmf_get_module_param Enter, bus=0,
>>>>>>> chip=17209, rev=2
>>>>>>> [ 19.322504] brcmfmac: brcmf_sdiod_sgtable_alloc nents=35
>>>>>>> [ 19.322531] brcmfmac: brcmf_sdio_kso_init Enter
>>>>>>> [ 19.322618] brcmfmac: brcmf_sdio_drivestrengthinit No SDIO
>>>>>>> driver
>>>>>>> strength init needed for chip 43
>>>>>>> 39 rev 2 pmurev 23
>>>>>>> [ 19.323235] brcmfmac: brcmf_attach Enter
>>>>>>> [ 19.323725] brcmfmac: brcmf_proto_attach Enter
>>>>>>> [ 19.323769] brcmfmac: brcmf_fweh_register event handler
>>>>>>> registered
>>>>>>> for PSM_WATCHDOG
>>>>>>> [ 19.324306] brcmfmac: brcmf_sdio_probe completed!!
>>>>>>> [ 19.324337] brcmfmac: brcmf_fw_map_chip_to_name: using
>>>>>>> brcm/brcmfmac4339-sdio.bin for chip 0x00433
>>>>>>> 9(17209) rev 0x000002
>>>>>>> [ 19.335353] brcmfmac: brcmf_fw_get_firmwares_pcie enter:
>>>>>>> dev=mmc0:0001:1
>>>>>>> [ 19.351787] brcmfmac: brcmf_fw_request_code_done enter:
>>>>>>> dev=mmc0:0001:1
>>>>>>> [ 19.353202] brcmfmac: brcmf_fw_request_nvram_done enter:
>>>>>>> dev=mmc0:0001:1
>>>>>>> [ 19.353424] brcmfmac: brcmf_sdio_firmware_callback Enter:
>>>>>>> dev=mmc0:0001:1, err=0
>>>>>>> [ 19.353814] brcmfmac: brcmf_sdio_download_code_file Enter
>>>>>>> [ 19.388586] brcmfmac: brcmf_sdio_verifymemory Compare RAM
>>>>>>> dl &
>>>>>>> ul
>>>>>>> at 0x00180000; size=493599
>>>>>>> [ 19.546675] brcmfmac: brcmf_sdio_download_nvram Enter
>>>>>>> [ 19.547432] brcmfmac: brcmf_sdio_verifymemory Compare RAM
>>>>>>> dl &
>>>>>>> ul
>>>>>>> at 0x0023f730; size=2256
>>>>>>> [ 19.548665] brcmfmac: brcmf_chip_set_active Enter
>>>>>>> [ 20.562974] brcmfmac: brcmf_sdio_htclk: HT Avail timeout
>>>>>>> (1000000):
>>>>>>> clkctl 0x50
>>>>>>> [ 20.570490] brcmfmac: brcmf_sdio_firmware_callback failed:
>>>>>>> dev=mmc0:0001:1, err=0
>>>>>>> [ 20.570739] brcmfmac: brcmf_sdio_remove Enter
>>>>>>> [ 20.570775] brcmfmac: brcmf_detach Enter
>>>>>>> [ 20.610414] brcmfmac: brcmf_bus_change_state 0 -> 0
>>>>>>> [ 20.610441] brcmfmac: brcmf_sdio_bus_stop Enter
>>>>>>> [ 21.622477] brcmfmac: brcmf_sdio_htclk: HT Avail timeout
>>>>>>> (1000000):
>>>>>>> clkctl 0x50
>>>>>>> [ 21.630912] brcmfmac: brcmf_proto_detach Enter
>>>>>>> [ 21.630967] brcmfmac: brcmf_fweh_unregister event handler
>>>>>>> cleared
>>>>>>> for PSM_WATCHDOG
>>>>>>> [ 22.642457] brcmfmac: brcmf_sdio_htclk: HT Avail timeout
>>>>>>> (1000000):
>>>>>>> clkctl 0x50
>>>>>>> [ 22.680131] brcmfmac: brcmf_chip_set_passive Enter
>>>>>>> [ 22.682580] brcmfmac: brcmf_sdio_remove Disconnected
>>>>>>>
>>>>>> Any suggestions on this?
>>>>> Sorry for not getting back to your earlier email. Thanks for the
>>>>> reminder. So you tried different firmwares, right? Can you
>>>>> provide
>>>>> output of the following command:
>>>>>
>>>>> $ strings firmware.bin | tail -1
>>>>>
>>>>> for the firmwares you tried.
>>>>>
>>>>> Regards,
>>>>> Arend
>>>> Thanks for the reply!
>>>>
>>>> Here's the output:
>>>>
>>>> For Technexion firmware:
>>>>
>>>> # strings /lib/firmware/brcm/brcmfmac4339-sdio.bin | tail -1
>>>> 4339a0-roml/sdio-ag-pool-p2p-pno-pktfilter-keepalive-aoe-sr-mchan-
>>>> proptxstatus-lpc-tdls-autoabn-txbf-
>>>> rcc-wepso-okc-ndoe Version: 6.37.32.28 CRC: 3075f12e Date: Thu
>>>> 2014-04-
>>>> 03 12:15:31 CST FWID 01-4ae4ad
>>>> 03
>>>>
>>>> For linux-firmware and Buildroot firmware:
>>>>
>>>> # strings /lib/firmware/brcm/brcmfmac4339-sdio.bin | tail -1
>>>> 4339a0-roml/sdio-ag-pool-autoabn-lpc Version: 6.37.34.28 CRC:
>>>> a696897b
>>>> Date: Thu 2014-08-28 18:40:12
>>>> PDT FWID 01-a13120fc
>>>>
>>>> In both cases, I am using the nvram provided by Technexion.
>>> That should be fine.
>>>
>>> Can you try the patch below. It would give me more info on state of
>>> firmware.
>>>
>>> Regards,
>>> Arend
>>>
>>> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
>>> b/drivers/ne
>>> index f355612..631c5cb 100644
>>> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
>>> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
>>> @@ -828,8 +828,27 @@ static int brcmf_sdio_htclk(struct brcmf_sdio
>>> *bus,
>>> bool on,
>>> return -EBADE;
>>> }
>>> if (!SBSDIO_CLKAV(clkctl, bus->alp_only)) {
>>> + struct brcmf_core *pmu =
>>> brcmf_chip_get_pmu(bus->ci);
>>> + u32 regaddr;
>>> + u32 val;
>>> +
>>> brcmf_err("HT Avail timeout (%d): clkctl
>>> 0x%02x\n",
>>> PMU_MAX_TRANSITION_DLY, clkctl);
>>> +
>>> + /* DEBUG INFO */
>>> + regaddr = CORE_CC_REG(pmu->base, pmucontrol);
>>> + val = brcmf_sdiod_regrl(bus->sdiodev,
>>> regaddr,
>>> &err);
>>> + brcmf_err(" pmucontrol = %08x\n", val);
>>> + regaddr = CORE_CC_REG(pmu->base, pmustatus);
>>> + val = brcmf_sdiod_regrl(bus->sdiodev,
>>> regaddr,
>>> &err);
>>> + brcmf_err(" pmustatus = %08x\n", val);
>>> + regaddr = CORE_CC_REG(pmu->base,
>>> min_res_mask);
>>> + val = brcmf_sdiod_regrl(bus->sdiodev,
>>> regaddr,
>>> &err);
>>> + brcmf_err(" min_res_mask = %08x\n", val);
>>> + regaddr = CORE_CC_REG(pmu->base,
>>> max_res_mask);
>>> + val = brcmf_sdiod_regrl(bus->sdiodev,
>>> regaddr,
>>> &err);
>>> + brcmf_err(" max_res_mask = %08x\n", val);
>>> +
>>> return -EBADE;
>>> }
>>>
>>>
>>
>> Here's the output for both firmwares:
>>
>> Technexion:
>> # dmesg | grep brcmfmac
>> [ 5.307067] brcmfmac: brcmf_fw_map_chip_to_name: using
>> brcm/brcmfmac4339-sdio.bin for chip 0x00433
>> 9(17209) rev 0x000002
>> [ 6.400792] brcmfmac: brcmf_sdio_htclk: HT Avail timeout (1000000):
>> clkctl 0x50
>> [ 6.408444] brcmfmac: brcmf_sdio_htclk: pmucontrol = 01774381
>> [ 6.415595] brcmfmac: brcmf_sdio_htclk: pmustatus = 0000002a
>> [ 6.421915] brcmfmac: brcmf_sdio_htclk: min_res_mask = 0fcaff77
>> [ 6.428124] brcmfmac: brcmf_sdio_htclk: max_res_mask = 0fceff77
>> [ 7.482668] brcmfmac: brcmf_sdio_htclk: HT Avail timeout (1000000):
>> clkctl 0x50
>> [ 7.490214] brcmfmac: brcmf_sdio_htclk: pmucontrol = 01774381
>> [ 7.496414] brcmfmac: brcmf_sdio_htclk: pmustatus = 0000002a
>> [ 7.503873] brcmfmac: brcmf_sdio_htclk: min_res_mask = 0fcaff77
>> [ 7.510182] brcmfmac: brcmf_sdio_htclk: max_res_mask = 0fceff77
>> # strings /lib/firmware/brcm/brcmfmac4339-sdio.bin | tail -1
>> 4339a0-roml/sdio-ag-pool-p2p-pno-pktfilter-keepalive-aoe-sr-mchan-
>> proptxstatus-lpc-tdls-autoabn-txbf-
>> rcc-wepso-okc-ndoe Version: 6.37.32.28 CRC: 3075f12e Date: Thu 2014-04-
>> 03 12:15:31 CST FWID 01-4ae4ad
>> 03
>>
>> Buildroot:
>> # dmesg | grep brcmfmac
>> [ 5.343118] brcmfmac: brcmf_fw_map_chip_to_name: using
>> brcm/brcmfmac4339-sdio.bin for chip 0x00433
>> 9(17209) rev 0x000002
>> [ 6.420070] brcmfmac: brcmf_sdio_htclk: HT Avail timeout (1000000):
>> clkctl 0x50
>> [ 6.427722] brcmfmac: brcmf_sdio_htclk: pmucontrol = 01774381
>> [ 6.434865] brcmfmac: brcmf_sdio_htclk: pmustatus = 0000002a
>> [ 6.441174] brcmfmac: brcmf_sdio_htclk: min_res_mask = 0fcaff77
>> [ 6.447379] brcmfmac: brcmf_sdio_htclk: max_res_mask = 0fceff77
>> [ 7.502653] brcmfmac: brcmf_sdio_htclk: HT Avail timeout (1000000):
>> clkctl 0x50
>> [ 7.510200] brcmfmac: brcmf_sdio_htclk: pmucontrol = 01774381
>> [ 7.516398] brcmfmac: brcmf_sdio_htclk: pmustatus = 0000002a
>> [ 7.523826] brcmfmac: brcmf_sdio_htclk: min_res_mask = 0fcaff77
>> [ 7.530117] brcmfmac: brcmf_sdio_htclk: max_res_mask = 0fceff77
>> # strings /lib/firmware/brcm/brcmfmac4339-sdio.bin | tail -1
>> 4339a0-roml/sdio-ag-pool-autoabn-lpc Version: 6.37.34.28 CRC: a696897b
>> Date: Thu 2014-08-28 18:40:12
>> PDT FWID 01-a13120fc
>
> Thanks for the info. The pmustatus indeed shows there is no HT clock for
> the backplane. Will have to discuss with h/w guys. Meanwhile, can you
> try the patch below. It will create a memory dump of the device using
> the dev_coredump framework, ie. under /sys/class/devcoredump/. It will
> probably create two dumps as the error occurs twice during probe. Just
> sent me the first or put it somewhere on internet so I can download it
> and have a look at it.
with patch :-(
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
b/drivers/ne
index f355612..f7ded91 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -830,6 +830,11 @@ static int brcmf_sdio_htclk(struct brcmf_sdio *bus,
bool on,
if (!SBSDIO_CLKAV(clkctl, bus->alp_only)) {
brcmf_err("HT Avail timeout (%d): clkctl 0x%02x\n",
PMU_MAX_TRANSITION_DLY, clkctl);
+
+ /* DEBUG INFO */
+ brcmf_debug_create_memdump(bus->sdiodev->bus_if,
+ NULL, 0);
+
return -EBADE;
}
^ permalink raw reply related
* [PATCH] test git-send-email please igore
From: Xinming Hu @ 2017-11-20 11:22 UTC (permalink / raw)
To: Linux Wireless; +Cc: geeksimon, Xinming Hu
test git-send-email please igore
^ permalink raw reply
* Re: [PATCH] ath10k: fix recent bandwidth conversion bug
From: Kalle Valo @ 2017-11-20 11:57 UTC (permalink / raw)
To: Christian Lamparter; +Cc: Sebastian Gottschall, linux-wireless@vger.kernel.org
In-Reply-To: <1666282.PC3nhpCf9f@debian64>
Christian Lamparter <chunkeey@gmail.com> writes:
> On Wednesday, November 1, 2017 9:37:53 PM CET Sebastian Gottschall wrote:
>> a additional array bounds check would be good
>
> Ah, about that:
>
> the bw variable in ath10k_htt_rx_h_rates() is extracted from info2
> in the following way [0]:
> | bw =3D info2 & 3;
>
> the txrate.bw variable in ath10k_update_per_peer_tx_stats() is set by [1]=
:
> | txrate.bw =3D ATH10K_HW_BW(peer_stats->flags);
>
> ATH10K_HW_BW is a macro defined as [2]:
> | #define ATH10K_HW_BW(flags) (((flags) >> 3) & 0x3)
>
> In both cases the bandwidth values already are limited to 0-3 by
> the "and 3" operation.
Until someone changes that part of the code (and the firmware
interface). IMHO a switch is safer as there we don't have any risk of
out of bands access.
--=20
Kalle Valo=
^ permalink raw reply
* Re: ath10k: Fix reported HT MCS rates with NSS > 1
From: Kalle Valo @ 2017-11-20 12:10 UTC (permalink / raw)
To: Peter Oh
Cc: Sven Eckelmann, Sebastian Gottschall, ath10k@lists.infradead.org,
Anilkumar Kolli, linux-wireless@vger.kernel.org
In-Reply-To: <bfcfa3eb-fb45-cb8d-ad87-a5fe6dc96fe3@bowerswilkins.com>
Peter Oh <peter.oh@bowerswilkins.com> writes:
> On 11/06/2017 01:02 AM, Sven Eckelmann wrote:
>> On Montag, 6. November 2017 09:28:42 CET Sebastian Gottschall wrote:
>>> Am 06.11.2017 um 09:23 schrieb Sven Eckelmann:
>>>> On Sonntag, 5. November 2017 10:22:22 CET Sebastian Gottschall wrote:
>>>>> the assumption made in this patch is obviously wrong (at least for mo=
re
>>>>> recent firmwares and 9984)
>>>>> my log is flooded with messages like
>>>>> [208802.803537] ath10k_pci 0001:03:00.0: Invalid VHT mcs 15 peer stat=
s
>>>>> [208805.108515] ath10k_pci 0001:03:00.0: Invalid VHT mcs 15 peer stat=
s
>>>>> [208821.747621] ath10k_pci 0001:03:00.0: Invalid VHT mcs 15 peer stat=
s
>>>>> [208822.516599] ath10k_pci 0001:03:00.0: Invalid VHT mcs 15 peer stat=
s
>>>>> [208841.257780] ath10k_pci 0001:03:00.0: Invalid VHT mcs 15 peer stat=
s
>> [...]
>>>> This patch only splits WMI_RATE_PREAMBLE_HT & WMI_RATE_PREAMBLE_VHT. A=
nd for
>>>> WMI_RATE_PREAMBLE_HT (*not VHT*), it uses a slightly different approac=
h. But
>>>> the WMI_RATE_PREAMBLE_VHT part (which you see in your logs) is basical=
ly
>>>> untouched.
>>> then a question follows up. is this check really neccessary?
>> Until we find out what the heck VHT MCS 15 should mean in this context -=
maybe.
>> But to the message - no, the message is most likely not necessary for ea=
ch
>> received "invalid" peer tx stat.
>
> This validation check expects peer tx stat packets from FW contain
> reasonable values and gives warning if values are different from
> expectation. The problem comes from the assumption that "it always
> contains reasonable stat value" which is wrong at least based on my
> results. For instance, the reason MCS =3D=3D 15 is because all 4 bits of
> mcs potion set to 1, not because FW really sets it to 15
> intentionally. when the mcs potion bits are set to all 1s, the other
> bits such as nss are also set to all 1s.
> Hence it looks FW passed totally invalid stat info to me.
>
> I don't have preference on whether it's better to split VHT and HT
> check or not, but it is more appropriate to change that warning level
> to debug level.
I think we should add a special case to not print the warning if mcs =3D=3D
15 until we figure out what it means.
--=20
Kalle Valo=
^ permalink raw reply
* [PATCH] rtlwifi:rtl8723ae: Fix embedded function names with __func__ Prefer and make it generic by using %s and __func__ to print functions name instead of embedding functions name in print statements
From: venkat.prashanth2498 @ 2017-11-20 12:33 UTC (permalink / raw)
To: gregkh, linux-wireless; +Cc: Larry.Finger, chaoming_li, Venkat Prashanth B U
From: Venkat Prashanth B U <venkat.prashanth2498@gmail.com>
---
drivers/net/wireless/realtek/rtlwifi/rtl8723ae/trx.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/trx.c b/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/trx.c
index f713c72..bd56bb6 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/trx.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/trx.c
@@ -389,7 +389,7 @@ void rtl8723e_tx_fill_desc(struct ieee80211_hw *hw,
if (pci_dma_mapping_error(rtlpci->pdev, mapping)) {
RT_TRACE(rtlpriv, COMP_SEND, DBG_TRACE,
- "DMA mapping error\n");
+ "%s():DMA Mapping Error", __func__);
return;
}
if (mac->opmode == NL80211_IFTYPE_STATION) {
@@ -498,7 +498,7 @@ void rtl8723e_tx_fill_desc(struct ieee80211_hw *hw,
if (ieee80211_is_data_qos(fc)) {
if (mac->rdg_en) {
RT_TRACE(rtlpriv, COMP_SEND, DBG_TRACE,
- "Enable RDG function.\n");
+ "%s():Enable RDG function.\n", __func__);
SET_TX_DESC_RDG_ENABLE(pdesc, 1);
SET_TX_DESC_HTC(pdesc, 1);
}
@@ -537,7 +537,7 @@ void rtl8723e_tx_fill_desc(struct ieee80211_hw *hw,
SET_TX_DESC_BMC(pdesc, 1);
}
- RT_TRACE(rtlpriv, COMP_SEND, DBG_TRACE, "\n");
+ RT_TRACE(rtlpriv, COMP_SEND, DBG_TRACE, "%s():\n", __func__);
}
void rtl8723e_tx_fill_cmddesc(struct ieee80211_hw *hw,
@@ -557,7 +557,7 @@ void rtl8723e_tx_fill_cmddesc(struct ieee80211_hw *hw,
if (pci_dma_mapping_error(rtlpci->pdev, mapping)) {
RT_TRACE(rtlpriv, COMP_SEND, DBG_TRACE,
- "DMA mapping error\n");
+ "%s():DMA Mapping Error", __func__);
return;
}
CLEAR_PCI_TX_DESC_CONTENT(pdesc, TX_DESC_SIZE);
--
1.9.1
^ permalink raw reply related
* [PATCH v1] rtlwifi:rtl8723ae: Fix embedded function names with __func__
From: venkat.prashanth2498 @ 2017-11-20 12:53 UTC (permalink / raw)
To: gregkh, linux-wireless; +Cc: Larry.Finger, chaoming_li, Venkat Prashanth B U
From: Venkat Prashanth B U <venkat.prashanth2498@gmail.com>
Prefer and make it generic by using %s and __func__ to print functions name
instead of embedding functions name in print statements
Signed-off-by: Venkat Prashanth B U <venkat.prashanth2498@gmail.com>
---
drivers/net/wireless/realtek/rtlwifi/rtl8723ae/trx.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/trx.c b/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/trx.c
index f713c72..bd56bb6 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/trx.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/trx.c
@@ -389,7 +389,7 @@ void rtl8723e_tx_fill_desc(struct ieee80211_hw *hw,
if (pci_dma_mapping_error(rtlpci->pdev, mapping)) {
RT_TRACE(rtlpriv, COMP_SEND, DBG_TRACE,
- "DMA mapping error\n");
+ "%s():DMA Mapping Error", __func__);
return;
}
if (mac->opmode == NL80211_IFTYPE_STATION) {
@@ -498,7 +498,7 @@ void rtl8723e_tx_fill_desc(struct ieee80211_hw *hw,
if (ieee80211_is_data_qos(fc)) {
if (mac->rdg_en) {
RT_TRACE(rtlpriv, COMP_SEND, DBG_TRACE,
- "Enable RDG function.\n");
+ "%s():Enable RDG function.\n", __func__);
SET_TX_DESC_RDG_ENABLE(pdesc, 1);
SET_TX_DESC_HTC(pdesc, 1);
}
@@ -537,7 +537,7 @@ void rtl8723e_tx_fill_desc(struct ieee80211_hw *hw,
SET_TX_DESC_BMC(pdesc, 1);
}
- RT_TRACE(rtlpriv, COMP_SEND, DBG_TRACE, "\n");
+ RT_TRACE(rtlpriv, COMP_SEND, DBG_TRACE, "%s():\n", __func__);
}
void rtl8723e_tx_fill_cmddesc(struct ieee80211_hw *hw,
@@ -557,7 +557,7 @@ void rtl8723e_tx_fill_cmddesc(struct ieee80211_hw *hw,
if (pci_dma_mapping_error(rtlpci->pdev, mapping)) {
RT_TRACE(rtlpriv, COMP_SEND, DBG_TRACE,
- "DMA mapping error\n");
+ "%s():DMA Mapping Error", __func__);
return;
}
CLEAR_PCI_TX_DESC_CONTENT(pdesc, TX_DESC_SIZE);
--
1.9.1
^ permalink raw reply related
* RE: [EXT] Marvell Mwifiex wireless driver: mwifiex_pcie broken on Marvell ESPRESSOBin
From: Ganapathi Bhat @ 2017-11-20 13:53 UTC (permalink / raw)
To: Ellie Reeves
Cc: linux-wireless@vger.kernel.org, amitkarwar@gmail.com,
Nishant Sarmukadam, Xinming Hu
In-Reply-To: <6dc0221c-c7ec-d107-02e8-0ab443807e51@gmail.com>
SGkgRWxpZSwNCg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IEhlbGxvLA0KPiBJIG5vdGljZWQgdGhlIE1h
cnZlbGwgTXdpZmlleCB3aXJlbGVzcyBkcml2ZXIgZW5kZWQgdXAgYnJva2VuIHNpbmNlIGtlcm5l
bA0KPiA0LjEzLjAsIGFuZCBpdCBpcyBzdGlsbCB0aGUgY2FzZSB3aXRoIDQuMTQuMCBvbiB0aGUg
TWFydmVsbCBFU1BSRVNTT0Jpbiwgc29sZWQgYnkNCj4gR2xvYmFsc2NhbGUgVGVjaG5vbG9neS4g
SSBib3VnaHQgdGhlIG9mZmljaWFsIHdpcmVsZXNzIGNhcmQgZnJvbSB0aGVtIGF0IHRoZQ0KPiBz
YW1lIHRpbWUgYXMgdGhlIGJvYXJkLiBIb3dldmVyIHNpbmNlIGtlcm5lbCA0LjEzLjAsIHdpZmkg
YXMgcHJvdmlkZWQgdmlhDQo+IG13aWZpZXhfcGNpZSBtb2R1bGUgc3RvcHBlZCB3b3JraW5nLg0K
PiBJIGRvbid0IGhhdmUgbXVjaCBpbmZvIG9uIHRoZSB1c2Vyc3BhY2Ugc2lkZSwgYXMgYWxsIHRo
YXQgaGFwcGVucyBpcyB0aGUNCj4gd2lyZWxlc3MgaW50ZXJmYWNlIGlzIG5ldmVyIGJyb3VnaHQg
dXAgYW5kIHN0YXlzIGluICdOTy1DQVJSSUVSJz8gc3RhdGUNCj4gYWNjb3JkaW5nIHRvICdpcCBh
Jy4gSG93ZXZlciBvbiBrZXJuZWwgc2lkZSwgSSBob3BlIEkgaGF2ZSBzb21lIGluZm8gdGhhdCBh
cmUNCj4gbW9yZSB1c2VmdWwgISA6KSBUaGlzIHdhcyBsb2dnZWQgdmlhIHN5c3RlbWQtam91cm5h
bGQgd2l0aCBkZWJ1ZyB0dXJuZWQgb24NCj4gaW4gbXdpZmlleCBkcml2ZXIuIEkgYW0gd2lsbGlu
ZyB0byB0cnkgYW55dGhpbmcgdG8gZ2V0IHRoaXMga2VybmVsIHdvcmtpbmcsIGFzIGl0J3MNCj4g
YSBsdHMga2VybmVsIGNvbnRyYXJ5IHRvIDQuMTIuMTIgb24gd2hpY2ggSSdtIGZvcmNlZCB0byBy
dW4gZm9yIG5vdy4NCj4NCj4gaHR0cHM6Ly9naXN0LmdpdGh1YnVzZXJjb250ZW50LmNvbS9tay0N
Cj4gZmcvMjdjMjUwNWZkM2JmZmNmMGFmODc3NzdhYWFmYjcxZmUvcmF3L2ZkYTcwZmY5ZjhlYWFi
MjQ4YTEwNGUwMzkyMjMyDQo+IDNjZjJmNDc1NGJmL3RtcC50eHQNCj4NCj4gSSBob3BlIHRoZXNl
IGluZm8gd2lsbCBiZSB1c2VmdWwgaW4gZGVidWdnaW5nLiBJJ20gbmV3IHRvIGFsbCB0aGVzZSBr
ZXJuZWwNCj4gc3R1ZmYsIHNvIEkgbWF5IGhhdmUgcG9zdGVkIHRvIHRoZSB3cm9uZyBwbGFjZSBv
ciBpbiBhIHdyb25nIHdheSwgaWYgc28sDQo+IHBsZWFzZSBsZXQgbWUga25vdy4NCj4NCj4gVGhh
bmtzIGluIGFkdmFuY2UNCj4NCg0KVGhhbmtzIGZvciB0aGUgbm90aWZpY2F0aW9uIGFuZCBsb2dz
LiAgV2UgaGF2ZSBhIGZpeCBmb3IgdGhpcyBpc3N1ZSwgd2hpY2ggd2lsbCBiZSBzZW5kIHVwc3Ry
ZWFtIHNvb24uDQoNCj4gLS0NCj4gRWxsaWUgUmVldmVzDQoNCg0KUmVnYXJkcywNCkdhbmFwYXRo
aQ0K
^ permalink raw reply
* Re: pull-request: iwlwifi 2017-11-19
From: Kalle Valo @ 2017-11-20 15:47 UTC (permalink / raw)
To: Luca Coelho; +Cc: linux-wireless, linuxwifi
In-Reply-To: <1511175768.4011.261.camel@coelho.fi>
Luca Coelho <luca@coelho.fi> writes:
> Here is my first set of fixes for 4.15. More details in the tag
> description.
>
> I have based it on wireless-drivers-next.git, because you didn't update
> wireless-drivers.git yet. Let me know if you want me to rebase once
> you update.
No need to rebase, you did the right thing. And now I have fast forwarded
wireless-drivers to latest net tree.
> I have sent this out before and kbuildbot didn't find any issues.
> Please let me know if there are any issues.
>
> Cheers,
> Luca.
>
>
> The following changes since commit fdd0bd88ceaecf729db103ac8836af5805dd2dc1:
>
> brcmfmac: add CLM download support (2017-11-11 03:04:09 +0200)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes.git tags/iwlwifi-for-kalle-2017-11-19
Pulled, thanks.
--
Kalle Valo
^ permalink raw reply
* [PATCH] mac80211: properly free requested-but-not-started TX agg sessions
From: Johannes Berg @ 2017-11-20 16:01 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
When deleting a station or otherwise tearing down all aggregation
sessions, make sure to delete requested but not yet started ones,
to avoid the following scenario:
* session is requested, added to tid_start_tx[]
* ieee80211_ba_session_work() runs, gets past BLOCK_BA check
* ieee80211_sta_tear_down_BA_sessions() runs, locks &sta->ampdu_mlme.mtx,
e.g. while deleting the station - deleting all active sessions
* ieee80211_ba_session_work() continues since tear down flushes it, and
calls ieee80211_tx_ba_session_handle_start() for the new session, arms
the timer for it
* station deletion continues to __cleanup_single_sta() and frees the
session struct, while the timer is armed
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/mac80211/agg-tx.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/net/mac80211/agg-tx.c b/net/mac80211/agg-tx.c
index 3680b380e70c..5f8ab5be369f 100644
--- a/net/mac80211/agg-tx.c
+++ b/net/mac80211/agg-tx.c
@@ -330,6 +330,11 @@ int ___ieee80211_stop_tx_ba_session(struct sta_info *sta, u16 tid,
spin_lock_bh(&sta->lock);
+ /* free struct pending for start, if present */
+ tid_tx = sta->ampdu_mlme.tid_start_tx[tid];
+ kfree(tid_tx);
+ sta->ampdu_mlme.tid_start_tx[tid] = NULL;
+
tid_tx = rcu_dereference_protected_tid_tx(sta, tid);
if (!tid_tx) {
spin_unlock_bh(&sta->lock);
--
2.14.2
^ permalink raw reply related
* pull-request: mac80211 2017-11-20
From: Johannes Berg @ 2017-11-20 16:06 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-wireless
Hi Dave,
Sorry this is coming now, I had a super hectic time after travel
since I had to catch up after two weeks of being away ...
That's not really an excuse, but I'm asking you anyway to pull
Kees's timer conversions with the fixes since he really wants
to make more changes on top and clean this up properly. I've had
those pending, but in the hectic week after coming back didn't
send the mac80211-next pull request that I should have done.
If you don't want that, let me know and I'll respin without it.
Otherwise, please pull and let me know if there's any problem.
Thanks,
johannes
The following changes since commit 32a72bbd5da2411eab591bf9bc2e39349106193a:
net: vxge: Fix some indentation issues (2017-11-20 11:36:30 +0900)
are available in the git repository at:
ssh://korg/pub/scm/linux/kernel/git/jberg/mac80211.git tags/mac80211-for-davem-2017-11-20
for you to fetch changes up to 33ddd81e2bd5d9970b9f01ab383ba45035fa41ee:
mac80211: properly free requested-but-not-started TX agg sessions (2017-11-20 17:01:31 +0100)
----------------------------------------------------------------
A few things:
* straggler timer conversions from Kees
* memory leak fix in hwsim
* fix some fallout from regdb changes if wireless is built-in
* also free aggregation sessions in startup state when station
goes away, to avoid crashing the timer
----------------------------------------------------------------
Ben Hutchings (1):
mac80211_hwsim: Fix memory leak in hwsim_new_radio_nl()
Johannes Berg (3):
nl80211: don't expose wdev->ssid for most interfaces
cfg80211: initialize regulatory keys/database later
mac80211: properly free requested-but-not-started TX agg sessions
Kees Cook (2):
mac80211: Convert timers to use timer_setup()
mac80211: aggregation: Convert timers to use timer_setup()
drivers/net/wireless/mac80211_hwsim.c | 5 +++-
net/mac80211/agg-rx.c | 41 ++++++++++++-----------------
net/mac80211/agg-tx.c | 49 ++++++++++++++++-------------------
net/mac80211/ibss.c | 7 +++--
net/mac80211/ieee80211_i.h | 3 ++-
net/mac80211/led.c | 11 ++++----
net/mac80211/main.c | 3 +--
net/mac80211/mesh.c | 27 +++++++++----------
net/mac80211/mesh.h | 2 +-
net/mac80211/mesh_hwmp.c | 4 +--
net/mac80211/mesh_pathtbl.c | 3 +--
net/mac80211/mlme.c | 32 ++++++++++-------------
net/mac80211/ocb.c | 10 +++----
net/mac80211/sta_info.c | 15 +++--------
net/mac80211/sta_info.h | 12 +++++++--
net/wireless/nl80211.c | 26 +++++++++++++++++--
net/wireless/reg.c | 42 +++++++++++++++++++-----------
17 files changed, 155 insertions(+), 137 deletions(-)
^ permalink raw reply
* Re: [PATCH] mac80211: Update last_ack status for all except probing frames
From: Johannes Berg @ 2017-11-20 16:09 UTC (permalink / raw)
To: Rajkumar Manoharan, Igor Mitsyanko
Cc: linux-wireless@vger.kernel.org, rmanohar@codeaurora.org
In-Reply-To: <839c3938efae497e9058391fd4be4817@NALASEXR01H.na.qualcomm.com>
On Wed, 2017-11-15 at 19:21 +0000, Rajkumar Manoharan wrote:
> >
> Hmm.. But polling TX/RX counters will not give exact activity time.
Yeah but if you do it every minute, you'll know if it was idle for
roughly 5 minutes, or so... dunno, things could be done.
> Moreover
> It will be useful if STA's last data activity tstamp is logged in station dump. No?
I don't object to adding that, though we should be careful with adding
things and see if we _really_ need them, since they all have a cost.
johannes
^ permalink raw reply
* Re: ath10k: Fix data rx for CCMP-256, GCMP and GCMP-256 in raw mode
From: Kalle Valo @ 2017-11-20 16:15 UTC (permalink / raw)
To: Vasanthakumar Thiagarajan
Cc: ath10k, linux-wireless, Vasanthakumar Thiagarajan
In-Reply-To: <1509079154-22759-1-git-send-email-vthiagar@qti.qualcomm.com>
Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com> wrote:
> Make sure 16-byte mic is removed from the rx data packet
> tail when CCMP-256, GCMP and GCMP-256 ciphers are used
> in raw decap mode. This fixed rx traffic failures in those
> ciphers in raw mode. Split the helper returning crypto
> tail length into two, one to get the ICV length and other
> to get the mic lengh for the cipher to make it clean.
>
> Fixes: 2ea9f12cefe4 ("ath10k: add new cipher suite support")
> Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Patch applied to ath-current branch of ath.git, thanks.
307aeb31af0d ath10k: fix data rx for CCMP-256, GCMP and GCMP-256 in raw mode
--
https://patchwork.kernel.org/patch/10029097/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: wcn36xx: fix iris child-node lookup
From: Kalle Valo @ 2017-11-20 16:25 UTC (permalink / raw)
To: Johan Hovold
Cc: Eugene Krasnikov, Kalle Valo, wcn36xx, linux-wireless, netdev,
linux-kernel, Johan Hovold, stable, Loic Poulain
In-Reply-To: <20171111170532.6110-1-johan@kernel.org>
Johan Hovold <johan@kernel.org> wrote:
> Fix child-node lookup during probe, which ended up searching the whole
> device tree depth-first starting at the parent rather than just matching
> on its children.
>
> To make things worse, the parent mmio node was also prematurely freed.
>
> Fixes: fd52bdae9ab0 ("wcn36xx: Disable 5GHz for wcn3620")
> Cc: Loic Poulain <loic.poulain@linaro.org>
> Signed-off-by: Johan Hovold <johan@kernel.org>
> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Patch applied to ath-current branch of ath.git, thanks.
1967c12896e0 wcn36xx: fix iris child-node lookup
--
https://patchwork.kernel.org/patch/10054441/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Setting TX power on a monitoring interface
From: Peter Große @ 2017-11-20 16:34 UTC (permalink / raw)
To: linux-wireless
[-- Attachment #1: Type: text/plain, Size: 1792 bytes --]
Hi everyone.
The iw tool allows to set TX power settings on network interfaces.
If I try to set the TX power level on a _monitor_ interface, I get
a kernel warning:
------------[ cut here ]------------
WARNING: CPU: 0 PID: 2193 at net/mac80211/driver-ops.h:167
ieee80211_bss_info_change_notify+0x111/0x190 Modules linked in: uvcvideo
videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core
rndis_host cdc_ether usbnet mii tp_smapi(O) thinkpad_ec(O) ohci_hcd vboxpci(O)
vboxnetadp(O) vboxnetflt(O) v boxdrv(O) x86_pkg_temp_thermal kvm_intel kvm
irqbypass iwldvm iwlwifi ehci_pci ehci_hcd tpm_tis tpm_tis_core tpm CPU: 0
PID: 2193 Comm: iw Tainted: G O 4.12.12-gentoo #2 task:
ffff880186fd5cc0 task.stack: ffffc90001b54000 RIP:
0010:ieee80211_bss_info_change_notify+0x111/0x190 RSP: 0018:ffffc90001b57a10
EFLAGS: 00010246 RAX: 0000000000000006 RBX: ffff8801052ce840 RCX:
0000000000000064 RDX: 00000000fffffffc RSI: 0000000000040000 RDI:
ffff8801052ce840 RBP: ffffc90001b57a38 R08: 0000000000000062 R09:
0000000000000000 R10: ffff8802144b5000 R11: ffff880049dc4614 R12:
0000000000040000 R13: 0000000000000064 R14: ffff8802105f0760 R15:
ffffc90001b57b48 FS: 00007f92644b4580(0000) GS:ffff88021e200000(0000)
knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f9263c109f0 CR3: 00000001df850000 CR4: 00000000000406f0
Call Trace:
ieee80211_recalc_txpower+0x33/0x40
ieee80211_set_tx_power+0x40/0x180
nl80211_set_wiphy+0x32e/0x950
Steps to reproduce:
iw dev wlan0 interface add mon0 type monitor
ip link set dev mon0 up
iw dev mon0 set txpower fixed 100
Is that a bug to be fixed?
What would be the correct way of fixing it? Maybe I can provide a patch.
Regards
Peter
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Question on a RTL8812AU driver
From: James Hughes @ 2017-11-20 16:39 UTC (permalink / raw)
To: linux-wireless
Hello all,
I know there been a lot of work done on Realtek drivers in the last
few months, and was wondering whether this will be of use for my
particular issue.
We have a Raspberry Pi that needs to use a USB wireless adaptor
(2001:3314) which uses the rtl8812AU chipset. We have to use this
device as it's the only one that has been qualified for this
particular use case.
We have been using an out of tree driver, I think originally from
Realtek, that works, but after a few days locks up, and often requires
a reboot on the Pi. We do have some mitigation strategies, but it'
would be better to have a working driver. The Pi is, on the whole,
inaccessible.
The OoT driver is from here
https://github.com/diederikdehaas/rtl8812AU and appear quite ancient.
So, I've been looking at the 4.14 staging drivers that do seem to have
support for some realtek devices. However, none of the drivers I have
built recognise the module. The source of rtlwifi does refer to the
8812AU, but only to ignore it. There are other references throughout
the source.,
My question, eventually, is down to figuring out whether any of the
new staging code is destined to work on this device, or am I going to
have to stick with the driver we are currently using which clearly has
a lockup issue that I, in all likelihood, not going to be able to
track down since its takes days for it to occur.
Or if anyone has any suggestions for getting this working, I'm all ears.
TIA
James Hughes, Raspberry Pi.
^ permalink raw reply
* Re: [PATCH v1] rtlwifi:rtl8723ae: Fix embedded function names with __func__
From: Larry Finger @ 2017-11-20 17:04 UTC (permalink / raw)
To: venkat.prashanth2498, gregkh, linux-wireless; +Cc: chaoming_li
In-Reply-To: <1511182437-5870-1-git-send-email-venkat.prashanth2498@gmail.com>
On 11/20/2017 06:53 AM, venkat.prashanth2498@gmail.com wrote:
> From: Venkat Prashanth B U <venkat.prashanth2498@gmail.com>
>
> Prefer and make it generic by using %s and __func__ to print functions name
> instead of embedding functions name in print statements
>
> Signed-off-by: Venkat Prashanth B U <venkat.prashanth2498@gmail.com>
What changed between the first one you sent, and the second that you labeled
"V1". The reviewers should not have to discover that for themselves.
Certainly adding the function name to the printouts might be useful; however,
your commit message says "instead of embedding functions name". That is
obviously not true. None of the changes ever included the function name in the
message.
There are other comments shown below.
>
> ---
> drivers/net/wireless/realtek/rtlwifi/rtl8723ae/trx.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/trx.c b/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/trx.c
> index f713c72..bd56bb6 100644
> --- a/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/trx.c
> +++ b/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/trx.c
> @@ -389,7 +389,7 @@ void rtl8723e_tx_fill_desc(struct ieee80211_hw *hw,
>
> if (pci_dma_mapping_error(rtlpci->pdev, mapping)) {
> RT_TRACE(rtlpriv, COMP_SEND, DBG_TRACE,
> - "DMA mapping error\n");
> + "%s():DMA Mapping Error", __func__);
> return;
> }
> if (mac->opmode == NL80211_IFTYPE_STATION) {
> @@ -498,7 +498,7 @@ void rtl8723e_tx_fill_desc(struct ieee80211_hw *hw,
> if (ieee80211_is_data_qos(fc)) {
> if (mac->rdg_en) {
> RT_TRACE(rtlpriv, COMP_SEND, DBG_TRACE,
> - "Enable RDG function.\n");
> + "%s():Enable RDG function.\n", __func__);
The above line fails to align the continuation statement. Always run
scripts/checkpatch.pl on all your submissions.
> SET_TX_DESC_RDG_ENABLE(pdesc, 1);
> SET_TX_DESC_HTC(pdesc, 1);
> }
> @@ -537,7 +537,7 @@ void rtl8723e_tx_fill_desc(struct ieee80211_hw *hw,
> SET_TX_DESC_BMC(pdesc, 1);
> }
>
> - RT_TRACE(rtlpriv, COMP_SEND, DBG_TRACE, "\n");
> + RT_TRACE(rtlpriv, COMP_SEND, DBG_TRACE, "%s():\n", __func__);
This one is NOT an error condition. Why would the function name be needed here?
If the user has DBG_TRACE turned on, then the function where a COMP_SEND message
is emitted will be known. The code is bloated enough already.
> }
>
> void rtl8723e_tx_fill_cmddesc(struct ieee80211_hw *hw,
> @@ -557,7 +557,7 @@ void rtl8723e_tx_fill_cmddesc(struct ieee80211_hw *hw,
>
> if (pci_dma_mapping_error(rtlpci->pdev, mapping)) {
> RT_TRACE(rtlpriv, COMP_SEND, DBG_TRACE,
> - "DMA mapping error\n");
> + "%s():DMA Mapping Error", __func__);
> return;
> }
> CLEAR_PCI_TX_DESC_CONTENT(pdesc, TX_DESC_SIZE);
>
The patch needs more work. NACK.
Larry
^ 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