[ Please avoid top-posting. ]
On Thu, Apr 15, 2021 at 07:09:14PM +0200, Erwan LE RAY wrote:
Hi Dillon,
STM32MP151 is mono-core, but both STM32MP153 and STM32MP157 are
dual-core (see
https://www.st.com/content/st_com/en/products/microcontrollers-microproce...).
So your point is fully relevant, thanks.
ST already fixed the same issue in st-asc.c driver in the past (see
ef49ffd8), because a systematic deadlock was detected with RT kernel.
That's not the same issue. The above mentioned commit fixed an issue on
*RT* where local_irq_save() should be avoided.
You proposed a first implementation in your patch, and a second one
in
the discussion. It seems that your initial proposal (ie your V2 patch)
is the most standard one (implemented in 6 drivers). The second
implementation is implemented by only 1 company.
It looks that the solution is to avoid locking in the sysrq case and
trylock in the oops_in_progress case (see detailed analysis in
677fe555cbfb1).
So your initial patch looks to the right proposal, but it would be safer
if Greg could confirm it.
That would only fix the RT issue (and by making the sysrq one slightly
worse).
Using uart_unlock_and_check_sysrq() would address both issues.
Johan