summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2025-03-02drm/rockchip: vop2: Remove AFBC from TRANSFORM_OFFSET register macroAndy Yan
This TRANSFORM_OFFSET register needs to be configured not only in AFBC mode, but also in tile mode, so remove the AFBC/AFBCD prefix. This also help avoid "exceeds 100 columns" warning from checkpatch. Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20250218112744.34433-3-andyshrk@163.com
2025-03-02drm/rockchip: vop2: use devm_regmap_field_alloc for cluster-regsAndy Yan
Right now vop2_cluster_init() copies the base vop2_cluster_regs and adapts the reg value with the current window's offset before adding the fields to the regmap. This conflicts with the notion of reg_fields being const, see https://lore.kernel.org/all/20240706-regmap-const-structs-v1-1-d08c776da787@weissschuh.net/ for reference, which now causes checkpatch to actually warn about that. So instead of creating one big copy and changing it afterwards, add the reg_fields individually using devm_regmap_field_alloc(). Functional it is the same, just that the reg_field we're handling can stay const. Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20250218112744.34433-2-andyshrk@163.com
2025-03-02Merge tag 'dmaengine-fix-6.14' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine Pull dmaengine fixes from Vinod Koul: - tegra210 div_u64 divison and max page fixes - revert Qualcomm unavailable register workaround which is causing regression, fixes have been proposed but still gaps are present so revert this for now * tag 'dmaengine-fix-6.14' of git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine: dmaengine: Revert "dmaengine: qcom: bam_dma: Avoid writing unavailable register" dmaengine: tegra210-adma: check for adma max page dmaengine: tegra210-adma: Use div_u64 for 64 bit division
2025-03-02Merge tag 'phy-fixes-6.14' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy Pull phy fixes from Vinod Koul: - rockchip phy kconfig dependency fix with USB_COMMON and regression fix for old DT - stm32 phy overflow assertion fix - exonysfs phy refclk masks fix and power gate on exit fix - freescale fix for clock dividor valid range - TI regmap syscon register fix - tegra reset registers on init fix * tag 'phy-fixes-6.14' of git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy: phy: tegra: xusb: reset VBUS & ID OVERRIDE phy: ti: gmii-sel: Do not use syscon helper to build regmap phy: exynos5-usbdrd: gs101: ensure power is gated to SS phy in phy_exit() phy: freescale: fsl-samsung-hdmi: Limit PLL lock detection clock divider to valid range phy: exynos5-usbdrd: fix MPLL_MULTIPLIER and SSC_REFCLKSEL masks in refclk phy: stm32: Fix constant-value overflow assertion phy: rockchip: naneng-combphy: compatible reset with old DT phy: rockchip: fix Kconfig dependency more
2025-03-02hwmon: (ad7314) Validate leading zero bits and return errorErik Schumacher
Leading zero bits are sent on the bus before the temperature value is transmitted. If any of these bits are high, the connection might be unstable or there could be no AD7314 / ADT730x (or compatible) at all. Return -EIO in that case. Signed-off-by: Erik Schumacher <erik.schumacher@iris-sensing.com> Fixes: 4f3a659581cab ("hwmon: AD7314 driver (ported from IIO)") Link: https://lore.kernel.org/r/24a50c2981a318580aca8f50d23be7987b69ea00.camel@iris-sensing.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-03-02hwmon: (ntc_thermistor) Fix the ncpXXxh103 sensor tableMaud Spierings
I could not find a single table that has the values currently present in the table, change it to the actual values that can be found in [1]/[2] and [3] (page 15 column 2) [1]: https://www.murata.com/products/productdetail?partno=NCP15XH103F03RC [2]: https://www.murata.com/products/productdata/8796836626462/NTHCG83.txt?1437969843000 [3]: https://nl.mouser.com/datasheet/2/281/r44e-522712.pdf Fixes: 54ce3a0d8011 ("hwmon: (ntc_thermistor) Add support for ncpXXxh103") Signed-off-by: Maud Spierings <maudspierings@gocontroll.com> Link: https://lore.kernel.org/r/20250227-ntc_thermistor_fixes-v1-3-70fa73200b52@gocontroll.com Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-03-02hwmon: (pmbus) Initialise page count in pmbus_identify()Titus Rwantare
The `pmbus_identify()` function fails to correctly determine the number of supported pages on PMBus devices. This occurs because `info->pages` is implicitly zero-initialised, and `pmbus_set_page()` does not perform writes to the page register if `info->pages` is not yet initialised. Without this patch, `info->pages` is always set to the maximum after scanning. This patch initialises `info->pages` to `PMBUS_PAGES` before the probing loop, enabling `pmbus_set_page()` writes to make it out onto the bus correctly identifying the number of pages. `PMBUS_PAGES` seemed like a reasonable non-zero number because that's the current result of the identification process. Testing was done with a PMBus device in QEMU. Signed-off-by: Titus Rwantare <titusr@google.com> Fixes: 442aba78728e7 ("hwmon: PMBus device driver") Link: https://lore.kernel.org/r/20250227222455.2583468-1-titusr@google.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2025-03-02drm/mediatek: Move to devm_platform_ioremap_resource() usageAnusha Srivatsa
Replace platform_get_resource + devm_ioremap_resource with just devm_platform_ioremap_resource() Cc: Chun-Kuang Hu <chunkuang.hu@kernel.org> Cc: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: CK Hu <ck.hu@mediatek.com> Signed-off-by: Anusha Srivatsa <asrivats@redhat.com> Link: https://patchwork.kernel.org/project/dri-devel/patch/20250213-mem-cocci-v3-v1-4-93466d165349@redhat.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2025-03-02drm/mediatek: Add support for MT8195 Digital Parallel InterfaceAngeloGioacchino Del Regno
Add support for the DPI block found in the MT8195 and MT8188 SoCs. Inside of the SoC, this block is directly connected to the HDMI IP. Reviewed-by: CK Hu <ck.hu@mediatek.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://patchwork.kernel.org/project/dri-devel/patch/20250217154836.108895-11-angelogioacchino.delregno@collabora.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2025-03-02drm/mediatek: mtk_dpi: Explicitly manage TVD clock in power on/offAngeloGioacchino Del Regno
In preparation for adding support for MT8195's HDMI reserved DPI, add calls to clk_prepare_enable() / clk_disable_unprepare() for the TVD clock: in this particular case, the aforementioned clock is not (and cannot be) parented to neither pixel or engine clocks hence it won't get enabled automatically by the clock framework. Please note that on all of the currently supported MediaTek platforms, the TVD clock is always a parent of either pixel or engine clocks, and this means that the common clock framework is already enabling this clock before the children. On such platforms, this commit will only increase the refcount of the TVD clock without any functional change. Reviewed-by: CK Hu <ck.hu@mediatek.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://patchwork.kernel.org/project/dri-devel/patch/20250217154836.108895-10-angelogioacchino.delregno@collabora.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2025-03-02drm/mediatek: mtk_dpi: Support AFIFO 1T1P output and conversionAngeloGioacchino Del Regno
On some SoCs, like MT8195 and MT8188, the DPI's FIFO controller (afifo) supports outputting either one or two pixels per round regardless of the input being 1T1P or 1T2P. Add a `output_1pixel` member to struct mtk_dpi_conf which, if set, will enable outputting one pixel per clock. In case the input is two pixel per clock (1T2P), the AFIFO HW will automatically (and internally) convert it to 1T1P. Reviewed-by: CK Hu <ck.hu@mediatek.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://patchwork.kernel.org/project/dri-devel/patch/20250217154836.108895-9-angelogioacchino.delregno@collabora.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2025-03-02Merge tag 'gpio-fixes-for-v6.14-rc5' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux Pull gpio fix from Bartosz Golaszewski: - fix a buggy get_direction() retval check * tag 'gpio-fixes-for-v6.14-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux: gpiolib: Fix Oops in gpiod_direction_input_nonotify()
2025-03-02drm/mediatek: mtk_dpi: Add support for DPI input clock from HDMIAngeloGioacchino Del Regno
On some SoCs, like MT8195 and MT8188, the DPI instance that is reserved to the HDMI Transmitter uses a different clock topology. In this case, the DPI is clocked by the HDMI IP, and this outputs its clock to the MM input of dpi_pixel_clk, which is essential to enable register access to the DPI IP. Add a `clocked_by_hdmi` member to struct mtk_dpi_conf, and check it to avoid enabling the DPI clocks in the mediatek-drm internal .start() callback (and avoid disabing in the .stop() component callback): this will make sure that the clock configuration sequence is respected during display pipeline setup by following the bridge ops between DPI and HDMI, where the HDMI driver is expected to enable the clocks in the bridge's pre_enable(), and DPI in the enable() cb. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: CK Hu <ck.hu@mediatek.com> Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2025-03-02drm/mediatek: mtk_dpi: Move the input_2p_en bit to platform dataAngeloGioacchino Del Regno
In preparation for adding support for MT8195's HDMI reserved DPI instance, move the input_2p_en bit for DP_INTF to platform data. While at it, remove the input_2pixel member from platform data as having this bit implies that the 2pixel feature must be enabled. Reviewed-by: CK Hu <ck.hu@mediatek.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://patchwork.kernel.org/project/dri-devel/patch/20250217154836.108895-7-angelogioacchino.delregno@collabora.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2025-03-02drm/mediatek: mtk_dpi: Add checks for reg_h_fre_con existenceAngeloGioacchino Del Regno
In preparation for adding support for newer DPI instances which do support direct-pin but do not have any H_FRE_CON register, like the one found in MT8195 and MT8188, add a branch to check if the reg_h_fre_con variable was declared in the mtk_dpi_conf structure for the probed SoC DPI version. As a note, this is useful specifically only for cases in which the support_direct_pin variable is true, so mt8195-dpintf is not affected by any issue. Reviewed-by: CK Hu <ck.hu@mediatek.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://patchwork.kernel.org/project/dri-devel/patch/20250217154836.108895-6-angelogioacchino.delregno@collabora.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2025-03-02drm/mediatek: mtk_dpi: Move pixel clock setting flow to functionAngeloGioacchino Del Regno
In preparation for adding support for the DPI IP found in MT8195 and in MT8188 used for HDMI, move the code flow for calculation and setting of the DPI pixel clock to a separate function called mtk_dpi_set_pixel_clk(). This was done because, on those platforms, the DPI instance that is used for HDMI will get its pixel clock from the HDMI clock, hence it is not necessary, nor desirable, to calculate or set the pixel clock in DPI. Reviewed-by: CK Hu <ck.hu@mediatek.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://patchwork.kernel.org/project/dri-devel/patch/20250217154836.108895-5-angelogioacchino.delregno@collabora.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2025-03-02drm/mediatek: mtk_dpi: Use an array for pixclk factor calculationAngeloGioacchino Del Regno
Setting the TVD PLL clock requires to multiply the target pixel clock by a specific constant factor to achieve the target PLL frequency, and this is done to reduce jitter to acceptable levels. On all MediaTek SoCs, the factor is not retrieved by any real kind of calculation but rather by checking if the target pixel clock is less than a specified frequency, hence assigning a function pointer for just a bunch of if branches does enlarge the code size for little reason. Remove all SoC-specific functions, add a structure `mtk_dpi_factor` that holds a clock frequency and corresponding PLL factor, and declare the constraints for each SoC in form of an array of said structure. Instead of function pointers, this structure (and its size) is then assigned to each SoC's platform data. The "calculation" is then performed with a new static function mtk_dpi_calculate_factor(dpi, mode_clk) that iterates through all of the entries of the aforementioned array and returns the right factor. If no factor is found, the lowest possible factor is returned, mimicking the same flow as all of the old per-SoC calculation functions. This commit brings no functional change. Reviewed-by: CK Hu <ck.hu@mediatek.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://patchwork.kernel.org/project/dri-devel/patch/20250217154836.108895-4-angelogioacchino.delregno@collabora.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2025-03-02drm/mediatek: mtk_dpi: Add support for Pattern Generator in debugfsAngeloGioacchino Del Regno
This IP includes a Pattern Generator which is useful for debugging and testing purposes: add the relevant register and bits to the mtk_dpi_regs.h header, and implement support for it in mtk_dpi. Adding this required to introduce a .debugfs_init() callback for the DPI bridge, which creates a "dpi_test_pattern" file in the directory of the appropriate connector. The pattern generator can generate various internal patterns and this submission includes support for: - 256 or 1024 shades of gray in a Vertical or Horizontal Pattern - Vertical Color Bars - Frame border - Dot Moire This generator also supports filling the entire screen with one custom color, but support for that is not included in this commit. Enabling and disabling this generator can be done by sending a string to the dpi_test_pattern debugfs file; the pattern is expected to be formatted as follows: <enable (1) or disable (0)> <pattern number> where the pattern number can be a number from 0 to 7, excluding 5. Of course 5 is excluded because that activates custom color fill which, again, is not supported in this commit. Reviewed-by: CK Hu <ck.hu@mediatek.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://patchwork.kernel.org/project/dri-devel/patch/20250217154836.108895-3-angelogioacchino.delregno@collabora.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
2025-03-01Merge tag 'i2c-for-6.14-rc5' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux Pull i2c fixes from Wolfram Sang: "All driver fixes this time: - fix interrupt initialization sequence (npcm) - fix frequency setting (ls2x) - re-enable interrupts properly at irq handler's exit (amd-asf)" * tag 'i2c-for-6.14-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: i2c: amd-asf: Fix EOI register write to enable successive interrupts i2c: ls2x: Fix frequency division register access i2c: npcm: disable interrupt enable bit before devm_request_irq
2025-03-01Merge tag 'ata-6.14-rc5' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/libata/linux Pull ata fixes from Niklas Cassel: - Fix a regression where the enablement of the PHYs would be skipped for device trees without any port child nodes (me) - Revert ATA_QUIRK_NOLPM for Samsung SSD 870 QVO drives, as it stops systems from entering lower package states. LPM works on newer firmware versions. We will need a more refined quirk that only targets the older firmware versions (me) * tag 'ata-6.14-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/libata/linux: Revert "ata: libata-core: Add ATA_QUIRK_NOLPM for Samsung SSD 870 QVO drives" ata: ahci: Make ahci_ignore_port() handle empty mask_port_map
2025-03-01Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvmLinus Torvalds
Pull kvm fixes from Paolo Bonzini: "ARM: - Fix TCR_EL2 configuration to not use the ASID in TTBR1_EL2 and not mess-up T1SZ/PS by using the HCR_EL2.E2H==0 layout. - Bring back the VMID allocation to the vcpu_load phase, ensuring that we only setup VTTBR_EL2 once on VHE. This cures an ugly race that would lead to running with an unallocated VMID. RISC-V: - Fix hart status check in SBI HSM extension - Fix hart suspend_type usage in SBI HSM extension - Fix error returned by SBI IPI and TIME extensions for unsupported function IDs - Fix suspend_type usage in SBI SUSP extension - Remove unnecessary vcpu kick after injecting interrupt via IMSIC guest file x86: - Fix an nVMX bug where KVM fails to detect that, after nested VM-Exit, L1 has a pending IRQ (or NMI). - To avoid freeing the PIC while vCPUs are still around, which would cause a NULL pointer access with the previous patch, destroy vCPUs before any VM-level destruction. - Handle failures to create vhost_tasks" * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: kvm: retry nx_huge_page_recovery_thread creation vhost: return task creation error instead of NULL KVM: nVMX: Process events on nested VM-Exit if injectable IRQ or NMI is pending KVM: x86: Free vCPUs before freeing VM state riscv: KVM: Remove unnecessary vcpu kick KVM: arm64: Ensure a VMID is allocated before programming VTTBR_EL2 KVM: arm64: Fix tcr_el2 initialisation in hVHE mode riscv: KVM: Fix SBI sleep_type use riscv: KVM: Fix SBI TIME error generation riscv: KVM: Fix SBI IPI error generation riscv: KVM: Fix hart suspend_type use riscv: KVM: Fix hart suspend status check
2025-03-01gpu: ipu-v3 ipu-cpmem: Remove unused functionsDr. David Alan Gilbert
ipu_cpmem_set_yuv_interleaved() was added in 2012 by commit 0125f21b2baf ("staging: drm/imx: Add ipu_cpmem_set_yuv_interleaved()") but has remained unused. ipu_cpmem_get_burstsize() was added in 2016 by commit 03085911d7bb ("gpu: ipu-cpmem: Add ipu_cpmem_get_burstsize()") but has remained unused. Remove them. Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20241226022752.219399-8-linux@treblig.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2025-03-01gpu: ipu-v3: ipu-csi: Remove unused functionsDr. David Alan Gilbert
ipu_csi_get_window(), ipu_csi_is_interlaced() and ipu_csi_set_test_generator() were added in 2014 by commit 2ffd48f2e7ae ("gpu: ipu-v3: Add Camera Sensor Interface unit") but have remained unused. Remove them. ipu_csi_set_testgen_mclk() is now unused. Remove it. Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20241226022752.219399-7-linux@treblig.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2025-03-01gpu: ipu-v3: Remove unused ipu_vdi_unsetupDr. David Alan Gilbert
ipu_vdi_unsetup() was added in 2016 by commit 2d2ead453077 ("gpu: ipu-v3: Add Video Deinterlacer unit") but has remained unused. Remove it. Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20241226022752.219399-6-linux@treblig.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2025-03-01gpu: ipu-v3: Remove unused ipu_image_convert_* functionsDr. David Alan Gilbert
ipu_image_convert_enum_format() and ipu_image_convert_sync() were both added in 2016 by commit cd98e85a6b78 ("gpu: ipu-v3: Add queued image conversion support") but have remained unused. Remove them. ipu_image_convert_sync() was the last user of image_convert_sync_complete(). Remove it. Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20241226022752.219399-5-linux@treblig.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2025-03-01gpu: ipu-v3: Remove unused ipu_idmac_channel_busyDr. David Alan Gilbert
The last use of ipu_idmac_channel_busy() was removed in 2017 by commit eb8c88808c83 ("drm/imx: add deferred plane disabling") Remove it. Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20241226022752.219399-4-linux@treblig.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2025-03-01gpu: ipu-v3: Remove unused ipu_rot_mode_to_degreesDr. David Alan Gilbert
ipu_rot_mode_to_degrees() was added in 2014 by commit f835f386a119 ("gpu: ipu-v3: Add rotation mode conversion utilities") but has remained unused. Remove it. Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20241226022752.219399-3-linux@treblig.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2025-03-01gpu: ipu-v3: ipu-ic: Remove unused ipu_ic_task_graphics_initDr. David Alan Gilbert
ipu_ic_task_graphics_init() was added in 2014 by commit 1aa8ea0d2bd5 ("gpu: ipu-v3: Add Image Converter unit") but has been unused. Remove it. Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20241226022752.219399-2-linux@treblig.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2025-03-01Revert "ata: libata-core: Add ATA_QUIRK_NOLPM for Samsung SSD 870 QVO drives"Niklas Cassel
This reverts commit cc77e2ce187d26cc66af3577bf896d7410eb25ab. It was reported that adding ATA_QUIRK_NOLPM for Samsung SSD 870 QVO drives breaks entering lower package states for certain systems. It turns out that Samsung SSD 870 QVO actually has working LPM when using a recent SSD firmware version. The author of commit cc77e2ce187d ("ata: libata-core: Add ATA_QUIRK_NOLPM for Samsung SSD 870 QVO drives") reported himself that only older SSD firmware versions have broken LPM: https://lore.kernel.org/stable/93c10d38-718c-459d-84a5-4d87680b4da7@debian.org/ Unfortunately, he did not specify which older firmware version he was using which had broken LPM. Let's revert this quirk, which has FW version field specified as NULL (which means that it applies for all Samsung SSD 870 QVO firmware versions) for now. Once the author reports which older firmware version(s) that are broken, we can create a more fine grained quirk, which populates the FW version field accordingly. Fixes: cc77e2ce187d ("ata: libata-core: Add ATA_QUIRK_NOLPM for Samsung SSD 870 QVO drives") Reported-by: Dieter Mummenschanz <dmummenschanz@web.de> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219747 Link: https://lore.kernel.org/r/20250228122603.91814-2-cassel@kernel.org Signed-off-by: Niklas Cassel <cassel@kernel.org>
2025-03-01vhost: return task creation error instead of NULLKeith Busch
Lets callers distinguish why the vhost task creation failed. No one currently cares why it failed, so no real runtime change from this patch, but that will not be the case for long. Signed-off-by: Keith Busch <kbusch@kernel.org> Message-ID: <20250227230631.303431-2-kbusch@meta.com> Reviewed-by: Mike Christie <michael.christie@oracle.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2025-02-28drm/xe: Add performance tunings to debugfsTvrtko Ursulin
Add a list of active tunings to debugfs, analogous to the existing list of workarounds. Rationale being that it seems to make sense to either have both or none. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250227101304.46660-6-tvrtko.ursulin@igalia.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-02-28drm/xe/xelp: L3 recommended hashing maskTvrtko Ursulin
According to the i915 codebase xe missed to set the recommended performance tuning for L3 hashing which is applicable to all legacy XeLP platforms. Lets add it. v2: * Rename prefixes to XELP_. * Tweak version end point. v3: * Add bspec tag. * Tweak version range. v4: * Move from LRC to engine tunings list. v5: * Drop L3 Cache Control comment. Bspec: 31870 Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> References: c46c5fb725be ("drm/i915/gen12: Apply recommended L3 hashing mask") Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250227101304.46660-5-tvrtko.ursulin@igalia.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-02-28drm/xe/xelp: Add Wa_1604555607Tvrtko Ursulin
According to the i915 code base and as confirmed in the workaround database, apart from setting the GS timer, all XeLP platforms should also set the TDS timer. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> References: 2b5298b0aa09 ("drm/i915/gen12: Add recommended hardware tuning value") Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250227101304.46660-4-tvrtko.ursulin@igalia.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-02-28drm/xe/xelp: Move Wa_16011163337 from tunings to workaroundsTvrtko Ursulin
Workaround database specifies 16011163337 as a workaround so lets move it there. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250227101304.46660-3-tvrtko.ursulin@igalia.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-02-28drm/xe: Fix GT "for each engine" workaroundsTvrtko Ursulin
Any rules using engine matching are currently broken due RTP processing happening too in early init, before the list of hardware engines has been initialised. Fix this by moving workaround processing to later in the driver probe sequence, to just before the processed list is used for the first time. Looking at the debugfs gt0/workarounds on ADL-P we notice 14011060649 should be present while we see, before: GT Workarounds 14011059788 14015795083 And with the patch: GT Workarounds 14011060649 14011059788 14015795083 Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: stable@vger.kernel.org # v6.11+ Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250227101304.46660-2-tvrtko.ursulin@igalia.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-02-28caif_virtio: fix wrong pointer check in cfv_probe()Vitaliy Shevtsov
del_vqs() frees virtqueues, therefore cfv->vq_tx pointer should be checked for NULL before calling it, not cfv->vdev. Also the current implementation is redundant because the pointer cfv->vdev is dereferenced before it is checked for NULL. Fix this by checking cfv->vq_tx for NULL instead of cfv->vdev before calling del_vqs(). Fixes: 0d2e1a2926b1 ("caif_virtio: Introduce caif over virtio") Signed-off-by: Vitaliy Shevtsov <v.shevtsov@mt-integration.ru> Reviewed-by: Gerhard Engleder <gerhard@engleder-embedded.com> Link: https://patch.msgid.link/20250227184716.4715-1-v.shevtsov@mt-integration.ru Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-02-28Merge tag 'thermal-6.14-rc5' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull thermal control fixes from Rafael Wysocki: "These fix the processing of DT thermal properties and the Power Allocator thermal governor: - Fix parsing cooling-maps in DT for trip points with more than one cooling device (Rafael Wysocki) - Fix granted_power computation in the Power Allocator thermal governor and make it update total_weight on configuration changes after the thermal zone has been registered (Yu-Che Cheng)" * tag 'thermal-6.14-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: thermal: gov_power_allocator: Update total_weight on bind and cdev updates thermal/of: Fix cdev lookup in thermal_of_should_bind() thermal: gov_power_allocator: Fix incorrect calculation in divvy_up_power()
2025-02-28Merge tag 'pm-6.14-rc5' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull power management fix from Rafael Wysocki: "Fix the handling of processors that stop the TSC in deeper C-states in the intel_idle driver (Thomas Gleixner)" * tag 'pm-6.14-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: intel_idle: Handle older CPUs, which stop the TSC in deeper C states, correctly
2025-02-28Merge tag 'iommu-fixes-v6.14-rc4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/iommu/linux Pull iommu fixes from Joerg Roedel: - Intel VT-d fixes: - Fix suspicious RCU usage splat - Fix passthrough for devices under PCIe-PCI bridge - AMD-Vi fix: - Fix to preserve bits when updating device table entries * tag 'iommu-fixes-v6.14-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/iommu/linux: iommu/vt-d: Fix suspicious RCU usage iommu/vt-d: Remove device comparison in context_setup_pass_through_cb iommu/amd: Preserve default DTE fields when updating Host Page Table Root
2025-02-28Merge tag 'for-net-2025-02-27' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth Luiz Augusto von Dentz says: ==================== bluetooth pull request for net: - mgmt: Check return of mgmt_alloc_skb - btusb: Initialize .owner field of force_poll_sync_fops * tag 'for-net-2025-02-27' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth: Bluetooth: Add check for mgmt_alloc_skb() in mgmt_device_connected() Bluetooth: Add check for mgmt_alloc_skb() in mgmt_remote_name() bluetooth: btusb: Initialize .owner field of force_poll_sync_fops ==================== Link: https://patch.msgid.link/20250227223802.3299088-1-luiz.dentz@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-02-28intel_idle: Handle older CPUs, which stop the TSC in deeper C states, correctlyThomas Gleixner
The Intel idle driver is preferred over the ACPI processor idle driver, but fails to implement the work around for Core2 generation CPUs, where the TSC stops in C2 and deeper C-states. This causes stalls and boot delays, when the clocksource watchdog does not catch the unstable TSC before the CPU goes deep idle for the first time. The ACPI driver marks the TSC unstable when it detects that the CPU supports C2 or deeper and the CPU does not have a non-stop TSC. Add the equivivalent work around to the Intel idle driver to cure that. Fixes: 18734958e9bf ("intel_idle: Use ACPI _CST for processor models without C-state tables") Reported-by: Fab Stz <fabstz-it@yahoo.fr> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Fab Stz <fabstz-it@yahoo.fr> Cc: All applicable <stable@vger.kernel.org> Closes: https://lore.kernel.org/all/10cf96aa-1276-4bd4-8966-c890377030c3@yahoo.fr Link: https://patch.msgid.link/87bjupfy7f.ffs@tglx Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-02-28Merge tag 'efi-fixes-for-v6.14-2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi Pull EFI fixes from Ard Biesheuvel: "Another couple of EFI fixes for v6.14. Only James's patch stands out, as it implements a workaround for odd behavior in fwupd in user space, which creates EFI variables by touching a file in efivarfs, clearing the immutable bit (which gets set automatically for $reasons) and then opening it again for writing, none of which is really necessary. The fwupd author and LVFS maintainer is already rolling out a fix for this on the fwupd side, and suggested that the workaround in this PR could be backed out again during the next cycle. (There is a semantic mismatch in efivarfs where some essential variable attributes are stored in the first 4 bytes of the file, and so zero length files cannot exist, as they cannot be written back to the underlying variable store. So now, they are dropped once the last reference is released.) Summary: - Fix CPER error record parsing bugs - Fix a couple of efivarfs issues that were introduced in the merge window - Fix an issue in the early remapping code of the MOKvar table" * tag 'efi-fixes-for-v6.14-2' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi: efi/mokvar-table: Avoid repeated map/unmap of the same page efi: Don't map the entire mokvar table to determine its size efivarfs: allow creation of zero length files efivarfs: Defer PM notifier registration until .fill_super efi/cper: Fix cper_arm_ctx_info alignment efi/cper: Fix cper_ia_proc_ctx alignment
2025-02-28gpu: host1x: Remove unused host1x_debug_dump_syncptsDr. David Alan Gilbert
host1x_debug_dump_syncpts() has been unused since commit f0fb260a0cdb ("gpu: host1x: Implement syncpoint wait using DMA fences") Remove it. Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org> Acked-by: Mikko Perttunen <mperttunen@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241215214750.448209-1-linux@treblig.org
2025-02-28drm/i915/display: Make POWER_DOMAIN_*() always result in enum ↵Gustavo Sousa
intel_display_power_domain In the hope of contributing to type safety in our code, let's ensure that the type returned by the POWER_DOMAIN_*() macros is always of type enum intel_display_power_domain. v2: - Remove accidental +1 in definition of POWER_DOMAIN_PIPE(). (Jani) Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250227-improve-type-safey-power-domain-macros-v3-2-b6eaa00f9c33@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2025-02-28drm/i915/display: Use explicit base values in POWER_DOMAIN_*() macrosGustavo Sousa
Although we have comments in intel_display_limits.h saying that the code expects PIPE_A and TRANSCODER_A to be zero, it doesn't hurt to add them as explicit base values for calculating the power domain offset in POWER_DOMAIN_*() macros. On the plus side, we have that this: * Fixes a warning reported by kernel test robot <lkp@intel.com> about doing arithmetic with two different enum types. * Makes the code arguably more robust (in the unlikely event of those bases becoming non-zero). v2: - Prefer using explicit base values instead of simply casting the macro argument to int. (Ville) - Update commit message to match the new approach (for reference, the old message subject was "drm/i915/display: Use explicit cast in POWER_DOMAIN_*() macros"). Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202502120809.XfmcqkBD-lkp@intel.com/ Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250227-improve-type-safey-power-domain-macros-v3-1-b6eaa00f9c33@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2025-02-28gpiolib: Fix Oops in gpiod_direction_input_nonotify()Dan Carpenter
The gpiod_direction_input_nonotify() function is supposed to return zero if the direction for the pin is input. But instead it accidentally returns GPIO_LINE_DIRECTION_IN (1) which will be cast into an ERR_PTR() in gpiochip_request_own_desc(). The callers dereference it and it leads to a crash. I changed gpiod_direction_output_raw_commit() just for consistency but returning GPIO_LINE_DIRECTION_OUT (0) is fine. Cc: stable@vger.kernel.org Fixes: 9d846b1aebbe ("gpiolib: check the return value of gpio_chip::get_direction()") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://lore.kernel.org/r/254f3925-3015-4c9d-aac5-bb9b4b2cd2c5@stanley.mountain [Bartosz: moved the variable declarations to the top of the functions] Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-02-28Merge drm/drm-next into drm-xe-nextLucas De Marchi
Sync to fix conlicts between drm-xe-next and drm-intel-next. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-02-28drm/i915/audio: Extend Wa_14020863754 to Xe3_LPDGustavo Sousa
Workaround Wa_14020863754 also applies to Xe3_LPD. Update needs_wa_14020863754() accordingly. Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250227-xe3lpd-wa-14020863754-v2-2-92b35de1c563@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2025-02-28drm/i915/display: Use IP version check for Wa_14020863754Gustavo Sousa
Wa_14020863754 applies to the display IP, so we should be checking on display IP version instead of platform. So, let's replace display->platform.battlemage with the proper IP version check (14.01 for Xe2_HPD). Furthermore, for workarounds, we should be checking on full IP versions to avoid applying the workaround to some variant of the IP that could theoretically appear in the future (which is likely to have a different minor release number), since the issue addressed by the workaround could be fixed in such new release. Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250227-xe3lpd-wa-14020863754-v2-1-92b35de1c563@intel.com Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
2025-02-28iommu/vt-d: Fix suspicious RCU usageLu Baolu
Commit <d74169ceb0d2> ("iommu/vt-d: Allocate DMAR fault interrupts locally") moved the call to enable_drhd_fault_handling() to a code path that does not hold any lock while traversing the drhd list. Fix it by ensuring the dmar_global_lock lock is held when traversing the drhd list. Without this fix, the following warning is triggered: ============================= WARNING: suspicious RCU usage 6.14.0-rc3 #55 Not tainted ----------------------------- drivers/iommu/intel/dmar.c:2046 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 1, debug_locks = 1 2 locks held by cpuhp/1/23: #0: ffffffff84a67c50 (cpu_hotplug_lock){++++}-{0:0}, at: cpuhp_thread_fun+0x87/0x2c0 #1: ffffffff84a6a380 (cpuhp_state-up){+.+.}-{0:0}, at: cpuhp_thread_fun+0x87/0x2c0 stack backtrace: CPU: 1 UID: 0 PID: 23 Comm: cpuhp/1 Not tainted 6.14.0-rc3 #55 Call Trace: <TASK> dump_stack_lvl+0xb7/0xd0 lockdep_rcu_suspicious+0x159/0x1f0 ? __pfx_enable_drhd_fault_handling+0x10/0x10 enable_drhd_fault_handling+0x151/0x180 cpuhp_invoke_callback+0x1df/0x990 cpuhp_thread_fun+0x1ea/0x2c0 smpboot_thread_fn+0x1f5/0x2e0 ? __pfx_smpboot_thread_fn+0x10/0x10 kthread+0x12a/0x2d0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x4a/0x60 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> Holding the lock in enable_drhd_fault_handling() triggers a lockdep splat about a possible deadlock between dmar_global_lock and cpu_hotplug_lock. This is avoided by not holding dmar_global_lock when calling iommu_device_register(), which initiates the device probe process. Fixes: d74169ceb0d2 ("iommu/vt-d: Allocate DMAR fault interrupts locally") Reported-and-tested-by: Ido Schimmel <idosch@nvidia.com> Closes: https://lore.kernel.org/linux-iommu/Zx9OwdLIc_VoQ0-a@shredder.mtl.com/ Tested-by: Breno Leitao <leitao@debian.org> Cc: stable@vger.kernel.org Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Link: https://lore.kernel.org/r/20250218022422.2315082-1-baolu.lu@linux.intel.com Tested-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Joerg Roedel <jroedel@suse.de>