summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2026-03-25drm/ci: uprev mesaVignesh Raman35-355/+387
Uprev mesa to adapt to the latest changes in Mesa CI, such as: - LAVA overlay-based firmware handling - Container/job rule separation - Removal of the python-artifacts job - Use lava-job-submitter container to submit jobs - Use of the Alpine container for LAVA jobs - Various other CI improvements - Remove bare-metal jobs and disable apq8016 and apq8096 jobs, as these have been migrated to the Collabora LAVA farm - Fix issues with rebase with external fixes branch - Update expectation files Signed-off-by: Vignesh Raman <vignesh.raman@collabora.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Co-developed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-03-25drm/ci: i915: cml: update runner tagVignesh Raman1-4/+4
asus-C436FA-Flip-hatch has fewer devices available in the LAVA lab and drm-ci uses only 2 DUTs, causing tests to time out. Update drm-ci to use puff instead of hatch so the tests can run on 5 DUTs. Also increase parallel count for amly jobs to 3. Signed-off-by: Vignesh Raman <vignesh.raman@collabora.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-03-25drm/ci: reduce sm8350-hdk parallel jobs from 4 to 2Vignesh Raman1-1/+1
The sm8350-hdk jobs are short and each test takes around 2–3 minutes and the full job completes in about 10 minutes. Running 4 parallel jobs uses 4 devices at once, which is not needed. Set parallel to 2 to reduce device usage. Signed-off-by: Vignesh Raman <vignesh.raman@collabora.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-03-25media: imx8mq-mipi-csi2: Add support for i.MX8ULPGuoniu Zhou1-0/+1
The CSI-2 receiver in i.MX8ULP is almost same as i.MX8QXP/QM except clocks and resets, so add compatible string for i.MX8ULP to handle the difference and reuse platform data of i.MX8QXP/QM. Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Guoniu Zhou <guoniu.zhou@nxp.com> Link: https://patch.msgid.link/20251205-csi2_imx8ulp-v10-4-190cdadb20a3@nxp.com Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-03-25media: imx8mq-mipi-csi2: Explicitly release resetGuoniu Zhou1-6/+2
Call reset_control_deassert() to explicitly release reset to make sure reset bits are cleared since platform like i.MX8ULP can't clear reset bits automatically. Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Guoniu Zhou <guoniu.zhou@nxp.com> Link: https://patch.msgid.link/20251205-csi2_imx8ulp-v10-3-190cdadb20a3@nxp.com Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-03-25media: imx8mq-mipi-csi2: Use devm_clk_bulk_get_all() to fetch clocksGuoniu Zhou1-35/+21
Use devm_clk_bulk_get_all() helper to simplify clock handle code. No functional changes intended. Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Guoniu Zhou <guoniu.zhou@nxp.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://patch.msgid.link/20251205-csi2_imx8ulp-v10-2-190cdadb20a3@nxp.com Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-03-25media: nxp: imx8-isi: Add ISI support for i.MX95Guoniu Zhou2-0/+13
The ISI module on i.MX95 supports up to eight channels and four link sources to obtain the image data for processing in its pipelines. It can process up to eight image sources at the same time. Add ISI basic functions support for i.MX95. Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Guoniu Zhou <guoniu.zhou@nxp.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://patch.msgid.link/20251105-isi_imx95-v3-3-3987533cca1c@nxp.com Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-03-25media: nxp: imx8-isi: Keep the default value for BLANK_PXL fieldGuoniu Zhou1-4/+2
The field BLANK_PXL provides the value of the blank pixel to be inserted in the image in case an overflow error occurs in the output buffers of the channel. Its default value is 0xff, so no need to set again. Besides, the field only exist in i.MX8QM/XP ISI version. Other versions like i.MX 8M series, remove the field since it won't send data to AXI bus when overflow error occurs and mark BLANK_PXL as reserved. i.MX9 series use it for other purposes. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Guoniu Zhou <guoniu.zhou@nxp.com> Link: https://patch.msgid.link/20251105-isi_imx95-v3-2-3987533cca1c@nxp.com Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-03-25media: nxp: imx8-isi: Reduce minimum queued buffers from 2 to 0Guoniu Zhou1-1/+1
Fix a hang issue when capturing a single frame with applications like cam in libcamera. It would hang waiting for the driver to complete the buffer, but streaming never starts because min_queued_buffers was set to 2. The ISI module uses a ping-pong buffer mechanism that requires two buffers to be programmed at all times. However, when fewer than 2 user buffers are available, the driver use internal discard buffers to fill the remaining slot(s). Reduce minimum queued buffers from 2 to 0 allows streaming to start without any queued buffers. Fixes: cf21f328fcaf ("media: nxp: Add i.MX8 ISI driver") Cc: stable@vger.kernel.org Signed-off-by: Guoniu Zhou <guoniu.zhou@nxp.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://patch.msgid.link/20260312-isi_min_buffers-v2-1-d5ea1c79ad81@nxp.com Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-03-25media: dw100: Merge dw100_device_run and dw100_startStefan Klug1-37/+30
The dw100_start() function is only called from dw100_device_run(). As both functions are not too big, move the code directly into dw100_device_run() and drop dw100_start() to improve readability. This patch contains no functional changes. Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com> Reviewed-by: Xavier Roumegue <xavier.roumegue@oss.nxp.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://patch.msgid.link/20260304-sklug-v6-16-topic-dw100-v3-1-dev-v5-4-1a7e1f721b50@ideasonboard.com Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-03-25media: dw100: Fix kernel oops with PREEMPT_RT enabledStefan Klug1-5/+16
On kernels with PREEMPT_RT enabled, a "BUG: scheduling while atomic" kernel oops occurs inside dw100_irq_handler -> vb2_buffer_done. This is because vb2_buffer_done takes a spinlock which is not allowed within interrupt context on PREEMPT_RT. The first attempt to fix this was to just drop the IRQF_ONESHOT so that the interrupt is handled threaded on PREEMPT_RT systems. This introduced a new issue. The dw100 has an internal timeout counter that is gated by the DW100_BUS_CTRL_AXI_MASTER_ENABLE bit. Depending on the time it takes for the threaded handler to run and the geometry of the data being processed it is possible to reach the timeout resulting in DW100_INTERRUPT_STATUS_INT_ERR_TIME_OUT being set and "dw100 32e30000.dwe: Interrupt error: 0x1" errors in dmesg. To properly fix that, split the interrupt into two halves, reset the DW100_BUS_CTRL_AXI_MASTER_ENABLE bit in the hard interrupt handler and do the v4l2 buffer handling in the threaded half. The IRQF_ONESHOT can still be dropped as the interrupt gets disabled in the hard handler and will only be reenabled on the next dw100_device_run which will not be called before the current job has finished. Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com> Reviewed-by: Xavier Roumegue <xavier.roumegue@oss.nxp.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://patch.msgid.link/20260304-sklug-v6-16-topic-dw100-v3-1-dev-v5-3-1a7e1f721b50@ideasonboard.com Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-03-25media: dw100: Implement dynamic vertex map updateStefan Klug1-6/+17
Implement dynamic vertex map updates by handling the V4L2_CID_DW100_DEWARPING_16x16_VERTEX_MAP control during streaming. This allows to implement features like dynamic zoom, pan, rotate and dewarp. To stay compatible with the old version, updates of V4L2_CID_DW100_DEWARPING_16x16_VERTEX_MAP are ignored during streaming when requests are not used. Print a corresponding warning once. Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://patch.msgid.link/20260304-sklug-v6-16-topic-dw100-v3-1-dev-v5-2-1a7e1f721b50@ideasonboard.com Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-03-25media: dw100: Implement V4L2 requests supportStefan Klug1-13/+42
The dw100 dewarper hardware present on the NXP i.MX8MP allows very flexible dewarping using a freely configurable vertex map. Aside from lens dewarping the vertex map can be used to implement things like arbitrary zoom, pan and rotation. The current driver supports setting that vertex map before calling VIDIOC_STREAMON. To control above mentioned features during streaming it is necessary to update the vertex map dynamically. To do that in a race free manner V4L2 requests support is required. Add V4L2 requests support to prepare for dynamic vertex map updates. Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://patch.msgid.link/20260304-sklug-v6-16-topic-dw100-v3-1-dev-v5-1-1a7e1f721b50@ideasonboard.com Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-03-25media: nxp: Add dev_err_probe() to all error paths in *async_register() helpersFrank Li2-23/+35
Add dev_err_probe() to all error branches in the *async_register() helpers to provide clearer diagnostic information when device registration fails. Drop the explicit error message after returning from mipi_csis_async_register(), as the error is already reported by this helper. Signed-off-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://patch.msgid.link/20260121-cam_cleanup-v5-1-01d1ab38db9d@nxp.com Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-03-25media: rkisp1: Fix enum_framesizes accepting invalid pixel formatsTarang Raval1-0/+3
Reject unsupported pixel formats in rkisp1_enum_framesizes() to fix v4l2-compliance failure. v4l2-compliance test failure: fail: ../utils/v4l2-compliance/v4l2-test-formats.cpp(403): Accepted framesize for invalid format test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: FAIL Tested on: Debix i.MX8MP Model A Kernel version: v6.17-rc3 v4l2-compliance: 1.31.0-5387 Signed-off-by: Tarang Raval <tarang.raval@siliconsignals.io> Tested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Link: https://patch.msgid.link/20250829101425.95442-1-tarang.raval@siliconsignals.io Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
2026-03-24Merge tag 'v7.0-rc5' into nextDmitry Torokhov361-2136/+3663
Sync up with mainline to pull in a fix for smb compilation error.
2026-03-24s390/zcrypt: Slight rework on the agent_id fieldHarald Freudenberger2-5/+4
The agent_id field is a two byte ascii field addressing the target agent on the crypto card. Some code however addresses this field as unsigned short. Rework these places to treat this field always as a two byte array. Unfortunately this field also shows up as __u16 in struct ica_xcRB as part of the zcrypt ioctl interface. Leave this untouched as it would break the API. There are two other places (func_id) where a byte array gets assigned with hex values but in fact these are ascii value. So replace these assignments with real ascii values for more readability. Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Acked-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2026-03-24s390/zcrypt: Explicitly use a card variable in _zcrypt_send_cprbHarald Freudenberger1-4/+4
Use an explicit variable "card" for the card addressing in function _zcrypt_send_cprb instead of the confusing field "user_defined" from the ica_xcRB struct. This makes the code somewhat cleaner and easier to understand. Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Acked-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2026-03-24s390/zcrypt: Rework MKVP fields and handlingHarald Freudenberger4-85/+123
In general all MKVPs (Master Key Verification Pattern) are binary data - usually some kind of shortened hash value e.g. sha256. Some code parts however used some u64 type which made compares a little bit easier. Anyway this is binary data and so all fields related to MKVP are now u8[] and function parameters use (const) u8 * now. The sysfs emit for the MKVPs also has been adapted to first format the MKVP as hex string into a buffer and then use %s with sysfs_emit_at() to generate the sysfs output. The patch also include a simple whitespace fix. Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Acked-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2026-03-24s390/zcrypt: Make apfs a real unsigned int fieldHarald Freudenberger3-21/+13
Slight rework on the apfs field: Instead of unsigned char[4] make this a real 32 bit unsigned int field. With that done, some assignments and some printouts can be simplified. With that comes a slight move of the anonymous struct covering the message type 86 header to dedupe some code lines. Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Acked-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2026-03-24s390/zcrypt: Rework domain processing within zcrypt device driverHarald Freudenberger3-31/+29
Slight rework of the domain handling within the zcrypt dd: Remove this curious construct to give a pointer to the domain field within the CPRB struct to the zcrypt API and later fill in the target domain via this pointer. Now the domain is filled in with the send function when the ready constructed AP message is about to be pushed down into the software queue for AP queue processing. So now the domain handling for CCA, EP11 and (internal) rng CPRBs is the same. With this comes a slight reshuffle of the code related to domain processing in the zcrypt API and the message type 60 protocol implementation code. Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Acked-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2026-03-24s390/zcrypt: Move inline function rng_type6cprb_msgx from header to codeHarald Freudenberger2-49/+49
Function rng_type6cprb_msgx() is only used once and thus no need to provide it in header file any more. Move it at the place within the code where it is used. Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Reviewed-by: Anthony Krowiak <akrowiak@linux.ibm.com> Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Acked-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2026-03-24s390/zcrypt: Fix memory leak with CCA cards used as acceleratorHarald Freudenberger1-18/+14
Tests showed that there is a memory leak if CCA cards are used as accelerator for clear key RSA requests (ME and CRT). With the last rework for the memory allocation the AP messages are allocated by ap_init_apmsg() but for some reason on two places (ME and CRT) the older allocation was still in place. So the first allocation simple was never freed. Fixes: 57db62a130ce ("s390/ap/zcrypt: Rework AP message buffer allocation") Reported-by: Yi Zhang <yi.zhang@redhat.com> Closes: https://lore.kernel.org/linux-s390/CAHj4cs9H67Uz0iVaRQv447p7JFPRPy3TKAT4=Y6_e=wSHCZM5w@mail.gmail.com/ Reported-by: Nadja Hariz <Nadia.Hariz@ibm.com> Cc: stable@vger.kernel.org Reviewed-by: Ingo Franzki <ifranzki@linux.ibm.com> Reviewed-by: Holger Dengler <dengler@linux.ibm.com> Acked-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Harald Freudenberger <freude@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2026-03-24spi: pxa2xx: update outdated reference to pump_transfers()Kexin Sun1-3/+3
The function pump_transfers() was split into pxa2xx_spi_transfer_one(), pxa2xx_spi_handle_err() and pxa2xx_spi_set_cs() in commit d5898e19c0d7 ("spi: pxa2xx: Use core message processing loop"). The comment in pxa2xx_spi_dma_transfer_complete() still warns about concurrent calls to pump_transfers(), but the actual operation protected by dma_running is now spi_finalize_current_transfer(). Update the reference. Assisted-by: unnamed:deepseek-v3.2 coccinelle Signed-off-by: Kexin Sun <kexinsun@smail.nju.edu.cn> Link: https://patch.msgid.link/20260321105945.8224-1-kexinsun@smail.nju.edu.cn Signed-off-by: Mark Brown <broonie@kernel.org>
2026-03-24Merge tag 'cxl-fixes-7.0-rc6' of ↵Linus Torvalds6-21/+21
git://git.kernel.org/pub/scm/linux/kernel/git/cxl/cxl Pull Compute Express Link (CXL) fixes from Dave Jiang: - Adjust the startup priority of cxl_pmem to be higher than that of cxl_acpi - Use proper endpoint validity check upon sanitize - Avoid incorrect DVSEC fallback when HDM decoders are enabled - Fix CXL_ACPI and CXL_PMEM Kconfig tristate mismatch - Fix leakage in __construct_region() - Fix use after free of parent_port in cxl_detach_ep() * tag 'cxl-fixes-7.0-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/cxl/cxl: cxl: Adjust the startup priority of cxl_pmem to be higher than that of cxl_acpi cxl/mbox: Use proper endpoint validity check upon sanitize cxl/hdm: Avoid incorrect DVSEC fallback when HDM decoders are enabled cxl/acpi: Fix CXL_ACPI and CXL_PMEM Kconfig tristate mismatch cxl/region: Fix leakage in __construct_region() cxl/port: Fix use after free of parent_port in cxl_detach_ep()
2026-03-24regulator: da91xx: Allow caching of buck registers when no GPIO input ↵Mark Brown1-7/+36
control is configured André Svensson <andre.svensson@axis.com> says: This series introduces a boolean DT property, dlg,no-gpio-control, for the DA91xx regulators. Use this property to indicate that GPIO control is not configured with the functions DVC/RELOAD/EN, allowing buck registers to be cached. The DA9121 driver checks dlg,no-gpio-control and updates regmap_config's volatile_table if the property is present. Buck registers are removed from the volatile_table if the property is present, enabling caching of the registers, which removes I2C reads when performing an I2C write to the buck registers. Link: https://patch.msgid.link/20260320-no-gpio-control-v2-0-dbc938e462cb@axis.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-03-24regulator: da9121: Allow caching BUCK registersAndré Svensson1-7/+36
Some BUCK registers may change without software writes when GPIO pins are configured for functions DVC/RELOAD/EN. If the board does not use these pin-controlled features, caching is possible. Caching BUCK registers removes unnecessary I2C reads when performing register updates. For example, updating regulator mode can result in two I2C reads, one from the regulator core regulator_set_mode() and one from the DA9121 driver, where da9121_buck_set_mode() uses regmap_update_bits() (read/modify/write). Check for the optional DT property dlg,no-gpio-control. When present, select the regmap configuration that does not mark the BUCK1 register block (DA9121_REG_BUCK_BUCK1_0..DA9121_REG_BUCK_BUCK1_6) as volatile, so that regmap can cache BUCK1 registers and avoid unnecessary I2C reads. The property dlg,no-gpio-control is required to ensure that BUCK1 registers can be cached, as the absence of relevant GPIO DT properties does not imply that the RELOAD/DVC/EN GPIO functions are unused. These functions are provided by DA91xx GPIO pins and may be controlled by external hardware without corresponding GPIO DT properties. The dlg,no-gpio-control property explicitly indicates that none of these GPIO functions are used. The dlg,no-gpio-control property is mutually exclusive with enable-gpios, regardless of whether the referenced GPIO is connected to a GPIO pin or the IC_EN pin, since pulling IC_EN low powers down the regulator and registers are reinitialized at startup, leaving cached values stale. Co-developed-by: Waqar Hameed <waqar.hameed@axis.com> Signed-off-by: Waqar Hameed <waqar.hameed@axis.com> Signed-off-by: André Svensson <andre.svensson@axis.com> Link: https://patch.msgid.link/20260320-no-gpio-control-v2-2-dbc938e462cb@axis.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-03-24thermal: intel: int340x: soc_slider: Set offset only for balanced modeSrinivas Pandruvada1-1/+7
The slider offset can be set via debugfs for balanced mode. The offset should be only applicable in balanced mode. For other modes, it should be 0 when writing to MMIO offset, Fixes: 8306bcaba06d ("thermal: intel: int340x: Add module parameter to change slider offset") Tested-by: Erin Park <erin.park@intel.com> Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Cc: 6.18+ <stable@vger.kernel.org> # 6.18+ [ rjw: Subject and changelog tweaks ] Link: https://patch.msgid.link/20260324172346.3317145-1-srinivas.pandruvada@linux.intel.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-03-24drm/amd/display: Fix DCE LVDS handlingAlex Deucher6-22/+19
LVDS does not use an HPD pin so it may be invalid. Handle this case correctly in link encoder creation. Fixes: 7c8fb3b8e9ba ("drm/amd/display: Add hpd_source index check for DCE60/80/100/110/112/120 link encoders") Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/5012 Cc: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Cc: Roman Li <roman.li@amd.com> Reviewed-by: Roman Li <roman.li@amd.com> Reviewed-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 3b5620f7ee688177fcf65cf61588c5435bce1872) Cc: stable@vger.kernel.org
2026-03-24drm/amdgpu: Handle GPU page faults correctly on non-4K page systemsDonet Tom1-3/+3
During a GPU page fault, the driver restores the SVM range and then maps it into the GPU page tables. The current implementation passes a GPU-page-size (4K-based) PFN to svm_range_restore_pages() to restore the range. SVM ranges are tracked using system-page-size PFNs. On systems where the system page size is larger than 4K, using GPU-page-size PFNs to restore the range causes two problems: Range lookup fails: Because the restore function receives PFNs in GPU (4K) units, the SVM range lookup does not find the existing range. This will result in a duplicate SVM range being created. VMA lookup failure: The restore function also tries to locate the VMA for the faulting address. It converts the GPU-page-size PFN into an address using the system page size, which results in an incorrect address on non-4K page-size systems. As a result, the VMA lookup fails with the message: "address 0xxxx VMA is removed". This patch passes the system-page-size PFN to svm_range_restore_pages() so that the SVM range is restored correctly on non-4K page systems. Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Donet Tom <donettom@linux.ibm.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 074fe395fb13247b057f60004c7ebcca9f38ef46)
2026-03-24drm/amd/pm: disable OD_FAN_CURVE if temp or pwm range invalid for smu v14Yang Wang1-1/+32
Forcibly disable the OD_FAN_CURVE feature when temperature or PWM range is invalid, otherwise PMFW will reject this configuration on smu v14.0.2/14.0.3. example: $ sudo cat /sys/bus/pci/devices/<BDF>/gpu_od/fan_ctrl/fan_curve OD_FAN_CURVE: 0: 0C 0% 1: 0C 0% 2: 0C 0% 3: 0C 0% 4: 0C 0% OD_RANGE: FAN_CURVE(hotspot temp): 0C 0C FAN_CURVE(fan speed): 0% 0% $ echo "0 50 40" | sudo tee fan_curve kernel log: [ 969.761627] amdgpu 0000:03:00.0: amdgpu: Fan curve temp setting(50) must be within [0, 0]! [ 1010.897800] amdgpu 0000:03:00.0: amdgpu: Fan curve temp setting(50) must be within [0, 0]! Signed-off-by: Yang Wang <kevinyang.wang@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit ab4905d466b60f170d85e19ca2a5d2b159aeb780) Cc: stable@vger.kernel.org
2026-03-24drm/amdkfd: Fix NULL pointer check order in kfd_ioctl_create_processSrinivasan Shanmugam1-3/+3
In kfd_ioctl_create_process(), the pointer 'p' is used before checking if it is NULL. The code accesses p->context_id before validating 'p'. This can lead to a possible NULL pointer dereference. Move the NULL check before using 'p' so that the pointer is validated before access. Fixes the below: drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_chardev.c:3177 kfd_ioctl_create_process() warn: variable dereferenced before check 'p' (see line 3174) Fixes: cc6b66d661fd ("amdkfd: introduce new ioctl AMDKFD_IOC_CREATE_PROCESS") Cc: Zhu Lingshan <lingshan.zhu@amd.com> Cc: Felix Kuehling <felix.kuehling@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 19d4149b22f57094bfc4b86b742381b3ca394ead)
2026-03-24drm/amd/display: check if ext_caps is valid in BL setupAlex Deucher1-1/+1
LVDS connectors don't have extended backlight caps so check if the pointer is valid before accessing it. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/5012 Fixes: 1454642960b0 ("drm/amd: Re-introduce property to control adaptive backlight modulation") Cc: Mario Limonciello <mario.limonciello@amd.com> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 3f797396d7f4eb9bb6eded184bbc6f033628a6f6) Cc: stable@vger.kernel.org
2026-03-24drm/amdgpu: Fix fence put before wait in amdgpu_amdkfd_submit_ibSrinivasan Shanmugam1-2/+2
amdgpu_amdkfd_submit_ib() submits a GPU job and gets a fence from amdgpu_ib_schedule(). This fence is used to wait for job completion. Currently, the code drops the fence reference using dma_fence_put() before calling dma_fence_wait(). If dma_fence_put() releases the last reference, the fence may be freed before dma_fence_wait() is called. This can lead to a use-after-free. Fix this by waiting on the fence first and releasing the reference only after dma_fence_wait() completes. Fixes the below: drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c:697 amdgpu_amdkfd_submit_ib() warn: passing freed memory 'f' (line 696) Fixes: 9ae55f030dc5 ("drm/amdgpu: Follow up change to previous drm scheduler change.") Cc: Felix Kuehling <Felix.Kuehling@amd.com> Cc: Dan Carpenter <dan.carpenter@linaro.org> Cc: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 8b9e5259adc385b61a6590a13b82ae0ac2bd3482)
2026-03-24ACPI: EC: clean up handlers on probe failure in acpi_ec_setup()Weiming Shi1-0/+2
When ec_install_handlers() returns -EPROBE_DEFER on reduced-hardware platforms, it has already started the EC and installed the address space handler with the struct acpi_ec pointer as handler context. However, acpi_ec_setup() propagates the error without any cleanup. The caller acpi_ec_add() then frees the struct acpi_ec for non-boot instances, leaving a dangling handler context in ACPICA. Any subsequent AML evaluation that accesses an EC OpRegion field dispatches into acpi_ec_space_handler() with the freed pointer, causing a use-after-free: BUG: KASAN: slab-use-after-free in mutex_lock (kernel/locking/mutex.c:289) Write of size 8 at addr ffff88800721de38 by task init/1 Call Trace: <TASK> mutex_lock (kernel/locking/mutex.c:289) acpi_ec_space_handler (drivers/acpi/ec.c:1362) acpi_ev_address_space_dispatch (drivers/acpi/acpica/evregion.c:293) acpi_ex_access_region (drivers/acpi/acpica/exfldio.c:246) acpi_ex_field_datum_io (drivers/acpi/acpica/exfldio.c:509) acpi_ex_extract_from_field (drivers/acpi/acpica/exfldio.c:700) acpi_ex_read_data_from_field (drivers/acpi/acpica/exfield.c:327) acpi_ex_resolve_node_to_value (drivers/acpi/acpica/exresolv.c:392) </TASK> Allocated by task 1: acpi_ec_alloc (drivers/acpi/ec.c:1424) acpi_ec_add (drivers/acpi/ec.c:1692) Freed by task 1: kfree (mm/slub.c:6876) acpi_ec_add (drivers/acpi/ec.c:1751) The bug triggers on reduced-hardware EC platforms (ec->gpe < 0) when the GPIO IRQ provider defers probing. Once the stale handler exists, any unprivileged sysfs read that causes AML to touch an EC OpRegion (battery, thermal, backlight) exercises the dangling pointer. Fix this by calling ec_remove_handlers() in the error path of acpi_ec_setup() before clearing first_ec. ec_remove_handlers() checks each EC_FLAGS_* bit before acting, so it is safe to call regardless of how far ec_install_handlers() progressed: -ENODEV (handler not installed): only calls acpi_ec_stop() -EPROBE_DEFER (handler installed): removes handler, stops EC Fixes: 03e9a0e05739 ("ACPI: EC: Consolidate event handler installation code") Reported-by: Xiang Mei <xmei5@asu.edu> Signed-off-by: Weiming Shi <bestswngs@gmail.com> Link: https://patch.msgid.link/20260324165458.1337233-2-bestswngs@gmail.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-03-24drm/amd/display: add a no_hpd link_encoder_funcs variantAlex Deucher1-2/+62
For link encoders without HPD (analog or LVDS), add a link_encoder_funcs structure with no hpd enable callbacks. The enable and disable hpd callbacks are currently not used outside of a special case in debugfs which checks if the hpd is valid before using it, but this will protect us if they ever are. Reviewed-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-24drm/amdgpu/userq: schedule_delayed_work should be after fence signalledSunil Khatri3-6/+7
Reorganise the amdgpu_eviction_fence_suspend_worker code so schedule_delayed_work is the last thing we do after amdgpu_userq_evict is complete and the eviction fence is signalled. Suggested-by: Christian König <christian.koenig@amd.com> Signed-off-by: Sunil Khatri <sunil.khatri@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-24drm/amdgpu/mes12_1: emove extra ; from declaration statementColin Ian King1-1/+1
There is a declaration statement that has a ;; at the end, remove the extraneous ; Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-24drm/amd/display: Fix DCE LVDS handlingAlex Deucher6-22/+19
LVDS does not use an HPD pin so it may be invalid. Handle this case correctly in link encoder creation. Fixes: 7c8fb3b8e9ba ("drm/amd/display: Add hpd_source index check for DCE60/80/100/110/112/120 link encoders") Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/5012 Cc: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Cc: Roman Li <roman.li@amd.com> Reviewed-by: Roman Li <roman.li@amd.com> Reviewed-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-24drm/amdgpu: update outdated comment for renamed amdgpu_fence_driver_init()Kexin Sun1-1/+1
The function amdgpu_fence_driver_init() was renamed to amdgpu_fence_driver_sw_init() by commit 067f44c8b459 ("drm/amdgpu: avoid over-handle of fence driver fini in s3 test (v2)"). Update the stale reference in the amdgpu_fence_driver_init_ring() kdoc. Assisted-by: unnamed:deepseek-v3.2 coccinelle Signed-off-by: Kexin Sun <kexinsun@smail.nju.edu.cn> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-24drm/amdgpu/userq: convert comma to semicolonChen Ni1-2/+2
Using a ',' in place of a ';' can have unintended side effects. Although that is not the case here, it seems best to use ';' unless ',' is intended. Found by inspection. No functional change intended. Compile tested only. Signed-off-by: Chen Ni <nichen@iscas.ac.cn> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-24drm/amdgpu: Handle GPU page faults correctly on non-4K page systemsDonet Tom1-3/+3
During a GPU page fault, the driver restores the SVM range and then maps it into the GPU page tables. The current implementation passes a GPU-page-size (4K-based) PFN to svm_range_restore_pages() to restore the range. SVM ranges are tracked using system-page-size PFNs. On systems where the system page size is larger than 4K, using GPU-page-size PFNs to restore the range causes two problems: Range lookup fails: Because the restore function receives PFNs in GPU (4K) units, the SVM range lookup does not find the existing range. This will result in a duplicate SVM range being created. VMA lookup failure: The restore function also tries to locate the VMA for the faulting address. It converts the GPU-page-size PFN into an address using the system page size, which results in an incorrect address on non-4K page-size systems. As a result, the VMA lookup fails with the message: "address 0xxxx VMA is removed". This patch passes the system-page-size PFN to svm_range_restore_pages() so that the SVM range is restored correctly on non-4K page systems. Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Donet Tom <donettom@linux.ibm.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-24drm/amd/display: update outdated comments for renamed vblank_control_worker()Kexin Sun1-3/+5
The function vblank_control_worker() was renamed to amdgpu_dm_crtc_vblank_control_worker() by commit 6ce4f9ee25ff ("drm/amd/display: Add prefix to amdgpu crtc functions"). Update the two stale references in amdgpu_dm.c. Assisted-by: unnamed:deepseek-v3.2 coccinelle Signed-off-by: Kexin Sun <kexinsun@smail.nju.edu.cn> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-24drm/amd/display: clean up typecasts and constants in dcn4_calcsAdriano Vero1-16/+16
Signed-off-by: Adriano Vero <litaliano00.contact@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-24drm/amdgpu/userq: dont use goto to jump when at end of functionSunil Khatri1-3/+1
In function amdgpu_userq_restore_worker we dont need to use goto as we already in the end of function and it will exit naturally. Signed-off-by: Sunil Khatri <sunil.khatri@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-24drm/amdgpu: fix syncobj leak for amdgpu_gem_va_ioctl()Prike Liang1-0/+5
It requires freeing the syncobj and chain alloction resource. Signed-off-by: Prike Liang <Prike.Liang@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-24drm/amdgpu/vcn4.0.3: gate per-queue reset by PSP SOS program versionJesse Zhang1-1/+18
Add a PSP SOS firmware compatibility check before enabling VCN per-queue reset on vcn_v4_0_3. Per review, program check is sufficient: when PSP SOS program is 0x01, require fw version >= 0x0036015f; otherwise allow per-queue reset. Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Suggested-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Jesse Zhang <Jesse.zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-24drm/amd/pm: Enable VCN reset for pgm=4 with appropriate FW versionJesse.Zhang1-0/+1
Extend the VCN reset capability to include pgm=4 variants when the firmware version meets the required threshold (>= 0x04557100). This follows the existing pattern for pgm=0 and pgm=7, ensuring that VCN reset is enabled only on configurations where it is supported by the firmware. Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Jesse Zhang <jesse.zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-24drm/amdgpu: use DISCOVERY_TMR_SIZE in ACPI TMR fallbackJesse.Zhang1-1/+1
amdgpu_acpi_get_tmr_info() returns the full TMR region size, not the IP discovery table size. Using tmr_size as discovery.size can lead to oversized allocations and probe failure. In the ACPI fallback path, keep discovery.size as DISCOVERY_TMR_SIZE and only use ACPI data for offset calculation. Fixes: 01bdc7e219c4 ("drm/amdgpu: New interface to get IP discovery binary v3") Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Suggested-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Jesse Zhang <jesse.zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-24drm/amd/pm: add dedicated dram addr msg for smu v15Yang Wang3-4/+6
Add dedicated SMU Dram MSG mapping to avoid conflicts in SMU IP v15 common code for upcoming ASICs. add new smu msg: - SMU_MSG_SetDriverDramAddr - SMU_MSG_SetToolsDramAddr Signed-off-by: Yang Wang <kevinyang.wang@amd.com> Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Reviewed-by: Asad Kamal <asad.kamal@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
generated by cgit v1.2.3 (git 2.39.0) at 2026-05-29 02:51:25 +0300