* Re: bcmdhd: Strange Power Save messages
From: Krishna Chaitanya @ 2016-10-04 18:54 UTC (permalink / raw)
To: Gucea Doru
Cc: Arend van Spriel, Arend van Spriel, Andra Paraschiv,
linux-wireless
In-Reply-To: <CANfLQrZs5EyTEMupsR=1M9gqo7ar88g6RHObJ=4fj3J3dkTtvQ@mail.gmail.com>
On Tue, Oct 4, 2016 at 11:57 PM, Gucea Doru <gucea.doru@gmail.com> wrote:
> On Tue, Oct 4, 2016 at 3:37 PM, Krishna Chaitanya
> <chaitanya.mgit@gmail.com> wrote:
>> On Tue, Oct 4, 2016 at 5:09 PM, Gucea Doru <gucea.doru@gmail.com> wrote:
>>> On Sat, Oct 1, 2016 at 2:52 PM, Arend van Spriel
>>>> <arend.vanspriel@broadcom.com> wrote:
>>>>>
>>>>>
>>>>> On 29-09-16 13:32, Gucea Doru wrote:
>>>>>> On Tue, Sep 27, 2016 at 12:03 PM, Gucea Doru <gucea.doru@gmail.com> wrote:
>>>>>>> What is the decision triggering the exit from the PS mode immediately
>>>>>>> after the ping request? I am asking this because 802.11 PS legacy
>>>>>>> specifies that the client should wait for a beacon with TIM set in
>>>>>>> order to wake up: in my case, there is no beacon between the ping
>>>>>>> request message and the Null frame that announces the exit from the PS
>>>>>>> mode.
>>>>>>
>>>>>>
>>>>>> Any help would be highly appreciated :)
>>>>>
>>>>> Actually though I already sent you are reply, but alas here it is.
>>>>>
>>>>> bcmdhd is our aosp driver. I am maintaining the upstream brcm80211
>>>>> drivers. Regardless your question is more for firmware running on the
>>>>> device. So like the same behavior would be observed when using brcmfmac
>>>>> with same firmware.
>>>>>
>>>>>> IEEE Std 802.11-2012, section 10.2.1.8 specifies that "when the STA
>>>>>> detects that the bit corresponding to its AID is 1 i the TIM, the STA
>>>>>> shall issue a PS Poll". In my capture there are cases when the STA
>>>>>> exits the PS mode without waiting for a beacon.
>>>>>
>>>>> It is a bit tricky, but the standard does not explicitly say the STA
>>>>> should be in power-save at any other time. So it is difficult to say
>>>>> what event occurred on the STA side to exit PS mode. Also STA means
>>>>> P2P-Client as you say. That means that you have multiple interfaces:
>>>>> regular STA and P2P-Client. So is the STA connected to some other AP or
>>>>> just not connected. wpa_supplicant will do intermittent scan or initiate
>>>>> scheduled scan by which firmware will scan at a certain interval. That
>>>>> is just some things I can come up with and I am sure there are more.
>>>
>>> I agree that there may be some events belonging to the regular STA
>>> interface that could trigger the Null Frame (which includes the exit
>>> from PS Mode). However, I would expect to see some management frames
>>> in the air before/after the Null Packet (e.g.: a Probe request in case
>>> of a scheduled scan). But in my case the trigger for the Null frame
>>> seems to be the ping request packet, the scenario is the same every
>>> time: ping request -> Block ACK -> Null Frame (Wireshark trace
>>> confirms this behavior).
>>>
>>> I thought that you had a power save optimization algorithm that keeps
>>> the card on a few milliseconds just to see if we can have a fast reply
>>> from the peer. Does this ring a bell? :)
>>>
>>> On Sat, Oct 1, 2016 at 3:02 PM, Krishna Chaitanya
>>> <chaitanya.mgit@gmail.com> wrote:
>>>> Keeping the STA aside, as far as AP is concerned the STA is still in PS,
>>>> so it should set the TIM/DTIM bit to 1 before sending out data to the STA.
>>>
>>> Not necessarily, see section 10.2.1.6/l from IEEE Std 802.11-2012:
>>> "When an AP is informed that a STA has changed to the Active mode,
>>> then the AP shall send buffered BUs (if any exist) to the STA without
>>> waiting for a PS Poll...."
>> Yes, but in this case the STA did not inform AP (as per sniffer captures)?
>> so AP should set TIM/DTIM...
>
> The STA _did_ inform the AP.
>
> If you take a look at the packet traces you'll see that the STA sends
> a NULL frame saying that it will exit Power Save Mode. According to
> the specification the AP can send the buffered frames.
Yeah, sorry i thought AP is sending the ping request.
But still as STA is sending "ping request" with PM=0, the state at
AP should be updated treating STA as active, so sending NULL data +
PM=0 is redundant.
--
Thanks,
Regards,
Chaitanya T K.
^ permalink raw reply
* Re: bcmdhd: Strange Power Save messages
From: Gucea Doru @ 2016-10-04 18:27 UTC (permalink / raw)
To: Krishna Chaitanya
Cc: Arend van Spriel, Arend van Spriel, Andra Paraschiv,
linux-wireless
In-Reply-To: <CABPxzY+yDnf6AOb4=yRo8jRCYD4FWJ0uBvmQnUSemwXQa2PQrg@mail.gmail.com>
On Tue, Oct 4, 2016 at 3:37 PM, Krishna Chaitanya
<chaitanya.mgit@gmail.com> wrote:
> On Tue, Oct 4, 2016 at 5:09 PM, Gucea Doru <gucea.doru@gmail.com> wrote:
>> On Sat, Oct 1, 2016 at 2:52 PM, Arend van Spriel
>>> <arend.vanspriel@broadcom.com> wrote:
>>>>
>>>>
>>>> On 29-09-16 13:32, Gucea Doru wrote:
>>>>> On Tue, Sep 27, 2016 at 12:03 PM, Gucea Doru <gucea.doru@gmail.com> wrote:
>>>>>> What is the decision triggering the exit from the PS mode immediately
>>>>>> after the ping request? I am asking this because 802.11 PS legacy
>>>>>> specifies that the client should wait for a beacon with TIM set in
>>>>>> order to wake up: in my case, there is no beacon between the ping
>>>>>> request message and the Null frame that announces the exit from the PS
>>>>>> mode.
>>>>>
>>>>>
>>>>> Any help would be highly appreciated :)
>>>>
>>>> Actually though I already sent you are reply, but alas here it is.
>>>>
>>>> bcmdhd is our aosp driver. I am maintaining the upstream brcm80211
>>>> drivers. Regardless your question is more for firmware running on the
>>>> device. So like the same behavior would be observed when using brcmfmac
>>>> with same firmware.
>>>>
>>>>> IEEE Std 802.11-2012, section 10.2.1.8 specifies that "when the STA
>>>>> detects that the bit corresponding to its AID is 1 i the TIM, the STA
>>>>> shall issue a PS Poll". In my capture there are cases when the STA
>>>>> exits the PS mode without waiting for a beacon.
>>>>
>>>> It is a bit tricky, but the standard does not explicitly say the STA
>>>> should be in power-save at any other time. So it is difficult to say
>>>> what event occurred on the STA side to exit PS mode. Also STA means
>>>> P2P-Client as you say. That means that you have multiple interfaces:
>>>> regular STA and P2P-Client. So is the STA connected to some other AP or
>>>> just not connected. wpa_supplicant will do intermittent scan or initiate
>>>> scheduled scan by which firmware will scan at a certain interval. That
>>>> is just some things I can come up with and I am sure there are more.
>>
>> I agree that there may be some events belonging to the regular STA
>> interface that could trigger the Null Frame (which includes the exit
>> from PS Mode). However, I would expect to see some management frames
>> in the air before/after the Null Packet (e.g.: a Probe request in case
>> of a scheduled scan). But in my case the trigger for the Null frame
>> seems to be the ping request packet, the scenario is the same every
>> time: ping request -> Block ACK -> Null Frame (Wireshark trace
>> confirms this behavior).
>>
>> I thought that you had a power save optimization algorithm that keeps
>> the card on a few milliseconds just to see if we can have a fast reply
>> from the peer. Does this ring a bell? :)
>>
>> On Sat, Oct 1, 2016 at 3:02 PM, Krishna Chaitanya
>> <chaitanya.mgit@gmail.com> wrote:
>>> Keeping the STA aside, as far as AP is concerned the STA is still in PS,
>>> so it should set the TIM/DTIM bit to 1 before sending out data to the STA.
>>
>> Not necessarily, see section 10.2.1.6/l from IEEE Std 802.11-2012:
>> "When an AP is informed that a STA has changed to the Active mode,
>> then the AP shall send buffered BUs (if any exist) to the STA without
>> waiting for a PS Poll...."
> Yes, but in this case the STA did not inform AP (as per sniffer captures)?
> so AP should set TIM/DTIM...
The STA _did_ inform the AP.
If you take a look at the packet traces you'll see that the STA sends
a NULL frame saying that it will exit Power Save Mode. According to
the specification the AP can send the buffered frames.
^ permalink raw reply
* Re: BCM43602 firmware reports multiple BRCMF_E_DEAUTH
From: Rafał Miłecki @ 2016-10-04 18:15 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org, brcm80211 development
In-Reply-To: <CACna6rzS4nDZ+H5kU71WwTTNLp5uZStpQHv4LLmWBDSdf5jpyw@mail.gmail.com>
On 09/28/2015 11:00 AM, Rafał Miłecki wrote:
> I'm using recent brcmfmac and brcmfmac43602-pcie.ap.bin that currently
> sits in linux-firmware.git.
>
> In OpenWrt we have hostapd with a feature of banning STAs. It works in
> a quite simple way. Whenever hostapd gets NL80211_CMD_NEW_STATION for
> STA that is banned it sends NL80211_CMD_DEL_STATION.
>
> The problem is that in such case BCM43602 firmware happens to randomly
> send more than 1 BRCMF_E_DEAUTH event. It seems it can send random
> amount between 1 and 3. Looks a bit like some kind of race. It's
> nothing really critical, just makes hostapd log a bit confusing.
>
> Could someone at Broadcom look at firmware source to see if you can
> fix this, please?
Hey, I didn't get any reply on this for a year. I just saw similar problem with
BCM4366. Below you will find a nice log with my extra comments.
Could take a look at this issue this time, please?
I think it may be another problem related to the A-MPDU thing (bug?) I reported
in "AMPDU stalls with brcmfmac4366b-pcie.bin triggering WARNINGs" e-mail thread.
# My smartphone remains in the same place (1 m from the AP) but there is some
# connection/A-MPDU problem.
Tue Oct 4 17:22:22 2016 kern.debug kernel: [ 247.509120] brcmfmac: CONSOLE: 026970.308 ampdu_dbg: wl0.0 scb:0035ee78 tid:0
Tue Oct 4 17:22:22 2016 kern.debug kernel: [ 247.509250] brcmfmac: CONSOLE: 026970.308 ampdu_dbg: wl0.0 dead_cnt 2 tx_in_transit 1 psm_mux 0xfff0 aqmqmap 0x0x101 aqmfifo_status 0x0x4000 fifordy 0x0 cpbusy 0x0
Tue Oct 4 17:22:22 2016 kern.debug kernel: [ 247.509304] brcmfmac: CONSOLE: 026970.308 ampdu_dbg: ifsstat 0xaf nav_stat 0x0 txop 110486
Tue Oct 4 17:22:22 2016 kern.debug kernel: [ 247.509346] brcmfmac: CONSOLE: 026970.308 ampdu_dbg: pktpend: 0 0 0 0 0 ap 1
Tue Oct 4 17:22:22 2016 kern.debug kernel: [ 247.509411] brcmfmac: CONSOLE: 026970.308 ampdu_dbg: txall 4 txbcn 0 txrts 0 rxcts 0 rsptmout 0 rxstrt 0
Tue Oct 4 17:22:22 2016 kern.debug kernel: [ 247.509477] brcmfmac: CONSOLE: 026970.308 ampdu_dbg: cwcur0-3 f f 7 3 bslots cur/0-3 4 0 0 0 0 ifs_boff 0
Tue Oct 4 17:22:22 2016 kern.debug kernel: [ 247.509527] brcmfmac: CONSOLE: 026970.308 ampdu_dbg: again1 ifsstat 0xaf nav_stat 0x0
Tue Oct 4 17:22:22 2016 kern.debug kernel: [ 247.509576] brcmfmac: CONSOLE: 026970.308 ampdu_dbg: again2 ifsstat 0xaf nav_stat 0x0
Tue Oct 4 17:22:22 2016 kern.debug kernel: [ 247.509665] brcmfmac: CONSOLE: 026970.308 wl0: wlc_ampdu_watchdog: cleaning up ini tid 0 due to no progress for 2 secs tx_in_transit 1
Tue Oct 4 17:22:22 2016 kern.debug kernel: [ 247.509726] brcmfmac: CONSOLE: 026970.308 wl0: wlc_ampdu_tx_send_delba: tid 0 initiator 1 reason 39
Tue Oct 4 17:22:41 2016 kern.debug kernel: [ 266.456860] brcmfmac: CONSOLE: 026990.068 wl0.0: wlc_send_bar: seq 0x7c tid 0
Tue Oct 4 17:22:43 2016 kern.debug kernel: [ 268.178234] brcmfmac: CONSOLE: 026991.783 pktid is NULL
# After recovering from A-MPDU thing firmware sends BRCMF_E_DEAUTH and
# BRCMF_E_DISASSOC_IND events.
# My smartphone never receives deauth/disassoc and it believes it's still
# connected to the AP.
Tue Oct 4 17:23:24 2016 kern.debug kernel: [ 309.275305] brcmfmac: brcmf_notify_connect_status_ap event 5, reason 4
Tue Oct 4 17:23:24 2016 daemon.info hostapd: wlan1: STA 78:d6:f0:9b:ba:bc IEEE 802.11: disassociated
Tue Oct 4 17:23:24 2016 kern.debug kernel: [ 309.275354] brcmfmac: brcmf_notify_connect_status_ap event 12, reason 8
Tue Oct 4 17:23:24 2016 daemon.info hostapd: wlan1: STA 78:d6:f0:9b:ba:bc IEEE 802.11: disassociated
Tue Oct 4 17:23:24 2016 kern.debug kernel: [ 309.275865] brcmfmac: brcmf_cfg80211_del_key key index (0)
Tue Oct 4 17:23:24 2016 kern.debug kernel: [ 309.276177] brcmfmac: brcmf_cfg80211_del_key key index (0)
Tue Oct 4 17:23:24 2016 kern.debug kernel: [ 309.276188] brcmfmac: brcmf_cfg80211_del_key Ignore clearing of (never configured) key
# My smartphone starts sending packets. It seems brcmfmac refuses them due to
# STA not being connected and for each packet it reports BRCMF_E_DEAUTH to the
# driver.
Tue Oct 4 17:23:58 2016 kern.debug kernel: [ 343.000406] brcmfmac: brcmf_notify_connect_status_ap event 5, reason 7
Tue Oct 4 17:23:58 2016 daemon.info hostapd: wlan1: STA 78:d6:f0:9b:ba:bc IEEE 802.11: disassociated
Tue Oct 4 17:23:58 2016 kern.debug kernel: [ 343.001227] brcmfmac: brcmf_notify_connect_status_ap event 5, reason 7
Tue Oct 4 17:23:58 2016 daemon.info hostapd: wlan1: STA 78:d6:f0:9b:ba:bc IEEE 802.11: disassociated
Tue Oct 4 17:23:58 2016 kern.debug kernel: [ 343.001894] brcmfmac: brcmf_notify_connect_status_ap event 5, reason 7
Tue Oct 4 17:23:58 2016 daemon.info hostapd: wlan1: STA 78:d6:f0:9b:ba:bc IEEE 802.11: disassociated
Tue Oct 4 17:23:58 2016 kern.debug kernel: [ 343.002594] brcmfmac: brcmf_notify_connect_status_ap event 5, reason 7
Tue Oct 4 17:23:58 2016 daemon.info hostapd: wlan1: STA 78:d6:f0:9b:ba:bc IEEE 802.11: disassociated
Tue Oct 4 17:23:58 2016 kern.debug kernel: [ 343.003741] brcmfmac: brcmf_notify_connect_status_ap event 5, reason 7
Tue Oct 4 17:23:58 2016 daemon.info hostapd: wlan1: STA 78:d6:f0:9b:ba:bc IEEE 802.11: disassociated
Tue Oct 4 17:23:58 2016 kern.debug kernel: [ 343.004096] brcmfmac: brcmf_notify_connect_status_ap event 5, reason 7
Tue Oct 4 17:23:58 2016 daemon.info hostapd: wlan1: STA 78:d6:f0:9b:ba:bc IEEE 802.11: disassociated
Tue Oct 4 17:23:58 2016 kern.debug kernel: [ 343.004490] brcmfmac: brcmf_notify_connect_status_ap event 5, reason 7
Tue Oct 4 17:23:58 2016 daemon.info hostapd: wlan1: STA 78:d6:f0:9b:ba:bc IEEE 802.11: disassociated
Tue Oct 4 17:23:58 2016 kern.debug kernel: [ 343.004936] brcmfmac: brcmf_notify_connect_status_ap event 5, reason 7
Tue Oct 4 17:23:58 2016 daemon.info hostapd: wlan1: STA 78:d6:f0:9b:ba:bc IEEE 802.11: disassociated
As you can see in above example I got more than just 3 BRCMF_E_DEAUTH reported
originally for BCM43602 firmware. But this isn't the worst case. In one extreme
situation I got 9714 of these events!
Mon Oct 3 09:10:04 2016 kern.err kernel: [227426.890053] brcmfmac: brcmf_netdev_wait_pend8021x: Timed out waiting for no pending 802.1x packets
Mon Oct 3 09:10:04 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:06 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:06 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:06 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:06 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:06 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
(another 472 identical lines were here)
Mon Oct 3 09:10:07 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:07 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:07 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:07 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:07 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
(another 623 identical lines were here)
Mon Oct 3 09:10:08 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:08 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:08 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:08 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:08 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
(another 443 identical lines were here)
Mon Oct 3 09:10:09 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:09 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:09 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:09 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:09 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
(another 434 identical lines were here)
Mon Oct 3 09:10:10 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:10 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:10 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:10 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:10 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
(another 577 identical lines were here)
Mon Oct 3 09:10:11 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:11 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:11 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:11 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:11 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
(another 562 identical lines were here)
Mon Oct 3 09:10:12 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:12 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:12 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:12 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:12 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
(another 451 identical lines were here)
Mon Oct 3 09:10:13 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:13 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:13 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:13 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:13 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
(another 557 identical lines were here)
Mon Oct 3 09:10:14 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:14 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:14 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:14 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:14 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
(another 426 identical lines were here)
Mon Oct 3 09:10:15 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:15 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:15 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:15 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:15 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
(another 340 identical lines were here)
Mon Oct 3 09:10:16 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:16 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:16 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:16 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:16 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
(another 115 identical lines were here)
Mon Oct 3 09:10:17 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:17 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:17 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:17 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:17 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
(another 115 identical lines were here)
Mon Oct 3 09:10:18 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:18 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:18 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:18 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:18 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
(another 150 identical lines were here)
Mon Oct 3 09:10:19 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:19 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:19 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:19 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:19 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
(another 668 identical lines were here)
Mon Oct 3 09:10:20 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:20 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:20 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:20 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:20 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
(another 602 identical lines were here)
Mon Oct 3 09:10:21 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:21 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:21 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:21 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:21 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
(another 482 identical lines were here)
Mon Oct 3 09:10:22 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:22 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:22 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:22 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:22 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
(another 419 identical lines were here)
Mon Oct 3 09:10:23 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:23 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:23 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:23 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:23 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
(another 462 identical lines were here)
Mon Oct 3 09:10:24 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:24 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:24 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:24 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:24 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
(another 584 identical lines were here)
Mon Oct 3 09:10:25 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:25 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:25 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:25 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:25 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
(another 417 identical lines were here)
Mon Oct 3 09:10:26 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:26 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:26 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:26 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:26 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
(another 485 identical lines were here)
Mon Oct 3 09:10:27 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:27 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:27 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:27 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:27 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
(another 200 identical lines were here)
Mon Oct 3 09:10:28 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:28 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:28 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:28 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
Mon Oct 3 09:10:28 2016 daemon.info hostapd: wlan1: STA 3c:15:c2:dd:ce:de IEEE 802.11: disassociated
(another 14 identical lines were here)
^ permalink raw reply
* Re: [PATCH] ath9k: Move generic entries below specific ones in ath_pci_id_table.
From: Vittorio Gambaletta (VittGam) @ 2016-10-04 18:14 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless, ath9k-devel, ath9k-devel, stable
In-Reply-To: <87k2dop15n.fsf@kamboji.qca.qualcomm.com>
Hello,
On 04/10/2016 17:46:44 CEST, Kalle Valo wrote:
> "Vittorio Gambaletta (VittGam)" <linux-wireless@vittgam.net> writes:
>
>> If generic entries are positioned above specific ones, then the
>> former will be matched first and used instead of the latter.
>>
>> Cc: <linux-wireless@vger.kernel.org>
>> Cc: <ath9k-devel@qca.qualcomm.com>
>> Cc: <ath9k-devel@lists.ath9k.org>
>> Cc: <stable@vger.kernel.org>
>> Signed-off-by: Vittorio Gambaletta <linuxbugs@vittgam.net>
>
> Why? What kind of bug you are fixing? You are not really describing the
> problem you are trying fix.
The active_high LED of my Wistron DNMA-92 is still being recognized as
active_low on 4.7.6 mainline.
When I was preparing my former patch to fix that, I initially added the
PCI_DEVICE_SUB section for 0x0029/0x2096 above the PCI_VDEVICE section
for 0x0029; but then I moved the former below the latter after seeing
how 0x002A sections were sorted in the file.
I must have somehow messed up with testing, because I tested the final
version of that patch before sending it, and it was apparently working;
but now it is not working on 4.7.6 mainline.
With this patch, 0x0029/0x2096 has finally got active_high LED on 4.7.6.
So, after seeing that the rest of the file is sorted this way (generic
section after the specific ones), I concluded that the 0x002A sorting
was wrong in the first place, and so is 0x0029. Then I sent this patch
to fix this.
> And your email headers look weird:
>
> To: <kvalo@codeaurora.org>
> Cc: <linux-wireless@vger.kernel.org>
> Cc: <ath9k-devel@qca.qualcomm.com>
> Cc: <ath9k-devel@venema.h4ckr.net>
> Cc: <stable@vger.kernel.org>
> Date: Mon, 3 Oct 2016 12:00:56 +0200
>
> What software are you using to send this? Only one CC header is valid
> according to the spec (thanks to Luca for checking) even though mailers
> seem to handle multiple CC headers. But for example my patchwork script
> fails with this and uses only the first CC header.
Sorry about this, I used a custom mailer to send the patch since I was
having problems with git-send-email...
^ permalink raw reply
* Re: [PATCH v8] Add new mac80211 driver mwlwifi.
From: Kalle Valo @ 2016-10-04 17:36 UTC (permalink / raw)
To: David Lin
Cc: Johannes Berg, linux-wireless@vger.kernel.org, Chor Teck Law,
Pete Hsieh
In-Reply-To: <fdef0b5d3b744af8be48680e56ae9fb1@SC-EXCH02.marvell.com>
David Lin <dlin@marvell.com> writes:
> PATCH v8 changes since PATCH v7:
>
> - Used scnprintf() to replace sprintf() for debugfs output messages to avoid
> overwriting buffer boundary.
> - Used mutex to replace spinlock for the protection of firmware command.
> - Used NL80211_BAND_XXXX instead of IEEE80211_BAND_XXXX (in order to work with
> updated mac80211).
> - Used usleep_range() instead of mdelay().
> - Modified the code to work with new mac80211 API ampdu_action() and get peer
> AMSDU information from parameters of this function instead of peeking ADDBA
> related packets.
> - Removed BA stream if traffic is not heavy.
> - Removed version information.
> - Added DFS, WPS, WDS and thermal function.
> - Changed length of mac vht_mpdu from 7991 to 3895.
I did a diff against v7 and you are not really making this easy:
drivers/net/wireless/marvell/mwlwifi/Makefile | 3 +-
drivers/net/wireless/marvell/mwlwifi/debugfs.c | 591 ++++++++++++++----
drivers/net/wireless/marvell/mwlwifi/debugfs.h | 8 +-
drivers/net/wireless/marvell/mwlwifi/dev.h | 85 ++-
drivers/net/wireless/marvell/mwlwifi/fwcmd.c | 750 ++++++++++++++++-------
drivers/net/wireless/marvell/mwlwifi/fwcmd.h | 24 +-
drivers/net/wireless/marvell/mwlwifi/fwdl.c | 43 +-
drivers/net/wireless/marvell/mwlwifi/fwdl.h | 8 +-
drivers/net/wireless/marvell/mwlwifi/hostcmd.h | 109 +++-
drivers/net/wireless/marvell/mwlwifi/isr.c | 90 ++-
drivers/net/wireless/marvell/mwlwifi/isr.h | 9 +-
drivers/net/wireless/marvell/mwlwifi/mac80211.c | 74 ++-
drivers/net/wireless/marvell/mwlwifi/main.c | 270 ++++----
drivers/net/wireless/marvell/mwlwifi/rx.c | 149 +----
drivers/net/wireless/marvell/mwlwifi/rx.h | 8 +-
drivers/net/wireless/marvell/mwlwifi/sysadpt.h | 18 +-
drivers/net/wireless/marvell/mwlwifi/thermal.c | 182 ++++++
drivers/net/wireless/marvell/mwlwifi/thermal.h | 40 ++
drivers/net/wireless/marvell/mwlwifi/tx.c | 145 +++--
drivers/net/wireless/marvell/mwlwifi/tx.h | 9 +-
20 files changed, 1799 insertions(+), 816 deletions(-)
You do understand that making so drastic changes during the driver
review is very counterproductive and demotivating for the reviewers?
Before I start looking this again I want to have an assurance that you
have frozen the driver and are not adding new features. I do not want
waste my time again just going circles.
You can continue adding new features but do that as separate patches and
submit them after the driver is applied to wireless-drivers-next.
--
Kalle Valo
^ permalink raw reply
* [PATCH v2 2/2] mwifiex: check hw_status in suspend and resume handlers
From: Amitkumar Karwar @ 2016-10-04 17:08 UTC (permalink / raw)
To: linux-wireless
Cc: Cathy Luo, Nishant Sarmukadam, rajatja, briannorris, Xinming Hu,
Amitkumar Karwar
In-Reply-To: <1475600905-2997-1-git-send-email-akarwar@marvell.com>
From: Xinming Hu <huxm@marvell.com>
We have observed a kernel crash when system immediately suspends
after booting. There is a race between suspend and driver
initialization paths.
This patch adds hw_status checks to fix the problem
Signed-off-by: Xinming Hu <huxm@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
v2: Return failure in suspend/resume handler in this scenario.
---
drivers/net/wireless/marvell/mwifiex/pcie.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c
index ba9e068..fa6bf85 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -122,9 +122,10 @@ static int mwifiex_pcie_suspend(struct device *dev)
if (pdev) {
card = pci_get_drvdata(pdev);
- if (!card || !card->adapter) {
+ if (!card || !card->adapter ||
+ card->adapter->hw_status != MWIFIEX_HW_STATUS_READY) {
pr_err("Card or adapter structure is not valid\n");
- return 0;
+ return -EBUSY;
}
} else {
pr_err("PCIE device is not specified\n");
@@ -166,9 +167,10 @@ static int mwifiex_pcie_resume(struct device *dev)
if (pdev) {
card = pci_get_drvdata(pdev);
- if (!card || !card->adapter) {
+ if (!card || !card->adapter ||
+ card->adapter->hw_status != MWIFIEX_HW_STATUS_READY) {
pr_err("Card or adapter structure is not valid\n");
- return 0;
+ return -EBUSY;
}
} else {
pr_err("PCIE device is not specified\n");
--
1.9.1
^ permalink raw reply related
* [PATCH v2 1/2] mwifiex: reset card->adapter during device unregister
From: Amitkumar Karwar @ 2016-10-04 17:08 UTC (permalink / raw)
To: linux-wireless
Cc: Cathy Luo, Nishant Sarmukadam, rajatja, briannorris, Xinming Hu,
Amitkumar Karwar
From: Xinming Hu <huxm@marvell.com>
card->adapter gets initialized during device registration.
As it's not cleared, we may end up accessing invalid memory
in some corner cases. This patch fixes the problem.
Signed-off-by: Xinming Hu <huxm@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
v2: Same as v1
---
drivers/net/wireless/marvell/mwifiex/pcie.c | 1 +
drivers/net/wireless/marvell/mwifiex/sdio.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c b/drivers/net/wireless/marvell/mwifiex/pcie.c
index f1eeb73..ba9e068 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -3042,6 +3042,7 @@ static void mwifiex_unregister_dev(struct mwifiex_adapter *adapter)
pci_disable_msi(pdev);
}
}
+ card->adapter = NULL;
}
/* This function initializes the PCI-E host memory space, WCB rings, etc.
diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c b/drivers/net/wireless/marvell/mwifiex/sdio.c
index 8718950..4cad1c2 100644
--- a/drivers/net/wireless/marvell/mwifiex/sdio.c
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
@@ -2066,6 +2066,7 @@ mwifiex_unregister_dev(struct mwifiex_adapter *adapter)
struct sdio_mmc_card *card = adapter->card;
if (adapter->card) {
+ card->adapter = NULL;
sdio_claim_host(card->func);
sdio_disable_func(card->func);
sdio_release_host(card->func);
--
1.9.1
^ permalink raw reply related
* Re: [v3,3/3] mt76: add driver code for MT76x2e
From: Kalle Valo @ 2016-10-04 16:45 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless
In-Reply-To: <20160905095128.80560-4-nbd@nbd.name>
Felix Fietkau <nbd@nbd.name> wrote:
> From: Felix Fietkau <nbd@openwrt.org>
>
> This is a 2x2 PCIe 802.11ac chipset by MediaTek
>
> Signed-off-by: Felix Fietkau <nbd@nbd.name>
I already asked this in v2, but what about firmware images? Will they be
available from linux-firmware.git?
--
https://patchwork.kernel.org/patch/9313311/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [v3,3/3] mt76: add driver code for MT76x2e
From: Kalle Valo @ 2016-10-04 16:34 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless
In-Reply-To: <20160905095128.80560-4-nbd@nbd.name>
Felix Fietkau <nbd@nbd.name> wrote:
> From: Felix Fietkau <nbd@openwrt.org>
>
> This is a 2x2 PCIe 802.11ac chipset by MediaTek
>
> Signed-off-by: Felix Fietkau <nbd@nbd.name>
A summary of what feature work would be nice to have. Also if there's something
notable which is not working it's good also to mention that.
I don't know why I didn't see this earlier but this fails to build for me:
ERROR: "mtd_read" [drivers/net/wireless/mediatek/mt76/mt76.ko] undefined!
ERROR: "put_mtd_device" [drivers/net/wireless/mediatek/mt76/mt76.ko] undefined!
ERROR: "get_mtd_device_nm" [drivers/net/wireless/mediatek/mt76/mt76.ko] undefined!
Dependency to mtd missing?
--
https://patchwork.kernel.org/patch/9313311/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] cfg80211: cap 20MHz VHT bitrate at MCS 8
From: Ben Greear @ 2016-10-04 16:31 UTC (permalink / raw)
To: Johannes Berg, Pedersen, Thomas; +Cc: linux-wireless
In-Reply-To: <1475573532.5324.47.camel@sipsolutions.net>
On 10/04/2016 02:32 AM, Johannes Berg wrote:
> Sorry - needed some time to think through this thread again.
>
>> I think it is a moot point as far as this change goes: Regardless of
>> whether the NIC should or not, it _does_. So, mis-reporting it up
>> the stack only hides the issue and does not even give the user a clue
>> that on-the-air encoding may be slightly off-spec.
>
> Arguably, reporting something that *seems* sane, like this patch does,
> will do more to hide it than reporting 0 which is clearly bogus, no?
>
> I realize you were replying to whether or not the *driver* should
> "misreport" it, but the same argument applies the other way here, imho.
If the firmware/NIC is putting it on air at a particular encoding, then
I think the stack should report it exactly as it is on air if possible.
Returning zero is not much of a clue to the user. Adding a WARN_ON_ONCE()
might be more useful, but no one can fix this by modifying the driver or stack, so the warning
will hit, confuse people, and then still never get fixed since it is a firmware
issue.
And, since someone added specific code to the firmware to use this rate
in certain cases, then maybe it is actually a good thing to do.
>> If the on-air encoding is an issue, then we need to hack the firmware
>> to disable this 'feature', but that is a completely separate issue.
>
> I guess it trusts rate control enough to try, and if it cannot be
> received by a spec-abiding receiver, it won't use it due to the
> failures ... not such a big deal I guess, even though it's odd.
>
> Does /anyone/ know why the spec disallowed it? Perhaps those "system"
> people you refer to?
I didn't talk to any system people, but maybe Thomas did. I can confirm
that the firmware appears to do this on purpose and not just to be buggy
on accident though.
>> Once this patch goes in, someone might consider properly reporting
>> CCK rx rates for 5Ghz band too: ath10k can do this 'feature' as
>> well, at least in some firmware. Probably can reproduce by sending
>> off-channel mgt frames on 5Ghz when associated on 2.4, or something
>> similar to this. I was using ath9k as sniffer when I found this long
>> ago, so at least ath9k needs the change....
>
> I don't see how this is related? It's not advertising those rates, so
> it probably also can't use/report them as far as mac80211 and the rest
> of the stack are concerned.
I can guarantee you that at least some ath10k firmware has a bug that will
send CCK encodings on 5Ghz. This is a bug in the firmware, but the packets
will go on air, and they can be decoded by ath9k (and ath10k)
and passed up the stack.
Stock ath9k driver will ignore them (or maybe lie and say rate is 6Mbps, I cannot
recall at this point) currently because it thinks the rate is
bad (since it sort of is). But, if you relax ath9k, then it can actually
sniff these frames and give you a clue as to what is really wrong.
It reminded me of hiding the rate by setting it to zero, since in both cases,
overly strict decisions based on what is *supposed* to happen caused me
to have to dig closely and modify code in order to understand what is
actually happening on-air.
Basically, if the NIC can decode a frame, and checksums pass and so forth,
then it seems it should pass it up the stack. Possibly with WARN_ONCE to
give use a better clue that there is an issue.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH] cfg80211: Add HT and VHT information in start_ap
From: Malinen, Jouni @ 2016-10-04 16:15 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless@vger.kernel.org, Xu, Peng
In-Reply-To: <1475587551.5324.57.camel@sipsolutions.net>
On Tue, Oct 04, 2016 at 03:25:51PM +0200, Johannes Berg wrote:
> > ath6kl:
> > Use cfg80211_get_chandef_type(&info->chandef) !=3D NL80211_CHAN_NO_HT
> > to determine whether HT is enabled. No VHT support. HT-required case
> > not covered. No parsing of HT/VHT IEs used.
>=20
> Hmm. Wouldn't the supported rates IE still advertise the cookie for HT
> only, to make sure HT-required was done?
I'm not completely sure how the driver/firmware behaves for this. There
is a reference to info->beacon.head, but that code looks like dead code
that does nothing as far as configuring the firmware with the supported
rates elements from user space. As such, I'd expect the firmware to
build (Ext)Supp Rates element from scratch and I'd assume ath6kl does
not currently support HT-required signaling. I'm not sure whether the
current firmware would even allow such configuration.
> [snip other drivers]
By the way, I did not find any clear example that would be either using
(Extended) Supported Rates element from start_ap() as-is or parsing it
for the BSS membership selectors in any of the in-tree drivers. In other
words, the HT/VHT required configuration may not really work properly
with non-mac80211 cases.
PS.
And even if the driver were to simply copy the IEs with the BSS
membership selectors, this would only work with stations that implement
this part correctly, i.e., the AP would not necessarily have any means
for rejecting the association if a non-HT/VHT station were to try to
associate.. With mac80211-drivers, this happens in hostapd.
--=20
Jouni Malinen PGP id EFC895FA=
^ permalink raw reply
* [PATCH v2] ath10k: Cleanup calling ath10k_htt_rx_h_unchain
From: Mohammed Shafi Shajakhan @ 2016-10-04 15:49 UTC (permalink / raw)
To: ath10k; +Cc: mohammed, linux-wireless, Mohammed Shafi Shajakhan
From: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
'ath10k_htt_rx_h_unchain' needs to be called only if the return
value from 'ath10k_htt_rx_amsdu_pop' is 1('chained msdu's'), this
change makes it more explicit and avoids doing a skb_peek, fetching
rx descriptor pointer, checking rx msdu decap format for the case of
ret = 0 (unchained msdus). Found this change during code walk through,
not sure if this addresses any issue.
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
---
[v2 rebased over top of master tree]
drivers/net/wireless/ath/ath10k/htt_rx.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c
index 0b4c156..285b235 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -1463,8 +1463,7 @@ static int ath10k_unchain_msdu(struct sk_buff_head *amsdu)
}
static void ath10k_htt_rx_h_unchain(struct ath10k *ar,
- struct sk_buff_head *amsdu,
- bool chained)
+ struct sk_buff_head *amsdu)
{
struct sk_buff *first;
struct htt_rx_desc *rxd;
@@ -1475,9 +1474,6 @@ static void ath10k_htt_rx_h_unchain(struct ath10k *ar,
decap = MS(__le32_to_cpu(rxd->msdu_start.common.info1),
RX_MSDU_START_INFO1_DECAP_FORMAT);
- if (!chained)
- return;
-
/* FIXME: Current unchaining logic can only handle simple case of raw
* msdu chaining. If decapping is other than raw the chaining may be
* more complex and this isn't handled by the current code. Don't even
@@ -1555,7 +1551,11 @@ static int ath10k_htt_rx_handle_amsdu(struct ath10k_htt *htt)
num_msdus = skb_queue_len(&amsdu);
ath10k_htt_rx_h_ppdu(ar, &amsdu, rx_status, 0xffff);
- ath10k_htt_rx_h_unchain(ar, &amsdu, ret > 0);
+
+ /* only for ret = 1 indicates chained msdus */
+ if (ret > 0)
+ ath10k_htt_rx_h_unchain(ar, &amsdu);
+
ath10k_htt_rx_h_filter(ar, &amsdu, rx_status);
ath10k_htt_rx_h_mpdu(ar, &amsdu, rx_status);
ath10k_htt_rx_h_deliver(ar, &amsdu, rx_status);
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH] ath9k: Move generic entries below specific ones in ath_pci_id_table.
From: Kalle Valo @ 2016-10-04 15:46 UTC (permalink / raw)
To: Vittorio Gambaletta (VittGam)
Cc: linux-wireless, ath9k-devel, ath9k-devel, stable
In-Reply-To: <ath9k-patch-20161003@vittgam.net>
"Vittorio Gambaletta (VittGam)" <linux-wireless@vittgam.net> writes:
> If generic entries are positioned above specific ones, then the
> former will be matched first and used instead of the latter.
>
> Cc: <linux-wireless@vger.kernel.org>
> Cc: <ath9k-devel@qca.qualcomm.com>
> Cc: <ath9k-devel@lists.ath9k.org>
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Vittorio Gambaletta <linuxbugs@vittgam.net>
Why? What kind of bug you are fixing? You are not really describing the
problem you are trying fix.
And your email headers look weird:
To: <kvalo@codeaurora.org>
Cc: <linux-wireless@vger.kernel.org>
Cc: <ath9k-devel@qca.qualcomm.com>
Cc: <ath9k-devel@venema.h4ckr.net>
Cc: <stable@vger.kernel.org>
Date: Mon, 3 Oct 2016 12:00:56 +0200
What software are you using to send this? Only one CC header is valid
according to the spec (thanks to Luca for checking) even though mailers
seem to handle multiple CC headers. But for example my patchwork script
fails with this and uses only the first CC header.
--
Kalle Valo
^ permalink raw reply
* Re: ath10k: Cleanup calling ath10k_htt_rx_h_unchain
From: Mohammed Shafi Shajakhan @ 2016-10-04 15:39 UTC (permalink / raw)
To: Kalle Valo; +Cc: Mohammed Shafi Shajakhan, ath10k, linux-wireless
In-Reply-To: <2cb38dba80294e6da1005ac0927d01eb@euamsexm01a.eu.qualcomm.com>
On Tue, Oct 04, 2016 at 05:30:17PM +0200, Kalle Valo wrote:
> Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> wrote:
> > From: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
> >
> > 'ath10k_htt_rx_h_unchain' is need to be called only if the return
> > value from 'ath10k_htt_rx_amsdu_pop' is 1('chained msdu's'), this
> > change makes it more explicit and avoids doing a skb_peek, fetching
> > rx descriptor pointer, checking rx msdu decap format for the case of
> > ret = 0 (unchained msdus). Found this change during code walk through,
> > not sure if this addresses any issue.
> >
> > Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
>
> Failed to apply to pending branch
>
> error: patch failed: drivers/net/wireless/ath/ath10k/htt_rx.c:1550
> error: drivers/net/wireless/ath/ath10k/htt_rx.c: patch does not apply
> stg import: Diff does not apply cleanly
[shafi] thanks, will rebase/fix this and send a v2
>
> Patch set to Changes Requested.
>
> --
> https://patchwork.kernel.org/patch/9351833/
>
> Documentation about submitting wireless patches and checking status
> from patchwork:
>
> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
>
^ permalink raw reply
* Re: [2/4] ath10k: implement offset_tsf ieee80211_op
From: Kalle Valo @ 2016-10-04 15:34 UTC (permalink / raw)
To: Pedersen, Thomas; +Cc: ath10k, Thomas Pedersen, linux-wireless
In-Reply-To: <20160928235631.9197-3-twp@qca.qualcomm.com>
"Pedersen, Thomas" <twp@qca.qualcomm.com> wrote:
> Current set_tsf is implemented in terms of TSF_INCREMENT
> only. Instead support new WMI command TSF_DECREMENT and
> export these through offset_tsf. Advantage is we get
> more accurate TSF adjustments, and don't calculate wrong
> offset in case absolute TSF was calculated from rx_mactime
> (actual TSF).
>
> The new WMI command is available in firmware
> 10.4-3.2.1-00033 for QCA4019 chips. Old drivers on new
> firmware or vice versa shouldn't be a problem since
> get/set tsf logic was already broken.
>
> Signed-off-by: Thomas Pedersen <twp@qca.qualcomm.com>
Depends on:
3a53731df7e2 mac80211: mesh: decrease max drift
354d381baf11 mac80211: add offset_tsf driver op and use it for mesh
2 patches set to Awaiting Upstream.
9355377 [2/4] ath10k: implement offset_tsf ieee80211_op
9355375 [3/4] ath10k: remove set/get_tsf ieee80211_ops
--
https://patchwork.kernel.org/patch/9355377/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: ath10k: Cleanup calling ath10k_htt_rx_h_unchain
From: Kalle Valo @ 2016-10-04 15:30 UTC (permalink / raw)
To: Mohammed Shafi Shajakhan
Cc: ath10k, mohammed, linux-wireless, Mohammed Shafi Shajakhan
In-Reply-To: <1474981314-15987-1-git-send-email-mohammed@qca.qualcomm.com>
Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> wrote:
> From: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
>
> 'ath10k_htt_rx_h_unchain' is need to be called only if the return
> value from 'ath10k_htt_rx_amsdu_pop' is 1('chained msdu's'), this
> change makes it more explicit and avoids doing a skb_peek, fetching
> rx descriptor pointer, checking rx msdu decap format for the case of
> ret = 0 (unchained msdus). Found this change during code walk through,
> not sure if this addresses any issue.
>
> Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Failed to apply to pending branch
error: patch failed: drivers/net/wireless/ath/ath10k/htt_rx.c:1550
error: drivers/net/wireless/ath/ath10k/htt_rx.c: patch does not apply
stg import: Diff does not apply cleanly
Patch set to Changes Requested.
--
https://patchwork.kernel.org/patch/9351833/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [1/2] ath: export alpha2 helper
From: Kalle Valo @ 2016-10-04 15:02 UTC (permalink / raw)
To: Bartosz Markowski
Cc: ath10k, linux-wireless, Michal Kazior, Bartosz Markowski
In-Reply-To: <1470140454-3899-2-git-send-email-bartosz.markowski@tieto.com>
Bartosz Markowski <bartosz.markowski@tieto.com> wrote:
> From: Michal Kazior <michal.kazior@tieto.com>
>
> This will be helpful for drivers that can acquire
> alpha2 regulatory codes.
>
> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
> Signed-off-by: Bartosz Markowski <bartosz.markowski@tieto.com>
2 patches applied to ath-next branch of ath.git, thanks.
d291d8e0592a ath: export alpha2 helper
209b2a68de76 ath10k: add platform regulatory domain support
--
https://patchwork.kernel.org/patch/9256535/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: ath10k: add cc_wraparound type for QCA9888 and QCA9884
From: Kalle Valo @ 2016-10-04 14:58 UTC (permalink / raw)
To: akolli; +Cc: ath10k, Anilkumar Kolli, akolli, linux-wireless
In-Reply-To: <1474026327-7065-1-git-send-email-akolli@qti.qualcomm.com>
akolli@qti.qualcomm.com wrote:
> From: Anilkumar Kolli <akolli@qti.qualcomm.com>
>
> During offchannel scan, iw survey dump shows wrong values.
> Fix this by assigning cycle counter wranarround type for
> QCA9888 and QCA9884, they share same config with QCA4019.
>
> Signed-off-by: Anilkumar Kolli <akolli@qti.qualcomm.com>
Patch applied to ath-next branch of ath.git, thanks.
bafe492610d5 ath10k: add cc_wraparound type for QCA9888 and QCA9884
--
https://patchwork.kernel.org/patch/9335581/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: ath10k: Provide provision to get Transmit Power Control stats for 10.4
From: Kalle Valo @ 2016-10-04 14:52 UTC (permalink / raw)
To: c_mkenna; +Cc: ath10k, linux-wireless, mkenna, Maharaja Kennadyrajan
In-Reply-To: <1473949819-29154-1-git-send-email-c_mkenna@qti.qualcomm.com>
c_mkenna@qti.qualcomm.com wrote:
> From: Maharaja Kennadyrajan <c_mkenna@qti.qualcomm.com>
>
> This patch helps to get the TPC stats for 10.4 fw variants.
>
> Signed-off-by: Maharaja Kennadyrajan <c_mkenna@qti.qualcomm.com>
Patch applied to ath-next branch of ath.git, thanks.
ac86aa5755db ath10k: provide provision to get Transmit Power Control stats for 10.4
--
https://patchwork.kernel.org/patch/9333777/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH RESEND v3] mwifiex: parse device tree node for PCIe
From: Rob Herring @ 2016-10-04 13:34 UTC (permalink / raw)
To: Amitkumar Karwar; +Cc: linux-wireless, devicetree, rajatja, Xinming Hu
In-Reply-To: <1475167183-18376-1-git-send-email-akarwar@marvell.com>
On Thu, Sep 29, 2016 at 10:09:43PM +0530, Amitkumar Karwar wrote:
> From: Xinming Hu <huxm@marvell.com>
>
> This patch derives device tree node from pcie bus layer framework.
> Device tree bindings file has been renamed(marvell-sd8xxx.txt ->
> marvell-8xxx.txt) to accomodate PCIe changes.
>
> Signed-off-by: Xinming Hu <huxm@marvell.com>
> Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
> ---
> v2: Included vendor and product IDs in compatible strings for PCIe
> chipsets(Rob Herring)
> v3: Patch is created using -M option so that it will only include diff of
> original and renamed files(Rob Herring)
> Resend v3: Resending the patch because I missed to include device tree mailing
> while sending v3.
> ---
> .../{marvell-sd8xxx.txt => marvell-8xxx.txt} | 8 +++++---
> drivers/net/wireless/marvell/mwifiex/pcie.c | 20 ++++++++++++++++++++
> drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 3 ++-
> 3 files changed, 27 insertions(+), 4 deletions(-)
> rename Documentation/devicetree/bindings/net/wireless/{marvell-sd8xxx.txt => marvell-8xxx.txt} (91%)
>
> diff --git a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
> similarity index 91%
> rename from Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
> rename to Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
> index c421aba..dfe5f8e 100644
> --- a/Documentation/devicetree/bindings/net/wireless/marvell-sd8xxx.txt
> +++ b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
> @@ -1,8 +1,8 @@
> -Marvell 8897/8997 (sd8897/sd8997) SDIO devices
> +Marvell 8897/8997 (sd8897/sd8997/pcie8997) SDIO/PCIE devices
> ------
>
> -This node provides properties for controlling the marvell sdio wireless device.
> -The node is expected to be specified as a child node to the SDIO controller that
> +This node provides properties for controlling the marvell sdio/pcie wireless device.
Capitalize SDIO/PCIe
> +The node is expected to be specified as a child node to the SDIO/PCIE controller that
> connects the device to the system.
>
> Required properties:
> @@ -10,6 +10,8 @@ Required properties:
> - compatible : should be one of the following:
> * "marvell,sd8897"
> * "marvell,sd8997"
> + * "pci11ab,2b42"
> + * "pci1b4b,2b42"
The string is pciVVVV,DDDD. Looks like you have vendor and device
swapped.
Rob
^ permalink raw reply
* [PATCH] mac80211: remove unnecessary mesh check
From: Johannes Berg @ 2016-10-04 13:32 UTC (permalink / raw)
To: linux-wireless; +Cc: Thomas Pedersen, Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
sta_info_get_bss() is equivalent to sta_info_get() in the
mesh case, since sta->sdata->bss will be NULL (it's only
set for AP/AP_VLAN interfaces.) Thus, the mesh check here
isn't actually needed - remove it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/mac80211/cfg.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index fd6541f3ade3..7d0172395589 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -357,10 +357,7 @@ static int ieee80211_add_key(struct wiphy *wiphy, struct net_device *dev,
mutex_lock(&local->sta_mtx);
if (mac_addr) {
- if (ieee80211_vif_is_mesh(&sdata->vif))
- sta = sta_info_get(sdata, mac_addr);
- else
- sta = sta_info_get_bss(sdata, mac_addr);
+ sta = sta_info_get_bss(sdata, mac_addr);
/*
* The ASSOC test makes sure the driver is ready to
* receive the key. When wpa_supplicant has roamed
--
2.8.1
^ permalink raw reply related
* Re: [PATCH] cfg80211: Add HT and VHT information in start_ap
From: Johannes Berg @ 2016-10-04 13:25 UTC (permalink / raw)
To: Malinen, Jouni; +Cc: linux-wireless@vger.kernel.org, Xu, Peng
In-Reply-To: <20161003211523.GA6585@jouni.qca.qualcomm.com>
> The main goal of this was to see if we can reduce actual driver
> implementation size and maybe even more so to prepare for 802.11ax
> changes (i.e., see what we are doing currently for configuring HT/VHT
> in a way that could be done better).
Fair enough.
> Looking at the current in-tree drivers, it looks like following
> approaches have been used:
>
> ath6kl:
> Use cfg80211_get_chandef_type(&info->chandef) != NL80211_CHAN_NO_HT
> to determine whether HT is enabled. No VHT support. HT-required case
> not covered. No parsing of HT/VHT IEs used.
Hmm. Wouldn't the supported rates IE still advertise the cookie for HT
only, to make sure HT-required was done?
[snip other drivers]
> So I guess there could be some code sharing and cleanup done with the
> existing in-tree drivers. Especially the mwifiex example looks like
> something that triggered us to look at this. I'm not sure we'd
> propose adding any new driver with the driver code itself doing
> HT/VHT IE parsing and since ath6kl did not do this either, I don't
> see us changing existing in-tree drivers to use this either.
Maybe Marvell folks would like to change something there.
> I'm not sure there would really be enough justification to add this
> specific patch due to the assumed user space update. Adding some of
> the HT/VHT element parsing in cfg80211 might benefit on or two of the
> in-tree drivers if their maintainers are interested in that.
Right, I agree. If we want to unify/combine anything, the best place to
do that would just be cfg80211 at this point. Adding both the API and
the parsing seems fairly pointless now, and evidently drivers can live
with the status quo.
> That said, without additional interest, I'm starting to lean towards
> using this as an example of what type of parameters we need to add
> for HE from the beginning and not merge this patch.
Ok. I agree that for HE we should consider this more carefully. I
haven't looked at HE AP side yet, so I don't really know what might be
needed there, but when we get to it we can discuss it.
I'll drop this patch then, and if Broadcom or you (ath6kl) want to add
more parsing to the respective drivers we can consider code sharing
with mwifiex that seems to have a more (but not fully) complete version
in there - probably would have to be rewritten for cfg80211, but still.
johannes
^ permalink raw reply
* Re: [v2] mwifiex: report wakeup for wowlan
From: Kalle Valo @ 2016-10-04 12:46 UTC (permalink / raw)
To: Rajat Jain
Cc: Amitkumar Karwar, Nishant Sarmukadam, linux-wireless, netdev,
Wei-Ning Huang, Brian Norris, Eric Caruso, Rajat Jain
In-Reply-To: <CACK8Z6Fe34xdvd5-=3dNmqKXYC=Qr9+kpG46eCV7uFArLW+yyQ@mail.gmail.com>
Rajat Jain <rajatja@google.com> writes:
> Hello Kalie,
>
> On Mon, Oct 3, 2016 at 6:04 AM, Kalle Valo <kvalo@codeaurora.org> wrote:
>> Rajat Jain <rajatja@google.com> wrote:
>>> Enable notifying wakeup source to the PM core in case of
>>> a wake on wireless LAN event.
>>>
>>> Signed-off-by: Wei-Ning Huang <wnhuang@google.com>
>>> Signed-off-by: Rajat Jain <rajatja@google.com>
>>> Tested-by: Wei-Ning Huang <wnhuang@chromium.org>
>>> Reviewed-by: Eric Caruso <ejcaruso@chromium.org>
>>> Acked-by: Amitkumar Karwar <akarwar@marvell.com>
>>
>> The commit log doesn't give any background info. Does this fix a bug or
>> why is it needed?
>
> Some of chromeos' features (called "darkresume" in chromeos
> terminology) use and track the wake up sources using the wakeup
> attributes in sysfs. Since the wireless device can wake up the host,
> hence we wanted to add it as a wakeup source to the system, and in the
> case of an actual wakeup event, trigger to the PM core that it was
> indeed caused by the device and it increments the different counters
> etc. In the absence of this patch, the feature wasn't working very
> well (as it was apparently confused about the cause of wake up).
Thanks, makes sense. Please add that to the commit and send v3.
--
Kalle Valo
^ permalink raw reply
* [PATCH 2/2] ath10k: Remove extraneous error message in tx alloc
From: Mohammed Shafi Shajakhan @ 2016-10-04 12:39 UTC (permalink / raw)
To: ath10k; +Cc: mohammed, linux-wireless, Mohammed Shafi Shajakhan
In-Reply-To: <1475584772-4091-1-git-send-email-mohammed@qca.qualcomm.com>
From: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Remove extraneous error message in 'ath10k_htt_tx_alloc_cont_frag_desc'
as the caller 'ath10k_htt_tx_alloc' already dumps a proper error
message
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
---
drivers/net/wireless/ath/ath10k/htt_tx.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/htt_tx.c b/drivers/net/wireless/ath/ath10k/htt_tx.c
index 786fbd7..4255c1a 100644
--- a/drivers/net/wireless/ath/ath10k/htt_tx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_tx.c
@@ -283,10 +283,8 @@ static int ath10k_htt_tx_alloc_cont_frag_desc(struct ath10k_htt *htt)
htt->frag_desc.vaddr = dma_alloc_coherent(ar->dev, size,
&htt->frag_desc.paddr,
GFP_KERNEL);
- if (!htt->frag_desc.vaddr) {
- ath10k_err(ar, "failed to alloc fragment desc memory\n");
+ if (!htt->frag_desc.vaddr)
return -ENOMEM;
- }
return 0;
}
--
1.9.1
^ permalink raw reply related
* [PATCH 1/2] ath10k: clean up HTT tx buffer allocation and free
From: Mohammed Shafi Shajakhan @ 2016-10-04 12:39 UTC (permalink / raw)
To: ath10k; +Cc: mohammed, linux-wireless, Mohammed Shafi Shajakhan
In-Reply-To: <1475584772-4091-1-git-send-email-mohammed@qca.qualcomm.com>
From: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
cleanup 'ath10k_htt_tx_alloc' by introducing the API's
'ath10k_htt_tx_alloc/free_{cont_txbuf, txdone_fifo} and
re-use them whereever needed
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
---
drivers/net/wireless/ath/ath10k/htt_tx.c | 76 +++++++++++++++++++++-----------
1 file changed, 51 insertions(+), 25 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/htt_tx.c b/drivers/net/wireless/ath/ath10k/htt_tx.c
index 7c072b6..786fbd7 100644
--- a/drivers/net/wireless/ath/ath10k/htt_tx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_tx.c
@@ -229,6 +229,33 @@ void ath10k_htt_tx_free_msdu_id(struct ath10k_htt *htt, u16 msdu_id)
idr_remove(&htt->pending_tx, msdu_id);
}
+static void ath10k_htt_tx_free_cont_txbuf(struct ath10k_htt *htt)
+{
+ size_t size;
+
+ if (!htt->txbuf.vaddr)
+ return;
+
+ size = htt->max_num_pending_tx * sizeof(struct ath10k_htt_txbuf);
+ dma_free_coherent(htt->ar->dev, size, htt->txbuf.vaddr,
+ htt->txbuf.paddr);
+}
+
+static int ath10k_htt_tx_alloc_cont_txbuf(struct ath10k_htt *htt)
+{
+ struct ath10k *ar = htt->ar;
+ size_t size;
+
+ size = htt->max_num_pending_tx * sizeof(struct ath10k_htt_txbuf);
+ htt->txbuf.vaddr = dma_alloc_coherent(ar->dev, size,
+ &htt->txbuf.paddr,
+ GFP_KERNEL);
+ if (!htt->txbuf.vaddr)
+ return -ENOMEM;
+
+ return 0;
+}
+
static void ath10k_htt_tx_free_cont_frag_desc(struct ath10k_htt *htt)
{
size_t size;
@@ -310,10 +337,26 @@ static int ath10k_htt_tx_alloc_txq(struct ath10k_htt *htt)
return 0;
}
+static void ath10k_htt_tx_free_txdone_fifo(struct ath10k_htt *htt)
+{
+ WARN_ON(!kfifo_is_empty(&htt->txdone_fifo));
+ kfifo_free(&htt->txdone_fifo);
+}
+
+static int ath10k_htt_tx_alloc_txdone_fifo(struct ath10k_htt *htt)
+{
+ int ret;
+ size_t size;
+
+ size = roundup_pow_of_two(htt->max_num_pending_tx);
+ ret = kfifo_alloc(&htt->txdone_fifo, size, GFP_KERNEL);
+ return ret;
+}
+
int ath10k_htt_tx_alloc(struct ath10k_htt *htt)
{
struct ath10k *ar = htt->ar;
- int ret, size;
+ int ret;
ath10k_dbg(ar, ATH10K_DBG_BOOT, "htt tx max num pending tx %d\n",
htt->max_num_pending_tx);
@@ -321,13 +364,9 @@ int ath10k_htt_tx_alloc(struct ath10k_htt *htt)
spin_lock_init(&htt->tx_lock);
idr_init(&htt->pending_tx);
- size = htt->max_num_pending_tx * sizeof(struct ath10k_htt_txbuf);
- htt->txbuf.vaddr = dma_alloc_coherent(ar->dev, size,
- &htt->txbuf.paddr,
- GFP_KERNEL);
- if (!htt->txbuf.vaddr) {
- ath10k_err(ar, "failed to alloc tx buffer\n");
- ret = -ENOMEM;
+ ret = ath10k_htt_tx_alloc_cont_txbuf(htt);
+ if (ret) {
+ ath10k_err(ar, "failed to alloc cont tx buffer: %d\n", ret);
goto free_idr_pending_tx;
}
@@ -343,8 +382,7 @@ int ath10k_htt_tx_alloc(struct ath10k_htt *htt)
goto free_frag_desc;
}
- size = roundup_pow_of_two(htt->max_num_pending_tx);
- ret = kfifo_alloc(&htt->txdone_fifo, size, GFP_KERNEL);
+ ret = ath10k_htt_tx_alloc_txdone_fifo(htt);
if (ret) {
ath10k_err(ar, "failed to alloc txdone fifo: %d\n", ret);
goto free_txq;
@@ -359,10 +397,7 @@ free_frag_desc:
ath10k_htt_tx_free_cont_frag_desc(htt);
free_txbuf:
- size = htt->max_num_pending_tx *
- sizeof(struct ath10k_htt_txbuf);
- dma_free_coherent(htt->ar->dev, size, htt->txbuf.vaddr,
- htt->txbuf.paddr);
+ ath10k_htt_tx_free_cont_txbuf(htt);
free_idr_pending_tx:
idr_destroy(&htt->pending_tx);
@@ -388,24 +423,15 @@ static int ath10k_htt_tx_clean_up_pending(int msdu_id, void *skb, void *ctx)
void ath10k_htt_tx_free(struct ath10k_htt *htt)
{
- int size;
-
tasklet_kill(&htt->txrx_compl_task);
idr_for_each(&htt->pending_tx, ath10k_htt_tx_clean_up_pending, htt->ar);
idr_destroy(&htt->pending_tx);
- if (htt->txbuf.vaddr) {
- size = htt->max_num_pending_tx *
- sizeof(struct ath10k_htt_txbuf);
- dma_free_coherent(htt->ar->dev, size, htt->txbuf.vaddr,
- htt->txbuf.paddr);
- }
-
+ ath10k_htt_tx_free_cont_txbuf(htt);
ath10k_htt_tx_free_txq(htt);
ath10k_htt_tx_free_cont_frag_desc(htt);
- WARN_ON(!kfifo_is_empty(&htt->txdone_fifo));
- kfifo_free(&htt->txdone_fifo);
+ ath10k_htt_tx_free_txdone_fifo(htt);
}
void ath10k_htt_htc_tx_complete(struct ath10k *ar, struct sk_buff *skb)
--
1.9.1
^ permalink raw reply related
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