Re: [RFC v0 7/8] Input: ims-pcu: use firmware_stat instead of completion

On Tue, Aug 2, 2016 at 12:41 AM, Luis R. Rodriguez wrote: > On Tue, Aug 02, 2016 at 08:53:55AM +0200, Daniel Wagner wrote: >> On 08/02/2016 08:34 AM, Luis R. Rodriguez wrote: >> >On Tue, Aug 02, 2016 at 07:49:19AM +0200, Daniel Wagner wrote: >> >>>The sysdata API's main goal

Re: [RFC v2 0/3] Improve wireless netdev detection

On Sat, 2016-07-09 at 01:16 -0500, Denis Kenzior wrote: > The current mechanism to detect hot-plug / unplug of wireless devices > is > somewhat arcane.  One has to listen to NEW_WIPHY/DEL_WIPHY events > over > nl80211 as well as RTM_NEWLINK / RTM_DELLINK events over rtnl, then > somehow find a

Re: [PATCH v2] nl80211: Receive correct value for NL80211_MESHCONF_HT_OPMODE command

> This patch could over write cfg->ht_opmode even though EINVAL. > I will modify this. > Don't think that actually matters since then it shouldn't be used, but the v3 patch looks good. I'm not sure we should bother to do cross-setting validation? Like, I mean, validating that non-GF and non-HT

Re: [PATCH v3 3/3] mac80211: mesh: fixed HT ies in beacon template

On Wed, 2016-08-03 at 11:51 +0900, Masashi Honma wrote: > On 2016年08月02日 16:27, Johannes Berg wrote: > > This explicitly configures *HT capability* though - that's even the > > name of the parameter. If you enable HT40 in the capability, the > > resulting BSS might still not actually *use* 40 MHz

Re: [PATCH] ath10k: Allow setting coverage class

On 29 July 2016 at 17:09, Ben Greear wrote: > On 07/29/2016 07:52 AM, Benjamin Berg wrote: [...] >> Yeah, I am aware of the fact that the firmware may do internal resets >> from time to time. The interesting question (and one for which I do not >> know the answer) is

Re: [PATCH] mac80211: fix purging multicast PS buffer queue

On Tue, 2016-08-02 at 11:13 +0200, Felix Fietkau wrote: > The code currently assumes that buffered multicast PS frames don't > have > a pending ACK frame for tx status reporting. > However, hostapd sends a broadcast deauth frame on teardown for which > tx > status is requested. This can lead to

Re: [PATCH v2] mac80211: End the MPSP even if EOSP frame was not acked

On Tue, 2016-08-02 at 17:16 +0900, Masashi Honma wrote: > If QoS frame with EOSP (end of service period) subfield=1 sent by > local > peer was not acked by remote peer, local peer did not end the MPSP. > This > prevents local peer from going to DOZE state. And if the remote peer > goes away

Re: [RFC v0 7/8] Input: ims-pcu: use firmware_stat instead of completion

On 08/02/2016 09:41 AM, Luis R. Rodriguez wrote: On Tue, Aug 02, 2016 at 08:53:55AM +0200, Daniel Wagner wrote: On 08/02/2016 08:34 AM, Luis R. Rodriguez wrote: On Tue, Aug 02, 2016 at 07:49:19AM +0200, Daniel Wagner wrote: So you argue for the remoteproc use case with 100+ MB firmware that

Re: [RFC] ath10k: silence firmware file probing warnings

On 02-08-16 16:16, Luis R. Rodriguez wrote: > On Tue, Aug 02, 2016 at 11:10:22AM +, Valo, Kalle wrote: >> "Luis R. Rodriguez" writes: >> >>> I was considering this as a future extension to the firmware API >>> through the new extensible firmware API, the sysdata API. >>

Re: [RFC v0 7/8] Input: ims-pcu: use firmware_stat instead of completion

On 03-08-16 09:42, Dmitry Torokhov wrote: > On Tue, Aug 2, 2016 at 12:41 AM, Luis R. Rodriguez wrote: >> On Tue, Aug 02, 2016 at 08:53:55AM +0200, Daniel Wagner wrote: >>> On 08/02/2016 08:34 AM, Luis R. Rodriguez wrote: On Tue, Aug 02, 2016 at 07:49:19AM +0200, Daniel

Re: [RFC] ath10k: silence firmware file probing warnings

"Luis R. Rodriguez" writes: > On Wed, Aug 03, 2016 at 01:33:31PM +0200, Arend van Spriel wrote: >> On 02-08-16 16:16, Luis R. Rodriguez wrote: >> > On Tue, Aug 02, 2016 at 11:10:22AM +, Valo, Kalle wrote: >> >> "Luis R. Rodriguez" writes: >> >> >> >>> I

Re: [RFC v0 7/8] Input: ims-pcu: use firmware_stat instead of completion

On Wed, Aug 03, 2016 at 05:55:40PM +0200, Luis R. Rodriguez wrote: > > I accept all help and would be glad to make enhancements instead of > the old API through new API. The biggest thing here first I think is > adding devm support, that I think should address what seemed to be > the need to add

Re: [RFC] ath10k: silence firmware file probing warnings

On Wed, Aug 03, 2016 at 01:33:31PM +0200, Arend van Spriel wrote: > On 02-08-16 16:16, Luis R. Rodriguez wrote: > > On Tue, Aug 02, 2016 at 11:10:22AM +, Valo, Kalle wrote: > >> "Luis R. Rodriguez" writes: > >> > >>> I was considering this as a future extension to the

RE: [PATCH] mwifiex: handle edmac vendor command

Hi Kalle, > From: Kalle Valo [mailto:kv...@codeaurora.org] > Sent: Tuesday, May 24, 2016 1:53 AM > To: Amitkumar Karwar > Cc: linux-wireless@vger.kernel.org > Subject: Re: [PATCH] mwifiex: handle edmac vendor command > > Amitkumar Karwar writes: > > > Hi Kalle, > > > >>

Re: [RFC v0 7/8] Input: ims-pcu: use firmware_stat instead of completion

On Wed, Aug 03, 2016 at 01:43:31PM +0200, Arend van Spriel wrote: > On 03-08-16 09:42, Dmitry Torokhov wrote: > > On Tue, Aug 2, 2016 at 12:41 AM, Luis R. Rodriguez > > wrote: > >> On Tue, Aug 02, 2016 at 08:53:55AM +0200, Daniel Wagner wrote: > >>> On 08/02/2016 08:34 AM,

[RESEND PATCH] nl80211: Allow GET_INTERFACE dumps to be filtered

This patch allows GET_INTERFACE dumps to be filtered based on NL80211_ATTR_WIPHY or NL80211_ATTR_WDEV. The documentation for GET_INTERFACE mentions that this is possible: "Request an interface's configuration; either a dump request on a %NL80211_ATTR_WIPHY or ..." However, this behavior has not

[PATCH v3 0/3] Improve wireless netdev detection

The current mechanism to detect hot-plug / unplug of wireless devices is somewhat arcane. One has to listen to NEW_WIPHY/DEL_WIPHY events over nl80211 as well as RTM_NEWLINK / RTM_DELLINK events over rtnl, then somehow find a correlation between these events. This involves userspace sending

Re: [RFC v0 7/8] Input: ims-pcu: use firmware_stat instead of completion

On Wed, Aug 03, 2016 at 12:42:14AM -0700, Dmitry Torokhov wrote: > On Tue, Aug 2, 2016 at 12:41 AM, Luis R. Rodriguez wrote: > > On Tue, Aug 02, 2016 at 08:53:55AM +0200, Daniel Wagner wrote: > >> On 08/02/2016 08:34 AM, Luis R. Rodriguez wrote: > >> >On Tue, Aug 02, 2016 at

Re: [PATCH] ath6kl: enable firmware crash dumps on the AR6004

On Wed, Aug 3, 2016 at 1:43 PM, wrote: > From: Dan Kephart > > The firmware crash dumps on the 6004 are the same as the 6003. Remove the > statement guarding it from dumping on the 6004. Renamed the > REG_DUMP_COUNT_AR6003 to reflect support on

Re: [PATCH] wl3501_cs: Add spinlock to wl3501_reset

On Tuesday 02 August 2016 03:11 PM, Pavel Andrianov wrote: > Likely wl3501_reset should acquire spinlock as wl3501_{open, close}. > One of calls of wl3501_reset has been already protected. > The others were unprotected and might lead to a race condition. > The patch adds spinlock into the

Re: [PATCH] ath9k: fix GPIO mask for AR9462 and AR9565

Sorry, try the patch. AR5416 will invoke ath9k_hw_gpio_get() before gpio initialized correctly. Thanks, Miaoqing From: Valo, Kalle Sent: Wednesday, August 3, 2016 9:54 PM To: Stefan Lippers-Hollmann; miaoq...@codeaurora.org Cc:

Re: [RFC v0 7/8] Input: ims-pcu: use firmware_stat instead of completion

On Tue 02 Aug 00:41 PDT 2016, Luis R. Rodriguez wrote: > On Tue, Aug 02, 2016 at 08:53:55AM +0200, Daniel Wagner wrote: > > On 08/02/2016 08:34 AM, Luis R. Rodriguez wrote: > > >On Tue, Aug 02, 2016 at 07:49:19AM +0200, Daniel Wagner wrote: > > >>>The sysdata API's main goal rather is to provide

Re: [RFC v0 7/8] Input: ims-pcu: use firmware_stat instead of completion

On Wed, Aug 03, 2016 at 09:18:21AM -0700, Dmitry Torokhov wrote: > On Wed, Aug 03, 2016 at 05:55:40PM +0200, Luis R. Rodriguez wrote: > > > > I accept all help and would be glad to make enhancements instead of > > the old API through new API. The biggest thing here first I think is > > adding

Re: [RFC] ath10k: silence firmware file probing warnings

On Wed, Aug 03, 2016 at 03:04:39PM +, Valo, Kalle wrote: > "Luis R. Rodriguez" writes: > > > On Wed, Aug 03, 2016 at 01:33:31PM +0200, Arend van Spriel wrote: > >> On 02-08-16 16:16, Luis R. Rodriguez wrote: > >> > On Tue, Aug 02, 2016 at 11:10:22AM +, Valo, Kalle

Re: [RFC v0 7/8] Input: ims-pcu: use firmware_stat instead of completion

On Wed, Aug 03, 2016 at 05:55:40PM +0200, Luis R. Rodriguez wrote: > On Wed, Aug 03, 2016 at 08:57:09AM +0200, Daniel Wagner wrote: > > On 08/02/2016 09:41 AM, Luis R. Rodriguez wrote: > > >On Tue, Aug 02, 2016 at 08:53:55AM +0200, Daniel Wagner wrote: > > >>On 08/02/2016 08:34 AM, Luis R.

Re: [RFC v0 7/8] Input: ims-pcu: use firmware_stat instead of completion

On Wed, Aug 03, 2016 at 08:57:09AM +0200, Daniel Wagner wrote: > On 08/02/2016 09:41 AM, Luis R. Rodriguez wrote: > >On Tue, Aug 02, 2016 at 08:53:55AM +0200, Daniel Wagner wrote: > >>On 08/02/2016 08:34 AM, Luis R. Rodriguez wrote: > >>>On Tue, Aug 02, 2016 at 07:49:19AM +0200, Daniel Wagner

[patch] ath9k: indent an if statement

It looks like this code is correct, but it just needs to be indented a bit. Signed-off-by: Dan Carpenter diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c index a394622..eb00724 100644 ---

Re: [RFC v0 7/8] Input: ims-pcu: use firmware_stat instead of completion

On 03-08-16 17:35, Dmitry Torokhov wrote: >> In my opinion the kernel should provide functionality to user-space and >> > user-space providing functionality to the kernel should be avoided. > Why? We have bunch of stuff running in userspace for the kernel. Fuse > for example. I am sure there are

Re: [RFC v0 7/8] Input: ims-pcu: use firmware_stat instead of completion

On Wed, Aug 03, 2016 at 10:39:55AM -0700, Bjorn Andersson wrote: > On Tue 02 Aug 00:41 PDT 2016, Luis R. Rodriguez wrote: > > > On Tue, Aug 02, 2016 at 08:53:55AM +0200, Daniel Wagner wrote: > > > On 08/02/2016 08:34 AM, Luis R. Rodriguez wrote: > > > >On Tue, Aug 02, 2016 at 07:49:19AM +0200,

Re: [RFC] ath10k: silence firmware file probing warnings

On 03-08-16 19:10, Luis R. Rodriguez wrote: > On Wed, Aug 03, 2016 at 03:04:39PM +, Valo, Kalle wrote: >> "Luis R. Rodriguez" writes: >> >>> On Wed, Aug 03, 2016 at 01:33:31PM +0200, Arend van Spriel wrote: On 02-08-16 16:16, Luis R. Rodriguez wrote: > On Tue,

Re: [PATCH] ath9k: fix GPIO mask for AR9462 and AR9565

Stefan Lippers-Hollmann writes: > Hi > > On 2016-06-03, miaoq...@codeaurora.org wrote: >> From: Miaoqing Pan >> >> The incorrect GPIO mask cause kernel warning, when AR9462 access GPIO11. >> Also fix the mask for AR9565. > [...] > > I think I'm seeing a

Re: [v4] Fix to avoid IS_ERR_VALUE and IS_ERR abuses on 64bit systems.

On Wednesday 03 August 2016 01:27 AM, Scott Wood wrote: On 08/02/2016 10:34 AM, arvind Yadav wrote: On Tuesday 02 August 2016 01:15 PM, Arnd Bergmann wrote: On Monday, August 1, 2016 4:55:43 PM CEST Scott Wood wrote: On 08/01/2016 02:02 AM, Arnd Bergmann wrote: diff --git

[PATCH v3 1/3] nl80211: Add nl80211_notify_iface

This function emits NL80211_CMD_NEW_INTERFACE or NL80211_CMD_DEL_INTERFACE events. This is meant to be used by the core to notify userspace applications such as wpa_supplicant when a netdev related to a wireless device has been added or removed. Signed-off-by: Denis Kenzior

[PATCH v3 3/3] core: Always notify when wireless netdev is removed

This change alters the semantics of NL80211_CMD_DEL_INTERFACE events by always sending this event whenever a net_device object associated with a wdev is destroyed. Prior to this change, this event was only emitted as a result of NL80211_CMD_DEL_INTERFACE command sent from userspace. This allows

[PATCH v3 2/3] core: Always notify of new wireless netdevs

This change alters the semantics of NL80211_CMD_NEW_INTERFACE events by always sending this event whenever a new net_device object associated with a wdev is registered. Prior to this change, this event was only sent as a result of NL80211_CMD_NEW_INTERFACE command sent from userspace. This

Re: [RFC v0 7/8] Input: ims-pcu: use firmware_stat instead of completion

On Wed 03 Aug 08:55 PDT 2016, Luis R. Rodriguez wrote: > On Wed, Aug 03, 2016 at 08:57:09AM +0200, Daniel Wagner wrote: > > On 08/02/2016 09:41 AM, Luis R. Rodriguez wrote: [..] > > Not sure if I get you here correctly. Is the 'system configurable > > deterministic file' is a knob which

Re: [PATCH v2] nl80211: Receive correct value for NL80211_MESHCONF_HT_OPMODE command

On 2016年08月03日 15:52, Johannes Berg wrote: I'm actually half thinking that we could just remove all restrictions on this and allow any u16 value of this field, and rely on wpa_supplicant to do the right thing... Then we don't have to update this if we ever want to do something new either. What

Re: PROBLEM: network data corruption (bisected to e5a4b0bb803b)

Christian Lamparter wrote: > > One thing I noticed in your previous post is that you "might" not have > draft-802.11n enabled. Do you see any "disabling HT/VHT due to WEP/TKIP use." > in your dmesg logs? If so, check if you can force your AP to use WPA2 > with CCMP/AES only. > Yes, I've had

[PATCH] ath6kl: enable firmware crash dumps on the AR6004

From: Dan Kephart The firmware crash dumps on the 6004 are the same as the 6003. Remove the statement guarding it from dumping on the 6004. Renamed the REG_DUMP_COUNT_AR6003 to reflect support on both chips. Signed-off-by: Dan Kephart ---

Re: PROBLEM: network data corruption (bisected to e5a4b0bb803b)

On Wednesday, August 3, 2016 3:49:26 AM CEST Alan Curry wrote: > Al Viro wrote: > > > > Which just might mean that we have *three* issues here - > > (1) buggered __copy_to_user_inatomic() (and friends) on some sparcs > > (2) your ssl-only corruption > > (3) Alan's x86_64 corruption on

Re: [PATCH 1/1 v2] rtlwifi: remove superfluous condition

Heinrich Schuchardt writes: > If sta == NULL, the changed line will not be reached. > So no need to check that sta != NULL here. > > v2: > fix typo > > Signed-off-by: Heinrich Schuchardt > Acked-by: Larry Finger > --- >

[bug report] NFC: nfcsim: Make use of the Digital layer

Hello Thierry Escande, The patch 204bddcb508f: "NFC: nfcsim: Make use of the Digital layer" from Jun 23, 2016, leads to the following static checker warning: drivers/nfc/nfcsim.c:485 nfcsim_init() error: we previously assumed 'link0' could be null (see line 457)