Signed-off-by: Tobias Schramm
---
include/linux/pci_ids.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index ab20dc5db423..6b01ac1e9bce 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -149,6 +149,8 @@
#define PCI_VE
Some modern Ubiquiti devices contain a rebranded QCA988X rev2 with
a custom Ubiquiti vendor and device id. This patch adds support for
those devices, treating them as a QCA988X v2.
Signed-off-by: Tobias Schramm
---
drivers/net/wireless/ath/ath10k/core.c | 24
drivers/net
A lot of more modern Ubiquiti AirMAX wireless devices contain a rebranded
QCA988X with changed PCI vendor and device id.
This patch adds support for those chips by treating them as QCA988X rev2
radios.
Changes since v1:
* Send patch to more people and lists
Tobias Schramm (2):
pci: Add vendor
Ganapathi Bhat wrote:
> From: Shrenik Shikhare
>
> There is a race condition for acquiring rx_proc_lock between
> rx worker thread and USB RX data interrupt
> (mwifiex_usb_rx_complete):
>
> 1. USB receives an RX data interrupt, queues rx_work
> 2. rx_work empties rx_data_q, tries to acquire rx
Ganapathi Bhat wrote:
> From: Shrenik Shikhare
>
> There is race for data_received flag between main thread and
> RX data interrupt(mwifiex_usb_rx_complete()):
> 1. USB received an RX data interrupt, set data_received flag
> 2. main thread checks data_received, if set queues rx_work
> 3. rx wor
Kalle Valo writes:
> Ganapathi Bhat wrote:
>
>> From: Shrenik Shikhare
>>
>> There is a race condition for acquiring rx_proc_lock between
>> rx worker thread and USB RX data interrupt
>> (mwifiex_usb_rx_complete):
>>
>> 1. USB receives an RX data interrupt, queues rx_work
>> 2. rx_work emptie
Ramon Fried wrote:
> wcn36xx_dxe_init() doesn't check for the return value of
> wcn36xx_dxe_init_descs(), release the resources in case an error ocurred.
>
> Signed-off-by: Ramon Fried
> Signed-off-by: Kalle Valo
Patch applied to ath-next branch of ath.git, thanks.
d0bb950b9f5f wcn36xx: rele
Wojciech Dubowik wrote:
> AR9003 factory calibration allows to use bigger EEPROM than
> standard 1k without changing the default layout. Allow
> probing of EEPROM at alternative address if initial check
> for default fails.
> The original ar9003 eeprom ops are still be used.
>
> Signed-off-by: W
Maya Erez wrote:
> PCIe device ID has changed in Talyn.
> Add this ID to wil6210_pcie_ids list to allow
> recognition of Talyn device.
>
> Signed-off-by: Maya Erez
> Signed-off-by: Kalle Valo
8 patches applied to ath-next branch of ath.git, thanks.
10cd2d45f6c7 wil6210: add Talyn PCIe device
Felix Fietkau wrote:
> Sometimes the hardware will push small packets that trigger a WARN_ON
> in mac80211. Discard them early to avoid this issue.
>
> Reported-by: Stijn Tintel
> Signed-off-by: Felix Fietkau
> Signed-off-by: Kalle Valo
Patch applied to ath-next branch of ath.git, thanks.
3
On Mon, 2018-01-22 at 13:00 +, kbuild test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.gi
> t master
> head: 076dc671ee9fa374e77c3d05925dafb75b23a74c
> commit: c179e91512cab01e83be35a60eaeda0f170a9101 [3/5] cfg80211: wext: don't
> use static stru
From: Ping-Ke Shih
Add 'static' or declaration to resolve the warnings, and remove two unused
functions halbtc_set_macreg() and halbtc_get_macreg() exposed when they
were made static.
Signed-off-by: Ping-Ke Shih
---
The original subject of this patch is '[PATCH 07/10]' in previous
patchset, and
From: Peter Oh
mesh TTL offset in Mesh Channel Switch Parameters element depends on
not only Secondary Channel Offset element, but also affected by
HT Control field and Wide Bandwidth Channel Switch element.
Use element structure to correct the miscalculation.
Signed-off-by: Peter Oh
---
net/m
From: Ryan Hsu
In the case of Station connects to AP with narrower bandwidth at beginning.
And later the AP changes the bandwidth to winder bandwidth, the AP will
beacon with wider bandwidth IE, eg VHT20->VHT40->VHT80 or VHT40->VHT80.
Since the supported BANDWIDTH will be limited by the PHYMODE,
Hello,
Can wiphy_apply_custom_regulatory() be called after wiphy registeration?
The documentation(comment) says "/* Used by drivers prior to wiphy
registration */"
Whys is there a restriction to call this after registration? Is the
comment outdated? After Tracing the regulatory code in the cfg8021
On 2018-01-24 17:20, Johannes Berg wrote:
> On Wed, 2018-01-24 at 17:11 +0100, Felix Fietkau wrote:
>>
>> I guess I will have to look into fragmentation. I have a second driver
>> pending that only reports the CCMP PN outside of the packet, and for
>> performance reasons I really don't want to tra
On Wed, 2018-01-24 at 17:11 +0100, Felix Fietkau wrote:
>
> I guess I will have to look into fragmentation. I have a second driver
> pending that only reports the CCMP PN outside of the packet, and for
> performance reasons I really don't want to translate it and move it to a
> place where mac8021
On 2018-01-24 16:56, Johannes Berg wrote:
> On Wed, 2018-01-24 at 16:19 +0100, Felix Fietkau wrote:
>> Apparently hardware does not perform CCMP PN validation in hardware, so
>> we need to take care of this in the driver. This is important for
>> protecting against replay attacks
>>
>> +static int
Arend Van Spriel wrote:
> The protocol layer api defines callbacks for dongle commands.
> Although not really well documented these should only return an
> error code in case of an error, or 0 upon success. In the bcdc
> protocol it can return value above 0 and we carry a fix in the
> caller of t
Sergey Matyukevich wrote:
> From: Vasily Ulyanov
>
> TLV is used to pass ACL data to firmware in start_ap cfg80211 callback.
> Use the same approach in set_mac_acl cfg80211 callback.
>
> Signed-off-by: Vasily Ulyanov
11 patches applied to wireless-drivers-next.git, thanks.
33f9899234a2 qtnf
On Wed, 2018-01-24 at 16:19 +0100, Felix Fietkau wrote:
> Apparently hardware does not perform CCMP PN validation in hardware, so
> we need to take care of this in the driver. This is important for
> protecting against replay attacks
>
> +static int
> +mt76_check_ccmp_pn(struct sk_buff *skb)
> +{
Luis de Bethencourt wrote:
> The trailing semicolon is an empty statement that does no operation.
> Removing it since it doesn't do anything.
>
> Signed-off-by: Luis de Bethencourt
> Acked-by: Jes Sorensen
Patch applied to wireless-drivers-next.git, thanks.
8054a275de08 rtl8xxxu: Fix trailin
Pkshih writes:
> On Mon, 2018-01-22 at 13:10 -0600, Larry Finger wrote:
>> On 01/19/2018 12:45 AM, pks...@realtek.com wrote:
>> >
>> > From: Ping-Ke Shih
>> >
>> > The field spec_ver is IC's specification mask for common code to do proper
>> > process to specified IC. This commit add a field n
Ping-Ke Shih wrote:
> From: Ping-Ke Shih
>
> The rtlwifi newer ICs support 80M bandwidth in 5G band, so extend
> get_wifi_bw() to know bandwidth 80M that helps btcoex to make correct
> decisions.
>
> Signed-off-by: Ping-Ke Shih
> Acked-by: Larry Finger
9 patches applied to wireless-drivers-
Ping-Ke Shih wrote:
> From: Ping-Ke Shih
>
> Add 'static' or declaration to resolve the warnings.
>
> Signed-off-by: Ping-Ke Shih
Dropping this patch 7 per comments, but I'll try to take the rest (if
they apply).
Patch set to Changes Requested.
--
https://patchwork.kernel.org/patch/101746
Sending frames to mac80211 needs time, which could allow for more rx
packets to end up in the DMA ring. Retry polling until there are no more
frames left. Improves rx latency under load.
Signed-off-by: Felix Fietkau
---
drivers/net/wireless/mediatek/mt76/dma.c | 10 +++---
1 file changed, 7
Apparently hardware does not perform CCMP PN validation in hardware, so
we need to take care of this in the driver. This is important for
protecting against replay attacks
Signed-off-by: Felix Fietkau
---
drivers/net/wireless/mediatek/mt76/mac80211.c| 51
drivers/net
Preparation for passing in more internal rx data via skb->cb
Signed-off-by: Felix Fietkau
---
drivers/net/wireless/mediatek/mt76/mac80211.c | 29 -
drivers/net/wireless/mediatek/mt76/mt76.h | 13 +++
drivers/net/wireless/mediatek/mt76/mt76x2_mac.c | 4 ++-
Add a separate function for processing frames after A-MPDU reordering,
reduce code duplication
Signed-off-by: Felix Fietkau
---
drivers/net/wireless/mediatek/mt76/agg-rx.c | 8 +---
drivers/net/wireless/mediatek/mt76/dma.c | 2 +-
drivers/net/wireless/mediatek/mt76/mac80211.c | 24 +
Preparation for adding software rx CCMP PN validation
Signed-off-by: Felix Fietkau
---
drivers/net/wireless/mediatek/mt76/mt76x2.h | 1 +
drivers/net/wireless/mediatek/mt76/mt76x2_mac.c | 15 ---
drivers/net/wireless/mediatek/mt76/mt76x2_main.c | 1 +
3 files changed, 14 inse
Avoids the rhashtable lookup based on the MAC address inside mac80211
Signed-off-by: Felix Fietkau
---
drivers/net/wireless/mediatek/mt76/dma.c | 4
drivers/net/wireless/mediatek/mt76/mac80211.c| 9 ++---
drivers/net/wireless/mediatek/mt76/mt76.h| 14 ++
Like beacons, probe responses need a hardware-generated TSF value. Set
the flag that causes the hw to generate it
Signed-off-by: Felix Fietkau
---
drivers/net/wireless/mediatek/mt76/mt76x2_mac.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mediate
This is required for performing CCMP PN validation in software
Signed-off-by: Felix Fietkau
---
drivers/net/wireless/mediatek/mt76/Makefile | 2 +-
drivers/net/wireless/mediatek/mt76/agg-rx.c | 264 +++
drivers/net/wireless/mediatek/mt76/mac80211.c| 11 +-
dr
Lorenzo Bianconi wrote:
> There is a possible race in mt76x2_stop_hardware() since pre_tbtt and
> dfs tasklets could run during driver cleanup. Fix it disabling all
> pending tasklets during device removal
>
> Signed-off-by: Lorenzo Bianconi
> Acked-by: Felix Fietkau
Patch applied to wireless
Lorenzo Bianconi wrote:
> Substitute tasklet_kill with tasklet_disable/tasklet_enable in order to
> guarantee dfs tasklet can not be executed during dfs parameter
> initialization
>
> Signed-off-by: Lorenzo Bianconi
3 patches applied to wireless-drivers-next.git, thanks.
8c9f6491a313 mt76x2:
Felix Fietkau wrote:
> Hardware encryption seems to break encrypted unicast mgmt tx.
> Unfortunately the hardware TXWI header does not have a bit to indicate
> that a frame is software encrypted, so sw-encrypted frames need to use a
> different WCID. For that to work, the CCMP PN needs to be gene
Lorenzo Bianconi wrote:
> Fix hw queue configuration since mt76x2 devices use a reverse queue
> enumeration respect to mac80211 one:
> - 0: AC_BE
> - 1: AC_BK
> - 2: AC_VI
> - 3: AC_VO
>
> The issue can be reproduced sending two concurrent flow using
> two separate queues:
> - VO: 20Mbps UD
Ramon Fried writes:
> wcn36xx_dxe_init() doesn't check for the return value
> of wcn36xx_dxe_init_descs().
> This patch releases the resources in case an error ocurred.
>
> Change-Id: I924bd7489b60243c0a0cbaa716caf924f11d7587
> Signed-off-by: Ramon Fried
This compiled now, thanks. But I did som
On 2018-01-22 17:52, Johannes Berg wrote:
On Thu, 2018-01-18 at 18:10 +0530, Venkateswara Naralasetty wrote:
From: Bhagavathi Perumal S
This patch provides support for users to get ack signal
strength of last transmitted by introducing new attribute
'NL80211_STA_INFO_ACK_SIGNAL'.
No real obj
On Wed, 2018-01-24 at 10:39 +0100, Benjamin Beichler wrote:
> sorry for introducing that error, but I'm a bit confused by the
> workqueue documentation.
> My assumption was, that deleting hwsim radios is reclaiming memory, and
> since this queue does nothing else it would save/necessary to set thi
Hi
So if 3.9 works and current kernel does not, the best way to address
the issue would be identify change that broke. Ideally if bisecton
could be performed, but this can be hard taking that the problem is not
easy reproducible. Further difficultly comes from a fact that OpenWRT
has custom patch
Hi Johannes,
sorry for introducing that error, but I'm a bit confused by the
workqueue documentation.
My assumption was, that deleting hwsim radios is reclaiming memory, and
since this queue does nothing else it would save/necessary to set this flag.
Maybe a hint in the documentation, that a work
Hi,
> I get this oops in 4.15rc9 when doing the following:
>
> # iw dev wlp2s0 set type ibss
> # ip link set dev wlp2s0 up
> # iw dev wlp2s0 ibss join "TEST" 2412
>
> The oops happens after some delay (approx. 5 seconds).
>
> Hardware is:
>
> 02:00.0 Network controller: Intel Corporation Wirel
Hello!
I can confirm - there is no firmware being uploaded to the device, or at least:
if it's there, it's not uploaded from an external file.
root@smalltalk:~# ls -Fa -1 /lib/firmware/
./
../
regulatory.db
root@smalltalk:~#
Anything I might do? I can also give an ssh session to the device in ca
I get this oops in 4.15rc9 when doing the following:
# iw dev wlp2s0 set type ibss
# ip link set dev wlp2s0 up
# iw dev wlp2s0 ibss join "TEST" 2412
The oops happens after some delay (approx. 5 seconds).
Hardware is:
02:00.0 Network controller: Intel Corporation Wireless 8265 / 8275 (rev 78)
pc
AR9003 series allows to calibrate noise floor for different frequency
bins. Once it's done it's possible to get more accurate rssi/signal
values over whole frequency band at a given temperature.
The RSSI/signal accuracy reported by calibrated RF cards improves
from 6 to up to 2dB.
This could be in
Display per frequency calibration data in dump_modal
debugfs entry including reference power, voltage,
tx temperature and noise floor.
Example of chain 0 of OEM card (dump from modal_eeprom):
Chain 0
Freq refvolttempnf_Cal nf_Pow rx_temp
5180-30 0 137 0 0
AR9003 series allows to calibrate noise floor for different frequency
bins. Once it's done it's possible to get more accurate rssi/signal
values over whole frequency band at a given temperature.
The RSSI/signal accuracy reported by calibrated RF cards improves
from 6 to up to 2dB.
This could be in
AR9003 factory calibration allows to use bigger EEPROM than
standard 1k without changing the default layout. Allow
probing of EEPROM at alternative address if initial check
for default fails.
The original ar9003 eeprom ops are still be used.
Signed-off-by: Wojciech Dubowik
---
drivers/net/wirele
AR9003 devices can have calibrated noise floor values
which can be used instead of hard coded one. Read them
from eeprom and save interpolated value in nf limits for
the current channel.
Signed-off-by: Wojciech Dubowik
---
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 63 +
50 matches
Mail list logo
