Re: [PATCH v2] mt76x2: init: disable all pending tasklets during device removal

On 2018-01-23 10:03, Lorenzo Bianconi wrote: > There is a possible race in mt76x2_stop_hardware() since pre_tbtt and > dfs tasklets could run during driver cleanup. Fix it disabling all > pending tasklets during device removal > > Signed-off-by: Lorenzo Bianconi

[PATCH v2] mt76x2: init: disable all pending tasklets during device removal

There is a possible race in mt76x2_stop_hardware() since pre_tbtt and dfs tasklets could run during driver cleanup. Fix it disabling all pending tasklets during device removal Signed-off-by: Lorenzo Bianconi --- Changes since v1: - add proper commit message - squash

Re: [PATCH] mt76x2: fix WMM parameter configuration

On 2018-01-17 12:01, Lorenzo Bianconi wrote: > Fix hw queue configuration since mt76x2 devices use a reverse queue > enumeration respect to mac80211 one: > - 0: AC_BE > - 1: AC_BK > - 2: AC_VI > - 3: AC_VO > > The issue can be reproduced sending two concurrent flow using > two separate

Re: [PATCH 1/2] cfg80211: Add support to notify station's opmode change to userspace

Hi Johannes, Thanks for the code review comments, I'll address these comments and send V2 patchset. /** + * enum wiphy_opmode_info_flag - opmode information flags + * + * @MAX_BW_CHANGED: Max Bandwidth changed + * @SMPS_MODE_CHANGED: SMPS mode changed + * @N_SS_CHANGED: max N_SS (number of

Re: ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue...?

On Thu, Jan 11, 2018 at 05:00:14PM +0100, Tom Psyborg wrote: > does not help as expected. there was even a crash: You mean the kernel hangs ? There is a WARNING at the end of the logs but it's from ath9k not from rt2800. > [ 92.559018] ieee80211 phy1: rt2800mmio_txstatus_is_spurious: Warning

Re: ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue...?

On Mon, Jan 22, 2018 at 06:45:57AM +0100, Enrico Mioso wrote: > Crash happening here also in the WL-330n3G device; unfortunately, no messages > to report. > Regarding your hypothesis regardingthe firmware not being able to communicate > a problem regarding it's inability to send frames: around

Re: iwlegacy: Please change led_mode default to _LED_RF_STATE

On Tue, 2018-01-23 at 12:55 +0100, c...@abwesend.de wrote: > Good morning, :-) > > In iwlegacy/common.c, when module_param(led_mode) is not set by the > user (i.e. it is 0=IL_LED_DEFAULT), then il_leds_init() uses the > device's cfg->led_mode as the default. That inheritance is ok for > devices

Re: ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Dropping frame due to full tx queue...?

good morning! First of all - thank you very much for your help and patience: it's not common to find kind people, and people that cares to help with some older hardware (in my case). So, regarding the WL-330N3G, I think you are right. And after all, thinking about it, my previous reasoning

Re: iwlegacy: Please change led_mode default to _LED_RF_STATE

On Tue, 2018-01-23 at 15:07 +0100, Stanislaw Gruszka wrote: > > Some of iwlwifi devices have BLINK and some other have RF_STATE > as default. I don't know why is that, but I assume there is reason > for it. Not really. As I remember, the reason was basically marketing having sold the devices

Re: WARNING in check_flush_dependency

On Mon, 2018-01-22 at 23:39 -0800, syzbot wrote: > Hello, > > syzbot hit the following crash on upstream commit > 0d665e7b109d512b7cae3ccef6e8654714887844 (Fri Jan 19 12:49:24 2018 +) > mm, page_vma_mapped: Drop faulty pointer arithmetics in check_pte() > > So far this crash happened 23

[PATCH] mac80211_hwsim: don't use WQ_MEM_RECLAIM

From: Johannes Berg We're obviously not part of a memory reclaim path, so don't set the flag. Signed-off-by: Johannes Berg --- drivers/net/wireless/mac80211_hwsim.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH v2] mac80211_hwsim: don't use WQ_MEM_RECLAIM

From: Johannes Berg We're obviously not part of a memory reclaim path, so don't set the flag. This also causes a warning in check_flush_dependency() since we end up in a code path that flushes a non-reclaim workqueue, and we shouldn't do that if we were really part of

Re: wcn36xx: release resources in case of error

On 1/22/2018 8:14 AM, Kalle Valo wrote: > Ramon Fried wrote: > >> wcn36xx_dxe_init() doesn't check for the return value >> of wcn36xx_dxe_init_descs(). >> This patch releases the resources in case an error ocurred. >> >> Signed-off-by: Ramon Fried

Fwd: iwlegacy: Please change led_mode default to _LED_RF_STATE

> Emmanuel and I are not the maintainers of iwlegacy, so I'm adding > the linux-wireless mailing list and Stanislaw, who is the actual > maintainer. The issue is the same for iwlwifi: while most iwiwifi device cfgs have led_mode = IWL_LED_RF_STATE iwlwifi/cfg/1000.c and iwlwifi/cfg/5000.c have

PATCH for nfcst (out of tree stuff) was Re: [linux-nfc] st95hf driver not working with neard 0.16

Hi Am Montag, 22. Januar 2018, 17:51:51 CET schrieb Tim Sander: > When using the st,stnfc driver linked at the beginning it works with tags: > nfctool -d nfc0 -p initiate > Start polling on nfc0 as initiator > > Targets found for nfc0 > Tags: [ tag3 ] > Devices: [ ] > > But as soon as i

Re: iwlegacy: Please change led_mode default to _LED_RF_STATE

On Tue, Jan 23, 2018 at 03:24:15PM +0200, Luciano Coelho wrote: > On Tue, 2018-01-23 at 12:55 +0100, c...@abwesend.de wrote: > > Good morning, :-) > > > > In iwlegacy/common.c, when module_param(led_mode) is not set by the > > user (i.e. it is 0=IL_LED_DEFAULT), then il_leds_init() uses the > >

[PATCH v2] wcn36xx: release resources in case of error

wcn36xx_dxe_init() doesn't check for the return value of wcn36xx_dxe_init_descs(). This patch releases the resources in case an error ocurred. Change-Id: I924bd7489b60243c0a0cbaa716caf924f11d7587 Signed-off-by: Ramon Fried --- drivers/net/wireless/ath/wcn36xx/dxe.c | 48