summaryrefslogtreecommitdiff
path: root/Documentation
AgeCommit message (Collapse)Author
2025-05-09media: dt-bindings: Add amlogic,c3-mipi-adapter.yamlKeke Li
c3-mipi-adapter is used to organize mipi data and send raw data to ISP module. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Keke Li <keke.li@amlogic.com> Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
2025-05-09media: dt-bindings: Add amlogic,c3-mipi-csi2.yamlKeke Li
c3-mipi-csi2 is used to receive mipi data from image sensor. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Keke Li <keke.li@amlogic.com> Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
2025-05-09Add RZ/G3E xSPI supportMark Brown
Merge series from Biju Das <biju.das.jz@bp.renesas.com>: The xSPI IP found on RZ/G3E SoC similar to RPC-IF interface, but it can support writes on memory-mapped area. Even though the registers are different, the rpcif driver code can be reused for xSPI by adding wrapper functions.
2025-05-09dt-bindings: arm: add imx8mp-libra-rdk-fpscYannic Moog
imx8mp-libra-rdk-fpsc is a development board based on the phyCORE-i.MX 8M Plus FPSC SoM. Add its description and binding. The imx8mp-phycore-fpsc som differs from the existing phyCORE-i.MX 8M Plus (dts: imx8mp-phycore-som.dtsi) in its physical form regarding the ball grid array. Other differences between the SoMs are missing SPI-NOR on this SoM and 1.8V IO voltage instead of 3.3V as found on the existing imx8mp-phycore-som. As a result the imx8mp-phycore-som is not compatible with this new libra development board. Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Yannic Moog <y.moog@phytec.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2025-05-08virt: tdx-guest: Expose TDX MRs as sysfs attributesCedric Xing
Expose the most commonly used TDX MRs (Measurement Registers) as sysfs attributes. Use the ioctl() interface of /dev/tdx_guest to request a full TDREPORT for access to other TD measurements. Directory structure of TDX MRs inside a TDVM is as follows: /sys/class/misc/tdx_guest └── measurements ├── mrconfigid ├── mrowner ├── mrownerconfig ├── mrtd:sha384 ├── rtmr0:sha384 ├── rtmr1:sha384 ├── rtmr2:sha384 └── rtmr3:sha384 Read the file/attribute to retrieve the current value of an MR. Write to the file/attribute (if writable) to extend the corresponding RTMR. Refer to Documentation/ABI/testing/sysfs-devices-virtual-misc-tdx_guest for more information. Signed-off-by: Cedric Xing <cedric.xing@intel.com> Acked-by: Dionna Amalie Glaze <dionnaglaze@google.com> [djbw: fixup exit order] Link: https://patch.msgid.link/20250508010606.4129953-1-dan.j.williams@intel.com Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2025-05-08tsm-mr: Add TVM Measurement Register supportCedric Xing
Introduce new TSM Measurement helper library (tsm-mr) for TVM guest drivers to expose MRs (Measurement Registers) as sysfs attributes, with Crypto Agility support. Add the following new APIs (see include/linux/tsm-mr.h for details): - tsm_mr_create_attribute_group(): Take on input a `struct tsm_measurements` instance, which includes one `struct tsm_measurement_register` per MR with properties like `TSM_MR_F_READABLE` and `TSM_MR_F_WRITABLE`, to determine the supported operations and create the sysfs attributes accordingly. On success, return a `struct attribute_group` instance that will typically be included by the guest driver into `miscdevice.groups` before calling misc_register(). - tsm_mr_free_attribute_group(): Free the memory allocated to the attrubute group returned by tsm_mr_create_attribute_group(). tsm_mr_create_attribute_group() creates one attribute for each MR, with names following this pattern: MRNAME[:HASH] - MRNAME - Placeholder for the MR name, as specified by `tsm_measurement_register.mr_name`. - :HASH - Optional suffix indicating the hash algorithm associated with this MR, as specified by `tsm_measurement_register.mr_hash`. Support Crypto Agility by allowing multiple definitions of the same MR (i.e., with the same `mr_name`) with distinct HASH algorithms. NOTE: Crypto Agility, introduced in TPM 2.0, allows new hash algorithms to be introduced without breaking compatibility with applications using older algorithms. CC architectures may face the same challenge in the future, needing new hashes for security while retaining compatibility with older hashes, hence the need for Crypto Agility. Signed-off-by: Cedric Xing <cedric.xing@intel.com> Reviewed-by: Dan Williams <dan.j.williams@intel.com> Acked-by: Dionna Amalie Glaze <dionnaglaze@google.com> [djbw: fixup bin_attr const conflict] Link: https://patch.msgid.link/20250509020739.882913-1-dan.j.williams@intel.com Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2025-05-08media: dt-bindings: Document Tegra186 and Tegra194 cecAaron Kling
These are already used in device trees, so describe them here. As the driver only declares up through Tegra210, these must use a fallback compatible of tegra210-cec. Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Aaron Kling <webgeek1234@gmail.com> Link: https://lore.kernel.org/r/20250413-tegra-cec-v4-1-b6337b66ccad@gmail.com Signed-off-by: Thierry Reding <treding@nvidia.com>
2025-05-08dt-bindings: arm: tegra: Add Asus Transformer Pad TF300TLSvyatoslav Ryhel
Add a compatible for the Asus Transformer Pad TF300TL. Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com> Link: https://lore.kernel.org/r/20250503102950.32744-3-clamor95@gmail.com Signed-off-by: Thierry Reding <treding@nvidia.com>
2025-05-08dt-bindings: arm: tegra: Group Tegra30 based ASUS TransformersSvyatoslav Ryhel
Group Tegra30 based ASUS Transformers under a common description. Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com> Link: https://lore.kernel.org/r/20250503102950.32744-2-clamor95@gmail.com Signed-off-by: Thierry Reding <treding@nvidia.com>
2025-05-08dt-bindings: interrupt-controller: Convert nvidia,tegra20-ictlr to DT schemaRob Herring (Arm)
Convert the NVIDIA Legacy interrupt controller binding to schema format. It's a straight-forward conversion of the typical interrupt controller. All the possible compatibles were not documented, so add the ones in use. Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Link: https://lore.kernel.org/r/20250505144759.1291261-1-robh@kernel.org Signed-off-by: Thierry Reding <treding@nvidia.com>
2025-05-08dt-bindings: dma: nvidia,tegra20-apbdma: convert text based binding to json ↵Charan Pedumuru
schema Update text binding to YAML. Changes during conversion: - Add a fallback for "nvidia,tegra30-apbdma" as it is compatible with the IP core on "nvidia,tegra20-apbdma". - Update examples and include appropriate file directives to resolve errors identified by `dt_binding_check` and `dtbs_check`. Signed-off-by: Charan Pedumuru <charan.pedumuru@gmail.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20250507-nvidea-dma-v4-2-6161a8de376f@gmail.com Signed-off-by: Thierry Reding <treding@nvidia.com>
2025-05-08riscv: hwprobe: Document SiFive xsfvfwmaccqqq vendor extensionCyan Yang
Document the support for matrix multiply accumulate instruction from SiFive using RISCV_HWPROBE_VENDOR_EXT_XSFVFWMACCQQQ. Signed-off-by: Cyan Yang <cyan.yang@sifive.com> Link: https://lore.kernel.org/r/20250418053239.4351-12-cyan.yang@sifive.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2025-05-08dt-bindings: riscv: Add xsfvfwmaccqqq ISA extension descriptionCyan Yang
Add "xsfvfwmaccqqq" ISA extension which is provided by SiFive for matrix multiply accumulate instructions support. Signed-off-by: Cyan Yang <cyan.yang@sifive.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20250418053239.4351-10-cyan.yang@sifive.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2025-05-08riscv: hwprobe: Document SiFive xsfvfnrclipxfqf vendor extensionCyan Yang
Document the support for SiFive vendor extensions for FP32-to-int8 Ranged Clip Instructions using RISCV_HWPROBE_VENDOR_EXT_XSFVFNRCLIPXFQF. Signed-off-by: Cyan Yang <cyan.yang@sifive.com> Link: https://lore.kernel.org/r/20250418053239.4351-8-cyan.yang@sifive.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2025-05-08dt-bindings: riscv: Add xsfvfnrclipxfqf ISA extension descriptionCyan Yang
Add "xsfvfnrclipxfqf" ISA extension which is provided by SiFive for FP32-to-int8 ranged clip instructions support. Signed-off-by: Cyan Yang <cyan.yang@sifive.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20250418053239.4351-6-cyan.yang@sifive.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2025-05-08riscv: hwprobe: Document SiFive xsfvqmaccdod and xsfvqmaccqoq vendor extensionsCyan Yang
Document the support for sifive vendor extensions using the key RISCV_HWPROBE_KEY_VENDOR_EXT_SIFIVE_0 and two vendor extensions for SiFive Int8 Matrix Multiplication Instructions using RISCV_HWPROBE_VENDOR_EXT_XSFVQMACCDOD and RISCV_HWPROBE_VENDOR_EXT_XSFVQMACCQOQ. Signed-off-by: Cyan Yang <cyan.yang@sifive.com> Link: https://lore.kernel.org/r/20250418053239.4351-4-cyan.yang@sifive.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2025-05-08dt-bindings: riscv: Add xsfvqmaccdod and xsfvqmaccqoq ISA extension descriptionCyan Yang
Add "xsfvqmaccdod" and "xsfvqmaccqoq" ISA extensions which are provided by SiFive for int8 matrix multiplication instructions support. Signed-off-by: Cyan Yang <cyan.yang@sifive.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20250418053239.4351-2-cyan.yang@sifive.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2025-05-08Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski
Cross-merge networking fixes after downstream PR (net-6.15-rc6). No conflicts. Adjacent changes: net/core/dev.c: 08e9f2d584c4 ("net: Lock netdevices during dev_shutdown") a82dc19db136 ("net: avoid potential race between netdev_get_by_index_lock() and netns switch") Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-08dt-bindings: display: panel: Add Novatek NT37801Krzysztof Kozlowski
Add bindings for the Novatek NT37801 or NT37810 AMOLED DSI panel. Sources, like downstream DTS, schematics and hardware manuals, use two model names (NT37801 and NT37810), so choose one and hope it is correct. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20250508-sm8750-display-panel-v2-1-3ca072e3d1fa@linaro.org Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20250508-sm8750-display-panel-v2-1-3ca072e3d1fa@linaro.org
2025-05-08dt-bindings: display: panel: convert truly,nt35597.txt to dt-schemaNeil Armstrong
Convert the Truly NT35597 2K display panel bindings to dt-schema. The vdispp-supply & vdispn-supply are not marked as required since in practice they are not defined in sdm845-mtp.dts which is the only used of these bindings. Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20250507-topic-misc-truly-nt35597-yaml-v1-1-bc719ad8dfff@linaro.org Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20250507-topic-misc-truly-nt35597-yaml-v1-1-bc719ad8dfff@linaro.org
2025-05-08Merge tag 'net-6.15-rc6' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net Pull networking fixes from Paolo Abeni: "Including fixes from CAN, WiFi and netfilter. We have still a comple of regressions open due to the recent drivers locking refactor. The patches are in-flight, but not ready yet. Current release - regressions: - core: lock netdevices during dev_shutdown - sch_htb: make htb_deactivate() idempotent - eth: virtio-net: don't re-enable refill work too early Current release - new code bugs: - eth: icssg-prueth: fix kernel panic during concurrent Tx queue access Previous releases - regressions: - gre: fix again IPv6 link-local address generation. - eth: b53: fix learning on VLAN unaware bridges Previous releases - always broken: - wifi: fix out-of-bounds access during multi-link element defragmentation - can: - initialize spin lock on device probe - fix order of unregistration calls - openvswitch: fix unsafe attribute parsing in output_userspace() - eth: - virtio-net: fix total qstat values - mtk_eth_soc: reset all TX queues on DMA free - fbnic: firmware IPC mailbox fixes" * tag 'net-6.15-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (55 commits) virtio-net: fix total qstat values net: export a helper for adding up queue stats fbnic: Do not allow mailbox to toggle to ready outside fbnic_mbx_poll_tx_ready fbnic: Pull fbnic_fw_xmit_cap_msg use out of interrupt context fbnic: Improve responsiveness of fbnic_mbx_poll_tx_ready fbnic: Cleanup handling of completions fbnic: Actually flush_tx instead of stalling out fbnic: Add additional handling of IRQs fbnic: Gate AXI read/write enabling on FW mailbox fbnic: Fix initialization of mailbox descriptor rings net: dsa: b53: do not set learning and unicast/multicast on up net: dsa: b53: fix learning on VLAN unaware bridges net: dsa: b53: fix toggling vlan_filtering net: dsa: b53: do not program vlans when vlan filtering is off net: dsa: b53: do not allow to configure VLAN 0 net: dsa: b53: always rejoin default untagged VLAN on bridge leave net: dsa: b53: fix VLAN ID for untagged vlan on bridge leave net: dsa: b53: fix flushing old pvid VLAN on pvid change net: dsa: b53: fix clearing PVID of a port net: dsa: b53: keep CPU port always tagged again ...
2025-05-08arm64/fpsimd: ptrace/prctl: Ensure VL changes leave task in a valid stateMark Rutland
Currently, vec_set_vector_length() can manipulate a task into an invalid state as a result of a prctl/ptrace syscall which changes the SVE/SME vector length, resulting in several problems: (1) When changing the SVE vector length, if the task initially has PSTATE.ZA==1, and sve_alloc() fails to allocate memory, the task will be left with PSTATE.ZA==1 and sve_state==NULL. This is not a legitimate state, and could result in a subsequent null pointer dereference. (2) When changing the SVE vector length, if the task initially has PSTATE.SM==1, the task will be left with PSTATE.SM==1 and fp_type==FP_STATE_FPSIMD. Streaming mode state always needs to be saved in SVE format, so this is not a legitimate state. Attempting to restore this state may cause a task to erroneously inherit stale streaming mode predicate registers and FFR contents, behaving non-deterministically and potentially leaving information from another task. While in this state, reads of the NT_ARM_SSVE regset will indicate that the registers are not stored in SVE format. For the NT_ARM_SSVE regset specifically, debuggers interpret this as meaning that PSTATE.SM==0. (3) When changing the SME vector length, if the task initially has PSTATE.SM==1, the lower 128 bits of task's streaming mode vector state will be migrated to non-streaming mode, rather than these bits being zeroed as is usually the case for changes to PSTATE.SM. To fix the first issue, we can eagerly allocate the new sve_state and sme_state before modifying the task. This makes it possible to handle memory allocation failure without modifying the task state at all, and removes the need to clear TIF_SVE and TIF_SME. To fix the second issue, we either need to clear PSTATE.SM or not change the saved fp_type. Given we're going to eagerly allocate sve_state and sme_state, the simplest option is to preserve PSTATE.SM and the saves fp_type, and consistently truncate the SVE state. This ensures that the task always stays in a valid state, and by virtue of not exiting streaming mode, this also sidesteps the third issue. I believe these changes should not be problematic for realistic usage: * When the SVE/SME vector length is changed via prctl(), syscall entry will have cleared PSTATE.SM. Unless the task's state has been manipulated via ptrace after entry, the task will have PSTATE.SM==0. * When the SVE/SME vector length is changed via a write to the NT_ARM_SVE or NT_ARM_SSVE regsets, PSTATE.SM will be forced immediately after the length change, and new vector state will be copied from userspace. * When the SME vector length is changed via a write to the NT_ARM_ZA regset, the (S)SVE state is clobbered today, so anyone who cares about the specific state would need to install this after writing to the NT_ARM_ZA regset. As we need to free the old SVE state while TIF_SVE may still be set, we cannot use sve_free(), and using kfree() directly makes it clear that the free pairs with the subsequent assignment. As this leaves sve_free() unused, I've removed the existing sve_free() and renamed __sve_free() to mirror sme_free(). Fixes: 8bd7f91c03d8 ("arm64/sme: Implement traps and syscall handling for SME") Fixes: baa8515281b3 ("arm64/fpsimd: Track the saved FPSIMD state type separately to TIF_SVE") Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: David Spickett <david.spickett@arm.com> Cc: Luis Machado <luis.machado@arm.com> Cc: Marc Zyngier <maz@kernel.org> Cc: Mark Brown <broonie@kernel.org> Cc: Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/20250508132644.1395904-16-mark.rutland@arm.com Signed-off-by: Will Deacon <will@kernel.org>
2025-05-08arm64/fpsimd: Make clone() compatible with ZA lazy savingMark Rutland
Linux is intended to be compatible with userspace written to Arm's AAPCS64 procedure call standard [1,2]. For the Scalable Matrix Extension (SME), AAPCS64 was extended with a "ZA lazy saving scheme", where SME's ZA tile is lazily callee-saved and caller-restored. In this scheme, TPIDR2_EL0 indicates whether the ZA tile is live or has been saved by pointing to a "TPIDR2 block" in memory, which has a "za_save_buffer" pointer. This scheme has been implemented in GCC and LLVM, with necessary runtime support implemented in glibc and bionic. AAPCS64 does not specify how the ZA lazy saving scheme is expected to interact with thread creation mechanisms such as fork() and pthread_create(), which would be implemented in terms of the Linux clone syscall. The behaviour implemented by Linux and glibc/bionic doesn't always compose safely, as explained below. Currently the clone syscall is implemented such that PSTATE.ZA and the ZA tile are always inherited by the new task, and TPIDR2_EL0 is inherited unless the 'flags' argument includes CLONE_SETTLS, in which case TPIDR2_EL0 is set to 0/NULL. This doesn't make much sense: (a) TPIDR2_EL0 is part of the calling convention, and changes as control is passed between functions. It is *NOT* used for thread local storage, despite superficial similarity to TPIDR_EL0, which is is used as the TLS register. (b) TPIDR2_EL0 and PSTATE.ZA are tightly coupled in the procedure call standard, and some combinations of states are illegal. In general, manipulating the two independently is not guaranteed to be safe. In practice, code which is compliant with the procedure call standard may issue a clone syscall while in the "ZA dormant" state, where PSTATE.ZA==1 and TPIDR2_EL0 is non-null and indicates that ZA needs to be saved. This can cause a variety of problems, including: * If the implementation of pthread_create() passes CLONE_SETTLS, the new thread will start with PSTATE.ZA==1 and TPIDR2==NULL. Per the procedure call standard this is not a legitimate state for most functions. This can cause data corruption (e.g. as code may rely on PSTATE.ZA being 0 to guarantee that an SMSTART ZA instruction will zero the ZA tile contents), and may result in other undefined behaviour. * If the implementation of pthread_create() does not pass CLONE_SETTLS, the new thread will start with PSTATE.ZA==1 and TPIDR2 pointing to a TPIDR2 block on the parent thread's stack. This can result in a variety of problems, e.g. - The child may write back to the parent's za_save_buffer, corrupting its contents. - The child may read from the TPIDR2 block after the parent has reused this memory for something else, and consequently the child may abort or clobber arbitrary memory. Ideally we'd require that userspace ensures that a task is in the "ZA off" state (with PSTATE.ZA==0 and TPIDR2_EL0==NULL) prior to issuing a clone syscall, and have the kernel force this state for new threads. Unfortunately, contemporary C libraries do not do this, and simply forcing this state within the implementation of clone would break fork(). Instead, we can bodge around this by considering the CLONE_VM flag, and manipulate PSTATE.ZA and TPIDR2_EL0 as a pair. CLONE_VM indicates that the new task will run in the same address space as its parent, and in that case it doesn't make sense to inherit a stale pointer to the parent's TPIDR2 block: * For fork(), CLONE_VM will not be set, and it is safe to inherit both PSTATE.ZA and TPIDR2_EL0 as the new task will have its own copy of the address space, and cannot clobber its parent's stack. * For pthread_create() and vfork(), CLONE_VM will be set, and discarding PSTATE.ZA and TPIDR2_EL0 for the new task doesn't break any existing assumptions in userspace. Implement this behaviour for clone(). We currently inherit PSTATE.ZA in arch_dup_task_struct(), but this does not have access to the clone flags, so move this logic under copy_thread(). Documentation is updated to describe the new behaviour. [1] https://github.com/ARM-software/abi-aa/releases/download/2025Q1/aapcs64.pdf [2] https://github.com/ARM-software/abi-aa/blob/c51addc3dc03e73a016a1e4edf25440bcac76431/aapcs64/aapcs64.rst Suggested-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Mark Rutland <mark.rutland@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Daniel Kiss <daniel.kiss@arm.com> Cc: Marc Zyngier <maz@kernel.org> Cc: Mark Brown <broonie@kernel.org> Cc: Richard Sandiford <richard.sandiford@arm.com> Cc: Sander De Smalen <sander.desmalen@arm.com> Cc: Tamas Petz <tamas.petz@arm.com> Cc: Will Deacon <will@kernel.org> Cc: Yury Khrustalev <yury.khrustalev@arm.com> Acked-by: Yury Khrustalev <yury.khrustalev@arm.com> Link: https://lore.kernel.org/r/20250508132644.1395904-14-mark.rutland@arm.com Signed-off-by: Will Deacon <will@kernel.org>
2025-05-08Documentation: wmi: alienware-wmi: Add GPIO control documentationKurt Borja
Add documentation for the GPIO control methods. Reviewed-by: Armin Wolf <W_Armin@gmx.de> Signed-off-by: Kurt Borja <kuurtb@gmail.com> Link: https://lore.kernel.org/r/20250505-awcc-gpio-v4-2-edda44c3a0dc@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-05-08platform/x86: alienware-wmi-wmax: Expose GPIO debug methodsKurt Borja
Expose GPIO control methods present on the AWCC interface through DebugFS. These models come with an RGB lighting STM32 MCU, which usually has two GPIO pins with debug capabilities: - Pin 0: Device Firmware Update mode (DFU) - Pin 1: Negative Reset (NRST) Suggested-by: Gabriel Marcano <gabemarcano@yahoo.com> Reviewed-by: Armin Wolf <W_Armin@gmx.de> Signed-off-by: Kurt Borja <kuurtb@gmail.com> Link: https://lore.kernel.org/r/20250505-awcc-gpio-v4-1-edda44c3a0dc@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-05-08Documentation/ABI: Add new attribute for mlxreg-io sysfs interfacesVadim Pasternak
Add documentation for the new attributes: - Request and response for access to protetced flashes: "global_wp_request", "global_wp_response". Only for systems equipped with BMC - grant can be provided only by BMC in case its security policy allows to grant access. - Request to unlock ASICs, which has been shutdown due-to ASIC thermal event: "shutdown_unlock". - Data processor Units (DPU) boot progress: "boot_progress". - DPU reset causes: "reset_aux_pwr_or_reload", "reset_dpu_thermal", "reset_from_main_board". - Reset control for DPU components: "perst_rst", "phy_rst", "tpm_rst", "usbphy_rst". - DPU Unified Fabric Manager upgrade - "ufm_upgrade". - Hardware Id of Data Process Unit board - "dpu_id". Reviewed-by: Michael Shych <michaelsh@nvidia.com> Signed-off-by: Vadim Pasternak <vadimp@nvidia.com> Link: https://lore.kernel.org/r/20250504165507.9003-3-vadimp@nvidia.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-05-08dt-bindings: mux: add optional regulator binding to gpio muxSrinivas Kandagatla
On some platforms to minimise pop and click during switching between CTIA and OMTP headset an additional HiFi Mux Switch is used. Most common case is that this switch is switched on by default, but on some platforms this needs a regulator enable. One such platform is Lenovo T14s. Adds required bindings in gpio-mux to add such optional regulator. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by: Rob Herring (Arm) <robh@kernel.org> Link: https://lore.kernel.org/r/20250327100633.11530-2-srinivas.kandagatla@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2025-05-07netlink: specs: rt-link: remove implicit structs from devconfJakub Kicinski
devconf is even odder than SNMP. On input it reports an array of u32s which seem to be indexed by the enum values - 1. On output kernel expects a nest where each attr has the enum type as the nla type. sub-type: u32 is probably best we can do right now. Reviewed-by: Donald Hunter <donald.hunter@gmail.com> Link: https://patch.msgid.link/20250506194101.696272-5-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-07netlink: specs: remove implicit structs for SNMP countersJakub Kicinski
uAPI doesn't define structs for the SNMP counters, just enums to index them as arrays. Switch to the same representation in the spec. C codegen will soon need all the struct types to actually exist. Note that the existing definition was broken, anyway, as the first member should be the number of counters reported. Reviewed-by: Donald Hunter <donald.hunter@gmail.com> Link: https://patch.msgid.link/20250506194101.696272-4-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-07netlink: specs: ovs: correct struct namesJakub Kicinski
C codegen will soon support using struct types for binary attrs. Correct the struct names in OvS specs. Reviewed-by: Donald Hunter <donald.hunter@gmail.com> Link: https://patch.msgid.link/20250506194101.696272-3-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-07netlink: specs: nl80211: drop structs which are not uAPIJakub Kicinski
C codegen will soon use structs for binary types. A handful of structs in WiFi carry information elements from the wire, defined by the standard. The structs are not part of uAPI, so we can't use them in C directly. We could add them to the uAPI or add some annotation to tell the codegen to output a local version to the user header. The former seems arbitrary since we don't expose structs for most of the standard. The latter seems like a lot of work for a rare occurrence. Drop the struct info for now. Reviewed-by: Donald Hunter <donald.hunter@gmail.com> Link: https://lore.kernel.org/004030652d592b379e730be2f0344bebc4a03475.camel@sipsolutions.net Link: https://patch.msgid.link/20250506194101.696272-2-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-07Documentation:ipmi: Remove comments about interrupt levelCorey Minyard
Callbacks no longer run at interrupt level or bh, so remove those comments. Signed-off-by: Corey Minyard <cminyard@mvista.com>
2025-05-07Documentation/gpu: Add new entries to amdgpu glossaryRodrigo Siqueira
Add some additional entries. Signed-off-by: Rodrigo Siqueira <siqueira@igalia.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-05-07xfs: allow sysadmins to specify a maximum atomic write limit at mount timeDarrick J. Wong
Introduce a mount option to allow sysadmins to specify the maximum size of an atomic write. If the filesystem can work with the supplied value, that becomes the new guaranteed maximum. The value mustn't be too big for the existing filesystem geometry (max write size, max AG/rtgroup size). We dynamically recompute the tr_atomic_write transaction reservation based on the given block size, check that the current log size isn't less than the new minimum log size constraints, and set a new maximum. The actual software atomic write max is still computed based off of tr_atomic_ioend the same way it has for the past few commits. Note also that xfs_calc_atomic_write_log_geometry is non-static because mkfs will need that. Signed-off-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: John Garry <john.g.garry@oracle.com> Reviewed-by: John Garry <john.g.garry@oracle.com>
2025-05-07thermal: int340x: processor_thermal: Platform temperature control documentationSrinivas Pandruvada
Update documentation of attributes for platform temperature control. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Link: https://patch.msgid.link/20250429000110.236243-4-srinivas.pandruvada@linux.intel.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-05-07drm/xe/doc: Wire up PCIe Gen5 limitationsRaag Jadav
Append PCIe Gen5 limitations to xe_firmware document. Signed-off-by: Raag Jadav <raag.jadav@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/20250506054835.3395220-4-raag.jadav@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-05-07dt-bindings: clock: thead: Add TH1520 VO clock controllerMichal Wilczynski
Add device tree bindings for the TH1520 Video Output (VO) subsystem clock controller. The VO sub-system manages clock gates for multimedia components including HDMI, MIPI, and GPU. Document the VIDEO_PLL requirements for the VO clock controller, which receives its input from the AP clock controller. The VIDEO_PLL is a Silicon Creations Sigma-Delta (integer) PLL typically running at 792 MHz with maximum FOUTVCO of 2376 MHz. This binding complements the existing AP sub-system clock controller which manages CPU, DPU, GMAC and TEE PLLs. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Michal Wilczynski <m.wilczynski@samsung.com> Reviewed-by: Drew Fustini <drew@pdp7.com> Signed-off-by: Drew Fustini <drew@pdp7.com>
2025-05-07dt-bindings: arm: qcom: Add SM7150 Google Pixel 4aDanila Tikhonov
Google Pixel 4a (google,sunfish) is a smartphone based on the SM7150 SoC Signed-off-by: Danila Tikhonov <danila@jiaxyga.com> Link: https://lore.kernel.org/r/20250422213137.80366-15-danila@jiaxyga.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-05-07dt-bindings: PCI: pci-ep: Add support for iommu-map and msi-mapFrank Li
Document the use of (msi|iommu)-map for PCI Endpoint (EP) controllers, which can use MSI as a doorbell mechanism. Each EP controller can support up to 8 physical functions and 65,536 virtual functions. Define how to construct device IDs using function bits [2:0] and virtual function index bits [31:3], enabling (msi|iommu)-map to associate each child device with a specific (msi|iommu)-specifier. The EP cannot rely on PCI Requester ID (RID) because the RID is determined by the PCI topology of the host system. Since the EP may be connected to different PCI hosts, the RID can vary between systems and is therefore not a reliable identifier. Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Link: https://lore.kernel.org/all/20250414-ep-msi-v18-4-f69b49917464@nxp.com
2025-05-07dt-bindings: memory-controllers: Add STM32 Octo Memory Manager controllerPatrice Chotard
Add bindings for STM32 Octo Memory Manager (OMM) controller. OMM manages: - the muxing between 2 OSPI busses and 2 output ports. There are 4 possible muxing configurations: - direct mode (no multiplexing): OSPI1 output is on port 1 and OSPI2 output is on port 2 - OSPI1 and OSPI2 are multiplexed over the same output port 1 - swapped mode (no multiplexing), OSPI1 output is on port 2, OSPI2 output is on port 1 - OSPI1 and OSPI2 are multiplexed over the same output port 2 - the split of the memory area shared between the 2 OSPI instances. - chip select selection override. - the time between 2 transactions in multiplexed mode. Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Link: https://lore.kernel.org/r/20250428-upstream_ospi_v6-v11-1-1548736fd9d2@foss.st.com Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
2025-05-07docs: dmaengine: add explanation for DMA_ASYNC_TX capabilityKendra Moore
This patch replaces the TODO for DMA_ASYNC_TX in the DMA engine provider documentation. The flag is automatically set by the DMA framework when a device supports key asynchronous memory-to-memory operations such as memcpy, memset, xor, pq, xor_val, and pq_val. It must not be set by drivers directly. Signed-off-by: Kendra Moore <kendra.j.moore3443@gmail.com> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Message-ID: <20250421010205.84719-1-kendra.j.moore3443@gmail.com>
2025-05-07Documentation: leds: improve readibility of multicolor docJean-Michel Hautbois
When reading the documentation of multicolor leds, the HTML output is not easy to read. Improve it by adding a few markups, splitting the console in a dedicated block. Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@yoseli.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Message-ID: <20250421-leds-doc-v1-1-9a32df7fc6f4@yoseli.org>
2025-05-07docs: fix typo in firmware-related sectionAlexander Shatalin
Fix a minor grammar issue by changing 'firmwares' to 'firmware' in the Documentation/index.rst file. Signed-off-by: Alexander Shatalin <sashatalin03@gmail.com> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Message-ID: <20250430142726.3276-1-sashatalin03@gmail.com>
2025-05-07docs: Makefile: Inherit PYTHONPYCACHEPREFIX setting as env variableAkira Yokosawa
Commit 6c2f0b28d76e ("docs: Makefile: store __pycache__ at the output directory") assigns a new path to PYTHONPYCACHEPREFIX for building kernel documentation. However, it is not necessarily optimal for everyone. If you find PYTHONPYCACHEPREFIX is already set, it strongly suggests that the developer has selected the setting as best suited for one's own workflow. Use "?=" in the assignment to PYTHONPYCACHEPREFIX so that the path of $(abspath $(BUILDDIR)/__pycache__) works only as a safeguard. Signed-off-by: Akira Yokosawa <akiyks@gmail.com> Cc: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Message-ID: <0253ce98-960c-4498-8ace-a4354e3ebc26@gmail.com>
2025-05-07Documentation: ioctl-number: Update outdated submission infoBagas Sanjaya
Much like device numbers that used to be assigned by LANANA (see commit ebdf4040c16df5 ("Documentation: update the devices.txt documentation"), ioctl numbers list is maintained by general kernel community nowadays instead of contacting Michael directly as he's long stepped down from kernel-related activity (his last LKML message was from 2003 [1] and he's in CREDITS since the beginning of kernel's git history). Also, patch (including one to update ioctl numbers list) submission now follows process as described in Documentation/process/submitting-patches.rst rather than sending patches directly to Linus as in the distant past. Update the docs to reflect that. Link: https://lore.kernel.org/r/200305261446.h4QEkBVv023861@duracef.shout.net/ [1] Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Message-ID: <20250502074504.26933-2-bagasdotme@gmail.com>
2025-05-07dt-bindings: interrupt-controller: Convert openrisc,ompic to DT schemaRob Herring (Arm)
Convert the OpenRISC OMPIC interrupt controller binding to schema format. It's a straight-forward conversion of the typical interrupt controller. Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Stafford Horne <shorne@gmail.com>
2025-05-06Merge tag 'wireless-next-2025-05-06' of ↵Jakub Kicinski
https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next Johannes Berg says: ==================== wireless features, notably * stack - free SKBTX_WIFI_STATUS flag - fixes for VLAN multicast in multi-link - improve codel parameters (revert some old twiddling) * ath12k - Enable AHB support for IPQ5332. - Add monitor interface support to QCN9274. - Add MLO support to WCN7850. - Add 802.11d scan offload support to WCN7850. * ath11k - Restore hibernation support * iwlwifi - EMLSR on two 5 GHz links * mwifiex - cleanups/refactoring along with many other small features/cleanups * tag 'wireless-next-2025-05-06' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (177 commits) Revert "wifi: iwlwifi: clean up config macro" wifi: iwlwifi: move phy_filters to fw_runtime wifi: iwlwifi: pcie: make sure to lock rxq->read wifi: iwlwifi: add definitions for iwl_mac_power_cmd version 2 wifi: iwlwifi: clean up config macro wifi: iwlwifi: mld: simplify iwl_mld_rx_fill_status() wifi: iwlwifi: mld: rx: simplify channel handling wifi: iwlwifi: clean up band in RX metadata wifi: iwlwifi: mld: skip unknown FW channel load values wifi: iwlwifi: define API for external FSEQ images wifi: iwlwifi: mld: allow EMLSR on separated 5 GHz subbands wifi: iwlwifi: mld: use cfg80211_chandef_get_width() wifi: iwlwifi: mld: fix iwl_mld_emlsr_disallowed_with_link() return wifi: iwlwifi: mld: clarify variable type wifi: iwlwifi: pcie: add support for the reset handshake in MSI wifi: mac80211_hwsim: Prevent tsf from setting if beacon is disabled wifi: mac80211: restructure tx profile retrieval for MLO MBSSID wifi: nl80211: add link id of transmitted profile for MLO MBSSID wifi: ieee80211: Add helpers to fetch EMLSR delay and timeout values wifi: mac80211: update ML STA with EML capabilities ... ==================== Link: https://patch.msgid.link/20250506174656.119970-3-johannes@sipsolutions.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-06devlink: define enum for attr types of dynamic attributesJiri Pirko
Devlink param and health reporter fmsg use attributes with dynamic type which is determined according to a different type. Currently used values are NLA_*. The problem is, they are not part of UAPI. They may change which would cause a break. To make this future safe, introduce a enum that shadows NLA_* values in it and is part of UAPI. Also, this allows to possibly carry types that are unrelated to NLA_* values. Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: Jiri Pirko <jiri@nvidia.com> Link: https://patch.msgid.link/20250505114513.53370-3-jiri@resnulli.us Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-05-07This patch set did some clean up and add runtime pmMark Brown
Merge series from Haibo Chen <haibo.chen@nxp.com>: PATCH1/3/4 to clean up the code, make the code more readable PATCH2 add the runtime pm support PATCH5 use devm_add_action_or_reset() to replace remove() callback, this can avoid oops when do bind/unbind test
2025-05-07dt-bindings: soc: sophgo: add RTC support for Sophgo CV1800 seriesJingbao Qiu
Add RTC devicetree binding for Sophgo CV1800 series SoC. The device is called RTC, but contains control registers of other HW blocks in its address space, most notably of Power-on-Reset (PoR) module, DW8051 IP (MCU core), accompanying SRAM, hence putting it in SoC subsystem. Signed-off-by: Jingbao Qiu <qiujingbao.dlmu@gmail.com> Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Inochi Amaoto <inochiama@gmail.com> Link: https://lore.kernel.org/r/20250315224921.3627852-2-alexander.sverdlin@gmail.com Signed-off-by: Inochi Amaoto <inochiama@gmail.com> Signed-off-by: Chen Wang <unicorn_wang@outlook.com> Signed-off-by: Chen Wang <wangchen20@iscas.ac.cn>