blaster4385/linux-IllusionX/drivers/pinctrl, branch v6.12.10

pinctrl: mcp23s08: Fix sleeping in atomic context due to regmap locking

2025-01-09T12:33:50Z

commit a37eecb705f33726f1fb7cd2a67e514a15dfe693 upstream. If a device uses MCP23xxx IO expander to receive IRQs, the following bug can happen: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:283 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, ... preempt_count: 1, expected: 0 ... Call Trace: ... __might_resched+0x104/0x10e __might_sleep+0x3e/0x62 mutex_lock+0x20/0x4c regmap_lock_mutex+0x10/0x18 regmap_update_bits_base+0x2c/0x66 mcp23s08_irq_set_type+0x1ae/0x1d6 __irq_set_trigger+0x56/0x172 __setup_irq+0x1e6/0x646 request_threaded_irq+0xb6/0x160 ... We observed the problem while experimenting with a touchscreen driver which used MCP23017 IO expander (I2C). The regmap in the pinctrl-mcp23s08 driver uses a mutex for protection from concurrent accesses, which is the default for regmaps without .fast_io, .disable_locking, etc. mcp23s08_irq_set_type() calls regmap_update_bits_base(), and the latter locks the mutex. However, __setup_irq() locks desc->lock spinlock before calling these functions. As a result, the system tries to lock the mutex whole holding the spinlock. It seems, the internal regmap locks are not needed in this driver at all. mcp->lock seems to protect the regmap from concurrent accesses already, except, probably, in mcp_pinconf_get/set. mcp23s08_irq_set_type() and mcp23s08_irq_mask/unmask() are called under chip_bus_lock(), which calls mcp23s08_irq_bus_lock(). The latter takes mcp->lock and enables regmap caching, so that the potentially slow I2C accesses are deferred until chip_bus_unlock(). The accesses to the regmap from mcp23s08_probe_one() do not need additional locking. In all remaining places where the regmap is accessed, except mcp_pinconf_get/set(), the driver already takes mcp->lock. This patch adds locking in mcp_pinconf_get/set() and disables internal locking in the regmap config. Among other things, it fixes the sleeping in atomic context described above. Fixes: 8f38910ba4f6 ("pinctrl: mcp23s08: switch to regmap caching") Cc: stable@vger.kernel.org Signed-off-by: Evgenii Shatokhin Link: https://lore.kernel.org/20241209074659.1442898-1-e.shatokhin@yadro.com Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

pinctrl: qcom: spmi-mpp: Add PM8937 compatible

2024-12-14T19:04:02Z

[ Upstream commit f755261190e88f5d19fe0a3b762f0bbaff6bd438 ] The PM8937 provides 4 MPPs. Add a compatible to support them. Reviewed-by: Dmitry Baryshkov Signed-off-by: Barnabás Czémán Link: https://lore.kernel.org/20241031-msm8917-v2-4-8a075faa89b1@mainlining.org Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin

pinctrl: qcom-pmic-gpio: add support for PM8937

2024-12-14T19:04:02Z

[ Upstream commit 89265a58ff24e3885c2c9ca722bc3aaa47018be9 ] PM8937 has 8 GPIO-s with holes on GPIO3, GPIO4 and GPIO6. Signed-off-by: Barnabás Czémán Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/20241031-msm8917-v2-2-8a075faa89b1@mainlining.org Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin

pinmux: Use sequential access to access desc->pinmux data

2024-12-14T19:03:59Z

[ Upstream commit 5a3e85c3c397c781393ea5fb2f45b1f60f8a4e6e ] When two client of the same gpio call pinctrl_select_state() for the same functionality, we are seeing NULL pointer issue while accessing desc->mux_owner. Let's say two processes A, B executing in pin_request() for the same pin and process A updates the desc->mux_usecount but not yet updated the desc->mux_owner while process B see the desc->mux_usecount which got updated by A path and further executes strcmp and while accessing desc->mux_owner it crashes with NULL pointer. Serialize the access to mux related setting with a mutex lock. cpu0 (process A) cpu1(process B) pinctrl_select_state() { pinctrl_select_state() { pin_request() { pin_request() { ... .... } else { desc->mux_usecount++; desc->mux_usecount && strcmp(desc->mux_owner, owner)) { if (desc->mux_usecount > 1) return 0; desc->mux_owner = owner; } } Signed-off-by: Mukesh Ojha Link: https://lore.kernel.org/20241014192930.1539673-1-quic_mojha@quicinc.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin

pinctrl: freescale: fix COMPILE_TEST error with PINCTRL_IMX_SCU

2024-12-14T19:03:58Z

[ Upstream commit 58414a31c5713afb5449fd74a26a843d34cc62e8 ] When PINCTRL_IMX_SCU was selected by PINCTRL_IMX8DXL or PINCTRL_IMX8QM combined with COMPILE_TEST on a non-arm platforms, the IMX_SCU dependency could not be enabled. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202410031439.GyTSa0kX-lkp@intel.com/ Closes: https://lore.kernel.org/oe-kbuild-all/202410030852.q0Hukplf-lkp@intel.com/ Signed-off-by: Esben Haabendal Link: https://lore.kernel.org/20241003-imx-pinctrl-compile-test-fix-v1-1-145ca1948cc3@geanix.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin

pinctrl: qcom: spmi: fix debugfs drive strength

2024-12-05T13:02:47Z

commit 6bc0ebfb1d920f13c522545f114cdabb49e9408a upstream. Commit 723e8462a4fe ("pinctrl: qcom: spmi-gpio: Fix the GPIO strength mapping") fixed a long-standing issue in the Qualcomm SPMI PMIC gpio driver which had the 'low' and 'high' drive strength settings switched but failed to update the debugfs interface which still gets this wrong. Fix the debugfs code so that the exported values match the hardware settings. Note that this probably means that most devicetrees that try to describe the firmware settings got this wrong if the settings were derived from debugfs. Before the above mentioned commit the settings would have actually matched the firmware settings even if they were described incorrectly, but now they are inverted. Fixes: 723e8462a4fe ("pinctrl: qcom: spmi-gpio: Fix the GPIO strength mapping") Fixes: eadff3024472 ("pinctrl: Qualcomm SPMI PMIC GPIO pin controller driver") Cc: Anjelique Melendez Cc: stable@vger.kernel.org # 3.19 Signed-off-by: Johan Hovold Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/20241025121622.1496-1-johan+linaro@kernel.org Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

pinctrl: k210: Undef K210_PC_DEFAULT

2024-12-05T13:02:16Z

[ Upstream commit 7e86490c5dee5c41a55f32d0dc34269e200e6909 ] When the temporary macro K210_PC_DEFAULT is not needed anymore, use its name in the #undef statement instead of the incorrect "DEFAULT" name. Fixes: d4c34d09ab03 ("pinctrl: Add RISC-V Canaan Kendryte K210 FPIOA driver") Signed-off-by: zhang jiao Reviewed-by: Damien Le Moal Link: https://lore.kernel.org/20241113071201.5440-1-zhangjiao2@cmss.chinamobile.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin

pinctrl: renesas: Select PINCTRL_RZG2L for RZ/V2H(P) SoC

2024-12-05T13:02:02Z

[ Upstream commit 5dcde519a067ac5c85c273e550dde1873e2199bf ] Add explicit selection of the PINCTRL_RZG2L config option for the RZ/V2H(P) (R9A09G057) SoC, ensuring pin control driver is enabled for this SoC. Fixes: 9bd95ac86e70 ("pinctrl: renesas: rzg2l: Add support for RZ/V2H SoC") Reported-by: Biju Das Signed-off-by: Lad Prabhakar Reviewed-by: Geert Uytterhoeven Link: https://lore.kernel.org/20241010132726.702658-1-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin

pinctrl: zynqmp: drop excess struct member description

2024-12-05T13:02:02Z

[ Upstream commit 2a85fc7044987d751f27d7f1e4423eebbcecc2c6 ] The 'node' member has never been part of this structure so drop its description. Fixes: 8b242ca700f8 ("pinctrl: Add Xilinx ZynqMP pinctrl driver support") Signed-off-by: Bartosz Golaszewski Link: https://lore.kernel.org/20241010080432.7781-1-brgl@bgdev.pl Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin

pinctrl: renesas: rzg2l: Fix missing return in rzg2l_pinctrl_register()

2024-12-05T13:02:02Z

[ Upstream commit 1737715a4c2c08f207c94cc1f3af3c5945318d29 ] Fix the missing return statement in the error path of rzg2l_pinctrl_register(). Fixes: f73f63b24491fa43 ("pinctrl: renesas: rzg2l: Use dev_err_probe()") Reported-by: Nobuhiro Iwamatsu Closes: https://lore.kernel.org/all/OS0PR01MB638837327E5487B71D88A70392712@OS0PR01MB6388.jpnprd01.prod.outlook.com/ Signed-off-by: Biju Das Reviewed-by: Geert Uytterhoeven Link: https://lore.kernel.org/20241003082550.33341-1-biju.das.jz@bp.renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin