iommu: Warn on premature unblock during DMA aliased sibling reset
When two aliased siblings are in the same iommu_group, they might share the
same RID. The reset functions don't support this case, though it is unclear
whether there is a real case of having an ATS capable device on a PCI/PCI-X
bus.
Theoretically, however, if two aliased devices are resetting concurrently,
one might be unblocked prematurely in the middle of the reset by the other
sibling who completes the reset first.
This isn't a regression from this series but it's better to spit a warning,
so we can know if such use case is common enough for us to make subsequent
patches for its coverage.
iommu: Fix WARN_ON in __iommu_group_set_domain_nofail() due to reset
In __iommu_group_set_domain_internal(), concurrent domain attachments are
rejected when any device in the group is recovering. This is necessary to
fence concurrent attachments to a multi-device group where devices might
share the same RID due to PCI DMA alias quirks, but triggers the WARN_ON in
__iommu_group_set_domain_nofail().
Other IOMMU_SET_DOMAIN_MUST_SUCCEED callers in detach/teardown paths, such
as __iommu_group_set_core_domain and __iommu_release_dma_ownership, should
not be rejected, as the domain would be freed anyway in these nofail paths
while group->domain is still pointing to it. So pci_dev_reset_iommu_done()
could trigger a UAF when re-attaching group->domain.
Honor the IOMMU_SET_DOMAIN_MUST_SUCCEED flag, allowing the callers through
the group->recovery_cnt fence, so as to update the group->domain pointer.
Instead add a gdev->blocked check in the device iteration loop, to prevent
any concurrent per-device detachment.
iommu: Fix ATS invalidation timeouts during __iommu_remove_group_pasid()
If a device is blocked, its PASID domains are already detached. Repeating
iommu_remove_dev_pasid() is unnecessary and might trigger ATS invalidation
timeouts.
Skip the iommu_remove_dev_pasid() call upon gdev->blocked.
Shuai found that cxl_reset_bus_function() calls pci_reset_bus_function()
internally while both are calling pci_dev_reset_iommu_prepare/done().
As pci_dev_reset_iommu_prepare() doesn't support re-entry, the inner call
will trigger a WARN_ON and return -EBUSY, resulting in failing the entire
device reset.
On the other hand, removing the outer calls in the PCI callers is unsafe.
As pointed out by Kevin, device-specific quirks like reset_hinic_vf_dev()
execute custom firmware waits after their inner pcie_flr() completes. If
the IOMMU protection relies solely on the inner reset, the IOMMU will be
unblocked prematurely while the device is still resetting.
Instead, fix this by making pci_dev_reset_iommu_prepare/done() reentrant.
Introduce gdev->reset_depth to handle the re-entries on the same device.
iommu: Replace per-group resetting_domain with per-gdev blocked flag
The core tracks device resetting states with a per-group resetting_domain,
while a reset is actually per group-device. Such a mismatch might lead to
confusion and even difficulty to untangle per-gdev handling requirement.
Shuai found that cxl_reset_bus_function() calls pci_reset_bus_function()
internally while both are calling pci_dev_reset_iommu_prepare/done(). And
the solution requires the core to track at the group_device level as well.
Introduce a 'blocked' flag to struct group_device, to allow a multi-device
group to isolate concurrent device resets independently.
As the reset routine is per gdev, it cannot clear group->resetting_domain
without iterating over the device list to ensure no other device is being
reset. Simplify it by replacing the resetting_domain with a 'recovery_cnt'
in the struct iommu_group.
No functional change. But this is essential to apply following bug fixes.
iommu: Fix NULL group->domain dereference in pci_dev_reset_iommu_done()
Local sashiko review pointed it out that group->domain could be NULL when
a default domain fails to allocate during the first probe, which can crash
at domain->ops->attach_dev dereference in __iommu_attach_device() invoked
by pci_dev_reset_iommu_done().
pci_dev_reset_iommu_prepare() is fine as an old_domain pointer can be NULL.
Skip the re-attach in pci_dev_reset_iommu_done() to fix the bug.
Pramod Maurya [Sun, 10 May 2026 17:52:06 +0000 (13:52 -0400)]
staging: rtl8723bs: Fix block comment style in ieee80211.h
Move trailing '*/' to a new line in multi-line block comments, add
proper ' * ' prefix to comment continuation lines, and consolidate
the OUI_MICROSOFT multi-line comment into a single line.
Biju Das [Tue, 5 May 2026 07:15:37 +0000 (08:15 +0100)]
clk: renesas: r9a08g046: Add RSCI clocks and resets
Add clock and reset entries for the Serial Communications Interfaces
(RSCI) found on the RZ/G3L SoC. This includes various dividers and mux
clocks needed for the four RSCI channels.
iommu/amd: Bounds-check devid in __rlookup_amd_iommu()
iommu_device_register() walks every device on the PCI bus via
bus_for_each_dev() and calls amd_iommu_probe_device() for each. The
inlined check_device() path computes the device's sbdf, calls
rlookup_amd_iommu() to find the owning IOMMU, and only afterwards
verifies devid <= pci_seg->last_bdf. __rlookup_amd_iommu() indexes
rlookup_table[devid] with no bounds check of its own, so for a PCI
device whose BDF is not described by the IVRS, the lookup reads past
the end of the allocation before the caller's bounds check can run.
This was harmless before commit e874c666b15b ("iommu/amd: Change
rlookup, irq_lookup, and alias to use kvalloc()"): the table was a
zeroed page-order allocation, so the over-read returned NULL and the
caller's NULL check skipped the device. After that commit the table is
a tight kvcalloc() and the over-read returns adjacent slab contents,
which check_device() then dereferences as a struct amd_iommu *,
causing a boot-time GPF.
Seen on Google Compute Engine ct6e VMs, where the virtualized IVRS
describes only the four TPU endpoints 00:04.0-07.0; the gVNIC at
00:08.0 (devid 0x40) indexes 56 bytes past the 456-byte allocation,
into the adjacent kmalloc-512 slab object:
pci 0000:00:04.0: Adding to iommu group 0
pci 0000:00:05.0: Adding to iommu group 1
pci 0000:00:06.0: Adding to iommu group 2
pci 0000:00:07.0: Adding to iommu group 3
Oops: general protection fault, probably for non-canonical address 0x3a64695f78746382: 0000 [#1] SMP NOPTI
CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.18.22 #1
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 12/06/2025
RIP: 0010:amd_iommu_probe_device+0x54/0x3a0
Call Trace:
__iommu_probe_device+0x107/0x520
probe_iommu_group+0x29/0x50
bus_for_each_dev+0x7e/0xe0
iommu_device_register+0xc9/0x240
iommu_go_to_state+0x9c0/0x1c60
amd_iommu_init+0x14/0x40
pci_iommu_init+0x16/0x60
do_one_initcall+0x47/0x2f0
Guard the array access in __rlookup_amd_iommu(). With the fix applied
on 6.18.22, the gVNIC at 00:08.0 is skipped cleanly and the VM boots.
Fixes: e874c666b15b ("iommu/amd: Change rlookup, irq_lookup, and alias to use kvalloc()") Cc: stable@vger.kernel.org Reported-by: Ziyuan Chen <zc@anthropic.com> Tested-by: Ziyuan Chen <zc@anthropic.com> Reviewed-by: Josef Bacik <josef@toxicpanda.com> Assisted-by: Claude:unspecified Signed-off-by: Jose Fernandez (Anthropic) <jose.fernandez@linux.dev> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
The macros IOMMU_IN/OUT_ADDR_BIT_SIZE became unused after commit 2fdf6db436e3 ("iommu/amd: Remove AMD io_pgtable support"), which removed
the last references in io_pgtable.c and io_pgtable_v2.c. Remove them to
clean up unused definitions.
Signed-off-by: Wei Wang <wei.w.wang@hotmail.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Jennifer Guo [Sun, 10 May 2026 06:58:29 +0000 (23:58 -0700)]
staging: rtl8723bs: remove unnecessary blank lines in rtw_recv.c
Remove unnecessary blank lines around braces {}.
This fixes the following checkpatch.pl checks in rtw_recv.c:
- CHECK: Blank lines aren't necessary after an open brace '{'
- CHECK: Blank lines aren't necessary before a close brace '}'
iommupt: Encode IOMMU_MMIO/IOMMU_CACHE via RISC-V Svpbmt bits
When the RISC-V IOMMU page table format support Svpbmt, PBMT provides
a way to tag mappings with page-based memory types. Encode memory type
via PBMT in RISC-V IOMMU PTEs:
iommu/riscv: Advertise Svpbmt support to generic page table
The RISC-V IOMMU can optionally support Svpbmt page-based memory types
in its page table format. When present,the generic page table code can
use this capability to encode memory attributes (e.g. MMIO vs normal
memory) in PTEs.
Signed-off-by: Fangyu Yu <fangyu.yu@linux.alibaba.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Anup Patel <anup@brainfault.org> Reviewed-by: Guo Ren <guoren@kernel.org> Reviewed-by: Nutty Liu <nutty.liu@hotmail.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Found a block comment formatting warning in odm_interface.h
via checkpatch.pl. As far as I can tell, this block comment is no
longer useful. Hence proposing to remove it.
The Verisilicon IOMMU hardware block can be found in combination
with Verisilicon hardware video codecs (encoders or decoders) on
different SoCs.
Enable it will allow us to use non contiguous memory allocators
for Verisilicon video codecs.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
dt-bindings: iommu: verisilicon: Add binding for VSI IOMMU
Add a device tree binding for the Verisilicon (VSI) IOMMU.
This IOMMU sits in front of hardware encoder and decoder
blocks on SoCs using Verisilicon IP, such as the Rockchip RK3588.
gpio: add GPIO controller found on Waveshare DSI TOUCH panels
The Waveshare DSI TOUCH family of panels has separate on-board GPIO
controller, which controls power supplies to the panel and the touch
screen and provides reset pins for both the panel and the touchscreen.
Also it provides a simple PWM controller for panel backlight. Add
support for this GPIO controller.
The Waveshare DSI TOUCH family of panels has separate on-board GPIO
controller, which controls power supplies to the panel and the touch
screen and provides reset pins for both the panel and the touchscreen.
Also it provides a simple PWM controller for panel backlight.
Add bindings for these GPIO controllers. As overall integration might be
not very obvious (and it differs significantly from the bindings used by
the original drivers), provide complete example with the on-board
regulators and the DSI panel.
Chen-Yu Tsai [Thu, 7 May 2026 05:29:41 +0000 (13:29 +0800)]
power: sequencing: print power sequencing device parent in debugfs
The debugfs summary currently shows the power sequencing device's name.
This is not really helpful since the device name is always "pwrseq.N".
Also print the parent device's name. This would likely be the device
node name from the device tree, something like "nvme-connector". This
would make it much easier for the developer to associate the summary
with a certain device.
Eder Zulian [Fri, 10 Apr 2026 12:55:50 +0000 (14:55 +0200)]
iommu/amd: Remove latent out-of-bounds access in IOMMU debugfs
In iommu_mmio_write() and iommu_capability_write(), the variables
dbg_mmio_offset and dbg_cap_offset are declared as int. However, they
are populated using kstrtou32_from_user(). If a user provides a
sufficiently large value, it can become a negative integer.
Prior to this patch, the AMD IOMMU debugfs implementation was already
protected by different mechanisms.
1. #define OFS_IN_SZ 8 ensures the user string <= 8 bytes, so
e.g. 0xffffffff isn't a valid input.
if (cnt > OFS_IN_SZ)
return -EINVAL;
2. Implicit type promotion in iommu_mmio_write(), dbg_mmio_offset is int
and iommu->mmio_phys_end is u64
if (dbg_mmio_offset > iommu->mmio_phys_end - sizeof(u64))
return -EINVAL;
3. The show handlers would currently catch the negative number and
refuse to perform the read.
Replace kstrtou32_from_user() with kstrtos32_from_user() to parse the
input, and check for negative values to explicitly prevent out-of-bounds
memory accesses directly in iommu_mmio_write() and
iommu_capability_write().
Signed-off-by: Eder Zulian <ezulian@redhat.com> Fixes: 7a4ee419e8c1 ("iommu/amd: Add debugfs support to dump IOMMU MMIO registers") Cc: stable@vger.kernel.org Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
staging: vme_user: remove unnecessary NULL initialization before list iteration
Remove redundant NULL initialization for list iterator because
variables used as iterators in list_for_each_entry() do not require
initialization, as the macro assigns them before first use.
Andrea Righi [Mon, 11 May 2026 06:18:12 +0000 (08:18 +0200)]
sched_ext: Fix ops->priv clobber on concurrent attach/detach
Under heavy concurrent attach/detach operations, scx_claim_exit() can
trigger a NULL pointer dereference. This can be reproduced running the
reload_loop kselftests inside a virtme-ng session:
T1 acquires scx_enable_mutex inside scx_root_disable()'s mutex_unlock
window and starts a fresh attach on the same kdata, assigning sch_a800
to @ops->priv. T2 then continues out of scx_disable()/flush_disable_work
and clobbers @ops->priv to NULL, leaking sch_a800; the bpf_link is gone
but state stays SCX_ENABLED, so all future attaches fail with -EBUSY
permanently. The next bpf_scx_unreg() on that kdata then reads NULL
@ops->priv and dereferences it in scx_claim_exit().
Make @ops->priv the lifecycle binding: in scx_root_enable_workfn() and
scx_sub_enable_workfn(), after the existing state check and still under
scx_enable_mutex, refuse with -EBUSY if @ops->priv is non-NULL. This
rejects an attempt to reuse a kdata that is still bound to a previous
scheduler instance, closing the race without changing the unreg side.
Yu Zhang [Tue, 31 Mar 2026 15:25:50 +0000 (23:25 +0800)]
iommu/amd: Remove dead code for exclusion ranges in IVMD
Exclusion ranges in IVMD are treated as unity mappings with r&w
permissions since commit 0bbe4ced53e3 ("iommu/amd: Fix the
overwritten field in IVMD header"), using 1:1 mappings. And IOMMU
Exclusion Base & Range Limit Registers (0x0020/0x0028) are actually
no longer used.
As a result, several definitions and code paths became dead code:
- exclusion_start/exclusion_length in struct amd_iommu are never
assigned,
- iommu_set_exclusion_range() always returns 0 now.
- MMIO_EXCL_ENABLE_MASK & MMIO_EXCL_ALLOW_MASK are only used by
the removed iommu_set_exclusion_range().
- DEV_ENTRY_EX is no longer set in any DTE.
- IOMMU_UNITY_MAP_FLAG_EXCL_RANGE is no longer set, thus the
IOMMU_RESV_RESERVED branch in amd_iommu_get_resv_regions() is
no longer reachable.
Just remove all of the dead code. No functional change.
Signed-off-by: Yu Zhang <zhangyu1@linux.microsoft.com> Reviewed-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com> Reviewed-by: Jacob Pan <jacob.pan@linux.microsoft.com> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
iommu/amd: Explicitly bail from enable_iommus_vapic() when in legacy mode
Bail early from enable_iommus_vapic() if IOMMUs are configured for either
of the legacy modes, as it's absurdly difficult to see that
iommu_ga_log_enable() is guaranteed to fail because iommu_init_ga_log()
skips allocating the ga_log.
Opportunistically have iommu_ga_log_enable() WARN if it's called without
IOMMUs being configured to support AVIC/vAPIC.
Jani Nikula [Fri, 8 May 2026 10:20:49 +0000 (13:20 +0300)]
Documentation/gpu: add remaining DOC: comments to Intel display documentation
Not all of the overview DOC: comments in the display driver are
incorporated into the documentation. Add the missing ones, including
some function documentation.
Jani Nikula [Fri, 8 May 2026 10:20:47 +0000 (13:20 +0300)]
Documentation/gpu: add dedicated documentation for Intel display
Nowadays, the display support for drm/i915 and drm/xe is shared between
the drivers, even though the code is located under drm/i915/display.
The drm/i915 documentation has everything, including display topics, in
one huge page, while the drm/xe documentation is well-organized but
hardly mentions display. It's not great, to put it mildly.
Split out the Intel display documentation to a dedicated directory,
Documentation/gpu/intel-display. Also directly split the
functionality/feature documentation to dedicated pages to keep the main
index page high level and readable. We'll want to organize this further,
but just sort them alphabetically for starters.
Drop the boilerplate documentation sections that don't actually document
anything.
Cross-reference drm/i915, drm/xe, and intel-display.
In preparation for adding support for 3, 5, 6 and 7 port devices, replace
the current one-bit-per-type encoding of the number of ports with a more
compact four bit encoding (2..16 ports or undefined).
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Johan Hovold <johan@kernel.org>
Albert Esteve [Fri, 8 May 2026 07:04:50 +0000 (09:04 +0200)]
drm/panel: Make drm_panel_init() static
Now that all panel drivers use devm_drm_panel_alloc(),
there are no external callers of drm_panel_init().
Make it static to prevent new users from bypassing the
refcounted allocation path.
Remove stale references to drm_panel_init() in kdocs.
Reviewed-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Albert Esteve <aesteve@redhat.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260508-drm_panel_init_rm-v2-10-0bd4ac429971@redhat.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
Albert Esteve [Fri, 8 May 2026 07:04:49 +0000 (09:04 +0200)]
drm/panel/startek-kd070fhfid015: Use refcounted allocation in place of devm_kzalloc()
Move to using the new API devm_drm_panel_alloc() to allocate the
panel. In the call to the new API, avoid using explicit type and use
__typeof() for more type safety.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Albert Esteve <aesteve@redhat.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260508-drm_panel_init_rm-v2-9-0bd4ac429971@redhat.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
Albert Esteve [Fri, 8 May 2026 07:04:48 +0000 (09:04 +0200)]
drm/panel/truly-nt35597: Use refcounted allocation in place of devm_kzalloc()
Move to using the new API devm_drm_panel_alloc() to allocate the
panel. In the call to the new API, avoid using explicit type and use
__typeof() for more type safety.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Albert Esteve <aesteve@redhat.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260508-drm_panel_init_rm-v2-8-0bd4ac429971@redhat.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
Albert Esteve [Fri, 8 May 2026 07:04:47 +0000 (09:04 +0200)]
drm/panel/sharp-ls043t1le01: Use refcounted allocation in place of devm_kzalloc()
Move to using the new API devm_drm_panel_alloc() to allocate the
panel. In the call to the new API, avoid using explicit type and use
__typeof() for more type safety.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Albert Esteve <aesteve@redhat.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260508-drm_panel_init_rm-v2-7-0bd4ac429971@redhat.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
Albert Esteve [Fri, 8 May 2026 07:04:46 +0000 (09:04 +0200)]
drm/panel/tdo-tl070wsh30: Use refcounted allocation in place of devm_kzalloc()
Move to using the new API devm_drm_panel_alloc() to allocate the
panel. In the call to the new API, avoid using explicit type and use
__typeof() for more type safety.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Albert Esteve <aesteve@redhat.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260508-drm_panel_init_rm-v2-6-0bd4ac429971@redhat.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
Albert Esteve [Fri, 8 May 2026 07:04:45 +0000 (09:04 +0200)]
drm/panel/ilitek-ili9806e: Use refcounted allocation in place of devm_kzalloc()
Move to using the new API devm_drm_panel_alloc() to allocate the
panel. In the call to the new API, avoid using explicit type and use
__typeof() for more type safety.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Albert Esteve <aesteve@redhat.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260508-drm_panel_init_rm-v2-5-0bd4ac429971@redhat.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
Albert Esteve [Fri, 8 May 2026 07:04:44 +0000 (09:04 +0200)]
drm/panel/lxd-m9189a: Use refcounted allocation in place of devm_kzalloc()
Move to using the new API devm_drm_panel_alloc() to allocate the
panel. In the call to the new API, avoid using explicit type and use
__typeof() for more type safety.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Albert Esteve <aesteve@redhat.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260508-drm_panel_init_rm-v2-4-0bd4ac429971@redhat.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
Albert Esteve [Fri, 8 May 2026 07:04:43 +0000 (09:04 +0200)]
drm/panel/novatek-nt37700f: Use refcounted allocation in place of devm_kzalloc()
Move to using the new API devm_drm_panel_alloc() to allocate the
panel. In the call to the new API, avoid using explicit type and use
__typeof() for more type safety.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Albert Esteve <aesteve@redhat.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260508-drm_panel_init_rm-v2-3-0bd4ac429971@redhat.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
Albert Esteve [Fri, 8 May 2026 07:04:42 +0000 (09:04 +0200)]
drm/panel/samsung-s6e63m0: Use refcounted allocation in place of devm_kzalloc()
Move to using the new API devm_drm_panel_alloc() to allocate the
panel. In the call to the new API, avoid using explicit type and use
__typeof() for more type safety.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Albert Esteve <aesteve@redhat.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260508-drm_panel_init_rm-v2-2-0bd4ac429971@redhat.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
Albert Esteve [Fri, 8 May 2026 07:04:41 +0000 (09:04 +0200)]
drm/panel/visionox-g2647fb105: Use refcounted allocation in place of devm_kzalloc()
Move to using the new API devm_drm_panel_alloc() to allocate the
panel. In the call to the new API, avoid using explicit type and use
__typeof() for more type safety. Also deduplicate the prepare_prev_first
assignment that was set both before and after drm_panel_init().
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Albert Esteve <aesteve@redhat.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260508-drm_panel_init_rm-v2-1-0bd4ac429971@redhat.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
Michal Piekos [Wed, 6 May 2026 15:10:29 +0000 (17:10 +0200)]
arm64: dts: allwinner: h616: add hstimer node
Describe high speed timer block on Allwinner H616.
Tested on Orange Pi Zero 3:
- hstimer is registered as clocksource
- switching clocksource at runtime works
- after rating increase hstimer operates as a broadcast clockevent device
Michal Piekos [Wed, 6 May 2026 15:10:28 +0000 (17:10 +0200)]
riscv: dts: allwinner: d1s-t113: add hstimer node
Describe high speed timer block on Allwinner D1S-T113.
Tested on LCPI-PC-T113/F113:
- hstimer is registered as clocksource
- switching clocksource at runtime works
- after rating increase hstimer operates as a broadcast clockevent device
Signed-off-by: Michal Piekos <michal.piekos@mmpsystems.pl> Reviewed-by: Chen-Yu Tsai <wens@kernel.org> Link: https://patch.msgid.link/20260506-h616-t113s-hstimer-v4-3-591d425863d6@mmpsystems.pl
[wens@kernel.org: change subject prefix from "arm" to "riscv"]
[wens@kernel.org: fix interrupt representation] Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
drm/i915/dp: Drop call to intel_panel_fixed_mode() from compute_config
At the moment, in intel_dp_compute_config(), intel_panel_fixed_mode() is
called to check if the panel has any fixed mode or not. If it is an eDP
and has the fixed mode, then intel_panel_compute_config() is called.
However, the intel_panel_compute_config already checks if the panel
supports a fixed mode and returns early if it doesn't. This makes the
earlier check in the caller redundant.
Remove this extra check for intel_panel_fixed_mode().
drm/i915/intel_sdvo: Drop call to intel_panel_fixed_mode() from compute_config
Currently, in intel_sdvo_compute_config(), intel_panel_fixed_mode() is
called to get the fixed mode. However, since the call is made after
intel_panel_compute_config, that copies the selected fixed mode to the
adjusted mode, we can directly use the crtc_state->hw.adjusted_mode.
So remove the extra call to intel_panel_fixed_mode() and use adjusted
mode instead.
drm/i915/intel_dvo: Drop call to intel_panel_fixed_mode() from compute_config
The function intel_dvo_compute_config() calls intel_panel_fixed_mode() only
to check if there is a valid fixed_mode and based on that it then calls
intel_panel_compute_config().
However, since the intel_panel_compute_config() already checks for
fixed_mode and we can drop the call to intel_panel_fixed_mode().
drm/i915/intel_panel: Avoid calls to intel_panel_fixed_mode() in mode_valid
Currently, most callers of intel_panel_mode_valid() also call
intel_panel_fixed_mode(). This is done either to check for the presence of
a fixed mode for the connector or to get the clock of the fixed mode, which
is then compared against the max dotclock for the pipe.
Since intel_panel_mode_valid() already calls intel_panel_fixed_mode()
internally, we can avoid yet another call to intel_panel_fixed_mode() from
the caller.
Remove the redundant call to intel_panel_fixed_mode() in mode_valid paths.
To get the clock for the fixed mode, extend the helper
intel_panel_mode_valid() to accept 'target_clock' as an out param.
The 'target_clock' can then be used by the callers to check against the
max dotclock.
Suraj Kandpal [Tue, 5 May 2026 09:40:22 +0000 (15:10 +0530)]
drm/i915/hdcp: Skip inactive MST connectors when building stream list
intel_hdcp_required_content_stream() walks every connector on the
digital port to populate hdcp_port_data->streams[]. The only filter is
connector_status_disconnected, which reflects physical presence on the
MST topology, not whether the connector currently drives a stream.
On a multi-sink MST setup where only a subset of sinks are modeset,
the loop can pick a sibling MST connector that is connected but has
no active CRTC / VC payload. intel_conn_to_vcpi() then logs "MST
Payload not present" and returns 0, and the bogus StreamID=0 is
written to the repeater in RepeaterAuth_Stream_Manage (DPCD 0x693F0).
Authentication completes, but the repeater shortly raises
LINK_INTEGRITY_FAILURE (RxStatus 0x69493 bit4) because the StreamID
does not match any stream on its input. The HDCP check work then
tears the link down, the Content Protection property drops back to
DESIRED, and userspace observes a spurious HDCP enable failure.
Filter the connector iteration to only those with a CRTC assigned in
the new atomic state, so intel_conn_to_vcpi() is called for the
connector actually being enabled and reads its real VCPI from the MST
topology state.
Devin Li [Wed, 6 May 2026 02:52:54 +0000 (10:52 +0800)]
arm64: dts: cix: Add SCMI performance domains for CPUFreq on Sky1
Add SCMI Protocol 13 (Performance) node under ap_to_pm_scmi with
domains.
Define SKY1_PERF_* macros in sky1-power.h for all performance domain
IDs (CPU L/B0/B1/M0/M1, GPU, DSU, NPU, VPU, CI700, NI700), and
wire each CPU node to its corresponding performance domain using
power-domains and power-domain-names properties.
platform/chrome: cros_kbd_led_backlight: Drop CONFIG_MFD_CROS_EC_DEV ifdeffery
The ifdeffery is unnecessary, as the compiler can already optimize away
all of the mfd-specific code based on the IS_ENABLED() in
keyboard_led_is_mfd_device().
platform/chrome: cros_kbd_led_backlight: Pass keyboard_led as parameter
Make the code simpler to read by passing the 'struct keyboard_led' as
a parameter to the 'init' callbacks instead of relying on the platform
device driver data.
A race condition exists between the probe of cros-ec-sysfs and
cros-ec-sensorhub.
The `kb_wake_angle` attribute should only be visible if the sensor hub
detects two or more accelerometers. If cros_ec_sysfs_probe() runs
before cros_ec_sensorhub_register() completes sensor enumeration, the
sysfs attributes are created while `has_kb_wake_angle` is still false,
hiding `kb_wake_angle` incorrectly.
Store the created attribute group pointer in `ec_dev->group`. When
the sensor hub completes sensor enumeration, it checks for this group
and calls sysfs_update_group() to notify the sysfs core to re-evaluate
attribute visibility. This ensures the `kb_wake_angle` attribute
visibility is correctly updated regardless of the driver probe order.
Andrea Righi [Sun, 10 May 2026 17:52:11 +0000 (19:52 +0200)]
selftests/sched_ext: Fix build error in dequeue selftest
Building the dequeue selftest with newer compilers (e.g., gcc 16)
triggers the following error:
dequeue.c:28:22: error: variable 'sum' set but not used
The 'volatile' qualifier prevents the writes from being optimized away,
but does not silence the unused variable 'sum' is indeed only written
and never read.
Consume 'sum' via an empty asm() with a register input constraint. This
forces the compiler to keep the accumulated value (preserving the CPU
stress loop) and avoiding the build error.
Fixes: 658ad2259b3e ("selftests/sched_ext: Add test to validate ops.dequeue() semantics") Signed-off-by: Andrea Righi <arighi@nvidia.com> Signed-off-by: Tejun Heo <tj@kernel.org>
cg_read_strcmp() allocated a buffer sized to strlen(expected) + 1,
then passed it to read_text() which calls read(fd, buf, size-1).
When comparing against an empty string (""), strlen("") = 0 gives a
1-byte buffer, and read() is asked to read 0 bytes. The file content
is never actually read, so strcmp("", buf) always returns 0 regardless
of the real content. This caused cg_test_proc_killed() to always
report the cgroup as empty immediately, making OOM tests pass without
verifying that processes were killed.
Signed-off-by: Hongfu Li <lihongfu@kylinos.cn> Signed-off-by: Tejun Heo <tj@kernel.org>
Guopeng Zhang [Mon, 11 May 2026 01:31:50 +0000 (09:31 +0800)]
cgroup/dmem: Return -ENOMEM on failed pool preallocation
get_cg_pool_unlocked() handles allocation failures under dmemcg_lock by
dropping the lock, preallocating a pool with GFP_KERNEL, and retrying the
locked lookup and creation path.
If the fallback allocation fails too, pool remains NULL. Since the loop
condition is while (!pool), the function can keep retrying instead of
propagating the allocation failure to the caller.
Set pool to ERR_PTR(-ENOMEM) when the fallback allocation fails so the
loop exits through the existing common return path. The callers already
handle ERR_PTR() from get_cg_pool_unlocked(), so this restores the
expected error path.
ASoC: core: Move all users to deferrable card binding
Commit a3375522bb5e2 ("ASoC: core: Complete support for card rebinding")
completed the feature and at the same time divided ASoC users into two
groups:
1) cards that fail to enumerate the moment one of the components is
not available
2) cards that succeed to enumerate even if some of their components
become available late
Given the component-based nature of ASoC, approach 2) is preferred and
can be used by all ASoC users. By dropping 1) the card binding code can
also be simplified.
Flatten code that is currently conditional based on ->devres_dev and
convert snd_soc_rebind_card() to call_soc_bind_card(). The latter is a
selector between managed and unmanaged card-binding behaviour to keep
non-devm users happy.
With rebinding being the default, devm_snd_soc_register_card() takes
form of its deferrable friend - all the devm job is already done by
devm_snd_soc_bind_card().
projects / thirdparty / kernel / linux.git / log
