Re: Coresight causes synchronous external abort on msm8916

[Sudeep Holla <sudeep.holla@arm.com>]

Hi,

On Fri, Jun 21, 2019 at 05:16:28PM +0100, Suzuki K Poulose wrote:
> Hi Stephan
>
> On 21/06/2019 17:06, Stephan Gerhold wrote:
> >
> >   (b) Preventing the crash:
> >       Is there some way to:
> >
> >        (1) Add a check in the AMBA bus code to verify if the power
> >            domain is actually turned on?
>
> No, there isn't, unless the DT tells you that device is disabled, just like
> your patch does.
>

Suzuki has already covered most of the points. Just wanted to add the
reason why kernel behaves the way it does. Kernel needs to deal with
absence of power domain info in DT by assuming the device is ready to
use. IIRC, even disabling few PM configuration, it behaves the same.

So yes, you need to explicitly disable in DT. Sorry if I misled you
earlier. I assumed the firmware and platform was tested to work, but
just missing configuration was causing the reported issue. If the
firmware doesn't enable PD by default and has no mechanism to enable
it, then disabling the device in DT is best way.

> >       or
> >        (2) Recover from the "synchronous external abort" and continue
> >            booting after printing an error/warning?
> >            (At the moment, userspace seems to continue for a while,
> >             but stops working at some point after the error...)
>
> Unfortunately, no. There is no way to do that from the kernel.
>
> >
> >       Otherwise, there is still the option to prevent the AMBA bus code
> >       from running by disabling the affected device tree nodes.
> >       That's what the debug@850000 { status = "disabled"; }; ... snippet
> >       from my first mail [3] does, and it is the only way to make the
> >       kernel boot successfully at the moment.
>
> For your board, I would say, this is the best option and the reasonable
> solution.
>
> >
> >       It wouldn't affect any other device if placed in the DTS for my
> >       device (i.e. *not* in the shared msm8916.dtsi).
>
> Ultimately, the device tree is based on the assumption that you are running with
> a firmware that supports the power domain and thus is fine for upstream. If
> someone is using a firmware that doesn't support this, it is better to disable
> the nodes, just like you did.
>
> Personally I would leave the upstream DTS as it is and expect the user to
> fixup his DTS for the firmware.
>
If there are known versions of firmware to work/not and they can be
discovered in bootloader or so, then affected platform can patch DT
to mark the device "disabled"(In case you can't disable it in upstream
without affecting other platforms)

--
Regards,
Sudeep