summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-09-16dt-bindings: i3c: Add adi-i3c-masterJorge Marques
Add bindings doc for ADI I3C Controller IP core, a FPGA synthesizable IP core that implements the MIPI I3C Basic controller specification. The IP Core is versioned following Semantic Versioning 2.0.0 and ADI's open-source HDL guidelines for devicetree bindings and drivers. Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Jorge Marques <jorge.marques@analog.com> Link: https://lore.kernel.org/r/20250827-adi-i3c-master-v9-1-04413925abe1@analog.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2025-09-16i3c: Fix default I2C adapter timeout valueJarkko Nikula
Commit 3a379bbcea0a ("i3c: Add core I3C infrastructure") set the default adapter timeout for I2C transfers as 1000 (ms). However that parameter is defined in jiffies not in milliseconds. With mipi-i3c-hci driver this wasn't visible until commit c0a90eb55a69 ("i3c: mipi-i3c-hci: use adapter timeout value for I2C transfers"). Fix this by setting the default timeout as HZ (CONFIG_HZ) not 1000. Fixes: 1b84691e7870 ("i3c: dw: use adapter timeout value for I2C transfers") Fixes: be27ed672878 ("i3c: master: cdns: use adapter timeout value for I2C transfers") Fixes: c0a90eb55a69 ("i3c: mipi-i3c-hci: use adapter timeout value for I2C transfers") Fixes: a747e01adad2 ("i3c: master: svc: use adapter timeout value for I2C transfers") Fixes: d028219a9f14 ("i3c: master: Add basic driver for the Renesas I3C controller") Fixes: 3a379bbcea0a ("i3c: Add core I3C infrastructure") Cc: stable@vger.kernel.org # 6.17 Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://lore.kernel.org/r/20250905100320.954536-1-jarkko.nikula@linux.intel.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2025-09-16i3c: mipi-i3c-hci: Convert remaining DBG() prints to dev_dbg()Jarkko Nikula
Get rid of local DBG() macro and convert remaining debug prints to dev_dbg() which can be controlled without code recompile when kernel is built with dynamic debug support. Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Link: https://lore.kernel.org/r/20250827103009.243771-6-jarkko.nikula@linux.intel.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2025-09-16i3c: mipi-i3c-hci: Remove function enter DBG() printoutsJarkko Nikula
These function enter DBG("") printouts are not very useful in error report point of view because they require code recompile. In which case they can be replaced with more informative debug prints if needed so remove them for now. Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Link: https://lore.kernel.org/r/20250827103009.243771-5-jarkko.nikula@linux.intel.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2025-09-16i3c: mipi-i3c-hci: Uniform ring number printoutsJarkko Nikula
Use the same "Ring" prefix in all prints that print out the ring number. Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://lore.kernel.org/r/20250827103009.243771-4-jarkko.nikula@linux.intel.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2025-09-16i3c: mipi-i3c-hci: Remove nonexistent ring interruptJarkko Nikula
Ring interrupt bit 7, INTR_WARN_INS_STOP_MODE was probably drafted at some point but is marked as reserved in the MIPI I3C HCI specification versions 1.1 and 1.2 that came out after the initial code and also in the earlier specification versions so remove it. Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://lore.kernel.org/r/20250827103009.243771-3-jarkko.nikula@linux.intel.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2025-09-16i3c: mipi-i3c-hci: Change interrupt status prints to dev_dbg()Jarkko Nikula
Change interrupt status prints from local DBG() macro to dev_dbg() in order to make it easier to enable them without needing to recompile code with DEBUG defined. While doing so, spell out the status register names as they are in the specification to make it easier to differentiate between different interrupt status registers. Since dynamic debug prints can include the line number remove the "(in)" and "(out)" markers from the PIO interrupt status prints. Prefix the ring interrupt status print using "Ring %d" instead of "rh%d" to make it uniform across all other prints showing the ring number. Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://lore.kernel.org/r/20250827103009.243771-2-jarkko.nikula@linux.intel.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2025-09-16i3c: mipi-i3c-hci: Use own DMA bounce buffer management for I2C transfersJarkko Nikula
Stop using I2C DMA-safe API for two reasons: - Not needed if driver is using PIO mode. - DMA transfers needs a DWORD align sized receive bounce buffer when the device DMA is IOMMU mapped, which is causing needless double bounce buffering in that case. Cc: Billy Tsai <billy_tsai@aspeedtech.com> Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://lore.kernel.org/r/20250822105630.2820009-5-jarkko.nikula@linux.intel.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2025-09-16i3c: mipi-i3c-hci: Use physical device pointer with DMA APIJarkko Nikula
DMA transfer faults on Intel hardware when the IOMMU is enabled and driver initialization will fail when attempting to do the first transfer: DMAR: DRHD: handling fault status reg 2 DMAR: [DMA Read NO_PASID] Request device [00:11.0] fault addr 0x676e3000 [fault reason 0x71] SM: Present bit in first-level paging entry is clear i3c mipi-i3c-hci.0: ring 0: Transfer Aborted mipi-i3c-hci mipi-i3c-hci.0: probe with driver mipi-i3c-hci failed with error -62 Reason for this is that the IOMMU setup is done for the physical devices only and not for the virtual I3C Controller device object. Therefore use the pointer to a physical device object with the DMA API. Due to a data corruption observation when the device DMA is IOMMU mapped, a properly sized receive bounce buffer is required if transfer length is not a multiple of DWORDs. Reported-by: Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://lore.kernel.org/r/20250822105630.2820009-4-jarkko.nikula@linux.intel.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2025-09-16i3c: mipi-i3c-hci: Use core helpers for DMA mapping and bounce bufferingJarkko Nikula
So far only I3C private and I2C transfers have required a bounce buffer for DMA transfers when buffer is not DMA'able. It was observed that when the device DMA is IOMMU mapped and the receive length is not a multiple of DWORDs (32-bit), the last DWORD is padded with stale data from the RX FIFO, corrupting 1-3 bytes beyond the expected data. A similar issue, though less severe, occurs when an I3C target returns less data than requested. In this case, the padding does not exceed the requested number of bytes, assuming the device DMA is not IOMMU mapped. Therefore, all I3C private transfer, CCC command payload and I2C transfer receive buffers must be properly sized for the DMA being IOMMU mapped. Even if those buffers are already DMA safe, their size may not be DWORD aligned. To prepare for the device DMA being IOMMU mapped and to address the above issue, use helpers from I3C core for DMA mapping and bounce buffering for all DMA transfers. For now, require bounce buffer only when the buffer is in the vmalloc() area to avoid unnecessary copying with CCC commands and DMA-safe I2C transfers. Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://lore.kernel.org/r/20250822105630.2820009-3-jarkko.nikula@linux.intel.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2025-09-16i3c: master: Add helpers for DMA mapping and bounce buffer handlingJarkko Nikula
Some I3C controllers such as MIPI I3C HCI may pad the last DWORD (32-bit) with stale data from the RX FIFO in DMA transfers if the receive length is not DWORD aligned and when the device DMA is IOMMU mapped. In such a case, a properly sized bounce buffer is required in order to avoid possible data corruption. In a review discussion, proposal was to have a common helpers in I3C core for DMA mapping and bounce buffer handling. Drivers may use the helper i3c_master_dma_map_single() to map a buffer for a DMA transfer. It internally allocates a bounce buffer if buffer is not DMA'able or when the driver requires it for a transfer. Helper i3c_master_dma_unmap_single() does the needed cleanups and data copying from the bounce buffer. Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://lore.kernel.org/r/20250822105630.2820009-2-jarkko.nikula@linux.intel.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2025-09-16i3c: mipi-i3c-hci-pci: Add support for Intel Wildcat Lake-U I3CJarkko Nikula
Add I3C controller PCI IDs on Intel Wildcat Lake-U. Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://lore.kernel.org/r/20250808131732.1213227-1-jarkko.nikula@linux.intel.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2025-09-16drm/xe/sysfs: Add cleanup action in xe_device_sysfs_initZongyao Bai
On partial failure, some sysfs files created before the failure might not be removed. Add common cleanup step to remove them all immediately, as is should be harmless to attempt to remove non-existing files. Fixes: 0e414bf7ad01 ("drm/xe: Expose PCIe link downgrade attributes") Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Stuart Summers <stuart.summers@intel.com> Cc: Shuicheng Lin <shuicheng.lin@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Zongyao Bai <zongyao.bai@intel.com> Reviewed-by: Shuicheng Lin <shuicheng.lin@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20250915214716.1327379-2-zongyao.bai@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-09-16arm64: dts: qcom: x1-hp-x14: Add support for X1P42100 HP Omnibook X14Jens Glathe
These laptops are the same as the already known 14-fe0xxx models, but with a Purwa SoC, SKU number 14-fe1xxx. [1] The supported features are the same as for the original Omnibook X14: - Keyboard (no function keys though) - Display - PWM brightness control - Touchpad - Touchscreen - PCIe ports (pcie4, pcie6a) - USB type-c, type-a - WCN6855 Wifi-6E - WCN6855 Bluetooth - ADSP and CDSP - X1 GPU - GPIO Keys (Lid switch) - Audio definition (works via USB and with internal speakers) [1]: https://www.hp.com/us-en/shop/pdp/hp-omnibook-x-laptop-next-gen-ai-pc-14-fe100-14-a4nd1av-1#techSpecs Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz> Link: https://lore.kernel.org/r/20250915-hp-x14-x1p-v9-3-fa457ca30ffe@oldschoolsolutions.biz Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16arm64: dts: qcom: x1-hp-x14: Unify HP Omnibook X14 device tree structureJens Glathe
Extract common elements into a shared .dtsi file for HP Omnibook X14 to support both Hamoa (x1e*/x1p6*) and Purwa (x1p4*/x1*) variants. Required because the device trees are not compatible. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz> Link: https://lore.kernel.org/r/20250915-hp-x14-x1p-v9-2-fa457ca30ffe@oldschoolsolutions.biz Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16dt-bindings: arm: qcom: Add HP Omnibook X14 AI X1P4200 variantJens Glathe
The HP Omnibook X14 AI PC is available in fe0 (Hamoa, x1e80100) and fe1 (Purwa, x1p42100) SKUs. Since they are not completely dtb-compatible, add another variant: hp,omnibook-x14-fe1 compatible to cqom,x1p42100 Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz> Link: https://lore.kernel.org/r/20250915-hp-x14-x1p-v9-1-fa457ca30ffe@oldschoolsolutions.biz Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16ARM: at91: pm: Remove 2.5V regulatorRyan Wanner
Remove 2.5V regulator since enabling and disabling this regulator is no longer supported. Signed-off-by: Ryan Wanner <Ryan.Wanner@microchip.com> Link: https://lore.kernel.org/r/a6785a40648b315a07152bca261a42bbf0f356af.1757519351.git.Ryan.Wanner@microchip.com Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
2025-09-16s390/dcssblk: Add DAX supportGerald Schaefer
With ZONE_DEVICE now available for s390, struct pages can be allocated for proper DAX support in dcssblk driver via devm_memremap_pages(). Adding struct pages for a range requires that the range is aligned to SUBSECTION_SIZE, which is defined as 2 MB in common code. Therefore, only enable DAX support and allocate struct pages for DCSS ranges that are aligned to 2 MB. Signed-off-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com> Acked-by: Heiko Carstens <hca@linux.ibm.com> Reviewed-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
2025-09-16arm64: dts: qcom: ipq5018: add QUP3 I2C nodeVandhiadevan Karunamoorthy
Add node to support I2C bus inside of IPQ5018. Signed-off-by: Vandhiadevan Karunamoorthy <vkarunam@codeaurora.org> Signed-off-by: George Moussalem <george.moussalem@outlook.com> Link: https://lore.kernel.org/r/20250915-ipq5018-i2c-v1-1-46bbf27396d6@outlook.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16arm64: dts: qcom: x1e80100-dell-xps13-9345: Enable IRISStephan Gerhold
Enable IRIS to allow using the hardware-accelerated video codecs. The firmware is not upstream in linux-firmware yet, so users need to copy it from Windows to qcom/x1e80100/dell/xps13-9345/qcvss8380.mbn (just like GPU/ADSP/CDSP firmware). Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Link: https://lore.kernel.org/r/20250915-x1e-iris-dt-v2-9-1f928de08fd4@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16arm64: dts: qcom: x1e80100-dell-latitude-7455: Enable IRISStephan Gerhold
Enable IRIS to allow using the hardware-accelerated video codecs. The firmware is not upstream in linux-firmware yet, so users need to copy it from Windows to qcom/x1e80100/dell/latitude-7455/qcvss8380.mbn (just like GPU/ADSP/CDSP firmware). Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Link: https://lore.kernel.org/r/20250915-x1e-iris-dt-v2-8-1f928de08fd4@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16arm64: dts: qcom: x1e80100-dell-inspiron-14-plus-7441: Enable IRISStephan Gerhold
Enable IRIS to allow using the hardware-accelerated video codecs. The firmware is not upstream in linux-firmware yet, so users need to copy it from Windows to qcom/x1e80100/dell/inspiron-14-plus-7441/qcvss8380.mbn (just like GPU/ADSP/CDSP firmware). Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org> Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Link: https://lore.kernel.org/r/20250915-x1e-iris-dt-v2-7-1f928de08fd4@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16arm64: dts: qcom: x1e80100-lenovo-yoga-slim7x: Enable IRISStephan Gerhold
IRIS firmware for the Lenovo Yoga Slim 7x is already upstream in linux-firmware at qcom/x1e80100/LENOVO/83ED/qcvss8380.mbn, so enable IRIS for the Slim 7x with the corresponding firmware-name property. Tested-by: Anthony Ruhier <aruhier@mailbox.org> Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Link: https://lore.kernel.org/r/20250915-x1e-iris-dt-v2-6-1f928de08fd4@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16arm64: dts: qcom: x1e78100-lenovo-thinkpad-t14s: Enable IRISStephan Gerhold
IRIS firmware for the Lenovo ThinkPad T14s is already upstream in linux-firmware at qcom/x1e80100/LENOVO/21N1/qcvss8380.mbn, so enable IRIS for the T14s with the corresponding firmware-name property. Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on Thinkpad T14S OLED Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Link: https://lore.kernel.org/r/20250915-x1e-iris-dt-v2-5-1f928de08fd4@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16arm64: dts: qcom: x1e80100-crd: Enable IRIS video codecStephan Gerhold
IRIS firmware for x1e80100-crd is already upstream in linux-firmware in the default path, so enable IRIS for the CRD to accelerate video decoding. It looks like the X1P CRD might need a different IRIS firmware (possibly even changes in the Linux kernel driver), so keep it local to the X1E CRD for now. Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Link: https://lore.kernel.org/r/20250915-x1e-iris-dt-v2-4-1f928de08fd4@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16arm64: dts: qcom: x1-el2: Disable IRIS for nowStephan Gerhold
The reset and IOMMU management for remoteprocs like IRIS is implemented in the hypervisor for older targets such as X1E [1]. When booting Linux/KVM directly in EL2, this functionality is missing and the PAS interface normally used by IRIS to boot the video firmware is not working. The Venus driver supports starting the video firmware without using the PAS interface. The same code also works for X1E when using KVM. However, for the new IRIS dt-bindings it was decided to avoid using the dummy "video-firmware" node in the device tree to describe the IOMMU [2]. Discussion is still ongoing how to describe this properly [3]. To avoid regressions when running using KVM, add a TODO in x1-el2.dtso for now and disable IRIS even when it was enabled by the board. [1]: https://resources.linaro.org/en/resource/sF8jXifdb9V1mUefdbfafa [2]: https://lore.kernel.org/r/20250823155349.22344-2-krzysztof.kozlowski@linaro.org/ [3]: https://lore.kernel.org/r/20250819165447.4149674-12-mukesh.ojha@oss.qualcomm.com/ Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Link: https://lore.kernel.org/r/20250915-x1e-iris-dt-v2-3-1f928de08fd4@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16arm64: dts: qcom: x1e80100: Add IRIS video codecStephan Gerhold
Add the IRIS video codec to accelerate video decoding/encoding. Copied mostly from sm8550.dtsi, only the opp-table is slightly different for X1E. For opp-240000000, we need to vote for a higher OPP on one of the power domains, because the voltage requirements for the PLL and the derived clocks differ (sm8550.dtsi has the same). Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> # x1e Inspiron 14p Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on Thinkpad T14S OLED Tested-by: Anthony Ruhier <aruhier@mailbox.org> # Lenovo Slim 7x Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org> Link: https://lore.kernel.org/r/20250915-x1e-iris-dt-v2-2-1f928de08fd4@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16arm64: dts: qcom: sm8550/sm8650: Fix typo in IRIS commentStephan Gerhold
It should be "enable on boards", not "enable in boards". Reported-by: Alexey Klimov <alexey.klimov@linaro.org> Closes: https://lore.kernel.org/r/DCQ8G73ISXHC.3V03MOGB6NDZE@linaro.org/ Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Link: https://lore.kernel.org/r/20250915-x1e-iris-dt-v2-1-1f928de08fd4@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16arm64: dts: qcom: msm8916: Add SDCC resetsStephan Gerhold
Add the missing resets for the two SDCC controllers to allow fully resetting previous hardware state from the bootloader. Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250915-msm8916-resets-v1-3-a5c705df0c45@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16arm64: dts: qcom: msm8939: Add missing MDSS resetStephan Gerhold
On most MSM8939 devices, the bootloader already initializes the display to show the boot splash screen. In this situation, MDSS is already configured and left running when starting Linux. To avoid side effects from the bootloader configuration, the MDSS reset can be specified in the device tree to start again with a clean hardware state. The reset for MDSS is currently missing in msm8939.dtsi, which causes errors when the MDSS driver tries to re-initialize the registers: dsi_err_worker: status=6 dsi_err_worker: status=6 dsi_err_worker: status=6 ... It turns out that we have always indirectly worked around this by building the MDSS driver as a module. Before v6.17, the power domain was temporarily turned off until the module was loaded, long enough to clear the register contents. In v6.17, power domains are not turned off during boot until sync_state() happens, so this is no longer working. Even before v6.17 this resulted in broken behavior, but notably only when the MDSS driver was built-in instead of a module. Cc: stable@vger.kernel.org Fixes: 61550c6c156c ("arm64: dts: qcom: Add msm8939 SoC") Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250915-msm8916-resets-v1-2-a5c705df0c45@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16arm64: dts: qcom: msm8916: Add missing MDSS resetStephan Gerhold
On most MSM8916 devices (aside from the DragonBoard 410c), the bootloader already initializes the display to show the boot splash screen. In this situation, MDSS is already configured and left running when starting Linux. To avoid side effects from the bootloader configuration, the MDSS reset can be specified in the device tree to start again with a clean hardware state. The reset for MDSS is currently missing in msm8916.dtsi, which causes errors when the MDSS driver tries to re-initialize the registers: dsi_err_worker: status=6 dsi_err_worker: status=6 dsi_err_worker: status=6 ... It turns out that we have always indirectly worked around this by building the MDSS driver as a module. Before v6.17, the power domain was temporarily turned off until the module was loaded, long enough to clear the register contents. In v6.17, power domains are not turned off during boot until sync_state() happens, so this is no longer working. Even before v6.17 this resulted in broken behavior, but notably only when the MDSS driver was built-in instead of a module. Cc: stable@vger.kernel.org Fixes: 305410ffd1b2 ("arm64: dts: msm8916: Add display support") Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250915-msm8916-resets-v1-1-a5c705df0c45@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16arm64: dts: qcom: sm8150: Fix reg base of frame@17c27000Alok Tiwari
The frame@17c27000 node uses the wrong base address 0x17c26000. This does not match the node name. Update the reg property to use the correct base address 0x17c27000, which matches the node name and avoids the overlap. Fixes: e13c6d144fa0 ("arm64: dts: qcom: sm8150: Add base dts file") Signed-off-by: Alok Tiwari <alok.a.tiwari@oracle.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250915200132.774377-1-alok.a.tiwari@oracle.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16arm64: dts: qcom: qcm6490: Introduce the Particle TachyonBjorn Andersson
The Particle Tachyon is a single board computer with 5G connectivity with AI accelerator, based on the Qualcomm QCM6490 platform. Introduce the board, with support for UFS, USB, USB Type-C PD and altmode (DisplayPort), GPU, charger/battery status, PCIe shield, SD-card, and remoteprocs. Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250915-tachyon-v2-3-4f8b02a17512@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16dt-bindings: arm: qcom: Add Particle TachyonBjorn Andersson
The Particle Tachyon is a single board computer with 5G connectivity with AI accelerator, based on the Qualcomm QCM6490 platform. Document the top-level compatible for this board. Acked-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250915-tachyon-v2-2-4f8b02a17512@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16dt-bindings: vendor-prefixes: Add Particle IndustriesBjorn Andersson
Particle is a San Francisco-based company providing an integrated IoT Platform-as-a-Service. https://www.particle.io/ Acked-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250915-tachyon-v2-1-4f8b02a17512@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16dt-bindings: leds: Unify 'leds' propertyAleksandrs Vinarskis
A number of existing schemas use 'leds' property to provide phandle-array of LED(s) to the consumer. Additionally, with the upcoming privacy-led support in device-tree, v4l2 subnode could be a LED consumer, meaning that all camera sensors should support 'leds' and 'led-names' property via common 'video-interface-devices.yaml'. To avoid duplication, unify 'leds' property from existing schemas to newly introduced 'led-consumer.yaml'. Signed-off-by: Aleksandrs Vinarskis <alex@vinarskis.com> Reviewed-by: "Rob Herring (Arm)" <robh@kernel.org> Link: https://lore.kernel.org/r/20250910-leds-v5-2-bb90a0f897d5@vinarskis.com Signed-off-by: Lee Jones <lee@kernel.org>
2025-09-16dt-bindings: leds: Add generic LED consumer documentationAleksandrs Vinarskis
Introduce common generic led consumer binding, where consumer defines led(s) by phandle, as opposed to trigger-source binding where the trigger source is defined in led itself. Add already used in some schemas 'leds' parameter which expects phandle-array. Additionally, introduce 'led-names' which could be used by consumers to map LED devices to their respective functions. Signed-off-by: Aleksandrs Vinarskis <alex@vinarskis.com> Reviewed-by: "Rob Herring (Arm)" <robh@kernel.org> Link: https://lore.kernel.org/r/20250910-leds-v5-1-bb90a0f897d5@vinarskis.com Signed-off-by: Lee Jones <lee@kernel.org>
2025-09-16arm64: dts: qcom: lemans-evk: Enable 2.5G Ethernet interfaceMohd Ayaan Anwar
Enable the QCA8081 2.5G Ethernet PHY on port 0. Add MDC and MDIO pin functions for ethernet0, and enable the internal SGMII/SerDes PHY node. Additionally, support fetching the MAC address from EEPROM via an nvmem cell. Signed-off-by: Mohd Ayaan Anwar <quic_mohdayaa@quicinc.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Wasim Nazir <wasim.nazir@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250916-lemans-evk-bu-v5-10-53d7d206669d@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16arm64: dts: qcom: lemans-evk: Enable SDHCI for SD CardMonish Chunara
Enable the SD Host Controller Interface (SDHCI) on the lemans EVK board to support SD card for storage. Also add the corresponding regulators. Signed-off-by: Monish Chunara <quic_mchunara@quicinc.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Wasim Nazir <wasim.nazir@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250916-lemans-evk-bu-v5-9-53d7d206669d@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16arm64: dts: qcom: lemans-evk: Enable first USB controller in device modeKrishna Kurapati
Enable the first USB controller in device mode on the Lemans EVK board and configure the associated LDO regulators to power the PHYs accordingly. The USB port is a Type-C port controlled by HD3SS3320 port controller. The role switch notifications would need to be routed to glue driver by adding an appropriate usb-c-connector node in DT. However in the design, the vbus supply that is to be provided to connected peripherals when port is configured as an DFP, is controlled by a GPIO. There is also one ID line going from Port controller chip to GPIO-50 of the SoC. As per the datasheet of HD3SS3320: "Upon detecting a UFP device, HD3SS3220 will keep ID pin high if VBUS is not at VSafe0V. Once VBUS is at VSafe0V, the HD3SS3220 will assert ID pin low. This is done to enforce Type-C requirement that VBUS must be at VSafe0V before re-enabling VBUS." The current HD3SS3220 driver doesn't have this functionality present. So, putting the first USB controller in device mode for now. Once the vbus control based on ID pin is implemented in hd3ss3220.c, the usb-c-connector will be implemented and dr mode would be made OTG. Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Wasim Nazir <wasim.nazir@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250916-lemans-evk-bu-v5-8-53d7d206669d@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16arm64: dts: qcom: lemans-evk: Enable Iris video codec supportVikash Garodia
Enable the Iris video codec accelerator on the Lemans EVK board and reference the appropriate firmware required for its operation. This allows hardware-accelerated video encoding and decoding using the Iris codec engine. Signed-off-by: Vikash Garodia <quic_vgarodia@quicinc.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Wasim Nazir <wasim.nazir@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250916-lemans-evk-bu-v5-7-53d7d206669d@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16arm64: dts: qcom: lemans-evk: Enable remoteproc subsystemsWasim Nazir
Enable remoteproc subsystems for supported DSPs such as Audio DSP, Compute DSP-0/1 and Generic DSP-0/1, along with their corresponding firmware. Signed-off-by: Wasim Nazir <wasim.nazir@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250916-lemans-evk-bu-v5-6-53d7d206669d@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16arm64: dts: qcom: lemans-evk: Enable PCIe supportSushrut Shree Trivedi
Enable PCIe0 and PCIe1 along with the respective phy-nodes. PCIe0 is routed to an m.2 E key connector on the mainboard for wifi attaches while PCIe1 routes to a standard PCIe x4 expansion slot. Signed-off-by: Sushrut Shree Trivedi <quic_sushruts@quicinc.com> Signed-off-by: Wasim Nazir <wasim.nazir@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250916-lemans-evk-bu-v5-5-53d7d206669d@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16arm64: dts: qcom: lemans-evk: Add EEPROM and nvmem layoutMonish Chunara
Integrate the GT24C256C EEPROM via I2C to enable access to board-specific non-volatile data. Also, define an nvmem-layout to expose structured regions within the EEPROM, allowing consumers to retrieve configuration data such as Ethernet MAC addresses via the nvmem subsystem. Signed-off-by: Monish Chunara <quic_mchunara@quicinc.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Signed-off-by: Wasim Nazir <wasim.nazir@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250916-lemans-evk-bu-v5-4-53d7d206669d@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16arm64: dts: qcom: lemans-evk: Add TCA9534 I/O expanderNirmesh Kumar Singh
Integrate the TCA9534 I/O expander via I2C to provide 8 additional GPIO lines for extended I/O functionality. Signed-off-by: Nirmesh Kumar Singh <quic_nkumarsi@quicinc.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Signed-off-by: Wasim Nazir <wasim.nazir@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250916-lemans-evk-bu-v5-3-53d7d206669d@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16arm64: dts: qcom: lemans-evk: Enable GPI DMA and QUPv3 controllersViken Dadhaniya
Enable GPI DMA controllers (gpi_dma0, gpi_dma1, gpi_dma2) and QUPv3 interfaces (qupv3_id_0, qupv3_id_2) in the device tree to support DMA and peripheral communication on the Lemans EVK platform. qupv3_id_0 provides access to I2C/SPI/UART instances 0-5. qupv3_id_2 provides access to I2C/SPI/UART instances 14-20. Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com> Signed-off-by: Wasim Nazir <wasim.nazir@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250916-lemans-evk-bu-v5-2-53d7d206669d@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16arm64: dts: qcom: lemans: Add SDHC controller and SDC pin configurationMonish Chunara
Introduce the SDHC v5 controller node for the Lemans platform. This controller supports either eMMC or SD-card, but only one can be active at a time. SD-card is the preferred configuration on Lemans targets, so describe this controller. Define the SDC interface pins including clk, cmd, and data lines to enable proper communication with the SDHC controller. Signed-off-by: Monish Chunara <quic_mchunara@quicinc.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Co-developed-by: Wasim Nazir <wasim.nazir@oss.qualcomm.com> Signed-off-by: Wasim Nazir <wasim.nazir@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250916-lemans-evk-bu-v5-1-53d7d206669d@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-16kunit: Extend kconfig help text for KUNIT_UML_PCIThomas Weißschuh
Checkpatch.pl expects at least 4 lines of help text. Extend the help text to make checkpatch.pl happy. Link: https://lore.kernel.org/r/20250916-kunit-pci-kconfig-v1-1-6d1369f06f2a@linutronix.de Fixes: 031cdd3bc3f3 ("kunit: Enable PCI on UML without triggering WARN()") Suggested-by: Shuah Khan <skhan@linuxfoundation.org> Link: https://lore.kernel.org/lkml/3dc95227-2be9-48a0-bdea-3f283d9b2a38@linuxfoundation.org/ Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Reviewed-by: David Gow <davidgow@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2025-09-16rust: kunit: allow `cfg` on `test`sKaibo Ma
The `kunit_test` proc macro only checks for the `test` attribute immediately preceding a `fn`. If the function is disabled via a `cfg`, the generated code would result in a compile error referencing a non-existent function [1]. This collects attributes and specifically cherry-picks `cfg` attributes to be duplicated inside KUnit wrapper functions such that a test function disabled via `cfg` compiles and is marked as skipped in KUnit correctly. Link: https://lore.kernel.org/r/20250916021259.115578-1-ent3rm4n@gmail.com Link: https://lore.kernel.org/rust-for-linux/CANiq72==48=69hYiDo1321pCzgn_n1_jg=ez5UYXX91c+g5JVQ@mail.gmail.com/ [1] Closes: https://github.com/Rust-for-Linux/linux/issues/1185 Suggested-by: Miguel Ojeda <ojeda@kernel.org> Suggested-by: David Gow <davidgow@google.com> Signed-off-by: Kaibo Ma <ent3rm4n@gmail.com> Reviewed-by: David Gow <davidgow@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2025-09-16MAINTAINERS: Add entry on MAX7360 driverMathieu Dubois-Briand
Add myself as maintainer of Maxim MAX7360 driver and device-tree bindings. Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Link: https://lore.kernel.org/r/20250824-mdb-max7360-support-v14-10-435cfda2b1ea@bootlin.com Signed-off-by: Lee Jones <lee@kernel.org>
generated by cgit v1.3 (git 2.53.0) at 2026-11-13 07:27:08 +0000