linux-kernel - Re: Crash in msm serial on dragonboard with ftrace bootargs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 13 Nov 2018 09:44:22 +0000
From:   Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
To:     saiprakash.ranjan@...eaurora.org,
        Steven Rostedt <rostedt@...dmis.org>,
        Stephen Boyd <sboyd@...nel.org>
Cc:     Joel Fernandes <joel@...lfernandes.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Andy Gross <andy.gross@...aro.org>,
        David Brown <david.brown@...aro.org>,
        Jiri Slaby <jslaby@...e.com>,
        Kees Cook <keescook@...omium.org>,
        Geliang Tang <geliangtang@...il.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Pramod Gurav <gpramod@...eaurora.org>,
        linux-arm-msm@...r.kernel.org, linux-soc@...r.kernel.org,
        linux-serial@...r.kernel.org, linux-kernel@...r.kernel.org,
        Rajendra Nayak <rnayak@...eaurora.org>,
        Vivek Gautam <vivek.gautam@...eaurora.org>,
        Sibi Sankar <sibis@...eaurora.org>
Subject: Re: Crash in msm serial on dragonboard with ftrace bootargs

Hi Sai,

On 25/10/18 15:36, saiprakash.ranjan@...eaurora.org wrote:
> "If I disable dma node and LS-UART0, then I don't see any crash and
> ftrace also works fine"
> 
> And one more observation is that even without ftrace cmdline, if I use
> earlycon and disable dma, I face the same crash.
> 
> So basically this seems to be some kind of earlycon and dma issue and
> not ftrace(I can be wrong).
> 
> So adding Srinivas for more info on this dma node.

Its Interesting that my old email conversations with SBoyd show that I 
have investigated this issue in early 2016!

My analysis so far:

This reason for such behavior is due the common iface clock
(GCC_BLSP1_AHB_CLK) across multiple drivers(serial ports, bam dma
and other low speed devices).
The code flow in DB410C is bit different, as the uart0 is first
attempted to set as console and then uart1, this ordering triggers
pm state change uart_change_pm(state, UART_PM_STATE_OFF) from serial
core while setting up uart0, this would go and disable all the
clocks for uart0.
As uart1 is not setup Yet, and earlycon is still active, any
attempts by earlycon to write to registers would trigger a system
reboot as the clock was just disabled by uart0 change_pm code.

This can even be triggered with any drivers like spi which uses same
clock I guess.

Hope it helps,

Either earlycon needs to reference the clocks or those clocks needs to
be marked always-on (but only with earlycon).

> 
> Also just for a note: apq8096-db820c.dtsi shows UART0 is disabled because
> bootloader does not allow access to it. Could this also be the case for 
> db410c?
No, this is not the case with DB410c. DB820c has added restrictions in 
TZ, I think new booloaders should have solved this issue.

Thanks,
srini