On 12/15/2016 06:15 AM, Michael S. Tsirkin wrote:
> That's the default now, no need for makefiles to set it.
>
> Signed-off-by: Michael S. Tsirkin
> ---
[...]
> drivers/net/can/Makefile | 1 -
For drivers/net/can/Makefile:
Acked-by: Marc Kleine-Budde
regards,
(Adding Luis because he has been working on request_firmware() lately)
Pali Rohár writes:
>> > So no, there is no argument against... request_firmware() in
>> > fallback mode with userspace helper is by design blocking and
>> > waiting for userspace. But waiting for some change in DTS in
>> > ke
Martin Blumenstingl writes:
> There are two types of swapping the EEPROM data in the ath9k driver.
> Before this series one type of swapping could not be used without the
> other.
>
> The first type of swapping looks at the "magic bytes" at the start of
> the EEPROM data and performs swab16 on th
Toke Høiland-Jørgensen wrote:
> This reworks the ath9k driver to schedule transmissions to connected
> stations in a way that enforces airtime fairness between them. It
> accomplishes this by measuring the time spent transmitting to or
> receiving from a station at TX and RX completion, and account
Toke Høiland-Jørgensen wrote:
> These are one-line functions that just call spin_lock/unlock_bh(); turn
> them into static inlines to avoid the function call overhead.
>
> Signed-off-by: Toke Høiland-Jørgensen
Patch applied to ath-next branch of ath.git, thanks.
5c4607ebaabe ath9k: Turn ath_txq
Hello.
On 15/12/16 06:15, Michael S. Tsirkin wrote:
__bitwise__ used to mean "yes, please enable sparse checks
unconditionally", but now that we dropped __CHECK_ENDIAN__
__bitwise is exactly the same.
There aren't many users, replace it by __bitwise everywhere.
Signed-off-by: Michael S. Tsirkin
On Thu, 2016-12-15 at 11:30 +0530, Vasanthakumar Thiagarajan wrote:
> This patch set adds a new data path to offload 802.11 header
> encap/decap to driver or hardware. Drivers having support
> for ieee80211 header encap/decap and other offload functionalities
> which can't be done before encap or a
> Drivers advertising this capability should also implement other
> functionalities which deal with 802.11 frame format like below
> - ADDBA/DELBA offload
This shouldn't be necessary.
> - Hardware rate control
Neither is this, if we find some API to do sampling. The existing rate
t
Mohammed Shafi Shajakhan wrote:
> From: Mohammed Shafi Shajakhan
>
> 'ath10k_htt_tx_free_cont_txbuf' and 'ath10k_htt_tx_free_cont_frag_desc'
> have NULL pointer checks to avoid crash if they are called twice
> but this is as of now not sufficient as these pointers are not assigned
> to NULL once
> There is a field, no_80211_encap, added to ieee80211_tx_info:control
> to mark if the 802.11 encapsulation is offloaded to driver.
> There is also a new callback for tx completion status indication
> to handle data frames using 802.11 encap offload.
I'm not sure I see the need for this? Maybe I
> This rx path only checks if the driver has advertised
> it's support of 802.11 header encap/decap offload for
> data frames.
I'm not even sure I see the point in that? Other than that (and the
various other offload requirements), it seems that encap/decap could be
considered orthogonal.
> +
On Wed, 2016-12-14 at 11:30 -0800, gree...@candelatech.com wrote:
> From: Ben Greear
>
> This fixes obtaining the rate info via sta_set_sinfo
> when the rx rate is invalid (for instance, on IBSS
> interface that has received no frames from one of its
> peers).
>
> This also fixes a more general
On Wed, 2016-12-14 at 17:28 +0100, Koen Vandeputte wrote:
> This speeds up the function in case a station already exists by
> avoiding
> calling an expensive kzalloc just to free it again after the next
> check.
It's not like this is called often, but yeah - still makes sense.
Applied.
johannes
That all looks good, applied.
johannes
On Thursday 15 December 2016 02:38 PM, Johannes Berg wrote:
> On Thu, 2016-12-15 at 11:30 +0530, Vasanthakumar Thiagarajan wrote:
>> This patch set adds a new data path to offload 802.11 header
>> encap/decap to driver or hardware. Drivers having support
>> for ieee80211 header encap/decap and othe
How you doing today? I hope you are doing well. My name is Bentley, from the
US. I'm in Syria right now fighting ISIS. I want to get to know you better, if
I may be so bold. I consider myself an easy-going man, and I am currently
looking for a relationship in which I feel loved. Please tell me m
On Thursday 15 December 2016 02:46 PM, Johannes Berg wrote:
>
>> Drivers advertising this capability should also implement other
>> functionalities which deal with 802.11 frame format like below
>
>> - ADDBA/DELBA offload
>
> This shouldn't be necessary.
Ok. Since driver/hw needs to implement
On Tue, Dec 13, 2016 at 04:56:55PM +0100, Johannes Berg wrote:
> Regarding reusing attributes, we have (for the BSS selection thing) the
> attribute NL80211_BSS_SELECT_ATTR_RSSI_ADJUST, which is really quite
> similar to your new NL80211_ATTR_SCHED_SCAN_RELATIVE_RSSI_5G_PREF since
> while connected
On Thu, Dec 15, 2016 at 07:15:30AM +0200, Michael S. Tsirkin wrote:
> That's the default now, no need for makefiles to set it.
>
> Signed-off-by: Michael S. Tsirkin
> ---
> drivers/bluetooth/Makefile| 2 --
> drivers/net/can/Makefile
On Thursday 15 December 2016 02:59 PM, Johannes Berg wrote:
>
>> There is a field, no_80211_encap, added to ieee80211_tx_info:control
>> to mark if the 802.11 encapsulation is offloaded to driver.
>> There is also a new callback for tx completion status indication
>> to handle data frames using 802
On Thu, Dec 15, 2016 at 07:15:20AM +0200, Michael S. Tsirkin wrote:
> __bitwise__ used to mean "yes, please enable sparse checks
> unconditionally", but now that we dropped __CHECK_ENDIAN__
> __bitwise is exactly the same.
> There aren't many users, replace it by __bitwise everywhere.
>
> Signed-o
On 2016-12-15 13:01, Thiagarajan, Vasanthakumar wrote:
> On Thursday 15 December 2016 02:59 PM, Johannes Berg wrote:
>>> + * @IEEE80211_CONF_CHANGE_80211_HDR_OFFL: Offload configuration
>>> + * implementing 802.11 encap/decap for data frames changed.
>>>*/
>>> enum ieee80211_conf_changed {
>>
> > I agree. Dynamic switch part is buggy, we can start with not
> > allowing interfaces resulting in dynamic switch.
>
> Does this mean that when bringing up multiple interfaces, users would
> need to figure out the 'magic' order that works?
I think we need to talk about hardware capabilities a
drivers/nfc/st21nfca/i2c.c does not use any miscdevice, so this patch
remove this unnecessary inclusion.
Signed-off-by: Corentin Labbe
---
drivers/nfc/st21nfca/i2c.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/nfc/st21nfca/i2c.c b/drivers/nfc/st21nfca/i2c.c
index 5a82f55..d16f58a
drivers/nfc/pn544/i2c.c does not use any miscdevice, so this
patch remove this unnecessary inclusion.
Signed-off-by: Corentin Labbe
---
drivers/nfc/pn544/i2c.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/nfc/pn544/i2c.c b/drivers/nfc/pn544/i2c.c
index f837c39..7030a47 100644
--- a
drivers/nfc/nxp-nci/i2c.c does not use any miscdevice, so this patch
remove this unnecessary inclusion.
Signed-off-by: Corentin Labbe
---
drivers/nfc/nxp-nci/i2c.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/nfc/nxp-nci/i2c.c b/drivers/nfc/nxp-nci/i2c.c
index 36099e5..0356515 1006
Jouni,
Thanks for the suggestion, I already tried something like this in wmi.c,
with the same result:
- Before patching the firmware scans DFS channels actively (with probes).
- After patching, the firmware scans DFS channels passively *until* any
beacon is received on the DFS channel. When *any
On Thu Dec 15 09:18:44 2016 Kalle Valo wrote:
> (Adding Luis because he has been working on request_firmware() lately)
>
> Pali Rohár writes:
>
> > > > So no, there is no argument against... request_firmware() in
> > > > fallback mode with userspace helper is by design blocking and
> > > > wait
Hello Christian,
On Wed, Dec 14, 2016 at 05:38:02PM +0100, Christian Lamparter wrote:
> On Wednesday, December 14, 2016 1:03:38 PM CET Mohammed Shafi Shajakhan wrote:
> > > On Wednesday, December 7, 2016 11:58:24 AM CET Mohammed Shafi Shajakhan
> > > wrote:
> > > > On Mon, Dec 05, 2016 at 10:52:4
On 12/15/2016 07:22 AM, Jean-Pierre Tosoni wrote:
Jouni,
Thanks for the suggestion, I already tried something like this in wmi.c,
with the same result:
- Before patching the firmware scans DFS channels actively (with probes).
- After patching, the firmware scans DFS channels passively *until*
Erik Stromdahl writes:
> Initial HIF sdio/mailbox implementation.
>
> Signed-off-by: Erik Stromdahl
> ---
> drivers/net/wireless/ath/ath10k/Kconfig |6 +
> drivers/net/wireless/ath/ath10k/Makefile |3 +
> drivers/net/wireless/ath/ath10k/sdio.c | 1860
> ++
Hi Christian,
I am also thinking, as of now there is not much use in appending
the extended peer stats (which gets periodically ) to the linked list
'&ar->debug.fw_stats.peers_extd)' and should we get rid of the below
(and the required cleanup as well)
list_splice_tail_init(&stats.peers_extd,
Hello Shafi,
On Thursday, December 15, 2016 10:13:39 PM CET Mohammed Shafi Shajakhan wrote:
> I am also thinking, as of now there is not much use in appending
> the extended peer stats (which gets periodically ) to the linked list
> '&ar->debug.fw_stats.peers_extd)' and should we get rid of the b
On Thu, Dec 15, 2016 at 07:15:20AM +0200, Michael S. Tsirkin wrote:
> __bitwise__ used to mean "yes, please enable sparse checks
> unconditionally", but now that we dropped __CHECK_ENDIAN__
> __bitwise is exactly the same.
> There aren't many users, replace it by __bitwise everywhere.
>
> Signed-o
> -Message d'origine-
> De : Ben Greear [mailto:gree...@candelatech.com]
> Envoyé : jeudi 15 décembre 2016 17:33
> À : Jean-Pierre Tosoni; 'Jouni Malinen'
> Cc : linux-wireless@vger.kernel.org; ath...@lists.infradead.org
> Objet : Re: ath10k firmware sends probes on DFS channels without rad
This is a step toward eliminating the RT_TRACE macros. Those calls that
have DBG_EMERG as the level are always logged, and they represent error
conditions, thus they are replaced with pr_err().
Signed-off-by: Larry Finger
Cc: Ping-Ke Shih
---
V2 - eliminate some files that should not have been s
Following the discussion regarding the patch entitled "rtlwifi: Add
BTC_TRACE_STRING to new btcoex", we are reworking the entire debug
system. This set of patches does the following:
1. Replaces every invocation of RT_ASSERT with WARN_ON. With this
change, triggering these conditions with now g
This is a step toward eliminating the RT_TRACE macros. Those calls that
have DBG_EMERG as the level are always logged, and they represent error
conditions, thus they are replaced with pr_err().
Signed-off-by: Larry Finger
Cc: Ping-Ke Shih
---
V2 - eliminate some files that should not have been s
This is a step toward eliminating the RT_TRACE macros. Those calls that
have DBG_EMERG as the level are always logged, and they represent error
conditions, thus they are replaced with pr_err().
Signed-off-by: Larry Finger
Cc: Ping-Ke Shih
---
V2 - eliminate some files that should not have been s
This is a step toward eliminating the RT_TRACE macros. Those calls that
have DBG_EMERG as the level are always logged, and they represent error
conditions, thus they are replaced with pr_err().
Signed-off-by: Larry Finger
Cc: Ping-Ke Shih
---
V2 - eliminate some files that should not have been s
This is a step toward eliminating the RT_TRACE macros. Those calls that
have DBG_EMERG as the level are always logged, and they represent error
conditions, thus they are replaced with pr_err().
Signed-off-by: Larry Finger
Cc: Ping-Ke Shih
---
V2 - eliminate some files that should not have been s
This macro can be replaced with WARN_ONCE. In addition to using a
standard debugging macro for these critical errors, we also get
a stack dump.
In rtl8821ae/hw.c, a senseless comment was removed, and an incorrect
indentation was fixed.
This patch also fixes two places in each of rtl8192ee, rtl872
These messages are always logged and represent error conditions, thus
we can use pr_err().
Signed-off-by: Larry Finger
Cc: Ping-Ke Shih
---
V2 - eliminate some files that should not have been sent, and remove the
module name from the format. It is already specified by a pr_fmt().
---
drive
This is a step toward eliminating the RT_TRACE macros. Those calls that
have DBG_EMERG as the level are always logged, and they represent error
conditions, thus they are replaced with pr_err().
Signed-off-by: Larry Finger
Cc: Ping-Ke Shih
---
V2 - eliminate some files that should not have been s
The symbol DBG_EMERG is no longer used and is removed.
In a number of places, the code has redundant messages. For example, if
the failure for the firmware to run is logged, it is not necessary to
log that the firmware has been started. In addition, extraneous braces are
removed.
Signed-off-by: L
This is a step toward eliminating the RT_TRACE macros. Those calls that
have DBG_EMERG as the level are always logged, and they represent error
conditions, thus they are replaced with pr_err().
Signed-off-by: Larry Finger
Cc: Ping-Ke Shih
---
V2 - eliminate some files that should not have been s
This is a step toward eliminating the RT_TRACE macros. Those calls that
have DBG_EMERG as the level are always logged, and they represent error
conditions, thus they are replaced with pr_err().
Signed-off-by: Larry Finger
Cc: Ping-Ke Shih
---
V2 - eliminate some files that should not have been s
This is a step toward eliminating the RT_TRACE macros. Those calls that
have DBG_EMERG as the level are always logged, and they represent error
conditions, thus they are replaced with pr_err().
Signed-off-by: Larry Finger
Cc: Ping-Ke Shih
---
V2 - eliminate some files that should not have been s
This is a step toward eliminating the RT_TRACE macros. Those calls that
have DBG_EMERG as the level are always logged, and they represent error
conditions, thus they are replaced with pr_err().
Signed-off-by: Larry Finger
Cc: Ping-Ke Shih
---
V2 - eliminate some files that should not have been s
This is a step toward eliminating the RT_TRACE macros. Those calls that
have DBG_EMERG as the level are always logged, and they represent error
conditions, thus they are replaced with pr_err().
Signed-off-by: Larry Finger
Cc: Ping-Ke Shih
---
V2 - eliminate some files that should not have been s
On 12/14/2016 09:15 PM, Michael S. Tsirkin wrote:
> __bitwise__ used to mean "yes, please enable sparse checks
> unconditionally", but now that we dropped __CHECK_ENDIAN__
> __bitwise is exactly the same.
> There aren't many users, replace it by __bitwise everywhere.
>
> Signed-off-by: Michael S.
On 15-12-2016 16:33, Pali Rohár wrote:
> On Thu Dec 15 09:18:44 2016 Kalle Valo wrote:
>> (Adding Luis because he has been working on request_firmware() lately)
>>
>> Pali Rohár writes:
>>
> So no, there is no argument against... request_firmware() in
> fallback mode with userspace helper
On 15-12-2016 6:15, Michael S. Tsirkin wrote:
> That's the default now, no need for makefiles to set it.
>
> Signed-off-by: Michael S. Tsirkin
> ---
> drivers/bluetooth/Makefile| 2 --
> drivers/net/can/Makefile | 1 -
> drivers/ne
On 12/15/2016 05:40 PM, Valo, Kalle wrote:
> Erik Stromdahl writes:
>
>> Initial HIF sdio/mailbox implementation.
>>
>> Signed-off-by: Erik Stromdahl
>> ---
>> drivers/net/wireless/ath/ath10k/Kconfig |6 +
>> drivers/net/wireless/ath/ath10k/Makefile |3 +
>> drivers/net/wireless/ath/
From: Geoff Lansberry
---
Documentation/devicetree/bindings/net/nfc/trf7970a.txt | 2 ++
drivers/nfc/trf7970a.c | 13 -
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
b/Documentat
From: Jaret Cantu
Repeated polling attempts cause a NULL dereference error to occur.
This is because the curent state of the trf7970a is reading but
a request has been made to send a command.
The solution is to properly kill the waiting reading (workqueue)
before failing on the send.
---
driver
From: Geoff Lansberry
---
.../devicetree/bindings/net/nfc/trf7970a.txt | 3 ++
drivers/nfc/trf7970a.c | 42 --
2 files changed, 34 insertions(+), 11 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
b/Documen
On Thu, Dec 15, 2016 at 06:53:47PM +0100, Jean-Pierre Tosoni wrote:
> > > Thanks for the suggestion, I already tried something like this in
> > > wmi.c, with the same result:
> > >
> > > - Before patching the firmware scans DFS channels actively (with
> > probes).
> > >
> > > - After patching, the
Hi Geoff.
On Thu, Dec 15, 2016 at 05:30:42PM -0500, Geoff Lansberry wrote:
> From: Geoff Lansberry
Please add an informative commit description to all of your commits.
No matter how trivial this patch may seem to you now, it may not be
to others (or to you in a few years).
> diff --git a/driver
On Thu, Dec 15, 2016 at 05:30:43PM -0500, Geoff Lansberry wrote:
> From: Geoff Lansberry
Missing commit description.
> diff --git a/drivers/nfc/trf7970a.c b/drivers/nfc/trf7970a.c
> index 2d2a077..b4c37ab 100644
> --- a/drivers/nfc/trf7970a.c
> +++ b/drivers/nfc/trf7970a.c
> @@ -1048,6 +1049,11
On Thu, Dec 15, 2016 at 05:30:44PM -0500, Geoff Lansberry wrote:
> From: Jaret Cantu
>
> Repeated polling attempts cause a NULL dereference error to occur.
> This is because the curent state of the trf7970a is reading but
> a request has been made to send a command.
>
> The solution is to proper
On Thu, Dec 15, 2016 at 2:12 PM, Arend Van Spriel
wrote:
> On 15-12-2016 16:33, Pali Rohár wrote:
>> On Thu Dec 15 09:18:44 2016 Kalle Valo wrote:
>>> (Adding Luis because he has been working on request_firmware() lately)
>>>
>>> Pali Rohár writes:
>>>
>> So no, there is no argument against.
On Wed, Dec 14, 2016 at 03:31:23PM -0700, Mark Greer wrote:
> I'll start on this
> tonight but won't likely get far until tomorrow. In the meantime,
> if you and/or your contractor make progress, please share.
Geoff,
Which version of neard are you using? 0.16?
Mark
--
Hi Christian,
> On Thursday, December 15, 2016 10:13:39 PM CET Mohammed Shafi Shajakhan wrote:
> > I am also thinking, as of now there is not much use in appending
> > the extended peer stats (which gets periodically ) to the linked list
> > '&ar->debug.fw_stats.peers_extd)' and should we get rid
On Thursday 15 December 2016 07:23 PM, Johannes Berg wrote:
>
>>> I agree. Dynamic switch part is buggy, we can start with not
>>> allowing interfaces resulting in dynamic switch.
>>
>> Does this mean that when bringing up multiple interfaces, users would
>> need to figure out the 'magic' order tha
Hi Johannes,
Thanks for the comments
On 2016-12-13 21:39, Johannes Berg wrote:
> > /**
> > + * wiphy_btcoex_support_flags
> > + * This enum has the driver supported frame types for
> > BTCOEX.
> > + * @WIPHY_WLAN_BE_PREFERRED - Supports Best Effort frame for
> > BTCOEX
> > + * @WIPHY_WLAN_BK
On Thursday 15 December 2016 03:08 PM, Johannes Berg wrote:
>
>> This rx path only checks if the driver has advertised
>> it's support of 802.11 header encap/decap offload for
>> data frames.
>
> I'm not even sure I see the point in that? Other than that (and the
> various other offload requirement
On 12/16/2016 03:03 AM, Luis R. Rodriguez wrote:
For the new API a solution for "fallback mechanisms" should be clean
though and I am looking to stay as far as possible from the existing
mess. A solution to help both the old API and new API is possible for
the "fallback mechanism" though -- but f
Enable dynamic bandwidth signalling by setting the corresponding
bit in MAC control register.
Signed-off-by: Amitkumar Karwar
---
drivers/net/wireless/marvell/mwifiex/fw.h | 1 +
drivers/net/wireless/marvell/mwifiex/init.c | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/
Firmware has started making use of reserved field.
Accordingly change curr_pkt_filter from u16 to u32.
Signed-off-by: Amitkumar Karwar
---
drivers/net/wireless/marvell/mwifiex/fw.h | 18 --
drivers/net/wireless/marvell/mwifiex/main.h| 2 +-
drivers/net/wireless/marvell/
70 matches
Mail list logo