Re: Research + questions on brcmfmac and support for monitor mode
On Mon, 18 Jun 2018 at 23:46, Rafał Miłecki wrote: > On Mon, 18 Jun 2018 at 21:36, Arend van Spriel > wrote: > > > > On 6/18/2018 1:54 PM, Rafał Miłecki wrote: > > > On Mon, 11 Jun 2018 at 12:48, Arend van Spriel > > > wrote: > > >> On 5/30/2018 1:52 PM, Rafał Miłecki wrote: > > >>> I'm providing extra version info of tested firmware images as requested > > >>> by Arend in another e-mail thread. > > >> > > >> Looking into our firmware repo it there are two flags, ie. WL_MONITOR > > >> and WL_RADIOTAP. It seems both are set for firmware containing -stamon- > > >> feature. Your list below confirms that. I still plan to add indication > > >> for WL_RADIOTAP in the "cap" iovar, but a stamon feature check could be > > >> used for older firmwares. > > > > > > The problem is that there isn't a direct mapping between what's > > > visible with the "tail" command and what firmware returns for the > > > "cap" iovar. Just to be sure I bumped #define MAX_CAPS_BUFFER_SIZE to > > > 1024. Firmware that has "stamon" when checked with "tail" command > > > doesn't report "stamon" over "cap" iovar. So I can't detect if > > > firmware was compiled with WL_MONITOR and WL_RADIOTAP using "cap" > > > iovar. > > > > All true. My suggestion is to look for "monitor" and "rtap" in the "cap" > > iovar response to detect if firmware is compiled with WL_MONITOR and > > WL_RADIOTAP respectively. When one (or both) of these is not detected, > > we could fallback to try a stamon iovar and if it is supported enable > > both WL_MONITOR and WL_RADIOTAP. I am looking into a good candidate for > > the stamon iovar so I can prepare a patch. > > Oh, I wasn't aware of the "stamon" iovar (or missed that in your > e-mails). If that works, it'll be a very nice fallback way of > detecting WL_MONITOR and WL_RADIOTAP! I just tried "stamon" iovar and it doesn't work. Following call: u32 var; brcmf_fil_iovar_int_get(ifp, "stamon", ); returns -52 Can you look at that "stamon" iovar again, please? -- Rafał
Kernel Oops in ieee80211_subif_start_xmit
Hi Johannes, Some Arch Linux users are reporting a kernel oops when using iwd on 4.17 inside the control port bits. It seems to be pre-emption related since I've never seen this in all my testing. Any pointers as to what might be causing this? [ 5069.567760] Call Trace: [ 5069.567765] dump_stack+0x5c/0x80 [ 5069.567769] check_preemption_disabled.cold.0+0x46/0x51 [ 5069.567778] __ieee80211_subif_start_xmit+0x144/0x210 [mac80211] [ 5069.567786] ieee80211_tx_control_port+0x116/0x140 [mac80211] [ 5069.567806] nl80211_tx_control_port+0x13c/0x270 [cfg80211] [ 5069.567809] genl_family_rcv_msg+0x1c4/0x3a0 [ 5069.567811] genl_rcv_msg+0x47/0x90 [ 5069.567814] ? __kmalloc_node_track_caller+0x210/0x2b0 [ 5069.567815] ? genl_family_rcv_msg+0x3a0/0x3a0 [ 5069.567816] netlink_rcv_skb+0x4c/0x120 [ 5069.567818] genl_rcv+0x24/0x40 [ 5069.567819] netlink_unicast+0x196/0x240 [ 5069.567821] netlink_sendmsg+0x1fd/0x3c0 [ 5069.567823] sock_sendmsg+0x33/0x40 [ 5069.567825] __sys_sendto+0xee/0x160 [ 5069.567826] ? __sys_recvmsg+0x54/0xa0 [ 5069.567829] ? do_epoll_wait+0xb0/0xd0 [ 5069.567830] __x64_sys_sendto+0x24/0x30 [ 5069.567832] do_syscall_64+0x5b/0x170 [ 5069.567834] entry_SYSCALL_64_after_hwframe+0x44/0xa9
Re: Research + questions on brcmfmac and support for monitor mode
On Mon, 18 Jun 2018 at 21:36, Arend van Spriel wrote: > > On 6/18/2018 1:54 PM, Rafał Miłecki wrote: > > On Mon, 11 Jun 2018 at 12:48, Arend van Spriel > > wrote: > >> On 5/30/2018 1:52 PM, Rafał Miłecki wrote: > >>> I'm providing extra version info of tested firmware images as requested > >>> by Arend in another e-mail thread. > >> > >> Looking into our firmware repo it there are two flags, ie. WL_MONITOR > >> and WL_RADIOTAP. It seems both are set for firmware containing -stamon- > >> feature. Your list below confirms that. I still plan to add indication > >> for WL_RADIOTAP in the "cap" iovar, but a stamon feature check could be > >> used for older firmwares. > > > > The problem is that there isn't a direct mapping between what's > > visible with the "tail" command and what firmware returns for the > > "cap" iovar. Just to be sure I bumped #define MAX_CAPS_BUFFER_SIZE to > > 1024. Firmware that has "stamon" when checked with "tail" command > > doesn't report "stamon" over "cap" iovar. So I can't detect if > > firmware was compiled with WL_MONITOR and WL_RADIOTAP using "cap" > > iovar. > > All true. My suggestion is to look for "monitor" and "rtap" in the "cap" > iovar response to detect if firmware is compiled with WL_MONITOR and > WL_RADIOTAP respectively. When one (or both) of these is not detected, > we could fallback to try a stamon iovar and if it is supported enable > both WL_MONITOR and WL_RADIOTAP. I am looking into a good candidate for > the stamon iovar so I can prepare a patch. Oh, I wasn't aware of the "stamon" iovar (or missed that in your e-mails). If that works, it'll be a very nice fallback way of detecting WL_MONITOR and WL_RADIOTAP! -- Rafał
Re: [PATCH v2] mac80211: Fix wlan freezes under load at rekey
Hi, > > > 2) For outgoing packets: > > > If mac80211 is providing the PN (IV) and hands over the cleartext > > > packets for encryption to the hardware immediately prior to a key > > > change the driver/card may process the queued packets after > > > switching to the new key. > > > This will immediatelly bump the PN (IV) value on the remote STA to > > > an incorrect high number, also freezing the connection. > > > > > > Both issues can be prevented by first replacing the key in the HW and > > > makeing sure no aggregation sessions are running during the rekey. > > > > Getting back to this, am I understanding correctly that in the latter > > (outgoing) case this would cause > > I don't get the point here...Shall I flesh out the description of the > exiting races in the code a bit more? You couldn't, I didn't finish this sentence for some reason ... or wrote and then deleted it by accident? I meant to say: Am I understanding correctly that in the latter (outgoing) case this might cause unencrypted packets to be transmitted? I talked about that more below. > > Also, I think you should probably describe better why the aggregation > > session stuff is needed. I'm already thinking there times about it again > > ... > > I'll rework the description and will go into more details. > Here a first quick draft what I plan amend to the commit message. But > this got kind of long: > ... > Both issues can be prevented by first replacing the key in the HW and > making sure no aggregation sessions are running during the rekey. > > The "core" of the fix is to change the old unicast key install sequence > - atomic switch over to the new key in mac80211 > - remove the old key in the HW and mac80211 > - add new key in the hw > to > - mark the old key as tainted to drop TX packets trying to use it > - remove the old key in the HW and mac80211 > - add new key to the HW > - atomic switch over to the new key in mac80211 > > Since the new key is not marked as tainted the last step will also > enable TX again. > > With the new procedure the HW will be unable to decode packets still > encrypted with the old key prior to switching to the new key in > mac80211. Locking down TX during the rekey makes sure that there are no > outgoing packets mac80211 prepared for the old key the hw can encrypt > with the new key. > We can now decrypt and get incoming packets while mac80211 is still on > the old key, but the worst (and most likely) case is now, that the > replay detection will drop those packets till mac80211 also switch over. This actually is somewhat problematic, at least for TKIP it could cause countermeasures. Should we exclude TKIP here somehow? I don't think we can disable countermeasures because then we could be attacked in this time window without starting them, and we have a really hard time distinguishing attacks and "fake" replays. > Instead of checking PN from old key packets against the new key (and > bump the PN for the new key, killing our connection) we are now checking > the PN from new key packets against the old key (and drop a few packets > during rekey only). > > When using TX aggregation we get an additional race which can poison the > remote station: > When a TX aggregation session is running during the key replacement it's > possible that one of the frames send out prior of the TX lock down (old > key) got lost and will be repeated after the TX lock down is lifted, > using the old skb prepared for the old key with the new installed key in > the hardware. This would bump the PN counter of our peer to an incorrect > value and breaking the RX for the remote station. Right, this is what I had forgotten about already. > > > + ieee80211_flush_queues(key->local, key->sdata, false); > > > + ieee80211_key_disable_hw_accel(key); > > > > I'm not sure all drivers implement drv_flush() [correctly], what happens > > if they don't? I guess some packets end up being transmitted in clear > > text or a dummy key, unless the hardware/firmware knows about this and > > drops them? > > Flushing the queues is not needed for to the logic and only a workaround > for drivers like ath9k which can still send out packets for a key which > was already deleted. When the driver guarantees that after the key > deletion function returns to mac80211 that there will be no more packets > send out prepared for the old key it can be removed. What will happen for other kinds of packets though? For iwlwifi, for example, the key material is added into the key. It thus doesn't have this race in the first place, but it will definitely send out packets after Btw - perhaps that means we should avoid the complicated mechanisms like TX aggregation shutdown for keys that the driver marks as being safe? Clearly for iwlwifi (at least CCMP and before, not with the longer keys in GCMP-256) the race can't possibly happen. In other drivers though, I worry that removing the key will *not* mean that
Re: [PATCH v2] mac80211: Fix wlan freezes under load at rekey
> On Tue, 2018-05-15 at 12:22 +0200, Alexander Wetzel wrote: >> Rekeying a pairwise key with encryption offload and only keyid 0 has two >> potential races which can freeze the wlan conection till rekeyed again: >> >> 1) For incomming packets: >> If the local STA installs the key prior to the remote STA we still >> have the old key active in the hardware for a short time after >> mac80211 switched to the new key. >> The card can still hand over packets decoded with the old key to >> mac80211, bumping the new PN (IV) value to an incorrect high number and >> tricking the local replay detection to drop all packets really sent >> with the new key. >> >> 2) For outgoing packets: >> If mac80211 is providing the PN (IV) and hands over the cleartext >> packets for encryption to the hardware immediately prior to a key >> change the driver/card may process the queued packets after >> switching to the new key. >> This will immediatelly bump the PN (IV) value on the remote STA to >> an incorrect high number, also freezing the connection. >> >> Both issues can be prevented by first replacing the key in the HW and >> makeing sure no aggregation sessions are running during the rekey. > > Getting back to this, am I understanding correctly that in the latter > (outgoing) case this would cause I don't get the point here...Shall I flesh out the description of the exiting races in the code a bit more? > > Also, I think you should probably describe better why the aggregation > session stuff is needed. I'm already thinking there times about it again > ... I'll rework the description and will go into more details. Here a first quick draft what I plan amend to the commit message. But this got kind of long: ... Both issues can be prevented by first replacing the key in the HW and making sure no aggregation sessions are running during the rekey. The "core" of the fix is to change the old unicast key install sequence - atomic switch over to the new key in mac80211 - remove the old key in the HW and mac80211 - add new key in the hw to - mark the old key as tainted to drop TX packets trying to use it - remove the old key in the HW and mac80211 - add new key to the HW - atomic switch over to the new key in mac80211 Since the new key is not marked as tainted the last step will also enable TX again. With the new procedure the HW will be unable to decode packets still encrypted with the old key prior to switching to the new key in mac80211. Locking down TX during the rekey makes sure that there are no outgoing packets mac80211 prepared for the old key the hw can encrypt with the new key. We can now decrypt and get incoming packets while mac80211 is still on the old key, but the worst (and most likely) case is now, that the replay detection will drop those packets till mac80211 also switch over. Instead of checking PN from old key packets against the new key (and bump the PN for the new key, killing our connection) we are now checking the PN from new key packets against the old key (and drop a few packets during rekey only). When using TX aggregation we get an additional race which can poison the remote station: When a TX aggregation session is running during the key replacement it's possible that one of the frames send out prior of the TX lock down (old key) got lost and will be repeated after the TX lock down is lifted, using the old skb prepared for the old key with the new installed key in the hardware. This would bump the PN counter of our peer to an incorrect value and breaking the RX for the remote station. Stopping all running aggregation sessions and declining any new ones till we have switched over to the new key side steps that problem. /end commit draft It would be possible to keep the aggregation sessions running, but that seems to need some quite invasive changes and checks. > >> + ieee80211_sta_tear_down_BA_sessions( >> + sta, AGG_STOP_LOCAL_REQUEST); > > minor indentation issue here I'll go for a 81 char long single line here. > >> + ieee80211_flush_queues(key->local, key->sdata, false); >> + ieee80211_key_disable_hw_accel(key); > > I'm not sure all drivers implement drv_flush() [correctly], what happens > if they don't? I guess some packets end up being transmitted in clear > text or a dummy key, unless the hardware/firmware knows about this and > drops them? Flushing the queues is not needed for to the logic and only a workaround for drivers like ath9k which can still send out packets for a key which was already deleted. When the driver guarantees that after the key deletion function returns to mac80211 that there will be no more packets send out prepared for the old key it can be removed. The driver could simply wait for whatever the may queue time may be or detect and drop these packets. (In fact it can even send out the packet again, it just must make sure to still use the old and official deleted
Re: [PATCH] cfg80211: Add cumulative channel survey dump support.
On 06/18/2018 01:46 PM, Johannes Berg wrote: On Thu, 2018-05-31 at 08:52 -0700, Ben Greear wrote: On 05/31/2018 02:06 AM, vnara...@codeaurora.org wrote: On 2018-05-23 15:24, Johannes Berg wrote: On Tue, 2018-05-22 at 14:45 +0530, Venkateswara Naralasetty wrote: This patch provides support to send accumulated survey data to user if low level drivers provides non-accumulated survey data. I think the commit log should say what you need this for? It's simultaneously a new flag, and a lot of code, but it's not clear what the point is? johannes I will sent next version of patch with updated commit log. Providing you the earlier discussion of this patch to give quick overview about this patch. https://patchwork.kernel.org/patch/9701459/ It is simple to fix the firmware, it just has several bugs related to clearing the accumulator as well as the 'real' values. If you can find a QCA firmware engineer that will accept patches I can show them how to fix this easily. I recently fixed this in my wave-1 firmware. I posted patches to the ath10k driver to support this a week or so ago, but not sure if Kalle will apply them. That would be nicer even, but I guess we still have to worry about older firmware? Perhaps not for survey support? Dunno. Obviously less code is better, but I can't really say how easy it would be to get firmware updates rolled out to people who'd need them ... And, it is likely that even if you don't use the 'clear' option, you are going to get wraps in the firmware and that will just be other harder to debug bugs. You have to use clear if you don't accumulate completely in fw, no? At least some firmware is broken in numerous ways, and there is no clear way to tell which firmware is broken how as far as I can tell. It does appear to be fixed in recent 10.4 (wave-2) firmware, so maybe they will fix 10.2 as well. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com
Re: [PATCH v2 1/2] cfg80211: last ack signal support in station dump
On Mon, 2018-06-18 at 14:48 +0530, Balaji Pothunoori wrote:
> On 2018-06-15 17:11, Johannes Berg wrote:
> > On Mon, 2018-06-04 at 19:41 +0530, Balaji Pothunoori wrote:
> > >
> > > +++ b/include/uapi/linux/nl80211.h
> > > @@ -3000,8 +3000,8 @@ enum nl80211_sta_bss_param {
> > > * received from the station (u64, usec)
> > > * @NL80211_STA_INFO_PAD: attribute used for padding for 64-bit
> > > alignment
> > > * @NL80211_STA_INFO_ACK_SIGNAL: signal strength of the last ACK
> > > frame(u8, dBm)
> > > - * @NL80211_STA_INFO_DATA_ACK_SIGNAL_AVG: avg signal strength of
> > > (data)
> > > - * ACK frame (s8, dBm)
> > > + * @NL80211_STA_INFO_ACK_SIGNAL_AVG: avg signal strength of data or
> > > management
> > > + * ACK frames(s8, dBm)
> > > * @__NL80211_STA_INFO_AFTER_LAST: internal
> > > * @NL80211_STA_INFO_MAX: highest possible station info attribute
> > > */
> > > @@ -3041,7 +3041,7 @@ enum nl80211_sta_info {
> > > NL80211_STA_INFO_RX_DURATION,
> > > NL80211_STA_INFO_PAD,
> > > NL80211_STA_INFO_ACK_SIGNAL,
> > > - NL80211_STA_INFO_DATA_ACK_SIGNAL_AVG,
> > > + NL80211_STA_INFO_ACK_SIGNAL_AVG,
> >
> > Wait, what happened here? You can't remove old API.
>
> Here is my intention is to make the unique average ack signal and last
> ack signal
> support in station dump irrespective of data or management tx ack
> packet.
> Do you want me to add a new API for management tx ack packet?
Well, you can't remove old API.
And the data-ACK was explicitly added because of concerns about signal
varying a lot with MCS, so ACK signal is more reliable.
I suppose the original use here didn't really *need* just *data* ACK, so
perhaps we can redefine it - you'd know better? After all, you defined
the old API :-))
But still, you can't just remove it. I think we're probably OK to
redefine it but then you need to keep API compatibility by adding the
necessary defines.
johannes
Re: [PATCH] cfg80211: Add cumulative channel survey dump support.
On Thu, 2018-05-31 at 08:52 -0700, Ben Greear wrote: > > On 05/31/2018 02:06 AM, vnara...@codeaurora.org wrote: > > On 2018-05-23 15:24, Johannes Berg wrote: > > > On Tue, 2018-05-22 at 14:45 +0530, Venkateswara Naralasetty wrote: > > > > This patch provides support to send accumulated survey data to > > > > user if low level drivers provides non-accumulated survey data. > > > > > > I think the commit log should say what you need this for? > > > > > > It's simultaneously a new flag, and a lot of code, but it's not clear > > > what the point is? > > > > > > johannes > > > > I will sent next version of patch with updated commit log. > > > > Providing you the earlier discussion of this patch to give quick overview > > about this patch. > > https://patchwork.kernel.org/patch/9701459/ > > It is simple to fix the firmware, it just has several bugs related to > clearing the > accumulator as well as the 'real' values. If you can find a QCA firmware > engineer > that will accept patches I can show them how to fix this easily. I recently > fixed this in my wave-1 firmware. I posted patches to the ath10k driver to > support this a week or so ago, but not sure if Kalle will apply them. That would be nicer even, but I guess we still have to worry about older firmware? Perhaps not for survey support? Dunno. Obviously less code is better, but I can't really say how easy it would be to get firmware updates rolled out to people who'd need them ... > And, it is likely that even if you don't use the 'clear' option, you are > going to > get wraps in the firmware and that will just be other harder to debug bugs. You have to use clear if you don't accumulate completely in fw, no? johannes
Re: [PATCH] cfg80211: Add cumulative channel survey dump support.
On Thu, 2018-05-31 at 14:36 +0530, vnara...@codeaurora.org wrote: > On 2018-05-23 15:24, Johannes Berg wrote: > > On Tue, 2018-05-22 at 14:45 +0530, Venkateswara Naralasetty wrote: > > > This patch provides support to send accumulated survey data to > > > user if low level drivers provides non-accumulated survey data. > > > > I think the commit log should say what you need this for? > > > > It's simultaneously a new flag, and a lot of code, but it's not clear > > what the point is? > > > > johannes > > I will sent next version of patch with updated commit log. > > Providing you the earlier discussion of this patch to give quick > overview about this patch. > https://patchwork.kernel.org/patch/9701459/ Haha. I guess it's too long ago :) johannes
[PATCH] rfkill: add header files to MAINTAINERS
From: Johannes Berg These files weren't covered by the MAINTAINERS file, add them. Reported-by: Peter Meerwald-Stadler Signed-off-by: Johannes Berg --- MAINTAINERS | 2 ++ 1 file changed, 2 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 2c7069037a15..1fe2aac28177 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -12155,6 +12155,8 @@ S: Maintained F: Documentation/rfkill.txt F: Documentation/ABI/stable/sysfs-class-rfkill F: net/rfkill/ +F: include/linux/rfkill.h +F: include/uapi/linux/rfkill.h RHASHTABLE M: Thomas Graf -- 2.14.4
Re: Atheros AR9462 - 5Ghz not working
Hi Arend, On Mon, Jun 18, 2018 at 9:23 PM Arend van Spriel wrote: > > + Martin thank you for CC'ing me! > On 6/18/2018 3:53 PM, mgre...@cinci.rr.com wrote: > > > > Tom Psyborg wrote: > >> Hi > >> > >> Your log only show attemps on ch 2447, Can you try connecting to 5GHz > >> AP? Connect to Hidden Wireless Network option at the bottom of the > >> nm-applet? Running airodump in monitor mode to see if it captures > >> anything? Maybe your laptop's antennas were designed for 2.4G card > >> only but this just dumb guessing... > >> > > > > It won't connect to any 5GHz AP. > > I don't run network manager or Gnome, in fact X11 is not installed on this > > machine at all. > > I don't think there is such a thing as 2.4GHz vs 5GHz antennas. > > Actually there is. At least there are 2.4G specific antennas and > dual-band antennas. > > In 4.11 there have been a couple eeprom related changes dealing with > endianness of fields in eeprom. Could be those cause a regression for > you. I don't have the exact sha id of those commits, but I added the > author to this thread. I couldn't find the whole thread in a mailing list archive somewhere could the original reporter please send a kernel log (dmesg) and some information about the host system? if the host system uses devicetree (maybe because it's an ARM based system or some PowerMac, etc.) then please keep reading Bas Vermeulen (I added him to this thread *in case* we find out that it's the same issue) reported that a AR9278 card refused to work in his "PowerMac G5" he posted a patch here: [0] back then I asked if he could test and send a modified version of his patch - I included that below (if someone is interested in the cause: whenever there is a devicetree node for the ath9k card then the driver-internal flag AH_NO_EEP_SWAP is set unconditionally. this flag is *NOT* set if there's no devicetree node. if it is set then the driver doesn't try to swap the EEPROM data as this breaks some OpenWrt based devices. however, since all OpenWrt devices set the "qca,no-eeprom" property we can move setting the AH_NO_EEP_SWAP flag into the existing if-block and hopefully solve all issues) Regards Martin [0] https://patchwork.kernel.org/patch/10241731/ diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c index c070a9e51ebf..fae572b38416 100644 --- a/drivers/net/wireless/ath/ath9k/init.c +++ b/drivers/net/wireless/ath/ath9k/init.c @@ -636,15 +636,15 @@ static int ath9k_of_init(struct ath_softc *sc) ret = ath9k_eeprom_request(sc, eeprom_name); if (ret) return ret; + + ah->ah_flags &= ~AH_USE_EEPROM; + ah->ah_flags |= AH_NO_EEP_SWAP; } mac = of_get_mac_address(np); if (mac) ether_addr_copy(common->macaddr, mac); - ah->ah_flags &= ~AH_USE_EEPROM; - ah->ah_flags |= AH_NO_EEP_SWAP; - return 0; }
Re: Research + questions on brcmfmac and support for monitor mode
On 6/18/2018 1:54 PM, Rafał Miłecki wrote: On Mon, 11 Jun 2018 at 12:48, Arend van Spriel wrote: On 5/30/2018 1:52 PM, Rafał Miłecki wrote: I'm providing extra version info of tested firmware images as requested by Arend in another e-mail thread. Looking into our firmware repo it there are two flags, ie. WL_MONITOR and WL_RADIOTAP. It seems both are set for firmware containing -stamon- feature. Your list below confirms that. I still plan to add indication for WL_RADIOTAP in the "cap" iovar, but a stamon feature check could be used for older firmwares. The problem is that there isn't a direct mapping between what's visible with the "tail" command and what firmware returns for the "cap" iovar. Just to be sure I bumped #define MAX_CAPS_BUFFER_SIZE to 1024. Firmware that has "stamon" when checked with "tail" command doesn't report "stamon" over "cap" iovar. So I can't detect if firmware was compiled with WL_MONITOR and WL_RADIOTAP using "cap" iovar. All true. My suggestion is to look for "monitor" and "rtap" in the "cap" iovar response to detect if firmware is compiled with WL_MONITOR and WL_RADIOTAP respectively. When one (or both) of these is not detected, we could fallback to try a stamon iovar and if it is supported enable both WL_MONITOR and WL_RADIOTAP. I am looking into a good candidate for the stamon iovar so I can prepare a patch. Regards, Arend
Re: Atheros AR9462 - 5Ghz not working
+ Martin On 6/18/2018 3:53 PM, mgre...@cinci.rr.com wrote: Tom Psyborg wrote: Hi Your log only show attemps on ch 2447, Can you try connecting to 5GHz AP? Connect to Hidden Wireless Network option at the bottom of the nm-applet? Running airodump in monitor mode to see if it captures anything? Maybe your laptop's antennas were designed for 2.4G card only but this just dumb guessing... It won't connect to any 5GHz AP. I don't run network manager or Gnome, in fact X11 is not installed on this machine at all. I don't think there is such a thing as 2.4GHz vs 5GHz antennas. Actually there is. At least there are 2.4G specific antennas and dual-band antennas. In 4.11 there have been a couple eeprom related changes dealing with endianness of fields in eeprom. Could be those cause a regression for you. I don't have the exact sha id of those commits, but I added the author to this thread. Regards, Arend
Re: mt7601u: remove warning when avg_rssi is zero
Stanislaw Gruszka wrote:
> It turned out that we can run calibration without already received
> frames with RSSI data. In such case just don't update AGC register
> and don't print the warning.
>
> Fixes: b305a6ab0247 ("mt7601u: use EWMA to calculate avg_rssi")
> Reported-by: Adam Borowski
> Signed-off-by: Stanislaw Gruszka
> Acked-by: Jakub Kicinski
As the first release for b305a6ab0247 was v4.18-rc1, I'll queue this to 4.18.
--
https://patchwork.kernel.org/patch/10455479/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH 2/2] mwifiex: handle race during mwifiex_usb_disconnect
Brian Norris writes: > Hi Ganapathi, > > On Fri, Jun 01, 2018 at 04:11:20PM +0530, Ganapathi Bhat wrote: >> Race condition is observed during rmmod of mwifiex_usb: >> >> 1. The rmmod thread will call mwifiex_usb_disconnect(), download >>SHUTDOWN command and do wait_event_interruptible_timeout(), >>waiting for response. >> >> 2. The main thread will handle the response and will do a >>wake_up_interruptible(), unblocking rmmod thread. >> >> 3. On getting unblocked, rmmod thread will make rx_cmd.urb = NULL in >>mwifiex_usb_free(). >> >> 4. The main thread will try to resubmit rx_cmd.urb in >>mwifiex_usb_submit_rx_urb(), which is NULL. >> >> To fix this, move mwifiex_usb_free() from mwifiex_usb_disconnect >> to mwifiex_unregister_dev(). Function mwifiex_unregister_dev() is >> called after flushing the command and RX work queues. >> >> Signed-off-by: Brian Norris > > ^^ I'm not sure if that line is quite accurate. While I nearly spelled > out what the patch would look like, you wrote it. > > Anyway, patch seems good to me, assuming it tests out OK for you: > > Reviewed-by: Brian Norris > > and if Kalle hasn't applied this yet, an alternative to Signed-off-by: > > Suggested-by: Brian Norris Ok, I'll change that. -- Kalle Valo
rtl8192cu with Edimax 7811UN and IMX6
Goodmorning. My name's Mauro Ziliani and I write from Parma, Italy. I need to plug he dongle Edimax 7811UN into a IMX6DLSABRESD board, using kerne 4.1.15 (Yocto Krogoth) I have the following problem. I switch on the board wth dongle plugged. I try a sftp transfer from my PC and the board. All works fine. I wait for some minute, I retry the transfer, but the board doesn't start to receive the file, and the file stay for some minuti waiting to start. Than the PC goes in timeout This is what I do 1. scp app_1.0_armhf.deb root@imx6dlsabresd:/home/root The transfer is completed. The progress bar is shown and the amount of transfered data 2. I wait some minutes ... ... I retry the transfer scp app_1.0_armhf.deb root@imx6dlsabresd:/home/root the PC wait for 5 minute about and then it goes to timeout. On the imx6dlsabresd board dmesg tells nothing of interesting Looking with iwconfig wlan0 I get this wlan0 IEEE 802.11bgn ESSID:"STUDIO" Mode:Managed Frequency:2.437 GHz Access Point: 00:0C:E6:0A:3E:CA Bit Rate=72.2 Mb/s Tx-Power=20 dBm Retry short limit:7 RTS thr=2347 B Fragment thr:off Encryption key:off Power Management:off Link Quality=62/70 Signal level=-48 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:240 Missed beacon:0 The power management is always off Where I can look to get some more information on this strange behaviour? There is a mini-cd sold with the dongle Edimax, but the linux driver is for kernel 3.x Best regards, Mauro Ziliani
[PATCH v3 5/5] staging: use BIT_ULL for NL80211_STA_INFO_* attribute types
The BIT macro uses unsigned long which some architectures handle as 32 bit
and therefore might cause macro's shift to overflow when used on a value
equals or larger than 32 (NL80211_STA_INFO_RX_DURATION and afterwards).
Since 'filled' member in station_info changed to u64, BIT_ULL macro
should be used with all NL80211_STA_INFO_* attribute types instead of BIT
to prevent future possible bugs when one will use BIT macro for higher
attributes by mistake.
This commit cleans up all usages of BIT macro with the above field
in cfg80211 by changing it to BIT_ULL instead.
Signed-off-by: Omer Efrat
---
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c | 10 +-
drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 14 +++---
drivers/staging/wlan-ng/cfg80211.c| 4 ++--
3 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
index 02178e2..26b838f 100644
--- a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
+++ b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
@@ -1273,16 +1273,16 @@ static int cfg80211_rtw_get_station(struct wiphy *wiphy,
goto exit;
}
- sinfo->filled |= BIT(NL80211_STA_INFO_SIGNAL);
+ sinfo->filled |= BIT_ULL(NL80211_STA_INFO_SIGNAL);
sinfo->signal =
translate_percentage_to_dbm(padapter->recvpriv.signal_strength);
- sinfo->filled |= BIT(NL80211_STA_INFO_TX_BITRATE);
+ sinfo->filled |= BIT_ULL(NL80211_STA_INFO_TX_BITRATE);
sinfo->txrate.legacy = rtw_get_cur_max_rate(padapter);
- sinfo->filled |= BIT(NL80211_STA_INFO_RX_PACKETS);
+ sinfo->filled |= BIT_ULL(NL80211_STA_INFO_RX_PACKETS);
sinfo->rx_packets = sta_rx_data_pkts(psta);
- sinfo->filled |= BIT(NL80211_STA_INFO_TX_PACKETS);
+ sinfo->filled |= BIT_ULL(NL80211_STA_INFO_TX_PACKETS);
sinfo->tx_packets = psta->sta_stats.tx_pkts;
}
@@ -3013,7 +3013,7 @@ static intcfg80211_rtw_dump_station(struct wiphy
*wiphy, struct net_device *nde
goto exit;
}
memcpy(mac, psta->hwaddr, ETH_ALEN);
- sinfo->filled = BIT(NL80211_STA_INFO_SIGNAL);
+ sinfo->filled = BIT_ULL(NL80211_STA_INFO_SIGNAL);
sinfo->signal = psta->rssi;
exit:
diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
index e248702..13d3918 100644
--- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
+++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
@@ -1141,7 +1141,7 @@ static int get_station(struct wiphy *wiphy, struct
net_device *dev,
return -ENOENT;
}
- sinfo->filled |= BIT(NL80211_STA_INFO_INACTIVE_TIME);
+ sinfo->filled |= BIT_ULL(NL80211_STA_INFO_INACTIVE_TIME);
wilc_get_inactive_time(vif, mac, _time);
sinfo->inactive_time = 1000 * inactive_time;
@@ -1150,11 +1150,11 @@ static int get_station(struct wiphy *wiphy, struct
net_device *dev,
wilc_get_statistics(vif, );
- sinfo->filled |= BIT(NL80211_STA_INFO_SIGNAL) |
-BIT(NL80211_STA_INFO_RX_PACKETS) |
-BIT(NL80211_STA_INFO_TX_PACKETS) |
-BIT(NL80211_STA_INFO_TX_FAILED) |
-BIT(NL80211_STA_INFO_TX_BITRATE);
+ sinfo->filled |= BIT_ULL(NL80211_STA_INFO_SIGNAL) |
+BIT_ULL(NL80211_STA_INFO_RX_PACKETS) |
+BIT_ULL(NL80211_STA_INFO_TX_PACKETS) |
+BIT_ULL(NL80211_STA_INFO_TX_FAILED) |
+BIT_ULL(NL80211_STA_INFO_TX_BITRATE);
sinfo->signal = stats.rssi;
sinfo->rx_packets = stats.rx_cnt;
@@ -1775,7 +1775,7 @@ static int dump_station(struct wiphy *wiphy, struct
net_device *dev,
priv = wiphy_priv(wiphy);
vif = netdev_priv(priv->dev);
- sinfo->filled |= BIT(NL80211_STA_INFO_SIGNAL);
+ sinfo->filled |= BIT_ULL(NL80211_STA_INFO_SIGNAL);
wilc_get_rssi(vif, >signal);
diff --git a/drivers/staging/wlan-ng/cfg80211.c
b/drivers/staging/wlan-ng/cfg80211.c
index 4291225..07c52e3 100644
--- a/drivers/staging/wlan-ng/cfg80211.c
+++ b/drivers/staging/wlan-ng/cfg80211.c
@@ -282,9 +282,9 @@ static int prism2_get_station(struct wiphy *wiphy, struct
net_device *dev,
if (result == 0) {
sinfo->txrate.legacy = quality.txrate.data;
- sinfo->filled |= BIT(NL80211_STA_INFO_TX_BITRATE);
+ sinfo->filled |= BIT_ULL(NL80211_STA_INFO_TX_BITRATE);
sinfo->signal = quality.level.data;
- sinfo->filled |=
Re: Atheros AR9462 - 5Ghz not working
Tom Psyborg wrote: > Hi > > Your log only show attemps on ch 2447, Can you try connecting to 5GHz > AP? Connect to Hidden Wireless Network option at the bottom of the > nm-applet? Running airodump in monitor mode to see if it captures > anything? Maybe your laptop's antennas were designed for 2.4G card > only but this just dumb guessing... > It won't connect to any 5GHz AP. I don't run network manager or Gnome, in fact X11 is not installed on this machine at all. I don't think there is such a thing as 2.4GHz vs 5GHz antennas. > On 17/06/2018, mgre...@cinci.rr.com wrote: > > > > "Michał Kazior" wrote: > >> On 15 June 2018 at 19:23, wrote: > >> > mgre...@cinci.rr.com wrote: > >> >> "Michał Kazior" wrote: > >> >> > Your noise floor readout in survey dump is terribly bad for 5GHz. It > >> >> > ain't stellar for 2.4GHz either but within reason nonetheless. > >> >> > > >> >> > Did you try using the card in a different device? I wonder if the > >> >> > device you're trying to use it in has some sort of internal noise on > >> >> > those frequencies and/or ath9k's ANI isn't able to deal with it. > >> >> > > >> >> > > >> >> > Michał > >> >> > > >> >> > On 15 June 2018 at 15:31, wrote: > >> >> > >> >> I did. > >> >> I took it out of the Penguin-Z notebook and put it in a Dell XPS15 9560 > >> >> running Windows 10. Only 2.4Ghz networks were visible from there as > >> >> well. Not exactly apples-to-apples, but consistent results. > >> > >> This reduces likeliness this is tied to a os/driver issue. Maybe > >> calibration data on the device eeprom is broken? Or maybe it's a > >> hardware defect? > > > > > > > > > > I have three of these cards all with the same problem, so if it's a hardware > > defect then it's pretty much game over and these cards are all useless. > > Forgive my ignorance, but is there any way to check/fix calibration data? > > > > > > > > > >> > >> > >> > Could it be antenna related (in multiple devices)? > >> > >> Antennas can be designed to work better on certain frequency ranges. I > >> wouldn't expect such a dramatic effect though. > >> > >> > >> > On wikidevi.com I see some M.2 cards listed with an antenna connector of > >> > U.FL and others with MHF4. I can't find anything describing the > >> > difference, if any. The connectors seemed to fit OK. Also, what's the > >> > deal with 'main' and 'aux' antenna connectors? I've seen people suggest > >> > swapping them has helped in some cases with poor signal, while others > >> > insist that it makes no difference. I have not tried swapping the > >> > connectors. > >> > >> I think it's not a connector problem because 2.4GHz scan results > >> report reasonable signal strength for found APs (-60dBm). My > >> experience is that if you use a wrong (but seemingly fitting) > >> connector you'd get near 0 results or below -90dBm across the board. > >> > >> > >> Michał > > > >
Re: [PATCH v3 5/5] staging: use BIT_ULL for NL80211_STA_INFO_* attribute types
On Mon, Jun 18, 2018 at 04:11:51PM +0300, Kalle Valo wrote: > Greg KH writes: > > > On Mon, Jun 18, 2018 at 10:29:43AM +0300, Kalle Valo wrote: > >> Greg KH writes: > >> > >> > On Sun, Jun 17, 2018 at 01:07:36PM +0300, Omer Efrat wrote: > >> >> The BIT macro uses unsigned long which some architectures handle as 32 > >> >> bit > >> >> and therefore might cause macro's shift to overflow when used on a value > >> >> equals or larger than 32 (NL80211_STA_INFO_RX_DURATION and afterwards). > >> >> > >> >> Since 'filled' member in station_info changed to u64, BIT_ULL macro > >> >> should be used with all NL80211_STA_INFO_* attribute types instead of > >> >> BIT > >> >> to prevent future possible bugs when one will use BIT macro for higher > >> >> attributes by mistake. > >> >> > >> >> This commit cleans up all usages of BIT macro with the above field > >> >> in cfg80211 by changing it to BIT_ULL instead. > >> >> > >> >> Signed-off-by: Omer Efrat > >> > > >> > Acked-by: Greg Kroah-Hartman > >> > >> Via which tree is this supposed to go? > > > > Not mine :) > > > > Have fun with it! > > Hehe :) > > But I don't see why this patch 5 should go either to mac80211 or > wireless-drivers trees as there's no dependency or anything like that, > AFAIK it's just cleanup. So it would simplest to get this patch 5 to > staging tree, less conflicts that way. Sorry, I thought it was dependant on the previous patches, given that the first time I tried to apply it, it failed. Omer, can you just resend this single patch to me and I will be glad to apply it to the staging tree, if it really is stand-alone. thanks, greg k-h
Re: [PATCH v3 5/5] staging: use BIT_ULL for NL80211_STA_INFO_* attribute types
Greg KH writes: > On Mon, Jun 18, 2018 at 10:29:43AM +0300, Kalle Valo wrote: >> Greg KH writes: >> >> > On Sun, Jun 17, 2018 at 01:07:36PM +0300, Omer Efrat wrote: >> >> The BIT macro uses unsigned long which some architectures handle as 32 bit >> >> and therefore might cause macro's shift to overflow when used on a value >> >> equals or larger than 32 (NL80211_STA_INFO_RX_DURATION and afterwards). >> >> >> >> Since 'filled' member in station_info changed to u64, BIT_ULL macro >> >> should be used with all NL80211_STA_INFO_* attribute types instead of BIT >> >> to prevent future possible bugs when one will use BIT macro for higher >> >> attributes by mistake. >> >> >> >> This commit cleans up all usages of BIT macro with the above field >> >> in cfg80211 by changing it to BIT_ULL instead. >> >> >> >> Signed-off-by: Omer Efrat >> > >> > Acked-by: Greg Kroah-Hartman >> >> Via which tree is this supposed to go? > > Not mine :) > > Have fun with it! Hehe :) But I don't see why this patch 5 should go either to mac80211 or wireless-drivers trees as there's no dependency or anything like that, AFAIK it's just cleanup. So it would simplest to get this patch 5 to staging tree, less conflicts that way. Patches 1 and 2 of course go to mac80211 tree and patch 4 goes to wireless-drivers. -- Kalle Valo
Re: Research + questions on brcmfmac and support for monitor mode
On Mon, 11 Jun 2018 at 12:48, Arend van Spriel wrote: > On 5/30/2018 1:52 PM, Rafał Miłecki wrote: > > I'm providing extra version info of tested firmware images as requested > > by Arend in another e-mail thread. > > Looking into our firmware repo it there are two flags, ie. WL_MONITOR > and WL_RADIOTAP. It seems both are set for firmware containing -stamon- > feature. Your list below confirms that. I still plan to add indication > for WL_RADIOTAP in the "cap" iovar, but a stamon feature check could be > used for older firmwares. The problem is that there isn't a direct mapping between what's visible with the "tail" command and what firmware returns for the "cap" iovar. Just to be sure I bumped #define MAX_CAPS_BUFFER_SIZE to 1024. Firmware that has "stamon" when checked with "tail" command doesn't report "stamon" over "cap" iovar. So I can't detect if firmware was compiled with WL_MONITOR and WL_RADIOTAP using "cap" iovar.
Re: [PATCH v2 2/2] mac80211: last ack signal support in station dump
On 2018-06-15 17:13, Johannes Berg wrote:
On Mon, 2018-06-04 at 19:41 +0530, Balaji Pothunoori wrote:
+ if (ieee80211_hw_check(>local->hw, REPORTS_TX_ACK_STATUS)) {
+ if (sta->status_stats.ack_signal_filled && ((!(sinfo->filled &
+ BIT_ULL(NL80211_STA_INFO_ACK_SIGNAL))) ||
+ (!(sinfo->filled &
+ BIT_ULL(NL80211_STA_INFO_ACK_SIGNAL_AVG) {
Uh, wow, the indentation here is awful - please break with && and || on
the end of line and indent properly according to the nesting level.
If a line ends up being longer than 80, I think that's better than this
monster expression :)
Sure , i will modify in v3.
+ sinfo->ack_signal =
+ sta->status_stats.last_ack_signal;
+ sinfo->filled |=
+ BIT_ULL(NL80211_STA_INFO_ACK_SIGNAL);
+ sinfo->avg_ack_signal =
+ -(s8)ewma_avg_signal_read(
>status_stats.avg_ack_signal);
- sinfo->filled |=
- BIT_ULL(NL80211_STA_INFO_DATA_ACK_SIGNAL_AVG);
+ sinfo->filled |=
+ BIT_ULL(NL80211_STA_INFO_ACK_SIGNAL_AVG);
+ }
Clearly your previous patch would even break the kernel compile since
the DATA_ACK_SIGNAL_AVG is still used here.
Here i have used "NL80211_STA_INFO_ACK_SIGNAL_AVG" not as
"NL80211_STA_INFO_DATA_ACK_SIGNAL_AVG".
Finally, please also explain why you're adding this feature, at least
in
the cover letter ("PATCH 0/2"), I can reuse that as a merge commit
message if necessary.
Sure, i will update in v3.
johannes
Regards,
Balaji.
Re: [PATCH v2 1/2] cfg80211: last ack signal support in station dump
On 2018-06-15 17:11, Johannes Berg wrote:
On Mon, 2018-06-04 at 19:41 +0530, Balaji Pothunoori wrote:
+++ b/include/uapi/linux/nl80211.h
@@ -3000,8 +3000,8 @@ enum nl80211_sta_bss_param {
* received from the station (u64, usec)
* @NL80211_STA_INFO_PAD: attribute used for padding for 64-bit
alignment
* @NL80211_STA_INFO_ACK_SIGNAL: signal strength of the last ACK
frame(u8, dBm)
- * @NL80211_STA_INFO_DATA_ACK_SIGNAL_AVG: avg signal strength of
(data)
- * ACK frame (s8, dBm)
+ * @NL80211_STA_INFO_ACK_SIGNAL_AVG: avg signal strength of data or
management
+ * ACK frames(s8, dBm)
* @__NL80211_STA_INFO_AFTER_LAST: internal
* @NL80211_STA_INFO_MAX: highest possible station info attribute
*/
@@ -3041,7 +3041,7 @@ enum nl80211_sta_info {
NL80211_STA_INFO_RX_DURATION,
NL80211_STA_INFO_PAD,
NL80211_STA_INFO_ACK_SIGNAL,
- NL80211_STA_INFO_DATA_ACK_SIGNAL_AVG,
+ NL80211_STA_INFO_ACK_SIGNAL_AVG,
Wait, what happened here? You can't remove old API.
Here is my intention is to make the unique average ack signal and last
ack signal
support in station dump irrespective of data or management tx ack
packet.
Do you want me to add a new API for management tx ack packet?
@@ -5128,9 +5128,9 @@ enum nl80211_feature_flags {
* "radar detected" event.
* @NL80211_EXT_FEATURE_CONTROL_PORT_OVER_NL80211: Driver supports
sending and
* receiving control port frames over nl80211 instead of the
netdevice.
- * @NL80211_EXT_FEATURE_DATA_ACK_SIGNAL_SUPPORT: This Driver support
data ack
- * rssi if firmware support, this flag is to intimate about ack rssi
- * support to nl80211.
+ * @NL80211_EXT_FEATURE_ACK_SIGNAL_SUPPORT: This Driver support ack
rssi if
+ * firmware support, this flag is to intimate about ack rssi support
+ * to nl80211.
Same here, why are you removing the data-ack-signal API?
Is that just a rebase error or something?
Or is it intentional, but then please explain what you're trying to do
and I can help find a correct solutions.
johannes
Here i renamed above API because in driver i will fill this
"NL80211_EXT_FEATURE_ACK_SIGNAL_SUPPORT"
if firmware supports either of the one "WMI_SERVICE_TX_DATA_ACK_RSSI" or
"WMI_SERVICE_HTT_MGMT_TX_COMP_VALID_FLAGS".
This is to make unique avg ack signal/last ack signal support.
Regards,
Balaji.
Re: MAINTAINERS: update Xinming's email address
Xinming Hu wrote: > I'd like to use this new gmail from now on. > > Cc: Ganapathi Bhat > Signed-off-by: Xinming Hu Patch applied to wireless-drivers.git, thanks. 755abd247a3d MAINTAINERS: update Xinming's email address -- https://patchwork.kernel.org/patch/10456899/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] NFC: fdp: Fix unused variable warnings
Hi Amit,
On Tue, Jun 12, 2018 at 07:44:10PM +0530, Amit Pundir wrote:
> Fix unused variable warnings reported on next-20180612.
>
> Fixes: 7579d009c4a1 ("NFC: fdp: Remove __func__ from dev_dbg()")
> Signed-off-by: Amit Pundir
> ---
> drivers/nfc/fdp/fdp.c | 13 -
> 1 file changed, 13 deletions(-)
Applied to nfc-next, thanks.
Cheers,
Samuel.
Re: [PATCH v3 5/5] staging: use BIT_ULL for NL80211_STA_INFO_* attribute types
On Mon, Jun 18, 2018 at 10:29:43AM +0300, Kalle Valo wrote: > Greg KH writes: > > > On Sun, Jun 17, 2018 at 01:07:36PM +0300, Omer Efrat wrote: > >> The BIT macro uses unsigned long which some architectures handle as 32 bit > >> and therefore might cause macro's shift to overflow when used on a value > >> equals or larger than 32 (NL80211_STA_INFO_RX_DURATION and afterwards). > >> > >> Since 'filled' member in station_info changed to u64, BIT_ULL macro > >> should be used with all NL80211_STA_INFO_* attribute types instead of BIT > >> to prevent future possible bugs when one will use BIT macro for higher > >> attributes by mistake. > >> > >> This commit cleans up all usages of BIT macro with the above field > >> in cfg80211 by changing it to BIT_ULL instead. > >> > >> Signed-off-by: Omer Efrat > > > > Acked-by: Greg Kroah-Hartman > > Via which tree is this supposed to go? Not mine :) Have fun with it! greg k-h
Re: [PATCH v3 5/5] staging: use BIT_ULL for NL80211_STA_INFO_* attribute types
Greg KH writes: > On Sun, Jun 17, 2018 at 01:07:36PM +0300, Omer Efrat wrote: >> The BIT macro uses unsigned long which some architectures handle as 32 bit >> and therefore might cause macro's shift to overflow when used on a value >> equals or larger than 32 (NL80211_STA_INFO_RX_DURATION and afterwards). >> >> Since 'filled' member in station_info changed to u64, BIT_ULL macro >> should be used with all NL80211_STA_INFO_* attribute types instead of BIT >> to prevent future possible bugs when one will use BIT macro for higher >> attributes by mistake. >> >> This commit cleans up all usages of BIT macro with the above field >> in cfg80211 by changing it to BIT_ULL instead. >> >> Signed-off-by: Omer Efrat > > Acked-by: Greg Kroah-Hartman Via which tree is this supposed to go? -- Kalle Valo
