summaryrefslogtreecommitdiff
path: root/Documentation
AgeCommit message (Collapse)AuthorFilesLines
2025-05-09bindings: arm: fsl: Add PHYTEC phyBOARD-Nash-i.MX93 boardPrimoz Fiser1-2/+4
Add devicetree bindings for PHYTEC phyBOARD-Nash-i.MX93 board based on the existing PHYTEC phyCORE-i.MX93 SoM (System-on-Module). Adjust the compatibles for the existing phyBOARD-Segin-i.MX93 board, to be able to add additional board based on the phyCORE-i.MX93 SoM. Signed-off-by: Primoz Fiser <primoz.fiser@norik.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2025-05-09dt: bindings: arm: add bindings for TQMa95xxSAAlexander Stein1-0/+10
TQMa95xxSA is a SOM using NXP i.MX95 CPU. MB-SMARC-2 is a carrier reference design. [1] https://www.tq-group.com/en/products/tq-embedded/arm-architecture/tqma95xxsa/ Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2025-05-09dt-bindings: mfd: Add max77759 bindingAndré Draszik1-0/+99
The Maxim MAX77759 is a companion PMIC for USB Type-C applications and includes Battery Charger, Fuel Gauge, temperature sensors, USB Type-C Port Controller (TCPC), NVMEM, and a GPIO expander. This describes the top-level device. Signed-off-by: André Draszik <andre.draszik@linaro.org> Reviewed-by: "Rob Herring (Arm)" <robh@kernel.org> Link: https://lore.kernel.org/r/20250325-max77759-mfd-v6-3-c0870ca662ba@linaro.org Signed-off-by: Lee Jones <lee@kernel.org>
2025-05-09dt-bindings: nvmem: Add max77759 bindingAndré Draszik1-0/+32
The Maxim MAX77759 is a companion PMIC for USB Type-C applications and includes Battery Charger, Fuel Gauge, temperature sensors, USB Type-C Port Controller (TCPC), NVMEM, and a GPIO expander. This describes its storage module (NVMEM). Signed-off-by: André Draszik <andre.draszik@linaro.org> Reviewed-by: "Rob Herring (Arm)" <robh@kernel.org> Link: https://lore.kernel.org/r/20250325-max77759-mfd-v6-2-c0870ca662ba@linaro.org Signed-off-by: Lee Jones <lee@kernel.org>
2025-05-09dt-bindings: gpio: Add max77759 bindingAndré Draszik1-0/+44
The Maxim MAX77759 is a companion PMIC for USB Type-C applications and includes Battery Charger, Fuel Gauge, temperature sensors, USB Type-C Port Controller (TCPC), NVMEM, and a GPIO expander. This describes its GPIO module. Signed-off-by: André Draszik <andre.draszik@linaro.org> Reviewed-by: "Rob Herring (Arm)" <robh@kernel.org> Acked-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Link: https://lore.kernel.org/r/20250325-max77759-mfd-v6-1-c0870ca662ba@linaro.org Signed-off-by: Lee Jones <lee@kernel.org>
2025-05-09dt-bindings: arm: add TQMa8XxS boardsMarkus Niebel1-0/+16
TQMa8XxS is a SOM series featuring NXP i.MX8X SoC. They are called TQMa8XQPS and TQMa8XDPS respectively. MB-SMARC-2 is a carrier reference design. Signed-off-by: Markus Niebel <Markus.Niebel@tq-group.com> Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Acked-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2025-05-09PM: hibernate: add configurable delay for pm_testZihuan Zhang1-0/+7
Turn the default 5 second test delay for hibernation into a configurable module parameter, so users can determine how long to wait in this pseudo-hibernate state before resuming the system. The configurable delay parameter has been added for suspend, so add an analogous one for hibernation. Example (wait 30 seconds); # echo 30 > /sys/module/hibernate/parameters/pm_test_delay # echo core > /sys/power/pm_test Signed-off-by: Zihuan Zhang <zhangzihuan@kylinos.cn> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Link: https://patch.msgid.link/20250507063520.419635-1-zhangzihuan@kylinos.cn [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-05-09dt-bindings: arm: fsl: add i.MX943 EVK boardJacky Bai1-0/+6
Add DT compatible string for NXP i.MX943 EVK board. Signed-off-by: Jacky Bai <ping.bai@nxp.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2025-05-09Documentation: media: Add documentation file c3-isp.rstKeke Li3-0/+128
Add the file 'c3-isp.rst' that documents the c3-isp driver. 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-09Documentation: media: Add documentation file metafmt-c3-isp.rstKeke Li2-0/+87
Add the file 'metafmt-c3-isp.rst' that documents the meta format of c3-isp. Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> 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-isp.yamlKeke Li1-0/+88
c3-isp is used to process raw image. 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-adapter.yamlKeke Li1-0/+111
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 Li1-0/+127
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 Brown1-0/+135
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 Moog1-0/+7
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-09virt: tdx-guest: Expose TDX MRs as sysfs attributesCedric Xing1-0/+63
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-09tsm-mr: Add TVM Measurement Register supportCedric Xing3-0/+25
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-09media: dt-bindings: Document Tegra186 and Tegra194 cecAaron Kling1-4/+10
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 Ryhel1-0/+1
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 Ryhel1-11/+7
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)2-41/+82
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 Pedumuru2-44/+90
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 Yang1-0/+4
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 Yang1-0/+6
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 Yang1-0/+4
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 Yang1-0/+6
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 Yang1-0/+14
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 Yang1-0/+13
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 Kicinski3-21/+99
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 Kozlowski1-0/+69
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 Armstrong2-59/+97
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 Torvalds1-7/+90
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 Rutland1-1/+1
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 Rutland1-2/+2
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 Borja1-4/+78
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 Borja1-0/+20
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 Pasternak1-0/+98
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 Kandagatla1-0/+4
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-08netlink: specs: rt-link: remove implicit structs from devconfJakub Kicinski1-97/+10
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-08netlink: specs: remove implicit structs for SNMP countersJakub Kicinski1-48/+12
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-08netlink: specs: ovs: correct struct namesJakub Kicinski2-9/+6
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-08netlink: specs: nl80211: drop structs which are not uAPIJakub Kicinski1-68/+0
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-08Documentation:ipmi: Remove comments about interrupt levelCorey Minyard1-6/+3
Callbacks no longer run at interrupt level or bh, so remove those comments. Signed-off-by: Corey Minyard <cminyard@mvista.com>
2025-05-08Documentation/gpu: Add new entries to amdgpu glossaryRodrigo Siqueira1-0/+33
Add some additional entries. Signed-off-by: Rodrigo Siqueira <siqueira@igalia.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2025-05-08xfs: allow sysadmins to specify a maximum atomic write limit at mount timeDarrick J. Wong1-0/+11
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 Pandruvada1-0/+21
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 Jadav1-0/+6
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 Wilczynski1-3/+14
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 Tikhonov1-0/+6
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 Li1-0/+68
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
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-12 22:57:44 +0300