- 07 Dec, 2022 18 commits
-
-
Paolo Abeni authored
Hariprasad Kelam says: ==================== CN10KB MAC block support OcteonTx2's next gen platform the CN10KB has RPM_USX MAC which has a different serdes when compared to RPM MAC. Though the underlying HW is different, the CSR interface has been designed largely inline with RPM MAC, with few exceptions though. So we are using the same CGX driver for RPM_USX MAC as well and will have a different set of APIs for RPM_USX where ever necessary. The RPM and RPM_USX blocks support a different number of LMACS. RPM_USX support 8 LMACS per MAC block whereas legacy RPM supports only 4 LMACS per MAC. with this RPM_USX support double the number of DMAC filters and fifo size. This patchset adds initial support for CN10KB's RPM_USX MAC i.e registering the driver and defining MAC operations (mac_ops). With these changes PF and VF netdev packet path will work and PF and VF netdev drivers are able to configure MAC features like pause frames,PFC and loopback etc. Also implements FEC stats for CN10K Mac block RPM and CN10KB Mac block RPM_USX and extends ethtool support for PF and VF drivers by defining get_fec_stats API to display FEC stats. ==================== Link: https://lore.kernel.org/r/20221205070521.21860-1-hkelam@marvell.comSigned-off-by:
Paolo Abeni <pabeni@redhat.com>
-
Hariprasad Kelam authored
CN10K silicon MAC block RPM and CN10KB silicon MAC block RPM_USX both support BASER and RSFEC modes. Also MAC (CGX) on OcteonTx2 silicon variants and MAC (RPM) on OcteonTx3 CN10K are different and FEC stats need to be read differently. CN10KB MAC block (RPM_USX) fec csr offsets are same as CN10K MAC block (RPM) mac_ops points to same fn(). Upper layer interface between RVU AF and PF netdev is kept same. Based on silicon variant appropriate fn() pointer is called to read FEC stats Signed-off-by:
Hariprasad Kelam <hkelam@marvell.com> Signed-off-by:
Sunil Kovvuri Goutham <sgoutham@marvell.com> Signed-off-by:
-
Hariprasad Kelam authored
This patch registers a callback for get_fec_stats such that FEC stats can be queried from the below command "ethtool -I --show-fec eth0" Signed-off-by:
-
Hariprasad Kelam authored
OcteonTx2's next gen platform the CN10KB has RPM_USX MAC which has a different serdes when compared to RPM MAC. Though the underlying HW is different, the CSR interface has been designed largely inline with RPM MAC, with few exceptions though. So we are using the same CGX driver for RPM_USX MAC as well and will have a different set of APIs for RPM_USX where ever necessary. The RPM and RPM_USX blocks support a different number of LMACS. RPM_USX support 8 LMACS per MAC block whereas legacy RPM supports only 4 LMACS per MAC. with this RPM_USX support double the number of DMAC filters and fifo size. This patch adds initial support for CN10KB's RPM_USX MAC i.e registering the driver and defining MAC operations (mac_ops). Adds the logic to configure internal loopback and pause frames and assign FIFO length to LMACS. Kernel reads lmac features like lmac type, autoneg, etc from shared firmware data this structure only supports 4 lmacs per MAC, this patch extends this structure to accommodate 8 lmacs. Signed-off-by:
-
Rakesh Babu Saladi authored
Most of the code in CGX/RPM driver assumes that max lmacs per given MAC as always, 4 and the number of MAC blocks also as 4. With this assumption, the max number of interfaces supported is hardcoded to 16. This creates a problem as next gen CN10KB silicon MAC supports 8 lmacs per MAC block. This patch solves the problem by using "max lmac per MAC block" value from constant csrs and uses cgx_cnt_max value which is populated based number of MAC blocks supported by silicon. Signed-off-by:
Rakesh Babu Saladi <rsaladi2@marvell.com> Signed-off-by:
-
Paolo Abeni authored
Oleksij Rempel says: ==================== net: dsa: microchip: add MTU support for KSZ8 series ==================== Link: https://lore.kernel.org/r/20221205052232.2834166-1-o.rempel@pengutronix.deSigned-off-by:
-
Oleksij Rempel authored
To make the code more comparable to KSZ9477 code, move DSA configurations to the same location. Signed-off-by:
Oleksij Rempel <o.rempel@pengutronix.de> Acked-by:
Arun Ramadoss <arun.ramadoss@microchip.com> Reviewed-by:
Vladimir Oltean <olteanv@gmail.com> Signed-off-by:
-
Oleksij Rempel authored
KSZ8795 and KSZ9477 compatible series of switches use global max frame size configuration register. So, enable MTU normalization for this reason. Signed-off-by:
-
Oleksij Rempel authored
Make MTU configurable on KSZ87xx and KSZ88xx series of switches. Before this patch, pre-configured behavior was different on different switch series, due to opposite meaning of the same bit: - KSZ87xx: Reg 4, Bit 1 - if 1, max frame size is 1532; if 0 - 1514 - KSZ88xx: Reg 4, Bit 1 - if 1, max frame size is 1514; if 0 - 1532 Since the code was telling "... SW_LEGAL_PACKET_DISABLE, true)", I assume, the idea was to set max frame size to 1532. With this patch, by setting MTU size 1500, both switch series will be configured to the 1532 frame limit. This patch was tested on KSZ8873. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Oleksij Rempel authored
Add ksz_rmw8(), it will be used in the next patch. Signed-off-by:
-
Oleksij Rempel authored
If we have global MTU configuration, it is enough to configure it on CPU port only. Signed-off-by:
-
Oleksij Rempel authored
There are no HW specific registers, so we can process all of them in one location. Signed-off-by:
-
Yuan Can authored
The np needs to be released through of_node_put() in the error handling path of mtk_wed_wo_hardware_init(). Fixes: 79968444 ("net: ethernet: mtk_wed: introduce wed wo support") Signed-off-by:
Yuan Can <yuancan@huawei.com> Reviewed-by:
Leon Romanovsky <leonro@nvidia.com> Link: https://lore.kernel.org/r/20221205034339.112163-1-yuancan@huawei.comSigned-off-by:
-
Lorenzo Bianconi authored
This patch adds reset parameter to mtk_wed_rx_ring_setup signature in order to align rx_ring_setup callback to tx_ring_setup one introduced in 'commit 23dca7a9 ("net: ethernet: mtk_wed: add reset to tx_ring_setup callback")' Co-developed-by:
Sujuan Chen <sujuan.chen@mediatek.com> Signed-off-by:
Lorenzo Bianconi <lorenzo@kernel.org> Reviewed-by:
Jakub Kicinski <kuba@kernel.org>
-
zhang songyi authored
Semicolons after "}" are not needed. Signed-off-by:
zhang songyi <zhang.songyi@zte.com.cn> Reviewed-by:
Jiri Pirko <jiri@nvidia.com> Link: https://lore.kernel.org/r/202212051422158113766@zte.com.cnSigned-off-by:
-
ye xingchen authored
Follow the advice of the Documentation/filesystems/sysfs.rst and show() should only use sysfs_emit() or sysfs_emit_at() when formatting the value to be returned to user space. Signed-off-by:
ye xingchen <ye.xingchen@zte.com.cn> Reviewed-by:
Martin Habets <habetsm.xilinx@gmail.com> Link: https://lore.kernel.org/r/202212051021451139126@zte.com.cnSigned-off-by:
-
Russell King (Oracle) authored
We currently have some complicated code in sfp_probe() which gets the I2C bus depending on whether the sfp node is DT or ACPI, and we use completely separate lookup functions. This could do with being in a separate function to make the code more readable, so move it to a new function, sfp_i2c_get(). We can also use fwnode_find_reference() to lookup the I2C bus fwnode before then decending into fwnode-type specific parsing. A future cleanup would be to move the fwnode-type specific parsing into the i2c layer, which is where it really should be. Signed-off-by:
Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Link: https://lore.kernel.org/r/E1p1WGJ-0098wS-4w@rmk-PC.armlinux.org.ukSigned-off-by:
-
Kees Cook authored
The memcpy() in ncsi_cmd_handler_oem deserializes nca->data into a flexible array structure that overlapping with non-flex-array members (mfr_id) intentionally. Since the mem_to_flex() API is not finished, temporarily silence this warning, since it is a false positive, using unsafe_memcpy(). Reported-by:
Joel Stanley <joel@jms.id.au> Link: https://lore.kernel.org/netdev/CACPK8Xdfi=OJKP0x0D1w87fQeFZ4A2DP2qzGCRcuVbpU-9=4sQ@mail.gmail.com/ Cc: Samuel Mendoza-Jonas <sam@mendozajonas.com> Signed-off-by:
Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20221202212418.never.837-kees@kernel.orgSigned-off-by:
-
- 06 Dec, 2022 7 commits
-
-
Paolo Abeni authored
Horatiu Vultur says: ==================== net: lan966x: Enable PTP on bridge interfaces Before it was not allowed to run ptp on ports that are part of a bridge because in case of transparent clock the HW will still forward the frames so there would be duplicate frames. Now that there is VCAP support, it is possible to add entries in the VCAP to trap frames to the CPU and the CPU will forward these frames. The first part of the patch series, extends the VCAP support to be able to modify and get the rule, while the last patch uses the VCAP to trap the ptp frames. ==================== Link: https://lore.kernel.org/r/20221203104348.1749811-1-horatiu.vultur@microchip.comSigned-off-by:
-
Horatiu Vultur authored
Currently lan966x, doesn't allow to run PTP over interfaces that are part of the bridge. The reason is when the lan966x was receiving a PTP frame (regardless if L2/IPv4/IPv6) the HW it would flood this frame. Now that it is possible to add VCAP rules to the HW, such to trap these frames to the CPU, it is possible to run PTP also over interfaces that are part of the bridge. Signed-off-by:
Horatiu Vultur <horatiu.vultur@microchip.com> Signed-off-by:
-
Horatiu Vultur authored
Add the function vcap_rule_get_key_u32 which allows to get the value and the mask of a key that exist on the rule. If the key doesn't exist, it would return error. Signed-off-by:
-
Horatiu Vultur authored
Add the function vcap_mod_rule which allows to update an existing rule in the vcap. It is required for the rule to exist in the vcap to be able to modify it. Signed-off-by:
-
Horatiu Vultur authored
Add function vcap_get_rule which returns a rule based on the internal rule id. The entire functionality of reading and decoding the rule from the VCAP was inside vcap_api_debugfs file. So move the entire implementation in vcap_api as this is used also by vcap_get_rule. Signed-off-by:
-
Lorenzo Bianconi authored
Since Wireless Ethernet Dispatcher is now available for mt7986 in mt76, enable hw flow support for MT7986 SoC. Signed-off-by:
-
Sudheer Mogilappagari authored
Add netlink based support for "ethtool -x <dev> [context x]" command by implementing ETHTOOL_MSG_RSS_GET netlink message. This is equivalent to functionality provided via ETHTOOL_GRSSH in ioctl path. It sends RSS table, hash key and hash function of an interface to user space. This patch implements existing functionality available in ioctl path and enables addition of new RSS context based parameters in future. Signed-off-by:
Sudheer Mogilappagari <sudheer.mogilappagari@intel.com> Link: https://lore.kernel.org/r/20221202002555.241580-1-sudheer.mogilappagari@intel.comSigned-off-by:
-
- 05 Dec, 2022 6 commits
-
-
Michael Walle authored
Rename the temperature sensors macros to match the names in the datasheet. Signed-off-by:
Michael Walle <michael@walle.cc> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Diana Wang authored
Rewrite nfp_net_set_rx_mode() to implement interface to delivery mc address and operations to firmware by using general mailbox for filtering multicast packets. The operations include add mc address and delete mc address. And the limitation of mc addresses number is 1024 for each net device. User triggers adding mc address by using command below: ip maddress add <mc address> dev <interface name> User triggers deleting mc address by using command below: ip maddress del <mc address> dev <interface name> Signed-off-by:
Diana Wang <na.wang@corigine.com> Signed-off-by:
Simon Horman <simon.horman@corigine.com> Reviewed-by:
-
ye xingchen authored
Follow the advice of the Documentation/filesystems/sysfs.rst and show() should only use sysfs_emit() or sysfs_emit_at() when formatting the value to be returned to user space. Signed-off-by:
Alex Elder <elder@linaro.org> Signed-off-by:
-
David S. Miller authored
Merge tag 'rxrpc-next-20221201-b' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs David Howells says: ==================== rxrpc: Increasing SACK size and moving away from softirq, parts 2 & 3 Here are the second and third parts of patches in the process of moving rxrpc from doing a lot of its stuff in softirq context to doing it in an I/O thread in process context and thereby making it easier to support a larger SACK table. The full description is in the description for the first part[1] which is already in net-next. The second part includes some cleanups, adds some testing and overhauls some tracing: (1) Remove declaration of rxrpc_kernel_call_is_complete() as the definition is no longer present. (2) Remove the knet() and kproto() macros in favour of using tracepoints. (3) Remove handling of duplicate packets from recvmsg. The input side isn't now going to insert overlapping/duplicate packets into the recvmsg queue. (4) Don't use the rxrpc_conn_parameters struct in the rxrpc_connection or rxrpc_bundle structs - rather put the members in directly. (5) Extract the abort code from a received abort packet right up front rather than doing it in multiple places later. (6) Use enums and symbol lists rather than __builtin_return_address() to indicate where a tracepoint was triggered for local, peer, conn, call and skbuff tracing. (7) Add a refcount tracepoint for the rxrpc_bundle struct. (8) Implement an in-kernel server for the AFS rxperf testing program to talk to (enabled by a Kconfig option). This is tagged as rxrpc-next-20221201-a. The third part introduces the I/O thread and switches various bits over to running there: (1) Fix call timers and call and connection workqueues to not hold refs on the rxrpc_call and rxrpc_connection structs to thereby avoid messy cleanup when the last ref is put in softirq mode. (2) Split input.c so that the call packet processing bits are separate from the received packet distribution bits. Call packet processing gets bumped over to the call event handler. (3) Create a per-local endpoint I/O thread. Barring some tiny bits that still get done in softirq context, all packet reception, processing and transmission is done in this thread. That will allow a load of locking to be removed. (4) Perform packet processing and error processing from the I/O thread. (5) Provide a mechanism to process call event notifications in the I/O thread rather than queuing a work item for that call. (6) Move data and ACK transmission into the I/O thread. ACKs can then be transmitted at the point they're generated rather than getting delegated from softirq context to some process context somewhere. (7) Move call and local processor event handling into the I/O thread. (8) Move cwnd degradation to after packets have been transmitted so that they don't shorten the window too quickly. A bunch of simplifications can then be done: (1) The input_lock is no longer necessary as exclusion is achieved by running the code in the I/O thread only. (2) Don't need to use sk->sk_receive_queue.lock to guard socket state changes as the socket mutex should suffice. (3) Don't take spinlocks in RCU callback functions as they get run in softirq context and thus need _bh annotations. (4) RCU is then no longer needed for the peer's error_targets list. (5) Simplify the skbuff handling in the receive path by dropping the ref in the basic I/O thread loop and getting an extra ref as and when we need to queue the packet for recvmsg or another context. (6) Get the peer address earlier in the input process and pass it to the users so that we only do it once. This is tagged as rxrpc-next-20221201-b. Changes: ======== ver #2) - Added a patch to change four assertions into warnings in rxrpc_read() and fixed a checker warning from a __user annotation that should have been removed.. - Change a min() to min_t() in rxperf as PAGE_SIZE doesn't seem to match type size_t on i386. - Three error handling issues in rxrpc_new_incoming_call(): - If not DATA or not seq #1, should drop the packet, not abort. - Fix a goto that went to the wrong place, dropping a non-held lock. - Fix an rcu_read_lock that should've been an unlock. Tested-by:
Marc Dionne <marc.dionne@auristor.com> Tested-by: kafs-testing+fedora36_64checkkafs-build-144@auristor.com Link: https://lore.kernel.org/r/166794587113.2389296.16484814996876530222.stgit@warthog.procyon.org.uk/ [1] Link: https://lore.kernel.org/r/166982725699.621383.2358362793992993374.stgit@warthog.procyon.org.uk/ # v1 ==================== Signed-off-by:
-
Bhadram Varka authored
Add support for the Multi-Gigabit Ethernet (MGBE/XPCS) IP found on NVIDIA Tegra234 SoCs. Signed-off-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
Bhadram Varka <vbhadram@nvidia.com> Co-developed-by:
Revanth Kumar Uppala <ruppala@nvidia.com> Signed-off-by:
Jon Hunter <jonathanh@nvidia.com> Signed-off-by:
-
Revanth Kumar Uppala authored
The Tegra MGBE ethernet controller requires that the SERDES link is powered-up after the PHY link is up, otherwise the link fails to become ready following a resume from suspend. Add a variable to indicate that the SERDES link must be powered-up after the PHY link. Signed-off-by:
-
- 03 Dec, 2022 6 commits
-
-
David S. Miller authored
Heiner Kallweit says: ==================== net: add and use netdev_sw_irq_coalesce_default_on() There are reports about r8169 not reaching full line speed on certain systems (e.g. SBC's) with a 2.5Gbps link. There was a time when hardware interrupt coalescing was enabled per default, but this was changed due to ASPM-related issues on few systems. Meanwhile we have sysfs attributes for controlling kind of "software interrupt coalescing" on the GRO level. However most distros and users don't know about it. So lets set a conservative default for both involved parameters. Users can still override the defaults via sysfs. Don't enable these settings on the fast ethernet chip versions, they are slow enough. Even with these conservative setting interrupt load on my 1Gbps test system reduced significantly. Follow Jakub's suggestion and put this functionality into net core so that other MAC drivers can reuse it. ==================== Signed-off-by: -
Heiner Kallweit authored
There are reports about r8169 not reaching full line speed on certain systems (e.g. SBC's) with a 2.5Gbps link. There was a time when hardware interrupt coalescing was enabled per default, but this was changed due to ASPM-related issues on few systems. So let's use software interrupt coalescing instead and enable it using new function netdev_sw_irq_coalesce_default_on(). Even with these conservative settings interrupt load on my 1Gbps test system reduced significantly. Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by:
-
Heiner Kallweit authored
Add a helper for drivers wanting to set SW IRQ coalescing by default. The related sysfs attributes can be used to override the default values. Follow Jakub's suggestion and put this functionality into net core so that drivers wanting to use software interrupt coalescing per default don't have to open-code it. Note that this function needs to be called before the netdevice is registered. Suggested-by:
-
Lorenzo Bianconi authored
In order to fix the following sleep while atomic bug always alloc pages with GFP_ATOMIC in mtk_wed_wo_queue_refill since page_frag_alloc runs in spin_lock critical section. [ 9.049719] Hardware name: MediaTek MT7986a RFB (DT) [ 9.054665] Call trace: [ 9.057096] dump_backtrace+0x0/0x154 [ 9.060751] show_stack+0x14/0x1c [ 9.064052] dump_stack_lvl+0x64/0x7c [ 9.067702] dump_stack+0x14/0x2c [ 9.071001] ___might_sleep+0xec/0x120 [ 9.074736] __might_sleep+0x4c/0x9c [ 9.078296] __alloc_pages+0x184/0x2e4 [ 9.082030] page_frag_alloc_align+0x98/0x1ac [ 9.086369] mtk_wed_wo_queue_refill+0x134/0x234 [ 9.090974] mtk_wed_wo_init+0x174/0x2c0 [ 9.094881] mtk_wed_attach+0x7c8/0x7e0 [ 9.098701] mt7915_mmio_wed_init+0x1f0/0x3a0 [mt7915e] [ 9.103940] mt7915_pci_probe+0xec/0x3bc [mt7915e] [ 9.108727] pci_device_probe+0xac/0x13c [ 9.112638] really_probe.part.0+0x98/0x2f4 [ 9.116807] __driver_probe_device+0x94/0x13c [ 9.121147] driver_probe_device+0x40/0x114 [ 9.125314] __driver_attach+0x7c/0x180 [ 9.129133] bus_for_each_dev+0x5c/0x90 [ 9.132953] driver_attach+0x20/0x2c [ 9.136513] bus_add_driver+0x104/0x1fc [ 9.140333] driver_register+0x74/0x120 [ 9.144153] __pci_register_driver+0x40/0x50 [ 9.148407] mt7915_init+0x5c/0x1000 [mt7915e] [ 9.152848] do_one_initcall+0x40/0x25c [ 9.156669] do_init_module+0x44/0x230 [ 9.160403] load_module+0x1f30/0x2750 [ 9.164135] __do_sys_init_module+0x150/0x200 [ 9.168475] __arm64_sys_init_module+0x18/0x20 [ 9.172901] invoke_syscall.constprop.0+0x4c/0xe0 [ 9.177589] do_el0_svc+0x48/0xe0 [ 9.180889] el0_svc+0x14/0x50 [ 9.183929] el0t_64_sync_handler+0x9c/0x120 [ 9.188183] el0t_64_sync+0x158/0x15c Fixes: 79968444 ("net: ethernet: mtk_wed: introduce wed wo support") Signed-off-by:
Pavan Chebbi <pavan.chebbi@broadcom.com> Link: https://lore.kernel.org/r/67ca94bdd3d9eaeb86e52b3050fbca0bcf7bb02f.1669908312.git.lorenzo@kernel.orgSigned-off-by:
-
Eric Dumazet authored
kfree_rcu(1-arg) should be avoided as much as possible, since this is only possible from sleepable contexts, and incurr extra rcu barriers. I wish the 1-arg variant of kfree_rcu() would get a distinct name, like kfree_rcu_slow() to avoid it being abused. Fixes: 459837b5 ("net/tcp: Disable TCP-MD5 static key on tcp_md5sig_info destruction") Signed-off-by:
Eric Dumazet <edumazet@google.com> Cc: Paul E. McKenney <paulmck@kernel.org> Reviewed-by:
Dmitry Safonov <dima@arista.com> Link: https://lore.kernel.org/r/20221202052847.2623997-1-edumazet@google.comSigned-off-by:
-
Jakub Kicinski authored
Merge tag 'wireless-next-2022-12-02' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next Kalle Valo says: ==================== wireless-next patches for v6.2 Third set of patches for v6.2. mt76 has a new driver for mt7996 Wi-Fi 7 devices and iwlwifi also got initial Wi-Fi 7 support. Otherwise smaller features and fixes. Major changes: ath10k - store WLAN firmware version in SMEM image table mt76 - mt7996: new driver for MediaTek Wi-Fi 7 (802.11be) devices - mt7986, mt7915: enable Wireless Ethernet Dispatch (WED) offload support - mt7915: add ack signal support - mt7915: enable coredump support - mt7921: remain_on_channel support - mt7921: channel context support iwlwifi - enable Wi-Fi 7 Extremely High Throughput (EHT) PHY capabilities - 320 MHz channels support * tag 'wireless-next-2022-12-02' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (144 commits) wifi: ath10k: fix QCOM_SMEM dependency wifi: mt76: mt7921e: add pci .shutdown() support wifi: mt76: mt7915: mmio: fix naming convention wifi: mt76: mt7996: add support to configure spatial reuse parameter set wifi: mt76: mt7996: enable ack signal support wifi: mt76: mt7996: enable use_cts_prot support wifi: mt76: mt7915: rely on band_idx of mt76_phy wifi: mt76: mt7915: enable per bandwidth power limit support wifi: mt76: mt7915: introduce mt7915_get_power_bound() mt76: mt7915: Fix PCI device refcount leak in mt7915_pci_init_hif2() wifi: mt76: do not send firmware FW_FEATURE_NON_DL region wifi: mt76: mt7921: Add missing __packed annotation of struct mt7921_clc wifi: mt76: fix coverity overrun-call in mt76_get_txpower() wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices wifi: mt76: mt76x0: remove dead code in mt76x0_phy_get_target_power wifi: mt76: mt7915: fix band_idx usage wifi: mt76: mt7915: enable .sta_set_txpwr support wifi: mt76: mt7915: add basedband Txpower info into debugfs wifi: mt76: mt7915: add support to configure spatial reuse parameter set wifi: mt76: mt7915: add missing MODULE_PARM_DESC ... ==================== Link: https://lore.kernel.org/r/20221202214254.D0D3DC433C1@smtp.kernel.orgSigned-off-by:
-
- 02 Dec, 2022 3 commits
-
-
Kalle Valo authored
Nathan noticed that when HWSPINLOCK is disabled there's a Kconfig warning: WARNING: unmet direct dependencies detected for QCOM_SMEM Depends on [n]: (ARCH_QCOM [=y] || COMPILE_TEST [=n]) && HWSPINLOCK [=n] Selected by [m]: - ATH10K_SNOC [=m] && NETDEVICES [=y] && WLAN [=y] && WLAN_VENDOR_ATH [=y] && ATH10K [=m] && (ARCH_QCOM [=y] || COMPILE_TEST [=n]) The problem here is that QCOM_SMEM depends on HWSPINLOCK so we cannot select QCOM_SMEM and instead we neeed to use 'depends on'. Reported-by:Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/all/Y4YsyaIW+CPdHWv3@dev-arch.thelio-3990X/ Fixes: 4d79f6f3 ("wifi: ath10k: Store WLAN firmware version in SMEM image table") Signed-off-by:
Kalle Valo <quic_kvalo@quicinc.com> Signed-off-by:
Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20221202103027.25974-1-kvalo@kernel.org
-
Gerhard Engleder authored
Refill RX queue in batches of descriptors to improve performance. Refill is allowed to fail as long as a minimum number of descriptors is active. Thus, a limited number of failed RX buffer allocations is now allowed for normal operation. Previously every failed allocation resulted in a dropped frame. If the minimum number of active descriptors is reached, then RX buffers are still reused and frames are dropped. This ensures that the RX queue never runs empty and always continues to operate. Prework for future XDP support. Signed-off-by:
Gerhard Engleder <gerhard@engleder-embedded.com> Signed-off-by:
-
Gerhard Engleder authored
Without interrupt throttling, iperf server mode generates a CPU load of 100% (A53 1.2GHz). Also the throughput suffers with less than 900Mbit/s on a 1Gbit/s link. The reason is a high interrupt load with interrupts every ~20us. Reduce interrupt load by throttling of interrupts. Interrupt delay default is 64us. For iperf server mode the CPU load is significantly reduced to ~20% and the throughput reaches the maximum of 941MBit/s. Interrupts are generated every ~140us. RX and TX coalesce can be configured with ethtool. RX coalesce has priority over TX coalesce if the same interrupt is used. Signed-off-by:
-
