Hi Kalle,
I was preparing a new patch series and got a bit confused. Turns out
there was a series still pending in patchwork.
https://patchwork.kernel.org/patch/9948825/
So I applied the pending series on wireless-drivers-next and it compiles
fine. So what I think happened is that the series
On Tue, Nov 07, 2017 at 12:01:23PM +0100, Richard Genoud wrote:
> Le mardi 07 novembre 2017 à 11:13 +0100, Stanislaw Gruszka a écrit :
> > On Tue, Nov 07, 2017 at 11:06:39AM +0100, Richard Genoud wrote:
> > > > 3 short articles how to configure and use ftrace are here:
> > > > https://lwn.net/Artic
+ Stefan
On 11/7/2017 2:31 PM, Simon Shields wrote:
Hi Arend,
On Tue, Nov 07, 2017 at 12:09:23PM +0100, Arend van Spriel wrote:
On 11/6/2017 12:27 PM, Simon Shields wrote:
On Mon, Nov 06, 2017 at 11:59:37AM +0100, Arend van Spriel wrote:
On 11/4/2017 2:24 PM, Simon Shields wrote:
Some board
On Tue, Nov 07, 2017 at 12:13:47PM +0100, Richard Genoud wrote:
> Le mardi 07 novembre 2017 à 11:13 +0100, Stanislaw Gruszka a écrit :
> > On Tue, Nov 07, 2017 at 11:06:39AM +0100, Richard Genoud wrote:
> > > > 3 short articles how to configure and use ftrace are here:
> > > > https://lwn.net/Artic
Le mercredi 08 novembre 2017 à 11:37 +0100, Stanislaw Gruszka a écrit :
> On Tue, Nov 07, 2017 at 12:01:23PM +0100, Richard Genoud wrote:
> > Le mardi 07 novembre 2017 à 11:13 +0100, Stanislaw Gruszka a
> > écrit :
> > > On Tue, Nov 07, 2017 at 11:06:39AM +0100, Richard Genoud wrote:
> > > > > 3 sh
On Wed, Nov 08, 2017 at 12:07:15PM +0100, Richard Genoud wrote:
> > No, that not I wanted you to do. Please remove those options and just
> > do
> > below on tracing directory.
> >
> > echo 0 > tracing_on
> > cat trace > /dev/null
> > echo "function_graph" > current_tracer
> > echo "rt2*" > set
Hi Arend,
On Wed, Nov 08, 2017 at 11:38:11AM +0100, Arend van Spriel wrote:
> + Stefan
>
> On 11/7/2017 2:31 PM, Simon Shields wrote:
> > Hi Arend,
> >
> > On Tue, Nov 07, 2017 at 12:09:23PM +0100, Arend van Spriel wrote:
> > > On 11/6/2017 12:27 PM, Simon Shields wrote:
> > > > On Mon, Nov 06,
Arend van Spriel writes:
> Hi Kalle,
>
> I was preparing a new patch series and got a bit confused. Turns out
> there was a series still pending in patchwork.
>
> https://patchwork.kernel.org/patch/9948825/
That's not pending, it's in "Changes Requested" meaning that I have
dropped them:
https:
Larry Finger writes:
> From: Ping-Ke Shih
>
> 8822be checks H2CQ by int_d, so we extend to four ISR.
> Also, irq_mask is extended to four.
>
> Signed-off-by: Ping-Ke Shih
> Signed-off-by: Larry Finger
> Cc: Yan-Hsuan Chuang
> Cc: Birming Chiu
> Cc: Shaofu
> Cc: Steven Ting
[...]
> @@ -93
Larry Finger writes:
> From: Steven Ting
>
> After this refactoring, the variables wp and rp in TX ring can only be
> updated in OP_TX and TX_OK respectively without protection.
Why? Try to always answer that, that's the most important part of the
commit log. Are you fixing a bug (if yes, descr
Larry Finger wrote:
> Checkpatch.pl reports a number of formatting problems in this header
> file. None of the changes cause any functional changes in the driver.
>
> Signed-off-by: Larry Finger
> Cc: Ping-Ke Shih
> Cc: Yan-Hsuan Chuang
> Cc: Birming Chiu
> Cc: Shaofu
> Cc: Steven Ting
7
Arnd Bergmann wrote:
> We set rtlhal->last_suspend_sec to an uninitialized stack variable,
> but unfortunately gcc never warned about this, I only found it
> while working on another patch. I opened a gcc bug for this.
>
> Presumably the value of rtlhal->last_suspend_sec is not all that
> import
Colin Ian King wrote:
> From: Colin Ian King
>
> tid_data is assigned but never read, hence it is redundant
> and can be removed. Cleans up clang warning:
>
> drivers/net/wireless/realtek/rtlwifi/base.c:1581:2: warning: Value
> stored to 'tid_data' is never read
>
> Signed-off-by: Colin Ian K
Colin Ian King wrote:
> From: Colin Ian King
>
> cfg_cmd is initialized to zero and this value is never read, instead
> it is over-written in the start of a do-while loop. Remove the
> redundant initialization. Cleans up clang warning:
>
> drivers/net/wireless/realtek/rtlwifi/core.c:1750:22: w
Larry Finger wrote:
> From: Steven Ting
>
> After this refactoring, the variables wp and rp in TX ring can only be
> updated in OP_TX and TX_OK respectively without protection. The other
> changes are listed below:
>
> 1. remove avl_desc from TX ring, because it can be calculated by wp and rp.
Colin Ian King wrote:
> From: Colin Ian King
>
> Pointer sta_priv is assigned but never read, hence it is redundant
> and can be removed. Cleans up clang warning:
>
> drivers/net/wireless/intel/iwlegacy/4965-rs.c:2163:2: warning: Value
> stored to 'sta_priv' is never read
>
> Signed-off-by: C
Colin Ian King wrote:
> From: Colin Ian King
>
> The pointer dev is assigned but never read, hence it is redundant
> and can be removed. Cleans up clang warning:
>
> drivers/net/wireless/intersil/orinoco/orinoco_usb.c:1468:2: warning:
> Value stored to 'dev' is never read
>
> Signed-off-by: C
Colin Ian King wrote:
> From: Colin Ian King
>
> Variable framelen is assigned but never read, hence it is redundant
> and can be removed. Cleans up clang warning:
>
> drivers/net/wireless/zydas/zd1201.c:234:3: warning: Value stored
> to 'framelen' is never read
>
> Signed-off-by: Colin Ian K
On Tue, Nov 07, 2017 at 03:48:12PM +0100, Per Mejdal Rasmussen wrote:
> Hi
>
> I have taken the time research which frequencies and power levels are
> allowed for WiFi in Denmark. So db.txt for wireless-regdb can be updated.
Thanks for this information. I know I've been slow to respond, but
there
On Wed, Nov 08, 2017 at 10:43:05PM +1100, Simon Shields wrote:
> Hi Arend,
>
> On Wed, Nov 08, 2017 at 11:38:11AM +0100, Arend van Spriel wrote:
> > + Stefan
> >
> > On 11/7/2017 2:31 PM, Simon Shields wrote:
> > > Hi Arend,
> > >
> > > On Tue, Nov 07, 2017 at 12:09:23PM +0100, Arend van Spriel
From: Franky Lin
Disable arp and nd offload to allow all packets sending to host.
Reported-by: Phil Elwell
Tested-by: Phil Elwell
Reviewed-by: Arend Van Spriel
Signed-off-by: Franky Lin
Signed-off-by: Arend van Spriel
---
.../broadcom/brcm80211/brcmfmac/cfg80211.c | 41
From: Arend Van Spriel
The function brcmf_cfg80211_escan() was always called with a non-null
request parameter and null pointer for this_ssid parameter. Clean up
the function removing the dead code path.
Reviewed-by: Hante Meuleman
Reviewed-by: Pieter-Paul Giesberts
Reviewed-by: Franky Lin
Si
From: Arend Van Spriel
Minor cleanup using provided macro to convert milliseconds interval
to jiffies in brcmf_cfg80211_escan().
Reviewed-by: Hante Meuleman
Reviewed-by: Pieter-Paul Giesberts
Reviewed-by: Franky Lin
Signed-off-by: Arend van Spriel
---
drivers/net/wireless/broadcom/brcm80211
From: Arend Van Spriel
The configuration of the IEs for probe requests was done in a P2P
related function, which is not very obvious. Moving it to
.scan callback function, ie. brcmf_cfg80211_scan().
Reviewed-by: Hante Meuleman
Reviewed-by: Pieter-Paul Giesberts
Reviewed-by: Franky Lin
Signed-
From: Arend Van Spriel
The function brcmf_cfg80211_escan() is only called by brcmf_cfg80211_scan()
so there is no reason to split in two function especially since the latter
does not do an awful lot.
Reviewed-by: Hante Meuleman
Reviewed-by: Pieter-Paul Giesberts
Reviewed-by: Franky Lin
Signed
From: Arend Van Spriel
The firmware uses a mailbox to communicate to the host what is going
on. In the driver we validate the bit received. Various people seen
the following message:
brcmfmac: brcmf_sdio_hostmail: Unknown mailbox data content: 0x40012
Bit 4 is cause of this message, but this a
This series is a resubmission. No changes were being made compared
to the previous series.
* handling firmware halt indication.
* cleanup scan related code.
The series applies to the master branch of the wireless-drivers-next
repository and is intended for v4.15 kernel.
Arend Van Spriel (6):
From: Arend Van Spriel
The field struct brcmf_cfg80211_info::active_scan is set to true upon
initializing the driver instance, but it is never changed so simply
get rid of it.
Reviewed-by: Hante Meuleman
Reviewed-by: Pieter-Paul Giesberts
Reviewed-by: Franky Lin
Signed-off-by: Arend van Sprie
Hi Luca,
Any suggestion for the "Failed to start INIT ucode: -110" issue
for the firmware?
Chris
On Tue, Nov 7, 2017 at 12:26 PM, Chris Chiu wrote:
> Hi Luca,
> I just tried the firmware but seems still something wrong. dmesg
> shows me the following
>
> [ 17.786041] Intel(R) Wireless
Hi Chris,
On Thu, 2017-11-09 at 11:11 +0800, Chris Chiu wrote:
> Hi Luca,
> Any suggestion for the "Failed to start INIT ucode: -110" issue
> for the firmware?
We are investigating this now. This seems to be related to the secure
boot key not being valid...
I'll let you know when we progre
Commit 4ca1807815aa6801aaced7fdefa9edacc2521767 disables the use of the
mac80211 TXQs for some devices because of a theoretical throughput
regression. We have not seen this regression for a while now, so it
should be safe to re-enable TXQs.
Signed-off-by: Toke Høiland-Jørgensen
---
This has been
31 matches
Mail list logo
