summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2026-07-24platform/x86: int1092: Fix info leak in parse_package()Abdun Nihaal1-4/+4
Sashiko reports a possible information leak that can occur as follows: 1. In parse_package(), memory allocated for data->device_mode_info is not zerozed initially as it is allocated with devm_kmalloc_array(). 2. In the for loop after the allocation, a malformed ACPI package provided by firmware can cause some fields in data->device_mode_info to remain uninitialized. 3. Later in update_sar_data(), the uninitialized fields gets copied to the fields of context->sar_data, which can be exposed to userspace through sysfs attribute read (intc_data_show()). Fix the leak by switching to use devm_kcalloc() for allocation. Reported-by: Sashiko <sashiko-bot@kernel.org> Closes: https://sashiko.dev/#/patchset/20260710052806.100107-1-nihaal%40cse.iitm.ac.in Signed-off-by: Abdun Nihaal <nihaal@cse.iitm.ac.in> Link: https://patch.msgid.link/20260723-platx86-v4-2-93b4a178b595@cse.iitm.ac.in Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-07-24platform/x86: int1092: Fix potential memory leak in sar_probe()Abdun Nihaal1-22/+10
The memory allocated for device_mode_info in parse_package() called by sar_get_data() is not freed in some of the error paths in sar_probe(). Fix that by converting to use device managed allocations. Fixes: dcfbd31ef4bc ("platform/x86: BIOS SAR driver for Intel M.2 Modem") Cc: stable@vger.kernel.org Signed-off-by: Abdun Nihaal <nihaal@cse.iitm.ac.in> Link: https://patch.msgid.link/20260723-platx86-v4-1-93b4a178b595@cse.iitm.ac.in Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-07-24pmdomain: Merge branch fixes into nextUlf Hansson1-8/+0
Merge the pmdomain fixes for v7.2-rc[n] into the next branch, to allow them to get tested together with the pmdomain changes that are targeted for the next release. Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-07-24drm/panthor: return PTR_ERR() from devm_drm_dev_alloc()Osama Abdelkader1-1/+1
devm_drm_dev_alloc() returns an ERR_PTR() on failure, but panthor_probe() always converts that failure to -ENOMEM. Preserve the actual error code returned by the DRM core instead. Fixes: 4bdca1150792 ("drm/panthor: Add the driver frontend block") Signed-off-by: Osama Abdelkader <osama.abdelkader@gmail.com> Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://patch.msgid.link/20260716140337.10679-1-osama.abdelkader@gmail.com
2026-07-24pmdomain: imx8m{p,}-blk-ctrl: Add MODULE_DESCRIPTIONUwe Kleine-König2-0/+2
Without a module description modpost emits a build warning: WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/pmdomain/imx/imx8m-blk-ctrl.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/pmdomain/imx/imx8mp-blk-ctrl.o So add the required string to these two drivers. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-07-24drm/panel-edp: take i2c adapter module referenceJohan Hovold1-2/+2
The i2c subsystem currently blocks during adapter deregistration whenever there are consumers holding a reference. Switch to using of_get_i2c_adapter_by_node() which also takes a reference to the adapter module so that an attempt to unload the module while in use fails gracefully instead of blocking uninterruptibly. Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patch.msgid.link/20260717143119.1815106-3-johan@kernel.org
2026-07-24drm/panel-edp: fix i2c adapter leak on probe failureJohan Hovold1-6/+13
Make sure to drop the i2c adapter reference on probe failure (e.g. probe deferral) and on driver unbind also if a devicetree redundantly uses the 'ddc-i2c-bus' property to point to the aux ddc bus. Fixes: cc5a3fc041f0 ("drm/panel: panel-simple: Stash DP AUX bus; allow using it for DDC") Cc: stable@vger.kernel.org # 5.15 Reported-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/CAD=FV=VZPhzHU+Pet2m3L+Pqc7mOPfZC-f5p0OuNL79wNZPxRg@mail.gmail.com Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patch.msgid.link/20260717143119.1815106-2-johan@kernel.org
2026-07-24pmdomains: mediatek: Avoid setting RTFF's CLK_DIS before NRESTOREAngeloGioacchino Del Regno1-8/+0
For the PCIE_PHY (also called PEXTP_PHY) type of RTFF hardware, there is special handling setting CLK_DIS before performing the NRESTORE sequence for resetting the RTFF and start sequencing from a clean state. That special handling, though, poses an issue in case the machine specific bootchain (bootloader in particular) ends up booting the kernel with both PCIe MAC and PHY enabled (not just power domains) as doing so will partially corrupt the PCIe MAC/PHY registers in an unpredictable manner, producing either an initialization fail in the PCI-Express drivers, or even a hard lockup! Resolve this by simply removing the special handling: in this case the bootchain, or remote processors, setting is getting honored by the later check for PWR_RTFF_SAVE_FLAG presence in the RTFF ctl register. Fixes: 9d02c94342b3 ("pmdomain: mediatek: Add support for RTFF Hardware in MT8196/MT6991") Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-07-24pmdomain: mediatek: Add support for MT6858 SoCNikolai Burov3-0/+476
Add support for the power domains found in the MediaTek MT6858 SoC. Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Nikolai Burov <nikolai.burov@jolla.com> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-07-24pmdomain: mediatek: Add support for secure modem power domain controlNikolai Burov2-5/+46
On recent MediaTek SoCs such as MT6858, the kernel is required to use a secure monitor call (SMC) to enable or disable the modem power domain. The power domain control register can be read, but firmware prevents it from being modified directly. Some other parts of the power sequence, such as setting the ext_buck_iso register, still need to be performed on the kernel side. In preparation for modem support, add a flag to enable this new power sequence for SoCs that need it. Power domains using this flag are not expected to configure any bus protection registers, since these are handled internally by the SMC call. Signed-off-by: Nikolai Burov <nikolai.burov@jolla.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-07-24pmdomain: rockchip: Add a regulator to the RK3568 NPU power domainMidgy BALON1-11/+25
The RK3568 NPU rail (vdd_npu) needs to be enabled before the domain is powered on and disabled after it is powered off. Give DOMAIN_RK3568 a regulator parameter (like DOMAIN_RK3588 already has) so the NPU domain can set need_regulator, letting genpd manage the rail wired up as the domain's domain-supply instead of marking it always-on in DT. Suggested-by: Chaoyi Chen <chaoyi.chen@rock-chips.com> Signed-off-by: Midgy BALON <midgy971@gmail.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Ulf Hansson <ulfh@kernel.org>
2026-07-24drm/amd/display: Fix missing DCE check in dm_gpureset_toggle_interrupts()Leo Li1-1/+2
This line was lost when cping from amd-staging-drm-next to drm-fixes. So add it back. Cc: stable@vger.kernel.org Fixes: 8382cd234981 ("drm/amd/display: consolidate DCN vblank/flip handling onto vupdate_no_lock") Reported-by: Lu Yao <yaolu@kylinos.cn> Signed-off-by: Leo Li <sunpeng.li@amd.com> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Link: https://patch.msgid.link/20260723134450.13838-1-sunpeng.li@amd.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
2026-07-24drm/amd/display: Fix flip-done timeouts on mode1 resetLeo Li1-2/+11
The vblank on/off callbacks mixed use of amdgpu_irq_get/put() and amdgpu_dm_crtc_set_vupdate_irq() to enable and disable IRQs. With get/put, base driver will callback into DC to disable IRQs when refcount == 0. With set_vupdate_irq(), DC is called directly to disable IRQs, bypassing base driver's refcount tracking. During gpu reset, base driver can restore IRQs via amdgpu_irq_gpu_reset_resume_helper() > amdgpu_irq_update(). So if get/put() is not used (i.e. refcount == 0), then vupdate_irq will be disabled. This is problematic if DRM requests vblank on before amdgpu_irq_update() is called: drm_vblank_on() > set_vupdate_irq() enables vupdate_irq, but the refcount is still 0. gpu_reset_resume_helper() > irq_update() then immediately disables it, thus leading to flip done timeouts. This is made worse on DCN since VUPDATE_NO_LOCK is the only IRQ enabled. Prior to 8382cd234981, a combination of GRPH_FLIP and VSTARTUP IRQs were used, and they used get/put(). This explains why 8382cd234981 exposed this issue. Fix by using get/put() instead of set_vupdate_irq(). DCE is unchanged, since it relies on unbalanced enable/disable calls based on VRR status, and hence requires direct set_vupdate_irq(). Plus, it also uses GRPH_FLIP and VLINE IRQs, which are properly tracked by get/put(). Cc: stable@vger.kernel.org Fixes: 8382cd234981 ("drm/amd/display: consolidate DCN vblank/flip handling onto vupdate_no_lock") Signed-off-by: Leo Li <sunpeng.li@amd.com> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Link: https://patch.msgid.link/20260723180159.52121-1-sunpeng.li@amd.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
2026-07-24Merge tag 'usb-serial-7.2-rc4' of ↵Greg Kroah-Hartman7-10/+58
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus Johan writes: USB serial fixes for 7.2-rc4 Here are some fixes for 7.2: - fix data loss on keyspan_pda throttle - fix memory corruption with malicious edgeport devices - fix memory corruption with corrupt io_ti firmware - fix OOB read with corrupt mxuport firmware Included are also some new ftdi and modem device ids. All have been in linux-next with no reported issues. * tag 'usb-serial-7.2-rc4' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial: USB: serial: io_edgeport: cap received transmit credits USB: serial: option: add TDTECH MT5710-CN USB: serial: io_ti: reject oversized boot-mode firmware USB: serial: mxuport: validate firmware header size USB: serial: ftdi_sio: add support for E+H FXA291 USB: serial: keyspan_pda: fix data loss on receive throttling
2026-07-24iommu/msm: Unwind probe state on registration failureWeimin Xiong1-2/+8
msm_iommu_probe() adds its devm-managed IOMMU object to qcom_iommu_devices before adding the IOMMU sysfs device and registering it with the IOMMU core. If iommu_device_sysfs_add() fails, probe returns with the object still on qcom_iommu_devices. The driver core then releases the devm allocation, leaving a dangling list entry that later list walks may dereference. If iommu_device_register() fails, the same dangling list entry remains and the sysfs device is left registered as well. Unwind the sysfs device and global list entry in reverse setup order on the corresponding failure paths. Fixes: 42df43b36163 ("iommu/msm: Make use of iommu_device_register interface") Cc: stable@vger.kernel.org Reviewed-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Signed-off-by: Weimin Xiong <xiongwm2026@163.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-07-24iommu/msm: Limit the per-master Machine ID listPengpeng Hou1-0/+3
The OF translation path appends each unique stream ID from an IOMMU specifier to the fixed mids array in the per-master object. It currently has no capacity check before storing at mids[num_mids] and incrementing num_mids. Return -ENOSPC when the array is full rather than writing the next ID beyond it. Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Will Deacon <will@kernel.org>
2026-07-24power: sequencing: pcie-m2: Match WCN6855 and WCN7851 UART BT variants by ↵Wei Deng1-2/+4
subdevice ID The WCN6855 and WCN7851 combo chips are available in M.2 card variants that differ by their BT interface: some expose BT over UART while others expose BT over USB. Both variants use the same PCIe device ID for the WiFi interface, distinguished only by their sub-system device ID. The bare PCI_DEVICE() entries match all sub-system IDs, so both UART and USB variants hit the same table entry and trigger UART serdev creation. For USB variants this is wrong — there is no UART BT interface on such a card, and the serdev probe will fail. Narrow the matches to UART variants only by using PCI_DEVICE_SUB with their respective sub-system IDs, so USB variants no longer trigger UART serdev creation. Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Wei Deng <wei.deng@oss.qualcomm.com> Link: https://patch.msgid.link/20260724-hamoa-m2-sub-id-v2-v3-1-af97de70bbbe@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
2026-07-24platform/x86: hp-wmi: Add GPU MUX switch supportKürşat Abaylı1-0/+133
Add support for querying and switching the graphics MUX mode on HP systems via WMI. This introduces the 'gpu_mux_mode' sysfs attribute under the hp-wmi platform device, allowing userspace tools to check and safely switch between available graphics modes (e.g., UMA, Hybrid, Discrete). The hardware capabilities mask is primarily read using the modern 128-byte System Design Data query. However, to ensure backward compatibility with older models, a fallback mechanism is implemented. By mirroring the behavior of the Windows Omen Gaming Hub software, if the modern query fails but the MUX WMI endpoint (0x52) responds successfully to a read request, the driver defaults to a standard Hybrid + Discrete support mask (0x06). Signed-off-by: Kürşat Abaylı <hello@kursatabayli.dev> Link: https://patch.msgid.link/20260723172734.18361-1-hello@kursatabayli.dev [ij: add kstrtox.h] Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2026-07-24drm/i915/fbc: No surface size restrictions from LNL onwardsVinod Govindapillai1-0/+3
From xe2_lpd+ platforms, enabling FBC do not depend on the surface size. So remove the check. v2: changes to patch description Bspec: 69560 Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patch.msgid.link/20260722132448.318112-3-vinod.govindapillai@intel.com
2026-07-24drm/i915/fbc: No need of any hardcoded plane width limit from LNL+Vinod Govindapillai1-4/+12
In xe2_lpd+ platforms, there are no restrictions to enable FBC on planes with respect to the plane width - width can be as per the platform's maximum supported resolution. v2: patches squashed and changes in patch descriptions Bspec: 69560 Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patch.msgid.link/20260722132448.318112-2-vinod.govindapillai@intel.com
2026-07-24drm/xe/display: Expose plane max width/height helpers to global scopeVinod Govindapillai2-8/+17
Enabling features like FBC on platforms may depend on a plane's maximum supported resolutions or some other arbitrary constant values because of hw restrictions. Currently the helpers that report a plane's max width and height are private to skl_plane / skl_universal_plane. Change the scope to golbal so that this can be queried from other areas as well. v2: function parameter alignment fixes Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patch.msgid.link/20260722132448.318112-1-vinod.govindapillai@intel.com
2026-07-24platform/loongarch: laptop: Explicitly reset bl_powered state when suspendZixing Liu1-0/+1
On EAECIS NL60R with EC firmware version 1.11, resuming from S3 has a very high chance (>90%) of causing the EC to lose the previous backlight power state. When this happens, the laptop resumes normally from S3, but the backlight remains off (when shining on the screen with a flash light, we can see the screen contents are updating normally). Since there is no generic way to query the EC's backlight state on Loongson laptop platforms, assume the worst-case scenario and restart the backlight power inside the kernel each time the system resumes. Cc: stable@vger.kernel.org Fixes: 53c762b47f72 ("platform/loongarch: laptop: Add backlight power control support") Tested-by: Yao Zi <me@ziyao.cc> Tested-by: Xi Ruoyao <xry111@xry111.site> Signed-off-by: Zixing Liu <liushuyu@aosc.io> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2026-07-24platform/loongarch: laptop: Stop setting acpi_device_class()Rafael J. Wysocki1-3/+0
The driver populates acpi_device_class() which is never read afterward, so make it stop doing that and drop the symbol defined specifically for this purpose. No intentional functional impact. This change will facilitate the removal of "device_class" from "struct acpi_device_pnp" in the future. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2026-07-24Merge tag 'drm-misc-fixes-2026-07-24' of ↵Dave Airlie22-142/+348
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes drm-misc-fixes for v7.2-rc5: - Improve damage handling in appletbdrm. - Fix harmful fragmenting of MM by backing up TTM pages at native page order. - Fix timeout handling in amdxdna. - Fix imagination locking for map/unmap operations. - Fix mm leak in gpusvm eviction. - Properly zero page array in gpusvm mm scanning. - Prevent trusted shader bo's from being mapped again in vc4. - Validate shader array size in vmwgfx. - Fix length calculation bugs in ethosu. - Better error handling during pagemap migration. - Improve v3d suspend. - Kconfig updates for some panels. - Handle missing iovcc in ili9881c panel. - Fix vc4 unbind. - Add i2c error handling in gma500. - Fix kunit tests on pp64le and s390x. - Prevent rearming vc4 timer on shutdown. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patch.msgid.link/07284633-6b9b-40f9-8949-b1516a42a34c@linux.intel.com
2026-07-24soc: ixp4xx: Remove redundant dev_err()Pan Chuang1-8/+2
Since commit 55b48e23f5c4 ("genirq/devres: Add error handling in devm_request_*_irq()"), devm_request_irq() automatically logs detailed error messages on failure. Remove the now-redundant driver-specific dev_err() calls. Signed-off-by: Pan Chuang <panchuang@vivo.com> Message-ID: <20260722023523.42269-2-panchuang@vivo.com> Signed-off-by: Linus Walleij <linusw@kernel.org>
2026-07-24soc: ixp4xx: npe: add missing MODULE_DEVICE_TABLE()Pengpeng Hou1-0/+1
The driver has an OF match table wired to .of_match_table, but does not export the table with MODULE_DEVICE_TABLE(). Add the missing MODULE_DEVICE_TABLE(of, ...) entry so module alias information is generated for OF based module autoloading. This is a source-level fix. It does not claim dynamic hardware reproduction; the evidence is the driver-owned match table, its use by the platform driver, and the missing module alias publication. Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn> Message-ID: <20260704122324.80274-1-pengpeng@iscas.ac.cn> Signed-off-by: Linus Walleij <linusw@kernel.org>
2026-07-24soc: ixp4xx: qmgr: add missing MODULE_DEVICE_TABLE()Pengpeng Hou1-0/+1
The driver has an OF match table wired to .of_match_table, but does not export the table with MODULE_DEVICE_TABLE(). Add the missing MODULE_DEVICE_TABLE(of, ...) entry so module alias information is generated for OF based module autoloading. This is a source-level fix. It does not claim dynamic hardware reproduction; the evidence is the driver-owned match table, its use by the platform driver, and the missing module alias publication. Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn> Message-ID: <20260704121851.63805-1-pengpeng@iscas.ac.cn> Signed-off-by: Linus Walleij <linusw@kernel.org>
2026-07-24drm/imagination: Fix value of HWRT address in pvr_job_create tracepointAlessio Belle1-3/+13
The pvr_job_create tracepoint was using pvr_fw_object::fw_addr_offset to display the firmware address of the render target structure attached to a job, but that's an offset into the firmware heap, not the expected full address, which is more useful in general e.g. for cross referencing against firmware logs. Use pvr_fw_object_get_fw_addr() to get the full firmware address. Fixes: c1079aebb4de ("drm/imagination: Add support for trace points") Reviewed-by: Brajesh Gupta <brajesh.gupta@imgtec.com> Link: https://patch.msgid.link/20260720-fix-pvr-job-trace-hwrt-v1-1-b24551802efb@imgtec.com Signed-off-by: Alessio Belle <alessio.belle@imgtec.com>
2026-07-24drm/imagination: promote BXM-4-64 MC1 (36.52.104.182) to supported statusFrank Binns2-3/+2
Support for this GPU is now in a very good state, with only a handful of Vulkan CTS tests still failing when testing using CTS version 1.4.5.3 on the BeagleV-Ahead SBC. With the firmware having been upstreamed [1], now is the time to promote this GPU from experimental to supported. [1] https://gitlab.com/kernel-firmware/linux-firmware/-/merge_requests/1138 Signed-off-by: Frank Binns <frank.binns@imgtec.com> Reviewed-by: Alessio Belle <alessio.belle@imgtec.com> Link: https://patch.msgid.link/20260720-promote-bxm-4-64-v1-2-39abcd1cf263@imgtec.com Signed-off-by: Alessio Belle <alessio.belle@imgtec.com>
2026-07-24drm/imagination: update GPU support documentationFrank Binns1-2/+2
The list of supported GPUs contains the GPU model, along with the SoCs they're found in. The SoC information can easily get out of date, as typically GPU models will be integrated into many different SoCs and upstream support for these can potentially happen over a long stretch of time without necessarily requiring any GPU driver changes. Replace the SoC information with the BVNC instead. This uniquely identifies a GPU implementation and is useful in cases where a GPU model may have multiple implementations due to, e.g. hardware errata having been fixed, and the driver doesn't yet support all of them. Signed-off-by: Frank Binns <frank.binns@imgtec.com> Reviewed-by: Alessio Belle <alessio.belle@imgtec.com> Link: https://patch.msgid.link/20260720-promote-bxm-4-64-v1-1-39abcd1cf263@imgtec.com Signed-off-by: Alessio Belle <alessio.belle@imgtec.com>
2026-07-24drm/tve200: add OF module alias for autoloadingCan Peng1-0/+1
The TVE200 DRM driver can be built as a module and uses tve200_of_match as its OF match table, but the table is not exported for module alias generation. Add the MODULE_DEVICE_TABLE(of, ...) entry so modpost can generate OF module aliases for OF based module autoloading. Fixes: 179c02fe90a4 ("drm/tve200: Add new driver for TVE200") Signed-off-by: Can Peng <pengcan@kylinos.cn> Signed-off-by: Linus Walleij <linusw@kernel.org> Link: https://patch.msgid.link/20260715024130.186416-1-pengcan@kylinos.cn
2026-07-24Revert "drm/pagemap: Guard HPAGE_PMD_ORDER use with ↵Maarten Lankhorst1-10/+3
CONFIG_ARCH_ENABLE_THP_MIGRATION" This reverts commit 04b177544a040cbafab760d6b766381c6b22e0a8. The original author requested it to be reverted, as it conflicts with changes in the -next branch for MM: "I'm not sure who is doing the drm-misc-fixes PR, but if you are can you omit this patch: https://patchwork.freedesktop.org/series/170865/ I guess this conflicts with MM changes in their next tree and it easy enough on our side to do this slightly differently to avoid a conflict so going to post revert + a different change. If this is already sent nbd." Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2026-07-24drm/i915/dp: Ignore the sink's DSC max FRL rate without a PCON DSC encoderAlexander Kaplan1-1/+8
intel_dp_hdmi_sink_max_frl() limits the sink's max FRL rate by its DSC max FRL rate whenever the sink supports DSC 1.2. However, the DSC max FRL rate (HF-VSDB DSC_Max_FRL_Rate) only applies to compressed video transport, which requires a DSC 1.2 encoder in the PCON (configured via intel_dp_pcon_dsc_configure()). Without such an encoder the HDMI link always carries uncompressed video, for which the regular Max_FRL_Rate is the correct limit. Applying the DSC limit unconditionally trains the FRL link at a lower rate than both the PCON and the sink support. E.g. an LG OLED G4 (Max_FRL_Rate 48 Gbps, DSC_Max_FRL_Rate 24 Gbps) behind a Synaptics VMM7100 PCON (PCON max FRL bw 48 Gbps, no DSC encoder): Sink max rate from EDID = 24 Gbps FRL trained with : 24 Gbps while Windows/macOS train the same hardware at 40/48 Gbps. The too low FRL rate needlessly constrains the formats available to the sink. Only apply the sink's DSC max FRL rate if the PCON has a DSC 1.2 encoder, matching the gate in intel_dp_pcon_dsc_configure(). PCONs with a DSC encoder keep the current conservative behavior, since the link is trained once and compressed transport may be used for any subsequent mode. With this the setup above trains at 48 Gbps. Tested on PTL (xe) with the above PCON/sink combo. Fixes: 10fec80b48c5 ("drm/i915/display: Configure PCON for DSC1.1 to DSC1.2 encoding") Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Alexander Kaplan <alexander.kaplan@sms-medipool.de> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patch.msgid.link/20260718105207.5565-3-alexander.kaplan@sms-medipool.de
2026-07-24drm/i915/dp: Prefer DSC over 6 bpc uncompressed output for HDMI sinksAlexander Kaplan1-0/+14
For modes which fit through the link uncompressed only with a 6 bpc pipe BPP, the link config currently selects 6 bpc with dithering even if the sink supports DSC. For HDMI sinks behind a DP to HDMI protocol converter this is the wrong preference: HDMI knows no 6 bpc transport format, so the converter has to expand the dithered 6 bpc stream back to 8 bpc for the HDMI link anyway, and DSC with an at least 8 bpc input provides a better output quality than that. Prefer DSC, following the pattern commit ba49a4643cf5 ("drm/i915/dp: Set min_bpp limit to 30 in HDR mode") uses for HDR: keep the uncompressed minimum pipe BPP at 8 bpc if the sink supports DSC, making the uncompressed link config fail for such modes and the mode fall back to DSC. As there, if the DSC computation fails, the mode falls back to YCbCr 4:2:0 where supported, or gets rejected. Besides the output quality, some converters can't even display a 6 bpc stream at high pixel clocks. Synaptics VMM PCON based DP to HDMI 2.1 adapters from two device families (branch device IDs SYNAq and SYNAa) output corrupted FRL timings for an uncompressed RGB 6 bpc 4k120 (1188 MHz) stream, resulting in a black screen, while the same mode works with DSC (12 bpc input) and 6 bpc works at lower pixel clocks. Windows and macOS drive 4k120 on these devices only via DSC. A lower bpc limit explicitly requested via the max bpc connector property is still honored. This keeps the current uAPI behavior (exercised by IGT kms_dither) and provides an escape hatch for sinks with a broken DSC implementation. DP and eDP sinks, and HDMI sinks without DSC support, are not affected and keep falling back to 6 bpc. Tested on PTL (xe) with the above PCONs and an LG OLED G4. Cc: Imre Deak <imre.deak@intel.com> Cc: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Alexander Kaplan <alexander.kaplan@sms-medipool.de> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patch.msgid.link/20260718105207.5565-2-alexander.kaplan@sms-medipool.de
2026-07-24wifi: rtw88: disable ASPM and deep PS on ASUS TUF Gaming A15 FA506IIMihail Dimoski1-0/+10
The RTL8822CE on the ASUS TUF Gaming A15 FA506II wedges during normal use. The driver watchdog toggles PCIe ASPM while leaving power save; the DBI read of the ASPM link-config register fails with -EIO, the PCIe link becomes unstable, and the device drops off the bus, taking Wi-Fi down until a cold power cycle: rtw88_8822ce 0000:03:00.0: failed to read ASPM, ret=-5 rtw88_8822ce 0000:03:00.0: firmware failed to leave lps state rtw88_8822ce 0000:03:00.0: mac power on failed This is the same platform ASPM inter-operability problem already handled for other machines through rtw_pci_quirks[]. Disabling PCI ASPM and deep power save on this model stops the failure. Add a DMI quirk so the workaround is applied automatically. Signed-off-by: Mihail Dimoski <mihaildimoski@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260718124045.23493-1-mihaildimoski@gmail.com
2026-07-24wifi: rtw89: coex: Add firmware 0.27.97.X support for RTL8852CChing-Te Ku1-0/+9
Newer firmware is using the new TLV-Header format, without this patch it will lead driver run into length mismatch state. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260717065739.64124-14-pkshih@realtek.com
2026-07-24wifi: rtw89: coex: Add wifi role info version 101Ching-Te Ku3-5/+125
The structure active_role which describes the using Wi-Fi role format is different with the exist v1. Add branch to cover the difference. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260717065739.64124-13-pkshih@realtek.com
2026-07-24wifi: rtw89: coex: Add cycle status report version 105Ching-Te Ku2-0/+218
The exists version 5 format has FDDT(frequency divided training) related information. But the feature wasn't support for RTL8852C now, so firmware will not send the related reference value. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260717065739.64124-12-pkshih@realtek.com
2026-07-24wifi: rtw89: coex: Add slots version 2Ching-Te Ku3-20/+51
Slots structure version 2 uses new TLV-Header to package slots information, patch related entry for version 2. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260717065739.64124-11-pkshih@realtek.com
2026-07-24wifi: rtw89: coex: Add TDMA version 4Ching-Te Ku1-3/+5
TDMA version 4 uses new TLV-Header to package TDMA information, patch related entry for version 4. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260717065739.64124-10-pkshih@realtek.com
2026-07-24wifi: rtw89: coex: Add firmware 0.29.133.X support for RTL8852B familyChing-Te Ku1-0/+27
The new firmware modified GPIO setup structure format for third party chip set I/O control & offloaded Wi-Fi TRX status to firmware for training traffic RF-Parameters & TDMA mechanism. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260717065739.64124-9-pkshih@realtek.com
2026-07-24wifi: rtw89: coex: Fix Wi-Fi role info H2C command header issueChing-Te Ku1-2/+6
The function to filled up H2C command data is the last step in the driver, the next step is going to firmware. So the structure version number should not included driver local branch number (like firmware is v5, but driver branch to v105), it should be assigned as a explicit version number which paired with firmware. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260717065739.64124-8-pkshih@realtek.com
2026-07-24wifi: rtw89: coex: Add driver info H2C command index version 103Ching-Te Ku1-6/+7
The 0.29.133.X firmware driver info H2C index maximum is 5, to prevent switch case fall through and send unexpected H2C commands, add version code 103 as judgment. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260717065739.64124-7-pkshih@realtek.com
2026-07-24wifi: rtw89: coex: Refine chip initial related structureChing-Te Ku11-474/+411
Due to the firmware version become more and more, the version divided branch coding method make the related code scattered everywhere, and too much version macro, rearrange the code, assign the value to version format only when H2C commands. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260717065739.64124-6-pkshih@realtek.com
2026-07-24wifi: rtw89: coex: Branch out version 105 firmware report map indexChing-Te Ku1-0/+11
RTL8852B in firmware 0.29.133.X do not support BT-TX-PWR report, re-index and branch out to version 105. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260717065739.64124-5-pkshih@realtek.com
2026-07-24wifi: rtw89: coex: Fix unexpected grant-signal assigneeChing-Te Ku1-12/+12
The C2H report is for knowing what the grant-signal setting is now, not for applying new grant-signal setting. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260717065739.64124-4-pkshih@realtek.com
2026-07-24wifi: rtw89: coex: Add version 9 report control infoChing-Te Ku2-6/+178
WiFi firmware will save its build date/time and package into C2H event then send to driver. It helps to analyze what kind of firmware was loaded now. Remove unnecessary memory set. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260717065739.64124-3-pkshih@realtek.com
2026-07-24wifi: rtw89: coex: Add version 107 TX/RX info for firmware featureChing-Te Ku3-37/+126
The previous version 7 format is for Dual-Bluetooth using. This patch is for single Bluetooth solution using. Driver will summary Wi-Fi now status for firmware to train RF parameters & TDMA mechanism. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260717065739.64124-2-pkshih@realtek.com
2026-07-24wifi: rtw89: phy: set CFR to manual mode for some 2GHz channelsPing-Ke Shih1-1/+7
The CFR (Channel Frequency Response) manual mode condition for 2GHz is missing to limit on bandwidth for specific channels, which are channel 13 with 20MHz bandwidth and channel 11 with 40MHz bandwidth. Also add a band check to avoid affecting 5GHz/6GHz bands. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260717061910.54466-10-pkshih@realtek.com
2026-07-24wifi: rtw89: 8922d: reduce IO in power-on functionPing-Ke Shih1-9/+9
To improve initial time, merge some IO to reduce IO times. Two registers are: 1. R_BE_SYS_PW_CTRL: 0x4[12:11]=0, 0x4[18]=1, 0x4[15]=0, and 0x4[10]=0 2. R_BE_SYS_ADIE_PAD_PWR_CTRL: Merge 0x18[6] and 0x18[5] Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/20260717061910.54466-9-pkshih@realtek.com
generated by cgit (git 2.54.0.dirty) at 2026-09-30 01:38:50 +0000