From: Mike Looijmans mike.looijmans@topic.nl
[ Upstream commit 3ede3f8b4b4b399b0ca41e44959f80d5cf84fc98 ]
At startup, the driver just assumes that all registers have their default values. But after a soft reset, the chip will just be in the state it was, and some pins may have been configured as outputs. Any modification of the output register will cause these pins to be driven low, which leads to unexpected/unwanted effects. To prevent this from happening, set the chip's IO configuration register to a known safe mode (all inputs) before toggling any other bits.
Signed-off-by: Mike Looijmans mike.looijmans@topic.nl Link: https://lore.kernel.org/20250314151803.28903-1-mike.looijmans@topic.nl Signed-off-by: Linus Walleij linus.walleij@linaro.org Signed-off-by: Sasha Levin sashal@kernel.org ---
Let me examine the exact change being made in the commit: Based on the commit analysis, here's my assessment: **YES** This commit should be backported to stable kernel trees. Here's my detailed analysis: ## Key Reasons for Backporting: ### 1. **Fixes a Real Safety Issue** The commit addresses a genuine safety problem where GPIO pins can be unexpectedly driven low during driver initialization. From the commit message: "Any modification of the output register will cause these pins to be driven low, which leads to unexpected/unwanted effects." This could cause hardware damage or system malfunction in real-world deployments. ### 2. **Small, Contained, and Safe Change** The code change is minimal and surgical: ```c + /bin /bin.usr-is-merged /boot /dev /etc /home /init /lib /lib.usr-is-merged /lib64 /lost+found /media /mnt /opt /proc /root /run /sbin /sbin.usr-is-merged /snap /srv /sys /tmp /usr /var + capability_test capability_test.c f2fs_folio_analysis.md ipv4_multipath_analysis.md ipv6_route_allocation_rcu_analysis.md ixgbe_e610_set_phys_id_analysis.md linux lpfc_timeout_analysis.md mac80211_mlo_mbssid_analysis.md pfcp_driver_historical_analysis.md rtl_bb_delay_analysis.md rtw89_mlo_analysis.md tcp_multipath_load_balance_analysis.md test_unaligned_diff test_unaligned_diff.c type_size_check type_size_check.c veth_driver_analysis.md wifi_mlo_mbssid_tx_link_id_analysis.md Reset the chip - we don't really know what state it's in, so reset + capability_test capability_test.c f2fs_folio_analysis.md ipv4_multipath_analysis.md ipv6_route_allocation_rcu_analysis.md ixgbe_e610_set_phys_id_analysis.md linux lpfc_timeout_analysis.md mac80211_mlo_mbssid_analysis.md pfcp_driver_historical_analysis.md rtl_bb_delay_analysis.md rtw89_mlo_analysis.md tcp_multipath_load_balance_analysis.md test_unaligned_diff test_unaligned_diff.c type_size_check type_size_check.c veth_driver_analysis.md wifi_mlo_mbssid_tx_link_id_analysis.md all pins to input first to prevent surprises. + linux/ + ret = mcp_write(mcp, MCP_IODIR, mcp->chip.ngpio == 16 ? 0xFFFF : 0xFF); + if (ret < 0) + return ret; ``` This simply writes all 1s to the MCP_IODIR register (I/O direction register), which according to the datasheet comment at line 29 is the proper reset value: `#define MCP_IODIR 0x00 /bin /bin.usr-is- merged /boot /dev /etc /home /init /lib /lib.usr-is-merged /lib64 /lost+found /media /mnt /opt /proc /root /run /sbin /sbin.usr-is-merged /snap /srv /sys /tmp /usr /var init/reset: all ones */` ### 3. **Aligns with Hardware Reset Behavior** The change makes the software behavior consistent with hardware reset behavior. The MCP_IODIR register defaults to 0xFF (all inputs) on hardware reset, so this ensures software reset has the same safe state. ### 4. **Minimal Risk of Regression** - The change occurs early in the probe function, before any other GPIO operations - Setting pins to input is the safest possible state - it cannot cause unexpected signal driving - The error handling is proper (returns on failure) - This matches the expected reset state per the hardware datasheet ### 5. **Affects Critical Subsystem Safety** GPIO drivers control physical hardware pins that can affect external circuits. Unexpected pin states can cause: - Hardware damage to connected devices - System instability - Safety issues in embedded systems ### 6. **No Architectural Changes** The fix doesn't introduce new features, change APIs, or modify the driver architecture. It simply ensures a known safe state during initialization. ### 7. **Similar Pattern to Other Stable Fixes** Looking at the similar commits provided, this follows the pattern of commit #3 (cy8c95x0 fix) which was marked as YES for backporting - both are small GPIO/pinctrl fixes that address real hardware behavior issues. ### 8. **Clear Problem Statement** The commit clearly explains the issue: "after a soft reset, the chip will just be in the state it was, and some pins may have been configured as outputs" - this is a well-defined problem that affects users. This commit meets all the criteria for stable backporting: it fixes an important bug that affects users, is small and contained, has minimal regression risk, and doesn't introduce new features or architectural changes.
drivers/pinctrl/pinctrl-mcp23s08.c | 8 ++++++++ 1 file changed, 8 insertions(+)
diff --git a/drivers/pinctrl/pinctrl-mcp23s08.c b/drivers/pinctrl/pinctrl-mcp23s08.c index 852354f6681b4..a743d9c6e1c77 100644 --- a/drivers/pinctrl/pinctrl-mcp23s08.c +++ b/drivers/pinctrl/pinctrl-mcp23s08.c @@ -567,6 +567,14 @@ int mcp23s08_probe_one(struct mcp23s08 *mcp, struct device *dev,
mcp->reset_gpio = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_LOW);
+ /* + * Reset the chip - we don't really know what state it's in, so reset + * all pins to input first to prevent surprises. + */ + ret = mcp_write(mcp, MCP_IODIR, mcp->chip.ngpio == 16 ? 0xFFFF : 0xFF); + if (ret < 0) + return ret; + /* verify MCP_IOCON.SEQOP = 0, so sequential reads work, * and MCP_IOCON.HAEN = 1, so we work with all chips. */