Re: [PATCH] rtl8xxxu: Stop log spam from each successful interrupt

On 09/17/2016 03:59 PM, Jes Sorensen wrote: Larry Finger writes: As soon as debugging is turned on, the logs are filled with messages reporting the interrupt status. As this quantity is usually zero, this output is not needed. In fact, there will be a report if the

Re: [PATCH 2/4] carl9170: fix debugfs crashes

On Sat, Sep 17, 2016 at 09:43:02PM +0200, Christian Lamparter wrote: > Ben Greear reported: > > I see lots of instability as soon as I load up the carl9710 NIC. > > My application is going to be poking at it's debugfs files... > > > > BUG: KASAN: slab-out-of-bounds in

Re: [PATCH] rtl8xxxu: Stop log spam from each successful interrupt

Larry Finger writes: > As soon as debugging is turned on, the logs are filled with messages > reporting the interrupt status. As this quantity is usually zero, this > output is not needed. In fact, there will be a report if the status is > not zero, thus the debug line

Re: [PATCH] rtl8xxxu: Stop log spam from each successful interrupt

Joe Perches writes: > On Sat, 2016-09-17 at 12:09 -0500, Larry Finger wrote: >> As soon as debugging is turned on, the logs are filled with messages >> reporting the interrupt status. As this quantity is usually zero, this >> output is not needed. In fact, there will be a report

[PATCH 3/4] b43: fix debugfs crash

This patch fixes a crash that happens because b43's debugfs code expects file->f_op to be a pointer to its own b43_debugfs_fops struct. This is no longer the case since commit 9fd4dcece43a ("debugfs: prevent access to possibly dead file_operations at file open") Reviewed-by: Nicolai Stange

[PATCH 4/4] b43legacy: fix debugfs crash

This patch fixes a crash that happens because b43legacy's debugfs code expects file->f_op to be a pointer to its own b43legacy_debugfs_fops struct. This is no longer the case since commit 9fd4dcece43a ("debugfs: prevent access to possibly dead file_operations at file open") Reviewed-by: Nicolai

[PATCH 1/4] debugfs: introduce a public file_operations accessor

This patch introduces an accessor which can be used by the users of debugfs (drivers, fs, ...) to get the original file_operations struct. It also removes the REAL_FOPS_DEREF macro in file.c and converts the code to use the public version. Previously, REAL_FOPS_DEREF was only available within the

[PATCH 2/4] carl9170: fix debugfs crashes

Ben Greear reported: > I see lots of instability as soon as I load up the carl9710 NIC. > My application is going to be poking at it's debugfs files... > > BUG: KASAN: slab-out-of-bounds in carl9170_debugfs_read+0xd5/0x2a0 > [carl9170] at addr 8801bc1208b0 > Read of size 8 by task

rtl8821ae WiFi does not work

Hi, I have a rtl8821ae wifi and it is almost impossible to use. Please help. Here are the details: [1.] One line summary of the problem: rtl8821ae WiFi does not work [2.] Full description of the problem/report: Download speed drops down to 50KB/s or less really often. Instead of 2.5 MB/s

Re: [PATCH] rtl8xxxu: Stop log spam from each successful interrupt

On Sat, 2016-09-17 at 12:09 -0500, Larry Finger wrote: > As soon as debugging is turned on, the logs are filled with messages > reporting the interrupt status. As this quantity is usually zero, this > output is not needed. In fact, there will be a report if the status is > not zero, thus the debug

Re: ath9k_htc kernel driver regression affecting throughput

Am 17.09.2016 um 18:14 schrieb Oleksij Rempel: > Am 17.09.2016 um 17:52 schrieb bruce m beach: Hm.. found here one report about bad perfomance on this driver https://ubuntuforums.org/showthread.php?t=2312343 affected persons seems to use WEP encryption. What

Re: ath9k_htc kernel driver regression affecting throughput

Am 17.09.2016 um 17:52 schrieb bruce m beach: >>> Hm.. found here one report about bad perfomance on this driver >>> https://ubuntuforums.org/showthread.php?t=2312343 >>> >>> affected persons seems to use WEP encryption. >>> >>> What encryption do are you using? > > I just wish I could do some

[PATCH 5/5] wlcore: wl18xx: Use chip specific configuration firmware

Use the wl18xx specific config firmware we now have available. Signed-off-by: Tony Lindgren --- drivers/net/wireless/ti/wl18xx/main.c | 19 ++- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/drivers/net/wireless/ti/wl18xx/main.c

[PATCHv2 0/5] Fix wlcore config firwmare annoyances

Hi all, Here are some patches to fix the firmware loading for wl12xx/wl18xx when the same rootfs is used on multiple WLAN chip variants. Changes since v1: - Fix copy paste typo for the SPI related changes as noted by Kalle Valo - Fix uninitialized ret variable warning as noted by Kalle Valo

[PATCH 1/5] wlcore: Prepare family to fix nvs file handling

Move struct wilink_family_data to be available for all TI WLAN variants. And fix familiy typo, it should be just family. Looks like wl12xx use two different nvs.bin files and wl18xx uses a different conf.bin file. Signed-off-by: Tony Lindgren ---

[PATCH 3/5] wlcore: spi: Populate config firmware data

Configure the config firmware names and make it available in platform data. Let's also fix the order of the struct wilink_family_data while at it. Signed-off-by: Tony Lindgren --- drivers/net/wireless/ti/wlcore/spi.c | 42 1 file changed,

[PATCH 4/5] wlcore: Fix config firmware loading issues

Booting multiple wl12xx and wl18xx devices using the same rootfs is a pain. You currently have to symlink the right nvs file depending on the wl12xx type. For example, with wl1271-nvs.bin being a symlink to wl127x-nvs.bin by default and trying to bring up a wl128x based device: wlcore: ERROR nvs

[PATCH 2/5] wlcore: sdio: Populate config firmware data

Configure the config firmware names and make it available in platform data. Signed-off-by: Tony Lindgren --- drivers/net/wireless/ti/wlcore/sdio.c | 76 ++- 1 file changed, 47 insertions(+), 29 deletions(-) diff --git

ath9k_htc kernel driver regression affecting throughput

>> Hm.. found here one report about bad perfomance on this driver >> https://ubuntuforums.org/showthread.php?t=2312343 >> >> affected persons seems to use WEP encryption. >> >> What encryption do are you using? I just wish I could do some testing on a single machine. Every test suite I've seen

Re: [PATCH 0/5] Fix wlcore config firwmare annoyances

* Kalle Valo [160917 08:25]: > Tony Lindgren writes: > > > Hi all, > > > > Here are some patches to fix the firmware loading for wl12xx/wl18xx > > when the same rootfs is used on multiple WLAN chip variants. > > > > Regards, > > > > Tony > > > > Tony

Re: mwifiex: fix error handling in mwifiex_create_custom_regdomain

Bob Copeland wrote: > smatch reports: > > sta_cmdresp.c:1053 mwifiex_create_custom_regdomain() warn: possible memory > leak of 'regd' > > Indeed, mwifiex_create_custom_regdomain() returns NULL in the > case that channel is missing in the TLV without freeing regd. > >

Re: [PATCH 0/5] Fix wlcore config firwmare annoyances

Tony Lindgren writes: > Hi all, > > Here are some patches to fix the firmware loading for wl12xx/wl18xx > when the same rootfs is used on multiple WLAN chip variants. > > Regards, > > Tony > > Tony Lindgren (5): > wlcore: Prepare family to fix nvs file handling > wlcore:

Re: [1/1] rtl8xxxu: Implement 8192e specific power down sequence

Jes Sorensen wrote: > From: Jes Sorensen > > This powers down the 8192e correctly, or at least to the point where > the firmware will load again, when reloading the driver module. > > Signed-off-by: Jes Sorensen

Re: [PATCH v2 RESEND] qtnfmac: announcement of new FullMAC driver for Quantenna chipsets

Johannes Berg writes: > On Sat, 2016-09-17 at 18:01 +0300, Kalle Valo wrote: >>  >> Sorry, I was unclear. I meant the whole file > [...] Argh, I meant the whole driver of course, not just the file. > Ah, ok - yeah, I think you're right - I think the supported_band

Re: pull-request: iwlwifi-next 2016-09-15-2

Luca Coelho writes: > This is v2 of my pull-request.  I have fixed the compilation error with > alpha (and possibly other) platforms. > > I'll send v2 of the changed patch as a reply to this email. > > Let me know if everything's fine (or not). :) > > Luca. > > > The following

Re: [PATCH v2 RESEND] qtnfmac: announcement of new FullMAC driver for Quantenna chipsets

On Sat, 2016-09-17 at 18:01 +0300, Kalle Valo wrote: >  > Sorry, I was unclear. I meant the whole file [...] Ah, ok - yeah, I think you're right - I think the supported_band ones can be, for example, and probably others as well. johannes

Re: [PATCH v2 RESEND] qtnfmac: announcement of new FullMAC driver for Quantenna chipsets

Johannes Berg writes: >> I guess some of these static variables could be also const, but >> didn't check. > > I think both bitrates and channels can't be, due to cfg80211 writing > some (global) flags there on init. Sorry, I was unclear. I meant the whole file, not

Re: [PATCH v2 RESEND] qtnfmac: announcement of new FullMAC driver for Quantenna chipsets

> drivers/net/wireless/quantenna/qtnfmac/event.c: In function > `qtnf_event_handle_scan_complete': > drivers/net/wireless/quantenna/qtnfmac/event.c:342:2: warning: > passing argument 2 of `cfg80211_scan_done' makes pointer from integer > without a cast [enabled by default] Yes,

Re: pull-request: iwlwifi 2016-09-15

Luca Coelho writes: > Hi Kalle, > > Here is one more patch intended for 4.8.  It's small and low risk, just > moving some lines of code around, to prevent a firmware crash in > certain situations. > > Let me know if everything's fine (or not). :) > > Luca. > > > The following

Re: [PATCH v2 RESEND] qtnfmac: announcement of new FullMAC driver for Quantenna chipsets

Igor Mitsyanko writes: > thank for review and sorry for long delays in replies. A parallel > thread with Dave a discussion was initiated regarding HW platform > samples availability. Current driver implementation supports a newer > QSR10G platform, which

Re: [PATCH v2 RESEND] qtnfmac: announcement of new FullMAC driver for Quantenna chipsets

writes: > From: Avinash Patil > > This patch adds support for new FullMAC WiFi driver for Quantenna > QSR10G chipsets. > > QSR10G is Quantenna's 8x8, 160M, 11ac offering. > QSR10G supports 2 simultaneous WMACs- one 5G and one 2G. 5G WMAC

Re: pull-request: wireless-drivers-next 2016-09-15

From: Kalle Valo Date: Thu, 15 Sep 2016 18:09:21 +0300 > here's the first pull request for 4.9. The ones I want to point out are > the FIELD_PREP() and FIELD_GET() macros added to bitfield.h, which are > reviewed by Linus, and make it possible to remove util.h from mt7601u.

Re: [athk9] beacon.c:642 ath9k_calculate_summary_state dump

Vidar Haarr writes: > I'm seeing the message below spammed continously in journald, even > with 4.8-rc6. It's so bad that it throttles the CPU performance every > few seconds. > > I found https://patchwork.kernel.org/patch/9247699/ which seems related. [...] > sep. 17

[athk9] beacon.c:642 ath9k_calculate_summary_state dump

Hi, I'm seeing the message below spammed continously in journald, even with 4.8-rc6. It's so bad that it throttles the CPU performance every few seconds. I found https://patchwork.kernel.org/patch/9247699/ which seems related. I am not subscribed to linux-wireless. First, here's some system