summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2025-06-30drivers/panel: raydium-rm67200: Make reset-gpio optionalAndy Yan1-7/+9
Although the datasheet of the panel module describes that it has a reset pin, in the actual hardware design, we often use an RC circuit to control the reset, and rarely use GPIO to control the reset. This is the way it is done on our numerous development boards (such as RK3568/RK3576 EVB). So make the reset-gpio optional. Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20250616070536.670519-2-andyshrk@163.com
2025-06-30drm/panel: Add driver for DJN HX83112B LCD panelLuca Weiss3-0/+441
Add support for the 2160x1080 LCD panel from DJN (98-03057-6598B-I) bundled with a HX83112B driver IC, as found on the Fairphone 3 smartphone. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Luca Weiss <luca@lucaweiss.eu> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20250611-fp3-display-v4-3-ef67701e7687@lucaweiss.eu
2025-06-30drm/sched/tests: Make timedout_job callback a better role modelPhilipp Stanner1-1/+25
Since the drm_mock_scheduler does not have real users in userspace, nor does it have real hardware or firmware rings, it's not necessary to signal timedout fences nor free jobs - from a functional standpoint. Still, the dma_fence framework establishes the hard rule that all fences must always get signaled. The unit tests, moreover, should as much as possible represent the intended usage of the scheduler API. Furthermore, this later enables simplifying the mock scheduler's teardown code path. Make sure timed out hardware fences get signaled with the appropriate error code. Signed-off-by: Philipp Stanner <phasta@kernel.org> Acked-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/r/20250605134154.191764-2-phasta@kernel.org
2025-06-30Merge tag 'rtc-6.16-fixes' of ↵Linus Torvalds3-74/+140
git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux Pull RTC fixes from Alexandre Belloni: "Some fixes for 6.16. The cmos one is important for PREEMPT_RT. I've also added the s5m changes as they had a dependency on the MFD pull request that was included in 6.16-rc1 and we didn't synchronize before the merge window and they won't hurt. - cmos: use spin_lock_irqsave in cmos_interrupt - pcf2127: fix SPI command byte for PCF2131 - s5m: add S2MPG10 support" * tag 'rtc-6.16-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux: rtc: pcf2127: add missing semicolon after statement rtc: pcf2127: fix SPI command byte for PCF2131 rtc: cmos: use spin_lock_irqsave in cmos_interrupt rtc: s5m: replace open-coded read/modify/write registers with regmap helpers rtc: s5m: replace regmap_update_bits with regmap_clear/set_bits rtc: s5m: switch to devm_device_init_wakeup rtc: s5m: fix a typo: peding -> pending rtc: s5m: add support for S2MPG10 RTC rtc: s5m: prepare for external regmap rtc: s5m: cache device type during probe
2025-06-30drm/i915/backlight: Use drm_edp_backlight_enableSuraj Kandpal1-14/+0
Use drm dp helper to enable backlight now that it has been modified to set PANEL_LUMINANCE_CONTROL_ENABLE bit based on if capability supports it and the driver wants it. Remove the dead code. Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com> Link: https://lore.kernel.org/r/20250620063445.3603086-14-suraj.kandpal@intel.com
2025-06-30drm/i915/backlight: Use drm helper to set edp backlightSuraj Kandpal1-31/+3
Now that the drm helper sets the backlight using luminance too we can use that. Remove the obselete function. Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com> Link: https://lore.kernel.org/r/20250620063445.3603086-13-suraj.kandpal@intel.com
2025-06-30drm/i915/backlight: Use drm helper to initialize edp backlightSuraj Kandpal1-50/+48
Now that drm_edp_backlight init has been modified to take into account the setup of lumininace based brightness manipulation we can just use that. --v2 -Fix commit message [Arun] Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com> Link: https://lore.kernel.org/r/20250620063445.3603086-12-suraj.kandpal@intel.com
2025-06-30drm/dp: Enable backlight control using luminanceSuraj Kandpal1-0/+3
Add flag to enable brightness control via luminance value when enabling edp backlight. Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com> Link: https://lore.kernel.org/r/20250620063445.3603086-11-suraj.kandpal@intel.com
2025-06-30drm/dp: Change argument type of drm_edp_backlight_enableSuraj Kandpal2-2/+2
Change the argument type to u32 for the default level being sent since it has to now account for luminance value which has to be set for DP_EDP_PANEL_LUMINANCE_TARGET_VALUE. --v2 -No need to typecast [Jani] Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com> Link: https://lore.kernel.org/r/20250620063445.3603086-10-suraj.kandpal@intel.com
2025-06-30drm/dp: Modify drm_edp_backlight_set_levelSuraj Kandpal1-4/+12
Modify drm_edp_backlight_set_level to be able to set the value for register in DP_EDP_PANEL_TARGET_LUMINANCE_VALUE. We multiply the level with 1000 since we get the value in Nits and the register accepts it in milliNits. --v2 -Add comment regarding the unit [Arun] Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com> Link: https://lore.kernel.org/r/20250620063445.3603086-9-suraj.kandpal@intel.com
2025-06-30drm/dp: Change argument type for drm_edp_backlight_set_levelSuraj Kandpal1-1/+1
Use u32 for level variable as one may need to pass value for DP_EDP_PANEL_TARGET_LUMINANCE_VALUE. --v2 -Typecase is not needed [Jani] Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com> Link: https://lore.kernel.org/r/20250620063445.3603086-8-suraj.kandpal@intel.com
2025-06-30drm/dp: Modify drm_edp_probe_stateSuraj Kandpal1-10/+30
Modify drm_edp_probe_state to read current level from DP_EDP_PANEL_TARGET_LUMINANCE_VALUE. We divide it by 1000 since the value in this register is in millinits. --v2 -Add comment on the unit sent back [Arun] Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com> Link: https://lore.kernel.org/r/20250620063445.3603086-7-suraj.kandpal@intel.com
2025-06-30drm/dp: Change current_level argument type to u32Suraj Kandpal3-4/+4
Change the current_level argument type to u32 from u16 since it can now carry the value which it gets from DP_EDP_PANEL_TARGET_LUMINANCE_VALUE. Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com> Link: https://lore.kernel.org/r/20250620063445.3603086-6-suraj.kandpal@intel.com
2025-06-30drm/dp: Move from u16 to u32 for max in drm_edp_backlight_infoSuraj Kandpal1-3/+7
Use u32 instead of u16 for max variable in drm_edp_backlight_info since it can now hold max luminance range value which is u32. We will set this max with max_luminance value when luminance_set is true. Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com> Link: https://lore.kernel.org/r/20250620063445.3603086-5-suraj.kandpal@intel.com
2025-06-30drm/dp: Add argument for max luminance in drm_edp_backlight_initSuraj Kandpal3-4/+9
Add new argument to drm_edp_backlight_init which gives the max_luminance which will be needed to set the max values for backlight. --v2 -Use pass only max luminance instead of luminance_range_info struct [Arun] Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com> Link: https://lore.kernel.org/r/20250620063445.3603086-4-suraj.kandpal@intel.com
2025-06-30drm/dp: Add argument in drm_edp_backlight_initSuraj Kandpal3-5/+6
Add bool argument in drm_edp_backlight init to provide the drivers option to choose if they want to use luminance values to manipulate brightness. Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com> Link: https://lore.kernel.org/r/20250620063445.3603086-3-suraj.kandpal@intel.com
2025-06-30drm/dp: Introduce new member in drm_backlight_infoSuraj Kandpal1-2/+6
Introduce luminance_set flag which indicates if we can manipulate backlight using luminance value or not which is only possible after eDP v1.5. Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com> Link: https://lore.kernel.org/r/20250620063445.3603086-2-suraj.kandpal@intel.com
2025-06-30regulator: mp886x: Fix ID table driver_dataJisheng Zhang1-1/+2
Currently, the driver_data of the i2c ID table is wrong, so it won't work if any mp886x user makes use of the ID table. Fortunately, there's no such user in upstream source code, we can fix the issue by using different ID table entry for mp8867 and mp8869. Signed-off-by: Jisheng Zhang <jszhang@kernel.org> Link: https://patch.msgid.link/20250629095918.912-1-jszhang@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2025-06-30regulator: sy8824x: Fix ID table driver_dataJisheng Zhang1-1/+4
Currently, the driver_data of the i2c ID table is wrong, so it won't work if any sy8824x user makes use of the ID table. Fortunately, there's no such user in upstream source code, we can fix the issue by using different ID table entry for sy8824c, sy8824e, sy20276 and sy20278. Signed-off-by: Jisheng Zhang <jszhang@kernel.org> Link: https://patch.msgid.link/20250629095905.898-1-jszhang@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2025-06-30spi: stm32: fix pointer-to-pointer variables usageAntonio Quartulli1-10/+12
In stm32_spi_prepare_rx_dma_mdma_chaining() both rx_dma_desc and rx_mdma_desc are passed as pointer-to-pointer arguments. The goal is to pass back to the caller the value returned by dmaengine_prep_slave_sg(), when it is not NULL. However, these variables are wrongly handled as simple pointers during later assignments and checks. Fix this behaviour by introducing two pointer variables which can then be treated accordingly. Fixes: d17dd2f1d8a1 ("spi: stm32: use STM32 DMA with STM32 MDMA to enhance DDR use") Addresses-Coverity-ID: 1644715 ("Null pointer dereferences (REVERSE_INULL)") Signed-off-by: Antonio Quartulli <antonio@mandelbit.com> Reviewed-by: Clement LE GOFFIC <clement.legoffic@foss.st.com> Link: https://patch.msgid.link/20250630081253.17294-1-antonio@mandelbit.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-06-30spi: stm32: fix sram pool free in probe error pathClément Le Goffic1-1/+3
Add a test to check whether the sram_pool is NULL before freeing it. Fixes: d17dd2f1d8a1 ("spi: stm32: use STM32 DMA with STM32 MDMA to enhance DDR use") Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Acked-by: Alain Volmat <alain.volmat@foss.st.com> Signed-off-by: Clément Le Goffic <clement.legoffic@foss.st.com> Link: https://patch.msgid.link/20250630-spi-fix-v2-1-4680939e2a3e@foss.st.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-06-30irqchip/irq-msi-lib: Select CONFIG_GENERIC_MSI_IRQNam Cao1-0/+1
irq-msi-lib directly uses struct msi_domain_info and more things which are only available when CONFIG_GENERIC_MSI_IRQ=y. However, there is no dependency specified and CONFIG_IRQ_MSI_LIB can be enabled without CONFIG_GENERIC_MSI_IRQ, which causes the kernel build fail. Make IRQ_MSI_LIB select GENEREIC_MSI_IRQ to prevent that. Fixes: 72e257c6f058 ("irqchip: Provide irq-msi-lib") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Nam Cao <namcao@linutronix.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/all/b0c44007f3b7e062228349a2395f8d850050db33.1751277765.git.namcao@linutronix.de Closes: https://lore.kernel.org/oe-kbuild-all/202506282256.cHlEHrdc-lkp@intel.com/
2025-06-30dm-mpath: don't print the "loaded" message if registering failsMikulas Patocka4-4/+12
If dm_register_path_selector, don't print the "version X loaded" message. Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2025-06-30dm-mpath: make dm_unregister_path_selector return voidMikulas Patocka7-26/+9
dm_unregister_path_selector may only return error if there's a bug in the code - so we make it return void and print a warning if the user abuses this function to unregister a target that was not registered. Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2025-06-30usb: dwc2: disable platform lowlevel hw resources during shutdownJisheng Zhang1-0/+3
On some SoC platforms, in shutdown stage, most components' power is cut off, but there's still power supply to the so called always-on domain, so if the dwc2's regulator is from the always-on domain, we need to explicitly disable it to save power. Disable platform lowlevel hw resources such as phy, clock and regulators etc. in device shutdown hook to reduce non-necessary power consumption when the platform enters shutdown stage. Signed-off-by: Jisheng Zhang <jszhang@kernel.org> Acked-by: Minas Harutyunyan <hminas@synopsys.com> Link: https://lore.kernel.org/r/20250629094655.747-1-jszhang@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-06-30usb: misc: onboard_usb_dev: Add Bison Electronics Inc. Integrated CameraJens Glathe2-0/+10
The Camera is built into the Thinkbook 16 G7 QOY and directly attached on the usb_2 controller (dwc3 USB2 only). It has a separate power supply that needs to be controlled for PM. Add the support for this device for the power supply. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz> Link: https://lore.kernel.org/r/20250629-tb16-dt-v7-2-35276341338f@oldschoolsolutions.biz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-06-30usb: hub: Fix flushing of delayed work used for post resume purposesMathias Nyman2-13/+9
Delayed work that prevents USB3 hubs from runtime-suspending too early needed to be flushed in hub_quiesce() to resolve issues detected on QC SC8280XP CRD board during suspend resume testing. This flushing did however trigger new issues on Raspberry Pi 3B+, which doesn't have USB3 ports, and doesn't queue any post resume delayed work. The flushed 'hub->init_work' item is used for several purposes, and is originally initialized with a 'NULL' work function. The work function is also changed on the fly, which may contribute to the issue. Solve this by creating a dedicated delayed work item for post resume work, and flush that delayed work in hub_quiesce() Cc: stable <stable@kernel.org> Fixes: a49e1e2e785f ("usb: hub: Fix flushing and scheduling of delayed work that tunes runtime pm") Reported-by: Mark Brown <broonie@kernel.org> Closes: https://lore.kernel.org/linux-usb/aF5rNp1l0LWITnEB@finisterre.sirena.org.uk Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Tested-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> # SC8280XP CRD Tested-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20250627164348.3982628-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-06-30wifi: zd1211rw: Fix potential NULL pointer dereference in zd_mac_tx_to_dev()Daniil Dulov1-1/+5
There is a potential NULL pointer dereference in zd_mac_tx_to_dev(). For example, the following is possible: T0 T1 zd_mac_tx_to_dev() /* len == skb_queue_len(q) */ while (len > ZD_MAC_MAX_ACK_WAITERS) { filter_ack() spin_lock_irqsave(&q->lock, flags); /* position == skb_queue_len(q) */ for (i=1; i<position; i++) skb = __skb_dequeue(q) if (mac->type == NL80211_IFTYPE_AP) skb = __skb_dequeue(q); spin_unlock_irqrestore(&q->lock, flags); skb_dequeue() -> NULL Since there is a small gap between checking skb queue length and skb being unconditionally dequeued in zd_mac_tx_to_dev(), skb_dequeue() can return NULL. Then the pointer is passed to zd_mac_tx_status() where it is dereferenced. In order to avoid potential NULL pointer dereference due to situations like above, check if skb is not NULL before passing it to zd_mac_tx_status(). Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 459c51ad6e1f ("zd1211rw: port to mac80211") Signed-off-by: Daniil Dulov <d.dulov@aladdin.ru> Link: https://patch.msgid.link/20250626114619.172631-1-d.dulov@aladdin.ru Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-06-30spi: spi-qpic-snand: avoid memory corruptionMark Brown2-4/+42
Merge series from Gabor Juhos <j4g8y7@gmail.com>: The 'spi-qpic-nand' driver may cause memory corruption under some circumstances. The first patch in the series changes the driver to avoid that, whereas the second adds some sanity checks to the common QPIC code in order to make detecting such errors easier in the future.
2025-06-30drm/vmwgfx: drop printing the TTM refcount for debuggingChristian König1-3/+2
That is something TTM internal which is about to get dropped. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Ian Forbes <ian.forbes@broadcom.com> Link: https://lore.kernel.org/r/20250616130726.22863-1-christian.koenig@amd.com
2025-06-30drm/i915/gt: Fix timeline left held on VMA alloc errorJanusz Krzysztofik1-1/+2
The following error has been reported sporadically by CI when a test unbinds the i915 driver on a ring submission platform: <4> [239.330153] ------------[ cut here ]------------ <4> [239.330166] i915 0000:00:02.0: [drm] drm_WARN_ON(dev_priv->mm.shrink_count) <4> [239.330196] WARNING: CPU: 1 PID: 18570 at drivers/gpu/drm/i915/i915_gem.c:1309 i915_gem_cleanup_early+0x13e/0x150 [i915] ... <4> [239.330640] RIP: 0010:i915_gem_cleanup_early+0x13e/0x150 [i915] ... <4> [239.330942] Call Trace: <4> [239.330944] <TASK> <4> [239.330949] i915_driver_late_release+0x2b/0xa0 [i915] <4> [239.331202] i915_driver_release+0x86/0xa0 [i915] <4> [239.331482] devm_drm_dev_init_release+0x61/0x90 <4> [239.331494] devm_action_release+0x15/0x30 <4> [239.331504] release_nodes+0x3d/0x120 <4> [239.331517] devres_release_all+0x96/0xd0 <4> [239.331533] device_unbind_cleanup+0x12/0x80 <4> [239.331543] device_release_driver_internal+0x23a/0x280 <4> [239.331550] ? bus_find_device+0xa5/0xe0 <4> [239.331563] device_driver_detach+0x14/0x20 ... <4> [357.719679] ---[ end trace 0000000000000000 ]--- If the test also unloads the i915 module then that's followed with: <3> [357.787478] ============================================================================= <3> [357.788006] BUG i915_vma (Tainted: G U W N ): Objects remaining on __kmem_cache_shutdown() <3> [357.788031] ----------------------------------------------------------------------------- <3> [357.788204] Object 0xffff888109e7f480 @offset=29824 <3> [357.788670] Allocated in i915_vma_instance+0xee/0xc10 [i915] age=292729 cpu=4 pid=2244 <4> [357.788994] i915_vma_instance+0xee/0xc10 [i915] <4> [357.789290] init_status_page+0x7b/0x420 [i915] <4> [357.789532] intel_engines_init+0x1d8/0x980 [i915] <4> [357.789772] intel_gt_init+0x175/0x450 [i915] <4> [357.790014] i915_gem_init+0x113/0x340 [i915] <4> [357.790281] i915_driver_probe+0x847/0xed0 [i915] <4> [357.790504] i915_pci_probe+0xe6/0x220 [i915] ... Closer analysis of CI results history has revealed a dependency of the error on a few IGT tests, namely: - igt@api_intel_allocator@fork-simple-stress-signal, - igt@api_intel_allocator@two-level-inception-interruptible, - igt@gem_linear_blits@interruptible, - igt@prime_mmap_coherency@ioctl-errors, which invisibly trigger the issue, then exhibited with first driver unbind attempt. All of the above tests perform actions which are actively interrupted with signals. Further debugging has allowed to narrow that scope down to DRM_IOCTL_I915_GEM_EXECBUFFER2, and ring_context_alloc(), specific to ring submission, in particular. If successful then that function, or its execlists or GuC submission equivalent, is supposed to be called only once per GEM context engine, followed by raise of a flag that prevents the function from being called again. The function is expected to unwind its internal errors itself, so it may be safely called once more after it returns an error. In case of ring submission, the function first gets a reference to the engine's legacy timeline and then allocates a VMA. If the VMA allocation fails, e.g. when i915_vma_instance() called from inside is interrupted with a signal, then ring_context_alloc() fails, leaving the timeline held referenced. On next I915_GEM_EXECBUFFER2 IOCTL, another reference to the timeline is got, and only that last one is put on successful completion. As a consequence, the legacy timeline, with its underlying engine status page's VMA object, is still held and not released on driver unbind. Get the legacy timeline only after successful allocation of the context engine's VMA. v2: Add a note on other submission methods (Krzysztof Karas): Both execlists and GuC submission use lrc_alloc() which seems free from a similar issue. Fixes: 75d0a7f31eec ("drm/i915: Lift timeline into intel_context") Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12061 Cc: Chris Wilson <chris.p.wilson@linux.intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Krzysztof Karas <krzysztof.karas@intel.com> Reviewed-by: Sebastian Brzezinka <sebastian.brzezinka@intel.com> Reviewed-by: Krzysztof Niemiec <krzysztof.niemiec@intel.com> Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> Reviewed-by: Nitin Gote <nitin.r.gote@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://lore.kernel.org/r/20250611104352.1014011-2-janusz.krzysztofik@linux.intel.com
2025-06-30drm/ttm: fix error handling in ttm_buffer_object_transferChristian König1-6/+7
Unlocking the resv object was missing in the error path, additionally to that we should move over the resource only after the fence slot was reserved. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Fixes: c8d4c18bfbc4a ("dma-buf/drivers: make reserving a shared slot mandatory v4") Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20250616130726.22863-3-christian.koenig@amd.com
2025-06-30spi: spi-pci1xxxx: enable concurrent DMA read/write across SPI transfersThangaraj Samynathan1-35/+47
Refactor the pci1xxxx SPI driver to allow overlapping DMA read and write operations across SPI transfers. This improves throughput and reduces idle time between SPI transactions. Transfer sequence: - Start with a DMA read to load TX data from host to device buffer. - After DMA read completes, trigger the SPI transfer. - On SPI completion: - Start DMA write to copy received data from RX buffer to host. - Start the next DMA read to prepare TX data for the following transfer. - Begin the next SPI transfer after both DMA write and read complete. To implement this sequence, the following changes were made: - Added dma_completion_count to track and synchronize DMA completions. - Split DMA setup into separate functions for TX (read) and RX (write). - Introduced separate spinlocks for safe access to RD and WR DMA registers. This new flow enables efficient pipelining by overlapping data preparation and completion stages, leading to better SPI transfer performance and utilization of DMA engines. Signed-off-by: Thangaraj Samynathan <thangaraj.s@microchip.com> Link: https://patch.msgid.link/20250630073233.7356-1-thangaraj.s@microchip.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-06-30dma-buf: fix timeout handling in dma_resv_wait_timeout v2Christian König1-5/+7
Even the kerneldoc says that with a zero timeout the function should not wait for anything, but still return 1 to indicate that the fences are signaled now. Unfortunately that isn't what was implemented, instead of only returning 1 we also waited for at least one jiffies. Fix that by adjusting the handling to what the function is actually documented to do. v2: improve code readability Reported-by: Marek Olšák <marek.olsak@amd.com> Reported-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Lucas Stach <l.stach@pengutronix.de> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20250129105841.1806-1-christian.koenig@amd.com
2025-06-30regulator: tps6286x-regulator: Enable REGCACHE_MAPLEJisheng Zhang1-0/+9
Enable regmap cache to reduce i2c transactions and corresponding interrupts if regulator is accessed frequently. Signed-off-by: Jisheng Zhang <jszhang@kernel.org> Link: https://patch.msgid.link/20250629095107.804-1-jszhang@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2025-06-30regulator: tps6287x-regulator: Enable REGCACHE_MAPLEJisheng Zhang1-0/+7
Enable regmap cache to reduce i2c transactions and corresponding interrupts if regulator is accessed frequently. Signed-off-by: Jisheng Zhang <jszhang@kernel.org> Link: https://patch.msgid.link/20250629095822.868-1-jszhang@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2025-06-30regulator: rt5739: Enable REGCACHE_MAPLEJisheng Zhang1-0/+9
Enable regmap cache to reduce i2c transactions and corresponding interrupts if regulator is accessed frequently. Signed-off-by: Jisheng Zhang <jszhang@kernel.org> Link: https://patch.msgid.link/20250629094803.776-1-jszhang@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2025-06-30platform/mellanox: mlxreg-lc: Fix logic error in power state checkAlok Tiwari1-1/+1
Fixes a logic issue in mlxreg_lc_completion_notify() where the intention was to check if MLXREG_LC_POWERED flag is not set before powering on the device. The original code used "state & ~MLXREG_LC_POWERED" to check for the absence of the POWERED bit. However this condition evaluates to true even when other bits are set, leading to potentially incorrect behavior. Corrected the logic to explicitly check for the absence of MLXREG_LC_POWERED using !(state & MLXREG_LC_POWERED). Fixes: 62f9529b8d5c ("platform/mellanox: mlxreg-lc: Add initial support for Nvidia line card devices") Suggested-by: Vadim Pasternak <vadimp@nvidia.com> Signed-off-by: Alok Tiwari <alok.a.tiwari@oracle.com> Link: https://lore.kernel.org/r/20250630105812.601014-1-alok.a.tiwari@oracle.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-06-30i2c: Re-enable piix4 driver on non-x86Mario Limonciello1-1/+1
loongarch and mips both support hardware that uses the i2c-piix4 driver. It should not be restricted to x86, so drop the x86 dependency. Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Closes: https://lore.kernel.org/all/CAMuHMdVPQLjOox5sMp34Z5MTwKv2WOpHa=MpZr8hWG22fQKcjw@mail.gmail.com/ Fixes: 7e173eb82ae97175 ("i2c: piix4: Make CONFIG_I2C_PIIX4 dependent on CONFIG_X86"). Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Reviewed-by: Hans de Goede <hansg@kernel.org> Acked-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/20250610205817.3912944-2-superm1@kernel.org Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-06-30Move FCH header to a location accessible by all archsMario Limonciello2-2/+2
A new header fch.h was created to store registers used by different AMD drivers. This header was included by i2c-piix4 in commit 624b0d5696a8 ("i2c: piix4, x86/platform: Move the SB800 PIIX4 FCH definitions to <asm/amd/fch.h>"). To prevent compile failures on non-x86 archs i2c-piix4 was set to only compile on x86 by commit 7e173eb82ae9717 ("i2c: piix4: Make CONFIG_I2C_PIIX4 dependent on CONFIG_X86"). This was not a good decision because loongarch and mips both actually support i2c-piix4 and set it enabled in the defconfig. Move the header to a location accessible by all architectures. Fixes: 624b0d5696a89 ("i2c: piix4, x86/platform: Move the SB800 PIIX4 FCH definitions to <asm/amd/fch.h>") Suggested-by: Hans de Goede <hansg@kernel.org> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Reviewed-by: Hans de Goede <hansg@kernel.org> Link: https://lore.kernel.org/r/20250610205817.3912944-1-superm1@kernel.org Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-06-30platform/x86: x86-android-tablets: Add ovc-capacity-table infoHans de Goede1-0/+60
Add ovc-capacity-table info to the generic battery nodes. The values come from the ug3105 driver which currently hardcodes these values. The ug3105 driver will be modified to stop hardcoding this and instead get the values from device-properties. Reviewed-by: Andy Shevchenko <andy@kernel.org> Signed-off-by: Hans de Goede <hansg@kernel.org> Link: https://lore.kernel.org/r/20250609104620.25896-2-hansg@kernel.org Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-06-30platform/x86: x86-android-tablets: Add generic_lipo_4v2_battery infoHans de Goede3-18/+20
Move the asus_tf103c_battery_node to shared-psy-info.c and rename it to generic_lipo_4v2_battery_node. This is a preparation patch for adding ovc-capacity-table info to the battery nodes. Reviewed-by: Andy Shevchenko <andy@kernel.org> Signed-off-by: Hans de Goede <hansg@kernel.org> Link: https://lore.kernel.org/r/20250609104620.25896-1-hansg@kernel.org Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-06-30net/mlx5e: Fix error handling in RQ memory model registrationFushuai Wang1-3/+6
Currently when xdp_rxq_info_reg_mem_model() fails in the XSK path, the error handling incorrectly jumps to err_destroy_page_pool. While this may not cause errors, we should make it jump to the correct location. Signed-off-by: Fushuai Wang <wangfushuai@baidu.com> Reviewed-by: Zhu Yanjun <yanjun.zhu@linux.dev> Acked-by: Dragos Tatulea <dtatulea@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2025-06-30platform/x86/intel/hid: Add Wildcat Lake supportSrinivas Pandruvada1-0/+1
Add ACPI ID for Wildcat Lake. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Link: https://lore.kernel.org/r/20250617232913.3314765-1-srinivas.pandruvada@linux.intel.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-06-30platform/x86: dell-wmi-sysman: Fix class device unregistrationKurt Borja1-2/+2
Devices under the firmware_attributes_class do not have unique a dev_t. Therefore, device_unregister() should be used instead of device_destroy(), since the latter may match any device with a given dev_t. Fixes: e8a60aa7404b ("platform/x86: Introduce support for Systems Management Driver over WMI for Dell Systems") Signed-off-by: Kurt Borja <kuurtb@gmail.com> Link: https://lore.kernel.org/r/20250625-dest-fix-v1-3-3a0f342312bb@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-06-30platform/x86: think-lmi: Fix class device unregistrationKurt Borja1-2/+2
Devices under the firmware_attributes_class do not have unique a dev_t. Therefore, device_unregister() should be used instead of device_destroy(), since the latter may match any device with a given dev_t. Fixes: a40cd7ef22fb ("platform/x86: think-lmi: Add WMI interface support on Lenovo platforms") Signed-off-by: Kurt Borja <kuurtb@gmail.com> Link: https://lore.kernel.org/r/20250625-dest-fix-v1-2-3a0f342312bb@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-06-30platform/x86: hp-bioscfg: Fix class device unregistrationKurt Borja1-2/+2
Devices under the firmware_attributes_class do not have unique a dev_t. Therefore, device_unregister() should be used instead of device_destroy(), since the latter may match any device with a given dev_t. Fixes: a34fc329b189 ("platform/x86: hp-bioscfg: bioscfg") Signed-off-by: Kurt Borja <kuurtb@gmail.com> Link: https://lore.kernel.org/r/20250625-dest-fix-v1-1-3a0f342312bb@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-06-30clk: amlogic: remove unnecessary headersJerome Brunet18-677/+530
Some Amlogic clock controller drivers have a dedicated headers file, some do not. Over time, these headers have evolved and now only carry register offset definitions. These offsets are only used by the related controller and are not meant to be shared. These headers are not serving any purpose now. Start enforcing some consistency between the different Amlogic clock drivers and move the register offset definitions to the related driver. Link: https://lore.kernel.org/r/20250623-clk-meson-no-headers-v1-1-468161a7279e@baylibre.com [jbrunet: checkpatch strict: removed extra blank line] Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
2025-06-30platform/x86: Update swnode graph for amd isp4Pratap Nirujogi1-37/+144
Existing swnode graph format is specific to sensor device and is causing conflicts when accessing standard property variables outside the sensor driver. To address this issue, enhanced swnode graph format with dedicated nodes for i2c and isp devices, with sensor node added as child to i2c node. This approach allows to have standard property variables (ex: 'clock-frequency') with values applicable for each of the devices (sensor, i2c and isp). ACPI device driver_data handle is also initialized with root camera swnode to access the property variables in the graph in isp and i2c drivers. Signed-off-by: Pratap Nirujogi <pratap.nirujogi@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20250618202958.3934822-1-pratap.nirujogi@amd.com Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-06-30EDAC: Initialize EDAC features sysfs attributesShiju Jose3-1/+5
Fix the lockdep splat caused by missing sysfs_attr_init() calls for the recently added EDAC feature's sysfs attributes. In lockdep_init_map_type(), the check for the lock-class key if (!static_obj(key) && !is_dynamic_key(key)) causes the splat. Backtrace: RIP: 0010:lockdep_init_map_type Call Trace: __kernfs_create_file sysfs_add_file_mode_ns internal_create_group internal_create_groups device_add ? __init_waitqueue_head edac_dev_register devm_cxl_memdev_edac_register ? lock_acquire ? find_held_lock ? cxl_mem_probe ? cxl_mem_probe ? lockdep_hardirqs_on ? cxl_mem_probe cxl_mem_probe [ bp: Massage. ] Fixes: f90b738166fe ("EDAC: Add scrub control feature") Fixes: bcbd069b11b0 ("EDAC: Add a Error Check Scrub control feature") Fixes: 699ea5219c4b ("EDAC: Add a memory repair control feature") Reported-by: Dave Jiang <dave.jiang@intel.com> Suggested-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Shiju Jose <shiju.jose@huawei.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com> Link: https://lore.kernel.org/20250626101344.1726-1-shiju.jose@huawei.com
generated by cgit v1.2.3 (git 2.39.0) at 2026-06-04 15:44:36 +0300