summaryrefslogtreecommitdiff
path: root/drivers/soc
AgeCommit message (Collapse)Author
2026-10-03soc: samsung: exynos-pmu: fix error paths in cpuhotplug/idle states setupAlexey Klimov
The setup_cpuhp_and_cpuidle() initialisation sequence currently ignores the return values of cpuhp_setup_state(), cpu_pm_register_notifier(), and register_reboot_notifier(). If any of these registrations fail during probe() routine, the driver returns 0, leaving the driver partially configured. Furthermore, if anything after setup_cpuhp_and_cpuidle() fails in probe() routine, for instance devm_mfd_add_devices(), the probe() lacks an error path and leaves notifiers and cpu hotplug states registered. Introduce variables for the cpu hotplug state IDs in exynos_pmu_context struct, that should be initialised to CPUHP_INVALID by default. Check all return codes in setup_cpuhp_and_cpuidle(), and add an error path to remove registered states on failure. Finally, add destroy_cpuhp_and_cpuidle() helper to safely tear down notifiers and cpu hotplug states. Reported-by: Sashiko <sashiko-bot@kernel.org> Closes: https://sashiko.dev/#/patchset/20260513-exynos850-cpuhotplug-v4-0-54fec5f65362@linaro.org?part=3 Fixes: 78b72897a5c8 ("soc: samsung: exynos-pmu: Enable CPU Idle for gs101") Cc: stable@vger.kernel.org Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org> Link: https://patch.msgid.link/20260930-exynos-pmu-cpuhp-idle-fixes-v3-1-4269d8425978@linaro.org Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2026-10-03soc/tegra: flowctrl: Release OF node reference on errorYuho Choi
tegra_flowctrl_init() obtains a reference from of_find_matching_node() and currently releases it only after of_address_to_resource() succeeds. Release the reference before checking the resource conversion result so the error path is balanced as well. Fixes: 1fd09e5d884a ("soc/tegra: Add initial flowctrl support for Tegra132/210") Signed-off-by: Yuho Choi <dbgh9129@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2026-10-03soc/tegra: pmc: Make sure clk_init_data is fully initializedGeert Uytterhoeven
The clk_init_data structure contains several mutually-exclusive members for different methods to specify the possible parents of a clock, prompting drivers to initialize only the members they need. However, not initializing all members may cause subtle issues, which are only exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is enabled. Make sure all members are fully initialized, to avoid such bugs, and to prevent future breakage when converting drivers to a different method for specifying the parents. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Brian Masney <bmasney@redhat.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2026-10-03soc/tegra: fuse: speedo-tegra210: Support revision B01Aaron Kling
Tegra210B01 has a separate set of skus and speedo tables Based-on: https://gitlab.com/nvidia/nv-tegra/linux-5.10/-/commit/8555ef4988d3b39d91791794825c354b3c9377ba Based-on-patch-by: Alex Frid <afrid@nvidia.com> Signed-off-by: Aaron Kling <webgeek1234@gmail.com> Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2026-10-03soc/tegra: fuse: Support revision B01Aaron Kling
Previously, all supported SoCs only used the A major revision. The Tegra210B01 SoC incremented the major revision. Add support for this. Signed-off-by: Aaron Kling <webgeek1234@gmail.com> Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2026-10-03soc/tegra: pmc: Add Tegra210B01 supportAlexandre Hamamdjian
The PMC in Tegra210B01 is very similar to the one in the original Tegra210, but has a few powergate differences. Specifically sata and ve2 are removed. Signed-off-by: Alexandre Hamamdjian <azkali.limited@gmail.com> Co-developed-by: Thomas Makin <halorocker89@gmail.com> Signed-off-by: Thomas Makin <halorocker89@gmail.com> Co-developed-by: Aaron Kling <webgeek1234@gmail.com> Signed-off-by: Aaron Kling <webgeek1234@gmail.com> Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2026-10-03soc/tegra: cbb: Fix loggger -> logger typoThierry Reding
Found using codespell. Signed-off-by: Thierry Reding <treding@nvidia.com>
2026-10-02soc: starfive: Add socinfo driver for JHB100 SoCChanghuang Liang
Add a socinfo driver for the JHB100 SoC, exposing the SoC family, ID and revision through the SoC bus. It is currently used to distinguish the two revisions, A0 and A1. The driver binds to the sys0 system controller node. That region only contains the PLL controls, this revision ID register and a few debug registers, so rather than describing an extra child node in the devicetree, the sys0 PLL device is instantiated from here as an MFD cell. The PLL driver then picks up the regmap from its parent's DT node. Note that CONFIG_STARFIVE_JHB100_SOCINFO is therefore a build-time prerequisite for the sys0 PLL clocks; see CLK_STARFIVE_JHB100_PLL. Signed-off-by: Changhuang Liang <changhuang.liang@starfivetech.com> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
2026-10-02soc: amlogic: clk-measure: Optimize CLK_MSR_ID to reduce memory usageChuan Liu
The original CLK_MSR_ID macro uses __id as the designated array index. This can waste memory when defining struct meson_msr_id arrays. For example: static const struct meson_msr_id clk_msr_foo[] = { CLK_MSR_ID(255, NULL), }; Although the array contains only one valid entry, it occupies space for 256 elements because the designated initializer forces the array size to match the highest index. The driver does not rely on the array index when accessing measurement IDs. Instead, the measurement ID is obtained from the id field of struct meson_msr_id. Therefore, removing the designated array index from CLK_MSR_ID does not affect the current driver behavior while significantly reducing unnecessary memory usage. Compared with before and after modification, the memory size is reduced by 24.76%: $ scripts/bloat-o-meter pre_meson-clk-measure.o meson-clk-measure.o add/remove: 0/0 grow/shrink: 0/15 up/down: 0/-16224 (-16224) Function old new delta clk_msr_sm1 3072 3048 -24 clk_msr_a1 1488 1272 -216 clk_msr_g12a 2952 2712 -240 clk_msr_gx 1992 1608 -384 clk_msr_m8 1536 1104 -432 clk_msr_a9 6120 5544 -576 clk_msr_t7 5352 4632 -720 clk_msr_axg 2640 1704 -936 clk_msr_s6 5064 3672 -1392 clk_msr_c3 4896 3264 -1632 clk_msr_s7d 4632 2880 -1752 clk_msr_s4 5376 3576 -1800 clk_msr_a4 4488 2544 -1944 clk_msr_s7 4632 2664 -1968 clk_msr_a5 4560 2352 -2208 Total: Before=65527, After=49303, chg -24.76% Signed-off-by: Chuan Liu <chuan.liu@amlogic.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260920-more-socs-to-support-clk_measure-v2-6-224382a429e8@amlogic.com Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
2026-10-02soc: amlogic: clk-measure: Add support for more SoCsChuan Liu
Add clk-measure driver support for Amlogic A5, A4, S7, S7D, S6 and A9 SoCs. Signed-off-by: Chuan Liu <chuan.liu@amlogic.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260920-more-socs-to-support-clk_measure-v2-5-224382a429e8@amlogic.com Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
2026-10-02soc: amlogic: clk-measure: Align compatible entries with DT bindingsChuan Liu
Reorder the meson_msr_match_table entries to match the order of the compatible strings in the DT binding. Move the newly added clk_msr_a1_data entry accordingly, while keeping the existing SoC-specific data order unchanged. Signed-off-by: Chuan Liu <chuan.liu@amlogic.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260920-more-socs-to-support-clk_measure-v2-4-224382a429e8@amlogic.com Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
2026-10-02soc: amlogic: clk-measure: Support more measurement channelsChuan Liu
On S4 and C3, as well as later SoCs, the clk-measure IP expands the number of supported measurement channels from 128 to 256. Accordingly, the MSR_CLK_SRC field in the register is extended from 7 bits to 8 bits. To support both the old and new implementations, the driver now uniformly defines the valid MSR_CLK_SRC field as bits[27:20]. For SoCs where MSR_CLK_SRC is only 7 bits wide, the driver never sets bit27, and on those SoCs bit27 is read-only. Therefore, using bits[27:20] as the unified field definition does not introduce any behavioral change or compatibility issue for existing SoCs. Signed-off-by: Chuan Liu <chuan.liu@amlogic.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260920-more-socs-to-support-clk_measure-v2-3-224382a429e8@amlogic.com Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
2026-10-02soc/tegra: pmc: Add PCIe wake event for Tegra234Manikanta Maddireddy
GPIO L.2 is used as the PCIe WAKE# signal on Tegra234 platforms. Add the PMC wake event mapping so the GPIO interrupt can be armed as a system wake source. Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2026-10-01Merge tag 'mtk-soc-for-v7.4' of ↵Krzysztof Kozlowski
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/mediatek/linux into soc/drivers MediaTek SoC driver updates This adds support for GPU<->SRAM regulator coupling for the MediaTek MT8189 SoC, and introduces more MMSYS routes for display controller pahs of the MediaTek MT8167 SoC. * tag 'mtk-soc-for-v7.4' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/mediatek/linux: soc: mediatek: mt8167-mmsys: add routes for all display paths soc: mediatek: mtk-regulator-coupler: Add support for MT8189 Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2026-10-01soc: st: Add STM32MP2 SYSCFG driverMarek Vasut
Add trivial SYSCFG driver for ST STM32MP25xx, which binds drivers to its subnodes. This is currently used to bind USB PHY drivers to subnodes described in the SYSCFG DT node. Signed-off-by: Marek Vasut <marex@nabladev.com> Tested-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com> Acked-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com> Link: https://lore.kernel.org/r/20260902124018.606544-2-marex@nabladev.com Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
2026-09-29soc: renesas: Kconfig: Enable ICU support for RZ/G3E and RZ/V2NLad Prabhakar
Explicitly select the RZ/V2H ICU driver for RZ/G3E and RZ/V2N, as GPIO and IRQ interrupts are routed through the ICU block on these SoCs. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20260925224927.14951-1-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2026-09-27soc: apple: rtkit-crashlog: Add support for AArch32 state 'CrgA' sectionNick Chan
Add support for CrgA section containing the AArch32 IOP CPU state, which may appear when an AArch32 RTKit IOP crashes. Signed-off-by: Nick Chan <towinchenmi@gmail.com> Link: https://patch.msgid.link/20260919-rtkit-armv7-crashlog-v1-2-f4a671ea453c@gmail.com Signed-off-by: Sven Peter <sven@kernel.org>
2026-09-27soc: apple: rtkit-crashlog: rename 'Crg8' section from regs to aarch64Nick Chan
This section contains AArch64 CPU state of the IOP when the exception occurred, including register information. Rename this section to be clear about the CPU architecture as support for crashlog section with AArch32 CPU state will be added. Signed-off-by: Nick Chan <towinchenmi@gmail.com> Link: https://patch.msgid.link/20260919-rtkit-armv7-crashlog-v1-1-f4a671ea453c@gmail.com Signed-off-by: Sven Peter <sven@kernel.org>
2026-09-25soc: qcom: Add QMI TMD support for remote thermal mitigationCasey Connolly
Add support for Qualcomm Messaging Interface (QMI) based Thermal Mitigation Device (TMD) cooling devices provided by remote subsystems. On Qualcomm platforms where remote processors expose mitigation controls through the TMD QMI service, client drivers need support to discover the service, register cooling devices for available mitigation endpoints, and forward cooling state updates to remote subsystems. Signed-off-by: Casey Connolly <casey.connolly@linaro.org> Co-developed-by: Daniel Lezcano <daniel.lezcano@oss.qualcomm.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@oss.qualcomm.com> Co-developed-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com> Signed-off-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260809-b4-qmi-tmd-v8-2-b15d47adc379@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-09-24soc: renesas: Enable SYSC driver for r8a774a3Ayman Chaudhry
Select SYSC_R8A774A3 config option if ARCH_R8A774A3 is enabled so that System Controller driver is enabled on Renesas RZ/G2M v3.0 SoC. Signed-off-by: Ayman Chaudhry <ayman.chaudhry.kc@renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20260921134432.50338-5-ayman.chaudhry.kc@renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2026-09-23drivers: Kconfig: Simplify dependencies on ARM64 && !CPU_BIG_ENDIANWill Deacon
Now that arm64 no longer supports a big-endian kernel, simplify some driver Kconfig entries so that the dependency on a little-endian kernel no longer needs to be called out explicitly. Reviewed-by: Michael Kelley <mhklinux@outlook.com> # Hyper-V Suggested-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Will Deacon <will@kernel.org> Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2026-09-22soc: ti: knav_qmss: Fix typos in commentsHemanth Selam
Correct "specifes" to "specifies" in the knav_queue_open() kernel-doc and "accomodate" to "accommodate" in knav_pool_create(). No code changes. Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com> Acked-by: Udit Kumar <u-kumar1@ti.com> Link: https://patch.msgid.link/20260911085055.715191-1-hemanth.selam@gmail.com Signed-off-by: Nishanth Menon <nm@ti.com>
2026-09-21soc: mediatek: mt8167-mmsys: add routes for all display pathsLuca Leonardo Scorcia
mt8167 display output pipeline can be configured in many different ways. Add support for additional routes according to the SoC data sheet and Android sources. There's a few inconsistencies between those two, but assume the Android sources are correct since they are required to drive HDMI output via DPI1. Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2026-09-21soc/tegra: fuse: Add Tegra264 supportJon Hunter
Add the fuse SoC data for the Tegra264 device which defines the address range and keepouts for the fuse registers. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2026-09-20soc: atmel: Convert to of_machine_device_match()Geert Uytterhoeven
Use the of_machine_device_match() helper instead of open-coding the same operation. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Claudiu Beznea <claudiu.beznea@tuxon.dev> Link: https://lore.kernel.org/r/c3b4f8aceb5f0bc95fa10e6fa469574cfdaa8ee6.1788429505.git.geert+renesas@glider.be Signed-off-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
2026-09-18soc: samsung: exynos-pmu: fix use-after-free of interrupt generator nodeAlexey Klimov
The setup_cpuhp_and_cpuidle() parses the device tree node for the interrupt generation block via of_parse_phandle() and decrements its reference count using of_node_put() immediately after fetching the resource address. However, later the intr_gen_node pointer is passed into of_syscon_register_regmap(). Fix this by declaring intr_gen_node with __free() and removing of_node_put(). Reported-by: Sashiko <sashiko-bot@kernel.org> Closes: https://sashiko.dev/#/patchset/20260513-exynos850-cpuhotplug-v4-0-54fec5f65362@linaro.org?part=3 Fixes: 78b72897a5c8 ("soc: samsung: exynos-pmu: Enable CPU Idle for gs101") Cc: stable@vger.kernel.org Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org> Link: https://patch.msgid.link/20260828-exynos-pmu-cpuhp-idle-fixes-v2-1-06bce6107bd6@linaro.org Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20260917081641.72291-2-krzk@kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2026-09-10soc: fsl: qe: drop GPIOD_FLAGS_BIT_NONEXCLUSIVEBartosz Golaszewski
The GPIOD_FLAGS_BIT_NONEXCLUSIVE flag for gpiod_get() is deprecated. For actually shared GPIOs, it should be replaced by using the functionality provided by gpio-shared-proxy. The Freescale QUICC Engine GPIO driver uses it as a workaround to access the GPIO descriptor already requested by the caller of qe_pin_request() in order to access the private GPIO chip data. As the existing comment itself states, the user already requested this GPIO and the only user in tree is the FHCI USB driver which does in fact request it, we can safely modify the function to take the *exclusive* GPIO descriptor as argument and stop using the deprecated flag. Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20260908-usb-fhci-drop-gpio-nonexclusive-v1-1-8e405dc67874@oss.qualcomm.com Signed-off-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
2026-09-10soc/tegra: pmc: Fix uninitialised clock rateJon Hunter
For legacy 32-bit Tegra devices, the warning in the tegra_pmc_enter_suspend_mode() function is being triggered because the early_pmc->rate variable is never configured and hence, always 0. This issue started occurring after updating the PMC driver to create the PMC context dynamically which causes the 'rate' to be set in the new dynamic context, but missed updating the rate in the early PMC context. Fix this by initialising the early_pmc->rate variable for 32-bit Tegra devices when the rate for the PMC context is initialised. Fixes: 4d61f0342689 ("soc/tegra: pmc: Create PMC context dynamically") Signed-off-by: Jon Hunter <jonathanh@nvidia.com> [treding@nvidia.com: move assignment to existing #ifdef block] Signed-off-by: Thierry Reding <treding@nvidia.com>
2026-09-10soc: mediatek: mtk-regulator-coupler: Add support for MT8189Justin Yeh
MT8189 couples its GPU supply (buck_vgpu) with the GPU SRAM supply (ldo_sram_gpu), which is exactly the GPU<->SRAM relationship this coupler already handles for MT8183, MT8186, MT8188 and MT8192. Register the coupler on MT8189 as well so that both supplies stay voltage-balanced. Signed-off-by: Justin Yeh <justin.yeh@mediatek.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
2026-09-07soc/fsl/qe: qe_ports_ic: Drop redundant IRQ_DOMAIN_FLAG_DESTROY_GCQingshuang Fu
Now that __irq_domain_instantiate() automatically sets IRQ_DOMAIN_FLAG_DESTROY_GC when dgc_info is provided, the explicit flag in the irq_domain_info is redundant. Remove it. Signed-off-by: Qingshuang Fu <fuqingshuang@kylinos.cn> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Reviewed-by: Herve Codina <herve.codina@bootlin.com> Link: https://patch.msgid.link/20260907024046.28845-4-fuqingshuang@kylinos.cn
2026-09-07soc: fsl: qe: Fix sparse warnings in GPIOChristophe Leroy (CS GROUP)
A C=2 build on mpc83xx_defconfig provides following warnings: drivers/soc/fsl/qe/gpio.c:44:34: warning: incorrect type in assignment (different base types) drivers/soc/fsl/qe/gpio.c:44:34: expected restricted __be32 [usertype] cpdata drivers/soc/fsl/qe/gpio.c:44:34: got unsigned int [usertype] cpdata drivers/soc/fsl/qe/gpio.c:45:34: warning: incorrect type in assignment (different base types) drivers/soc/fsl/qe/gpio.c:45:34: expected restricted __be32 [usertype] cpdir1 drivers/soc/fsl/qe/gpio.c:45:34: got unsigned int drivers/soc/fsl/qe/gpio.c:46:34: warning: incorrect type in assignment (different base types) drivers/soc/fsl/qe/gpio.c:46:34: expected restricted __be32 [usertype] cpdir2 drivers/soc/fsl/qe/gpio.c:46:34: got unsigned int drivers/soc/fsl/qe/gpio.c:47:34: warning: incorrect type in assignment (different base types) drivers/soc/fsl/qe/gpio.c:47:34: expected restricted __be32 [usertype] cppar1 drivers/soc/fsl/qe/gpio.c:47:34: got unsigned int drivers/soc/fsl/qe/gpio.c:48:34: warning: incorrect type in assignment (different base types) drivers/soc/fsl/qe/gpio.c:48:34: expected restricted __be32 [usertype] cppar2 drivers/soc/fsl/qe/gpio.c:48:34: got unsigned int drivers/soc/fsl/qe/gpio.c:49:33: warning: incorrect type in assignment (different base types) drivers/soc/fsl/qe/gpio.c:49:33: expected restricted __be32 [usertype] cpodr drivers/soc/fsl/qe/gpio.c:49:33: got unsigned int drivers/soc/fsl/qe/gpio.c:297:17: warning: restricted __be32 degrades to integer drivers/soc/fsl/qe/gpio.c:299:17: warning: restricted __be32 degrades to integer drivers/soc/fsl/qe/gpio.c:302:17: warning: restricted __be32 degrades to integer drivers/soc/fsl/qe/gpio.c:304:17: warning: restricted __be32 degrades to integer drivers/soc/fsl/qe/gpio.c:308:18: warning: restricted __be32 degrades to integer drivers/soc/fsl/qe/gpio.c:314:9: warning: restricted __be32 degrades to integer The problem is the 'struct qe_pio_reg' embedded in 'struct qe_gpio_chip' to save register values. As the values are read with ioread32be(), they are now in CPU byte order and can't be stored as-is in a __be32 object. Replace 'struct qe_pio_reg saved_regs' by individual u32 fields. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202608051952.ADkLIB86-lkp@intel.com/ Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202608130908.gEy44F1D-lkp@intel.com/ Link: https://lore.kernel.org/r/6a84b38e766729676b375c93bf54c67ea455288d.1786080840.git.chleroy@kernel.org Signed-off-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
2026-09-07soc: renesas: rcar-rst: Add support for RZ/G2M v3.0Ayman Chaudhry
Add support for Renesas RZ/G2M v3.0 (a.k.a. R8A774A3) SoC to the R-Car RST driver. Signed-off-by: Ayman Chaudhry <ayman.chaudhry.kc@renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20260821150408.73829-6-ayman.chaudhry.kc@renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2026-09-07soc: renesas: Identify RZ/G2M v3.0 SoCAyman Chaudhry
Add support to identify the Renesas RZ/G2M v3.0 (a.k.a. R8A774A3) SoC. The RZ/G2M v3.0 is assigned the same Product ID Number in the Product Register as the Renesas RZ/G2M v1.3 (a.k.a. R8A774A1), so use the same SoC data. Signed-off-by: Ayman Chaudhry <ayman.chaudhry.kc@renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20260821150408.73829-2-ayman.chaudhry.kc@renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2026-09-07soc: renesas: rcar-mfis: Add hwspinlock supportWolfram Sang
Every MFIS instance has a block of hardware spinlocks. Add support for them. R-Car Gen4 has only one instance, so the base_id is always 0. R-Car Gen5 has multiple instances, so the base_id has to be encoded in the info description. Also being a provider, a hwspinlock-private header needs to be included. Work to refactor the headers is on-going, but will need many preparational steps. Until then, we need to live with the special include. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20260817095447.34693-3-wsa+renesas@sang-engineering.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2026-09-04treewide: refresh kmalloc_obj() conversionsKees Cook
This is another run of the Coccinelle script for converting kmalloc() family of allocations to kmalloc_obj() via the existing rules in scripts/coccinelle/api/kmalloc_objs.cocci This catches both the set of kmalloc() uses added since the first kmalloc_obj() conversions in v7.0 and adds a large group missed in the first pass due to Coccinelle not interacting well with the cleanup.h scoped_...() family of macros[1]. I worked around this with spatch's "--macro-file" argument to a file with all the scoped_...() macros mapped to Coccinelle's YACFE_ITERATOR[2] as that was the closest viable control flow indicator I could find. Build tested allmodconfig on x86, arm64, arm, loongarch, mips, powerpc, riscv, and s390 with no new warnings. Link: https://lore.kernel.org/lkml/202609021314.8A9C0B8@keescook/ [1] Link: https://github.com/coccinelle/coccinelle/blob/master/standard.h [2] Signed-off-by: Kees Cook <kees+treewide@kernel.org>
2026-09-04soc: samsung: exynos-chipid: Add Exynos5515 SoC supportAiden Isik
Add Exynos5515 information to the soc_ids table. The ChipID for Exynos5515 is "0xE5515000". Signed-off-by: Aiden Isik <aidenisik@member.fsf.org> Link: https://patch.msgid.link/20260818-for-next-lucky7-chipid-v2-2-28ae49f5c349@member.fsf.org Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2026-09-02soc: renesas: Kconfig: Select POWER_SEQUENCING_RENESAS_PWRRDY for R9A08G046Biju Das
The RZ/G3L SYSC driver registers a "pwrseq-pwrrdy" auxiliary device to handle the PWRRDY power sequencing, which requires the pwrseq-renesas-pwrrdy driver to bind to it. Select POWER_SEQUENCING_RENESAS_PWRRDY from SYSC_R9A08G046 so it's built whenever RZ/G3L SYSC support is enabled. Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://patch.msgid.link/20260826122742.153643-5-biju.das.jz@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2026-09-02soc: renesas: rz-sysc: Register auxiliary device for PWRRDY power sequencerBiju Das
Some RZ SoCs (e.g. RZ/G3L) have a PWRRDY register that is controlled through a power sequencer rather than directly by the SYSC driver. Add a pwrrdy_pwrseq flag to struct rz_sysc_soc_id_init_data to mark SoCs with this property, and set it for RZ/G3L. When set, rz_sysc_probe() registers a "pwrseq-pwrrdy" auxiliary device so a dedicated driver can handle the PWRRDY sequencing. Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://patch.msgid.link/20260826122742.153643-2-biju.das.jz@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2026-08-31soc: qcom: geni-se: allow selection on 32-bit ARM Qualcomm SoCsHardeep Sharma
Kuno, a 32-bit ARM Cortex-A7 Qualcomm SoC, uses the GENI-based QUP wrapper for its debug UART. Drop the explicit ARM64 dependency so the driver can be selected on 32-bit ARM as well; QCOM_GENI_SE already sits under the QCOM_SOC menuconfig, which is gated by ARCH_QCOM || COMPILE_TEST, so no replacement dependency is needed. Acked-by: Mukesh Savaliya <mukesh.savaliya@oss.qualcomm.com> Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Signed-off-by: Hardeep Sharma <hardeep.sharma@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260827-kuno-soc-support-v5-1-6d47636a8f09@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-08-31soc: qcom: Remove redundant dev_err()Pan Chuang
Since commit 55b48e23f5c4 ("genirq/devres: Add error handling in devm_request_*_irq()"), devm_request_irq() and devm_request_threaded_irq() automatically log detailed error messages on failure. Remove the now-redundant driver-specific dev_err() calls. Signed-off-by: Pan Chuang <panchuang@vivo.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260723024248.17480-1-panchuang@vivo.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-08-31soc: qcom: apr: Drop unused apr_device_idUwe Kleine-König (The Capable Hub)
apr_device_id was introduced in commit 6adba21eb434 ("soc: qcom: Add APR bus driver") in 2018, and since then not a single driver made use of it. So drop the unused id_table pointer from struct apr_driver and move APR_NAME_SIZE to the apr header which still has a usage of it. Note that with the id_table being NULL apr_device_match() degrades to just of_driver_match_device(), so replace this callback accordingly. Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com> Link: https://lore.kernel.org/r/e8b352f33ae38df3616dc157c1cafd13d49c5e3e.1784554037.git.u.kleine-koenig@baylibre.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-08-31soc: qcom: smsm: fix __iomem annotationsBen Dooks
There are a number of points in the driver which miss out on __iomem annotations, so add these to remove the following sparse warnings: drivers/soc/qcom/smsm.c:159:32: warning: incorrect type in argument 1 (different address spaces) drivers/soc/qcom/smsm.c:159:32: expected void const volatile [noderef] __iomem *addr drivers/soc/qcom/smsm.c:159:32: got unsigned int [usertype] *local_state drivers/soc/qcom/smsm.c:171:25: warning: incorrect type in argument 2 (different address spaces) drivers/soc/qcom/smsm.c:171:25: expected void volatile [noderef] __iomem *addr drivers/soc/qcom/smsm.c:171:25: got unsigned int [usertype] *local_state drivers/soc/qcom/smsm.c:181:48: warning: incorrect type in argument 1 (different address spaces) drivers/soc/qcom/smsm.c:181:48: expected void const volatile [noderef] __iomem *addr drivers/soc/qcom/smsm.c:181:48: got unsigned int [usertype] * drivers/soc/qcom/smsm.c:219:26: warning: incorrect type in argument 1 (different address spaces) drivers/soc/qcom/smsm.c:219:26: expected void const volatile [noderef] __iomem *addr drivers/soc/qcom/smsm.c:219:26: got unsigned int [usertype] *remote_state drivers/soc/qcom/smsm.c:257:49: warning: incorrect type in argument 1 (different address spaces) drivers/soc/qcom/smsm.c:257:49: expected void const volatile [noderef] __iomem *addr drivers/soc/qcom/smsm.c:257:49: got unsigned int [usertype] * drivers/soc/qcom/smsm.c:259:49: warning: incorrect type in argument 2 (different address spaces) drivers/soc/qcom/smsm.c:259:49: expected void volatile [noderef] __iomem *addr drivers/soc/qcom/smsm.c:259:49: got unsigned int [usertype] * drivers/soc/qcom/smsm.c:280:24: warning: incorrect type in argument 1 (different address spaces) drivers/soc/qcom/smsm.c:280:24: expected void const volatile [noderef] __iomem *addr drivers/soc/qcom/smsm.c:280:24: got unsigned int [usertype] *remote_state drivers/soc/qcom/smsm.c:288:49: warning: incorrect type in argument 1 (different address spaces) drivers/soc/qcom/smsm.c:288:49: expected void const volatile [noderef] __iomem *addr drivers/soc/qcom/smsm.c:288:49: got unsigned int [usertype] * drivers/soc/qcom/smsm.c:290:49: warning: incorrect type in argument 2 (different address spaces) drivers/soc/qcom/smsm.c:290:49: expected void volatile [noderef] __iomem *addr drivers/soc/qcom/smsm.c:290:49: got unsigned int [usertype] * drivers/soc/qcom/smsm.c:330:26: warning: incorrect type in argument 1 (different address spaces) drivers/soc/qcom/smsm.c:330:26: expected void const volatile [noderef] __iomem *addr drivers/soc/qcom/smsm.c:330:26: got unsigned int [usertype] *remote_state drivers/soc/qcom/smsm.c:635:47: warning: incorrect type in argument 2 (different address spaces) drivers/soc/qcom/smsm.c:635:47: expected void volatile [noderef] __iomem *addr drivers/soc/qcom/smsm.c:635:47: got unsigned int [usertype] * Note, we don't fixup the qcom_smem_get() to return an __iomem annotated pointer. Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Link: https://lore.kernel.org/r/20260623090954.620688-1-ben.dooks@codethink.co.uk Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-08-31soc: qcom: llcc: Update the SCT table for IPQ5424Kathiravan Thirumoorthy
Update the IPQ5424 LLCC slice configuration table to give the PPE and Wi-Fi datapaths dedicated slices. Assign slice IDs 1 and 5 to the PPE RX descriptor and RX fill use cases, slice IDs 6 and 7 to the Wi-Fi radios connected over PCIe, and slice ID 2 to the CPU subsystem. Adjust the corresponding capacities, priorities, and way masks for these consumers. These slice assignments are based on recommendations from the performance team, following throughput measurements on IPQ5424. Having the dedicated slice configuration for each of these use cases helps to improve the networking throughput by more than 1 Gbps. Rename the usecase IDs for slice IDs 1 and 2 because LLCC_CPUSS and LLCC_VIDSC0 do not describe the actual users of those slices. Assisted-by: LLM Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260819-ipq5424_llcc_updates-v3-1-42b48451481d@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-08-31soc: qcom: smem: support Glymur DRAM infoKonrad Dybcio
Glymur firmware provides a version 7 DDR-info SMEM entry whose 872-byte layout is different from the one the driver supports today. The data contains 16 channel descriptors, 14 DDR frequency slots, four 4 DDR region slots, a 10-entry SHUB frequency plan, and v6 misc information. It accounts for 616 bytes; the captured SMEM entry has a further 256 zero bytes. Add a Glymur-specific version 7 layout and recognize that complete entry. Parse the DDR frequencies and highest-bank bit from the common fields. Assisted-by: LLM Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Tested-by: Gopikrishna Garmidi <gopikrishna.garmidi@oss.qualcomm.com> Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260820-topic-glymur_dramc-v1-1-f714eef34e4d@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-08-31soc: qcom: smem: Fix byte order in v3 14-frequency parserLinmao Li
smem_dram_parse_v3_14freqs_data() uses the little-endian freq_khz field directly when scaling the frequency from kHz to Hz. This produces byte-swapped values on big-endian systems. Convert freq_khz to CPU byte order before using it, as the other DDR data parsers do. Fixes: 1d234eeafc56 ("soc: qcom: smem: Expose DDR data from SMEM") Signed-off-by: Linmao Li <lilinmao@kylinos.cn> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260827020447.2642830-1-lilinmao@kylinos.cn Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-08-31soc: qcom: smem: fix 32-bit overflow in DDR frequency calculationGopikrishna Garmidi
The DDR frequency in SMEM is reported in kHz and converted to Hz by multiplying it by 1000. Since the SMEM frequency value is a u32, using an unsuffixed integer constant causes the multiplication to be performed with 32-bit arithmetic. This overflows for DDR frequencies above 4294967 kHz, resulting in an incorrect frequency being reported through the SMEM DRAM interface. Use an unsigned long constant for the multiplication so the calculation is performed with 64-bit arithmetic on the supported Qualcomm platforms. Apply the fix consistently to the v3, v3.1, v4, v5, and v7 SMEM parsers. Fixes: 1d234eeafc56 ("soc: qcom: smem: Expose DDR data from SMEM") Signed-off-by: Gopikrishna Garmidi <gopikrishna.garmidi@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260827-glymur_dramc-v1-1-eba358d504b8@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-08-31soc/tegra: pmc: Add PMC support for Tegra410Kartik Rajput
Tegra410 uses PMC driver only to retrieve system reset reason using PMC sysfs. Tegra410 uses ACPI to probe PMC, unlike device-tree boot it does not use the early initialisation sequence. Add PMC support for Tegra410, which uses the PMC driver to retrieve the system reset reason via PMC sysfs. Signed-off-by: Kartik Rajput <kkartik@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2026-08-31soc/tegra: fuse: Add missing newline to APBMISC error messageJinhui Guo
The error message printed by tegra_acpi_init_apbmisc() when failing to get APBMISC memory resources is missing a trailing newline. This can cause the message to be merged with the following kernel log line, making the log harder to read. Add the missing newline to keep the error output properly formatted. Fixes: 7b0c505eb341 ("soc/tegra: fuse: Add tegra_acpi_init_apbmisc()") Signed-off-by: Jinhui Guo <guojinhui.liam@bytedance.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2026-08-31soc: renesas: rcar-mfis: Convert spinlock to raw_spinlockWolfram Sang
With the upcoming hwspinlock support for this driver, mfis_write() can also be accessed from atomic contexts. Convert the spinlock guarding the unprotect register to a raw_spinlock, so we will avoid potential deadlocks with preempt_rt. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20260718182355.50045-2-wsa+renesas@sang-engineering.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2026-08-31soc: renesas: Expand MFIS acronym in RCAR_MFIS help descriptionGeert Uytterhoeven
People not very familiar with Renesas R-Car SoCs may not know the meaning of the MFIS acronym. Hence expand it in the help text. While at it, drop "core driver", as there is only a single driver, unlike early development revisions, and replace "Gen5" by "R-Car Gen5". Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/b92a4b39a18aec7cdffdfdfbc75de4ecadb0395d.1782998764.git.geert+renesas@glider.be
generated by cgit v1.2.3 (git 2.0.4) at 2026-10-30 23:37:13 +0000