aboutsummaryrefslogtreecommitdiff
path: root/scripts/gdb/linux/mm.py
diff options
context:
space:
mode:
authorRichard Genoud <richard.genoud@bootlin.com>2024-06-21 17:00:55 +0200
committerMathieu Poirier <mathieu.poirier@linaro.org>2024-07-01 10:37:26 -0600
commita8631f6d6344d976096b1efafdb2fbb3111bd790 (patch)
treed9aacd4dbd2b761b7c16c3f04c09f25282d75632 /scripts/gdb/linux/mm.py
parent67ca3f98070ffdf308b91e08a477fcb1e9684ae8 (diff)
remoteproc: k3-r5: Fix IPC-only mode detection
ret variable was used to test reset status, get from reset_control_status() call. But this variable was overwritten by ti_sci_proc_get_status() a few lines bellow. And as ti_sci_proc_get_status() returns 0 or a negative value (in this latter case, followed by a return), the expression !ret was always true, Clearly, this was not what was intended: In the comment above it's said that "requires both local and module resets to be deasserted"; if reset_control_status() returns 0 it means that the reset line is deasserted. So, it's pretty clear that the return value of reset_control_status() was intended to be used instead of ti_sci_proc_get_status() return value. This could lead in an incorrect IPC-only mode detection if reset line is asserted (so reset_control_status() return > 0) and c_state != 0 and halted == 0. In this case, the old code would have detected an IPC-only mode instead of a mismatched mode. Fixes: 1168af40b1ad ("remoteproc: k3-r5: Add support for IPC-only mode for all R5Fs") Signed-off-by: Richard Genoud <richard.genoud@bootlin.com> Reviewed-by: Hari Nagalla <hnagalla@ti.com> Link: https://lore.kernel.org/r/20240621150058.319524-2-richard.genoud@bootlin.com Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Diffstat (limited to 'scripts/gdb/linux/mm.py')
0 files changed, 0 insertions, 0 deletions