- 21 Dec, 2018 9 commits
-
-
David S. Miller authored
Merge tag 'wireless-drivers-next-for-davem-2018-12-20' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next Kalle Valo says: ==================== wireless-drivers-next patches for 4.21 Last set of patches for 4.21. mt76 is still in very active development and having some refactoring as well as new features. But also other drivers got few new features and fixes. Major changes: ath10k * add amsdu support for QCA6174 monitor mode * report tx rate using the new ieee80211_tx_rate_update() API * wcn3990 support is not experimental anymore iwlwifi * support for FW version 43 for 9000 and 22000 series brcmfmac * add support for CYW43012 SDIO chipset * add the raw 4354 PCIe device ID for unprogrammed Cypress boards mwifiex * add NL80211_STA_INFO_RX_BITRATE support mt76 * use the same firmware for mt76x2e and mt76x2u * mt76x0e survey support * more unification between mt76x2 and mt76x0 * mt76x0e AP mode support * mt76x0e DFS support * rework and fix tx status handling for mt76x0 and mt76x2 ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Stephen Hemminger authored
Don't need extern prefix before function prototypes. Checkpatch has complained about this for a couple of years. Signed-off-by: Stephen Hemminger <stephen@networkplumber.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Ido Schimmel says: ==================== net: ipv4: Prevent user triggerable warning Patch #1 prevents a user triaggerable warning in the flow dissector by setting 'skb->dev' in skbs used for IPv4 output route get requests. Patch #2 adds a test case that triggers the warning without the first patch. I have audited all the RTM_GETROUTE handlers and could not find any other callpath where an skb is passed to the flow dissector with both 'skb->dev' and 'skb->sk' cleared. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ido Schimmel authored
Without previous patch a warning would be generated upon multipath route get when FIB multipath hash policy is to use a 5-tuple for multipath hash calculation. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ido Schimmel authored
When user requests to resolve an output route, the kernel synthesizes an skb where the relevant parameters (e.g., source address) are set. The skb is then passed to ip_route_output_key_hash_rcu() which might call into the flow dissector in case a multipath route was hit and a nexthop needs to be selected based on the multipath hash. Since both 'skb->dev' and 'skb->sk' are not set, a warning is triggered in the flow dissector [1]. The warning is there to prevent codepaths from silently falling back to the standard flow dissector instead of the BPF one. Therefore, instead of removing the warning, set 'skb->dev' to the loopback device, as its not used for anything but resolving the correct namespace. [1] WARNING: CPU: 1 PID: 24819 at net/core/flow_dissector.c:764 __skb_flow_dissect+0x314/0x16b0 ... RSP: 0018:ffffa0df41fdf650 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff8bcded232000 RCX: 0000000000000000 RDX: ffffa0df41fdf7e0 RSI: ffffffff98e415a0 RDI: ffff8bcded232000 RBP: ffffa0df41fdf760 R08: 0000000000000000 R09: 0000000000000000 R10: ffffa0df41fdf7e8 R11: ffff8bcdf27a3000 R12: ffffffff98e415a0 R13: ffffa0df41fdf7e0 R14: ffffffff98dd2980 R15: ffffa0df41fdf7e0 FS: 00007f46f6897680(0000) GS:ffff8bcdf7a80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055933e95f9a0 CR3: 000000021e636000 CR4: 00000000001006e0 Call Trace: fib_multipath_hash+0x28c/0x2d0 ? fib_multipath_hash+0x28c/0x2d0 fib_select_path+0x241/0x32f ? __fib_lookup+0x6a/0xb0 ip_route_output_key_hash_rcu+0x650/0xa30 ? __alloc_skb+0x9b/0x1d0 inet_rtm_getroute+0x3f7/0xb80 ? __alloc_pages_nodemask+0x11c/0x2c0 rtnetlink_rcv_msg+0x1d9/0x2f0 ? rtnl_calcit.isra.24+0x120/0x120 netlink_rcv_skb+0x54/0x130 rtnetlink_rcv+0x15/0x20 netlink_unicast+0x20a/0x2c0 netlink_sendmsg+0x2d1/0x3d0 sock_sendmsg+0x39/0x50 ___sys_sendmsg+0x2a0/0x2f0 ? filemap_map_pages+0x16b/0x360 ? __handle_mm_fault+0x108e/0x13d0 __sys_sendmsg+0x63/0xa0 ? __sys_sendmsg+0x63/0xa0 __x64_sys_sendmsg+0x1f/0x30 do_syscall_64+0x5a/0x120 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fixes: d0e13a14 ("flow_dissector: lookup netns by skb->sk if skb->dev is NULL") Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Steen Hegelund authored
When doing indirect access in the Ocelot chip, a command is setup, issued and then we need to poll until the result is ready. The polling timeout is specified in milliseconds in the datasheet and not in register access attempts. It is not a bug on the currently supported platform, but we observed that the code does not work properly on other platforms that we want to support as the timing requirements there are different. Signed-off-by: Steen Hegelund <steen.hegelund@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Colin Ian King authored
Currently the stray semicolon means that the final term in the addition is being missed. Fix this by removing it. Cleans up clang warning: net/core/neighbour.c:2821:9: warning: expression result unused [-Wunused-value] Fixes: 82cbb5c6 ("neighbour: register rtnl doit handler") Signed-off-by: Colin Ian King <colin.king@canonical.com> Acked-By: Roopa Prabhu <roopa@cumulusnetworks.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Tristram Ha authored
Port partitioning is done by enabling UNICAST_VLAN_BOUNDARY and changing the default port membership of 0x7f to other values such that there is no communication between ports. In KSZ9477 the member for port 1 is 0x41; port 2, 0x42; port 3, 0x44; port 4, 0x48; port 5, 0x50; and port 7, 0x60. Port 6 is the host port. Setting a zero value can be used to stop port from receiving. However, when UNICAST_VLAN_BOUNDARY is disabled and the unicast addresses are already learned in the dynamic MAC table, setting zero still allows devices connected to those ports to communicate. This does not apply to multicast and broadcast addresses though. To prevent these leaks and make the function of port membership consistent UNICAST_VLAN_BOUNDARY should never be disabled. Note that UNICAST_VLAN_BOUNDARY is enabled by default in KSZ9477. Fixes: b987e98e ("dsa: add DSA switch driver for Microchip KSZ9477") Signed-off-by: Tristram Ha <Tristram.Ha@microchip.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
When resolving the conflict wrt. the vxlan_fdb_update call in vxlan_changelink() I made the last argument false instead of true. Fix this. Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 20 Dec, 2018 31 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linuxDavid S. Miller authored
Saeed Mahameed says: ==================== mlx5-updates-2018-12-19 This series adds some misc updates and the support for tunnels over VLAN tc offloads. From Miroslav Lichvar, patches #1,2 1) Update timecounter at least twice per counter overflow 2) Extend PTP gettime function to read system clock From Gavi Teitz, patch #3 3) Increase VF representors' SQ size to 128 From Eli Britstein and Or Gerlitz, patches #4-10 4) Adds the capability to support tunnels over VLAN device. Patch 4 avoids crash for TC flow with egress upper devices Patch 5 refactors tunnel routing devs into a helper function Patch 6 avoids crash for TC encap flows with vlan on underlay Patches 7-8 refactor encap tunnel header preparing code. Patch 9 adds support for building VLAN tagged ETH header. Patch 10 adds support for tunnel routing to VLAN device. From Aviv, patches 11,12 to fix earlier VF lag series 5) Fix query_nic_sys_image_guid() error during init 6) Fix LAG requirement when CONFIG_MLX5_ESWITCH is off ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Ido Schimmel says: ==================== mlxsw: Two usability improvements This patchset contains two small improvements in the mlxsw driver. The first one, in patches #1-#2, relieves the user from the need to configure a VLAN interface and only later the corresponding VXLAN tunnel. The issue is explained in detail in the first patch. The second improvement is described below and allows the user to make use of VID 1 by having the driver use the reserved 4095 VID for untagged traffic. VLAN entries on a given port can be associated with either a bridge or a router. For example, if swp1.10 is assigned an IP address and swp1.20 is enslaved to a VLAN-unaware bridge, then both {Port 1, VID 10} and {Port 1, VID 20} would be associated with a filtering identifier (FID) of the correct type. In case swp1 itself is assigned an IP address or enslaved to a VLAN-unaware bridge, then a FID would be associated with {Port 1, VID 1}. Using VID 1 for this purpose means that VLAN devices with VID 1 cannot be created over mlxsw ports, as this VID is (ab)used as the default VLAN. Instead of using VID 1 for this purpose, we can use VID 4095 which is reserved for internal use and cannot be configured by either the 8021q or the bridge driver. Patches #3-#7 perform small and non-functional changes that finally allow us to switch to VID 4095 as the default VID in patch #8. Patch #9 removes the limitation about creation of VLAN devices with VID 1 over mlxsw ports. Patches #10-#11 add test cases. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ido Schimmel authored
Previous patches made it possible to setup VLAN devices with VID 1 over mlxsw ports. Verify this functionality actually works by conducting a simple router test over VID 1. Adding this test as a generic test since it can be run using veth pairs and it can also be useful for other physical devices where VID 1 was considered reserved (knowingly or not). Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Petr Machata <petrm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ido Schimmel authored
Previous patches made it possible to create VLAN devices with VID 1 over mlxsw ports. Adjust the test to verify such an operation succeeds. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Petr Machata <petrm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ido Schimmel authored
VID 1 is not reserved anymore, so remove the check that prevented the creation of VLAN devices with this VID over mlxsw ports. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Petr Machata <petrm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ido Schimmel authored
There is no need to abuse VID 1 anymore and we can instead use VID 4095 as the default VLAN, which will be configured on the port throughout its lifetime. The OVS join / leave functions are changed to enable VIDs 1-4094 (inclusive) instead of 2-4095. This because VID 4095 is now the default VLAN instead of 1. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Petr Machata <petrm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ido Schimmel authored
VLAN entries on a port can be associated with either a bridge VLAN or a router port. Before the VLAN entry is destroyed these associations need to be cleaned up. Currently, this is always invoked from the function which destroys the VLAN entry, but next patch is going to skip the destruction of the default entry when a port in unlinked from a LAG. The above does not mean that the associations should not be cleaned up, so add a helper that will be invoked from both call sites. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Petr Machata <petrm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ido Schimmel authored
Subsequent patches will need to access the default port VLAN. Since this VLAN will exist throughout the lifetime of the port, simply store it in the port's struct. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Petr Machata <petrm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ido Schimmel authored
The function allows flushing all the existing VLAN entries on a port. It is invoked when a port is destroyed and when it is unlinked from a LAG. In the latter case, when moving to the new default VLAN, there will not be a need to destroy the default VLAN entry. Therefore, add an argument that allows to control whether the default port VLAN should be destroyed or not. Currently it is always set to 'true'. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Petr Machata <petrm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ido Schimmel authored
Currently, the driver does not set the port's PVID when initializing a new port. This is because the driver is using VID 1 as PVID which is the firmware default. Subsequent patches are going to change the PVID the driver is setting when initializing a new port. Prepare for that by explicitly setting the port's PVID. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Petr Machata <petrm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ido Schimmel authored
Subsequent patches are going to replace the current default VID (1) with VLAN_N_VID - 1 (4095). Prepare for this conversion by replacing the hard-coded '1' with a define. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Petr Machata <petrm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ido Schimmel authored
Previous patch added the ability to offload a VXLAN tunnel used for L3 VNI when it is present in the VLAN-aware bridge before the corresponding VLAN interface is configured. This patch adds a test case to verify that. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ido Schimmel authored
In symmetric routing, the only two members in the VLAN corresponding to the L3 VNI are the router port and the VXLAN tunnel. In case the VXLAN device is already enslaved to the bridge and only later the VLAN interface is configured, the tunnel will not be offloaded. The reason for this is that when the router interface (RIF) corresponding to the VLAN interface is configured, it calls the core fid_get() API which does not check if NVE should be enabled on the FID. Instead, call into the bridge code which will check if NVE should be enabled on the FID. This effectively means that the same code path is used to retrieve a FID when either a local port or a router port joins the FID. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Reviewed-by: Petr Machata <petrm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queueDavid S. Miller authored
Jeff Kirsher says: ==================== Intel Wired LAN Driver Updates 2018-12-20 This series contains updates to e100, igb, ixgbe, i40e and ice drivers. I replaced spinlocks for mutex locks to reduce the latency on CPU0 for igb when updating the statistics. This work was based off a patch provided by Jan Jablonsky, which was against an older version of the igb driver. Jesus adjusts the receive packet buffer size from 32K to 30K when running in QAV mode, to stay within 60K for total packet buffer size for igb. Vinicius adds igb kernel documentation regarding the CBS algorithm and its implementation in the i210 family of NICs. YueHaibing from Huawei fixed the e100 driver that was potentially passing a NULL pointer, so use the kernel macro IS_ERR_OR_NULL() instead. Konstantin Khorenko fixes i40e where we were not setting up the neigh_priv_len in our net_device, which caused the driver to read beyond the neighbor entry allocated memory. Miroslav Lichvar extends the PTP gettime() to read the system clock by adding support for PTP_SYS_OFFSET_EXTENDED ioctl in i40e. Young Xiao fixed the ice driver to only enable NAPI on q_vectors that actually have transmit and receive rings. Kai-Heng Feng fixes an igb issue that when placed in suspend mode, the NIC does not wake up when a cable is plugged in. This was due to the driver not setting PME during runtime suspend. Stephen Douthit enables the ixgbe driver allow DSA devices to use the MII interface to talk to switches. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Steve Douthit authored
Use the mii_bus callbacks to address the entire clause 22/45 address space. Enables userspace to poke switch registers instead of a single PHY address. The ixgbe firmware may be polling PHYs in a way that is not protected by the mii_bus lock. This isn't new behavior, but as Andrew Lunn pointed out there are more addresses available for conflicts. Signed-off-by: Stephen Douthit <stephend@silicom-usa.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
-
Steve Douthit authored
Most dsa devices expect a 'struct mii_bus' pointer to talk to switches via the MII interface. While this works for dsa devices, it will not work safely with Linux PHYs in all configurations since the firmware of the ixgbe device may be polling some PHY addresses in the background. Signed-off-by: Stephen Douthit <stephend@silicom-usa.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
-
Kai-Heng Feng authored
I210 ethernet card doesn't wakeup when a cable gets plugged. It's because its PME is not set. Since commit 42eca230 ("PCI: Don't touch card regs after runtime suspend D3"), if the PCI state is saved, pci_pm_runtime_suspend() stops calling pci_finish_runtime_suspend(), which enables the PCI PME. To fix the issue, let's not to save PCI states when it's runtime suspend, to let the PCI subsystem enables PME. Fixes: 42eca230 ("PCI: Don't touch card regs after runtime suspend D3") Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
-
Young Xiao authored
If ice driver has q_vectors w/ active NAPI that has no rings, then this will result in a divide by zero error. To correct it I am updating the driver code so that we only support NAPI on q_vectors that have 1 or more rings allocated to them. See commit 13a8cd19 ("i40e: Do not enable NAPI on q_vectors that have no rings") for detail. Signed-off-by: Young Xiao <YangX92@hotmail.com> Acked-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
-
Miroslav Lichvar authored
This adds support for the PTP_SYS_OFFSET_EXTENDED ioctl. Cc: Richard Cochran <richardcochran@gmail.com> Cc: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Miroslav Lichvar <mlichvar@redhat.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Acked-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
-
Konstantin Khorenko authored
Out of bound read reported by KASan. i40iw_net_event() reads unconditionally 16 bytes from neigh->primary_key while the memory allocated for "neighbour" struct is evaluated in neigh_alloc() as tbl->entry_size + dev->neigh_priv_len where "dev" is a net_device. But the driver does not setup dev->neigh_priv_len and we read beyond the neigh entry allocated memory, so the patch in the next mail fixes this. Signed-off-by: Konstantin Khorenko <khorenko@virtuozzo.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
-
YueHaibing authored
Fix a static code checker warning: drivers/net/ethernet/intel/e100.c:1349 e100_load_ucode_wait() warn: passing zero to 'PTR_ERR' Signed-off-by: YueHaibing <yuehaibing@huawei.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
-
git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller authored
Lots of conflicts, by happily all cases of overlapping changes, parallel adds, things of that nature. Thanks to Stephen Rothwell, Saeed Mahameed, and others for their guidance in these resolutions. Signed-off-by: David S. Miller <davem@davemloft.net>
-
Vinicius Costa Gomes authored
Add some pointers to the definition of the CBS algorithm, and some notes about the limits of its implementation in the i210 family of controllers. Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
-
Jesus Sanchez-Palencia authored
Section 4.5.9 of the datasheet says that the total size of all packet buffers combined (TxPB 0 + 1 + 2 + 3 + RxPB + BMC2OS + OS2BMC) must not exceed 60KB. Today we are configuring a total of 62KB, so reduce the RxPB from 32KB to 30KB in order to respect that. The choice of changing RxPBSIZE here is mainly because it seems more correct to give more priority to the transmit packet buffers over the receiver ones when running in Qav mode. Also, the BMC2OS and OS2BMC sizes are already too short. Signed-off-by: Jesus Sanchez-Palencia <jesus.s.palencia@gmail.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
-
Jeff Kirsher authored
This change is based off of the work and suggestion of Jan Jablonsky <jan.jablonsky@thalesgroup.com>. The Watchdog workqueue in igb driver is scheduled every 2s for each network interface. That includes updating a statistics protected by spinlock. Function igb_update_stats in this case will be protected against preemption. According to number of a statistics registers (cca 60), processing this function might cause additional cpu load on CPU0. In case of statistics spinlock may be replaced with mutex, which reduce latency on CPU0. CC: Bernhard Kaindl <bernhard.kaindl@thalesgroup.com> CC: Jan Jablonsky <jan.jablonsky@thalesgroup.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
-
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.gitKalle Valo authored
ath.git patches for 4.21. Major changes: ath10k * add amsdu support for QCA6174 monitor mode * report tx rate using the new ieee80211_tx_rate_update() API * wcn3990 support is not experimental anymore
-
Bhagavathi Perumal S authored
Add wmi configuration cmd to configure base band(BB) power amplifier(PA) off timing values in hardware. The default PA off timings were fine tuned to make proper DFS radar detection in QCA reference design. If ODM uses different PA in their design, then the same default PA off timing values cannot be used, it requires different settling time to detect radar pulses very sooner and avoid radar detection problems. In that case it provides provision to select proper PA off timing values based on the PA hardware used. The PA component is part of FEM hardware and new device tree entry "ext-fem-name" is used to indentify the FEM hardware. And this wmi configuration cmd is enabled via wmi service flag "WMI_SERVICE_BB_TIMING_CONFIG_SUPPORT". Other way is to apply these values through calibration data, but recalibration of all boards out there might not be feasible. This change tested on firmware ver 10.2.4-1.0-00042 in QCA988X chipset. Signed-off-by: Bhagavathi Perumal S <bperumal@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Bhagavathi Perumal S authored
This adds new dt entry ext-fem-name, it is used by ath10k driver to select correct timing parameters and configure it in target wifi hardware. The Front End Module(FEM) normally includes tx power amplifier(PA) and rx low noise amplifier(LNA). The default timing parameters like tx end to PA off timing values were fine tuned for internal FEM used in reference design. And these timing values can not be same if ODM modifies hardware design with different external FEM. This DT entry helps to choose correct timing values in driver if different external FEM hardware used. Signed-off-by: Bhagavathi Perumal S <bperumal@codeaurora.org> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Bhagavathi Perumal S authored
In qcom,ath10k documentation, ath10k is used as node name in the example of pci based device. Normally, node name should be class of device and not the model name, so fix it to node name "wifi". And remove the property device_type pci since only pci bridges should have this property. Signed-off-by: Bhagavathi Perumal S <bperumal@codeaurora.org> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Zhi Chen authored
Memory of tx_stats was allocated when a STA was added. But it's not freed if the STA failed to be added to driver. This issue could be seen in MDK3 attack case when STA number reached the limit. Tested: QCA9984 with firmware ver 10.4-3.9.0.1-00005 Signed-off-by: Zhi Chen <zhichen@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-
Zhi Chen authored
There was a race condition in SMP that an ath10k_peer was created but its member sta was null. Following are procedures of ath10k_peer creation and member sta access in peer statistics path. 1. Peer creation: ath10k_peer_create() =>ath10k_wmi_peer_create() =>ath10k_wait_for_peer_created() ... # another kernel path, RX from firmware ath10k_htt_t2h_msg_handler() =>ath10k_peer_map_event() =>wake_up() # ar->peer_map[id] = peer //add peer to map #wake up original path from waiting ... # peer->sta = sta //sta assignment 2. RX path of statistics ath10k_htt_t2h_msg_handler() =>ath10k_update_per_peer_tx_stats() =>ath10k_htt_fetch_peer_stats() # peer->sta //sta accessing Any access of peer->sta after peer was added to peer_map but before sta was assigned could cause a null pointer issue. And because these two steps are asynchronous, no proper lock can protect them. So both peer and sta need to be checked before access. Tested: QCA9984 with firmware ver 10.4-3.9.0.1-00005 Signed-off-by: Zhi Chen <zhichen@codeaurora.org> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
-