- 07 Sep, 2024 22 commits
-
-
Vadim Fedorenko authored
The PCIe bus can be pretty busy during boot and probe function can see excessive delays. Let's find the minimal value out of several tests and use it as estimated value. Signed-off-by:
Vadim Fedorenko <vadim.fedorenko@linux.dev> Link: https://patch.msgid.link/20240905140028.560454-1-vadim.fedorenko@linux.devSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Eric Dumazet authored
netpoll_srcu is currently used from netpoll_poll_disable() and __netpoll_cleanup() Both functions run under RTNL, using netpoll_srcu adds confusion and no additional protection. Moreover the synchronize_srcu() call in __netpoll_cleanup() is performed before clearing np->dev->npinfo, which violates RCU rules. After this patch, netpoll_poll_disable() and netpoll_poll_enable() simply use rtnl_dereference(). This saves a big chunk of memory (more than 192KB on platforms with 512 cpus) Signed-off-by:
Eric Dumazet <edumazet@google.com> Reviewed-by:
Breno Leitao <leitao@debian.org> Link: https://patch.msgid.link/20240905084909.2082486-1-edumazet@google.comSigned-off-by:
-
Jakub Kicinski authored
Simon Horman says: ==================== octeontx2: Address some warnings This patchset addresses some warnings flagged by Sparse, gcc-14, and clang-18 in files touched by recent patch submissions. Although these changes do not alter the functionality of the code, by addressing them real problems introduced in future which are flagged by Sparse will stand out more readily. v1: https://lore.kernel.org/20240903-octeontx2-sparse-v1-0-f190309ecb0a@kernel.org ==================== Link: https://patch.msgid.link/20240904-octeontx2-sparse-v2-0-14f2305fe4b2@kernel.orgSigned-off-by:
-
Simon Horman authored
In otx2_sqe_add_ext() iplen is used to hold a 16-bit big-endian value, but it's type is u16, indicating a host byte order integer. Address this mismatch by changing the type of iplen to __be16. Flagged by Sparse as: .../otx2_txrx.c:699:31: warning: incorrect type in assignment (different base types) .../otx2_txrx.c:699:31: expected unsigned short [usertype] iplen .../otx2_txrx.c:699:31: got restricted __be16 [usertype] .../otx2_txrx.c:701:54: warning: incorrect type in assignment (different base types) .../otx2_txrx.c:701:54: expected restricted __be16 [usertype] tot_len .../otx2_txrx.c:701:54: got unsigned short [usertype] iplen .../otx2_txrx.c:704:60: warning: incorrect type in assignment (different base types) .../otx2_txrx.c:704:60: expected restricted __be16 [usertype] payload_len .../otx2_txrx.c:704:60: got unsigned short [usertype] iplen Introduced in commit dc1a9bf2 ("octeontx2-pf: Add UDP segmentation offload support") No functional change intended. Compile tested only by author. Tested-by:
Geetha sowjanya <gakula@marvell.com> Signed-off-by:
Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20240904-octeontx2-sparse-v2-2-14f2305fe4b2@kernel.orgSigned-off-by:
-
Simon Horman authored
Recently I noticed that both gcc-14 and clang-18 report that passing a non-string literal as the format argument of alloc_workqueue() is potentially insecure. E.g. clang-18 says: .../rvu.c:2493:32: warning: format string is not a string literal (potentially insecure) [-Wformat-security] 2493 | mw->mbox_wq = alloc_workqueue(name, | ^~~~ .../rvu.c:2493:32: note: treat the string as an argument to avoid this 2493 | mw->mbox_wq = alloc_workqueue(name, | ^ | "%s", It is always the case where the contents of name is safe to pass as the format argument. That is, in my understanding, it never contains any format escape sequences. But, it seems better to be safe than sorry. And, as a bonus, compiler output becomes less verbose by addressing this issue as suggested by clang-18. Compile tested only by author. Tested-by: -
Rosen Penev authored
No need for the mask when there's already a macro for this. Signed-off-by:
Rosen Penev <rosenp@gmail.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20240904205659.7470-1-rosenp@gmail.comSigned-off-by:
-
Edward Cree authored
Siena hardware does not support custom RSS contexts, but when the driver was forked from sfc.ko, some of the plumbing for them was copied across from the common code. Actually trying to use them would lead to EOPNOTSUPP as the relevant efx_nic_type methods were not populated. Remove this dead code from the Siena driver. Signed-off-by:
Edward Cree <ecree.xilinx@gmail.com> Reviewed-by:
-
Jakub Kicinski authored
Vasileios Amoiridis says: ==================== Use functionality of irq_get_trigger_type() v1: https://lore.kernel.org/20240902225534.130383-1-vassilisamir@gmail.com ==================== Link: https://patch.msgid.link/20240904151018.71967-1-vassilisamir@gmail.comSigned-off-by:
-
Vasileios Amoiridis authored
Convert irqd_get_trigger_type(irq_get_irq_data(irq)) cases to the more simple irq_get_trigger_type(irq). Signed-off-by:
Vasileios Amoiridis <vassilisamir@gmail.com> Reviewed-by:
Alvin Šipraga <alsi@bang-olufsen.dk> Link: https://patch.msgid.link/20240904151018.71967-4-vassilisamir@gmail.comSigned-off-by:
-
Vasileios Amoiridis authored
Convert irqd_get_trigger_type(irq_get_irq_data(irq)) cases to the more simple irq_get_trigger_type(irq). Reviewed-by:
-
Vasileios Amoiridis authored
Convert irqd_get_trigger_type(irq_get_irq_data(irq)) cases to the more simple irq_get_trigger_type(irq). Signed-off-by:
-
Sascha Hauer authored
When asynchronous encryption is used KTLS sends out the final data at proto->close time. This becomes problematic when the task calling close() receives a signal. In this case it can happen that tcp_sendmsg_locked() called at close time returns -ERESTARTSYS and the final data is not sent. The described situation happens when KTLS is used in conjunction with io_uring, as io_uring uses task_work_add() to add work to the current userspace task. A discussion of the problem along with a reproducer can be found in [1] and [2] Fix this by waiting for the asynchronous encryption to be completed on the final message. With this there is no data left to be sent at close time. [1] https://lore.kernel.org/all/20231010141932.GD3114228@pengutronix.de/ [2] https://lore.kernel.org/all/20240315100159.3898944-1-s.hauer@pengutronix.de/Signed-off-by:
Sascha Hauer <s.hauer@pengutronix.de> Link: https://patch.msgid.link/20240904-ktls-wait-async-v1-1-a62892833110@pengutronix.deSigned-off-by:
-
Jakub Kicinski authored
Hongbo Li says: ==================== make use of the helper macro LIST_HEAD() The macro LIST_HEAD() declares a list variable and initializes it, which can be used to simplify the steps of list initialization, thereby simplifying the code. These serials just do some equivalatent substitutions, and with no functional modifications. ==================== Link: https://patch.msgid.link/20240904093243.3345012-1-lihongbo22@huawei.comSigned-off-by:
-
Hongbo Li authored
list_head can be initialized automatically with LIST_HEAD() instead of calling INIT_LIST_HEAD(). Here we can simplify the code. Signed-off-by:
Hongbo Li <lihongbo22@huawei.com> Link: https://patch.msgid.link/20240904093243.3345012-6-lihongbo22@huawei.comSigned-off-by:
-
Hongbo Li authored
list_head can be initialized automatically with LIST_HEAD() instead of calling INIT_LIST_HEAD(). Here we can simplify the code. Signed-off-by:
-
Hongbo Li authored
list_head can be initialized automatically with LIST_HEAD() instead of calling INIT_LIST_HEAD(). Here we can simplify the code. Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org> Link: https://patch.msgid.link/20240904093243.3345012-4-lihongbo22@huawei.comSigned-off-by:
-
Hongbo Li authored
list_head can be initialized automatically with LIST_HEAD() instead of calling INIT_LIST_HEAD(). Here we can simplify the code. Signed-off-by:
-
Hongbo Li authored
list_head can be initialized automatically with LIST_HEAD() instead of calling INIT_LIST_HEAD(). Here we can simplify the code. Signed-off-by:
-
Chen Ni authored
Replace comma between expressions with semicolons. Using a ',' in place of a ';' can have unintended side effects. Although that is not the case here, it is seems best to use ';' unless ',' is intended. Found by inspection. No functional change intended. Compile tested only. Signed-off-by:
Chen Ni <nichen@iscas.ac.cn> Acked-by:
-
Chen Ni authored
Replace comma between expressions with semicolons. Using a ',' in place of a ';' can have unintended side effects. Although that is not the case here, it is seems best to use ';' unless ',' is intended. Found by inspection. No functional change intended. Compile tested only. Signed-off-by:
-
Chen Ni authored
Replace comma between expressions with semicolons. Using a ',' in place of a ';' can have unintended side effects. Although that is not the case here, it is seems best to use ';' unless ',' is intended. Found by inspection. No functional change intended. Compile tested only. Signed-off-by:
Shannon Nelson <shannon.nelson@amd.com> Link: https://patch.msgid.link/20240904081728.1353260-1-nichen@iscas.ac.cnSigned-off-by:
-
Chen Ni authored
Replace comma between expressions with semicolons. Using a ',' in place of a ';' can have unintended side effects. Although that is not the case here, it is seems best to use ';' unless ',' is intended. Found by inspection. No functional change intended. Compile tested only. Signed-off-by:
-
- 06 Sep, 2024 18 commits
-
-
David S. Miller authored
Gal Pressman says: ==================== RX software timestamp for all - round 2 Round 1 of drivers conversion was merged [1], this is round 2, more drivers to follow. [1] https://lore.kernel.org/netdev/20240901112803.212753-1-gal@nvidia.com/ ==================== Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Gal Pressman authored
The responsibility for reporting of RX software timestamp has moved to the core layer (see __ethtool_get_ts_info()), remove usage from the device drivers. Reviewed-by:
Carolina Jubran <cjubran@nvidia.com> Reviewed-by:
Rahul Rameshbabu <rrameshbabu@nvidia.com> Signed-off-by:
Gal Pressman <gal@nvidia.com> Signed-off-by:
-
Gal Pressman authored
The responsibility for reporting of RX software timestamp has moved to the core layer (see __ethtool_get_ts_info()), remove usage from the device drivers. Reviewed-by:
Potnuri Bharat Teja <bharat@chelsio.com> Signed-off-by:
-
Gal Pressman authored
The responsibility for reporting of RX software timestamp has moved to the core layer (see __ethtool_get_ts_info()), remove usage from the device drivers. Reviewed-by:
Tony Nguyen <anthony.l.nguyen@intel.com> Signed-off-by:
-
Gal Pressman authored
The responsibility for reporting of RX software timestamp has moved to the core layer (see __ethtool_get_ts_info()), remove usage from the device drivers. Reviewed-by:
-
Gal Pressman authored
The responsibility for reporting of RX software timestamp has moved to the core layer (see __ethtool_get_ts_info()), remove usage from the device drivers. Reviewed-by:
-
Gal Pressman authored
The responsibility for reporting of RX software timestamp has moved to the core layer (see __ethtool_get_ts_info()), remove usage from the device drivers. Reviewed-by:
-
Gal Pressman authored
The responsibility for reporting of RX software timestamp has moved to the core layer (see __ethtool_get_ts_info()), remove usage from the device drivers. Reviewed-by:
-
Gal Pressman authored
The responsibility for reporting of RX software timestamp has moved to the core layer (see __ethtool_get_ts_info()), remove usage from the device drivers. Reviewed-by:
-
Gal Pressman authored
The responsibility for reporting of RX software timestamp has moved to the core layer (see __ethtool_get_ts_info()), remove usage from the device drivers. Reviewed-by:
Roger Quadros <rogerq@kernel.org> Reviewed-by:
MD Danish Anwar <danishanwar@ti.com> Signed-off-by:
-
Gal Pressman authored
The responsibility for reporting of RX software timestamp has moved to the core layer (see __ethtool_get_ts_info()), remove usage from the device drivers. Reviewed-by:
-
Gal Pressman authored
The responsibility for reporting of RX software timestamp has moved to the core layer (see __ethtool_get_ts_info()), remove usage from the device drivers. Reviewed-by:
-
Gal Pressman authored
The responsibility for reporting of RX software timestamp has moved to the core layer (see __ethtool_get_ts_info()), remove usage from the device drivers. Reviewed-by:
Petr Machata <petrm@nvidia.com> Signed-off-by:
-
Gal Pressman authored
The responsibility for reporting of RX software timestamp has moved to the core layer (see __ethtool_get_ts_info()), remove usage from the device drivers. Reviewed-by:
-
Gal Pressman authored
The responsibility for reporting of RX software timestamp has moved to the core layer (see __ethtool_get_ts_info()), remove usage from the device drivers. Reviewed-by:
-
Gal Pressman authored
The responsibility for reporting of RX software timestamp has moved to the core layer (see __ethtool_get_ts_info()), remove usage from the device drivers. Reviewed-by:
Raju Lakkaraju <Raju.Lakkaraju@microchip.com> Signed-off-by:
-
David S. Miller authored
Pieter Van Trappen says: ==================== net: dsa: microchip: rename and clean ksz8 series files The first KSZ8 series implementation was done for a KSZ8795 device but since several other KSZ8 devices have been added. Rename these files to adhere to the ksz8 naming convention as already used in most functions and the existing ksz8.h; add an explanatory note. In addition, clean the files by removing macros that are defined at more than one place and remove confusion by renaming the KSZ8830 string which in fact is not an existing KSZ series switch. Signed-off-by:
Pieter Van Trappen <pieter.van.trappen@cern.ch> --- v4: - correct once more Kconfig list of supported switches v3: https://lore.kernel.org/netdev/20240903072946.344507-1-vtpieter@gmail.com/ - rename all KSZ8830 to KSZ88X3 only (not KSZ8863) - update Kconfig as per Arun's suggestion v2: https://lore.kernel.org/netdev/20240830141250.30425-1-vtpieter@gmail.com/ - more finegrained description in Kconfig and ksz8.c header - add KSZ8830/ksz8830 to KSZ8863/ksz88x3 renaming v1: https://lore.kernel.org/netdev/20240828102801.227588-1-vtpieter@gmail.com/ ==================== Signed-off-by:
-
Pieter Van Trappen authored
Replace ksz8830 with ksz88x3 for CHIP_ID definition and other strings. This due to KSZ8830 not being an actual switch but the Chip ID shared among KSZ8863/8873 switches, impossible to differentiate from their Chip ID or Revision ID registers. Now all KSZ*_CHIP_ID macros refer to actual, existing switches which removes confusion. Signed-off-by:
Arun Ramadoss <arun.ramadoss@microchip.com> Signed-off-by:
-
