summaryrefslogtreecommitdiff
path: root/Documentation
AgeCommit message (Collapse)Author
2026-01-15ACPI: Documentation: driver-api: Disapprove of using ACPI driversRafael J. Wysocki
Sadly, there is quite a bit of technical debt related to the kernel's ACPI support subsystem and one of the most significant pieces of it is the existence and use of ACPI drivers represented by struct acpi_driver objects. Those drivers are bound directly to struct acpi_device objects, also referred to as "ACPI device nodes", representing device objects in the ACPI namespace defined as: A hierarchical tree structure in OS-controlled memory that contains named objects. These objects may be data objects, control method objects, bus/device package objects, and so on. according to the ACPI specification [1]. The above definition implies, although rather indirectly, that the objects in question don't really represent hardware. They are just "device package objects" containing some information on the devices present in the given platform that is known to the platform firmware. Although the platform firmware can be the only source of information on some devices, the information provided by it alone may be insufficient for device enumeration in general. If that is the case, binding a driver directly to a given ACPI device node clearly doesn't make sense. If the device in question is enumerated through a hardware interface, it will be represented by a device object matching that interface, like a struct pci_dev, and the ACPI device node corresponding to it will be treated as its "ACPI companions" whose role is to amend the "native" enumeratiom mechanism. For the sake of consistency and confusion avoidance, it is better to treat ACPI device nodes in general as ACPI companions of other device objects representing hardware. In some cases though it appeared easier to take a shortcut and use an ACPI driver binding directly to an ACPI device node. Moreover, there were corner cases in which that was the only choice, but they all have been addressed now. In all cases in which an ACPI driver might be used, the ACPI device node it might bind to is an ACPI companion of another device object representing a piece of hardware. It is thus better to use a driver binding to the latter than to use an ACPI driver and leave the other device object alone, not just because doing so is more consistent and less confusing, but also because using ACPI drivers may lead to potential functional deficiencies, like possible ordering issues related to power management. Unfortunately, there are quite a few ACPI drivers in use and, as a rule, they bind to ACPI device nodes that are ACPI companions of platform devices, so in fact they play the role of platform drivers although in a kind of convoluted way. An effort has been under way to replace them with platform drivers, which is relatively straightforward in the vast majority of cases, but it has not been pursued very aggressively so far, mostly due to the existence of the corner cases mentioned above. However, since those corner cases are gone now, it makes sense to spend more time on driver conversions with the ultimate goal to get rid of struct acpi_driver and the related code from the kernel. To that end, add a document explaining why using ACPI drivers is not a good idea, so it need not be explained from scratch on every attempt to convert an ACPI driver to a platform one. Link: https://uefi.org/specs/ACPI/6.6/02_Definition_of_Terms.html#term-ACPI-Namespace [1] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Armin Wolf <W_Armin@gmx.de> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Link: https://patch.msgid.link/2396510.ElGaqSPkdT@rafael.j.wysocki
2026-01-15dt-bindings: arm: amlogic: introduce specific compatibles for S4 familyNick Xie
The Amlogic S4 SoC family includes multiple variants, such as the S805X2 and S905Y4. Currently, the bindings only define the generic "amlogic,s4" compatible. This patch introduces specific compatibles "amlogic,s805x2" and "amlogic,s905y4" to properly differentiate these SoCs while keeping "amlogic,s4" as the family fallback. This allows for more precise hardware description and future-proofing if SoC-specific quirks arise. Signed-off-by: Nick Xie <nick@khadas.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260115030015.1334517-2-nick@khadas.com Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
2026-01-15ASoC: rt5640: Fix duplicate clock properties in DT bindingMark Brown
Not quite overlapping changes to the rt5640 binding resulted in duplicate definitions of the clocks and clock-names properties. Delete one of them, preferring the simpler one. Reported-by: Jon Hunter <jonathanh@nvidia.com> Closes: https://lore.kernel.org/r/0e68c5f4-f68d-4544-bc7a-40694829db75@nvidia.com Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://patch.msgid.link/20260114-asoc-fix-rt5640-dt-clocks-v1-1-421d438673c2@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-15dt-bindings: soc: renesas: Document RZ/N1 GPIO Interrupt MultiplexerHerve Codina (Schneider Electric)
On the Renesas RZ/N1 SoC, GPIOs can generate interruptions. Those interruption lines are multiplexed by the GPIO Interrupt Multiplexer in order to map 32 * 3 GPIO interrupt lines to 8 GIC interrupt lines. The GPIO interrupt multiplexer IP does nothing but select 8 GPIO IRQ lines out of the 96 available to wire them to the GIC input lines. Signed-off-by: Herve Codina (Schneider Electric) <herve.codina@bootlin.com> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20260114093938.1089936-7-herve.codina@bootlin.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2026-01-15platform/x86: thinkpad_acpi: Add sysfs to display details of damaged device.Nitin Joshi
Add new sysfs interface to identify the impacted component with location of device. Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca> Signed-off-by: Nitin Joshi <nitjoshi@gmail.com> Link: https://patch.msgid.link/20260106174519.6402-2-nitjoshi@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-01-15platform/x86: thinkpad_acpi: Add support to detect hardware damage detection ↵Nitin Joshi
capability. Thinkpads are adding the ability to detect and report hardware damage status. Add new sysfs interface to identify whether hardware damage is detected or not. Initial support is available for the USB-C replaceable connector. Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca> Signed-off-by: Nitin Joshi <nitjoshi@gmail.com> Link: https://patch.msgid.link/20260106174519.6402-1-nitjoshi@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-01-15perf/x86/intel: Add support for rdpmc user disable featureDapeng Mi
Starting with Panther Cove, the rdpmc user disable feature is supported. This feature allows the perf system to disable user space rdpmc reads at the counter level. Currently, when a global counter is active, any user with rdpmc rights can read it, even if perf access permissions forbid it (e.g., disallow reading ring 0 counters). The rdpmc user disable feature mitigates this security concern. Details: - A new RDPMC_USR_DISABLE bit (bit 37) in each EVNTSELx MSR indicates that the GP counter cannot be read by RDPMC in ring 3. - New RDPMC_USR_DISABLE bits in IA32_FIXED_CTR_CTRL MSR (bits 33, 37, 41, 45, etc.) for fixed counters 0, 1, 2, 3, etc. - When calling rdpmc instruction for counter x, the following pseudo code demonstrates how the counter value is obtained: If (!CPL0 && RDPMC_USR_DISABLE[x] == 1) ? 0 : counter_value; - RDPMC_USR_DISABLE is enumerated by CPUID.0x23.0.EBX[2]. This patch extends the current global user space rdpmc control logic via the sysfs interface (/sys/devices/cpu/rdpmc) as follows: - rdpmc = 0: Global user space rdpmc and counter-level user space rdpmc for all counters are both disabled. - rdpmc = 1: Global user space rdpmc is enabled during the mmap-enabled time window, and counter-level user space rdpmc is enabled only for non-system-wide events. This prevents counter data leaks as count data is cleared during context switches. - rdpmc = 2: Global user space rdpmc and counter-level user space rdpmc for all counters are enabled unconditionally. The new rdpmc settings only affect newly activated perf events; currently active perf events remain unaffected. This simplifies and cleans up the code. The default value of rdpmc remains unchanged at 1. For more details about rdpmc user disable, please refer to chapter 15 "RDPMC USER DISABLE" in ISE documentation. Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20260114011750.350569-8-dapeng1.mi@linux.intel.com
2026-01-14docs: kernel-parameters: add kfence parametersMarco Elver
Add a brief summary for KFENCE's kernel command-line parameters in admin-guide/kernel-parameters. Link: https://lkml.kernel.org/r/20251222150018.1349672-1-elver@google.com Signed-off-by: Marco Elver <elver@google.com> Cc: Alexander Potapenko <glider@google.com> Cc: Dmitriy Vyukov <dvyukov@google.com> Cc: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-01-15Merge tag 'amd-drm-next-6.20-2026-01-09' of ↵Dave Airlie
https://gitlab.freedesktop.org/agd5f/linux into drm-next amd-drm-next-6.20-2026-01-09: amdgpu: - GPUVM updates - Initial support for larger GPU address spaces - Initial SMUIO 15.x support - Documentation updates - Initial PSP 15.x support - Initial IH 7.1 support - Initial IH 6.1.1 support - SMU 13.0.12 updates - RAS updates - Initial MMHUB 3.4 support - Initial MMHUB 4.2 support - Initial GC 12.1 support - Initial GC 11.5.4 support - HDMI fixes - Panel replay improvements - DML updates - DC FP fixes - Initial SDMA 6.1.4 support - Initial SDMA 7.1 support - Userq updates - DC HPD refactor - SwSMU cleanups and refactoring - TTM memory ops parallelization - DCN 3.5 fixes - DP audio fixes - Clang fixes - Misc spelling fixes and cleanups - Initial SDMA 7.11.4 support - Convert legacy DRM logging helpers to new drm logging helpers - Initial JPEG 5.3 support - Add support for changing UMA size via the driver - DC analog fixes - GC 9 gfx queue reset support - Initial SMU 15.x support amdkfd: - Reserved SDMA rework - Refactor SPM - Initial GC 12.1 support - Initial GC 11.5.4 support - Initial SDMA 7.1 support - Initial SDMA 6.1.4 support - Increase the kfd process hash table - Per context support - Topology fixes radeon: - Convert legacy DRM logging helpers to new drm logging helpers - Use devm for i2c adapters - Variable sized array fix - Misc cleanups UAPI: - KFD context support. Proposed userspace: https://github.com/ROCm/rocm-systems/pull/1705 https://github.com/ROCm/rocm-systems/pull/1701 - Add userq metadata queries for more queue types. Proposed userspace: https://gitlab.freedesktop.org/yogeshmohan/mesa/-/commits/userq_query From: Alex Deucher <alexander.deucher@amd.com> Link: https://patch.msgid.link/20260109154713.3242957-1-alexander.deucher@amd.com Signed-off-by: Dave Airlie <airlied@redhat.com>
2026-01-14Documentation: riscv: uabi: Clarify ISA spec version for canonical orderGuodong Xu
Specify that chapter 27 refers to version 20191213 of the RISC-V ISA Unprivileged Architecture. The chapter numbering differs across specification versions - for example, in version 20250508, the ISA Extension Naming Conventions is chapter 36, not chapter 27. Historical versions of the RISC-V specification can be found via Link [1]. Acked-by: Paul Walmsley <pjw@kernel.org> Link: https://riscv.org/specifications/ratified/ [1] Fixes: f07b2b3f9d47 ("Documentation: riscv: add a section about ISA string ordering in /proc/cpuinfo") Signed-off-by: Guodong Xu <guodong@riscstar.com> Link: https://patch.msgid.link/20260115-adding-b-dtsi-v2-1-254dd61cf947@riscstar.com
2026-01-14Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf after rc5Alexei Starovoitov
Cross-merge BPF and other fixes after downstream PR. No conflicts. Adjacent: Auto-merging MAINTAINERS Auto-merging Makefile Auto-merging kernel/bpf/verifier.c Auto-merging kernel/sched/ext.c Auto-merging mm/memcontrol.c Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-01-14slab: Introduce kmalloc_flex() and familyKees Cook
As done for kmalloc_obj*(), introduce a type-aware allocator for flexible arrays, which may also have "counted_by" annotations: ptr = kmalloc(struct_size(ptr, flex_member, count), gfp); becomes: ptr = kmalloc_flex(*ptr, flex_member, count, gfp); The internal use of __flex_counter() allows for automatically setting the counter member of a struct's flexible array member when it has been annotated with __counted_by(), avoiding any missed early size initializations while __counted_by() annotations are added to the kernel. Additionally, this also checks for "too large" allocations based on the type size of the counter variable. For example: if (count > type_max(ptr->flex_counter)) fail...; size = struct_size(ptr, flex_member, count); ptr = kmalloc(size, gfp); if (!ptr) fail...; ptr->flex_counter = count; becomes (n.b. unchanged from earlier example): ptr = kmalloc_flex(*ptr, flex_member, count, gfp); if (!ptr) fail...; ptr->flex_counter = count; Note that manual initialization of the flexible array counter is still required (at some point) after allocation as not all compiler versions support the __counted_by annotation yet. But doing it internally makes sure they cannot be missed when __counted_by _is_ available, meaning that the bounds checker will not trip due to the lack of "early enough" initializations that used to work before enabling the stricter bounds checking. For example: ptr = kmalloc_flex(*ptr, flex_member, count, gfp); fill(ptr->flex, count); ptr->flex_count = count; This works correctly before adding a __counted_by annotation (since nothing is checking ptr->flex accesses against ptr->flex_count). After adding the annotation, the bounds sanitizer would trip during fill() because ptr->flex_count wasn't set yet. But with kmalloc_flex() setting ptr->flex_count internally at allocation time, the existing code works without needing to move the ptr->flex_count assignment before the call to fill(). (This has been a stumbling block for __counted_by adoption.) Link: https://patch.msgid.link/20251203233036.3212363-4-kees@kernel.org Acked-by: Vlastimil Babka <vbabka@suse.cz> Signed-off-by: Kees Cook <kees@kernel.org>
2026-01-14slab: Introduce kmalloc_obj() and familyKees Cook
Introduce type-aware kmalloc-family helpers to replace the common idioms for single object and arrays of objects allocation: ptr = kmalloc(sizeof(*ptr), gfp); ptr = kmalloc(sizeof(struct some_obj_name), gfp); ptr = kzalloc(sizeof(*ptr), gfp); ptr = kmalloc_array(count, sizeof(*ptr), gfp); ptr = kcalloc(count, sizeof(*ptr), gfp); These become, respectively: ptr = kmalloc_obj(*ptr, gfp); ptr = kmalloc_obj(*ptr, gfp); ptr = kzalloc_obj(*ptr, gfp); ptr = kmalloc_objs(*ptr, count, gfp); ptr = kzalloc_objs(*ptr, count, gfp); Beyond the other benefits outlined below, the primary ergonomic benefit is the elimination of needing "sizeof" nor the type name, and the enforcement of assignment types (they do not return "void *", but rather a pointer to the type of the first argument). The type name _can_ be used, though, in the case where an assignment is indirect (e.g. via "return"). This additionally allows[1] variables to be declared via __auto_type: __auto_type ptr = kmalloc_obj(struct foo, gfp); Internal introspection of the allocated type now becomes possible, allowing for future alignment-aware choices to be made by the allocator and future hardening work that can be type sensitive. For example, adding __alignof(*ptr) as an argument to the internal allocators so that appropriate/efficient alignment choices can be made, or being able to correctly choose per-allocation offset randomization within a bucket that does not break alignment requirements. Link: https://lore.kernel.org/all/CAHk-=wiCOTW5UftUrAnvJkr6769D29tF7Of79gUjdQHS_TkF5A@mail.gmail.com/ [1] Acked-by: Vlastimil Babka <vbabka@suse.cz> Link: https://patch.msgid.link/20251203233036.3212363-1-kees@kernel.org Signed-off-by: Kees Cook <kees@kernel.org>
2026-01-14sound: codecs: tlv320adcx140: assorted patchesMark Brown
Merge series from Sascha Hauer <s.hauer@pengutronix.de>: These are some patches for the tlv320adcx140 codec we are carrying around for a while, time to upstream them.
2026-01-14ASoC: codecs: aw88261: add dvdd-supply propertyMark Brown
Merge series from Bharadwaj Raju <bharadwaj.raju@machinesoul.in>: The AW88261 has a DVDD chip which needs to be powered on for it to function correctly. The property for this was missing, so this patchset adds the dvdd-supply property which enables a regulator to be bound to it in a device tree.
2026-01-14ASoC: Fix sdw_utils calling wrong codec init callbacksMark Brown
Merge series from Richard Fitzgerald <rf@opensource.cirrus.com>: This series fixes a problem with soc_sdw_utils.c calling the wrong codec init callbacks, because it assumed that the DAI name could be used to uniquely identify the codec. This isn't the case, especially on SDCA which is a generic driver for many parts. The first patch is needed to add a missing export to SoundWire core.
2026-01-14Merge tag 'scsi-fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi Pull SCSI fixes from James Bottomley: "Only one core change (and one in doc only) the rest are drivers. The one core fix is for some inline encrypting drives that can't handle encryption requests on non-data commands (like error handling ones); it saves the request level encryption parameters in the eh_save structure so they can be cleared for error handling and restored after it is completed" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: scsi: ufs: host: mediatek: Make read-only array scale_us static const scsi: bfa: Update outdated comment scsi: mpt3sas: Update maintainer list scsi: ufs: core: Configure MCQ after link startup scsi: core: Fix error handler encryption support scsi: core: Correct documentation for scsi_test_unit_ready() scsi: ufs: dt-bindings: Fix several grammar errors
2026-01-14Merge tag 'media/v6.19-3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media Pull media fixes from Mauro Carvalho Chehab: - ov02c10: some fixes related to preserving bayer pattern and horizontal control - ipu-bridge: Add quirks for some Dell XPS laptops with inverted sensors - mali-c55: Fix version identifier logic - rzg2l-cru: csi-2: fix RZ/V2H input sizes on some variants * tag 'media/v6.19-3' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: media: ov02c10: Remove unnecessary hflip and vflip pointers media: ipu-bridge: Add DMI quirk for Dell XPS laptops with upside down sensors media: ov02c10: Fix the horizontal flip control media: ov02c10: Adjust x-win/y-win when changing flipping to preserve bayer-pattern media: ov02c10: Fix bayer-pattern change after default vflip change media: rzg2l-cru: csi-2: Support RZ/V2H input sizes media: uapi: mali-c55-config: Remove version identifier media: mali-c55: Remove duplicated version check media: Documentation: mali-c55: Use v4l2-isp version identifier
2026-01-14docs: exportfs: Use source code struct documentationAndré Almeida
Instead of duplicating struct export_operations documentation in both ReST file and in the C source code, just use the kernel-doc in the docs. While here, make the sentence preceding the paragraph less redundant. Signed-off-by: André Almeida <andrealmeid@igalia.com> Link: https://patch.msgid.link/20260112-tonyk-fs_uuid-v1-4-acc1889de772@igalia.com Reviewed-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Christian Brauner <brauner@kernel.org>
2026-01-14dt-bindings: phy: google: Add Google Tensor G5 USB PHYRoy Luo
Document the device tree bindings for the USB PHY interfaces integrated with the DWC3 controller on Google Tensor SoCs, starting with G5 generation (Laguna). The USB PHY on Tensor G5 includes two integrated Synopsys PHY IPs: the eUSB 2.0 PHY IP and the USB 3.2/DisplayPort combo PHY IP. Due to a complete architectural overhaul in the Google Tensor G5, the existing Samsung/Exynos USB PHY binding for older generations of Google silicons such as gs101 are no longer compatible, necessitating this new device tree binding. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Roy Luo <royluo@google.com> Link: https://patch.msgid.link/20251227-phyb4-v10-1-e8caf6b93fe7@google.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-14dt-bindings: pinctrl: spacemit: k3: fix drive-strength docYixun Lan
Fix a typo in DT documentation, it should describe the 3.3V drive strength table of SpacemiT k3 SoC. Fixes: 5adaa1a8c088 ("dt-bindings: pinctrl: spacemit: add K3 SoC support") Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Yixun Lan <dlan@gentoo.org> Signed-off-by: Linus Walleij <linusw@kernel.org>
2026-01-14xen: introduce xen_console_io optionStefano Stabellini
Xen can support console_io hypercalls for any domains, not just dom0, depending on DEBUG and XSM policies. These hypercalls can be very useful for development and debugging. Introduce a kernel command line option xen_console_io to enable the usage of console_io hypercalls for any domain upon request. When xen_console_io is not specified, the current behavior is retained. Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com> Reviewed-by: Juergen Gross <jgross@suse.com> Signed-off-by: Juergen Gross <jgross@suse.com> Message-ID: <alpine.DEB.2.22.394.2601131522540.992863@ubuntu-linux-20-04-desktop>
2026-01-14dt-bindings: sound: google,goldfish-audio: Convert to DT schemaKuan-Wei Chiu
Convert the Android Goldfish Audio binding to DT schema format. Move the file to the sound directory to match the subsystem. Update the example node name to 'sound' to comply with generic node naming standards. Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260113092602.3197681-6-visitorckw@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-14ASoC: dt-bindings: document dvdd-supply property for awinic,aw88261Bharadwaj Raju
Add (and require) the dvdd-supply property for awinic,aw88261 in the awinic,aw88395.yaml binding. The chip needs DVDD to power on, and currently there are no users of this compatible in the kernel device trees, so we should be fine to change the ABI in this case. Signed-off-by: Bharadwaj Raju <bharadwaj.raju@machinesoul.in> Link: https://patch.msgid.link/20260114-aw88261-dvdd-v2-1-ef485b82a7a7@machinesoul.in Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-14ASoC: dt-bindings: add avdd and iovdd supplySascha Hauer
Add bindings for the avdd-supply and iovdd-supply which are named after the corresponding pins on the tlv320adcx140 chips. Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Link: https://patch.msgid.link/20260113-sound-soc-codecs-tvl320adcx140-v4-8-8f7ecec525c8@pengutronix.de Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-14ASoC: dt-bindings: clarify areg-supply documentationEmil-Juhl
The documentation for areg-supply could cause confusion mainly in terms of the relationship between AREG and AVDD. According to the datasheet[1] the AREG can be one of two cases: 1) an external 1.8V supply 2) generated by an internal regulator (hence a 1.8V output) [1] https://www.ti.com/lit/ds/symlink/tlv320adc5140.pdf Signed-off-by: Emil-Juhl <juhl.emildahl@gmail.com> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260113-sound-soc-codecs-tvl320adcx140-v4-7-8f7ecec525c8@pengutronix.de Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-14Merge tag 'phy_common_properties' into nextVinod Koul
phy common properties Vladimir Oltean <vladimir.oltean@nxp.com> wrote: Introduce "rx-polarity" and "tx-polarity" device tree properties with Kunit tests
2026-01-14dt-bindings: phy-common-props: RX and TX lane polarity inversionVladimir Oltean
Differential signaling is a technique for high-speed protocols to be more resilient to noise. At the transmit side we have a positive and a negative signal which are mirror images of each other. At the receiver, if we subtract the negative signal (say of amplitude -A) from the positive signal (say +A), we recover the original single-ended signal at twice its original amplitude. But any noise, like one coming from EMI from outside sources, is supposed to have an almost equal impact upon the positive (A + E, E being for "error") and negative signal (-A + E). So (A + E) - (-A + E) eliminates this noise, and this is what makes differential signaling useful. Except that in order to work, there must be strict requirements observed during PCB design and layout, like the signal traces needing to have the same length and be physically close to each other, and many others. Sometimes it is not easy to fulfill all these requirements, a simple case to understand is when on chip A's pins, the positive pin is on the left and the negative is on the right, but on the chip B's pins (with which A tries to communicate), positive is on the right and negative on the left. The signals would need to cross, using vias and other ugly stuff that affects signal integrity (introduces impedance discontinuities which cause reflections, etc). So sometimes, board designers intentionally connect differential lanes the wrong way, and expect somebody else to invert that signal to recover useful data. This is where RX and TX polarity inversion comes in as a generic concept that applies to any high-speed serial protocol as long as it uses differential signaling. I've stopped two attempts to introduce more vendor-specific descriptions of this only in the past month: https://lore.kernel.org/linux-phy/20251110110536.2596490-1-horatiu.vultur@microchip.com/ https://lore.kernel.org/netdev/20251028000959.3kiac5kwo5pcl4ft@skbuf/ and in the kernel we already have merged: - "st,px_rx_pol_inv" - "st,pcie-tx-pol-inv" - "st,sata-tx-pol-inv" - "mediatek,pnswap" - "airoha,pnswap-rx" - "airoha,pnswap-tx" and maybe more. So it is pretty general. One additional element of complexity is introduced by the fact that for some protocols, receivers can automatically detect and correct for an inverted lane polarity (example: the PCIe LTSSM does this in the Polling.Configuration state; the USB 3.1 Link Layer Test Specification says that the detection and correction of the lane polarity inversion in SuperSpeed operation shall be enabled in Polling.RxEQ.). Whereas for other protocols (SGMII, SATA, 10GBase-R, etc etc), the polarity is all manual and there is no detection mechanism mandated by their respective standards. So why would one even describe rx-polarity and tx-polarity for protocols like PCIe, if it had to always be PHY_POL_AUTO? Related question: why would we define the polarity as an array per protocol? Isn't the physical PCB layout protocol-agnostic, and aren't we describing the same physical reality from the lens of different protocols? The answer to both questions is because multi-protocol PHYs exist (supporting e.g. USB2 and USB3, or SATA and PCIe, or PCIe and Ethernet over the same lane), one would need to manually set the polarity for SATA/Ethernet, while leaving it at auto for PCIe/USB 3.0+. I also investigated from another angle: what if polarity inversion in the PHY is one layer, and then the PCIe/USB3 LTSSM polarity detection is another layer on top? Then rx-polarity = <PHY_POL_AUTO> doesn't make sense, it can still be rx-polarity = <PHY_POL_NORMAL> or <PHY_POL_INVERT>, and the link training state machine figures things out on top of that. This would radically simplify the design, as the elimination of PHY_POL_AUTO inherently means that the need for a property array per protocol also goes away. I don't know how things are in the general case, but at least in the 10G and 28G Lynx SerDes blocks from NXP Layerscape devices, this isn't the case, and there's only a single level of RX polarity inversion: in the SerDes lane. In the case of PCIe, the controller is in charge of driving the RDAT_INV bit autonomously, and it is read-only to software. So the existence of this kind of SerDes lane proves the need for PHY_POL_AUTO to be a third state. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20260111093940.975359-5-vladimir.oltean@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-14dt-bindings: phy-common-props: ensure protocol-names are uniqueVladimir Oltean
Rob Herring points out that "The default for .*-names is the entries don't have to be unique.": https://lore.kernel.org/linux-phy/20251204155219.GA1533839-robh@kernel.org/ Let's use uniqueItems: true to make sure the schema enforces this. It doesn't make sense in this case to have duplicate properties for the same SerDes protocol. Note that this can only be done with the $defs + $ref pattern as established by the previous commit. When the tx-p2p-microvolt-names constraints were expressed directly under "properties", it would have been validated by the string-array meta-schema, which does not support the 'uniqueItems' keyword as can be seen below. properties:tx-p2p-microvolt-names: Additional properties are not allowed ('uniqueItems' was unexpected) from schema $id: http://devicetree.org/meta-schemas/string-array.yaml Suggested-by: Rob Herring <robh@kernel.org> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20260111093940.975359-4-vladimir.oltean@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-14dt-bindings: phy-common-props: create a reusable "protocol-names" definitionVladimir Oltean
Other properties also need to be defined per protocol than just tx-p2p-microvolt-names. Create a common definition to avoid copying a 55 line property. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20260111093940.975359-3-vladimir.oltean@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-14dt-bindings: phy: rename transmit-amplitude.yaml to phy-common-props.yamlVladimir Oltean
I would like to add more properties similar to tx-p2p-microvolt, and I don't think it makes sense to create one schema for each such property (transmit-amplitude.yaml, lane-polarity.yaml, transmit-equalization.yaml etc). Instead, let's rename to phy-common-props.yaml, which makes it a more adequate host schema for all the above properties. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Acked-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20260111093940.975359-2-vladimir.oltean@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-14tee: add revision sysfs attributeAristo Chen
Add a generic TEE revision sysfs attribute backed by a new optional get_tee_revision() callback. The revision string is diagnostic-only and must not be used to infer feature support. Signed-off-by: Aristo Chen <aristo.chen@canonical.com> Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com> Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
2026-01-14fs: use nullfs unconditionally as the real rootfsChristian Brauner
Remove the "nullfs_rootfs" boot parameter and simply always use nullfs. The mutable rootfs will be mounted on top of it. Systems that don't use pivot_root() to pivot away from the real rootfs will have an additional mount stick around but that shouldn't be a problem at all. If it is we'll rever this commit. This also simplifies the boot process and removes the need for the traditional switch_root workarounds. Suggested-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Christian Brauner <brauner@kernel.org>
2026-01-14dt-bindings: ata: sata: Document the graph portManivannan Sadhasivam
An external connector like M.2 could expose the SATA interface to the plugin cards. So add the graph port to establish link between the SATA port and the connector node. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
2026-01-14dt-bindings: phy: qcom,sc8280xp-qmp-ufs-phy: Add QMP UFS PHY compatiblePradeep P V K
Document QMP UFS PHY compatible for x1e80100 SoC. Use SM8550 as a fallback since x1e80100 is fully compatible with it. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Pradeep P V K <pradeep.pragallapati@oss.qualcomm.com> Link: https://patch.msgid.link/20260106154207.1871487-2-pradeep.pragallapati@oss.qualcomm.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-14dt-bindings: phy: qcom,m31-eusb2-phy: Document M31 eUSB2 PHY for KaanapaliRonak Raheja
Document M31 eUSB2 PHY for Kaanapali which handles the USB2 path. Use fallback to indicate the compatibility of the M31 eUSB2 PHY on the Kaanapali with that on the SM8750. Signed-off-by: Ronak Raheja <ronak.raheja@oss.qualcomm.com> Co-developed-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260108052459.1819970-3-krishna.kurapati@oss.qualcomm.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-14dt-bindings: phy: qcom,sc8280xp-qmp-usb43dp-phy: Add Kaanapali QMP PHYRonak Raheja
Document QMP combo PHY for Kaanapali. Use fallback to indicate the compatibility of the QMP PHY on the Kaanapali with that on the SM8750. Signed-off-by: Ronak Raheja <ronak.raheja@oss.qualcomm.com> Co-developed-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com> Link: https://patch.msgid.link/20260108052459.1819970-2-krishna.kurapati@oss.qualcomm.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-14dt-bindings: phy: qcom,sc8280xp-qmp-ufs-phy: document the Milos QMP UFS PHYLuca Weiss
Document the QMP UFS PHY on the Milos SoC. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> Link: https://patch.msgid.link/20260112-milos-ufs-v2-3-d3ce4f61f030@fairphone.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-14dt-bindings: i2c: i2c-mt65xx: Add compatible for MT8189 SoCLouis-Alexis Eyraud
Add compatible string for MT8189 SoC. Its multiple I2C controller instances are compatible with the ones found in the MT8188 SoC. Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2026-01-13Merge branch '20260105-kvmrprocv10-v10-0-022e96815380@oss.qualcomm.com' of ↵Bjorn Andersson
https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into rproc-next Merge the support for loading and managing TustZone-based remote processors found in the Qualcomm Glymur platform from a shared topic branch, as it's a mix of qcom-soc and remoteproc patches.
2026-01-13Merge branch '20260105-kvmrprocv10-v10-0-022e96815380@oss.qualcomm.com' into ↵Bjorn Andersson
drivers-for-6.20 Merge the support for loading and managing the TrustZone-based remote processors found in the Glymur platform through a topic branch, as it's a mix of qcom-soc and remoteproc patches.
2026-01-13Documentation: networking: Document the phy_port infrastructureMaxime Chevallier
This documentation aims at describing the main goal of the phy_port infrastructure. Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Tested-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Link: https://patch.msgid.link/20260108080041.553250-15-maxime.chevallier@bootlin.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-13dt-bindings: net: dp83822: Deprecate ti,fiber-modeMaxime Chevallier
The newly added ethernet-connector binding allows describing an Ethernet connector with greater precision, and in a more generic manner, than ti,fiber-mode. Deprecate this property. Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu> Tested-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Link: https://patch.msgid.link/20260108080041.553250-6-maxime.chevallier@bootlin.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-13dt-bindings: net: Introduce the ethernet-connector descriptionMaxime Chevallier
The ability to describe the physical ports of Ethernet devices is useful to describe multi-port devices, as well as to remove any ambiguity with regard to the nature of the port. Moreover, describing ports allows for a better description of features that are tied to connectors, such as PoE through the PSE-PD devices. Introduce a binding to allow describing the ports, for now with 2 attributes : - The number of pairs, which is a quite generic property that allows differentating between multiple similar technologies such as BaseT1 and "regular" BaseT (which usually means BaseT4). - The media that can be used on that port, such as BaseT for Twisted Copper, BaseC for coax copper, BaseS/L for Fiber, BaseK for backplane ethernet, etc. This allows defining the nature of the port, and therefore avoids the need for vendor-specific properties such as "micrel,fiber-mode" or "ti,fiber-mode". The port description lives in its own file, as it is intended in the future to allow describing the ports for phy-less devices. Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20260108080041.553250-2-maxime.chevallier@bootlin.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-01-14io_uring/zcrx: document area chunking parameterPavel Begunkov
struct io_uring_zcrx_ifq_reg::rx_buf_len is used as a hint specifying the kernel what buffer size it should use. Document the API and limitations. Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
2026-01-13dt-bindings: riscv: extensions: Drop unnecessary select schemaRob Herring (Arm)
The "select" schema is not necessary because this schema is referenced by riscv/cpus.yaml schema. Signed-off-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
2026-01-13dt-bindings: riscv: Add Sha and its comprised extensionsGuodong Xu
Add descriptions for the Sha extension and the seven extensions it comprises: Shcounterenw, Shgatpa, Shtvala, Shvsatpa, Shvstvala, Shvstvecd, and Ssstateen. Sha is ratified in the RVA23 Profiles Version 1.0 (commit 0273f3c921b6 "rva23/rvb23 ratified") as a new profile-defined extension that captures the full set of features that are mandated to be supported along with the H extension. Extensions Shcounterenw, Shgatpa, Shtvala, Shvsatpa, Shvstvala, Shvstvecd, and Ssstateen are ratified in the RISC-V Profiles Version 1.0 (commit b1d806605f87 "Updated to ratified state"). The requirement status for Sha and its comprised extension in RISC-V Profiles are: - Sha: Mandatory in RVA23S64 - H: Optional in RVA22S64; Mandatory in RVA23S64 - Shcounterenw: Optional in RVA22S64; Mandatory in RVA23S64 - Shgatpa: Optional in RVA22S64; Mandatory in RVA23S64 - Shtvala: Optional in RVA22S64; Mandatory in RVA23S64 - Shvsatpa: Optional in RVA22S64; Mandatory in RVA23S64 - Shvstvala: Optional in RVA22S64; Mandatory in RVA23S64 - Shvstvecd: Optional in RVA22S64; Mandatory in RVA23S64 - Ssstateen: Optional in RVA22S64; Mandatory in RVA23S64 Signed-off-by: Guodong Xu <guodong@riscstar.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
2026-01-13dt-bindings: riscv: Add Ssccptr, Sscounterenw, Sstvala, Sstvecd, Ssu64xlGuodong Xu
Add descriptions for five new extensions: Ssccptr, Sscounterenw, Sstvala, Sstvecd, and Ssu64xl. These extensions are ratified in RISC-V Profiles Version 1.0 (commit b1d806605f87 "Updated to ratified state."). They are introduced as new extension names for existing features and regulate implementation details for RISC-V Profile compliance. According to RISC-V Profiles Version 1.0 and RVA23 Profiles Version 1.0, their requirement status are: - Ssccptr: Mandatory in RVA20S64, RVA22S64, RVA23S64 - Sscounterenw: Mandatory in RVA22S64, RVA23S64 - Sstvala: Mandatory in RVA20S64, RVA22S64, RVA23S64 - Sstvecd: Mandatory in RVA20S64, RVA22S64, RVA23S64 - Ssu64xl: Optional in RVA20S64, RVA22S64; Mandatory in RVA23S64 Signed-off-by: Guodong Xu <guodong@riscstar.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
2026-01-13dt-bindings: riscv: Add descriptions for Za64rs, Ziccamoa, Ziccif, and ZicclsmGuodong Xu
Add descriptions for four extensions: Za64rs, Ziccamoa, Ziccif, and Zicclsm. These extensions are ratified in RISC-V Profiles Version 1.0 (commit b1d806605f87 "Updated to ratified state."). They are introduced as new extension names for existing features and regulate implementation details for RISC-V Profile compliance. According to RISC-V Profiles Version 1.0 and RVA23 Profiles Version 1.0, they are mandatory for the following profiles: - za64rs: Mandatory in RVA22U64, RVA23U64 - ziccamoa: Mandatory in RVA20U64, RVA22U64, RVA23U64 - ziccif: Mandatory in RVA20U64, RVA22U64, RVA23U64 - zicclsm: Mandatory in RVA20U64, RVA22U64, RVA23U64 Ziccrse specifies the main memory must support "RsrvEventual", which is one (totally there are four) of the support level for Load-Reserved/ Store-Conditional (LR/SC) atomic instructions. Thus it depends on Zalrsc. Ziccamoa specifies the main memory must support AMOArithmetic, among the four levels of PMA support defined for AMOs in the A extension. Thus it depends on Zaamo. Za64rs defines reservation sets are contiguous, naturally aligned, and a maximum of 64 bytes. Za64rs is consumed by two extensions: Zalrsc and Zawrs. Zawrs itself depends on Zalrsc too. Based on the relationship that "A" = Zaamo + Zalrsc, add the following dependencies checks: Za64rs -> Zalrsc or A Ziccrse -> Zalrsc or A Ziccamoa -> Zaamo or A Signed-off-by: Guodong Xu <guodong@riscstar.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
2026-01-13dt-bindings: riscv: Add B ISA extension descriptionGuodong Xu
Add description of the single-letter B extension for Bit Manipulation. B is mandatory for RVA23U64. The B extension is ratified in the 20240411 version of the unprivileged ISA specification. According to the ratified spec, the B standard extension comprises instructions provided by the Zba, Zbb, and Zbs extensions. Add two-way dependency check to enforce that B implies Zba/Zbb/Zbs; and when Zba/Zbb/Zbs (all of them) are specified, then B must be added too. The reason why B/Zba/Zbb/Zbs must coexist at the same time is that unlike other single-letter extensions, B was ratified (Apr/2024) much later than its component extensions Zba/Zbb/Zbs (Jun/2021). When "b" is specified, zba/zbb/zbs must be present to ensure backward compatibility with existing software and kernels that only look for the explicit component strings. When all three components zba/zbb/zbs are specified, "b" should also be present. Making "b" mandatory when all three components are present. Existing devicetrees with zba/zbb/zbs but without "b" will generate warnings that can be fixed in follow-up patches. Signed-off-by: Guodong Xu <guodong@riscstar.com> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
generated by cgit v1.2.3 (git 2.39.1) at 2026-09-15 01:13:09 +0000