summaryrefslogtreecommitdiff
path: root/include/linux
AgeCommit message (Collapse)Author
2026-01-26xdrgen: Add enum value validation to generated decodersChuck Lever
XDR enum decoders generated by xdrgen do not verify that incoming values are valid members of the enum. Incoming out-of-range values from malicious or buggy peers propagate through the system unchecked. Add validation logic to generated enum decoders using a switch statement that explicitly lists valid enumerator values. The compiler optimizes this to a simple range check when enum values are dense (contiguous), while correctly rejecting invalid values for sparse enums with gaps in their value ranges. The --no-enum-validation option on the source subcommand disables this validation when not needed. The minimum and maximum fields in _XdrEnum, which were previously unused placeholders for a range-based validation approach, have been removed since the switch-based validation handles both dense and sparse enums correctly. Because the new mechanism results in substantive changes to generated code, existing .x files are regenerated. Unrelated white space and semicolon changes in the generated code are due to recent commit 1c873a2fd110 ("xdrgen: Don't generate unnecessary semicolon") and commit 38c4df91242b ("xdrgen: Address some checkpatch whitespace complaints"). Reviewed-by: NeilBrown <neil@brown.name> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2026-01-26xdrgen: Initialize data pointer for zero-length itemsChuck Lever
The xdrgen decoders for strings and opaque data had an optimization that skipped calling xdr_inline_decode() when the item length was zero. This left the data pointer uninitialized, which could lead to unpredictable behavior when callers access it. Remove the zero-length check and always call xdr_inline_decode(). When passed a length of zero, xdr_inline_decode() returns the current buffer position, which is valid and matches the behavior of hand-coded XDR decoders throughout the kernel. Fixes: 4b132aacb076 ("tools: Add xdrgen") Reviewed-by: Jeff Layton <jlayton@kernel.org> Reviewed-by: NeilBrown <neil@brown.name> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2026-01-26xdrgen: Implement short (16-bit) integer typesChuck Lever
"short" and "unsigned short" types are not defined in RFC 4506, but are supported by the rpcgen program. An upcoming protocol specification includes at least one "unsigned short" field, so xdrgen needs to implement support for these types. Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
2026-01-26Merge branch 'fixes' of into for-nextIlpo Järvinen
2026-01-26Merge tag 'v6.19-rc7' into driver-core-nextDanilo Krummrich
We need the driver-core fixes in here as well to build on top of. Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-01-26ASoC: fsl_sai: Add AUDMIX mode support on i.MX952Shengjiu Wang
One of SAI interfaces is connected to AUDMIX in the i.MX952 chip, but AUDMIX can be bypassed or not bypassed on the i.MX952 platform. There are three use cases: 1) SAI -> Codec (No AUDMIX between SAI and Codec) 2) SAI -> Codec (Has AUDMIX, but AUDMIX is bypassed) 3) SAI -> AUDMIX -> Codec (Has AUDMIX and used) So add 'fsl,sai-amix-mode' property for this feature fsl,sai-amix-mode = "none": is for case 1) fsl,sai-amix-mode = "bypass": is for case 2) fsl,sai-amix-mode = "audmix": is for case 3) Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com> Link: https://patch.msgid.link/20260123082501.4050296-5-shengjiu.wang@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-26nubus: Call put_device() in bus initialization error pathFinn Thain
The error path for bus initialization is missing a call to put_device(). Add that call. This error path will probably never actually execute, but any kernel source code may be subject to static checking or re-use. Cc: Haoxiang Li <lihaoxiang@isrc.iscas.ac.cn> Cc: Daniel Palmer <daniel@0x0f.com> Suggested-by: Haoxiang Li <lihaoxiang@isrc.iscas.ac.cn> Signed-off-by: Finn Thain <fthain@linux-m68k.org> Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org> Link: https://patch.msgid.link/478d5f080d74b6688c9e3f9132e3fe251e997ad7.1765610469.git.fthain@linux-m68k.org Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
2026-01-26Merge tag 'coresight-next-v7.0' of ↵Greg Kroah-Hartman
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/coresight/linux into char-misc-next Suzuki writes: coresight: Updates for Linux v6.20/v7.0 This batch of CoreSight hwtracing updates contains : - Fine grained control of Timestamp generation in ETM4 trace, retaining backward compatibility - Feature updates for Qualcomm TPDA driver - Support Qualcomm Interconnect TNOC - Miscellaneous fixes to TMC-ETR driver Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> * tag 'coresight-next-v7.0' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/coresight/linux: (27 commits) coresight: tmc: Decouple the perf buffer allocation from sysfs mode coresight: tmc-etr: Fix race condition between sysfs and perf mode coresight: tmc: Add missing doc including reading and etr_mode of struct tmc_drvdata coresight-tnoc: Add runtime PM support for Interconnect TNOC coresight-tnoc: add platform driver to support Interconnect TNOC dt-bindings: arm: qcom: Add Coresight Interconnect TNOC coresight: etm3x: Fix cpulocked warning on cpuhp coresight: tpda: Fix intendation for sysfs interface documentation coresight: tpda: add sysfs node to flush specific port coresight: tpda: add logic to configure TPDA_SYNCR register coresight: tpda: add global_flush_req sysfs node coresight: tpda: add sysfs nodes for tpda cross-trigger configuration coresight: docs: Document etm4x timestamp interval option coresight: Extend width of timestamp format attribute coresight: Prepare to allow setting the timestamp interval coresight: Remove misleading definitions coresight: Interpret ETMv4 config with ATTR_CFG_GET_FLD() coresight: Interpret perf config with ATTR_CFG_GET_FLD() coresight: Don't reject unrecognized ETMv3 format attributes coresight: Interpret ETMv3 config with ATTR_CFG_GET_FLD() ...
2026-01-26Merge 6.19-rc7 into char-misc-nextGreg Kroah-Hartman
We need the char/misc/iio fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-01-25mm: add VM_SHADOW_STACK definition for riscvDeepak Gupta
VM_HIGH_ARCH_5 is used for riscv. Reviewed-by: Zong Li <zong.li@sifive.com> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Acked-by: David Hildenbrand <david@redhat.com> Signed-off-by: Deepak Gupta <debug@rivosinc.com> Tested-by: Andreas Korb <andreas.korb@aisec.fraunhofer.de> # QEMU, custom CVA6 Tested-by: Valentin Haudiquet <valentin.haudiquet@canonical.com> Link: https://patch.msgid.link/20251112-v5_user_cfi_series-v23-1-b55691eacf4f@rivosinc.com [pjw@kernel.org: clarify subject; update to apply] Signed-off-by: Paul Walmsley <pjw@kernel.org>
2026-01-25ipv4: igmp: annotate data-races around idev->mr_maxdelayEric Dumazet
idev->mr_maxdelay is read and written locklessly, add READ_ONCE()/WRITE_ONCE() annotations. While we are at it, make this field an u32. Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: David Ahern <dsahern@kernel.org> Link: https://patch.msgid.link/20260122172247.2429403-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-25net: expand NETDEV_RSS_KEY_LEN to 256 bytesEric Dumazet
NETDEV_RSS_KEY_LEN has been set to 52 bytes in 2014, until now. Jakub suggested we bump the size to 128 bytes or more. Some drivers (like idpf) were already working around the core limit. Since this change might cause some issues in admin scripts, bump it directly to 256 in one go. tjbp26:~# cat /proc/sys/net/core/netdev_rss_key | wc -c 768 tjbp26:~# ethtool -x eth1 RX flow hash indirection table for eth1 with 32 RX ring(s): ... RSS hash key: fe:16:5b:2f:93:85:c2:c9:c1:ef:bd:60:c6:e0:2b:99:4d:bf:b7:14:c8:1e:8d:cb:31:17:51:da:55:eb:91:d9:9e:f9:89:9b:44:a1:dc:08:72:3a:b3:d6:31:86:9a:fe:02:3a:0d:eb:a1:7c:f5:a3:51:3b:08:56:c9:3f:71:69:01:ba:70:38 RSS hash function: toeplitz: on xor: off crc32: off Suggested-by: Jakub Kicinski <kuba@kernel.org> Link: https://lore.kernel.org/netdev/20260122075206.504ec591@kernel.org/ Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20260122190349.2771064-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-25net: always inline skb_frag_unref() and __skb_frag_unref()Eric Dumazet
clang is not inlining skb_frag_unref() and __skb_frag_unref() in gro fast path. It also does not inline gro_try_pull_from_frag0(). Using __always_inline fixes this issue, makes the kernel faster _and_ smaller. Also change __skb_frag_ref(), skb_frag_ref() and skb_page_unref() to let them inlined for the last patch in this series. $ scripts/bloat-o-meter -t vmlinux.0 vmlinux.1 add/remove: 2/6 grow/shrink: 1/2 up/down: 218/-511 (-293) Function old new delta gro_pull_from_frag0 - 188 +188 __pfx_gro_pull_from_frag0 - 16 +16 skb_shift 1125 1139 +14 __pfx_skb_frag_unref 16 - -16 __pfx_gro_try_pull_from_frag0 16 - -16 __pfx___skb_frag_unref 16 - -16 __skb_frag_unref 36 - -36 skb_frag_unref 59 - -59 dev_gro_receive 1608 1514 -94 napi_gro_frags 892 771 -121 gro_try_pull_from_frag0 153 - -153 Total: Before=22566192, After=22565899, chg -0.00% Signed-off-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20260122045720.1221017-2-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-25u64_stats: Introduce u64_stats_copy()David Yang
The following (anti-)pattern was observed in the code tree: do { start = u64_stats_fetch_begin(&pstats->syncp); memcpy(&temp, &pstats->stats, sizeof(temp)); } while (u64_stats_fetch_retry(&pstats->syncp, start)); On 64bit arches, struct u64_stats_sync is empty and provides no help against load/store tearing, especially for memcpy(), for which arches may provide their highly-optimized implements. In theory the affected code should convert to u64_stats_t, or use READ_ONCE()/WRITE_ONCE() properly. However since there are needs to copy chunks of statistics, instead of writing loops at random places, we provide a safe memcpy() variant for u64_stats. Signed-off-by: David Yang <mmyangfl@gmail.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20260120092137.2161162-2-mmyangfl@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-25Merge tag 'char-misc-6.19-rc7' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc Pull char/misc/iio driver fixes from Greg KH: "Here are some small char/misc/iio and some other minor driver subsystem fixes for 6.19-rc7. Nothing huge here, just some fixes for reported issues including: - lots of little iio driver fixes - comedi driver fixes - mux driver fix - w1 driver fixes - uio driver fix - slimbus driver fixes - hwtracing bugfix - other tiny bugfixes All of these have been in linux-next for a while with no reported issues" * tag 'char-misc-6.19-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (36 commits) comedi: dmm32at: serialize use of paged registers mei: trace: treat reg parameter as string uio: pci_sva: correct '-ENODEV' check logic uacce: ensure safe queue release with state management uacce: implement mremap in uacce_vm_ops to return -EPERM uacce: fix isolate sysfs check condition uacce: fix cdev handling in the cleanup path slimbus: core: clean up of_slim_get_device() slimbus: core: fix of_slim_get_device() kernel doc slimbus: core: amend slim_get_device() kernel doc slimbus: core: fix device reference leak on report present slimbus: core: fix runtime PM imbalance on report present slimbus: core: fix OF node leak on registration failure intel_th: rename error label intel_th: fix device leak on output open() comedi: Fix getting range information for subdevices 16 to 255 mux: mmio: Fix IS_ERR() vs NULL check in probe() interconnect: debugfs: initialize src_node and dst_node to empty strings iio: dac: ad3552r-hs: fix out-of-bound write in ad3552r_hs_write_data_source iio: accel: iis328dq: fix gain values ...
2026-01-24bpf: support fsession for bpf_session_cookieMenglong Dong
Implement session cookie for fsession. The session cookies will be stored in the stack, and the layout of the stack will look like this: return value -> 8 bytes argN -> 8 bytes ... arg1 -> 8 bytes nr_args -> 8 bytes ip (optional) -> 8 bytes cookie2 -> 8 bytes cookie1 -> 8 bytes The offset of the cookie for the current bpf program, which is in 8-byte units, is stored in the "(((u64 *)ctx)[-1] >> BPF_TRAMP_COOKIE_INDEX_SHIFT) & 0xFF". Therefore, we can get the session cookie with ((u64 *)ctx)[-offset]. Implement and inline the bpf_session_cookie() for the fsession in the verifier. Signed-off-by: Menglong Dong <dongml2@chinatelecom.cn> Link: https://lore.kernel.org/r/20260124062008.8657-6-dongml2@chinatelecom.cn Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-01-24bpf: support fsession for bpf_session_is_returnMenglong Dong
If fsession exists, we will use the bit (1 << BPF_TRAMP_IS_RETURN_SHIFT) in ((u64 *)ctx)[-1] to store the "is_return" flag. The logic of bpf_session_is_return() for fsession is implemented in the verifier by inline following code: bool bpf_session_is_return(void *ctx) { return (((u64 *)ctx)[-1] >> BPF_TRAMP_IS_RETURN_SHIFT) & 1; } Signed-off-by: Menglong Dong <dongml2@chinatelecom.cn> Co-developed-by: Leon Hwang <leon.hwang@linux.dev> Signed-off-by: Leon Hwang <leon.hwang@linux.dev> Link: https://lore.kernel.org/r/20260124062008.8657-5-dongml2@chinatelecom.cn Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-01-24bpf: add fsession supportMenglong Dong
The fsession is something that similar to kprobe session. It allow to attach a single BPF program to both the entry and the exit of the target functions. Introduce the struct bpf_fsession_link, which allows to add the link to both the fentry and fexit progs_hlist of the trampoline. Signed-off-by: Menglong Dong <dongml2@chinatelecom.cn> Co-developed-by: Leon Hwang <leon.hwang@linux.dev> Signed-off-by: Leon Hwang <leon.hwang@linux.dev> Link: https://lore.kernel.org/r/20260124062008.8657-2-dongml2@chinatelecom.cn Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-01-24Merge tag 'driver-core-6.19-rc7' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core Pull driver core fixes from Danilo Krummrich: - Always inline I/O and IRQ methods using build_assert!() to avoid false positive build errors - Do not free the driver's device private data in I2C shutdown() avoiding race conditions that can lead to UAF bugs - Drop the driver's device private data after the driver has been fully unbound from its device to avoid UAF bugs from &Device<Bound> scopes, such as IRQ callbacks * tag 'driver-core-6.19-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core: rust: driver: drop device private data post unbind rust: driver: add DriverData type to the DriverLayout trait rust: driver: add DEVICE_DRIVER_OFFSET to the DriverLayout trait rust: driver: introduce a DriverLayout trait rust: auxiliary: add Driver::unbind() callback rust: i2c: do not drop device private data on shutdown() rust: irq: always inline functions using build_assert with arguments rust: io: always inline functions using build_assert with arguments
2026-01-23scsi: Change the return type of the .queuecommand() callbackBart Van Assche
In clang version 21.1 and later the -Wimplicit-enum-enum-cast warning option has been introduced. This warning is enabled by default and can be used to catch .queuecommand() implementations that return another value than 0 or one of the SCSI_MLQUEUE_* constants. Hence this patch that changes the return type of the .queuecommand() implementations from 'int' into 'enum scsi_qc_status'. No functionality has been changed. Cc: Damien Le Moal <dlemoal@kernel.org> Cc: John Garry <john.g.garry@oracle.com> Signed-off-by: Bart Van Assche <bvanassche@acm.org> Link: https://patch.msgid.link/20260115210357.2501991-6-bvanassche@acm.org Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2026-01-23Merge branch 'for-7.0/cxl-init' into cxl-for-nextDave Jiang
Merge in patches to support several patch series such as Soft Reserve handling, type2 accelerator enabling, and LSA 2.1 labeling support. Mainly addition of cxl_memdev_attach() to allow the memdev probe to make a decision of proceed/fail depending success of CXL topology enumeration. dax/hmem, e820, resource: Defer Soft Reserved insertion until hmem is ready cxl/mem: Introduce cxl_memdev_attach for CXL-dependent operation cxl/mem: Drop @host argument to devm_cxl_add_memdev() cxl/mem: Convert devm_cxl_add_memdev() to scope-based-cleanup cxl/port: Arrange for always synchronous endpoint attach cxl/mem: Arrange for always-synchronous memdev attach cxl/mem: Fix devm_cxl_memdev_edac_release() confusion
2026-01-23net: introduce mangleid_featuresPaolo Abeni
Some/most devices implementing gso_partial need to disable the GSO partial features when the IP ID can't be mangled; to that extend each of them implements something alike the following[1]: if (skb->encapsulation && !(features & NETIF_F_TSO_MANGLEID)) features &= ~NETIF_F_TSO; in the ndo_features_check() op, which leads to a bit of duplicate code. Later patch in the series will implement GSO partial support for virtual devices, and the current status quo will require more duplicate code and a new indirect call in the TX path for them. Introduce the mangleid_features mask, allowing the core to disable NIC features based on/requiring MANGLEID, without any further intervention from the driver. The same functionality could be alternatively implemented adding a single boolean flag to the struct net_device, but would require an additional checks in ndo_features_check(). Also note that [1] is incorrect if the NIC additionally implements NETIF_F_GSO_UDP_L4, mangleid_features transparently handle even such a case. Signed-off-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/5a7cdaeea40b0a29b88e525b6c942d73ed3b8ce7.1769011015.git.pabeni@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-23tty: tty_port: add workqueue to flip TTY bufferXin Zhao
On the embedded platform, certain critical data, such as IMU data, is transmitted through UART. The tty_flip_buffer_push() interface in the TTY layer uses system_dfl_wq to handle the flipping of the TTY buffer. Although the unbound workqueue can create new threads on demand and wake up the kworker thread on an idle CPU, it may be preempted by real-time tasks or other high-prio tasks. flush_to_ldisc() needs to wake up the relevant data handle thread. When executing __wake_up_common_lock(), it calls spin_lock_irqsave(), which does not disable preemption but disables migration in RT-Linux. This prevents the kworker thread from being migrated to other cores by CPU's balancing logic, resulting in long delays. The call trace is as follows: __wake_up_common_lock __wake_up ep_poll_callback __wake_up_common __wake_up_common_lock __wake_up n_tty_receive_buf_common n_tty_receive_buf2 tty_ldisc_receive_buf tty_port_default_receive_buf flush_to_ldisc In our system, the processing interval for each frame of IMU data transmitted via UART can experience significant jitter due to this issue. Instead of the expected 10 to 15 ms frame processing interval, we see spikes up to 30 to 35 ms. Moreover, in just one or two hours, there can be 2 to 3 occurrences of such high jitter, which is quite frequent. This jitter exceeds the software's tolerable limit of 20 ms. Introduce flip_wq in tty_port which can be set by tty_port_link_wq() or as default linked to default workqueue allocated when tty_register_driver(). The default workqueue is allocated with flag WQ_SYSFS, so that cpumask and nice can be set dynamically. The execution timing of tty_port_link_wq() is not clearly restricted. The newly added function tty_port_link_driver_wq() checks whether the flip_wq of the tty_port has already been assigned when linking the default tty_driver's workqueue to the port. After the user has set a custom workqueue for a certain tty_port using tty_port_link_wq(), the system will only use this custom workqueue, even if tty_driver does not have %TTY_DRIVER_CUSTOM_WORKQUEUE flag. Introduce %TTY_DRIVER_CUSTOM_WORKQUEUE flag meaning not to create the default single tty_driver workqueue. Two reasons why need to introduce the %TTY_DRIVER_CUSTOM_WORKQUEUE flag: 1. If the WQ_SYSFS parameter is enabled, workqueue_sysfs_register() will fail when trying to create a workqueue with the same name. The pty is an example of this; if both CONFIG_LEGACY_PTYS and CONFIG_UNIX98_PTYS are enabled, the call to tty_register_driver() in unix98_pty_init() will fail. 2. Different tty ports may be used for different tasks, which may require separate core binding control via workqueues. In this case, the workqueue created by default in the tty driver is unnecessary. Enabling this flag prevents the creation of this redundant workqueue. After applying this patch, we can set the related UART TTY flip buffer workqueue by sysfs. We set the cpumask to CPU cores associated with the IMU tasks, and set the nice to -20. Testing has shown significant improvement in the previously described issue, with almost no stuttering occurring anymore. Signed-off-by: Xin Zhao <jackzxcui1989@163.com> Reviewed-by: Jiri Slaby <jirislaby@kernel.org> Link: https://patch.msgid.link/20251223034836.2625547-1-jackzxcui1989@163.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-01-23usb: phy: tegra: add HSIC supportSvyatoslav Ryhel
Add support for HSIC USB mode, which can be set for second USB controller and PHY on Tegra SoC along with already supported UTMI or ULPI. Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com> Link: https://patch.msgid.link/20260122151125.7367-3-clamor95@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-01-23usb: phy: tegra: use phy type directlySvyatoslav Ryhel
Refactor to directly use enum usb_phy_interface to determine the PHY mode. This change is in preparation for adding support for HSIC mode. Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com> Link: https://patch.msgid.link/20260122151125.7367-2-clamor95@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-01-23usb: typec: Introduce mode_selection bitAndrei Kuchynski
The port driver sets this bit for an alternate mode description to indicate support for the mode selection feature. Once set, individual Alt Mode drivers will no longer attempt to activate their respective modes within their probe functions. This prevents race conditions and non-prioritized activation. The bit is not set by default. If left unset, the system retains the current behavior where Alt Mode drivers manage their own activation logic. Signed-off-by: Andrei Kuchynski <akuchynski@chromium.org> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://patch.msgid.link/20260119131824.2529334-6-akuchynski@chromium.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-01-23usb: typec: Implement mode selectionAndrei Kuchynski
The mode selection process is controlled by the following API functions, which allow to initiate and complete mode entry based on the priority of each mode: `typec_mode_selection_start` function compiles a priority list of supported Alternate Modes. `typec_altmode_state_update` function is invoked by the port driver to communicate the current mode of the Type-C connector. `typec_mode_selection_delete` function stops the currently running mode selection process and releases all associated system resources. `mode_selection_work_fn` task attempts to activate modes. The process stops on success; otherwise, it proceeds to the next mode after a timeout or error. Signed-off-by: Andrei Kuchynski <akuchynski@chromium.org> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://patch.msgid.link/20260119131824.2529334-5-akuchynski@chromium.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-01-23usb: typec: Expose alternate mode priority via sysfsAndrei Kuchynski
This patch introduces a priority sysfs attribute to the USB Type-C alternate mode port interface. This new attribute allows user-space to configure the numeric priority of alternate modes managing their preferred order of operation. If a new priority value conflicts with an existing mode's priority, the priorities of the conflicting mode and all subsequent modes are automatically incremented to ensure uniqueness. Signed-off-by: Andrei Kuchynski <akuchynski@chromium.org> Reviewed-by: Benson Leung <bleung@chromium.org> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://patch.msgid.link/20260119131824.2529334-4-akuchynski@chromium.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-01-23usb: typec: Add mode_control field to port propertyAndrei Kuchynski
This new field in the port properties dictates whether the Platform Policy Manager (PPM) allows the OS Policy Manager (OPM) to change the currently active, negotiated alternate mode. Signed-off-by: Andrei Kuchynski <akuchynski@chromium.org> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by: Benson Leung <bleung@chromium.org> Link: https://patch.msgid.link/20260119131824.2529334-2-akuchynski@chromium.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-01-23fsnotify: Track inode connectors for a superblockJan Kara
Introduce a linked list tracking all inode connectors for a superblock. We will use this list when the superblock is getting shutdown to properly clean up all the inode marks instead of relying on scanning all inodes in the superblock which can get rather slow. Suggested-by: Amir Goldstein <amir73il@gmail.com> Reviewed-by: Amir Goldstein <amir73il@gmail.com> Reviewed-by: Christian Brauner <brauner@kernel.org> Signed-off-by: Jan Kara <jack@suse.cz>
2026-01-23firmware: xilinx: Add firmware API's to support aes-gcm in Versal deviceHarsh Jain
Add aes-gcm crypto API's for AMD/Xilinx Versal device. Signed-off-by: Harsh Jain <h.jain@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-01-23firmware: zynqmp: Add helper API to self discovery the deviceHarsh Jain
Add API to get SoC version and family info. Signed-off-by: Harsh Jain <h.jain@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-01-23firmware: zynqmp: Move crypto API's to separate fileHarsh Jain
For better maintainability move crypto related API's to new zynqmp-crypto.c file. Signed-off-by: Harsh Jain <h.jain@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2026-01-22Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski
Cross-merge networking fixes after downstream PR (net-6.19-rc7). Conflicts: drivers/net/ethernet/huawei/hinic3/hinic3_irq.c b35a6fd37a00 ("hinic3: Add adaptive IRQ coalescing with DIM") fb2bb2a1ebf7 ("hinic3: Fix netif_queue_set_napi queue_index input parameter error") https://lore.kernel.org/fc0a7fdf08789a52653e8ad05281a0a849e79206.1768915707.git.zhuyikai1@h-partners.com drivers/net/wireless/ath/ath12k/mac.c drivers/net/wireless/ath/ath12k/wifi7/hw.c 31707572108d ("wifi: ath12k: Fix wrong P2P device link id issue") c26f294fef2a ("wifi: ath12k: Move ieee80211_ops callback to the arch specific module") https://lore.kernel.org/20260114123751.6a208818@canb.auug.org.au Adjacent changes: drivers/net/wireless/ath/ath12k/mac.c 8b8d6ee53dfd ("wifi: ath12k: Fix scan state stuck in ABORTING after cancel_remain_on_channel") 914c890d3b90 ("wifi: ath12k: Add framework for hardware specific ieee80211_ops registration") Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-23Merge tag 'drm-misc-next-2026-01-22' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-next drm-misc-next for 6.20: Core Changes: - buddy: Fix free_trees memory leak, prevent a BUG_ON - dma-buf: Start to introduce cgroup memory accounting in heaps, Remove sysfs stats, add new tracepoints - hdmi: Limit infoframes exposure to userspace based on driver capabilities - property: Account for property blobs in memcg Driver Changes: - atmel-hlcdc: Switch to drmm resources, Support nomodeset parameter, various patches to use newish helpers and fix memory safety bugs - hisilicon: Fix various DisplayPort related bugs - imagination: Introduce hardware version checks - renesas: Fix kernel panic on reboot - rockchip: Fix RK3576 HPD interrupt handling, Improve RK3588 HPD interrupt handling - v3d: Convert to drm logging helpers - bridge: - Continuation of the refcounting effort - new bridge: Algoltek AG6311 - panel: - new panel: Anbernic RG-DS Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maxime Ripard <mripard@redhat.com> Link: https://patch.msgid.link/20260122-antique-sexy-junglefowl-1bc5a8@houat
2026-01-22net: stmmac: dwmac-imx: keep preamble before sfd on i.MX8MPStefan Eichenberger
The stmmac implementation used by NXP for the i.MX8MP SoC is subject to errata ERR050694. According to this errata, when no preamble byte is transferred before the SFD from the PHY to the MAC, the MAC will discard the frame. Setting the PHY_F_KEEP_PREAMBLE_BEFORE_SFD flag instructs PHYs that support it to keep the preamble byte before the SFD. This ensures that the MAC successfully receives frames. As this is an issue in the MAC implementation, only enable the flag for the i.MX8MP SoC where the errata applies but not for other SoCs using a working stmmac implementation. The exact wording of the errata ERR050694 from NXP: The IEEE 802.3 standard states that, in MII/GMII modes, the byte preceding the SFD (0xD5), SMD-S (0xE6,0x4C, 0x7F, or 0xB3), or SMD-C (0x61, 0x52, 0x9E, or 0x2A) byte can be a non-PREAMBLE byte or there can be no preceding preamble byte. The MAC receiver must successfully receive a packet without any preamble(0x55) byte preceding the SFD, SMD-S, or SMD-C byte. However due to the defect, in configurations where frame preemption is enabled, when preamble byte does not precede the SFD, SMD-S, or SMD-C byte, the received packet is discarded by the MAC receiver. This is because, the start-of-packet detection logic of the MAC receiver incorrectly checks for a preamble byte. NXP refers to IEEE 802.3 where in clause 35.2.3.2.2 Receive case (GMII) they show two tables one where the preamble is preceding the SFD and one where it is not. The text says: The operation of 1000 Mb/s PHYs can result in shrinkage of the preamble between transmission at the source GMII and reception at the destination GMII. Table 35-3 depicts the case where no preamble bytes are conveyed across the GMII. This case may not be possible with a specific PHY, but illustrates the minimum preamble with which MAC shall be able to operate. Table 35-4 depicts the case where the entire preamble is conveyed across the GMII. This workaround was tested on a Verdin iMX8MP by enforcing 10 MBit/s: ethtool -s end0 speed 10 Without keeping the preamble, no packet were received. With keeping the preamble, everything worked as expected. Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Tested-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Link: https://patch.msgid.link/20260120203905.23805-4-eichest@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-22net: phy: add a new phy_device flag to keep preamble before sfdStefan Eichenberger
Add a new flag, PHY_F_KEEP_PREAMBLE_BEFORE_SFD, to indicate that the PHY shall not remove the preamble before the SFD if it supports it. MACs that do not support receiving frames without a preamble can set this flag. Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Tested-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Link: https://patch.msgid.link/20260120203905.23805-2-eichest@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-22PCI/IDE: Fix off by one error calculating VF RID rangeLi Ming
The VF ID range of an SR-IOV device is [0, num_VFs - 1]. pci_ide_stream_alloc() mistakenly uses num_VFs to represent the last ID. Fix that off by one error to stay in bounds of the range. Fixes: 1e4d2ff3ae45 ("PCI/IDE: Add IDE establishment helpers") Signed-off-by: Li Ming <ming.li@zohomail.com> Reviewed-by: Xu Yilun <yilun.xu@linux.intel.com> Link: https://patch.msgid.link/20260114111455.550984-1-ming.li@zohomail.com Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2026-01-22Revert "PCI/TSM: Report active IDE streams"Dan Williams
The proposed ABI failed to account for multiple host bridges with the same stream name. The fix needs to namespace streams or otherwise link back to the host bridge, but a change like that is too big for a fix. Given this ABI never saw a released kernel, delete it for now and bring it back later with this issue addressed. Reported-by: Xu Yilun <yilun.xu@linux.intel.com> Reported-by: Yi Lai <yi1.lai@intel.com> Closes: http://lore.kernel.org/20251223085601.2607455-1-yilun.xu@linux.intel.com Link: http://patch.msgid.link/6972c872acbb9_1d3310035@dwillia2-mobl4.notmuch Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2026-01-22PCI/AER: Export pci_aer_unmask_internal_errors()Terry Bowman
Internal PCIe errors are not enabled by default during initialization because their behavior is too device-specific and there is no standard way to reason about them. However, for CXL an internal error is the standard mechanism for conveying CXL protocol errors. Export pci_aer_unmask_internal_errors() for CXL, but make it clear that they are only meant for CXL and the status quo for leaving them masked for PCIe in general remains. Signed-off-by: Terry Bowman <terry.bowman@amd.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Link: https://patch.msgid.link/20260114182055.46029-10-terry.bowman@amd.com Co-developed-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Dave Jiang <dave.jiang@intel.com>
2026-01-22PCI: Introduce pcie_is_cxl()Terry Bowman
CXL is a protocol that runs on top of PCIe electricals. Its error model also runs on top of the PCIe AER error model by standardizing "internal" errors as "CXL" errors. Linux has historically ignored internal errors. CXL protocol error handling is then a task of enhancing the PCIe AER core to understand that PCIe ports (upstream and downstream) and endpoints may throw internal errors that represent standard CXL protocol errors. The proposed method to make that determination is to teach 'struct pci_dev' to cache when its link has trained the CXL.mem and/or CXL.cache protocols and then treat all internal errors as CXL errors. A design goal is to not burden the PCIe AER core with CXL knowledge beyond just enough to forward error notifications to the CXL RAS core. The forwarded notification looks up a 'struct cxl_port' or 'struct cxl_dport' companion device to the PCI device. Introduce set_pcie_cxl() with logic checking for CXL.mem or CXL.cache status in the CXL Flex Bus DVSEC status register. The CXL Flex Bus DVSEC presence is used because it is required for all the CXL PCIe devices.[1] [1] CXL 3.1 Spec, 8.1.1 PCIe Designated Vendor-Specific Extended Capability (DVSEC) ID Assignment, Table 8-2 Signed-off-by: Terry Bowman <terry.bowman@amd.com> Reviewed-by: Ira Weiny <ira.weiny@intel.com> Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Alejandro Lucero <alucerop@amd.com> Reviewed-by: Ben Cheatham <benjamin.cheatham@amd.com> Reviewed-by: Dan Williams <dan.j.williams@intel.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20260114182055.46029-4-terry.bowman@amd.com Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Dave Jiang <dave.jiang@intel.com>
2026-01-22units: add conversion macros for percentage related unitsJonathan Santos
Add macros to convert between ratio and percentage related units, including percent (1/100), permille (1/1,000), permyriad (1/10,000, also equivalent to one Basis point) and per cent mille (1/100,000). Those are Used for precise fractional calculations in engineering, finance, and measurement applications. Signed-off-by: Jonathan Santos <Jonathan.Santos@analog.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2026-01-22iio: core: Add cleanup.h support for iio_device_claim_*()Kurt Borja
Add guard classes for iio_device_claim_*() conditional locks. This will aid drivers write safer and cleaner code when dealing with some common patterns. These classes are not meant to be used directly by drivers (hence the __priv__ prefix). Instead, documented wrapper macros are provided to enforce the use of ACQUIRE() or guard() semantics and avoid the problematic scoped guard. Suggested-by: Andy Shevchenko <andriy.shevchenko@intel.com> Reviewed-by: David Lechner <dlechner@baylibre.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Acked-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Kurt Borja <kuurtb@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2026-01-22iio: core: Match iio_device_claim_*() semantics and implementationKurt Borja
Implement iio_device_claim_buffer_mode() fully inline with the use of __iio_dev_mode_lock(), which takes care of sparse annotations. To completely match iio_device_claim_direct() semantics, we need to also change iio_device_claim_buffer_mode() return semantics to usual true/false conditional lock semantics. Additionally, to avoid silently breaking out-of-tree drivers, rename iio_device_claim_buffer_mode() to iio_device_claim_try_buffer_mode(). Reviewed-by: David Lechner <dlechner@baylibre.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Signed-off-by: Kurt Borja <kuurtb@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2026-01-22iio: core: Refactor iio_device_claim_direct() implementationKurt Borja
In order to eventually unify the locking API, implement iio_device_claim_direct() fully inline, with the use of __iio_dev_mode_lock(), which takes care of sparse annotations. Reviewed-by: David Lechner <dlechner@baylibre.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Signed-off-by: Kurt Borja <kuurtb@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2026-01-22iio: core: Add and export __iio_dev_mode_lock()Kurt Borja
Add unconditional wrappers around the internal IIO mode lock. As mentioned in the documentation, this is not meant to be used by drivers, instead this will aid in the eventual addition of cleanup classes around conditional locks. Reviewed-by: David Lechner <dlechner@baylibre.com> Reviewed-by: Nuno Sá <nuno.sa@analog.com> Signed-off-by: Kurt Borja <kuurtb@gmail.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2026-01-22Merge remote-tracking branch 'i3c/ib-i3c-iio-v6.20' into togregJonathan Cameron
Needed for some stubs to prevent build issues if !CONFIG_I3C
2026-01-22driver-core: move devres_for_each_res() to base.hDanilo Krummrich
devres_for_each_res() is only used by .../firmware_loader/main.c, which already includes base.h. The usage of devres_for_each_res() by code outside of driver-core is questionable, hence move it to base.h. Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://patch.msgid.link/20260119162920.77189-1-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-01-22mfd: axp20x: AXP717: Add type-C CC registersChen-Yu Tsai
The AXP717 has some extra registers related to type-C CC pin negotiation. They were missing from the original submission. Add them for completeness. Signed-off-by: Chen-Yu Tsai <wens@kernel.org> Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://patch.msgid.link/20251225080241.3153453-1-wens@kernel.org Signed-off-by: Lee Jones <lee@kernel.org>
2026-01-22mfd: tps65219: Implement LOCK register handling for TPS65214Kory Maincent (TI.com)
The TPS65214 PMIC variant has a LOCK_REG register that prevents writes to nearly all registers when locked. Unlock the registers at probe time and leave them unlocked permanently. This approach is justified because: - Register locking is very uncommon in typical system operation - No code path is expected to lock the registers during runtime - Adding a custom regmap write function would add overhead to every register write, including voltage changes triggered by CPU OPP transitions from the cpufreq governor which could happen quite frequently Cc: stable@vger.kernel.org Fixes: 7947219ab1a2d ("mfd: tps65219: Add support for TI TPS65214 PMIC") Reviewed-by: Andrew Davis <afd@ti.com> Signed-off-by: Kory Maincent (TI.com) <kory.maincent@bootlin.com> Link: https://patch.msgid.link/20251218-fix_tps65219-v5-1-8bb511417f3a@bootlin.com Signed-off-by: Lee Jones <lee@kernel.org>
generated by cgit v1.2.3 (git 2.25.1) at 2026-08-11 09:08:01 +0000