kernel.git/drivers/net/wireless/quantenna/qtnfmac/core.h, branch master

wifi: qtnfmac: fix spelling error in core.h

2024-12-12T18:01:33Z

Fix specific spelling error in core.h. Signed-off-by: Liu Jing Signed-off-by: Kalle Valo Link: https://patch.msgid.link/20241209062425.4139-1-liujing@cmss.chinamobile.com

wifi: qtnfmac: don't include lib80211.h

2024-10-08T19:52:16Z

This driver doesn't use it, and really can't, so don't include lib80211.h. Link: https://patch.msgid.link/20241007202706.d92615cbf659.I2dc8ea3df0760121dc202616bdf3942caf51b232@changeid Signed-off-by: Johannes Berg

qtnfmac: switch to core handling of rx/tx byte/packet counters

2020-11-12T22:58:27Z

Use netdev->tstats instead of a member of qtnf_vif for storing a pointer to the per-cpu counters. This allows us to use core functionality for statistics handling. The driver sets netdev->needs_free_netdev, therefore freeing the per-cpu counters at the right point in time is a little bit tricky. Best option seems to be to use the ndo_init/ndo_uninit callbacks. Signed-off-by: Heiner Kallweit Acked-by: Kalle Valo Signed-off-by: Jakub Kicinski

qtnfmac: assign each wiphy to its own virtual platform device

2020-03-12T13:38:58Z

Quantenna Pearl device exposes multiple (up to 3) radio interfaces under single PCIe function. So far all the wiphy devices were attached to the same pcie device. As a result, all different wireless network devices were reported under the same sysfs directory for pcie device, e.g.: $ ls /sys/class/net/wlan0/device/net/ wlan0 wlan1 It turns out that such behavior may confuse various users of wireless subsystem. For instance, it turned out to be the case for: - Linux init systems, e.g. for renaming based on parent device - OpenWRT configuration scripts Suggested solution is to add an intermediate virtual platform device for each radio interface. Signed-off-by: Sergey Matyukevich Signed-off-by: Kalle Valo

qtnfmac: pass max scan SSIDs limit on per-radio basis

2020-02-12T16:16:45Z

Each radio on a given wifi device may have different max scan SSIDs limitation, so take this information from a per-radio info structure. Signed-off-by: Igor Mitsyanko Signed-off-by: Kalle Valo

qtnfmac: implement extendable channel survey dump

2020-02-12T16:16:44Z

Switch to extendable implementation of channel survey dump to make sure that any new channel statistics can be added in the future without any backwards compatibility issues. For this purpose use a separate variable length bitmap to pass the list of valid statistics in firmware response. Besides, switch to using channel frequency instead of IEEE channel number to prepare for adding support of 6GHz band. Signed-off-by: Igor Mitsyanko Signed-off-by: Kalle Valo

qtnfmac: merge PHY_PARAMS_GET into MAC_INFO

2020-02-12T16:16:41Z

QLINK_CMD_PHY_PARAMS_GET command does not need to be separate, it can be included into GET_MAC_INFO command. Merge these two commands adding all the missing wiphy data. Signed-off-by: Igor Mitsyanko Signed-off-by: Kalle Valo

qtnfmac: pass hardware capabilities in TLV element

2020-02-12T16:16:40Z

To support any number of capabilities bits in the future, replace u32 capabilities bitmask by array. Pass capabilities from firmware using TLV element. Signed-off-by: Igor Mitsyanko Signed-off-by: Kalle Valo

qtnfmac: use MAJOR.MINOR format for firmware protocol

2020-02-12T16:16:39Z

Use MAJOR.MINOR format for QLink firmware protocol. MAJOR part is incremented when backward compatibility is broken. Normally this part should not be incremented unless there is a good reason for that. MINOR part is incremented each time when new features are added to qlink.h, e.g. new TLVs, events, commands. These changes should not break backward compatibility. For instance, older firmware versions may not be able to parse new flags or send new types of events, but this does not impact normal system operations. As part of initialization sequence, driver requests protocol version from firmware and refuses to start in case there is a mismatch in MAJOR part of the version. Signed-off-by: Igor Mitsyanko Signed-off-by: Kalle Valo

qtnfmac: add module param to configure DFS offload

2020-01-26T15:43:58Z

Firmware may support DFS offload. However the final decision on whether to use it or not should be up to the user. So even if firmware supports DFS offload, it should be enabled only if user explicitly requests it. For this purpose introduce kernel param dfs_offload which is disabled by default. Signed-off-by: Sergey Matyukevich Signed-off-by: Kalle Valo