Re: [PATCH] remoteproc: qcom: pas: Request stop before tearing down GLINK and SMD

[Jure Rebernik]

Hi Val,

Thank you for looking at the patch and for offering to test it.

On 11/9/26 10:40 PM, Val Packett wrote:
> I've been seeing crashes in sensorspd like
>
> qcom_q6v5_pas 3700000.remoteproc: fatal error received:
> EX:kernel:0x1:SNS_SEE_I_0:0x10000025:PC=0xf00280b8:LR=0xf001f>
>
> on a Kodiak device (sm7325-motorola-dubai) also cause a whole-SoC reset
> right after logging that, when trying to restart the ADSP.
>
> Those are somewhat random and not too frequent, like once every couple days.
>
> I'll test this patch and see if I no longer end up with my phone
> randomly showing the u-boot menu when I pull it out of my pocket :D

A test on Kodiak would be very welcome, thank you. I should say up
front that I don't expect this patch to change that case, though. Your
log shows a crash that the firmware reported itself:
q6v5_fatal_interrupt() clears the running flag before it reports the
crash, so qcom_q6v5_request_stop() does not send a stop request, with
or without this patch. The patch only moves the request that is sent
for a crash the host reports, such as one triggered through the
debugfs crash file. I could not inject a firmware-reported crash on my
boards, so I would be glad to hear how it behaves on your device
either way.

> Try not to provide the free advertisement right in the commit msg btw,
> and to make it sliiightly less verbose.

Thanks for the feedback, that's fair. I added the note because
generated-content.rst asks for tool use to be noted in the changelog.
I'll wait for comments from Bjorn and Mathieu, and then send a v2 that
cuts it down to one short sentence, moves the details below the ---,
and tightens the rest of the message.

> It looks a bit funny that "stop is a device" but well, it's not like I
> can think of a more elegant solution...

Agreed, it does read a bit oddly. The alternative I could see is a hook
in the remoteproc core that runs before rproc_stop() stops the
subdevices. That would change the core for every driver to fix an
ordering problem inside the qcom drivers, so I kept the change local.
I'm happy to rework it that way if Bjorn or Mathieu prefer it.

Thanks again,
Jure