From: Laurentiu Tudor laurentiu.tudor@nxp.com
[ Upstream commit 23d060136841c58c2f9ee8c08ad945d1879ead4b ]
In case the MC firmware runs in debug mode with extensive prints pushed to the console, the current timeout of 500ms is not enough. Increase the timeout value so that we don't have any chance of wrongly assuming that the firmware is not responding when it's just taking more time.
Signed-off-by: Laurentiu Tudor laurentiu.tudor@nxp.com Signed-off-by: Ioana Ciornei ioana.ciornei@nxp.com Link: https://lore.kernel.org/r/20250408105814.2837951-7-ioana.ciornei@nxp.com Signed-off-by: Christophe Leroy christophe.leroy@csgroup.eu Signed-off-by: Sasha Levin sashal@kernel.org ---
Based on my analysis of the commit and the surrounding code context, here is my assessment: **YES** This commit should be backported to stable kernel trees. **Detailed Analysis:** **1. Bug Fix Nature:** This commit addresses a real timeout issue where legitimate MC firmware operations can fail due to an inadequate timeout value. The commit message explicitly states that "In case the MC firmware runs in debug mode with extensive prints pushed to the console, the current timeout of 500ms is not enough." **2. Code Change Analysis:** The change is minimal and surgical: - Changes a single timeout constant from 500ms to 15000ms (15 seconds) - Only affects `drivers/bus/fsl-mc/mc-sys.c:22` - No architectural changes or new functionality added - The timeout is used in both `mc_polling_wait_preemptible()` and `mc_polling_wait_atomic()` functions that handle MC command completion **3. Risk Assessment:** The change has minimal risk: - Increasing a timeout value is generally safe and doesn't change behavior for successful operations - Only affects systems with Freescale/NXP DPAA2 Management Complex hardware - The original 500ms timeout was clearly insufficient for legitimate use cases - Similar to successful backports in the reference commits (e.g., Similar Commit #1 and #3 which both increased timeouts) **4. Impact and Importance:** - Fixes a real user-facing issue where MC commands fail with timeouts during firmware debug scenarios - The FSL-MC bus is critical infrastructure for DPAA2 networking architecture on NXP ARM SoCs - Timeout failures can cause device initialization problems and system instability - The `mc_send_command()` function is used extensively throughout the FSL-MC subsystem for all hardware communication **5. Comparison with Similar Commits:** - Very similar to Similar Commit #1 (UCSI timeout increase from 1s to 5s) - **Status: YES** - Very similar to Similar Commit #3 (MLX5 timeout decrease from 2 hours to 60s) - **Status: YES** - Both of these were timeout adjustments that got backported successfully **6. Subsystem Scope:** The change is contained within the FSL-MC bus driver subsystem and only affects NXP DPAA2 hardware platforms, making it a safe candidate for stable trees. **7. Explicit Stable Tree Criteria:** This meets the stable tree criteria: - Fixes an important bug affecting real users - Small and contained change with minimal regression risk - No new features or architectural changes - Addresses a timeout issue that can cause system functionality problems The commit represents a classic example of a safe, important bug fix that should be backported to help users experiencing MC command timeouts in production environments, especially during firmware debugging scenarios.
drivers/bus/fsl-mc/mc-sys.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/bus/fsl-mc/mc-sys.c b/drivers/bus/fsl-mc/mc-sys.c index 85a0225db522a..14d77dc618cc1 100644 --- a/drivers/bus/fsl-mc/mc-sys.c +++ b/drivers/bus/fsl-mc/mc-sys.c @@ -19,7 +19,7 @@ /** * Timeout in milliseconds to wait for the completion of an MC command */ -#define MC_CMD_COMPLETION_TIMEOUT_MS 500 +#define MC_CMD_COMPLETION_TIMEOUT_MS 15000
/* * usleep_range() min and max values used to throttle down polling