On Tue, Dec 5, 2017 at 9:41 PM, Alexey Brodkin
wrote:
> Hi Amit,
>
> I'm seeing quite a strange behavior of RedPine module.
> It connects perfectly fine to one of access points but fails
> to connect to another.
>
> Moreover after that failure RSI driver starts to
Hello Johannes,
> > In our case, we are experimenting with applications running along with
> > hostapd and enabling band steering and client roaming functionality.
> > As I mentioned, various approaches are being examined, including
> > both pure nl80211-based approach as well as adding direct
Hi Kalle,
This is my second batch of patches intended for v4.16. As I mentioned
in the patchset thread, I moved patches 5/15 and 6/16 to iwlwifi-fixes.
Otherwise nothing major here, just the usual continued development.
More details about the contents in the tag description.
I have sent this
From: David Ahern
Date: Tue, 5 Dec 2017 11:15:29 -0700
> Is the patch I sent as an attachment good or should I re-send
> standalone? (don't see it in patchwork)
Patchwork has been wonky laterly, please resubmit as a fresh
email for rewiew.
Thanks.
Hi,
On Mon, Dec 04, 2017 at 08:18:42PM +0800, Xinming Hu wrote:
> This patch refactor current device dump code to make it generic
> for subsequent implementation on usb interface.
I still think you're making the spaghetti worse. I only have a few
specific suggestions for improving your spaghetti
On 12/5/17 10:40 AM, David Miller wrote:
> From: Johannes Berg
> Date: Tue, 05 Dec 2017 18:30:10 +0100
>
>> On Tue, 2017-12-05 at 11:41 -0500, David Miller wrote:
>>>
>>> There is no reasonable interpretation for what that application is
>>> doing, so I think we can
From: Johannes Berg
Date: Tue, 05 Dec 2017 18:30:10 +0100
> On Tue, 2017-12-05 at 11:41 -0500, David Miller wrote:
>>
>> There is no reasonable interpretation for what that application is
>> doing, so I think we can safely call that case as buggy.
>>
>> We are only
On Tue, 2017-12-05 at 11:41 -0500, David Miller wrote:
>
> There is no reasonable interpretation for what that application is
> doing, so I think we can safely call that case as buggy.
>
> We are only trying to handle the situation where a U8 attribute
> is presented as a bonafide U32 or a
Hello,
dmesg:
[17361.70] iwlwifi :01:00.0: fail to flush all tx fifo queues Q 0
[17361.733401] iwlwifi :01:00.0: Queue 0 is active on fifo 3 and
stuck for 0 ms. SW [72, 73] HW [72, 73] FH TRB=0x080300048
Regards,
--
Cristian
00:00.0 Host bridge [0600]: Intel Corporation 2nd
Hello,
dmesg:
[20164.665033] iwlwifi :01:00.0: RF_KILL bit toggled to disable radio.
[20164.665037] iwlwifi :01:00.0: reporting RF_KILL (radio disabled)
[20168.544323] iwlwifi :01:00.0: RF_KILL bit toggled to enable radio.
[20168.544328] iwlwifi :01:00.0: reporting RF_KILL (radio
From: David Ahern
Date: Tue, 5 Dec 2017 09:41:21 -0700
> On 12/5/17 9:34 AM, Johannes Berg wrote:
>> On Tue, 2017-12-05 at 11:31 -0500, David Miller wrote:
>>>
We could try to fix up the big endian problem here, but we
don't know *how* userspace misbehaved - if using
On 12/5/17 9:34 AM, Johannes Berg wrote:
> On Tue, 2017-12-05 at 11:31 -0500, David Miller wrote:
>>
>>> We could try to fix up the big endian problem here, but we
>>> don't know *how* userspace misbehaved - if using nla_put_u32
>>> then we could, but we also found a debug tool (which we'll
>>>
From: Johannes Berg
Date: Tue, 05 Dec 2017 17:34:21 +0100
> On Tue, 2017-12-05 at 11:31 -0500, David Miller wrote:
>>
>> > We could try to fix up the big endian problem here, but we
>> > don't know *how* userspace misbehaved - if using nla_put_u32
>> > then we could,
On Tue, 2017-12-05 at 11:31 -0500, David Miller wrote:
>
> > We could try to fix up the big endian problem here, but we
> > don't know *how* userspace misbehaved - if using nla_put_u32
> > then we could, but we also found a debug tool (which we'll
> > ignore for the purposes of this regression)
From: Johannes Berg
Date: Sat, 2 Dec 2017 21:23:31 +0100
> From: Johannes Berg
>
> This netlink type is used only for backwards compatibility
> with broken userspace that used the wrong size for a given
> u8 attribute, which is now rejected.
> >> +int qtnf_cmd_start_cac(const struct qtnf_vif *vif,
> >> + const struct cfg80211_chan_def *chdef,
> >> + u32 cac_time_ms)
> >> +{
> >> +struct qtnf_bus *bus = vif->mac->bus;
> >> +struct sk_buff *cmd_skb;
> >> +struct qlink_cmd_start_cac *cmd;
>
Hello Kalle,
> > Center frequency is not enough to describe the channel in HT and VHT
> > modes. For 40MHz and 80MHz channels both primary channel and center
> > frequency should be specified in order to qualify channel completely.
> > This change adds primary channel info into qlink_chandef
Hi Amit,
I'm seeing quite a strange behavior of RedPine module.
It connects perfectly fine to one of access points but fails
to connect to another.
Moreover after that failure RSI driver starts to flood me with
messages saying:
->8
rsi_91x:
Hello Kalle,
> Sergey Matyukevich writes:
>
> > From: Vasily Ulyanov
> >
> > This allows a running AP to blacklist STAs by their MAC addresses
> > respecting the configured policy (either accept or deny unless listed).
> > It can be
On Ter, 2017-12-05 at 10:06 +0100, Arend Van Spriel wrote:
> On Mon, Dec 4, 2017 at 8:00 PM, Vanessa Maegima com> wrote:
> >
> > Hi Arend,
> >
> > On Qui, 2017-11-30 at 13:31 +0100, Arend van Spriel wrote:
> > >
> > > On 11/23/2017 4:24 PM, Vanessa Maegima wrote:
> > > >
Hi Kalle,
Here is my third set of fixes for 4.15. The most important fixes are
for the new 9000 series where we were not handling some offloads
correctly and secure connections were totally broken. There is also 4
new PCI IDs and an ROC fix on P2P. More details in the tag
description.
I have
Smatch generates a warning here:
drivers/net/wireless/ath/ath9k/htc_drv_main.c:1688 ath9k_htc_ampdu_action()
error: buffer overflow 'ista->tid_state' 8 <= 15
I don't know if it's a real bug or not but the other paths through this
function all ensure that "tid" is less than
From: Anilkumar Kolli
10.2.4 firmware branch (used in QCA988X) does not support
HTT_10_4_T2H_MSG_TYPE_PEER_STATS and that's why ath10k does not provide
tranmission rate statistics to user space, instead it just shows
hardcoded 6 Mbit/s. But pktlog firmware facility
From: Anilkumar Kolli
Remove CONFIG_MAC80211_DEBUGFS dependency on ath10k_sta_statistics().
ath10k_sta_statistics() has per sta tx/rx stats and this should not
be dependent on MAC80211_DEBUGFS.
No changes in functionality.
Signed-off-by: Anilkumar Kolli
From: Anilkumar Kolli
Move pktlog_filter from struct ath10k_debug to struct ath10k
so that pktlog can be enabled even when debugfs is not
enabled, needed to enable peer tx stats for 10.2.4.
No changes in functionality.
Signed-off-by: Anilkumar Kolli
From: Anilkumar Kolli
Add tx stats supoort for QCA988X.
Parse peer stats from pktlog packets and update the tx rate
information per STA.
This way user space can query about transmit rate with iw.
V2:
- Added patch ath10k: remove MAC80211_DEBUGFS dependency on
Hi Rene,
On Tue, Dec 5, 2017 at 1:31 PM, René Rebe wrote:
> Hi Marek,
>
> thank you for your blazingly fast reply.
np.
>
> On 12/05/2017 12:41 PM, Belisko Marek wrote:
>>
>> Hi Rene,
>>
>> On Tue, Dec 5, 2017 at 12:06 PM, René Rebe wrote:
>>>
>>> Hi all,
Hi Marek,
thank you for your blazingly fast reply.
On 12/05/2017 12:41 PM, Belisko Marek wrote:
Hi Rene,
On Tue, Dec 5, 2017 at 12:06 PM, René Rebe wrote:
Hi all,
I write to start a discussion about the state of the mwifiex driver.
For over two years many other and me
Hi Rene,
On Tue, Dec 5, 2017 at 12:06 PM, René Rebe wrote:
> Hi all,
>
> I write to start a discussion about the state of the mwifiex driver.
> For over two years many other and me wait that the driver finally becomes
> "stable". However, even with kernel 4.14.2 it still
Hi all,
I write to start a discussion about the state of the mwifiex driver.
For over two years many other and me wait that the driver finally
becomes "stable". However, even with kernel 4.14.2 it still fails after
some minutes, or latest after some hours. With various stray errors in
the
From: Johannes Berg
Since od/sed are in posix, hopefully there's a better chance
people will have them, over hexdump.
Fixes: 90a53e4432b1 ("cfg80211: implement regdb signature checking")
Signed-off-by: Johannes Berg
---
net/wireless/Makefile |
From: Johannes Berg
Change the scripting inside the shipped/extra certs C code
generation to not write the file when there are any failures.
That way, if the build aborts due to failures, we don't get
into a situation where a dummy file has been created and the
next
Dear Johannes,
On 12/05/17 11:31, Johannes Berg wrote:
Ah, here we go - you probably don't have "hexdump" installed on this
system?
Well, I didn’t, but got the error, that hexdump couldn’t be found. After
installing it, I got the error above, and sent the message.
Ah, ok.
Removing the
Pavel Machek writes:
> This is quite annoying: repeated
>
> [ 4169.591529] ---[ end trace e65d97cf1d20b84d ]---
> [ 4169.591565] WARNING: CPU: 0 PID: 5472 at net/mac80211/agg-tx.c:315
> ___ieee80211_stop_tx_\
> ba_session+0x158/0x1f0
>
> Hardware is thinkpad x60. Git blame says
Hi,
> > Ah, here we go - you probably don't have "hexdump" installed on this
> > system?
>
> Well, I didn’t, but got the error, that hexdump couldn’t be found. After
> installing it, I got the error above, and sent the message.
Ah, ok.
> Removing the file `net/wireless/shipped-certs.c`, and
Hi!
This is quite annoying: repeated
[ 4169.591529] ---[ end trace e65d97cf1d20b84d ]---
[ 4169.591565] WARNING: CPU: 0 PID: 5472 at net/mac80211/agg-tx.c:315
___ieee80211_stop_tx_\
ba_session+0x158/0x1f0
Hardware is thinkpad x60. Git blame says cfcdbde35 introduced the
test.
Dear Johannes,
On 12/05/17 11:03, Johannes Berg wrote:
On Tue, 2017-12-05 at 11:01 +0100, Paul Menzel wrote:
```
$ git describe
v4.15-rc2-79-gfd6d2e506ce6
$ git log --oneline -1
fd6d2e506ce6 Merge tag 'docs-4.15-fixes' of git://git.lwn.net/linux
$ time ARCH=i386 make deb-pkg -j50
[…]
Felix Fietkau writes:
> On 2017-12-04 16:04, Kalle Valo wrote:
>> Felix Fietkau writes:
>>
>>> Changes since v7:
>>> - Fix build errors
>>>
>>> Changes since v6:
>>> - DT documentation fixes
>>> - Add LED configuration
>>> - PHY gain calibration fixes
>>> - Endian
On Tue, 2017-12-05 at 11:01 +0100, Paul Menzel wrote:
>
>
> ```
> $ git describe
> v4.15-rc2-79-gfd6d2e506ce6
> $ git log --oneline -1
> fd6d2e506ce6 Merge tag 'docs-4.15-fixes' of git://git.lwn.net/linux
> $ time ARCH=i386 make deb-pkg -j50
> […]
> net/wireless/shipped-certs.c:2:1: error:
Dear Linux folks,
Building the Linux kernel fails with the error below on Debian
Sid/unstable with gcc (Debian 7.2.0-8) 7.2.0.
```
$ git describe
v4.15-rc2-79-gfd6d2e506ce6
$ git log --oneline -1
fd6d2e506ce6 Merge tag 'docs-4.15-fixes' of git://git.lwn.net/linux
$ time ARCH=i386 make
Andy Shevchenko wrote:
> When I run make W=1 on gcc (Debian 7.2.0-16) 7.2.0 I got an error for
> the first run, all next ones are okay.
>
> CC [M] drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.o
>
On Dienstag, 21. November 2017 11:43:36 CET ako...@codeaurora.org wrote:
[...]
> > I think we should add a special case to not print the warning if mcs ==
> > 15 until we figure out what it means.
>
> Fix identified in Firmware and will push ASAP.
Is it known when this will be released and for
On Mon, Dec 4, 2017 at 8:00 PM, Vanessa Maegima wrote:
> Hi Arend,
>
> On Qui, 2017-11-30 at 13:31 +0100, Arend van Spriel wrote:
>> On 11/23/2017 4:24 PM, Vanessa Maegima wrote:
>> >
>> > >
>> > > >
>> > > > >
>> > > > > >
>> > > > > > >
>> > > > > > > Buildroot:
>> > >
43 matches
Mail list logo