summaryrefslogtreecommitdiff
path: root/include
AgeCommit message (Collapse)Author
2026-03-25drm/simple-kms: Deprecate simple-kms helpersThomas Zimmermann
Deprecate simple-encoder and simple-display-pipe helpers in favor of regular atomic helpers. Remove the related documentation. Add TODO item for converting the remaining drivers. These helpers have been deprecated for years and many drivers have been updated to not use them. Still there are a few left and we occasionally receive new drivers build upon them. Marking them as deprecated will hopefully resolve these problems. The TODO items should be easy enough for getting new voluteers started on DRM driver development. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: David Lechner <david@lechnology.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://patch.msgid.link/20260319160110.109610-17-tzimmermann@suse.de
2026-03-25drm/mipi-dbi: Remove simple-display helpers from mipi-dbiThomas Zimmermann
With the conversion to regular atomic helpers, mipi-dbi's support for simple-display helpers is unused. Removed it. v2: - remove unused connector from struct mipi_dbi_dev Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: David Lechner <david@lechnology.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://patch.msgid.link/20260319160110.109610-16-tzimmermann@suse.de
2026-03-25drm/mipi-dbi: Provide callbacks for atomic interfacesThomas Zimmermann
Refactor the existing simple-display callbacks such that they invoke helpers compatible with regular atomic modesetting. Allows for adding mipi-dbi drives that do not require simple-display helpers. Provide initializer macro for elements of the regular modesetting pipeline. These will be used by drivers to integrate mipi-dbi helpers. Also provide initializer macros for the plane formats. As the new helpers are DRM functions, add the drm_ prefix. Mipi-dbi interfaces currently lack this. v3: - fix uninitialized variable (David) - document public interfaces (David) - mention format macros in commit message (David) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: David Lechner <david@lechnology.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://patch.msgid.link/20260319160110.109610-4-tzimmermann@suse.de
2026-03-25drm/mipi-dbi: Support custom pipelines with drm_mipi_dbi_dev_init()Thomas Zimmermann
Initialize the mipi-dbi device with drm_mipi_dbi_dev_init() without creating a modesetting pipeline. Will allow for mipi-dbi drivers without simple-display helpers. As the new helper is a DRM function, add the drm_ prefix. Mipi-dbi interfaces currently lack this. v3: - document tx_buf_size parameter (David) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: David Lechner <david@lechnology.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://patch.msgid.link/20260319160110.109610-3-tzimmermann@suse.de
2026-03-25drm/mipi-dbi: Only modify planes on enabled CRTCsThomas Zimmermann
Use drm_atomic_helper_commit_tail_rpm() as commit tail to update the plane after enabling the CRTC. Then remove the plane-update code from mipi_dbi_enable_flush() and inline the remaining backlight code where necessary. Mipi-dbi's current commit tail drm_atomic_helper_commit_tail() first updates the plane and then enables the CRTC. But the CRTC enablement includes power management that prevents the initial plane update from working. Hence, each mipi-dbi driver includes a plane update in their CRTC enablement; in the form of mipi_dbi_enable_flush() or custom code. Using drm_atomic_helper_commit_tail_rpm() enables the CRTC before any plane updates. Hence the additional plane update can be removed from mipi_dbi_enable_flush() and a number of drivers. This leaves backlight_enable() in the helper, which can now be inlined into affected drivers. Drivers now enable the CRTC plus an optional backlight and then automatically update the plane. In the case of disabling the display, drm_atomic_helper_commit_tail_rpm() only disables the CRTC without touching the plane at all. Mipi-dbi's mipi_dbi_pipe_disable() already contains the necessary logic. Removing the plane update from the CRTC enablement will also help with converting mipi-dbi from simple-pipe helpers to regular atomic helpers. v3: - st7586: remove unused variable v2: - ili9225: remove unused variables (David) - st7586: remove unused variables (David) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: David Lechner <david@lechnology.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://patch.msgid.link/20260319160110.109610-2-tzimmermann@suse.de
2026-03-25cpufreq: acpi-cpufreq: use DMI max speed when CPPC is unavailableHenry Tseng
On AMD Ryzen Embedded V1780B (Family 17h, Zen 1), the BIOS does not provide ACPI _CPC objects and the CPU does not support MSR-based CPPC (X86_FEATURE_CPPC). The _PSS table only lists nominal P-states (P0 = 3350 MHz), so when get_max_boost_ratio() fails at cppc_get_perf_caps(), cpuinfo_max_freq reports only the base frequency instead of the rated boost frequency (3600 MHz). dmesg: ACPI CPPC: No CPC descriptor for CPU:0 acpi_cpufreq: CPU0: Unable to get performance capabilities (-19) cppc-cpufreq already has a DMI fallback (cppc_get_dmi_max_khz()) that reads the processor max speed from SMBIOS Type 4. Export it and reuse it in acpi-cpufreq as a last-resort source for the boost frequency. A sanity check ensures the DMI value is above the _PSS P0 frequency and within 2x of it; values outside that range are ignored and the existing arch_set_max_freq_ratio() path is taken instead. The 2x upper bound is based on a survey of the AMD Ryzen Embedded V1000 series, where the highest boost-to-base ratio is 1.8x (V1404I: 2.0 GHz base / 3.6 GHz boost). The DMI lookup and sanity check are wrapped in a helper, acpi_cpufreq_resolve_max_freq(), which falls through to arch_set_max_freq_ratio() if the DMI value is absent or out of range. Tested on AMD Ryzen Embedded V1780B with v7.0-rc4: Before: cpuinfo_max_freq = 3350000 (base only) After: cpuinfo_max_freq = 3600000 (includes boost) Link: https://www.amd.com/en/products/embedded/ryzen/ryzen-v1000-series.html#specifications Signed-off-by: Henry Tseng <henrytseng@qnap.com> Link: https://patch.msgid.link/20260324090948.1667340-1-henrytseng@qnap.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-03-25drbd: use genl pre_doit/post_doitChristoph Böhmwalder
Every doit handler followed the same pattern: stack-allocate an adm_ctx, call drbd_adm_prepare() at the top, call drbd_adm_finish() at the bottom. This duplicated boilerplate across 25 handlers and made error paths inconsistent, since some handlers could miss sending the reply skb on early-exit paths. The generic netlink framework already provides pre_doit/post_doit hooks for exactly this purpose. An old comment even noted "this would be a good candidate for a pre_doit hook". Use them: - pre_doit heap-allocates adm_ctx, looks up per-command flags from a new drbd_genl_cmd_flags[] table, runs drbd_adm_prepare(), and stores the context in info->user_ptr[0]. - post_doit sends the reply, drops kref references for device/connection/resource, and frees the adm_ctx. - Handlers just receive adm_ctx from info->user_ptr[0], set reply_dh->ret_code, and return. All teardown is in post_doit. - drbd_adm_finish() is removed, superseded by post_doit. Signed-off-by: Christoph Böhmwalder <christoph.boehmwalder@linbit.com> Link: https://patch.msgid.link/20260324152907.2840984-1-christoph.boehmwalder@linbit.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2026-03-25mfd: bcm2835-pm: Introduce SoC-specific type identifierPhil Elwell
Power management blocks across the BCM2835 family share a common base but require variant-specific handling. For instance, the BCM2712 lacks ASB register space, yet it manages the power domain for the V3D graphics block. Add a hardware type identifier to the driver's private data. This allows the driver to distinguish between SoC models and implement custom quirks or features as needed. Signed-off-by: Phil Elwell <phil@raspberrypi.com> Co-developed-by: Stanimir Varbanov <svarbanov@suse.de> Signed-off-by: Stanimir Varbanov <svarbanov@suse.de> Signed-off-by: Andrea della Porta <andrea.porta@suse.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://patch.msgid.link/c4bb218654e91f312a01b419d3d408e5131f7673.1772839224.git.andrea.porta@suse.com Signed-off-by: Lee Jones <lee@kernel.org>
2026-03-25mfd: si476x: Fix kernel-doc warningsRandy Dunlap
Add kernel-doc entries for missing fields or correct some typos in names to eliminate kernel-doc warnings: Warning: include/linux/mfd/si476x-core.h:156 struct member 'regmap' not described in 'si476x_core' Warning: include/linux/mfd/si476x-core.h:156 struct member 'power_state' not described in 'si476x_core' Warning: include/linux/mfd/si476x-core.h:156 struct member 'supplies' not described in 'si476x_core' Warning: include/linux/mfd/si476x-core.h:156 struct member 'is_alive' not described in 'si476x_core' Warning: include/linux/mfd/si476x-core.h:156 struct member 'rds_fifo_depth' not described in 'si476x_core' Warning: include/linux/mfd/si476x-core.h:170 function parameter 'core' not described in 'si476x_core_lock' Warning: include/linux/mfd/si476x-core.h:179 function parameter 'core' not described in 'si476x_core_unlock' Warning: include/linux/mfd/si476x-core.h:259 struct member 'firmware' not described in 'si476x_func_info' Warning: include/linux/mfd/si476x-core.h:335 struct member 'rds' not described in 'si476x_rds_status_report' I don't know what the 'ble' field is so I didn't add a kernel-doc comment for it: Warning: include/linux/mfd/si476x-core.h:335 struct member 'ble' not described in 'si476x_rds_status_report' Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Link: https://patch.msgid.link/20260309214223.749088-5-rdunlap@infradead.org Signed-off-by: Lee Jones <lee@kernel.org>
2026-03-25mfd: rsmu: Remove a empty kernel-doc lineRandy Dunlap
kernel-doc format expects a prototype on the line that immediately follows the "/**" line, so drop this empty line. Warning: include/linux/mfd/rsmu.h:21 Cannot find identifier on line: * Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Link: https://patch.msgid.link/20260309214223.749088-4-rdunlap@infradead.org Signed-off-by: Lee Jones <lee@kernel.org>
2026-03-25mfd: kempld: Fix kernel-doc struct member namesRandy Dunlap
Correct the struct member names to avoid kernel-doc warnings: Warning: include/linux/mfd/kempld.h:114 struct member 'gpio_base' not described in 'kempld_platform_data' Warning: include/linux/mfd/kempld.h:114 struct member 'get_hardware_mutex' not described in 'kempld_platform_data' Warning: include/linux/mfd/kempld.h:114 struct member 'release_hardware_mutex' not described in 'kempld_platform_data' Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Link: https://patch.msgid.link/20260309214223.749088-3-rdunlap@infradead.org Signed-off-by: Lee Jones <lee@kernel.org>
2026-03-25mfd: congatec: Fix kernel-doc struct member namesRandy Dunlap
Correct the struct member names to avoid kernel-doc warnings: Warning: include/linux/mfd/cgbc.h:38 struct member 'version' not described in 'cgbc_device_data' Warning: ../include/linux/mfd/cgbc.h:38 struct member 'lock' not described in 'cgbc_device_data' Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Link: https://patch.msgid.link/20260309214223.749088-2-rdunlap@infradead.org Signed-off-by: Lee Jones <lee@kernel.org>
2026-03-25mfd: mt6397: Properly fix CID of MT6328, MT6331 and MT6332Akari Tsuyukusa
CIDs set for MT6328, MT6331 and MT6332 are not appropriate. Many Android downstream kernels define CID as below, MT6328: #define PMIC6328_E1_CID_CODE 0x2810 #define PMIC6328_E2_CID_CODE 0x2820 #define PMIC6328_E3_CID_CODE 0x2830 MT6331/MT6332: #define PMIC6331_E1_CID_CODE 0x3110 #define PMIC6331_E2_CID_CODE 0x3120 #define PMIC6331_E3_CID_CODE 0x3130 #define PMIC6332_E1_CID_CODE 0x3210 #define PMIC6332_E2_CID_CODE 0x3220 #define PMIC6332_E3_CID_CODE 0x3230 The current configuration incorrectly uses the revision code as the CID. Therefore, the driver cannot detect the same PMIC of different revisions. (E1/E2 for MT6328, E1/E3 for MT6331/MT6332) Based on these, the CID of MT6328, MT6331 and MT6332 should be corrected. Additionally, the incorrect MT6331/MT6332 CID overlaps with the MT6320's actual CID: #define PMIC6320_E1_CID_CODE 0x1020 #define PMIC6320_E2_CID_CODE 0x2020 This causes a conflict in the switch-case statement of mt6397-irq.c, this prevents adding support for MT6320. Signed-off-by: Akari Tsuyukusa <akkun11.open@gmail.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://patch.msgid.link/20260302140045.651727-1-akkun11.open@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
2026-03-25mfd: lpc_ich: Expose the GPIO controller cell's software nodeBartosz Golaszewski
One of the users of this driver - meraki-mx100 - abuses the software node API by setting up a dummy software node without any logical link to this GPIO controller and uses the fact that the GPIO core matches the controller's label against the swnode's name to make the lookup work. We want to remove this behavior from GPIOLIB in favor of actual matching of firmware nodes but that would break this user. To facilitate that: create a software node for the GPIO controller cell and expose its address in the provided MFD header. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20260218-meraki-swnodes-v2-1-92c521da241c@oss.qualcomm.com Signed-off-by: Lee Jones <lee@kernel.org>
2026-03-25mfd: atmel-hlcdc: Fetch LVDS PLL clock for LVDS displayManikandan Muralidharan
The XLCDC IP supports parallel RGB, MIPI DSI and LVDS Display. The LCD Generic clock (sys_clk) is used for Parallel RGB and MIPI displays, while the LVDS PLL clock (lvds_pll_clk) is used for LVDS displays.Since both the clocks cannot co-exist together in the DT for a given display, this patch tries sys_clk first (RGB/MIPI), fallback to lvds_pll_clk (LVDS). Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com> Signed-off-by: Dharma Balasubiramani <dharma.b@microchip.com> Link: https://patch.msgid.link/20260223101920.284697-2-manikandan.m@microchip.com Signed-off-by: Lee Jones <lee@kernel.org>
2026-03-25ASoC: SDCA: remove the max count of initialization tableShuming Fan
The number of the initialization table may exceed 2048. Therefore, this patch removes the limitation and allows the driver to allocate memory dynamically based on the size of the initialization table. Signed-off-by: Shuming Fan <shumingf@realtek.com> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20260325092017.3221640-1-shumingf@realtek.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-03-25quota: Fix race of dquot_scan_active() with quota deactivationJan Kara
dquot_scan_active() can race with quota deactivation in quota_release_workfn() like: CPU0 (quota_release_workfn) CPU1 (dquot_scan_active) ============================== ============================== spin_lock(&dq_list_lock); list_replace_init( &releasing_dquots, &rls_head); /* dquot X on rls_head, dq_count == 0, DQ_ACTIVE_B still set */ spin_unlock(&dq_list_lock); synchronize_srcu(&dquot_srcu); spin_lock(&dq_list_lock); list_for_each_entry(dquot, &inuse_list, dq_inuse) { /* finds dquot X */ dquot_active(X) -> true atomic_inc(&X->dq_count); } spin_unlock(&dq_list_lock); spin_lock(&dq_list_lock); dquot = list_first_entry(&rls_head); WARN_ON_ONCE(atomic_read(&dquot->dq_count)); The problem is not only a cosmetic one as under memory pressure the caller of dquot_scan_active() can end up working on freed dquot. Fix the problem by making sure the dquot is removed from releasing list when we acquire a reference to it. Fixes: 869b6ea1609f ("quota: Fix slow quotaoff") Reported-by: Sam Sun <samsun1006219@gmail.com> Link: https://lore.kernel.org/all/CAEkJfYPTt3uP1vAYnQ5V2ZWn5O9PLhhGi5HbOcAzyP9vbXyjeg@mail.gmail.com Signed-off-by: Jan Kara <jack@suse.cz>
2026-03-25drm/mipi-dsi: add RGB101010 pixel formatAlexander Koskovich
Add MIPI_DSI_FMT_RGB101010 for 30 bit (10,10,10 RGB) pixel format, corresponding to the packed 30 bit pixel stream defined in MIPI DSI v1.3 Section 8.8.17. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Alexander Koskovich <akoskovich@pm.me> Patchwork: https://patchwork.freedesktop.org/patch/713714/ Link: https://lore.kernel.org/r/20260324-dsi-rgb101010-support-v5-1-ff6afc904115@pm.me [Acked by Maxime to be merged through msm-next on IRC on dri-devel] [DB: moved RGB101010 to the end of enum mipi_dsi_pixel_format] Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-03-25Merge branch 'ib-scmi-pinctrl-gpio' of ↵Bartosz Golaszewski
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl into gpio/for-next Pull in the SCMI GPIO driver along with its pinctrl dependencies.
2026-03-25media: uvcvideo: Add support for P010 pixel formatOliver Collyer
Add support for the P010 (10-bit Y/UV 4:2:0) pixel format to the uvcvideo driver. This format is exposed by USB capture devices such as the Magewell USB Capture HDMI 4K Pro when capturing HDR10 content. P010 stores 10-bit Y and interleaved UV samples in 16-bit little-endian words, with data in the upper 10 bits and zeros in the lower 6 bits. This requires 2 bytes per sample, so bytesperline is wWidth * 2. V4L2_PIX_FMT_P010 was added to the V4L2 core in commit 5374d8fb75f3 ("media: Add P010 video format"). Based on the community DKMS patch from awawa-dev/P010_for_V4L2. Link: https://github.com/awawa-dev/P010_for_V4L2 Signed-off-by: Oliver Collyer <ovcollyer@mac.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://patch.msgid.link/20251226065718.95504-1-ovcollyer@mac.com Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-03-25dma-mapping: add missing `inline` for `dma_free_attrs`Miguel Ojeda
Under an UML build for an upcoming series [1], I got `-Wstatic-in-inline` for `dma_free_attrs`: BINDGEN rust/bindings/bindings_generated.rs - due to target missing In file included from rust/helpers/helpers.c:59: rust/helpers/dma.c:17:2: warning: static function 'dma_free_attrs' is used in an inline function with external linkage [-Wstatic-in-inline] 17 | dma_free_attrs(dev, size, cpu_addr, dma_handle, attrs); | ^ rust/helpers/dma.c:12:1: note: use 'static' to give inline function 'rust_helper_dma_free_attrs' internal linkage 12 | __rust_helper void rust_helper_dma_free_attrs(struct device *dev, size_t size, | ^ | static The issue is that `dma_free_attrs` was not marked `inline` when it was introduced alongside the rest of the stubs. Thus mark it. Fixes: ed6ccf10f24b ("dma-mapping: properly stub out the DMA API for !CONFIG_HAS_DMA") Closes: https://lore.kernel.org/rust-for-linux/20260322194616.89847-1-ojeda@kernel.org/ [1] Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://lore.kernel.org/r/20260325015548.70912-1-ojeda@kernel.org
2026-03-24dt-bindings: clock, reset: Add econet EN751221Caleb James DeLisle
Add clock and reset bindings for EN751221 as well as a "chip-scu" which is an additional regmap that is used by the clock driver as well as others. This split of the SCU across two register areas is the same as the Airoha AN758x family. Signed-off-by: Caleb James DeLisle <cjd@cjdns.fr> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2026-03-24randomize_kstack: Unify random source across archesRyan Roberts
Previously different architectures were using random sources of differing strength and cost to decide the random kstack offset. A number of architectures (loongarch, powerpc, s390, x86) were using their timestamp counter, at whatever the frequency happened to be. Other arches (arm64, riscv) were using entropy from the crng via get_random_u16(). There have been concerns that in some cases the timestamp counters may be too weak, because they can be easily guessed or influenced by user space. And get_random_u16() has been shown to be too costly for the level of protection kstack offset randomization provides. So let's use a common, architecture-agnostic source of entropy; a per-cpu prng, seeded at boot-time from the crng. This has a few benefits: - We can remove choose_random_kstack_offset(); That was only there to try to make the timestamp counter value a bit harder to influence from user space [*]. - The architecture code is simplified. All it has to do now is call add_random_kstack_offset() in the syscall path. - The strength of the randomness can be reasoned about independently of the architecture. - Arches previously using get_random_u16() now have much faster syscall paths, see below results. [*] Additionally, this gets rid of some redundant work on s390 and x86. Before this patch, those architectures called choose_random_kstack_offset() under arch_exit_to_user_mode_prepare(), which is also called for exception returns to userspace which were *not* syscalls (e.g. regular interrupts). Getting rid of choose_random_kstack_offset() avoids a small amount of redundant work for the non-syscall cases. In some configurations, add_random_kstack_offset() will now call instrumentable code, so for a couple of arches, I have moved the call a bit later to the first point where instrumentation is allowed. This doesn't impact the efficacy of the mechanism. There have been some claims that a prng may be less strong than the timestamp counter if not regularly reseeded. But the prng has a period of about 2^113. So as long as the prng state remains secret, it should not be possible to guess. If the prng state can be accessed, we have bigger problems. Additionally, we are only consuming 6 bits to randomize the stack, so there are only 64 possible random offsets. I assert that it would be trivial for an attacker to brute force by repeating their attack and waiting for the random stack offset to be the desired one. The prng approach seems entirely proportional to this level of protection. Performance data are provided below. The baseline is v6.18 with rndstack on for each respective arch. (I)/(R) indicate statistically significant improvement/regression. arm64 platform is AWS Graviton3 (m7g.metal). x86_64 platform is AWS Sapphire Rapids (m7i.24xlarge): +-----------------+--------------+---------------+---------------+ | Benchmark | Result Class | per-cpu-prng | per-cpu-prng | | | | arm64 (metal) | x86_64 (VM) | +=================+==============+===============+===============+ | syscall/getpid | mean (ns) | (I) -9.50% | (I) -17.65% | | | p99 (ns) | (I) -59.24% | (I) -24.41% | | | p99.9 (ns) | (I) -59.52% | (I) -28.52% | +-----------------+--------------+---------------+---------------+ | syscall/getppid | mean (ns) | (I) -9.52% | (I) -19.24% | | | p99 (ns) | (I) -59.25% | (I) -25.03% | | | p99.9 (ns) | (I) -59.50% | (I) -28.17% | +-----------------+--------------+---------------+---------------+ | syscall/invalid | mean (ns) | (I) -10.31% | (I) -18.56% | | | p99 (ns) | (I) -60.79% | (I) -20.06% | | | p99.9 (ns) | (I) -61.04% | (I) -25.04% | +-----------------+--------------+---------------+---------------+ I tested an earlier version of this change on x86 bare metal and it showed a smaller but still significant improvement. The bare metal system wasn't available this time around so testing was done in a VM instance. I'm guessing the cost of rdtsc is higher for VMs. Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Ryan Roberts <ryan.roberts@arm.com> Link: https://patch.msgid.link/20260303150840.3789438-3-ryan.roberts@arm.com Signed-off-by: Kees Cook <kees@kernel.org>
2026-03-24randomize_kstack: Maintain kstack_offset per taskRyan Roberts
kstack_offset was previously maintained per-cpu, but this caused a couple of issues. So let's instead make it per-task. Issue 1: add_random_kstack_offset() and choose_random_kstack_offset() expected and required to be called with interrupts and preemption disabled so that it could manipulate per-cpu state. But arm64, loongarch and risc-v are calling them with interrupts and preemption enabled. I don't _think_ this causes any functional issues, but it's certainly unexpected and could lead to manipulating the wrong cpu's state, which could cause a minor performance degradation due to bouncing the cache lines. By maintaining the state per-task those functions can safely be called in preemptible context. Issue 2: add_random_kstack_offset() is called before executing the syscall and expands the stack using a previously chosen random offset. choose_random_kstack_offset() is called after executing the syscall and chooses and stores a new random offset for the next syscall. With per-cpu storage for this offset, an attacker could force cpu migration during the execution of the syscall and prevent the offset from being updated for the original cpu such that it is predictable for the next syscall on that cpu. By maintaining the state per-task, this problem goes away because the per-task random offset is updated after the syscall regardless of which cpu it is executing on. Fixes: 39218ff4c625 ("stack: Optionally randomize kernel stack offset each syscall") Closes: https://lore.kernel.org/all/dd8c37bc-795f-4c7a-9086-69e584d8ab24@arm.com/ Cc: stable@vger.kernel.org Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Ryan Roberts <ryan.roberts@arm.com> Link: https://patch.msgid.link/20260303150840.3789438-2-ryan.roberts@arm.com Signed-off-by: Kees Cook <kees@kernel.org>
2026-03-24tcp: add cwnd_event_tx_start to tcp_congestion_opsEric Dumazet
(tcp_congestion_ops)->cwnd_event() is called very often, with @event oscillating between CA_EVENT_TX_START and other values. This is not branch prediction friendly. Provide a new cwnd_event_tx_start pointer dedicated for CA_EVENT_TX_START. Both BBR and CUBIC benefit from this change, since they only care about CA_EVENT_TX_START. No change in kernel size: $ scripts/bloat-o-meter -t vmlinux.0 vmlinux add/remove: 4/4 grow/shrink: 3/1 up/down: 564/-568 (-4) Function old new delta bbr_cwnd_event_tx_start - 450 +450 cubictcp_cwnd_event_tx_start - 70 +70 __pfx_cubictcp_cwnd_event_tx_start - 16 +16 __pfx_bbr_cwnd_event_tx_start - 16 +16 tcp_unregister_congestion_control 93 99 +6 tcp_update_congestion_control 518 521 +3 tcp_register_congestion_control 422 425 +3 __tcp_transmit_skb 3308 3306 -2 __pfx_cubictcp_cwnd_event 16 - -16 __pfx_bbr_cwnd_event 16 - -16 cubictcp_cwnd_event 80 - -80 bbr_cwnd_event 454 - -454 Total: Before=25240512, After=25240508, chg -0.00% Signed-off-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20260323234920.1097858-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-24net_sched: codel: fix stale state for empty flows in fq_codelJonas Köppeler
When codel_dequeue() finds an empty queue, it resets vars->dropping but does not reset vars->first_above_time. The reference CoDel algorithm (Nichols & Jacobson, ACM Queue 2012) resets both: dodeque_result codel_queue_t::dodeque(time_t now) { ... if (r.p == NULL) { first_above_time = 0; // <-- Linux omits this } ... } Note that codel_should_drop() does reset first_above_time when called with a NULL skb, but codel_dequeue() returns early before ever calling codel_should_drop() in the empty-queue case. The post-drop code paths do reach codel_should_drop(NULL) and correctly reset the timer, so a dropped packet breaks the cycle -- but the next delivered packet re-arms first_above_time and the cycle repeats. For sparse flows such as ICMP ping (one packet every 200ms-1s), the first packet arms first_above_time, the flow goes empty, and the second packet arrives after the interval has elapsed and gets dropped. The pattern repeats, producing sustained loss on flows that are not actually congested. Test: veth pair, fq_codel, BQL disabled, 30000 iptables rules in the consumer namespace (NAPI-64 cycle ~14ms, well above fq_codel's 5ms target), ping at 5 pps under UDP flood: Before fix: 26% ping packet loss After fix: 0% ping packet loss Fix by resetting first_above_time to zero in the empty-queue path of codel_dequeue(), matching the reference algorithm. Fixes: 76e3cc126bb2 ("codel: Controlled Delay AQM") Fixes: d068ca2ae2e6 ("codel: split into multiple files") Co-developed-by: Jesper Dangaard Brouer <hawk@kernel.org> Signed-off-by: Jesper Dangaard Brouer <hawk@kernel.org> Signed-off-by: Jonas Köppeler <j.koeppeler@tu-berlin.de> Reported-by: Chris Arges <carges@cloudflare.com> Tested-by: Jonas Köppeler <j.koeppeler@tu-berlin.de> Reviewed-by: Toke Høiland-Jørgensen <toke@redhat.com> Link: https://lore.kernel.org/all/20260318134826.1281205-7-hawk@kernel.org/ Reviewed-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20260323174920.253526-1-hawk@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-03-24Merge commit 'f35dbac6942171dc4ce9398d1d216a59224590a9' into ↵Steven Rostedt
trace/ring-buffer/core The commit f35dbac69421 ("ring-buffer: Fix to update per-subbuf entries of persistent ring buffer") was a fix and merged upstream. It is needed for some other work in the ring buffer. The current branch has the remote buffer code that is shared with the Arm64 subsystem and can't be rebased. Merge in the upstream commit to allow continuing of the ring buffer work. Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
2026-03-24clk: divider: Add devm_clk_hw_register_divider_parent_dataXuyang Dong
Add the devres variant of clk_hw_register_divider_parent_data() for registering a divider clock with parent clk data instead of parent name. Reviewed-by: Brian Masney <bmasney@redhat.com> Signed-off-by: Xuyang Dong <dongxuyang@eswincomputing.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2026-03-24dt-bindings: clock: eswin: Documentation for eic7700 SoCXuyang Dong
Add device tree binding documentation for the ESWIN eic7700 clock controller module. Signed-off-by: Yifeng Huang <huangyifeng@eswincomputing.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Acked-by: Troy Mitchell <troy.mitchell@linux.dev> Tested-by: Marcel Ziswiler <marcel@ziswiler.com> # ebc77 Signed-off-by: Xuyang Dong <dongxuyang@eswincomputing.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2026-03-24entry: Add missing kernel-doc for arch_ptrace_report_syscall functionsKit Dallege
Document @regs and @step parameters for arch_ptrace_report_syscall_entry() and arch_ptrace_report_syscall_exit() that were missing from the kernel-doc comments. Signed-off-by: Kit Dallege <xaum.io@gmail.com> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Assisted-by: Claude:claude-opus-4-6 Link: https://patch.msgid.link/20260315170941.65913-1-xaum.io@gmail.com
2026-03-24module: Move 'struct module_signature' to UAPIThomas Weißschuh
This structure definition is used outside the kernel proper. For example in kmod and the kernel build environment. To allow reuse, move it to a new UAPI header. While it is not a true UAPI, it is a common practice to have non-UAPI interface definitions in the kernel's UAPI headers. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Reviewed-by: Petr Pavlu <petr.pavlu@suse.com> Reviewed-by: Nicolas Schier <nsc@kernel.org> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
2026-03-24module: Give MODULE_SIG_STRING a more descriptive nameThomas Weißschuh
The purpose of the constant it is not entirely clear from its name. As this constant is going to be exposed in a UAPI header, give it a more specific name for clarity. As all its users call it 'marker', use that wording in the constant itself. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Reviewed-by: Petr Pavlu <petr.pavlu@suse.com> Reviewed-by: Nicolas Schier <nsc@kernel.org> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
2026-03-24module: Give 'enum pkey_id_type' a more specific nameThomas Weißschuh
This enum originates in generic cryptographic code and has a very generic name. Nowadays it is only used for module signatures. As this enum is going to be exposed in a UAPI header, give it a more specific name for clarity and consistency. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Reviewed-by: Petr Pavlu <petr.pavlu@suse.com> Reviewed-by: Nicolas Schier <nsc@kernel.org> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
2026-03-24module: Drop unused signature typesThomas Weißschuh
Only PKCS#7 signatures are used today. Remove the unused enum values. As this enum is used in on-disk data, preserve the numeric value. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Reviewed-by: Petr Pavlu <petr.pavlu@suse.com> Reviewed-by: Nicolas Schier <nsc@kernel.org> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
2026-03-24Merge tag 'v7.0-rc5' into nextDmitry Torokhov
Sync up with mainline to pull in a fix for smb compilation error.
2026-03-24cgroup: Wait for dying tasks to leave on rmdirTejun Heo
a72f73c4dd9b ("cgroup: Don't expose dead tasks in cgroup") hid PF_EXITING tasks from cgroup.procs so that systemd doesn't see tasks that have already been reaped via waitpid(). However, the populated counter (nr_populated_csets) is only decremented when the task later passes through cgroup_task_dead() in finish_task_switch(). This means cgroup.procs can appear empty while the cgroup is still populated, causing rmdir to fail with -EBUSY. Fix this by making cgroup_rmdir() wait for dying tasks to fully leave. If the cgroup is populated but all remaining tasks have PF_EXITING set (the task iterator returns none due to the existing filter), wait for a kick from cgroup_task_dead() and retry. The wait is brief as tasks are removed from the cgroup's css_set between PF_EXITING assertion in do_exit() and cgroup_task_dead() in finish_task_switch(). v2: cgroup_is_populated() true to false transition happens under css_set_lock not cgroup_mutex, so retest under css_set_lock before sleeping to avoid missed wakeups (Sebastian). Fixes: a72f73c4dd9b ("cgroup: Don't expose dead tasks in cgroup") Reported-by: kernel test robot <oliver.sang@intel.com> Closes: https://lore.kernel.org/oe-lkp/202603222104.2c81684e-lkp@intel.com Reported-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Tejun Heo <tj@kernel.org> Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Cc: Bert Karwatzki <spasswolf@web.de> Cc: Michal Koutny <mkoutny@suse.com> Cc: cgroups@vger.kernel.org
2026-03-24f2fs: call f2fs_handle_critical_error() to set cp_error flagChao Yu
f2fs_handle_page_eio() is the only left place we set CP_ERROR_FLAG directly, it missed to update superblock.s_stop_reason, let's call f2fs_handle_critical_error() instead to fix that. Introduce STOP_CP_REASON_READ_{META,NODE,DATA} stop_cp_reason enum variable to indicate which kind of data we failed to read. Signed-off-by: Chao Yu <chao@kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
2026-03-24tracing: trace_mmap.h: fix a kernel-doc warningRandy Dunlap
Add a description of struct reader to resolve a kernel-doc warning: Warning: include/uapi/linux/trace_mmap.h:43 struct member 'reader' not described in 'trace_buffer_meta' Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
2026-03-24Merge tag 'mm-hotfixes-stable-2026-03-23-17-56' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Pull MM fixes from Andrew Morton: "6 hotfixes. 2 are cc:stable. All are for MM. All are singletons - please see the changelogs for details" * tag 'mm-hotfixes-stable-2026-03-23-17-56' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: mm/damon/stat: monitor all System RAM resources mm/zswap: add missing kunmap_local() mailmap: update email address for Muhammad Usama Anjum zram: do not slot_free() written-back slots mm/damon/core: avoid use of half-online-committed context mm/rmap: clear vma->anon_vma on error
2026-03-24drm/panthor: extend timestamp query with flagsMarcin Slusarz
Flags now control which data user space wants to query, there is more information sources, and there's ability to query duration of multiple timestamp reads. New sources: - CPU's monotonic, - CPU's monotonic raw, - GPU's cycle count These changes should make the implementation of VK_KHR_calibrated_timestamps more accurate and much simpler. Signed-off-by: Marcin Slusarz <marcin.slusarz@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patch.msgid.link/20260324132557.1707286-1-marcin.slusarz@arm.com
2026-03-24bpf: Remove inclusions of crypto/sha1.hEric Biggers
Since commit 603b44162325 ("bpf: Update the bpf_prog_calc_tag to use SHA256") made BPF program tags use SHA-256 instead of SHA-1, the header <crypto/sha1.h> no longer needs to be included. Remove the relevant inclusions so that they no longer unnecessarily come up in searches for which kernel code is still using the obsolete SHA-1 algorithm. Since net/ipv6/addrconf.c was relying on the transitive inclusion of <crypto/sha1.h> (for an unrelated purpose) via <linux/filter.h>, make it include <crypto/sha1.h> explicitly in order to keep that file building. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Acked-by: Paul Chaignon <paul.chaignon@gmail.com> Link: https://lore.kernel.org/r/20260314214555.112386-1-ebiggers@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-03-24ASoc: uda1380: Improve error reportingMark Brown
Wenyuan Li <2063309626@qq.com> says: The driver currently ignores the return values of several I2C operations during register writes, which could lead to silent failures and inconsistent device state. Link: https://patch.msgid.link/tencent_579D057AC557914CF739A2D9EAD045CE7306@qq.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-03-24spi: use generic driver_override infrastructureDanilo Krummrich
When a driver is probed through __driver_attach(), the bus' match() callback is called without the device lock held, thus accessing the driver_override field without a lock, which can cause a UAF. Fix this by using the driver-core driver_override infrastructure taking care of proper locking internally. Note that calling match() from __driver_attach() without the device lock held is intentional. [1] Also note that we do not enable the driver_override feature of struct bus_type, as SPI - in contrast to most other buses - passes "" to sysfs_emit() when the driver_override pointer is NULL. Thus, printing "\n" instead of "(null)\n". Link: https://lore.kernel.org/driver-core/DGRGTIRHA62X.3RY09D9SOK77P@kernel.org/ [1] Reported-by: Gui-Dong Han <hanguidong02@gmail.com> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220789 Fixes: 5039563e7c25 ("spi: Add driver_override SPI device attribute") Signed-off-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20260324005919.2408620-12-dakr@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2026-03-24Merge tag 'ipsec-2026-03-23' of ↵Paolo Abeni
git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec Steffen Klassert says: ==================== pull request (net): ipsec 2026-03-23 1) Add missing extack for XFRMA_SA_PCPU in add_acquire and allocspi. From Sabrina Dubroca. 2) Fix the condition on x->pcpu_num in xfrm_sa_len by using the proper check. From Sabrina Dubroca. 3) Call xdo_dev_state_delete during state update to properly cleanup the xdo device state. From Sabrina Dubroca. 4) Fix a potential skb leak in espintcp when async crypto is used. From Sabrina Dubroca. 5) Validate inner IPv4 header length in IPTFS payload to avoid parsing malformed packets. From Roshan Kumar. 6) Fix skb_put() panic on non-linear skb during IPTFS reassembly. From Fernando Fernandez Mancera. 7) Silence various sparse warnings related to RCU, state, and policy handling. From Sabrina Dubroca. 8) Fix work re-schedule race after cancel in xfrm_nat_keepalive_net_fini(). From Hyunwoo Kim. 9) Prevent policy_hthresh.work from racing with netns teardown by using a proper cleanup mechanism. From Minwoo Ra. 10) Validate that the family of the source and destination addresses match in pfkey_send_migrate(). From Eric Dumazet. 11) Only publish mode_data after the clone is setup in the IPTFS receive path. This prevents leaving x->mode_data pointing at freed memory on error. From Paul Moses. Please pull or let me know if there are problems. ipsec-2026-03-23 * tag 'ipsec-2026-03-23' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec: xfrm: iptfs: only publish mode_data after clone setup af_key: validate families in pfkey_send_migrate() xfrm: prevent policy_hthresh.work from racing with netns teardown xfrm: Fix work re-schedule after cancel in xfrm_nat_keepalive_net_fini() xfrm: avoid RCU warnings around the per-netns netlink socket xfrm: add rcu_access_pointer to silence sparse warning for xfrm_input_afinfo xfrm: policy: silence sparse warning in xfrm_policy_unregister_afinfo xfrm: policy: fix sparse warnings in xfrm_policy_{init,fini} xfrm: state: silence sparse warnings during netns exit xfrm: remove rcu/state_hold from xfrm_state_lookup_spi_proto xfrm: state: add xfrm_state_deref_prot to state_by* walk under lock xfrm: state: fix sparse warnings around XFRM_STATE_INSERT xfrm: state: fix sparse warnings in xfrm_state_init xfrm: state: fix sparse warnings on xfrm_state_hold_rcu xfrm: iptfs: fix skb_put() panic on non-linear skb during reassembly xfrm: iptfs: validate inner IPv4 header length in IPTFS payload esp: fix skb leak with espintcp and async crypto xfrm: call xdo_dev_state_delete during state update xfrm: fix the condition on x->pcpu_num in xfrm_sa_len xfrm: add missing extack for XFRMA_SA_PCPU in add_acquire and allocspi ==================== Link: https://patch.msgid.link/20260323083440.2741292-1-steffen.klassert@secunet.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-03-24compiler: Simplify generic RELOC_HIDE()Marco Elver
When enabling Context Analysis (CONTEXT_ANALYSIS := y) in arch/x86/kvm code, Clang's Thread Safety Analysis failed to recognize that identical per_cpu() accesses refer to the same lock: | CC [M] arch/x86/kvm/vmx/posted_intr.o | arch/x86/kvm/vmx/posted_intr.c:186:2: error: releasing raw_spinlock '__ptr + __per_cpu_offset[vcpu->cpu]' that was not held [-Werror,-Wthread-safety-analysis] | 186 | raw_spin_unlock(&per_cpu(wakeup_vcpus_on_cpu_lock, vcpu->cpu)); | | ^ | ./include/linux/spinlock.h:276:32: note: expanded from macro 'raw_spin_unlock' | 276 | #define raw_spin_unlock(lock) _raw_spin_unlock(lock) | | ^ | arch/x86/kvm/vmx/posted_intr.c:207:1: error: raw_spinlock '__ptr + __per_cpu_offset[vcpu->cpu]' is still held at the end of function [-Werror,-Wthread-safety-analysis] | 207 | } | | ^ | arch/x86/kvm/vmx/posted_intr.c:182:2: note: raw_spinlock acquired here | 182 | raw_spin_lock_nested(&per_cpu(wakeup_vcpus_on_cpu_lock, vcpu->cpu), | | ^ | ./include/linux/spinlock.h:235:2: note: expanded from macro 'raw_spin_lock_nested' | 235 | _raw_spin_lock(((void)(subclass), (lock))) | | ^ | 2 errors generated. This occurred because the default RELOC_HIDE() implementation (used by the per-CPU macros) is a statement expression containing an intermediate 'unsigned long' variable (this version appears to predate Git history). While the analysis strips away inner casts when resolving pointer aliases, it stops when encountering intermediate non-pointer variables (this is Thread Safety Analysis specific and irrelevant for codegen). This prevents the analysis from concluding that the pointers passed to e.g. raw_spin_lock() and raw_spin_unlock() were identical when per-CPU accessors are used. Simplify RELOC_HIDE() to a single expression. This preserves the intent of obfuscating UB-introducing out-of-bounds pointer calculations from the compiler via the 'unsigned long' cast, but allows the alias analysis to successfully resolve the pointers. Using a recent Clang version, I observe that generated code remains the same for vmlinux; the intermediate variable was already being optimized away (for any respectable modern compiler, not doing so would be an optimizer bug). Note that GCC provides its own version of RELOC_HIDE(), so this change only affects Clang builds. Add a test case to lib/test_context-analysis.c to catch any regressions. Reported-by: Bart Van Assche <bvanassche@acm.org> Reported-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Marco Elver <elver@google.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/all/e3946223-4543-4a76-a328-9c6865e95192@acm.org/ Link: https://patch.msgid.link/20260319135245.1420780-1-elver@google.com
2026-03-24iommu/tegra241-cmdqv: Update uAPI to clarify HYP_OWN requirementNicolin Chen
>From hardware implementation perspective, a guest tegra241-cmdqv hardware is different than the host hardware: - Host HW is backed by a VINTF (HYP_OWN=1) - Guest HW is backed by a VINTF (HYP_OWN=0) The kernel driver has an implementation requirement of the HYP_OWN bit in the VM. So, VMM must follow that to allow the same copy of Linux to work. Add this requirement to the uAPI, which is currently missing. Fixes: 4dc0d12474f9 ("iommu/tegra241-cmdqv: Add user-space use support") Signed-off-by: Nicolin Chen <nicolinc@nvidia.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-03-24ASoC: sdw_utils: add vendor_id to asoc_sdw_codec_infoNiranjan H Y
struct asoc_sdw_codec_info has part_id which is not sufficient to uniquely identify devices. This change adds the vendor_id field and updates the codec_info list with the corresponding vendor id as per the Manufacturer's id in https://mid.mipi.org/ Signed-off-by: Niranjan H Y <niranjan.hy@ti.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20260324041300.784-1-niranjan.hy@ti.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-03-24drm/display: hdmi: Use drm_output_color_format instead of hdmi_colorspaceMaxime Ripard
The hdmi_colorspace enum was defined to represent the colorspace value of the HDMI infoframes. It was later used by some HDMI drivers to express the output format they should be setting up. During the introduction of the HDMI helpers, it then was used to represent it in the drm_connector_hdmi_state structure. However, it's always been somewhat redundant with the DRM_COLOR_FORMAT_* defines, and now with the drm_output_color_format enum. Let's consolidate around drm_output_color_format in drm_connector_hdmi_state to facilitate the current effort to provide a global output format selection mechanism. Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260305-drm-rework-color-formats-v3-14-f3935f6db579@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-03-24drm/connector: Remove DRM_COLOR_FORMAT definesMaxime Ripard
Now that all users of DRM_COLOR_FORMAT_* defines have been converted to the new enum, we can get rid of those defines. Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260305-drm-rework-color-formats-v3-13-f3935f6db579@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-03-24drm/connector: Introduce drm_output_color_format enumMaxime Ripard
The EDID parsing code initially introduced the DRM_COLOR_FORMAT_* defines to represent the sink capabilities. Since a given sink could support multiple formats, it was first defined as a bitmask. However, the core and drivers have since leveraged those defines to represent both the supported formats but also the current format being used. Considering the latter case, the more natural, and consistent, thing to do would be to create an enum of all the possible formats, and then list the supported formats using a bitmask of the individual enum values. Let's create a new enum following that pattern, drm_output_color_format, while maintaining the DRM_COLOR_FORMAT_* compatibility to make the transition easier. Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260305-drm-rework-color-formats-v3-1-f3935f6db579@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
generated by cgit v1.2.3 (git 2.25.1) at 2026-05-21 22:26:51 +0000