summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2025-09-25ACPI: support BGRT table on RISC-VHeinrich Schuchardt
The BGRT table is used to display a vendor logo in the boot process. There is no good reason why RISC-V should not support it. Remove the architecture constraint. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Acked-by: Rafael J. Wysocki <rafael@kernel.org> Reviewed-by: Sunil V L <sunilvl@ventanamicro.com> Link: https://lore.kernel.org/r/20250729131535.522205-3-heinrich.schuchardt@canonical.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2025-09-25irqchip/riscv-rpmi-sysmsi: Add ACPI supportSunil V L
Add ACPI support for the RISC-V RPMI system MSI based irqchip driver. Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Signed-off-by: Anup Patel <apatel@ventanamicro.com> Acked-by: Jassi Brar <jassisinghbrar@gmail.com> Link: https://lore.kernel.org/r/20250818040920.272664-23-apatel@ventanamicro.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2025-09-25mailbox/riscv-sbi-mpxy: Add ACPI supportSunil V L
Add ACPI support for the RISC-V SBI message proxy (MPXY) based mailbox driver. Acked-by: Jassi Brar <jassisinghbrar@gmail.com> Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Signed-off-by: Anup Patel <apatel@ventanamicro.com> Link: https://lore.kernel.org/r/20250818040920.272664-22-apatel@ventanamicro.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2025-09-25irqchip/irq-riscv-imsic-early: Export imsic_acpi_get_fwnode()Sunil V L
ACPI based loadable drivers which need MSIs will also need imsic_acpi_get_fwnode() to update the device MSI domain so export this function. Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Signed-off-by: Anup Patel <apatel@ventanamicro.com> Link: https://lore.kernel.org/r/20250818040920.272664-21-apatel@ventanamicro.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2025-09-25ACPI: RISC-V: Add RPMI System MSI to GSI mappingSunil V L
The RPMI System MSI device will provide GSIs to downstream devices (such as GED) so add it to the RISC-V GSI to fwnode mapping. Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Signed-off-by: Anup Patel <apatel@ventanamicro.com> Acked-by: Jassi Brar <jassisinghbrar@gmail.com> Link: https://lore.kernel.org/r/20250818040920.272664-20-apatel@ventanamicro.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2025-09-25ACPI: RISC-V: Add support to update gsi rangeSunil V L
Some RISC-V interrupt controllers like RPMI based system MSI interrupt controllers do not have MADT entry defined. These interrupt controllers exist only in the namespace. ACPI spec defines _GSB method to get the GSI base of the interrupt controller, However, there is no such standard method to get the GSI range. To support such interrupt controllers, set the GSI range of such interrupt controllers to non-overlapping range and provide API for interrupt controller driver to update it with proper value. Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Signed-off-by: Anup Patel <apatel@ventanamicro.com> Acked-by: Jassi Brar <jassisinghbrar@gmail.com> Link: https://lore.kernel.org/r/20250818040920.272664-19-apatel@ventanamicro.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2025-09-25ACPI: RISC-V: Create interrupt controller list in sorted orderSunil V L
Currently, the interrupt controller list is created without any order. Create the list sorted with the GSI base of the interrupt controllers. Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Signed-off-by: Anup Patel <apatel@ventanamicro.com> Acked-by: Jassi Brar <jassisinghbrar@gmail.com> Link: https://lore.kernel.org/r/20250818040920.272664-18-apatel@ventanamicro.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2025-09-25ACPI: scan: Update honor list for RPMI System MSISunil V L
The RPMI System MSI interrupt controller (just like PLIC and APLIC) needs to probed prior to devices like GED which use interrupts provided by it. Also, it has dependency on the SBI MPXY mailbox device. Add HIDs of RPMI System MSI and SBI MPXY mailbox devices to the honor list so that those dependencies are handled. Reviewed-by: Atish Patra <atishp@rivosinc.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Signed-off-by: Anup Patel <apatel@ventanamicro.com> Acked-by: Jassi Brar <jassisinghbrar@gmail.com> Link: https://lore.kernel.org/r/20250818040920.272664-17-apatel@ventanamicro.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2025-09-25ACPI: Add support for nargs_prop in acpi_fwnode_get_reference_args()Sunil V L
Currently, ACPI does not support the use of a nargs_prop (e.g., associated with a reference in fwnode_property_get_reference_args(). Instead, ACPI expects the number of arguments (nargs) to be explicitly passed or known. This behavior diverges from Open Firmware (OF), which allows the use of a #*-cells property in the referenced node to determine the number of arguments. Since fwnode_property_get_reference_args() is a common interface used across both OF and ACPI firmware paradigms, it is desirable to have a unified calling convention that works seamlessly for both. Add the support for ACPI to parse a nargs_prop from the referenced fwnode, aligning its behavior with the OF backend. This allows drivers and subsystems using fwnode_property_get_reference_args() to work in a firmware-agnostic way without having to hardcode or special-case argument counts for ACPI. Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Signed-off-by: Anup Patel <apatel@ventanamicro.com> Acked-by: Jassi Brar <jassisinghbrar@gmail.com> Link: https://lore.kernel.org/r/20250818040920.272664-16-apatel@ventanamicro.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2025-09-25PCI: rcar-host: Convert struct rcar_msi mask_lock into raw spinlockMarek Vasut
The rcar_msi_irq_unmask() function may be called from a PCI driver request_threaded_irq() function. This triggers kernel/irq/manage.c __setup_irq() which locks raw spinlock &desc->lock descriptor lock and with that descriptor lock held, calls rcar_msi_irq_unmask(). Since the &desc->lock descriptor lock is a raw spinlock, and the rcar_msi .mask_lock is not a raw spinlock, this setup triggers 'BUG: Invalid wait context' with CONFIG_PROVE_RAW_LOCK_NESTING=y. Use scoped_guard() to simplify the locking. Fixes: 83ed8d4fa656 ("PCI: rcar: Convert to MSI domains") Reported-by: Duy Nguyen <duy.nguyen.rh@renesas.com> Reported-by: Thuan Nguyen <thuan.nguyen-hong@banvien.com.vn> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Marc Zyngier <maz@kernel.org> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20250909162707.13927-2-marek.vasut+renesas@mailbox.org
2025-09-25PCI: tegra194: Rename 'root_bus' to 'root_port_bus' in ↵Manivannan Sadhasivam
tegra_pcie_downstream_dev_to_D0() In tegra_pcie_downstream_dev_to_D0(), PCI devices are transitioned to D0 state. For iterating over the devices, first the downstream bus of the Root Port is searched from the root bus. But the name of the variable that holds the Root Port downstream bus is named as 'root_bus', which is wrong. Rename the variable to 'root_port_bus'. Also, move the comment on 'bringing the devices to D0' to where the state is set exactly. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20250922081057.15209-1-mani@kernel.org
2025-09-25PCI: tegra: Convert struct tegra_msi mask_lock into raw spinlockMarek Vasut
The tegra_msi_irq_unmask() function may be called from a PCI driver request_threaded_irq() function. This triggers kernel/irq/manage.c __setup_irq() which locks raw spinlock &desc->lock descriptor lock and with that descriptor lock held, calls tegra_msi_irq_unmask(). Since the &desc->lock descriptor lock is a raw spinlock, and the tegra_msi .mask_lock is not a raw spinlock, this setup triggers 'BUG: Invalid wait context' with CONFIG_PROVE_RAW_LOCK_NESTING=y. Use scoped_guard() to simplify the locking. Fixes: 2c99e55f7955 ("PCI: tegra: Convert to MSI domains") Reported-by: Geert Uytterhoeven <geert+renesas@glider.be> Closes: https://patchwork.kernel.org/project/linux-pci/patch/20250909162707.13927-2-marek.vasut+renesas@mailbox.org/#26574451 Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20250922150811.88450-1-marek.vasut+renesas@mailbox.org
2025-09-25PCI: rcar-gen4: Fix inverted break condition in PHY initializationMarek Vasut
R-Car V4H Reference Manual R19UH0186EJ0130 Rev.1.30 Apr. 21, 2025 page 4581 Figure 104.3b Initial Setting of PCIEC(example), third quarter of the figure indicates that register 0xf8 should be polled until bit 18 becomes set to 1. Register 0xf8, bit 18 is 0 immediately after write to PCIERSTCTRL1 and is set to 1 in less than 1 ms afterward. The current readl_poll_timeout() break condition is inverted and returns when register 0xf8, bit 18 is set to 0, which in most cases means immediately. In case CONFIG_DEBUG_LOCK_ALLOC=y, the timing changes just enough for the first readl_poll_timeout() poll to already read register 0xf8, bit 18 as 1 and afterward never read register 0xf8, bit 18 as 0, which leads to timeout and failure to start the PCIe controller. Fix this by inverting the poll condition to match the reference manual initialization sequence. Fixes: faf5a975ee3b ("PCI: rcar-gen4: Add support for R-Car V4H") Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20250915235910.47768-1-marek.vasut+renesas@mailbox.org
2025-09-25PCI: rcar-gen4: Assure reset occurs before DBI accessMarek Vasut
Assure the reset is latched and the core is ready for DBI access. On R-Car V4H, the PCIe reset is asynchronous and does not take effect immediately, but needs a short time to complete. In case DBI access happens in that short time, that access generates an SError. Make sure that condition can never happen, read back the state of the reset, which should turn the asynchronous reset into a synchronous one, and wait a little over 1ms to add additional safety margin. Fixes: 0d0c551011df ("PCI: rcar-gen4: Add R-Car Gen4 PCIe controller support for host mode") Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20250924005610.96484-1-marek.vasut+renesas@mailbox.org
2025-09-25PCI: rcar-gen4: Add missing 1ms delay after PWR reset assertionMarek Vasut
R-Car V4H Reference Manual R19UH0186EJ0130 Rev.1.30 Apr. 21, 2025 page 585 Figure 9.3.2 Software Reset flow (B) indicates that for peripherals in HSC domain, after reset has been asserted by writing a matching reset bit into register SRCR, it is mandatory to wait 1ms. Because it is the controller driver which can determine whether or not the controller is in HSC domain based on its compatible string, add the missing delay in the controller driver. This 1ms delay is documented on R-Car V4H and V4M; it is currently unclear whether S4 is affected as well. This patch does apply the extra delay on R-Car S4 as well. Fixes: 0d0c551011df ("PCI: rcar-gen4: Add R-Car Gen4 PCIe controller support for host mode") Suggested-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> [mani: added the missing r-b tag from Krzysztof] Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Krzysztof Wilczyński <kwilczynski@kernel.org> Link: https://patch.msgid.link/20250919134644.208098-1-marek.vasut+renesas@mailbox.org
2025-09-26drm/i915: i915_pmu: Use sysfs_emit() instead of sprintf()Madhur Kumar
Follow the advice in Documentation/filesystems/sysfs.rst: show() should only use sysfs_emit() or sysfs_emit_at() when formatting the value to be returned to user space. Signed-off-by: Madhur Kumar <madhurkumar004@gmail.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/20250923195051.1277855-1-madhurkumar004@gmail.com
2025-09-26drm/i915/gvt: Improve intel_vgpu_ioctl hdr error handlingJonathan Cavitt
Add error handling for the following VFIO_DEVICE_SET_IRQS cases with respect to the hdr struct: - More than one VFIO_IRQ_DATA_TYPE_MASK flag is set in hdr.flags - More than one VFIO_IRQ_ACTION_TYPE_MASK flag is set in hdr.flags - hdr.count is not specified Note that since hdr.count != 0, data_size != 0 is guaranteed unless vfio_set_irqs_validate_and_prepare fails and returns an error. So, we no longer need to check data_size before running memdup_user because checking the return value of the function is sufficient. v2: Use correct name for mask v3: Use is_power_of_2 over hweight32 as it's more efficient (Andi) Signed-off-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Cc: Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by: Zhenyu Wang <zhenyuw.linux@gmail.com> Reviewed-by: Krzysztof Karas <krzysztof.karas@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/20250923212332.112137-2-jonathan.cavitt@intel.com
2025-09-25i2c: busses: Fix some spelling errorsXichao Zhao
Fix spelling errors in some comments. Signed-off-by: Xichao Zhao <zhao.xichao@vivo.com> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2025-09-25i2c: mux: Simplify boolean assignment in i2c_mux_allocI Viswanath
Refactor boolean field assignments of the form `if (a) b = true` to `b = !!(a)` in i2c_mux_alloc. Signed-off-by: I Viswanath <viswanathiyyappan@gmail.com> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2025-09-25i2c: designware: use dev_err_probe() when probing platform deviceBenoît Monin
Add calls to dev_err_probe() on error paths that can return -EPROBE_DEFER when probing platform device. Namely when requesting the reset controller, when probing for lock support and when requesting the clocks. PCI device probing already use dev_err_probe(). Signed-off-by: Benoît Monin <benoit.monin@bootlin.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2025-09-25i2c: designware: convert to dev_err_probe() on request IRQ errorBenoît Monin
Simplify the error handling of devm_request_irq() in i2c_dw_probe_master() and i2c_dw_probe_slave() by converting to: return dev_err_probe(); instead of calling: dev_err(); return ret; This also handle deferred probe error without spamming the log. Signed-off-by: Benoît Monin <benoit.monin@bootlin.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2025-09-25i2c: spacemit: ensure SDA is released after bus resetTroy Mitchell
After performing a conditional bus reset, the controller must ensure that the SDA line is actually released. Previously, the reset routine only performed a single check, which could leave the bus in a locked state in some situations. This patch introduces a loop that toggles the reset cycle and issues a reset request up to SPACEMIT_BUS_RESET_CLK_CNT_MAX times, checking SDA after each attempt. If SDA is released before the maximum count, the function returns early. Otherwise, a warning is emitted. This change improves bus recovery reliability. Fixes: 5ea558473fa31 ("i2c: spacemit: add support for SpacemiT K1 SoC") Signed-off-by: Troy Mitchell <troy.mitchell@linux.spacemit.com> Reviewed-by: Aurelien Jarno <aurelien@aurel32.net> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2025-09-25i2c: spacemit: check SDA instead of SCL after bus resetTroy Mitchell
After calling spacemit_i2c_conditionally_reset_bus(), the controller should ensure that the SDA line is release before proceeding. Previously, the driver checked the SCL line instead, which does not guarantee that the bus is truly idle. This patch changes the check to verify SDA. This ensures proper bus recovery and avoids potential communication errors after a conditional reset. Fixes: 5ea558473fa31 ("i2c: spacemit: add support for SpacemiT K1 SoC") Reviewed-by: Aurelien Jarno <aurelien@aurel32.net> Signed-off-by: Troy Mitchell <troy.mitchell@linux.spacemit.com> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2025-09-25i2c: spacemit: disable SDA glitch fix to avoid restart delayTroy Mitchell
The K1 I2C controller has an SDA glitch fix that introduces a small delay on restart signals. While this feature can suppress glitches on SDA when SCL = 0, it also delays the restart signal, which may cause unexpected behavior in some transfers. The glitch itself does not affect normal I2C operation, because the I2C specification allows SDA to change while SCL is low. To ensure correct transmission for every message, we disable the SDA glitch fix by setting the RCR.SDA_GLITCH_NOFIX bit during initialization. This guarantees that restarts are issued promptly without unintended delays. Fixes: 5ea558473fa31 ("i2c: spacemit: add support for SpacemiT K1 SoC") Reviewed-by: Aurelien Jarno <aurelien@aurel32.net> Signed-off-by: Troy Mitchell <troy.mitchell@linux.spacemit.com> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2025-09-25ACPI: property: Refactor acpi_fwnode_get_reference_args() to support nargs_propSunil V L
Currently, acpi_fwnode_get_reference_args() delegates to the internal function __acpi_node_get_property_reference() to retrieve property references. However, this function does not handle the nargs_prop (cells property) parameter, and instead expects the number of arguments (nargs) to be known or hardcoded. As a result, when fwnode_property_get_reference_args() is used with a valid nargs_prop, the ACPI backend ignores it, whereas the Device Tree (DT) backend uses the #*-cells property from the reference node to determine the number of arguments dynamically. To support the nargs_prop in ACPI, refactor the code as follows: - Move the implementation from __acpi_node_get_property_reference() into acpi_fwnode_get_reference_args(). - Update __acpi_node_get_property_reference() to call the (now updated) acpi_fwnode_get_reference_args() passing NULL as nargs_prop to keep the behavior of __acpi_node_get_property_reference() intact. Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Signed-off-by: Anup Patel <apatel@ventanamicro.com> Acked-by: Jassi Brar <jassisinghbrar@gmail.com> Link: https://lore.kernel.org/r/20250818040920.272664-15-apatel@ventanamicro.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2025-09-25PCI: Set up bridge resources earlierIlpo Järvinen
Bridge windows are read twice from PCI Config Space, the first time from pci_read_bridge_windows(), which does not set up the device's resources. This causes problems down the road as child resources of the bridge cannot check whether they reside within the bridge window or not. Set up the bridge windows already in pci_read_bridge_windows(). Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://patch.msgid.link/20250924134228.1663-2-ilpo.jarvinen@linux.intel.com
2025-09-25i2c: spacemit: remove stop function to avoid bus errorTroy Mitchell
Previously, STOP handling was split into two separate steps: 1) clear TB/STOP/START/ACK bits 2) issue STOP by calling spacemit_i2c_stop() This left a small window where the control register was updated twice, which can confuse the controller. While this race has not been observed with interrupt-driven transfers, it reliably causes bus errors in PIO mode. Inline the STOP sequence into the IRQ handler and ensure that control register bits are updated atomically in a single writel(). Fixes: 5ea558473fa31 ("i2c: spacemit: add support for SpacemiT K1 SoC") Signed-off-by: Troy Mitchell <troy.mitchell@linux.spacemit.com> Reviewed-by: Aurelien Jarno <aurelien@aurel32.net> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2025-09-25i2c: spacemit: ensure bus release check runs when wait_bus_idle() failsTroy Mitchell
spacemit_i2c_wait_bus_idle() only returns 0 on success or a negative error code on failure. Since 'ret' can never be positive, the final 'else' branch was unreachable, and spacemit_i2c_check_bus_release() was never called. This commit guarantees we attempt to release the bus whenever waiting for an idle bus fails. Fixes: 5ea558473fa31 ("i2c: spacemit: add support for SpacemiT K1 SoC") Reviewed-by: Aurelien Jarno <aurelien@aurel32.net> Signed-off-by: Troy Mitchell <troy.mitchell@linux.spacemit.com> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2025-09-25i2c: mediatek: fix potential incorrect use of I2C_MASTER_WRRDLeilk.Liu
The old IC does not support the I2C_MASTER_WRRD (write-then-read) function, but the current code’s handling of i2c->auto_restart may potentially lead to entering the I2C_MASTER_WRRD software flow, resulting in unexpected bugs. Instead of repurposing the auto_restart flag, add a separate flag to signal I2C_MASTER_WRRD operations. Also fix handling of msgs. If the operation (i2c->op) is I2C_MASTER_WRRD, then the msgs pointer is incremented by 2. For all other operations, msgs is simply incremented by 1. Fixes: b2ed11e224a2 ("I2C: mediatek: Add driver for MediaTek MT8173 I2C controller") Signed-off-by: Leilk.Liu <leilk.liu@mediatek.com> Suggested-by: Chen-Yu Tsai <wenst@chromium.org> Reviewed-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2025-09-25i2c: boardinfo: Annotate code used in init phase onlyHeiner Kallweit
Annotate two places in boardinfo code: - __i2c_first_dynamic_bus_num is set in init phase. Annotate it as __ro_after_init to prevent later changes. - i2c_register_board_info() is used in init phase only, so annotate it as __init, allowing to free the memory after init phase. This is safe, see comment: "done in board-specific init code near arch_initcall() time" Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2025-09-25Merge branch 'i2c/immutable/scoped_fwnode_child' into i2c/for-mergewindowWolfram Sang
2025-09-25irqchip: Add driver for the RPMI system MSI service groupAnup Patel
The RPMI specification defines a system MSI service group which allows application processors to receive MSIs upon system events such as graceful shutdown/reboot request, CPU hotplug event, memory hotplug event, etc. Add an irqchip driver for the RISC-V RPMI system MSI service group to directly receive system MSIs in Linux kernel. Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Anup Patel <apatel@ventanamicro.com> Link: https://lore.kernel.org/r/20250818040920.272664-14-apatel@ventanamicro.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
2025-09-25thermal/drivers/renesas/rzg3e: Add thermal driver for the Renesas RZ/G3E SoCJohn Madieu
The RZ/G3E SoC integrates a Temperature Sensor Unit (TSU) block designed to monitor the chip's junction temperature. This sensor is connected to channel 1 of the APB port clock/reset and provides temperature measurements. It also requires calibration values stored in the system controller registers for accurate temperature measurement. Add a driver for the Renesas RZ/G3E TSU. [ dlezcano: Fixed conflict with "renesas: Add support for RZ/G3S" ] Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://lore.kernel.org/r/20250917170202.197929-3-john.madieu.xa@bp.renesas.com Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2025-09-25thermal/drivers/thermal-generic-adc: Add temperature sensor channelSvyatoslav Ryhel
To avoid duplicating sensor functionality and conversion tables, this design allows converting an ADC IIO channel's output directly into a temperature IIO channel. This is particularly useful for devices where hwmon isn't suitable or where temperature data must be accessible through IIO. One such device is, for example, the MAX17040 fuel gauge. Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Link: https://lore.kernel.org/r/20250903162749.109910-2-clamor95@gmail.com Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2025-09-25thermal/drivers/rockchip: Shut up GRF warningSebastian Reichel
Most of the recent Rockchip devices do not have a GRF associated with the tsadc IP. Let's avoid printing a warning on those devices. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Reviewed-by: Dragan Simic <dsimic@manjaro.org> Tested-by: Diederik de Haas <didi.debian@cknow.org> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20250820-thermal-rockchip-grf-warning-v2-2-c7e2d35017b8@kernel.org Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2025-09-25thermal/drivers/rockchip: Unify struct rockchip_tsadc_chip formatSebastian Reichel
Unify all chip descriptions to the version without any empty lines. Suggested-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Reviewed-by: Dragan Simic <dsimic@manjaro.org> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20250820-thermal-rockchip-grf-warning-v2-1-c7e2d35017b8@kernel.org Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2025-09-25thermal/drivers/renesas/rzg3s: Add thermal driver for the Renesas RZ/G3S SoCClaudiu Beznea
The Renesas RZ/G3S SoC features a Thermal Sensor Unit (TSU) that reports the junction temperature. The temperature is reported through a dedicated ADC channel. Add a driver for the Renesas RZ/G3S TSU. Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://lore.kernel.org/r/20250810122125.792966-3-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2025-09-25thermal/drivers/k3_j72xx_bandgap: Register sensors with hwmonMichael Walle
Make the sensors available in the hwmon subsystem (if CONFIG_THERMAL_HWMON is enabled). Signed-off-by: Michael Walle <mwalle@kernel.org> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Link: https://lore.kernel.org/r/20250828124042.1680853-1-mwalle@kernel.org Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2025-09-25thermal/drivers/rcar_gen3: Fix mapping SoCs to generic Gen4 entryWolfram Sang
S4 was added first so it was assumed to be the blueprint for R-Car Gen4. It turned out now, that S4 is a special mix between Gen3 and Gen4. V4H and V4M are the similar ones as confirmed by HW engineers. So, rename the S4 entry to be specific instead of generic. Rename the V4H entry to be the new generic one, so V4M will use it as well now. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20250911070254.2214-2-wsa+renesas@sang-engineering.com Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2025-09-25thermal/drivers/tegra: Add Tegra114 specific SOCTHERM driverSvyatoslav Ryhel
Add Tegra114 specific SOCTHERM driver. Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com> Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com> Link: https://lore.kernel.org/r/20250828055104.8073-6-clamor95@gmail.com Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2025-09-25thermal/drivers/tegra/soctherm-fuse: Prepare calibration for Tegra114 supportSvyatoslav Ryhel
The Tegra114 has a different fuse calibration register layout and address compared to other Tegra SoCs, requiring SOCTHERM shift, mask, register address, and nominal tf calibration value to be configurable. Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com> Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com> Link: https://lore.kernel.org/r/20250828055104.8073-4-clamor95@gmail.com Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2025-09-25thermal/drivers/rcar_gen3: Document Gen4 support in Kconfig entryMarek Vasut
The R-Car Gen3 thermal driver supports both R-Car Gen3 and Gen4 SoCs. Update the Kconfig entry. Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Link: https://lore.kernel.org/r/20250905193322.148115-1-marek.vasut+renesas@mailbox.org Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2025-09-25thermal/drivers/rcar_gen3: Fix comment typoMarek Vasut
Fix typo to millidegree Celsius. This aligns the comment with another comment later on the same function. No functional change. Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Link: https://lore.kernel.org/r/20250907154148.171496-1-marek.vasut+renesas@mailbox.org Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2025-09-25drivers/thermal/qcom/lmh: Fix incorrect error messageSumeet Pawnikar
It was showing wrong error message as ARM threshold thremal trip for setting LOW threshold thermal trip. Fix this incorrect error message for setting LOW threshold thermal trip. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Sumeet Pawnikar <sumeet4linux@gmail.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20250710175426.5789-1-sumeet4linux@gmail.com
2025-09-25thermal/drivers/qcom/lmh: Add missing IRQ includesDmitry Baryshkov
As reported by LKP, the Qualcomm LMH driver needs to include several IRQ-related headers, which decrlare necessary IRQ functionality. Currently driver builds on ARM64 platforms, where the headers are pulled in implicitly by other headers, but fails to build on other platforms. Fixes: 53bca371cdf7 ("thermal/drivers/qcom: Add support for LMh driver") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202507270042.KdK0KKht-lkp@intel.com/ Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20250728-lmh-scm-v2-2-33bc58388ca5@oss.qualcomm.com
2025-09-25thermal/drivers/qcom: Make LMH select QCOM_SCMDmitry Baryshkov
The QCOM_SCM symbol is not user-visible, so it makes little sense to depend on it. Make LMH driver select QCOM_SCM as all other drivers do and, as the dependecy is now correctly handled, enable || COMPILE_TEST in order to include the driver into broader set of build tests. Fixes: 9e5a4fb84230 ("thermal/drivers/qcom/lmh: make QCOM_LMH depends on QCOM_SCM") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20250728-lmh-scm-v2-1-33bc58388ca5@oss.qualcomm.com
2025-09-25thermal/drivers/mediatek/lvts_thermal: Remove unneeded semicolonJiapeng Chong
./drivers/thermal/mediatek/lvts_thermal.c:642:2-3: Unneeded semicolon. A semicolon is present after the closing bracket of the loop, let's remove it. No functional change intended. [ dlezcano : Reworded the description and reordered the tags order ] Reported-by: Abaci Robot <abaci@linux.alibaba.com> Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=23244 Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20250801063540.2959610-1-jiapeng.chong@linux.alibaba.com
2025-09-25thermal/drivers/rcar_gen3: Add support for R-Car V4H default trim valuesMarek Vasut
Add default trimming values for the four temperature sensors located in Renesas R-Car V4H Working Sample SoC. The trimming values are identical for all four THS temperature sensors. Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Link: https://lore.kernel.org/r/20250625181739.28391-2-marek.vasut+renesas@mailbox.org
2025-09-25thermal/drivers/rcar_gen3: Add support for per-SoC default trim valuesMarek Vasut
The Working Sample R-Car SoCs may not yet have thermal sensor trimming values programmed into fuses, those fuses are blank instead. For such SoCs, the driver includes fallback trimming values. Those values are currently applied to all SoCs which use this driver. Introduce support for per-SoC fallback trimming values in preparation for SoCs which do not use these current trimming values. No functional change is intended here. Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Link: https://lore.kernel.org/r/20250625181739.28391-1-marek.vasut+renesas@mailbox.org
2025-09-25drm/amd: Add name to modes from amdgpu_connector_add_common_modes()Mario Limonciello
[Why] When DC adds common modes it adds modes with a string to match what they are. Non-DC doesn't. This can be inconsistent when turning on/off DC support. [How] Add a name member to common_modes[] and copy it into the drm display mode. Cc: Timur Kristóf <timur.kristof@gmail.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Timur Kristóf <timur.kristof@gmail.com> Link: https://lore.kernel.org/r/20250924161624.1975819-6-mario.limonciello@amd.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>