- 24 Jun, 2023 16 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queueJakub Kicinski authored
Tony Nguyen says: ==================== Intel Wired LAN Driver Updates 2023-06-22 (ice) This series contains updates to ice driver only. Jake adds a slight wait on control queue send to reduce wait time for responses that occur within normal times. Maciej allows for hot-swapping XDP programs. Przemek removes unnecessary checks when enabling SR-IOV and freeing allocated memory. Christophe Jaillet converts a managed memory allocation to a regular one. * '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue: ice: use ice_down_up() where applicable ice: Remove managed memory usage in ice_get_fw_log_cfg() ice: remove null checks before devm_kfree() calls ice: clean up freeing SR-IOV VFs ice: allow hot-swapping XDP programs ice: reduce initial wait for control queue messages ==================== Link: https://lore.kernel.org/r/20230622183601.2406499-1-anthony.l.nguyen@intel.comSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Pavel Begunkov authored
Even when tcp_splice_read() reads all it was asked for, for blocking sockets it'll release and immediately regrab the socket lock, loop around and break on the while check. Check tss.len right after we adjust it, and return if we're done. That saves us one release_sock(); lock_sock(); pair per successful blocking splice read. Signed-off-by:
Pavel Begunkov <asml.silence@gmail.com> Reviewed-by:
Eric Dumazet <edumazet@google.com> Link: https://lore.kernel.org/r/80736a2cc6d478c383ea565ba825eaf4d1abd876.1687523671.git.asml.silence@gmail.comSigned-off-by:
-
Kuniyuki Iwashima authored
syzkaller hit a WARN_ON_ONCE(!scm->pid) in scm_pidfd_recv(). In unix_stream_read_generic(), if there is no skb in the queue, we could bail out the do-while loop without calling scm_set_cred(): 1. No skb in the queue 2. sk is non-blocking or shutdown(sk, RCV_SHUTDOWN) is called concurrently or peer calls close() If the socket is configured with SO_PASSCRED or SO_PASSPIDFD, scm_recv() would populate cmsg with garbage. Let's not call scm_recv() unless there is skb to receive. WARNING: CPU: 1 PID: 3245 at include/net/scm.h:138 scm_pidfd_recv include/net/scm.h:138 [inline] WARNING: CPU: 1 PID: 3245 at include/net/scm.h:138 scm_recv.constprop.0+0x754/0x850 include/net/scm.h:177 Modules linked in: CPU: 1 PID: 3245 Comm: syz-executor.1 Not tainted 6.4.0-rc5-01219-gfa0e21fa #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:scm_pidfd_recv include/net/scm.h:138 [inline] RIP: 0010:scm_recv.constprop.0+0x754/0x850 include/net/scm.h:177 Code: 67 fd e9 55 fd ff ff e8 4a 70 67 fd e9 7f fd ff ff e8 40 70 67 fd e9 3e fb ff ff e8 36 70 67 fd e9 02 fd ff ff e8 8c 3a 20 fd <0f> 0b e9 fe fb ff ff e8 50 70 67 fd e9 2e f9 ff ff e8 46 70 67 fd RSP: 0018:ffffc90009af7660 EFLAGS: 00010216 RAX: 00000000000000a1 RBX: ffff888041e58a80 RCX: ffffc90003852000 RDX: 0000000000040000 RSI: ffffffff842675b4 RDI: 0000000000000007 RBP: ffffc90009af7810 R08: 0000000000000007 R09: 0000000000000013 R10: 00000000000000f8 R11: 0000000000000001 R12: ffffc90009af7db0 R13: 0000000000000000 R14: ffff888041e58a88 R15: 1ffff9200135eecc FS: 00007f6b7113f640(0000) GS:ffff88806cf00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f6b7111de38 CR3: 0000000012a6e002 CR4: 0000000000770ee0 PKRU: 55555554 Call Trace: <TASK> unix_stream_read_generic+0x5fe/0x1f50 net/unix/af_unix.c:2830 unix_stream_recvmsg+0x194/0x1c0 net/unix/af_unix.c:2880 sock_recvmsg_nosec net/socket.c:1019 [inline] sock_recvmsg+0x188/0x1d0 net/socket.c:1040 ____sys_recvmsg+0x210/0x610 net/socket.c:2712 ___sys_recvmsg+0xff/0x190 net/socket.c:2754 do_recvmmsg+0x25d/0x6c0 net/socket.c:2848 __sys_recvmmsg net/socket.c:2927 [inline] __do_sys_recvmmsg net/socket.c:2950 [inline] __se_sys_recvmmsg net/socket.c:2943 [inline] __x64_sys_recvmmsg+0x224/0x290 net/socket.c:2943 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3f/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x72/0xdc RIP: 0033:0x7f6b71da2e5d Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 9f 1b 00 f7 d8 64 89 01 48 RSP: 002b:00007f6b7113ecc8 EFLAGS: 00000246 ORIG_RAX: 000000000000012b RAX: ffffffffffffffda RBX: 00000000004bc050 RCX: 00007f6b71da2e5d RDX: 0000000000000007 RSI: 0000000020006600 RDI: 000000000000000b RBP: 00000000004bc050 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000120 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000006e R14: 00007f6b71e03530 R15: 0000000000000000 </TASK> Fixes: 5e2ff670 ("scm: add SO_PASSPIDFD and SCM_PIDFD") Fixes: 1da177e4 ("Linux-2.6.12-rc2") Reported-by:syzkaller <syzkaller@googlegroups.com> Signed-off-by:
Kuniyuki Iwashima <kuniyu@amazon.com> Reviewed-by:
Alexander Mikhalitsyn <alexander@mihalicyn.com> Link: https://lore.kernel.org/r/20230622184351.91544-1-kuniyu@amazon.comSigned-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queueJakub Kicinski authored
Tony Nguyen says: ==================== Intel Wired LAN Driver Updates 2023-06-22 (iavf) This series contains updates to iavf driver only. Przemek defers removing, previous, primary MAC address until after getting result of adding its replacement. He also does some cleanup by removing unused functions and making applicable functions static. * '40GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue: iavf: make functions static where possible iavf: remove some unused functions and pointless wrappers iavf: fix err handling for MAC replace ==================== Link: https://lore.kernel.org/r/20230622165914.2203081-1-anthony.l.nguyen@intel.comSigned-off-by:
-
Randy Dunlap authored
The referenced patch is causing build errors when ETHERNET=y and FDDI=m. While we work out the preferred patch(es), revert this patch to make the pain go away. Fixes: 12827233 ("s390/net: lcs: use IS_ENABLED() for kconfig detection") Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Reported-by:
kernel test robot <lkp@intel.com> Link: lore.kernel.org/r/202306202129.pl0AqK8G-lkp@intel.com Cc: Alexandra Winter <wintera@linux.ibm.com> Cc: Wenjia Zhang <wenjia@linux.ibm.com> Cc: Heiko Carstens <hca@linux.ibm.com> Cc: Vasily Gorbik <gor@linux.ibm.com> Cc: Alexander Gordeev <agordeev@linux.ibm.com> Cc: Christian Borntraeger <borntraeger@linux.ibm.com> Cc: Sven Schnelle <svens@linux.ibm.com> Reviewed-by:
Simon Horman <simon.horman@corigine.com> Link: https://lore.kernel.org/r/20230622155409.27311-1-rdunlap@infradead.orgSigned-off-by:
-
Giulio Benetti authored
Linux provides phy_set_bits() helper so let's drop brcm_phy_setbits() and use phy_set_bits() in its place. Signed-off-by:
Giulio Benetti <giulio.benetti@benettiengineering.com> Reviewed-by:
Florian Fainelli <florian.fainelli@broadcom.com> Link: https://lore.kernel.org/r/20230622184721.24368-1-giulio.benetti@benettiengineering.comSigned-off-by:
-
https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-nextJakub Kicinski authored
Daniel Borkmann says: ==================== pull-request: bpf-next 2023-06-23 We've added 49 non-merge commits during the last 24 day(s) which contain a total of 70 files changed, 1935 insertions(+), 442 deletions(-). The main changes are: 1) Extend bpf_fib_lookup helper to allow passing the route table ID, from Louis DeLosSantos. 2) Fix regsafe() in verifier to call check_ids() for scalar registers, from Eduard Zingerman. 3) Extend the set of cpumask kfuncs with bpf_cpumask_first_and() and a rework of bpf_cpumask_any*() kfuncs. Additionally, add selftests, from David Vernet. 4) Fix socket lookup BPF helpers for tc/XDP to respect VRF bindings, from Gilad Sever. 5) Change bpf_link_put() to use workqueue unconditionally to fix it under PREEMPT_RT, from Sebastian Andrzej Siewior. 6) Follow-ups to address issues in the bpf_refcount shared ownership implementation, from Dave Marchevsky. 7) A few general refactorings to BPF map and program creation permissions checks which were part of the BPF token series, from Andrii Nakryiko. 8) Various fixes for benchmark framework and add a new benchmark for BPF memory allocator to BPF selftests, from Hou Tao. 9) Documentation improvements around iterators and trusted pointers, from Anton Protopopov. 10) Small cleanup in verifier to improve allocated object check, from Daniel T. Lee. 11) Improve performance of bpf_xdp_pointer() by avoiding access to shared_info when XDP packet does not have frags, from Jesper Dangaard Brouer. 12) Silence a harmless syzbot-reported warning in btf_type_id_size(), from Yonghong Song. 13) Remove duplicate bpfilter_umh_cleanup in favor of umd_cleanup_helper, from Jarkko Sakkinen. 14) Fix BPF selftests build for resolve_btfids under custom HOSTCFLAGS, from Viktor Malik. * tag 'for-netdev' of https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next: (49 commits) bpf, docs: Document existing macros instead of deprecated bpf, docs: BPF Iterator Document selftests/bpf: Fix compilation failure for prog vrf_socket_lookup selftests/bpf: Add vrf_socket_lookup tests bpf: Fix bpf socket lookup from tc/xdp to respect socket VRF bindings bpf: Call __bpf_sk_lookup()/__bpf_skc_lookup() directly via TC hookpoint bpf: Factor out socket lookup functions for the TC hookpoint. selftests/bpf: Set the default value of consumer_cnt as 0 selftests/bpf: Ensure that next_cpu() returns a valid CPU number selftests/bpf: Output the correct error code for pthread APIs selftests/bpf: Use producer_cnt to allocate local counter array xsk: Remove unused inline function xsk_buff_discard() bpf: Keep BPF_PROG_LOAD permission checks clear of validations bpf: Centralize permissions checks for all BPF map types bpf: Inline map creation logic in map_create() function bpf: Move unprivileged checks into map_create() and bpf_prog_load() bpf: Remove in_atomic() from bpf_link_put(). selftests/bpf: Verify that check_ids() is used for scalars in regsafe() bpf: Verify scalar ids mapping in regsafe() using check_ids() selftests/bpf: Check if mark_chain_precision() follows scalar ids ... ==================== Link: https://lore.kernel.org/r/20230623211256.8409-1-daniel@iogearbox.netSigned-off-by: -
Jakub Kicinski authored
Petr Machata says: ==================== mlxsw: Maintain candidate RIFs The mlxsw driver currently makes the assumption that the user applies configuration in a bottom-up manner. Thus netdevices need to be added to the bridge before IP addresses are configured on that bridge or SVI added on top of it. Enslaving a netdevice to another netdevice that already has uppers is in fact forbidden by mlxsw for this reason. Despite this safety, it is rather easy to get into situations where the offloaded configuration is just plain wrong. As an example, take a front panel port, configure an IP address: it gets a RIF. Now enslave the port to the bridge, and the RIF is gone. Remove the port from the bridge again, but the RIF never comes back. There is a number of similar situations, where changing the configuration there and back utterly breaks the offload. The situation is going to be made better by implementing a range of replays and post-hoc offloads. This patch set lays the ground for replay of next hops. The particular issue that it deals with is that currently, driver-specific bookkeeping for next hops is hooked off RIF objects, which come and go across the lifetime of a netdevice. We would rather keep these objects at an entity that mirrors the lifetime of the netdevice itself. That way they are at hand and can be offloaded when a RIF is eventually created. To that end, with this patchset, mlxsw keeps a hash table of CRIFs: candidate RIFs, persistent handles for netdevices that mlxsw deems potentially interesting. The lifetime of a CRIF matches that of the underlying netdevice, and thus a RIF can always assume a CRIF exists. A CRIF is where next hops are kept, and when RIF is created, these next hops can be easily offloaded. (Previously only the next hops created after the RIF was created were offloaded.) - Patches #1 and #2 are minor adjustments. - In patches #3 and #4, add CRIF bookkeeping. - In patch #5, link CRIFs to RIFs such that given a netdevice-backed RIF, the corresponding CRIF is easy to look up. - Patch #6 is a clean-up allowed by the previous patches - Patches #7 and #8 move next hop tracking to CRIFs No observable effects are intended as of yet. This will be useful once there is support for RIF creation for netdevices that become mlxsw uppers, which will come in following patch sets. ==================== Link: https://lore.kernel.org/r/cover.1687438411.git.petrm@nvidia.comSigned-off-by:
-
Petr Machata authored
Move the list of next hops from struct mlxsw_sp_rif to mlxsw_sp_crif. The reason is that eventually, next hops for mlxsw uppers should be offloaded and unoffloaded on demand as a netdevice becomes an upper, or stops being one. Currently, next hops are tracked at RIFs, but RIFs do not exist when a netdevice is not an mlxsw uppers. CRIFs are kept track of throughout the netdevice lifetime. Correspondingly, track at each next hop not its RIF, but its CRIF (from which a RIF can always be deduced). Note that now that next hops are tracked at a CRIF, it is not necessary to move each over to a new RIF when it is necessary to edit a RIF. Therefore drop mlxsw_sp_nexthop_rif_migrate() and have mlxsw_sp_rif_migrate_destroy() call mlxsw_sp_nexthop_rif_update() directly. Signed-off-by:
Petr Machata <petrm@nvidia.com> Reviewed-by:
Danielle Ratson <danieller@nvidia.com> Link: https://lore.kernel.org/r/e7c1c0a7dd13883b0f09aeda12c4fcf4d63a70e3.1687438411.git.petrm@nvidia.comSigned-off-by:
-
Petr Machata authored
Nexthop finalization consists of two steps: the part where the offload is removed, because the backing RIF is now gone; and the part where the association to the RIF is severed. Extract from mlxsw_sp_nexthop_type_fini() a helper that covers the unoffloading part, mlxsw_sp_nexthop_type_rif_gone(), so that it can later be called independently. Note that this swaps around the ordering of mlxsw_sp_nexthop_ipip_fini() vs. mlxsw_sp_nexthop_rif_fini(). The current ordering is more of a historical happenstance than a conscious decision. The two cleanups do not depend on each other, and this change should have no observable effects. Signed-off-by:
-
Petr Machata authored
A previous patch added a pointer to loopback CRIF to the router data structure. That makes the loopback RIF index redundant, as everything necessary can be derived from the CRIF. Drop the field and adjust the code accordingly. Signed-off-by:
-
Petr Machata authored
When a RIF is about to be created, the registration of the netdevice that it should be associated with must have been seen in the past, and a CRIF created. Therefore make this a hard requirement by looking up the CRIF during RIF creation, and complaining loudly when there isn't one. This then allows to keep a link between a RIF and its corresponding CRIF (and back, as the relationship is one-to-at-most-one), which do. The CRIF will later be useful as the objects tracked there will be offloaded lazily as a result of RIF creation. CRIFs are created when an "interesting" netdevice is registered, and destroyed after such device is unregistered. CRIFs are supposed to already exist when a RIF creation request arises, and exist at least as long as that RIF exists. This makes for a simple invariant: it is always safe to dereference CRIF pointer from "its" RIF. To guarantee this, CRIFs cannot be removed immediately when the UNREGISTER event is delivered. The reason is that if a RIF's netdevices has an IPv6 address, removal of this address is notified in an atomic block. To remove the RIF, the IPv6 removal handler schedules a work item. It must be safe for this work item to access the associated CRIF as well. Thus when a netdevice that backs the CRIF is removed, if it still has a RIF, do not actually free the CRIF, only toggle its can_destroy flag, which this patch adds. Later on, mlxsw_sp_rif_destroy() collects the CRIF. Signed-off-by:
-
Petr Machata authored
CRIFs are generally not maintained for loopback RIFs. However, the RIF for the default VRF is used for offloading of blackhole nexthops. Nexthops expect to have a valid CRIF. Therefore in this patch, add code to maintain CRIF for the loopback RIF as well. Signed-off-by:
-
Petr Machata authored
CRIFs are objects that mlxsw maintains for netdevices that may not have an associated RIF (i.e. they may not have been instantiated in the ASIC), but if indeed they do not, it is quite possible they will in the future. These netdevices are candidate RIFs, hence CRIFs. Netdevices for which CRIFs are created include e.g. bridges, LAGs, or front panel ports. The idea is that next hops would be kept at CRIFs, not RIFs, and thus it would be easier to offload and unoffload the entities that have been added before the RIF was created. In this patch, add the code for low-level CRIF maintenance: create and destroy, and keep in a table keyed by the netdevice pointer for easy recall. Signed-off-by:
-
Petr Machata authored
The current function, mlxsw_sp_router_ul_rif_get(), is a wrapper around the function mentioned in the subject. As such it forms an external interface of the router code. In future patches we will want to maintain connection between RIFs and the CRIFs (introduced in the next patch) that back them. That will not hold for the VRF-based loopback netdevices, so the whole CRIF business can be kept hidden from the rest of mlxsw. But for the main VRF loopback RIF we do want to keep the RIF-CRIF connection, because that RIF is used for blackhole next hops, and the next hop code can be kept simpler for assuming rif->crif is valid. Hence, instead, call mlxsw_sp_ul_rif_get() to create the main VRF loopback RIF. This being an internal function will take the CRIF argument anyway. Furthermore, the function does not lock, which is not necessary at this point in code yet. Signed-off-by:
-
Petr Machata authored
The extack will be handy in later patches. Signed-off-by:
-
- 23 Jun, 2023 24 commits
-
-
Rob Herring authored
The conditional if/then schema has an error as the "enum" values have "const" in them. Drop the "const". Signed-off-by:
Rob Herring <robh@kernel.org> Reviewed-by:
Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20230621231012.3816139-1-robh@kernel.orgSigned-off-by:
Paolo Abeni <pabeni@redhat.com>
-
Paolo Abeni authored
Alexandra Winter says: ==================== s390/net: updates 2023-06-10 Please apply the following patch series for s390's ctcm and lcs drivers to netdev's net-next tree. Just maintenance patches, no functional changes. ==================== Link: https://lore.kernel.org/r/20230621134921.904217-1-wintera@linux.ibm.comSigned-off-by:
-
Thorsten Winkler authored
This LWN article explains the why scnprintf is preferred over snprintf in general https://lwn.net/Articles/69419/ Ie. snprintf() returns what *would* be the resulting length, while scnprintf() returns the actual length. Note that ctcm_print_statistics() writes the data into the kernel log and is therefore not suitable for sysfs_emit(). Observable behavior is not changed, as there may be dependencies. Reviewed-by:
Alexandra Winter <wintera@linux.ibm.com> Signed-off-by:
Thorsten Winkler <twinkler@linux.ibm.com> Signed-off-by:
-
Thorsten Winkler authored
Following the advice of the Documentation/filesystems/sysfs.rst. All sysfs related show()-functions should only use sysfs_emit() or sysfs_emit_at() when formatting the value to be returned to user space. Reviewed-by:
-
Thorsten Winkler authored
This LWN article explains the why scnprintf is preferred over snprintf in general https://lwn.net/Articles/69419/ Ie. snprintf() returns what *would* be the resulting length, while scnprintf() returns the actual length. Reported-by:
Jules Irenge <jbi.octave@gmail.com> Reviewed-by:
-
Thorsten Winkler authored
Following the advice of the Documentation/filesystems/sysfs.rst. All sysfs related show()-functions should only use sysfs_emit() or sysfs_emit_at() when formatting the value to be returned to user space. While at it, follow Linux kernel coding style and unify indentation Reported-by:
Joe Perches <joe@perches.com> Reviewed-by:
-
Paolo Abeni authored
Hao Lan says: ==================== net: hns3: There are some cleanup for the HNS3 ethernet driver There are some cleanup for the HNS3 ethernet driver. ==================== Link: https://lore.kernel.org/r/20230621123309.34381-1-lanhao@huawei.comSigned-off-by:
-
Peiyang Wang authored
Several functions in the hns3 driver have unused parameters. The compiler will warn about them when building with -Wunused-parameter option of hns3. Signed-off-by:
Peiyang Wang <wangpeiyang1@huawei.com> Signed-off-by:
Hao Lan <lanhao@huawei.com> Signed-off-by:
-
Hao Chen authored
Now, strncpy() in hns3_dbg_fill_content() use src-length as copy-length, it may result in dest-buf overflow. This patch is to fix intel compile warning for csky-linux-gcc (GCC) 12.1.0 compiler. The warning reports as below: hclge_debugfs.c:92:25: warning: 'strncpy' specified bound depends on the length of the source argument [-Wstringop-truncation] strncpy(pos, items[i].name, strlen(items[i].name)); hclge_debugfs.c:90:25: warning: 'strncpy' output truncated before terminating nul copying as many bytes from a string as its length [-Wstringop-truncation] strncpy(pos, result[i], strlen(result[i])); strncpy() use src-length as copy-length, it may result in dest-buf overflow. So,this patch add some values check to avoid this issue. Signed-off-by:
Hao Chen <chenhao418@huawei.com> Reported-by:
-
Jian Shen authored
The result of expression '(k ^ ~v) & k' is exactly the same with 'k & v', so simplify it. (k ^ ~v) & k == k & v The truth table (in non table form): k == 0, v == 0: (k ^ ~v) & k == (0 ^ ~0) & 0 == (0 ^ 1) & 0 == 1 & 0 == 0 k & v == 0 & 0 == 0 k == 0, v == 1: (k ^ ~v) & k == (0 ^ ~1) & 0 == (0 ^ 0) & 0 == 1 & 0 == 0 k & v == 0 & 1 == 0 k == 1, v == 0: (k ^ ~v) & k == (1 ^ ~0) & 1 == (1 ^ 1) & 1 == 0 & 1 == 0 k & v == 1 & 0 == 0 k == 1, v == 1: (k ^ ~v) & k == (1 ^ ~1) & 1 == (1 ^ 0) & 1 == 1 & 1 == 1 k & v == 1 & 1 == 1 Signed-off-by:
Jian Shen <shenjian15@huawei.com> Signed-off-by:
-
Jakub Kicinski authored
Merge tag 'wireless-next-2023-06-22' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next Johannes Berg says: ==================== Notable changes this time around: MAINTAINERS - add missing driver git trees ath11k - factory test mode support iwlwifi - config rework to drop test devices and split the different families - major update for new firmware and MLO stack - initial multi-link reconfiguration suppor - multi-BSSID and MLO improvements other - fix the last few W=1 warnings from GCC 13 - merged wireless tree to avoid conflicts * tag 'wireless-next-2023-06-22' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (245 commits) wifi: ieee80211: fix erroneous NSTR bitmap size checks wifi: rtlwifi: cleanup USB interface wifi: rtlwifi: simplify LED management wifi: ath10k: improve structure padding wifi: ath9k: convert msecs to jiffies where needed wifi: iwlwifi: mvm: Add support for IGTK in D3 resume flow wifi: iwlwifi: mvm: update two most recent GTKs on D3 resume flow wifi: iwlwifi: mvm: Refactor security key update after D3 wifi: mac80211: mark keys as uploaded when added by the driver wifi: iwlwifi: remove support of A0 version of FM RF wifi: iwlwifi: cfg: clean up Bz module firmware lines wifi: iwlwifi: pcie: add device id 51F1 for killer 1675 wifi: iwlwifi: bump FW API to 83 for AX/BZ/SC devices wifi: iwlwifi: cfg: remove trailing dash from FW_PRE constants wifi: iwlwifi: also unify Ma device configurations wifi: iwlwifi: also unify Sc device configurations wifi: iwlwifi: unify Bz/Gl device configurations wifi: iwlwifi: pcie: also drop jacket from info macro wifi: iwlwifi: remove support for *nJ devices wifi: iwlwifi: don't load old firmware for 22000 ... ==================== Link: https://lore.kernel.org/r/20230622185602.147650-2-johannes@sipsolutions.netSigned-off-by:
-
Jakub Kicinski authored
Merge tag 'linux-can-next-for-6.5-20230622' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next Marc Kleine-Budde says: ==================== pull-request: can-next 2023-06-22 The first patch is by Carsten Schmidt, targets the kvaser_usb driver and adds len8_dlc support. Marcel Hellwig's patch for the xilinx_can driver adds support for CAN transceivers via the PHY framework. Frank Jungclaus contributes 6+2 patches for the esd_usb driver in preparation for the upcoming CAN-USB/3 support. The 2 patches by Miquel Raynal for the sja1000 driver work around overruns stalls on the Renesas SoCs. The next 3 patches are by me and fix the coding style in the rx-offload helper and in the m_can and ti_hecc driver. Vincent Mailhol contributes 3 patches to fix and update the calculation of the length of CAN frames on the wire. Oliver Hartkopp's patch moves the CAN_RAW_FILTER_MAX definition into the correct header. The remaining 14 patches are by Jimmy Assarsson, target the kvaser_pciefd driver and bring various updates and improvements. * tag 'linux-can-next-for-6.5-20230622' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next: (33 commits) can: kvaser_pciefd: Use TX FIFO size read from CAN controller can: kvaser_pciefd: Refactor code can: kvaser_pciefd: Add len8_dlc support can: kvaser_pciefd: Use FIELD_{GET,PREP} and GENMASK where appropriate can: kvaser_pciefd: Sort register definitions can: kvaser_pciefd: Change return type for kvaser_pciefd_{receive,transmit,set_tx}_irq() can: kvaser_pciefd: Rename device ID defines can: kvaser_pciefd: Sort includes in alphabetic order can: kvaser_pciefd: Remove SPI flash parameter read functionality can: uapi: move CAN_RAW_FILTER_MAX definition to raw.h can: kvaser_pciefd: Define unsigned constants with type suffix 'U' can: kvaser_pciefd: Set hardware timestamp on transmitted packets can: kvaser_pciefd: Add function to set skb hwtstamps can: kvaser_pciefd: Remove handler for unused KVASER_PCIEFD_PACK_TYPE_EFRAME_ACK can: kvaser_pciefd: Remove useless write to interrupt register can: length: refactor frame lengths definition to add size in bits can: length: fix bitstuffing count can: length: fix description of the RRS field can: m_can: fix coding style can: ti_hecc: fix coding style ... ==================== Link: https://lore.kernel.org/r/20230622082658.571150-1-mkl@pengutronix.deSigned-off-by:
-
Piotr Gardocki authored
Commit ad72c4a0 introduced optimization to return from function quickly if the MAC address is not changing at all. It was reported that such change causes dev->addr_assign_type to not change to NET_ADDR_SET from _PERM or _RANDOM. Restore the old behavior and skip only call to ndo_set_mac_address. Fixes: ad72c4a0 ("net: add check for current MAC address in dev_set_mac_address") Reported-by:
Gal Pressman <gal@nvidia.com> Signed-off-by:
Piotr Gardocki <piotrx.gardocki@intel.com> Reviewed-by:
Jiri Pirko <jiri@nvidia.com> Link: https://lore.kernel.org/r/20230621132106.991342-1-piotrx.gardocki@intel.comSigned-off-by:
-
Edward Cree authored
When processing counter updates, if any action set using the newly incremented counter includes an encap action, prod the corresponding neighbouring entry to indicate to the neighbour cache that the entry is still in use and passing traffic. Signed-off-by:
Edward Cree <ecree.xilinx@gmail.com> Link: https://lore.kernel.org/r/20230621121504.17004-1-edward.cree@amd.comSigned-off-by:
-
Christian Marangi authored
The QCA8K switch supports additional modes that can be handled in hardware for the LED netdev trigger. Add these additional modes to further support the Switch LEDs and offload more blink modes. Add additional modes: - link_10 - link_100 - link_1000 - half_duplex - full_duplex Signed-off-by:
Christian Marangi <ansuelsmth@gmail.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Reviewed-by:
-
Christian Marangi authored
Document newly introduced modes and entry for the LED netdev trigger. Add documentation for new modes: - link_10 - link_100 - link_1000 - half_duplex - full_duplex Add documentation for new entry: - hw_control Also add additional info for the interval entry and the tx/rx modes with the special case of hw_control ON. Signed-off-by:
-
Ying Hsu authored
In a setup where a Thunderbolt hub connects to Ethernet and a display through USB Type-C, users may experience a hung task timeout when they remove the cable between the PC and the Thunderbolt hub. This is because the igb_down function is called multiple times when the Thunderbolt hub is unplugged. For example, the igb_io_error_detected triggers the first call, and the igb_remove triggers the second call. The second call to igb_down will block at napi_synchronize. Here's the call trace: __schedule+0x3b0/0xddb ? __mod_timer+0x164/0x5d3 schedule+0x44/0xa8 schedule_timeout+0xb2/0x2a4 ? run_local_timers+0x4e/0x4e msleep+0x31/0x38 igb_down+0x12c/0x22a [igb 6615058754948bfde0bf01429257eb59f13030d4] __igb_close+0x6f/0x9c [igb 6615058754948bfde0bf01429257eb59f13030d4] igb_close+0x23/0x2b [igb 6615058754948bfde0bf01429257eb59f13030d4] __dev_close_many+0x95/0xec dev_close_many+0x6e/0x103 unregister_netdevice_many+0x105/0x5b1 unregister_netdevice_queue+0xc2/0x10d unregister_netdev+0x1c/0x23 igb_remove+0xa7/0x11c [igb 6615058754948bfde0bf01429257eb59f13030d4] pci_device_remove+0x3f/0x9c device_release_driver_internal+0xfe/0x1b4 pci_stop_bus_device+0x5b/0x7f pci_stop_bus_device+0x30/0x7f pci_stop_bus_device+0x30/0x7f pci_stop_and_remove_bus_device+0x12/0x19 pciehp_unconfigure_device+0x76/0xe9 pciehp_disable_slot+0x6e/0x131 pciehp_handle_presence_or_link_change+0x7a/0x3f7 pciehp_ist+0xbe/0x194 irq_thread_fn+0x22/0x4d ? irq_thread+0x1fd/0x1fd irq_thread+0x17b/0x1fd ? irq_forced_thread_fn+0x5f/0x5f kthread+0x142/0x153 ? __irq_get_irqchip_state+0x46/0x46 ? kthread_associate_blkcg+0x71/0x71 ret_from_fork+0x1f/0x30 In this case, igb_io_error_detected detaches the network interface and requests a PCIE slot reset, however, the PCIE reset callback is not being invoked and thus the Ethernet connection breaks down. As the PCIE error in this case is a non-fatal one, requesting a slot reset can be avoided. This patch fixes the task hung issue and preserves Ethernet connection by ignoring non-fatal PCIE errors. Signed-off-by:Ying Hsu <yinghsu@chromium.org> Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel) Signed-off-by:
Tony Nguyen <anthony.l.nguyen@intel.com> Reviewed-by:
-
Jakub Kicinski authored
Rasmus Villemoes says: ==================== net: dsa: microchip: fix writes to phy registers >= 0x10 Patch 1 is just a simplification, technically unrelated to the other two patches. But it would be a bit inconsistent to have the new ksz_prmw32() introduced in patch 2 use ksz_rmw32() while leaving ksz_prmw8() as-is. The actual fix is of course patch 3. I can definitely see some weird behaviour on our ksz9567 when writing to phy registers 0x1e and 0x1f (with phytool from userspace), though it does not seem that the effect is always to write zeroes to the buddy register as the errata sheet says would be the case. In our case, the switch is connected via i2c; I hope somebody with other switches and/or the SPI variants can test this. ==================== Link: https://lore.kernel.org/r/20230620113855.733526-1-linux@rasmusvillemoes.dkSigned-off-by:
-
Rasmus Villemoes authored
According to the errata sheets for ksz9477 and ksz9567, writes to the PHY registers 0x10-0x1f (i.e. those located at addresses 0xN120 to 0xN13f) must be done as a 32 bit write to the 4-byte aligned address containing the register, hence requires a RMW in order not to change the adjacent PHY register. Signed-off-by:
Rasmus Villemoes <linux@rasmusvillemoes.dk> Reviewed-by:
-
Rasmus Villemoes authored
This will be used in a subsequent patch fixing an errata for writes to certain PHY registers. Signed-off-by:
Arun Ramadoss <arun.ramadoss@microchip.com> Link: https://lore.kernel.org/r/20230620113855.733526-3-linux@rasmusvillemoes.dkSigned-off-by:
-
Rasmus Villemoes authored
Implement ksz_prmw8() in terms of ksz_rmw8(), just as all the other ksz_pX are implemented in terms of ksz_X. No functional change. Signed-off-by:
-
Jakub Kicinski authored
Przemek suggests that I shouldn't accuse GCC of witchcraft, there is a simpler explanation for why we need manual define. scripts/headers_install.sh modifies the guard, removing _UAPI. That's why including a kernel header from the tree and from /usr leads to duplicate definitions. This also solves the mystery of why I needed to include the header conditionally. I had the wrong guards for most cases but ethtool. Suggested-by:
Przemek Kitszel <przemyslaw.kitszel@intel.com> Reviewed-by:
-
Zhengchao Shao authored
Half a year passed since commit 049fe536 ("net: txgbe: Add operations to interact with firmware") was submitted, the buffer in txgbe_calc_eeprom_checksum was not used. So remove it and the related branch codes. Reported-by:
Jiawen Wu <jiawenwu@trustnetic.com> Signed-off-by:
Zhengchao Shao <shaozhengchao@huawei.com> Reviewed-by:
-
Jakub Kicinski authored
Russell King says: ==================== Add and use helper for PCS negotiation modes Earlier this month, I proposed a helper for deciding whether a PCS should use inband negotiation modes or not. There was some discussion around this topic, and I believe there was no disagreement about providing the helper. The initial discussion can be found at: https://lore.kernel.org/r/ZGIkGmyL8yL1q1zp@shell.armlinux.org.uk Subsequently, I posted a RFC series back in May: https://lore.kernel.org/r/ZGzhvePzPjJ0v2En@shell.armlinux.org.uk that added a helper, phylink_pcs_neg_mode() which PCS drivers could use to parse the state, and updated a bunch of drivers to use it. I got a couple of bits of feedback to it, including some ACKs. However, I've decided to take this slightly further and change the "mode" parameter to both the pcs_config() and pcs_link_up() methods when a PCS driver opts in to this (by setting "neg_mode" in the phylink_pcs structure.) If this is not set, we default to the old behaviour. That said, this series converts all the PCS implementations I can find currently in net-next. Doing this has the added benefit that the negotiation mode parameter is also available to the pcs_link_up() function, which can now know whether inband negotiation was in fact enabled or not at pcs_config() time. It has been posted as RFC at: https://lore.kernel.org/r/ZIh/CLQ3z89g0Ua0@shell.armlinux.org.uk and received one reply, thanks Elad, which is a similar amount of interest to previous postings. Let's post it as non-RFC and see whether we get more reaction. ==================== Link: https://lore.kernel.org/r/ZIxQIBfO9dH5xFlg@shell.armlinux.org.ukSigned-off-by:
-
