summaryrefslogtreecommitdiff
path: root/Documentation
AgeCommit message (Collapse)AuthorFilesLines
2026-07-21KVM: arm64: vgic: Avoid double-deactivate of IRQs in the nested contextD Scott Phillips1-0/+4
In the nested state, the physical interrupt has already been deactivated through the HW bit in the LR. The extra deactivation would be harmless but can hit an errata case on AmpereOne, so avoid it here. On AmpereOne, deactivating a physical interrupt through ICC_DIR_EL1 or ICC_EOIR1_EL1 (depending on EOImode) which is not active, but is the highest priority pending interrupt causes the cpu to lose the interrupt pending state and also prevents the delivery of future interrupts. Fixes: 6dd333c8942b2 ("KVM: arm64: GICv3: nv: Plug L1 LR sync into deactivation primitive") Signed-off-by: D Scott Phillips <scott@os.amperecomputing.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-arm-kernel/20260710222128.416581-1-scott@os.amperecomputing.com/ Link: https://patch.msgid.link/20260714231158.496808-1-scott@os.amperecomputing.com Signed-off-by: Marc Zyngier <maz@kernel.org>
2026-07-21net: ethernet: oa_tc6: add OA_TC6_BROKEN_PHY quirk flagCiprian Regus1-1/+2
Some MAC-PHY devices need custom MDIO bus access functions to work around hardware issues. Add the OA_TC6_BROKEN_PHY quirk flag so drivers can opt in to skip oa_tc6's internal PHY init and manage the PHY themselves. When the flag is set, oa_tc6 skips MDIO bus registration, PHY discovery and PHY connection, leaving these to the driver. Drivers that do not set the flag retain the existing behavior. Update lan865x and the framework documentation accordingly. Signed-off-by: Ciprian Regus <ciprian.regus@analog.com> Link: https://patch.msgid.link/20260708-adin1140-driver-v5-3-4aca7b51a58b@analog.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-21dt-bindings: net: Add ADIN1140Ciprian Regus1-0/+71
The ADIN1140 is a single port 10BASE-T1S Ethernet controller that includes both the MAC and a PHY in the same package. Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Ciprian Regus <ciprian.regus@analog.com> Link: https://patch.msgid.link/20260708-adin1140-driver-v5-1-4aca7b51a58b@analog.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-21dt-bindings: clock: versal-clk: Fix Versal NET clock validationMichal Simek1-29/+22
The Versal NET clock controller compatible is specified as: compatible = "xlnx,versal-net-clk", "xlnx,versal-clk"; with xlnx,versal-clk listed as fallback. The original binding had two separate if/then blocks - one matching xlnx,versal-clk (2 clocks) and another matching xlnx,versal-net-clk (3 clocks). Since both compatible strings are present, both conditions matched simultaneously and JSON Schema applied the more restrictive 2-clock constraint, causing false "too long" validation errors for Versal NET. Define clock-names at the top-level and use if/then only to constrain the clock count (2 for Versal, 3 for Versal NET). Add a dedicated example for the Versal NET 3-clock configuration. Fixes: 39118392d19a ("dt-bindings: Remove alt_ref from versal") Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://patch.msgid.link/202e448e57cf979e1b5be61da0bad7778defdd4e.1783516336.git.michal.simek@amd.com Signed-off-by: Michal Simek <michal.simek@amd.com>
2026-07-21dt-bindings: clock: Move xlnx,zynqmp-clk to its own schemaMichal Simek3-51/+78
The ZynqMP clock controller binding shares only #clock-cells with the Versal bindings. Move it to a dedicated xlnx,zynqmp-clk.yaml schema. Also remove "(Optional clock)" from clock description because it is visible from schema itself. Also update versal-firmware example to match changes in xlnx,zynqmp-firmware.yaml. Suggested-by: Rob Herring <robh@kernel.org> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://patch.msgid.link/973a8a5441cf13622594b95dd0dd20a5f42ccece.1783516336.git.michal.simek@amd.com Signed-off-by: Michal Simek <michal.simek@amd.com>
2026-07-21dt-bindings: clock: versal-clk: Fix mio_clk index range in clock-names patternMichal Simek1-1/+1
The clock-names pattern "^mio_clk[00-77]+.*$" was intended to constrain the MIO index to the valid range 00..77 (ZynqMP has 78 MIO pins), but a regex character class cannot express a multi-digit decimal range. Replace the bogus character class with an explicit alternation that enumerates the two-digit decimal values 00..77. Fixes: 03d4a1004053 ("dt-bindings: clock: versal: Convert the xlnx,zynqmp-clk.txt to yaml") Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://patch.msgid.link/e742b7da70c2bf10650a81e537f1b90d76799416.1783516336.git.michal.simek@amd.com Signed-off-by: Michal Simek <michal.simek@amd.com>
2026-07-21dt-bindings: firmware: xilinx: Add missing example for ZynqMPMichal Simek1-0/+8
Document clock-controller under zynqmp-firmware in the binding example so ZynqMP DTs validate against xlnx,versal-clk.yaml (Versal example already did). Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://patch.msgid.link/12dba601a8b631e565dd98e52a89b0ec18fcdce2.1783516336.git.michal.simek@amd.com Signed-off-by: Michal Simek <michal.simek@amd.com>
2026-07-21dt-bindings: ethernet: eswin: add EIC7700 eth1 RX clock inversion variantZhi Li1-2/+49
The EIC7700 SoC integrates two GMAC instances. The eth1 MAC exhibits different RX clock sampling characteristics due to silicon-inherent timing behavior. The eth1 MAC has a fixed, non-configurable RX clock-to-data skew at the MAC input in the order of 4-5 ns. This cannot be compensated solely by the standard MAC internal delay configuration and PHY delay, and RX clock inversion is required at 1000Mbps for correct sampling. The eth1 TX path also includes a fixed silicon-inherent delay of approximately 2 ns. This delay is always present and cannot be disabled. It is therefore part of the effective transmit timing observed on the wire. For the eth1 variant, the valid tx-internal-delay-ps values include this fixed delay component. Consequently, the effective range becomes 2000-4540 ps (approximately 2000 ps fixed delay plus 0-2540 ps programmable delay). Introduce a dedicated compatible string "eswin,eic7700-qos-eth-clk-inversion" to represent the eth1 variant, allowing the driver to apply RX clock inversion only when required by hardware variant selection. This keeps SoC-level differentiation without exposing silicon-fixed skew as configurable device tree parameters. To reflect this, model the TX internal delay as a base 0-4540 ps range, and constrain valid values per compatible using conditional schema rules. Update the binding schema as follows: - Define tx-internal-delay-ps as a base range: 0-4540 ps - Add compatible-specific constraints using if/then rules: * eswin,eic7700-qos-eth: max 2540 ps * eswin,eic7700-qos-eth-clk-inversion: minimum 2000 ps (effective range 2000-4540 ps) No functional change for existing "eswin,eic7700-qos-eth" users. Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Zhi Li <lizhi2@eswincomputing.com> Link: https://patch.msgid.link/20260707064159.1299-1-lizhi2@eswincomputing.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-21dt-bindings: ethernet: eswin: relax internal delay model to range-based ↵Zhi Li1-12/+13
constraints Relax internal delay constraints for EIC7700 Ethernet binding. Replace fixed enumeration of rx-internal-delay-ps and tx-internal-delay-ps with a range-based definition (0-2540 ps, 20 ps steps) to reflect actual hardware capability. Mark rx/tx internal delay properties as optional, as they are board- specific tuning parameters rather than mandatory configuration. Update the device tree example to align with the relaxed constraint model and remove delay properties from the example to avoid implying they are required. No functional change to existing DT users. Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Zhi Li <lizhi2@eswincomputing.com> Link: https://patch.msgid.link/20260707064131.1282-1-lizhi2@eswincomputing.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-20netlink: specs: rt-link: convert bridge port flag attributes to u8Danielle Ratson1-20/+20
A number of IFLA_BRPORT_* attributes are documented in the rt-link spec as having the "flag" type, i.e. a payload-less NLA_FLAG attribute whose meaning is presence-only. This does not match the kernel, which emits these attributes with nla_put_u8() and validates them as NLA_U8 in br_port_policy[]. The values are not mere presence flags but carry a u8 payload (0/1). Convert these bridge port attributes from "flag" to "u8" so the spec reflects the actual wire format. Fixes: 077b6022d24b ("doc/netlink/specs: Add sub-message type to rt_link family") Reviewed-by: Petr Machata <petrm@nvidia.com> Acked-by: Nikolay Aleksandrov <nikolay@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Danielle Ratson <danieller@nvidia.com> Link: https://patch.msgid.link/a57cdfcfc4a6dcb92106c25b4dde5059fde2bd44.1783236731.git.danieller@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-21power: supply: bd71828: add a terminating table borderRandy Dunlap1-0/+1
Fix a documentation build error by adding a bottom table border: Documentation/ABI/testing/sysfs-class-power-bd71828:1: ERROR: Malformed table. No bottom table border found. ============ =========================================== 1 automatic adjustment of input current limit 0 no adjustment of input current limit. This helps for more unusual power sources like solar modules. [docutils] Fixes: e92786dd86a2 ("power: supply: bd71828: sysfs for auto input current limitation") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Acked-by: Matti Vaittinen <mazziesaccount@gmail.com> Link: https://patch.msgid.link/20260620011821.3568674-1-rdunlap@infradead.org Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
2026-07-20dt-bindings: update Sudeep Holla's email addressLaszlo Ersek7-7/+7
MAINTAINERS disagrees with Documentation/devicetree/bindings on Sudeep's email address; fix the latter. Fixes: 59e82a4237cf ("MAINTAINERS: Change Sudeep Holla's email address") Signed-off-by: Laszlo Ersek <laszlo.ersek@arm.com> Acked-by: Sudeep Holla <sudeep.holla@kernel.org> Link: https://patch.msgid.link/20260720160235.36592-1-laszlo.ersek@arm.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2026-07-20dtc: dt-check-style: Expect first device_typeKrzysztof Kozlowski1-7/+8
A few nodes do have "device_type" property which is mostly, but not always, the first property in a device node, when applicable. Adjust the DTS coding style rules to actually expect the device_type first and improve the dt-check-style to handle this correctly. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260709-dts-style-checker-v5-4-fcc147cb697d@oss.qualcomm.com Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2026-07-20dt-bindings: power: maxim,max17042: Fix temp types to signedRob Herring (Arm)1-2/+2
The max17042 binding described "maxim,cold-temp" and "maxim,over-heat-temp" as unsigned values, but in-tree DTS examples use negative temperatures such as a cold threshold below zero degrees. Document the temperature properties as signed int32 values so the schema matches existing DTS data and the driver can use signed helpers. Assisted-by: Codex:gpt-5-5 Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260612215315.1889039-1-robh@kernel.org Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2026-07-20Merge tag 'mm-hotfixes-stable-2026-07-20-11-37' of ↵Linus Torvalds1-87/+87
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Pull misc fixes from Andrew Morton: "12 hotfixes. 8 are cc:stable and the remainder address post-7.1 issues or aren't considered appropriate for backporting. 10 are for MM. All are singletons - please see the relevant changelogs for details" * tag 'mm-hotfixes-stable-2026-07-20-11-37' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: mm/memory-failure: trace: change memory_failure_event to ras subsystem mm: page_reporting: allow driver to set batch capacity mm/kmemleak: fix checksum computation for per-cpu objects mm/damon/core: disallow overlapping input ranges for damon_set_regions() MAINTAINERS: add Usama as a THP reviewer fat: avoid stack overflow warning mm/damon/core: validate ranges in damon_set_regions() m68k: avoid -Wunused-but-set-parameter in clear_user_page() mm/huge_memory: set PG_has_hwpoisoned only after new folio head is established mm/page_vma_mapped: fix device-private PMD handling MAINTAINERS: s/SeongJae/SJ/ userfaultfd: prevent registration of special VMAs
2026-07-20entry, treewide: Make syscall_enter_from_user_mode[_work]() indicate syscall ↵Thomas Gleixner1-10/+35
execution The return values of syscall_enter_from_user_mode[_work]() are non-intuitive. Both functions return the syscall number which should be invoked by the architecture specific syscall entry code. The returned number can be: - the unmodified syscall number which was handed in by the caller - a modified syscall number (ptrace, seccomp, trace/probe/bpf) That has an additional twist. If the return value is -1L then the caller is not allowed to modify the return value as that indicates that the modifying entity requests to abort the syscall and set the return value already. That can obviously not be differentiated from a syscall which handed in -1 as syscall number. The most trivial way to deal with that is: set_return_value(regs, -ENOSYS); nr = syscall_enter_from_user_mode(regs, nr); if (valid(nr)) handle_syscall(regs, nr); That's what LOONGARCH, RISCV, and X86 do. But PowerPC and S390 do not preset the return value, so when user space hands in -1 and there is nothing setting the return value in the entry work code, then the syscall is skipped but the return value is whatever random data has been in the return value register. Change the return values of syscall_enter_from_user_mode[_work]() to boolean and return false, when either ptrace or seccomp request to skip the syscall. If they return true, update the syscall number as it might have been changed. That results in slightly different behaviour of the architectures versus tracing. If the syscall tracepoint has probe/BPF attached, those might set the syscall number to -1 and also set the return value. PowerPC and S390 will then overwrite that value with -ENOSYS. The other architectures will just ignore it like any other invalid syscall and use the modified one. Originally-by: Michal Suchánek <msuchanek@suse.de> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Tested-by: Michal Suchánek <msuchanek@suse.de> Link: https://patch.msgid.link/20260712141346.772209074@kernel.org
2026-07-20blk-crypto: Update docs for blk-crypto-fallback motivationEric Biggers1-7/+7
The "Objective" section of inline-encryption.rst suggests that blk-crypto-fallback is just for testing. That's no longer accurate, so update it accordingly. Also fix a typo later in the document. Reviewed-by: Christoph Hellwig <hch@lst.de> Link: https://patch.msgid.link/20260718214655.63186-7-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2026-07-20blk-crypto: Remove unused function blk_crypto_config_supported()Eric Biggers1-19/+10
blk_crypto_config_supported() is no longer called, so remove it. Reviewed-by: Christoph Hellwig <hch@lst.de> Link: https://patch.msgid.link/20260718214655.63186-6-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2026-07-20fscrypt: Update docs for data pathEric Biggers1-16/+34
Update the "Data path changes" section to accurately document and elaborate on the current implementation of file contents en/decryption. Reviewed-by: Christoph Hellwig <hch@lst.de> Link: https://patch.msgid.link/20260718214655.63186-5-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2026-07-20fscrypt: Update encryption policy version docsEric Biggers1-22/+18
Update the wording of the documentation to put v1 encryption policies a bit more firmly in the past, explicitly calling them "deprecated" (which is consistent with the warning message the kernel has printed ever since v5.4). Do the same for FS_IOC_GET_ENCRYPTION_POLICY which supports only v1 policies, and remove the explicit recommendation to fall back to it. Also clarify that reusing master keys across policies isn't the best practice or normal usage, even though it's technically allowed for v2. Link: https://patch.msgid.link/20260718212526.53943-1-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2026-07-20Documentation: fscrypt: Update docs for inlinecryptEric Biggers3-43/+26
Update the documentation for the inlinecrypt mount option to reflect that it's now just about the choice of whether to use inline encryption hardware, not whether the blk-crypto framework is used. Also remove an outdated statement about the data unit size, and make the ext4 and f2fs docs reference the fscrypt docs rather than the block layer docs directly. Reviewed-by: Christoph Hellwig <hch@lst.de> Link: https://patch.msgid.link/20260713023708.9245-7-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2026-07-20fscrypt: Fully disallow IV_INO_LBLK_32 with s_blocksize != PAGE_SIZEEric Biggers1-0/+3
FSCRYPT_POLICY_FLAG_IV_INO_LBLK_32 with s_blocksize != PAGE_SIZE works only with the fs-layer implementation of file contents encryption, not blk-crypto. This is a problem for standardizing on blk-crypto. Fortunately, no one should be using this combination anyway. It doesn't make sense because the entire point of IV_INO_LBLK_32 is to support inline encryption hardware that is limited to 32-bit DUNs. Thus, fully disallow IV_INO_LBLK_32 with s_blocksize != PAGE_SIZE. Reviewed-by: Christoph Hellwig <hch@lst.de> Link: https://patch.msgid.link/20260713023708.9245-5-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2026-07-20dt-bindings: remoteproc: Document AMD MicroBlaze/V BRAM-based rprocBen Levinsky1-0/+105
Describe an AMD MicroBlaze/V BRAM-based remote processor controlled through the remoteproc framework. The binding models a soft-core processor subsystem instantiated in AMD programmable logic and using dual-port BRAM for firmware storage and execution. The remoteproc device is represented as a child node whose reg property describes the firmware memory window in the processor-local address space. The parent bus node provides standard devicetree address translation through ranges so Linux can access the same BRAM through the system physical address space. A clock input feeds the soft-core processor subsystem, and an active-low reset GPIO holds the processor in reset until firmware loading completes. The firmware-name property is optional. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Ben Levinsky <ben.levinsky@amd.com> Link: https://lore.kernel.org/r/20260714202441.554065-2-ben.levinsky@amd.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
2026-07-20dt-bindings: arm: add MBa93xxCA as mainboard for TQMa91xxCA and TQMa91xxLA SOMMarkus Niebel1-2/+4
TQMa91xxLA and TQMa91xxCA are two series of feature compatible SOM using NXP i.MX91 SoC in 11x11 mm package. MBa93xxCA is a starterkit base board usable for TQMa91xxCA and TQMa91xxLA soldered on an adapter board to demonstrate use cases without display but more interfaces. Signed-off-by: Markus Niebel <Markus.Niebel@ew.tq-group.com> Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-07-20dt-bindings: soc: imx: Add fsl,eim-busFrank Li1-1/+3
Add the fsl,eim-bus compatible strings for i.MX51 variants. These compatibles are only intended for existing legacy chips (more than 15 years old) and will not be used for new device trees. Fix below CHECK_DTBS warnings arch/arm/boot/dts/nxp/imx/imx53-ard.dtb: /eim-cs1@f4000000: failed to match any schema with compatible: ['fsl,eim-bus', 'simple-bus'] Acked-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Frank Li <Frank.Li@nxp.com>
2026-07-20dt-bindings: display: panel: Add Novatek NT36536Pengyu Luo1-0/+91
NT36536 is a driver IC used to drive MIPI-DSI panels. It is found in LENOVO Legion Y700 Gen4 with a dual-link 10-bit CSOT panel. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Pengyu Luo <mitltlatltl@gmail.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260709142846.12463-2-mitltlatltl@gmail.com
2026-07-20dt-bindings: PCI: mediatek-gen3: Allow memory-region for restricted DMA bufferChen-Yu Tsai1-0/+4
On some SoCs without an IOMMU behind the PCIe controller, the PCIe controller memory access could be limited to a small region by the firmware configuring a memory protection unit. This memory region must be assigned to the PCIe controller so that the OS knows to use that region. Otherwise PCIe devices would not work properly. Allow the memory-region property with one item pointing to a restricted DMA buffer. Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Acked-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20260720092116.1823562-1-wenst@chromium.org
2026-07-20dt-bindings: phy: mediatek,dsi-phy: Add support for MT8196AngeloGioacchino Del Regno1-0/+1
Add support for the MediaTek Kompanio Ultra (MT8196) SoC: this chip features a DSI PHY that is similar to the one found in the MT8183 SoC, but is a new (incremental) revision with a different register layout. Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://patch.msgid.link/20260713103805.23030-2-angelogioacchino.delregno@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-07-20dt-bindings: phy: Add Spacemit K3 USB3/PCIe comb phy supportInochi Amaoto1-0/+68
The USB3/PCIe comb PHY on the K3 is a complex PHY group that can provide multiple phy for both PCIe and USB controller. Its mux configuration is controlled by the APMU syscon device. Signed-off-by: Inochi Amaoto <inochiama@gmail.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20260703021024.495433-2-inochiama@gmail.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-07-20dt-bindings: phy: qcom,sc8280xp-qmp-pcie-phy: Add Hawi compatiblesMatthew Leung1-0/+6
Document the compatibles for the Gen3 x2 and Gen4 x1 QMP PCIe PHYs found on the Hawi platform. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Matthew Leung <matthew.leung@oss.qualcomm.com> Link: https://patch.msgid.link/20260707-hawi-phy-pcie-v4-1-8d9cc6324947@oss.qualcomm.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-07-20Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netPaolo Abeni13-214/+332
Cross-merge networking fixes after downstream PR (net-7.2-rc4). No conflicts. Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-07-20docs: ABI: testing: Fix typoManuel Ebner1-1/+1
Add missing ')'. Signed-off-by: Manuel Ebner <manuelebner@mailbox.org> Reviewed-by: Brian Norris <briannorris@chromium.org> Link: https://lore.kernel.org/r/20260612125111.187072-2-manuelebner@mailbox.org Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
2026-07-20dt-bindings: iio: adc: rockchip-saradc: Add RV1106 compatibleSimon Glass1-1/+3
Add the compatible for the SARADC of the Rockchip RV1106, which is compatible with the RK3588 variant. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
2026-07-19lib/crypto: aes: Add XTS supportEric Biggers1-0/+7
Add support for AES-XTS to the crypto library. This will be used to provide a streamlined implementation of the "xts(aes)" crypto_skcipher algorithm. I'm also planning to use this directly in fscrypt and blk-crypto-fallback. As usual, the architecture-optimized AES-XTS code will be migrated into the library as well (using the hooks provided in this commit), eliminating lots of repetitive boilerplate code. Compared to direct implementation of "xts(aes)", I've also eliminated the requirement for architectures to implement ciphertext stealing, as the library just handles it portably instead. That will simplify things considerably. Initial test coverage is provided by the crypto_skcipher support added in a later commit. I'm planning a KUnit test suite as well. Link: https://patch.msgid.link/20260715221153.246410-6-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2026-07-19lib/crypto: aes: Add CTR and XCTR supportEric Biggers1-0/+7
Add support for AES-CTR and AES-XCTR to the crypto library. These will be used to provide streamlined implementations of the "ctr(aes)" and "xctr(aes)" crypto_skcipher algorithms. Most users of "ctr(aes)" will also be able to switch to the library, which as usual will be simpler and faster, e.g.: - net/mac80211/fils_aead.c - net/mac802154/llsec.c As usual, the architecture-optimized AES-CTR and AES-XCTR code will be migrated into the library as well (using the hooks provided in this commit), eliminating lots of repetitive boilerplate code. This is also a prerequisite for supporting AES-GCM, AES-CCM, and AES-HCTR2 in the crypto library. Initial test coverage is provided by the crypto_skcipher support added in a later commit. I'm planning a KUnit test suite as well. Reviewed-by: Thomas Huth <thuth@redhat.com> Link: https://patch.msgid.link/20260715221153.246410-5-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2026-07-19lib/crypto: aes: Add CBC and CBC-CTS supportEric Biggers1-0/+7
Add support for AES-CBC and AES-CBC-CTS to the crypto library. These will be used to provide streamlined implementations of the "cbc(aes)" and "cts(cbc(aes))" crypto_skcipher algorithms. Most users of these crypto_skcipher algorithms will also be able to switch to the library, which as usual will be simpler and faster, e.g.: - block/blk-crypto-fallback.c (for AES-128-CBC-ESSIV) - fs/crypto/crypto.c (for AES-128-CBC-ESSIV) - fs/crypto/fname.c (for AES-256-CTS and AES-128-CBC) - kernel/bpf/crypto.c - net/ceph/crypto.c - security/keys/encrypted-keys/encrypted.c As usual, the architecture-optimized AES-CBC and AES-CBC-CTS code will be migrated into the library as well (using the hooks provided in this commit), eliminating lots of repetitive boilerplate code. Initial test coverage is provided by the crypto_skcipher support added in a later commit. I'm planning a KUnit test suite as well. Reviewed-by: Thomas Huth <thuth@redhat.com> Link: https://patch.msgid.link/20260715221153.246410-4-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2026-07-19lib/crypto: aes: Add ECB supportEric Biggers2-0/+29
Add support for AES-ECB to the crypto library. This will be used to provide a streamlined implementation of the "ecb(aes)" crypto_skcipher algorithm. fs/crypto/keysetup_v1.c will also use aes_ecb_encrypt() directly. As usual, the architecture-optimized AES-ECB code will be migrated into the library as well (using the hooks provided in this commit), eliminating lots of repetitive boilerplate code. ECB is obsolete of course, but we need this for parity with the traditional API and to support some odd users of ECB in the kernel. Initial test coverage is provided by the crypto_skcipher support added in a later commit. I'm planning a KUnit test suite as well. Create a documentation file libcrypto-unauth-encryption.rst to hold the documentation for this and other unauthenticated encryption modes. Reviewed-by: Thomas Huth <thuth@redhat.com> Link: https://patch.msgid.link/20260715221153.246410-3-ebiggers@kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org>
2026-07-20dt-bindings: iio: adc: add ti,ads112c14David Lechner (TI)1-0/+219
Add new bindings for ti,ads112c14 and similar devices. This is an ADC that is primarily intended for use with resistive sensors (RTD, thermocouple, Wheatstone bridge, etc.). There are a few unusual properties because of this. In particular, the reference voltage source and current output requirements can be different for each measurement, so these are included in the channel bindings. The REFP/REFN reference voltage is usually just connected to a resistor that is being driven by the ADC's current outputs, so there is special property for this case rather than requiring a regulator to be defined to represent that. Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: David Lechner (TI) <dlechner@baylibre.com> Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
2026-07-20dt-bindings: iio: adc: add input-chopping propertyDavid Lechner (TI)1-0/+8
Add a generic input-chopping property to adc.yaml. This is a feature seen frequently in ADCs that are designed to measure resistive loads, such as RTDs and strain gauges. Enabling this can reduce offset errors by swapping the positive and negative input channels on every other conversion. This can have side-effects in timing and filter response, so it is not always desirable to enable this feature in some applications. Therefore, it is best to make this a property that can be enabled or disabled in the device tree. Signed-off-by: David Lechner (TI) <dlechner@baylibre.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
2026-07-20dt-bindings: iio: adc: Add burn-out current propertiesKurt Borja1-0/+5
Some ADCs incorporate burn-out current sources that provide current to the channel's input pins for open-circuit or short-circuit detection. Signed-off-by: Kurt Borja <kuurtb@gmail.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: David Lechner (TI) <dlechner@baylibre.com> Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
2026-07-20dt-bindings: iio: adc: Add excitation current sources propertiesKurt Borja1-0/+21
Some ADCs incorporate current sources that provide excitation current to resistive temperature devices (RTDs), thermistors, diodes and other resistive sensors that require constant current biasing. Signed-off-by: Kurt Borja <kuurtb@gmail.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: David Lechner (TI) <dlechner@baylibre.com> Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
2026-07-20dt-bindings: iio: adc: Add reference-sources propertyKurt Borja1-0/+7
Some ADCs have configurable voltage reference sources for each channel. Signed-off-by: Kurt Borja <kuurtb@gmail.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: David Lechner (TI) <dlechner@baylibre.com> Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
2026-07-19spi: atmel-quadspi: add support for LAN969xMark Brown20-240/+362
Robert Marko <robert.marko@sartura.hr> says: This series adds QSPI support for the Microchip LAN969x which has two QSPI controllers based on SAMA7G5. It requires pad calibration, supports DMA, and supports 100 MHz operation. It requires a different init sequence to SAMA7G5 so support for custom .init per controller caps is added, and existing controllers relying on checking gclk are converted to it. Signed-off-by: Robert Marko <robert.marko@sartura.hr> Link: https://patch.msgid.link/20260709112006.390742-1-robert.marko@sartura.hr
2026-07-19spi: dt-bindings: Document LAN969x QSPIRobert Marko1-0/+1
LAN969x has 2 QSPI instances, so document their compatible. Signed-off-by: Robert Marko <robert.marko@sartura.hr> Link: https://patch.msgid.link/20260709112006.390742-2-robert.marko@sartura.hr Signed-off-by: Mark Brown <broonie@kernel.org>
2026-07-19alpha: enable lockdep hardirq state trackingMagnus Lindholm1-1/+1
Alpha masks interrupts through the PAL IPL state, so lockdep cannot infer hardirq state transitions from generic code alone. Add explicit hardirq on/off annotations to the low-level entry and return paths so lockdep's IRQ state follows the hardware IPL state. Annotate the PAL IPL transitions and the shared return-to-user/kernel paths where interrupts become enabled or disabled. With the preceding irqflags, raw-lock, sysfs, and ftrace return-address preparations in place, select LOCKDEP_SUPPORT and TRACE_IRQFLAGS_SUPPORT for Alpha. This keeps CONFIG_PROVE_LOCKING usable on Alpha instead of disabling debug_locks due to IRQ-state mismatches. Reviewed-by: Matt Turner <mattst88@gmail.com> Tested-by: Matt Turner <mattst88@gmail.com> Signed-off-by: Magnus Lindholm <linmag7@gmail.com> Link: https://lore.kernel.org/r/20260706170019.2941459-7-linmag7@gmail.com Signed-off-by: Magnus Lindholm <linmag7@gmail.com>
2026-07-19alpha: enable regset-based ptrace and core dumpsMagnus Lindholm1-1/+1
Add a user_regset_view for Alpha and switch ELF core dumping to CORE_DUMP_USE_REGSET. General-purpose registers are exported in ELF gregs layout, including callee-saved registers and a correct user stack pointer. The user stack pointer is not preserved in pt_regs on Alpha, so expose it from the PCB, or via rdusp() for the current task, when building the ELF register image. This makes the user stack pointer consistent for core dumps, ptrace regsets, and PTRACE_GET_SYSCALL_INFO. Implement regset get/set callbacks for both NT_PRSTATUS and NT_PRFPREG. The callbacks translate between Alpha's pt_regs/thread state and the ELF-visible register layouts, while the common ptrace regset code handles PTRACE_GETREGSET and PTRACE_SETREGSET iovec semantics. This avoids duplicating subtle short-buffer and oversized-buffer behavior in arch_ptrace(). With these changes Alpha satisfies the requirements for HAVE_ARCH_TRACEHOOK and selects it, enabling generic tracehook and ptrace syscall-info code paths without changing the existing syscall entry ABI. Reviewed-by: Matt Turner <mattst88@gmail.com> Tested-by: Matt Turner <mattst88@gmail.com> Signed-off-by: Magnus Lindholm <linmag7@gmail.com> Link: https://lore.kernel.org/r/20260706170019.2941459-2-linmag7@gmail.com Signed-off-by: Magnus Lindholm <linmag7@gmail.com>
2026-07-18dt-bindings: remoteproc: qcom: move glymur SoCCP pas to standaloneAnanthu C V1-1/+1
SHM bridge creation is required to enable memory protection for both remoteproc metadata and its memory region on Qualcomm SoCs like Glymur running non-Gunyah based Hypervisors, unlike Kaanapali. Having Glymur fall back to the Kaanapali binding is therefore incorrect and breaks subsystem restart on Glymur. Fix this by decoupling Glymur SoCCP PAS from Kaanapali and registering it as its own binding. Fixes: 8b54bacadc0c ("dt-bindings: remoteproc: qcom: Document pas for SoCCP on Kaanapali and Glymur platforms") Signed-off-by: Ananthu C V <ananthu.cv@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260709-glymur-soccp-v6-1-16f70227547d@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-07-18dt-bindings: iio: dac: fix spelling of 'reference' in adi,ad5791Yahya Toubali1-2/+2
Fix misspelling of 'reference' (was 'referance') in the vrefp-supply and vrefn-supply descriptions. Signed-off-by: Yahya Toubali <yahya@yahyatoubali.me> Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
2026-07-18dt-bindings: display/msm: Document Adreno 722 GPU and GMUPuranam V G Tejaswi2-0/+2
Adreno 722 found in Eliza chipset belongs to the A7x Gen1 family. It is derived from A730 and shares the same IP-level configurations: HWCG registers, protected registers, GBIF CX registers and gmu_cgc_mode. Major differences include lower cache/core counts, 1MB GMEM, no Concurrent Binning & LPAC support. Some of the peripheral blocks like RSCC are from A740 that resulted in updates to RSC layout. Update the dt-binding docs to document this GPU and GMU. Signed-off-by: Puranam V G Tejaswi <puranam.tejaswi@oss.qualcomm.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/740964/ Message-ID: <20260718-eliza-gpu-v2-5-64379dbebd7a@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2026-07-18dt-bindings: arm-smmu: Document GPU SMMU for Eliza SoCAkhil P Oommen1-0/+2
Add specific compatible strings to document the GPU SMMU present in the Eliza SoC. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/740962/ Message-ID: <20260718-eliza-gpu-v2-4-64379dbebd7a@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
generated by cgit (git 2.54.0.dirty) at 2026-09-23 11:37:49 +0000