* Re: [RFC PATCH v3] rtl8xxxu: Improve TX performance of RTL8723BU on rtl8xxxu driver
From: Chris Chiu @ 2019-05-30 4:58 UTC (permalink / raw)
To: Larry Finger
Cc: Jes Sorensen, Kalle Valo, David Miller, linux-wireless, netdev,
Linux Kernel, Linux Upstreaming Team
In-Reply-To: <5f5e262d-aadb-cca0-8576-879735366a73@lwfinger.net>
On Thu, May 30, 2019 at 2:22 AM Larry Finger <Larry.Finger@lwfinger.net> wrote:
>
> On 5/29/19 12:03 AM, Chris Chiu wrote:
> > We have 3 laptops which connect the wifi by the same RTL8723BU.
> > The PCI VID/PID of the wifi chip is 10EC:B720 which is supported.
> > They have the same problem with the in-kernel rtl8xxxu driver, the
> > iperf (as a client to an ethernet-connected server) gets ~1Mbps.
> > Nevertheless, the signal strength is reported as around -40dBm,
> > which is quite good. From the wireshark capture, the tx rate for each
> > data and qos data packet is only 1Mbps. Compare to the driver from
> > https://github.com/lwfinger/rtl8723bu, the same iperf test gets ~12
> > Mbps or more. The signal strength is reported similarly around
> > -40dBm. That's why we want to improve.
>
> The driver at GitHub was written by Realtek. I only published it in a prominent
> location, and fix it for kernel API changes. I would say "the Realtek driver at
> https://...", and every mention of "Larry's driver" should say "Realtek's
> driver". That attribution is more correct.
Thanks. I'll modify this in next revision.
> >
> > After reading the source code of the rtl8xxxu driver and Larry's, the
> > major difference is that Larry's driver has a watchdog which will keep
> > monitoring the signal quality and updating the rate mask just like the
> > rtl8xxxu_gen2_update_rate_mask() does if signal quality changes.
> > And this kind of watchdog also exists in rtlwifi driver of some specific
> > chips, ex rtl8192ee, rtl8188ee, rtl8723ae, rtl8821ae...etc. They have
> > the same member function named dm_watchdog and will invoke the
> > corresponding dm_refresh_rate_adaptive_mask to adjust the tx rate
> > mask.
> >
> > With this commit, the tx rate of each data and qos data packet will
> > be 39Mbps (MCS4) with the 0xF00000 as the tx rate mask. The 20th bit
> > to 23th bit means MCS4 to MCS7. It means that the firmware still picks
> > the lowest rate from the rate mask and explains why the tx rate of
> > data and qos data is always lowest 1Mbps because the default rate mask
> > passed is always 0xFFFFFFF ranges from the basic CCK rate, OFDM rate,
> > and MCS rate. However, with Larry's driver, the tx rate observed from
> > wireshark under the same condition is almost 65Mbps or 72Mbps.
> >
> > I believe the firmware of RTL8723BU may need fix. And I think we
> > can still bring in the dm_watchdog as rtlwifi to improve from the
> > driver side. Please leave precious comments for my commits and
> > suggest what I can do better. Or suggest if there's any better idea
> > to fix this. Thanks.
> >
> > Signed-off-by: Chris Chiu <chiu@endlessm.com>
>
> I have not tested this patch, but I plan to soon.
>
> Larry
>
>
^ permalink raw reply
* Re: [PATCH 01/11] rtw88: resolve order of tx power setting routines
From: Kalle Valo @ 2019-05-30 4:59 UTC (permalink / raw)
To: Tony Chuang; +Cc: Larry Finger, linux-wireless@vger.kernel.org
In-Reply-To: <F7CD281DE3E379468C6D07993EA72F84D17FABBF@RTITMBSVM04.realtek.com.tw>
Tony Chuang <yhchuang@realtek.com> writes:
>> -----Original Message-----
>> From: Larry Finger [mailto:larry.finger@gmail.com] On Behalf Of Larry Finger
>> Sent: Wednesday, May 29, 2019 11:17 PM
>> To: Tony Chuang; kvalo@codeaurora.org
>> Cc: linux-wireless@vger.kernel.org
>> Subject: Re: [PATCH 01/11] rtw88: resolve order of tx power setting routines
>>
>> On 5/29/19 2:54 AM, yhchuang@realtek.com wrote:
>> > From: Yan-Hsuan Chuang <yhchuang@realtek.com>
>> >
>> > Some functions that should be static are unnecessarily exposed, remove
>> > their declaration in header file phy.h.
>> >
>> > After resolving their declaration order, they can be declared as static.
>> > So this commit changes nothing except the order and marking them static.
>> >
>> > Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
>>
>> This patch does not apply. Using quilt to see what is wrong, there are 6
>> changes
>> that have already been applied.
>>
>> Larry
>>
>
>
> These patches are based on
>
> https://kernel.googlesource.com/pub/scm/linux/kernel/git/kvalo/wireless-drivers
> branch master
>
> commit 6aca09771db4277a78853d6ac680d8d5f0d915e3
> Author: YueHaibing <yuehaibing@huawei.com>
> Date: Sat May 4 18:32:24 2019 +0800
>
> rtw88: Make some symbols static
>
>
> It should apply, did I miss something?
I keep the bar high and take to wireless-drivers only patches which fix
important, user visible problems. Everything else goes to
wireless-drivers-next. So you should use wireless-drivers-next as the
baseline for all regular patches.
--
Kalle Valo
^ permalink raw reply
* RE: [PATCH 01/11] rtw88: resolve order of tx power setting routines
From: Tony Chuang @ 2019-05-30 5:05 UTC (permalink / raw)
To: Kalle Valo; +Cc: Larry Finger, linux-wireless@vger.kernel.org
In-Reply-To: <87v9xspmfd.fsf@codeaurora.org>
> -----Original Message-----
> From: Kalle Valo [mailto:kvalo@codeaurora.org]
> Sent: Thursday, May 30, 2019 1:00 PM
> To: Tony Chuang
> Cc: Larry Finger; linux-wireless@vger.kernel.org
> Subject: Re: [PATCH 01/11] rtw88: resolve order of tx power setting routines
>
> Tony Chuang <yhchuang@realtek.com> writes:
>
> >> -----Original Message-----
> >> From: Larry Finger [mailto:larry.finger@gmail.com] On Behalf Of Larry
> Finger
> >> Sent: Wednesday, May 29, 2019 11:17 PM
> >> To: Tony Chuang; kvalo@codeaurora.org
> >> Cc: linux-wireless@vger.kernel.org
> >> Subject: Re: [PATCH 01/11] rtw88: resolve order of tx power setting
> routines
> >>
> >> On 5/29/19 2:54 AM, yhchuang@realtek.com wrote:
> >> > From: Yan-Hsuan Chuang <yhchuang@realtek.com>
> >> >
> >> > Some functions that should be static are unnecessarily exposed, remove
> >> > their declaration in header file phy.h.
> >> >
> >> > After resolving their declaration order, they can be declared as static.
> >> > So this commit changes nothing except the order and marking them
> static.
> >> >
> >> > Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
> >>
> >> This patch does not apply. Using quilt to see what is wrong, there are 6
> >> changes
> >> that have already been applied.
> >>
> >> Larry
> >>
> >
> >
> > These patches are based on
> >
> >
> https://kernel.googlesource.com/pub/scm/linux/kernel/git/kvalo/wireless-dr
> ivers
> > branch master
> >
> > commit 6aca09771db4277a78853d6ac680d8d5f0d915e3
> > Author: YueHaibing <yuehaibing@huawei.com>
> > Date: Sat May 4 18:32:24 2019 +0800
> >
> > rtw88: Make some symbols static
> >
> >
> > It should apply, did I miss something?
>
> I keep the bar high and take to wireless-drivers only patches which fix
> important, user visible problems. Everything else goes to
> wireless-drivers-next. So you should use wireless-drivers-next as the
> baseline for all regular patches.
Hi, Kalle
But this series has dependency with " rtw88: Make some symbols static"
Or you can handle it
>
> --
> Kalle Valo
>
Yan-Hsuan
^ permalink raw reply
* Re: [PATCH 01/11] rtw88: resolve order of tx power setting routines
From: Kalle Valo @ 2019-05-30 5:11 UTC (permalink / raw)
To: Tony Chuang; +Cc: Larry Finger, linux-wireless@vger.kernel.org
In-Reply-To: <F7CD281DE3E379468C6D07993EA72F84D17FAD0F@RTITMBSVM04.realtek.com.tw>
Tony Chuang <yhchuang@realtek.com> writes:
>> > These patches are based on
>> >
>> >
>> https://kernel.googlesource.com/pub/scm/linux/kernel/git/kvalo/wireless-dr
>> ivers
>> > branch master
>> >
>> > commit 6aca09771db4277a78853d6ac680d8d5f0d915e3
>> > Author: YueHaibing <yuehaibing@huawei.com>
>> > Date: Sat May 4 18:32:24 2019 +0800
>> >
>> > rtw88: Make some symbols static
>> >
>> >
>> > It should apply, did I miss something?
>>
>> I keep the bar high and take to wireless-drivers only patches which fix
>> important, user visible problems. Everything else goes to
>> wireless-drivers-next. So you should use wireless-drivers-next as the
>> baseline for all regular patches.
>
> But this series has dependency with " rtw88: Make some symbols static"
This is exactly why I keep the bar high for patches going to
wireless-drivers :) These depencies and conflicts are just too time
consuming otherwise.
> Or you can handle it
Unfortunately not, as I made a mistake when fast-forwarding
wireless-drivers and I cannot merge wireless-drivers into
wireles-drivers-next right now. So you just need to wait for the
depencies to trickle down to w-d-next, that will take few weeks.
--
Kalle Valo
^ permalink raw reply
* RE: [PATCH 01/11] rtw88: resolve order of tx power setting routines
From: Tony Chuang @ 2019-05-30 5:15 UTC (permalink / raw)
To: Kalle Valo; +Cc: Larry Finger, linux-wireless@vger.kernel.org
In-Reply-To: <87r28gplw5.fsf@codeaurora.org>
> -----Original Message-----
> From: Kalle Valo [mailto:kvalo@codeaurora.org]
> Sent: Thursday, May 30, 2019 1:11 PM
> To: Tony Chuang
> Cc: Larry Finger; linux-wireless@vger.kernel.org
> Subject: Re: [PATCH 01/11] rtw88: resolve order of tx power setting routines
>
> Tony Chuang <yhchuang@realtek.com> writes:
>
> >> > These patches are based on
> >> >
> >> >
> >>
> https://kernel.googlesource.com/pub/scm/linux/kernel/git/kvalo/wireless-dr
> >> ivers
> >> > branch master
> >> >
> >> > commit 6aca09771db4277a78853d6ac680d8d5f0d915e3
> >> > Author: YueHaibing <yuehaibing@huawei.com>
> >> > Date: Sat May 4 18:32:24 2019 +0800
> >> >
> >> > rtw88: Make some symbols static
> >> >
> >> >
> >> > It should apply, did I miss something?
> >>
> >> I keep the bar high and take to wireless-drivers only patches which fix
> >> important, user visible problems. Everything else goes to
> >> wireless-drivers-next. So you should use wireless-drivers-next as the
> >> baseline for all regular patches.
> >
> > But this series has dependency with " rtw88: Make some symbols static"
>
> This is exactly why I keep the bar high for patches going to
> wireless-drivers :) These depencies and conflicts are just too time
> consuming otherwise.
>
> > Or you can handle it
>
> Unfortunately not, as I made a mistake when fast-forwarding
> wireless-drivers and I cannot merge wireless-drivers into
> wireles-drivers-next right now. So you just need to wait for the
> depencies to trickle down to w-d-next, that will take few weeks.
It means that I just need to wait for the patches in w-d to go to w-d-next?
So I don't need to resend them, just wait and you can merge this.
Yan-Hsuan
^ permalink raw reply
* Re: cellular modem APIs - take 2
From: Marcel Holtmann @ 2019-05-30 5:28 UTC (permalink / raw)
To: Johannes Berg
Cc: netdev, linux-wireless, Subash Abhinov Kasiviswanathan,
Dan Williams, Sean Tranchetti, Daniele Palmas, Aleksander Morgado,
Bjørn Mork
In-Reply-To: <acf18b398fd63f2dfece5981ebd5057141529e6a.camel@sipsolutions.net>
Hi Johannes,
>> Have you actually looked at Phonet or CAIF.
>
> Phonet is just a specific protocol spoken by a specific modem (family)
> for their control plane. Not all modems are going to be speaking this.
> Same for CAIF, really. I don't really see all that much that's generic
> (enough) here. It's unfortunate that in all this time nobody ever
> bothered to even try though, and just invented all their own mechanisms
> to precisely mirror the hardware and firmware they were working with.
>
> Theoretically now, you could build a driver that still speaks CAIF or
> phonet and then translates to a specific modem, but what would the point
> be?
>
> Now, I'm looking more at the data plan than the control plane, so I
> guess you could argue I should've not just mentioned MBIM and AT
> commands, but also something like Phonet/CAIF.
actually Phonet and CAIF are the transports and endpoint connections in the devices. The modem control protocol of Phonet was ISI and for CAIF it was actually AT commands (but I think there was a plan for ISI over CAIF).
>> And netdev by default seems like repeating the same mistake we have
>> done with WiFi. Your default context in LTE cases is only available
>> when actually registered to the LTE bearer. It is pretty much
>> pointless to have a netdev if you are not registered to the network.
>
> I partially agree with this.
>
> Of course, for WiFi, that's just wrong since the control path is on the
> netdev. Without a netdev, nothing works, and so not having one by
> default just adds something pointless to the setup necessary to bring up
> anything at all. It can be argued whether not allowing to remove it is
> right, but that just detracts from the discussion at hand and there's
> also a lot of history here.
Actually we need to have that history discussion on how it was also wrong for WiFi from my point of view. I do understand how things have made sense back in the days, but these days clinging to a netdev for control point even in WiFi makes no sense. Anyway, that is a different discussion.
My point is really that a lot of other things are ongoing before a modem even gets a data plane that would be mapped to a netdev.
> I do understand (and mostly agree) that having a netdev by default
> that's not connected to anything and has no functionality until you've
> done some out-of-band (as far as the netdev is concerned) setup is
> fairly much pointless, but OTOH having a netdev is something that people
> seem to want for various reasons (discovery, ethtool, …).
That worries me even more. Discovery via RTNL is pointless and totally racy. Usage of ethtool is pointless as well since we are dealing with IP only interfaces.
I have a felling that these points are from people that don’t really understand 3GPP and want to use command line tools to handle cellular modem. Back in the days iwconfig worked as well and so did pppd, but by now we all learned that this is not going to work. Especially in the world of 3GPP it is not going to work. I do not care a bit if ethtool or any other command line tool that wants to talk directly to kernel. Unless you have a way for a telephony daemon like oFono to get its work done, any of this above is just a distraction.
>> You have to do a lot of initial modem setup before you ever get to the
>> having your default context connected. Have a look at oFono and what
>> it does to bring up the modem.
>
> Sure.
>
>>> 2) Clearly, one needs to be able to create PDN netdevs, with the PDN
>>> given to the command. Here's another advantage: If these are created
>>> on top of another abstraction, not another netdev, they can have
>>> their own queues, multiqueue RX etc. much more easily.
> [...]
>> I think you need to provide actually a lot more details on how queue
>> control inside Linux would be helpful and actually work in the first
>> place. I don’t see how Linux will be ever in charge and not the modem
>> do this all for you.
>
> I think you misunderstand. I wasn't really talking about *queue control*
> (packet dequeue etc.) although this is *also* something that could be
> interesting, since the modem can only control packets that ever made it
> to the hardware.
>
> I was more thinking of what I actually wrote - "have their own queues,
> multiqueue RX etc." - i.e. control the software layer of the queues in
> the driver, rather than having all of that managed in some stacked
> netdev like VLAN.
>
> For example, with stacked netdevs like VLANs it gets difficult (and
> awkward from a network stack perspective) to put frames for different
> connections (stacked netdevs) into different hardware queues and manage
> flow control correctly.
>
> Similarly, if one connection has maybe multiple hardware queues (say for
> a specific video stream) disentangling that when you have stacked
> netdevs is much harder than when they're all separate.
>
> (And, of course, there's little point in having the underlying netdev to
> start with since it speaks a device-specific protocol the network stack
> will never understand.)
I am not convinced that any of this will help us since it is all network specific and the Linux job is just to feed the packets into the hardware.
>>> 3) Separately, we need to have an ability to create "generalized control
>>> channels". I'm thinking there would be a general command "create
>>> control channel" with a given type (e.g. ATCMD, RPC, MBIM, GNSS) plus
>>> a list of vendor-specific channels (e.g. for tracing).
> [...]
>>> I guess such a channel should also be created by default, if it's
>>> not already created by the driver in some out-of-band way anyway (and
>>> most likely it shouldn't be, but I guess drivers might have some
>>> entirely different communication channels for AT CMDs?)
>>
>> I would just use sockets like Phonet and CAIF.
>
> It was in fact one of the options I considered, but it seems to have
> very little traction with any other userspace, and having a separate
> socket family yet again also seems a bit pointless. I guess for devices
> that do already speak Phonet or CAIF that would make sense. Possible to
> some extent, but not really useful, would be to terminate the Phonet or
> CAIF protocol inside the driver or stack, but then you end up having to
> emulate some specific firmware behaviour ...
>
> So ultimately it boils down to what protocols you want to support and
> what kind of API they typically use. I guess I don't have enough hubris
> to propose unifying the whole command set and how you talk to your
> device ;-)
>
> I suppose you could have a socket type for AT commands, but is that
> really all that useful? Or a socket type that muxes the different
> control channels you might have, which gets close to phonet/caif.
As I stated above, Phonet and CAIF where just there to connect endpoints inside the hardware / platform. The protocol running inside these pipes could have been anything. I think what is more important is to figure out on how you access the pipes.
I think that Dan already stated this, the difference is just that we have protocols that underneath accept a transport that is serialized and stream based and others where the transport has packet boundaries and is packetized. These would obviously match to SOCK_STREAM and SOCK_SEQPACKET if you had to classify them.
Now that said, it is nice to just get a file descriptor from the kernel and then drive your protocol from userspace. We have used AT commands over TCP to connect to Phonesim for example. The AT commands don’t care if it is a real serial port, an emulated one by the modem driver or even a SOCK_STREAM socket. Same applies to all the other protocols and implementation that have been written over the years.
Dan also stated the major problems that the control and data path endpoints have been served by different drivers and figuring out what character device belongs to what network interface has been a mess. Creating a character device or a TTY is far too simple and because everybody wants to run pppd on a TTY that is what led us into this mess.
So what is really needed is a way to discovery the cellular modem and its capabilities towards the Linux host. Not all modems are equal and the number of control paths might be limited in the same way as the number of contexts it can expose or its voice to the host streams.
>> Frankly I have a problem if this is designed from the hardware point
>> of view. Unless you are familiar with how 3GPP works and what a
>> telephony stack like oFono has to do, there is really no point in
>> trying to create a WWAN subsystem.
>>
>> Anything defined needs to be defined in terms of 3GPP and not what
>> current drivers have hacked together.
>
> That objection makes no sense to me. 3GPP doesn't define how the data
> plane is implemented in your device/OS. There's a data plane, it carries
> IP packets, but how you get those to your applications?
>
> After all, I'm not really proposing that we put oFono or something like
> it into the kernel - far from it! I'm only proposing that we kill the
> many various ways of creating and managing the necessary netdevs (VLANs,
> sysfs, rmnet, ...) from a piece of software like oFono (or libmbim or
> whatever else).
>
> Apart from CAIF and phonet, oFono doesn't even try to do this though,
> afaict, so I guess it relies on the default netdev created, or some out-
> of-band configuration is still needed?
As stated above, that is the problem of default netdev by drivers. Phonet and CAIF (and also our own support with 207.07 and RawIP) are superior in these regards. That is also why phones used these. The rest was then cellular data cards where the thinking was ATD+PPP.
Regards
Marcel
^ permalink raw reply
* iwl_mvm_add_new_dqa_stream_wk BUG in lib/list_debug.c:56
From: Marc Haber @ 2019-05-30 8:12 UTC (permalink / raw)
To: linux-kernel, linux-wireless, netdev
Hi,
on my primary notebook, a Lenovo X260, with an Intel Wireless 8260
(8086:24f3), running Debian unstable, I have started to see network
hangs since upgrading to kernel 5.1. In this situation, I cannot
restart Network-Manager (the call just hangs), I can log out of X, but
the system does not cleanly shut down and I need to Magic SysRq myself
out of the running system. This happens about once every two days.
dmesg:
[38083.673678] lanw0: authenticate with 92:2a:a8:cb:8b:6c
[38083.682971] lanw0: send auth to 92:2a:a8:cb:8b:6c (try 1/3)
[38083.693860] lanw0: authenticated
[38083.697711] lanw0: associate with 92:2a:a8:cb:8b:6c (try 1/3)
[38083.703029] lanw0: RX ReassocResp from 92:2a:a8:cb:8b:6c (capab=0x411 status=0 aid=1)
[38083.705838] lanw0: associated
[38114.658765] lanw0: disconnect from AP 92:2a:a8:cb:8b:6c for new auth to 02:9f:c2:ab:b6:9f
[38114.671649] lanw0: authenticate with 02:9f:c2:ab:b6:9f
[38114.680074] lanw0: send auth to 02:9f:c2:ab:b6:9f (try 1/3)
[38114.692359] lanw0: authenticated
[38114.693609] lanw0: associate with 02:9f:c2:ab:b6:9f (try 1/3)
[38114.698697] lanw0: RX ReassocResp from 02:9f:c2:ab:b6:9f (capab=0x411 status=0 aid=1)
[38114.700878] lanw0: associated
[38179.708187] lanw0: disconnect from AP 02:9f:c2:ab:b6:9f for new auth to 92:2a:a8:cb:8b:6c
[38179.720183] lanw0: authenticate with 92:2a:a8:cb:8b:6c
[38179.728924] lanw0: send auth to 92:2a:a8:cb:8b:6c (try 1/3)
[38179.741439] lanw0: authenticated
[38179.745606] lanw0: associate with 92:2a:a8:cb:8b:6c (try 1/3)
[38179.750579] lanw0: RX ReassocResp from 92:2a:a8:cb:8b:6c (capab=0x411 status=0 aid=1)
[38179.752854] lanw0: associated
[38179.854525] list_del corruption. next->prev should be ffff88839d6167f8, but was ffff88839d616108
[38179.854533] ------------[ cut here ]------------
[38179.854535] kernel BUG at lib/list_debug.c:56!
[38179.854539] invalid opcode: 0000 [#2] SMP PTI
[38179.854542] CPU: 0 PID: 1869 Comm: kworker/0:2 Tainted: G D O 5.1.1-zgws1 #5.1.1.20190514.3
[38179.854543] Hardware name: LENOVO 20F5S5X100/20F5S5X100, BIOS R02ET63W (1.36 ) 12/15/2017
[38179.854552] Workqueue: events iwl_mvm_add_new_dqa_stream_wk [iwlmvm]
[38179.854556] RIP: 0010:__list_del_entry_valid.cold.1+0x20/0x4c
[38179.854557] Code: e3 d8 81 e8 a7 f2 da ff 0f 0b 48 89 fe 48 89 c2 48 c7 c7 20 e4 d8 81 e8 93 f2 da ff 0f 0b 48 c7 c7 d0 e4 d8 81 e8 85 f2 da ff <0f> 0b 48 89 f2 48 89 fe 48 c7 c7 90 e4 d8 81 e8 71 f2 da ff 0f 0b
38179.854559] RSP: 0018:ffffc9000844fde8 EFLAGS: 00010246
[38179.854560] RAX: 0000000000000054 RBX: ffff88839d6167f8 RCX: 0000000000000000
[38179.854561] RDX: 0000000000000000 RSI: ffff8884318164d8 RDI: ffff8884318164d8
[38179.854562] RBP: ffff888150a56888 R08: 000000000000042a R09: 0000000000000063
[38179.854563] R10: 0000000000000000 R11: ffffc9000844fc88 R12: 000000000000000a
[38179.854564] R13: 0000000000000000 R14: ffff88842bdfe388 R15: 0000000000000000
[38179.854566] FS: 0000000000000000(0000) GS:ffff888431800000(0000) knlGS:0000000000000000
[38179.854567] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[38179.854568] CR2: 00007f87c26a5000 CR3: 000000033154a006 CR4: 00000000003626f0
[38179.854569] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[38179.854570] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[38179.854571] Call Trace:
[38179.854578] iwl_mvm_add_new_dqa_stream_wk+0x2b2/0x760 [iwlmvm]
[38179.854582] process_one_work+0x195/0x3d0
[38179.854584] worker_thread+0x2b/0x390
[38179.854586] ? create_worker+0x190/0x190
[38179.854588] kthread+0x111/0x130
[38179.854589] ? kthread_bind+0x20/0x20
[38179.854592] ret_from_fork+0x35/0x40
[38179.854594] Modules linked in: vhost_net vhost tap ext2 mmc_block tun hid_generic usbhid hid ctr ccm rfcomm fuse acpi_call(O) cpufreq_userspace cpufreq_powersave cpufreq_conservative cmac bnep option cdc_ether btusb usbnet btbcm btintel usb_wwan mii usbserial bluetooth hmac drbg ansi_cprng ecdh_generic msr bridge stp llc dummy ip6t_REJECT arc4 nf_reject_ipv6 ip6_tables nft_chain_nat ipt_MASQUERADE nf_nat wmi_bmof nft_chain_route_ipv4 snd_hda_codec_hdmi iwlmvm xt_TCPMSS mac80211 snd_hda_codec_realtek nft_counter snd_hda_codec_generic iwlwifi snd_hda_intel intel_rapl snd_hda_codec x86_pkg_temp_thermal intel_powerclamp ipt_REJECT nf_reject_ipv4 kvm_intel xt_tcpudp snd_hda_core kvm irqbypass snd_hwdep xt_conntrack intel_cstate intel_rapl_perf nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 snd_pcm nft_compat input_leds serio_raw snd_timer cfg80211 thinkpad_acpi nf_tables sg nvram mei_hdcp ledtrig_audio intel_pch_thermal tpm_tis snd nfnetlink tpm_tis_core soundcore tpm rfkill wmi rng_core a
c battery
[38179.854623] evdev pcc_cpufreq button tcp_bbr sch_fq nfsd auth_rpcgss nfs_acl lockd grace coretemp sunrpc loop ip_tables x_tables autofs4 btrfs zlib_deflate ext4 crc16 mbcache jbd2 algif_skcipher af_alg dm_crypt dm_mod raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor uas usb_storage raid6_pq libcrc32c crc32c_generic raid1 raid0 multipath linear md_mod sd_mod crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel rtsx_pci_sdmmc mmc_core aesni_intel aes_x86_64 crypto_simd cryptd glue_helper ahci libahci psmouse xhci_pci i2c_i801 e1000e libata xhci_hcd rtsx_pci mfd_core scsi_mod usbcore usb_common i915 i2c_algo_bit drm_kms_helper drm i2c_core thermal video
[38179.854652] ---[ end trace fd93637fcde969e6 ]---
[38179.854654] RIP: 0010:compaction_alloc+0x569/0x8c0
[38179.854656] Code: 62 01 00 00 49 be 00 00 00 00 00 16 00 00 eb 72 48 b8 00 00 00 00 00 ea ff ff 49 89 da 49 c1 e2 06 4d 8d 2c 02 4d 85 ed 74 3b <41> 8b 45 30 25 80 00 00 f0 3d 00 00 00 f0 0f 84 f9 00 00 00 41 80
[38179.854657] RSP: 0018:ffffc90001a5f900 EFLAGS: 00010286
[38179.854658] RAX: ffffea0000000000 RBX: 80000000000ffe00 RCX: 000000000000003c
[38179.854659] RDX: 80000000000ffe00 RSI: 0000000000000000 RDI: ffff8884417f42c0
[38179.854660] RBP: 8000000000100000 R08: 0000000000000000 R09: ffff8884417fab80
[38179.854661] R10: 0000000003ff8000 R11: 8000000000122c00 R12: 0000000000000020
[38179.854662] R13: ffffea0003ff8000 R14: 0000160000000000 R15: ffffc90001a5fae0
[38179.854664] FS: 0000000000000000(0000) GS:ffff888431800000(0000) knlGS:0000000000000000
[38179.854665] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[38179.854666] CR2: 00007f87c26a5000 CR3: 000000033154a006 CR4: 00000000003626f0
[38179.854667] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[38179.854667] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Is that a known issue? I currently have this with 5.1.5, are there patches in
the queue that may be candidates to stabilize my wireless again?
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
^ permalink raw reply
* Re: [PATCH wireless-drivers] mt76: usb: fix buffer allocation for scatter-gather capable devices
From: Lorenzo Bianconi @ 2019-05-30 9:23 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, nbd, lorenzo.bianconi, sgruszka
In-Reply-To: <87zhn4pmjv.fsf@codeaurora.org>
[-- Attachment #1: Type: text/plain, Size: 968 bytes --]
> Lorenzo Bianconi <lorenzo@kernel.org> writes:
>
> > Partially revert commit f8f527b16db5 ("mt76: usb: use EP max packet
> > aligned buffer sizes for rx") since it breaks A-MSDU support.
> > When A-MSDU is enable the device can receive frames up to
> > q->buf_size but they will be discarded in mt76u_process_rx_entry
> > since there is no enough room for skb_shared_info.
> > Fix it by introducing q->data_size and take info account
> > skb_shared_info size in q->buf_size
> > Moreover increase buffer size even for legacy mode (scatter-gather not
> > available)
> >
> > Fixes: f8f527b16db5 ("mt76: usb: use EP max packet aligned buffer sizes for rx")
> > Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
>
> Felix, can I take this directly to wireless-drivers?
Hi Kalle,
please hold on with this patch, I will post a new one with a different
approach based on what Felix has suggested me
Regards,
Lorenzo
>
> --
> Kalle Valo
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH v5] ath10k: add support for controlling tx power to a station
From: Balaji Pothunoori @ 2019-05-30 9:47 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Ashok Raj Nagarajan, Balaji Pothunoori
From: Ashok Raj Nagarajan <arnagara@codeaurora.org>
This patch will add the support to control the transmit power for traffic
to a station associated with the AP.
Underlying firmware will enforce that the maximum tx power will be based
on the regulatory requirements. If the user given transmit power is greater
than the allowed tx power in the given channel, then the firmware will use
the maximum tx power in the same channel.
Max and Min tx power values will depends on no of tx chain masks,
for QCA9984 allowed tx power range values from 6 to 23.
When 0 is sent to the firmware as tx power, it will revert to the default
tx power for the station.
Tested Hardware : QCA9984
Tested Firmware : 10.4-3.9.0.2-00046
Co-developed-by: Balaji Pothunoori <bpothuno@codeaurora.org>
Signed-off-by: Ashok Raj Nagarajan <arnagara@codeaurora.org>
Signed-off-by: Balaji Pothunoori <bpothuno@codeaurora.org>
---
v2: removed mBm to dBm conversion
v3: rebased wmi.h changes
v4: no changes, rebased
v5: updated firmware details which
addresses Bob comments.
updated commit log.
Note: mac80211/cfg80211 patches got merged hence sending
ath10k alone with v5 and mentioned 10.4-3.9.0.2-00046
firmware is yet to be upstream.
patchwork links :
https://patchwork.kernel.org/patch/10876859/
https://patchwork.kernel.org/patch/10876853/
drivers/net/wireless/ath/ath10k/debug.h | 3 +++
drivers/net/wireless/ath/ath10k/mac.c | 39 +++++++++++++++++++++++++++++++++
drivers/net/wireless/ath/ath10k/wmi.h | 6 +++++
3 files changed, 48 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/debug.h b/drivers/net/wireless/ath/ath10k/debug.h
index db78e85..2e43d8d 100644
--- a/drivers/net/wireless/ath/ath10k/debug.h
+++ b/drivers/net/wireless/ath/ath10k/debug.h
@@ -71,6 +71,9 @@ struct ath10k_pktlog_hdr {
/* FIXME: How to calculate the buffer size sanely? */
#define ATH10K_FW_STATS_BUF_SIZE (1024 * 1024)
+#define ATH10K_TX_POWER_MAX_VAL 70
+#define ATH10K_TX_POWER_MIN_VAL 0
+
extern unsigned int ath10k_debug_mask;
__printf(2, 3) void ath10k_info(struct ath10k *ar, const char *fmt, ...);
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index b500fd4..7e3e403 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -6358,6 +6358,41 @@ static void ath10k_mac_dec_num_stations(struct ath10k_vif *arvif,
ar->num_stations--;
}
+static int ath10k_sta_set_txpwr(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif,
+ struct ieee80211_sta *sta)
+{
+ struct ath10k *ar = hw->priv;
+ struct ath10k_vif *arvif = (void *)vif->drv_priv;
+ int ret = 0;
+ s16 txpwr;
+
+ if (sta->txpwr.type == NL80211_TX_POWER_AUTOMATIC) {
+ txpwr = 0;
+ } else {
+ txpwr = sta->txpwr.power;
+ if (!txpwr)
+ return -EINVAL;
+ }
+
+ if (txpwr > ATH10K_TX_POWER_MAX_VAL || txpwr < ATH10K_TX_POWER_MIN_VAL)
+ return -EINVAL;
+
+ mutex_lock(&ar->conf_mutex);
+
+ ret = ath10k_wmi_peer_set_param(ar, arvif->vdev_id, sta->addr,
+ WMI_PEER_USE_FIXED_PWR, txpwr);
+ if (ret) {
+ ath10k_warn(ar, "failed to set tx power for station ret: %d\n",
+ ret);
+ goto out;
+ }
+
+out:
+ mutex_unlock(&ar->conf_mutex);
+ return ret;
+}
+
static int ath10k_sta_state(struct ieee80211_hw *hw,
struct ieee80211_vif *vif,
struct ieee80211_sta *sta,
@@ -8015,6 +8050,7 @@ static const struct ieee80211_ops ath10k_ops = {
.set_key = ath10k_set_key,
.set_default_unicast_key = ath10k_set_default_unicast_key,
.sta_state = ath10k_sta_state,
+ .sta_set_txpwr = ath10k_sta_set_txpwr,
.conf_tx = ath10k_conf_tx,
.remain_on_channel = ath10k_remain_on_channel,
.cancel_remain_on_channel = ath10k_cancel_remain_on_channel,
@@ -8703,6 +8739,9 @@ int ath10k_mac_register(struct ath10k *ar)
wiphy_ext_feature_set(ar->hw->wiphy,
NL80211_EXT_FEATURE_ENABLE_FTM_RESPONDER);
+ if (test_bit(WMI_SERVICE_TX_PWR_PER_PEER, ar->wmi.svc_map))
+ wiphy_ext_feature_set(ar->hw->wiphy,
+ NL80211_EXT_FEATURE_STA_TX_PWR);
/*
* on LL hardware queues are managed entirely by the FW
* so we only advertise to mac we can do the queues thing
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drivers/net/wireless/ath/ath10k/wmi.h
index 12f57f9..a0ed078 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -200,6 +200,7 @@ enum wmi_service {
WMI_SERVICE_RTT_RESPONDER_ROLE,
WMI_SERVICE_PER_PACKET_SW_ENCRYPT,
WMI_SERVICE_REPORT_AIRTIME,
+ WMI_SERVICE_TX_PWR_PER_PEER,
/* Remember to add the new value to wmi_service_name()! */
@@ -367,6 +368,7 @@ enum wmi_10_4_service {
WMI_10_4_SERVICE_RTT_RESPONDER_ROLE,
WMI_10_4_SERVICE_EXT_PEER_TID_CONFIGS_SUPPORT,
WMI_10_4_SERVICE_REPORT_AIRTIME,
+ WMI_10_4_SERVICE_TX_PWR_PER_PEER,
};
static inline char *wmi_service_name(enum wmi_service service_id)
@@ -491,6 +493,7 @@ static inline char *wmi_service_name(enum wmi_service service_id)
SVCSTR(WMI_SERVICE_RTT_RESPONDER_ROLE);
SVCSTR(WMI_SERVICE_PER_PACKET_SW_ENCRYPT);
SVCSTR(WMI_SERVICE_REPORT_AIRTIME);
+ SVCSTR(WMI_SERVICE_TX_PWR_PER_PEER);
case WMI_SERVICE_MAX:
return NULL;
@@ -818,6 +821,8 @@ static inline void wmi_10_4_svc_map(const __le32 *in, unsigned long *out,
WMI_SERVICE_PER_PACKET_SW_ENCRYPT, len);
SVCMAP(WMI_10_4_SERVICE_REPORT_AIRTIME,
WMI_SERVICE_REPORT_AIRTIME, len);
+ SVCMAP(WMI_10_4_SERVICE_TX_PWR_PER_PEER,
+ WMI_SERVICE_TX_PWR_PER_PEER, len);
}
#undef SVCMAP
@@ -6262,6 +6267,7 @@ enum wmi_peer_param {
WMI_PEER_USE_4ADDR = 0x6,
WMI_PEER_DEBUG = 0xa,
WMI_PEER_PHYMODE = 0xd,
+ WMI_PEER_USE_FIXED_PWR = 0x8,
WMI_PEER_DUMMY_VAR = 0xff, /* dummy parameter for STA PS workaround */
};
--
2.7.4
^ permalink raw reply related
* RE: [PATCH 1/2] mwifiex: add support for host wakeup via PCIE wake#
From: Ganapathi Bhat @ 2019-05-30 10:01 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
Cc: Cathy Luo, Zhiyuan Yang, James Cao, Rakesh Parmar,
Sharvari Harisangam
In-Reply-To: <1559209955-10089-1-git-send-email-gbhat@marvell.com>
Hi Kalle,
I have pushed two patches usingn 'git send-mail' and below patch is the first one;
I could not see the patches in patchwork page(https://patchwork.kernel.org/project/linux-wireless/list/); Did you get this patch?
Regards,
Ganapathi
> -----Original Message-----
> From: Ganapathi Bhat <gbhat@marvell.com>
> Sent: Thursday, May 30, 2019 3:23 PM
> To: linux-wireless@vger.kernel.org
> Cc: Cathy Luo <cluo@marvell.com>; Zhiyuan Yang <yangzy@marvell.com>;
> James Cao <jcao@marvell.com>; Rakesh Parmar <rakeshp@marvell.com>;
> Sharvari Harisangam <sharvari@marvell.com>; Ganapathi Bhat
> <gbhat@marvell.com>
> Subject: [PATCH 1/2] mwifiex: add support for host wakeup via PCIE wake#
>
> From: Sharvari Harisangam <sharvari@marvell.com>
>
> PCIE WAKE# is asserted by firmware, when WoWLAN conditions are
> matched. Current driver does not enable PME bit needed for WAKE#
> assertion, causing host to remain in sleep even after WoWLAN conditions are
> matched. This commit fixes it by enabling wakeup (PME bit) in suspend
> handler.
>
> Signed-off-by: Sharvari Harisangam <sharvari@marvell.com>
> Signed-off-by: Ganapathi Bhat <gbhat@marvell.com>
> ---
> drivers/net/wireless/marvell/mwifiex/pcie.c | 27 +++++++++++++++------------
> 1 file changed, 15 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c
> b/drivers/net/wireless/marvell/mwifiex/pcie.c
> index 3fe81b2..0bd81d4 100644
> --- a/drivers/net/wireless/marvell/mwifiex/pcie.c
> +++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
> @@ -147,11 +147,10 @@ static bool mwifiex_pcie_ok_to_access_hw(struct
> mwifiex_adapter *adapter)
> * If already not suspended, this function allocates and sends a host
> * sleep activate request to the firmware and turns off the traffic.
> */
> -static int mwifiex_pcie_suspend(struct device *dev)
> +static int mwifiex_pcie_suspend(struct pci_dev *pdev, pm_message_t
> +state)
> {
> struct mwifiex_adapter *adapter;
> struct pcie_service_card *card;
> - struct pci_dev *pdev = to_pci_dev(dev);
>
> card = pci_get_drvdata(pdev);
>
> @@ -160,7 +159,7 @@ static int mwifiex_pcie_suspend(struct device *dev)
>
> adapter = card->adapter;
> if (!adapter) {
> - dev_err(dev, "adapter is not valid\n");
> + dev_err(&pdev->dev, "adapter is not valid\n");
> return 0;
> }
>
> @@ -181,6 +180,10 @@ static int mwifiex_pcie_suspend(struct device *dev)
> set_bit(MWIFIEX_IS_SUSPENDED, &adapter->work_flags);
> clear_bit(MWIFIEX_IS_HS_ENABLING, &adapter->work_flags);
>
> + pci_enable_wake(pdev, pci_choose_state(pdev, state), 1);
> + pci_save_state(pdev);
> + pci_set_power_state(pdev, pci_choose_state(pdev, state));
> +
> return 0;
> }
>
> @@ -192,16 +195,20 @@ static int mwifiex_pcie_suspend(struct device
> *dev)
> * If already not resumed, this function turns on the traffic and
> * sends a host sleep cancel request to the firmware.
> */
> -static int mwifiex_pcie_resume(struct device *dev)
> +static int mwifiex_pcie_resume(struct pci_dev *pdev)
> {
> struct mwifiex_adapter *adapter;
> struct pcie_service_card *card;
> - struct pci_dev *pdev = to_pci_dev(dev);
> +
> + pci_set_power_state(pdev, PCI_D0);
> + pci_restore_state(pdev);
> + pci_enable_wake(pdev, PCI_D0, 0);
> +
>
> card = pci_get_drvdata(pdev);
>
> if (!card->adapter) {
> - dev_err(dev, "adapter structure is not valid\n");
> + dev_err(&pdev->dev, "adapter structure is not valid\n");
> return 0;
> }
>
> @@ -416,11 +423,6 @@ static void mwifiex_pcie_reset_done(struct pci_dev
> *pdev)
> .reset_done = mwifiex_pcie_reset_done,
> };
>
> -#ifdef CONFIG_PM_SLEEP
> -/* Power Management Hooks */
> -static SIMPLE_DEV_PM_OPS(mwifiex_pcie_pm_ops, mwifiex_pcie_suspend,
> - mwifiex_pcie_resume);
> -#endif
>
> /* PCI Device Driver */
> static struct pci_driver __refdata mwifiex_pcie = { @@ -431,7 +433,8 @@
> static SIMPLE_DEV_PM_OPS(mwifiex_pcie_pm_ops, mwifiex_pcie_suspend,
> .driver = {
> .coredump = mwifiex_pcie_coredump,
> #ifdef CONFIG_PM_SLEEP
> - .pm = &mwifiex_pcie_pm_ops,
> + .suspend = mwifiex_pcie_suspend,
> + .resume = mwifiex_pcie_resume,
> #endif
> },
> .shutdown = mwifiex_pcie_shutdown,
> --
> 1.9.1
^ permalink raw reply
* RE: [PATCH 2/2] mwifiex: add support for WIPHY_WOWLAN_ANY
From: Ganapathi Bhat @ 2019-05-30 10:03 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
Cc: Cathy Luo, Zhiyuan Yang, James Cao, Rakesh Parmar,
Sharvari Harisangam
In-Reply-To: <1559209955-10089-2-git-send-email-gbhat@marvell.com>
Hi Kalle,
Below is the second patch in the series; Kindly help to merge both;
Regards,
Ganapathi
> -----Original Message-----
> From: Ganapathi Bhat <gbhat@marvell.com>
> Sent: Thursday, May 30, 2019 3:23 PM
> To: linux-wireless@vger.kernel.org
> Cc: Cathy Luo <cluo@marvell.com>; Zhiyuan Yang <yangzy@marvell.com>;
> James Cao <jcao@marvell.com>; Rakesh Parmar <rakeshp@marvell.com>;
> Sharvari Harisangam <sharvari@marvell.com>; Ganapathi Bhat
> <gbhat@marvell.com>
> Subject: [PATCH 2/2] mwifiex: add support for WIPHY_WOWLAN_ANY
>
> From: Sharvari Harisangam <sharvari@marvell.com>
>
> Advertise support for WIPHY_WOWLAN_ANY trigger. Update default
> hostsleep condition to handle magic packet.
>
> Signed-off-by: Sharvari Harisangam <sharvari@marvell.com>
> Signed-off-by: Ganapathi Bhat <gbhat@marvell.com>
> ---
> drivers/net/wireless/marvell/mwifiex/cfg80211.c | 6 +++---
> drivers/net/wireless/marvell/mwifiex/fw.h | 4 +++-
> 2 files changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> index e11a4bb..f23bb9c 100644
> --- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> +++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
> @@ -3492,7 +3492,7 @@ static int mwifiex_cfg80211_suspend(struct wiphy
> *wiphy,
> wowlan->nd_config);
> }
>
> - if (wowlan->disconnect) {
> + if (wowlan->disconnect || wowlan->any || wowlan->magic_pkt) {
> hs_cfg.conditions |= HS_CFG_COND_MAC_EVENT;
> mwifiex_dbg(sta_priv->adapter, INFO, "Wake on device
> disconnect\n");
> }
> @@ -4232,7 +4232,7 @@ static int mwifiex_tm_cmd(struct wiphy *wiphy,
> struct wireless_dev *wdev, static const struct wiphy_wowlan_support
> mwifiex_wowlan_support = {
> .flags = WIPHY_WOWLAN_MAGIC_PKT |
> WIPHY_WOWLAN_DISCONNECT |
> WIPHY_WOWLAN_NET_DETECT |
> WIPHY_WOWLAN_SUPPORTS_GTK_REKEY |
> - WIPHY_WOWLAN_GTK_REKEY_FAILURE,
> + WIPHY_WOWLAN_GTK_REKEY_FAILURE |
> WIPHY_WOWLAN_ANY,
> .n_patterns = MWIFIEX_MEF_MAX_FILTERS,
> .pattern_min_len = 1,
> .pattern_max_len = MWIFIEX_MAX_PATTERN_LEN, @@ -4242,7
> +4242,7 @@ static int mwifiex_tm_cmd(struct wiphy *wiphy, struct
> wireless_dev *wdev,
>
> static const struct wiphy_wowlan_support
> mwifiex_wowlan_support_no_gtk = {
> .flags = WIPHY_WOWLAN_MAGIC_PKT |
> WIPHY_WOWLAN_DISCONNECT |
> - WIPHY_WOWLAN_NET_DETECT,
> + WIPHY_WOWLAN_NET_DETECT | WIPHY_WOWLAN_ANY,
> .n_patterns = MWIFIEX_MEF_MAX_FILTERS,
> .pattern_min_len = 1,
> .pattern_max_len = MWIFIEX_MAX_PATTERN_LEN, diff --git
> a/drivers/net/wireless/marvell/mwifiex/fw.h
> b/drivers/net/wireless/marvell/mwifiex/fw.h
> index b73f99d..ad34b25 100644
> --- a/drivers/net/wireless/marvell/mwifiex/fw.h
> +++ b/drivers/net/wireless/marvell/mwifiex/fw.h
> @@ -478,7 +478,9 @@ enum mwifiex_channel_flags {
> #define HostCmd_SCAN_RADIO_TYPE_A 1
>
> #define HS_CFG_CANCEL 0xffffffff
> -#define HS_CFG_COND_DEF 0x00000000
> +#define HS_CFG_COND_DEF (HS_CFG_COND_BROADCAST_DATA
> |\
> + HS_CFG_COND_UNICAST_DATA |\
> + HS_CFG_COND_MULTICAST_DATA)
> #define HS_CFG_GPIO_DEF 0xff
> #define HS_CFG_GAP_DEF 0xff
> #define HS_CFG_COND_BROADCAST_DATA 0x00000001
> --
> 1.9.1
^ permalink raw reply
* Re: [PATCH wireless-drivers] mt76: usb: fix buffer allocation for scatter-gather capable devices
From: Kalle Valo @ 2019-05-30 10:19 UTC (permalink / raw)
To: Lorenzo Bianconi; +Cc: linux-wireless, nbd, lorenzo.bianconi, sgruszka
In-Reply-To: <20190530092327.GA2626@localhost.localdomain>
Lorenzo Bianconi <lorenzo@kernel.org> writes:
>> Lorenzo Bianconi <lorenzo@kernel.org> writes:
>>
>> > Partially revert commit f8f527b16db5 ("mt76: usb: use EP max packet
>> > aligned buffer sizes for rx") since it breaks A-MSDU support.
>> > When A-MSDU is enable the device can receive frames up to
>> > q->buf_size but they will be discarded in mt76u_process_rx_entry
>> > since there is no enough room for skb_shared_info.
>> > Fix it by introducing q->data_size and take info account
>> > skb_shared_info size in q->buf_size
>> > Moreover increase buffer size even for legacy mode (scatter-gather not
>> > available)
>> >
>> > Fixes: f8f527b16db5 ("mt76: usb: use EP max packet aligned buffer sizes for rx")
>> > Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
>>
>> Felix, can I take this directly to wireless-drivers?
>
> Hi Kalle,
>
> please hold on with this patch, I will post a new one with a different
> approach based on what Felix has suggested me
Ok, thanks for letting me know.
--
Kalle Valo
^ permalink raw reply
* [PATCH] wireless-regdb: update source of information for CU
From: Xose Vazquez Perez @ 2019-05-30 11:00 UTC (permalink / raw)
Cc: Xose Vazquez Perez, Seth Forshee, WIRELESS ML, REGDB ML
Cc: Seth Forshee <seth.forshee@canonical.com>
Cc: WIRELESS ML <linux-wireless@vger.kernel.org>
Cc: REGDB ML <wireless-regdb@lists.infradead.org>
Signed-off-by: Xose Vazquez Perez <xose.vazquez@gmail.com>
---
db.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/db.txt b/db.txt
index 6b65312..3bdc7c0 100644
--- a/db.txt
+++ b/db.txt
@@ -316,7 +316,7 @@ country CR: DFS-FCC
(5735 - 5835 @ 20), (30)
# Source:
-# http://www.mincom.gob.cu/?q=marcoregulatorio
+# https://www.mincom.gob.cu/es/marco-legal
# - Redes Informáticas
# Resolución 127- 2011 Reglamento de Banda de frecuencias de 2,4 GHz.
country CU: DFS-FCC
--
2.21.0
^ permalink raw reply related
* Re: [PATCH 1/2] mwifiex: Fix possible buffer overflows at parsing bss descriptor
From: Kalle Valo @ 2019-05-30 11:22 UTC (permalink / raw)
To: Takashi Iwai
Cc: linux-wireless, Amitkumar Karwar, Nishant Sarmukadam,
Ganapathi Bhat, Xinming Hu, huangwen, Solar Designer,
Marcus Meissner
In-Reply-To: <20190529125220.17066-2-tiwai@suse.de>
Takashi Iwai <tiwai@suse.de> wrote:
> mwifiex_update_bss_desc_with_ie() calls memcpy() unconditionally in
> a couple places without checking the destination size. Since the
> source is given from user-space, this may trigger a heap buffer
> overflow.
>
> Fix it by putting the length check before performing memcpy().
>
> This fix addresses CVE-2019-3846.
>
> Reported-by: huangwen <huangwen@venustech.com.cn>
> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2 patches applied to wireless-drivers.git, thanks.
13ec7f10b87f mwifiex: Fix possible buffer overflows at parsing bss descriptor
685c9b7750bf mwifiex: Abort at too short BSS descriptor element
--
https://patchwork.kernel.org/patch/10967049/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [RFC 1/8] nl80211: add 6GHz band definition to enum nl80211_band
From: Jeff Johnson @ 2019-05-30 14:53 UTC (permalink / raw)
To: Arend van Spriel; +Cc: linux-wireless
In-Reply-To: <1558353645-18119-2-git-send-email-arend.vanspriel@broadcom.com>
On 2019-05-20 05:00, Arend van Spriel wrote:
> [...snip...]
> enum nl80211_band {
> NL80211_BAND_2GHZ,
> NL80211_BAND_5GHZ,
> + NL80211_BAND_6GHZ,
> NL80211_BAND_60GHZ,
>
> NUM_NL80211_BANDS,
Is it not a concern that this changes the value of NL80211_BAND_60GHZ
and hence will break any ABI which expects the current value?
^ permalink raw reply
* Re: [RFC 1/8] nl80211: add 6GHz band definition to enum nl80211_band
From: Arend Van Spriel @ 2019-05-30 16:07 UTC (permalink / raw)
To: Jeff Johnson; +Cc: linux-wireless
In-Reply-To: <d27aac46e682d6cb93ac97df0073818c@codeaurora.org>
On May 30, 2019 4:53:13 PM Jeff Johnson <jjohnson@codeaurora.org> wrote:
> On 2019-05-20 05:00, Arend van Spriel wrote:
>> [...snip...]
>> enum nl80211_band {
>> NL80211_BAND_2GHZ,
>> NL80211_BAND_5GHZ,
>> + NL80211_BAND_6GHZ,
>> NL80211_BAND_60GHZ,
>>
>> NUM_NL80211_BANDS,
>
> Is it not a concern that this changes the value of NL80211_BAND_60GHZ
> and hence will break any ABI which expects the current value?
Sigh! Obviously that is a concern. Johannes already mentioned it.
Thanks,
Arend
^ permalink raw reply
* Re: [RFC PATCH v3] rtl8xxxu: Improve TX performance of RTL8723BU on rtl8xxxu driver
From: Daniel Drake @ 2019-05-30 16:18 UTC (permalink / raw)
To: Chris Chiu
Cc: Jes Sorensen, Kalle Valo, David Miller, linux-wireless, netdev,
Linux Kernel, Linux Upstreaming Team
In-Reply-To: <CAB4CAwfVDfphWNAN5L1f9BCT9Oo3AQwL19BOUTNJNFM=QR7rjQ@mail.gmail.com>
On Wed, May 29, 2019 at 10:52 PM Chris Chiu <chiu@endlessm.com> wrote:
> You mean moving the ratr_index to be the 4th function parameter of
> update_rate_mask which has 2 candidates rtl8xxxu_update_rate_mask
> and rtl8xxxu_gen2_update_rate_mask? I was planning to keep the
> rtl8xxxu_update_rate_mask the same because old chips seems don't
> need the rate index when invoking H2C command to change rate mask.
> And rate index is not a common phrase/term for rate adaptive. Theoretically
> we just need packet error rate, sgi and other factors to determine the rate
> mask. This rate index seems to be only specific to newer Realtek drivers
> or firmware for rate adaptive algorithm. I'd like to keep this for gen2 but
> I admit it's ugly to put it in the priv structure. Any suggestion is
> appreciated.
I think it's cleaner to have it as a function parameter, even if the
old chips don't use it.
The rest of the implementation is in the core, so we aren't exactly
dealing with chip-specific code here, at least the way it's currently
done.
The vendor driver also has it as a function parameter from what I can see.
Daniel
^ permalink raw reply
* Re: [RFC 1/8] nl80211: add 6GHz band definition to enum nl80211_band
From: Jeff Johnson @ 2019-05-30 17:43 UTC (permalink / raw)
To: Arend Van Spriel; +Cc: linux-wireless
In-Reply-To: <16b097efa48.2764.9b12b7fc0a3841636cfb5e919b41b954@broadcom.com>
On 2019-05-30 09:07, Arend Van Spriel wrote:
> Sigh! Obviously that is a concern. Johannes already mentioned it.
Sorry, overlooked his comment on the [0/8] patch. I'll climb back under
my rock.
^ permalink raw reply
* Re: [RFC 1/8] nl80211: add 6GHz band definition to enum nl80211_band
From: Arend Van Spriel @ 2019-05-30 17:52 UTC (permalink / raw)
To: Jeff Johnson; +Cc: linux-wireless
In-Reply-To: <284014c56afe555b5fda60a8467f8e6a@codeaurora.org>
On May 30, 2019 7:43:27 PM Jeff Johnson <jjohnson@codeaurora.org> wrote:
> On 2019-05-30 09:07, Arend Van Spriel wrote:
>> Sigh! Obviously that is a concern. Johannes already mentioned it.
>
> Sorry, overlooked his comment on the [0/8] patch. I'll climb back under
> my rock.
No need to do that. It is mainly me feeling stupid about making such a
mistake that makes me sigh ;-)
Regards,
Arend
^ permalink raw reply
* [PATCH] rtlwifi: remove redundant assignment to variable badworden
From: Colin King @ 2019-05-30 18:40 UTC (permalink / raw)
To: Ping-Ke Shih, Kalle Valo, David S . Miller, linux-wireless,
netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
The variable badworden is assigned with a value that is never read and
it is re-assigned a new value immediately afterwards. The assignment is
redundant and can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/wireless/realtek/rtlwifi/efuse.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/efuse.c b/drivers/net/wireless/realtek/rtlwifi/efuse.c
index e68340dfd980..37ab582a8afb 100644
--- a/drivers/net/wireless/realtek/rtlwifi/efuse.c
+++ b/drivers/net/wireless/realtek/rtlwifi/efuse.c
@@ -986,7 +986,6 @@ static int efuse_pg_packet_write(struct ieee80211_hw *hw,
} else if (write_state == PG_STATE_DATA) {
RTPRINT(rtlpriv, FEEPROM, EFUSE_PG,
"efuse PG_STATE_DATA\n");
- badworden = 0x0f;
badworden =
enable_efuse_data_write(hw, efuse_addr + 1,
target_pkt.word_en,
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] rtlwifi: remove redundant assignment to variable badworden
From: Larry Finger @ 2019-05-30 18:50 UTC (permalink / raw)
To: Colin King, Ping-Ke Shih, Kalle Valo, David S . Miller,
linux-wireless, netdev
Cc: kernel-janitors, linux-kernel
In-Reply-To: <20190530184044.8479-1-colin.king@canonical.com>
On 5/30/19 1:40 PM, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> The variable badworden is assigned with a value that is never read and
> it is re-assigned a new value immediately afterwards. The assignment is
> redundant and can be removed.
>
> Addresses-Coverity: ("Unused value")
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Thanks,
Larry
> drivers/net/wireless/realtek/rtlwifi/efuse.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/net/wireless/realtek/rtlwifi/efuse.c b/drivers/net/wireless/realtek/rtlwifi/efuse.c
> index e68340dfd980..37ab582a8afb 100644
> --- a/drivers/net/wireless/realtek/rtlwifi/efuse.c
> +++ b/drivers/net/wireless/realtek/rtlwifi/efuse.c
> @@ -986,7 +986,6 @@ static int efuse_pg_packet_write(struct ieee80211_hw *hw,
> } else if (write_state == PG_STATE_DATA) {
> RTPRINT(rtlpriv, FEEPROM, EFUSE_PG,
> "efuse PG_STATE_DATA\n");
> - badworden = 0x0f;
> badworden =
> enable_efuse_data_write(hw, efuse_addr + 1,
> target_pkt.word_en,
>
^ permalink raw reply
* Re: [PATCH v3] {nl,mac}80211: allow 4addr AP operation on crypto controlled devices
From: Manikanta Pubbisetty @ 2019-05-31 4:33 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <fd3addc01fc3f5362dba5771ee82659cf01c195b.camel@sipsolutions.net>
On 5/14/2019 2:08 PM, Johannes Berg wrote:
> On Wed, 2019-05-08 at 14:55 +0530, Manikanta Pubbisetty wrote:
>> +++ b/net/mac80211/util.c
>> @@ -3795,7 +3795,9 @@ int ieee80211_check_combinations(struct ieee80211_sub_if_data *sdata,
>> }
>>
>> /* Always allow software iftypes */
>> - if (local->hw.wiphy->software_iftypes & BIT(iftype)) {
>> + if (local->hw.wiphy->software_iftypes & BIT(iftype) ||
>> + (iftype == NL80211_IFTYPE_AP_VLAN &&
>> + local->hw.wiphy->flags & WIPHY_FLAG_4ADDR_AP)) {
>> if (radar_detect)
>> return -EINVAL;
> Shouldn't this check if 4addr is actually enabled too, like here:
Sure Johannes, I'll look into it.
>> case NETDEV_PRE_UP:
>> - if (!(wdev->wiphy->interface_modes & BIT(wdev->iftype)))
>> + if (!(wdev->wiphy->interface_modes & BIT(wdev->iftype)) &&
>> + !(wdev->iftype == NL80211_IFTYPE_AP_VLAN &&
>> + rdev->wiphy.flags & WIPHY_FLAG_4ADDR_AP &&
>> + wdev->use_4addr))
>> return notifier_from_errno(-EOPNOTSUPP);
> ?
> Or is there some reason it doesn't matter?
>
>> @@ -3439,6 +3438,11 @@ static int nl80211_new_interface(struct sk_buff *skb, struct genl_info *info)
>> return err;
>> }
>>
>> + if (!(rdev->wiphy.interface_modes & (1 << type)) &&
>> + !(type == NL80211_IFTYPE_AP_VLAN && params.use_4addr &&
>> + rdev->wiphy.flags & WIPHY_FLAG_4ADDR_AP))
>> + return -EOPNOTSUPP;
>> +
> I also wonder if we shouldn't go "all in" and actually make the check
> something like
>
> check_interface_allowed(iftype, 4addr):
> if (iftype == AP_VLAN && 4addr)
> return wiphy.flags & WIPHY_FLAG_4ADDR_AP;
>
> else return wiphy.interface_modes & BIT(iftype);
>
> i.e. make it "you must have WIPHY_FLAG_4ADDR_AP to use 4-addr AP_VLAN
> interfaces", rather than "also allow it in this case".
>
> That would seem like the clearer semantics to me?
Yeah, it can be better; I'll check if this is feasible.
Thanks,
Manikanta
^ permalink raw reply
* Re: [PATCH 00/16] wilc1000: move out of staging
From: Ajay.Kathat @ 2019-05-31 4:53 UTC (permalink / raw)
To: kvalo
Cc: linux-wireless, johannes, gregkh, Adham.Abozaeid,
Venkateswara.Kaja, Nicolas.Ferre, Claudiu.Beznea
In-Reply-To: <fb17fb6b-08d2-6871-d214-2fbcc1da73fb@microchip.com>
Hi Kalle,
On 5/23/2019 10:15 PM, Ajay.Kathat@microchip.com wrote:
> Hi Kalle,
>
> On 5/23/2019 7:43 PM, Kalle Valo wrote:
>> <Ajay.Kathat@microchip.com> writes:
>>
>>> Hi Kalle,
>>>
>>> On 3/21/2019 6:24 PM, Kalle Valo wrote:
>>>>
>>>> <Ajay.Kathat@microchip.com> writes:
>>>>
>>>>> Hi Kalle/Johannes,
>>>>>
>>>>> On 2/9/2019 12:42 PM, Ajay Kathat - I15481 wrote:
>>>>>> From: Ajay Singh <ajay.kathat@microchip.com>
>>>>>>
>>>>>> This patch series is to review and move wilc1000 driver out of staging.
>>>>>> Implemented the initial received review comments[1] and submitting the
>>>>>> driver again. During this cleanup deleted around 3.3k lines of code.
>>>>>>
>>>>>> Below are the major items fixed in recent cleanup:
>>>>>> - remove use of shadow buffer to keep scan result.
>>>>>> - remove internal messaging flow to handle cfg80211_ops.
>>>>>> - make use of cfg80211 provided API.
>>>>>> - use structure for packing firmware commands.
>>>>>> - make use of kernel provided API and macros.
>>>>>> - remove unnecessary logs messages.
>>>>>>
>>>>>> Pending action item:
>>>>>> - dynamically add/remove p2p interface.
>>>>>>
>>>>>> This item will take some time, we are planning to take it up after
>>>>>> mainline.
>>>>>>
>>>>>> We hope it can be move out staging in v5.1.
>>>>>> Please review and confirm if it is good to move out.
>>>>>
>>>>> Do you have any update for this series. Please provide your inputs for
>>>>> next step.
>>>>
>>>> rtw88 is taking priority in the new drivers "queue" so I doubt I can
>>>> take a look at this in the next few weeks.
>>>>
>>>
>>> Is there any update for wilc1000 driver review. Please let me know your
>>> inputs.
>>
>> So is the driver in good shape now? I really do not want to use a lot of
>> time reviewing it just to find out that there's a lot of work to do. For
>> example, has someone else reviewed it?
>>
>
> The first series for complete driver review was submitted earlier [1].
> It was reviewed by Johannes and he looked into driver integration with
> the cfg80211 stack part. We worked on the review comments and submitted
> the changes to staging.
>
> We need further review to identify if there is any blocker to move to
> mainline.
>
> [1]. https://www.spinics.net/lists/linux-wireless/msg177878.html
>
Just a gentle mail to check if wilc1000 driver is picked-up for review
and what is the next step.
Regards,
Ajay
^ permalink raw reply
* Re: [PATCH 00/16] wilc1000: move out of staging
From: Kalle Valo @ 2019-05-31 6:23 UTC (permalink / raw)
To: Ajay.Kathat
Cc: linux-wireless, johannes, gregkh, Adham.Abozaeid,
Venkateswara.Kaja, Nicolas.Ferre, Claudiu.Beznea
In-Reply-To: <8e227b89-6068-266c-f41d-1c45664d57d1@microchip.com>
<Ajay.Kathat@microchip.com> writes:
> Hi Kalle,
>
> On 5/23/2019 10:15 PM, Ajay.Kathat@microchip.com wrote:
>> Hi Kalle,
>>
>> On 5/23/2019 7:43 PM, Kalle Valo wrote:
>>> <Ajay.Kathat@microchip.com> writes:
>>>
>>>> Hi Kalle,
>>>>
>>>> On 3/21/2019 6:24 PM, Kalle Valo wrote:
>>>>>
>>>>> <Ajay.Kathat@microchip.com> writes:
>>>>>
>>>>>> Hi Kalle/Johannes,
>>>>>>
>>>>>> On 2/9/2019 12:42 PM, Ajay Kathat - I15481 wrote:
>>>>>>> From: Ajay Singh <ajay.kathat@microchip.com>
>>>>>>>
>>>>>>> This patch series is to review and move wilc1000 driver out of staging.
>>>>>>> Implemented the initial received review comments[1] and submitting the
>>>>>>> driver again. During this cleanup deleted around 3.3k lines of code.
>>>>>>>
>>>>>>> Below are the major items fixed in recent cleanup:
>>>>>>> - remove use of shadow buffer to keep scan result.
>>>>>>> - remove internal messaging flow to handle cfg80211_ops.
>>>>>>> - make use of cfg80211 provided API.
>>>>>>> - use structure for packing firmware commands.
>>>>>>> - make use of kernel provided API and macros.
>>>>>>> - remove unnecessary logs messages.
>>>>>>>
>>>>>>> Pending action item:
>>>>>>> - dynamically add/remove p2p interface.
>>>>>>>
>>>>>>> This item will take some time, we are planning to take it up after
>>>>>>> mainline.
>>>>>>>
>>>>>>> We hope it can be move out staging in v5.1.
>>>>>>> Please review and confirm if it is good to move out.
>>>>>>
>>>>>> Do you have any update for this series. Please provide your inputs for
>>>>>> next step.
>>>>>
>>>>> rtw88 is taking priority in the new drivers "queue" so I doubt I can
>>>>> take a look at this in the next few weeks.
>>>>>
>>>>
>>>> Is there any update for wilc1000 driver review. Please let me know your
>>>> inputs.
>>>
>>> So is the driver in good shape now? I really do not want to use a lot of
>>> time reviewing it just to find out that there's a lot of work to do. For
>>> example, has someone else reviewed it?
>>>
>>
>> The first series for complete driver review was submitted earlier [1].
>> It was reviewed by Johannes and he looked into driver integration with
>> the cfg80211 stack part. We worked on the review comments and submitted
>> the changes to staging.
>>
>> We need further review to identify if there is any blocker to move to
>> mainline.
>>
>> [1]. https://www.spinics.net/lists/linux-wireless/msg177878.html
>>
>
> Just a gentle mail to check if wilc1000 driver is picked-up for review
> and what is the next step.
Please be patient, getting a driver upstream is not a simple task. What
this driver needs now is reviews and people saying that the driver is
ready for upstream, I have not seen any of that yet. Maybe you could
submit a new version, hopefully that triggers people to review this?
Also I'll try to find time for review but, as usual, I'm really busy.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 00/16] wilc1000: move out of staging
From: Ajay.Kathat @ 2019-05-31 7:11 UTC (permalink / raw)
To: kvalo
Cc: linux-wireless, johannes, gregkh, Adham.Abozaeid,
Venkateswara.Kaja, Nicolas.Ferre, Claudiu.Beznea
In-Reply-To: <87zhn3ywfh.fsf@kamboji.qca.qualcomm.com>
On 5/31/2019 11:53 AM, Kalle Valo wrote:
> External E-Mail
>
>
> <Ajay.Kathat@microchip.com> writes:
>
>> Hi Kalle,
>>
>> On 5/23/2019 10:15 PM, Ajay.Kathat@microchip.com wrote:
>>> Hi Kalle,
>>>
>>> On 5/23/2019 7:43 PM, Kalle Valo wrote:
>>>> <Ajay.Kathat@microchip.com> writes:
>>>>
>>>>> Hi Kalle,
>>>>>
>>>>> On 3/21/2019 6:24 PM, Kalle Valo wrote:
>>>>>>
>>>>>> <Ajay.Kathat@microchip.com> writes:
>>>>>>
>>>>>>> Hi Kalle/Johannes,
>>>>>>>
>>>>>>> On 2/9/2019 12:42 PM, Ajay Kathat - I15481 wrote:
>>>>>>>> From: Ajay Singh <ajay.kathat@microchip.com>
>>>>>>>>
>>>>>>>> This patch series is to review and move wilc1000 driver out of staging.
>>>>>>>> Implemented the initial received review comments[1] and submitting the
>>>>>>>> driver again. During this cleanup deleted around 3.3k lines of code.
>>>>>>>>
>>>>>>>> Below are the major items fixed in recent cleanup:
>>>>>>>> - remove use of shadow buffer to keep scan result.
>>>>>>>> - remove internal messaging flow to handle cfg80211_ops.
>>>>>>>> - make use of cfg80211 provided API.
>>>>>>>> - use structure for packing firmware commands.
>>>>>>>> - make use of kernel provided API and macros.
>>>>>>>> - remove unnecessary logs messages.
>>>>>>>>
>>>>>>>> Pending action item:
>>>>>>>> - dynamically add/remove p2p interface.
>>>>>>>>
>>>>>>>> This item will take some time, we are planning to take it up after
>>>>>>>> mainline.
>>>>>>>>
>>>>>>>> We hope it can be move out staging in v5.1.
>>>>>>>> Please review and confirm if it is good to move out.
>>>>>>>
>>>>>>> Do you have any update for this series. Please provide your inputs for
>>>>>>> next step.
>>>>>>
>>>>>> rtw88 is taking priority in the new drivers "queue" so I doubt I can
>>>>>> take a look at this in the next few weeks.
>>>>>>
>>>>>
>>>>> Is there any update for wilc1000 driver review. Please let me know your
>>>>> inputs.
>>>>
>>>> So is the driver in good shape now? I really do not want to use a lot of
>>>> time reviewing it just to find out that there's a lot of work to do. For
>>>> example, has someone else reviewed it?
>>>>
>>>
>>> The first series for complete driver review was submitted earlier [1].
>>> It was reviewed by Johannes and he looked into driver integration with
>>> the cfg80211 stack part. We worked on the review comments and submitted
>>> the changes to staging.
>>>
>>> We need further review to identify if there is any blocker to move to
>>> mainline.
>>>
>>> [1]. https://www.spinics.net/lists/linux-wireless/msg177878.html
>>>
>>
>> Just a gentle mail to check if wilc1000 driver is picked-up for review
>> and what is the next step.
>
> Please be patient, getting a driver upstream is not a simple task. What
> this driver needs now is reviews and people saying that the driver is
> ready for upstream, I have not seen any of that yet. Maybe you could
> submit a new version, hopefully that triggers people to review this?
> Also I'll try to find time for review but, as usual, I'm really busy.
>
Thanks Kalle, I will wait for review comments and in the meantime I will
send the patch update.
Regards,
Ajay
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox