Re: [PATCH v3 1/2] remoteproc: qcom: pas: Decide early_boot attach at probe time

[Shawn Guo <shengchao.guo@oss.qualcomm.com>]

On Wed, Oct 14, 2026 at 09:47:55AM +0200, Stephan Gerhold wrote:
> On Wed, Oct 14, 2026 at 03:00:37PM +0800, Shawn Guo wrote:
> > For early_boot subsystems, probe unconditionally marks the rproc
> > RPROC_DETACHED and qcom_pas_attach() discovers from SMP2P whether the
> > bootloader actually started the remote. If it did not, attach sets the
> > state back to RPROC_OFFLINE and fails, expecting the core to boot the
> > firmware instead. The core does not do that: rproc_boot() treats the
> > attach failure as fatal and the remote is never started.
> > 
> > This is hit on Nord with firmware where XBL no longer brings ADSP out
> > of reset. The remote never publishes its inbound SMP2P entries, so the
> > very first state read fails (debug print below) and the ADSP stays down:
> > 
> >   qcom_q6v5_pas 4c00000.remoteproc: Failed to get fatal_irq state: -19
> >   remoteproc remoteproc0: can't attach to rproc adsp: -19
> > 
> > The ready, stop-ack and sysmon shutdown-ack signals cannot change while
> > Linux has not yet interacted with the remote, so there is no reason to
> > defer the decision to attach time. Check them in probe and only mark
> > the rproc RPROC_DETACHED when the remote is up and has not been asked
> > to stop; otherwise leave it RPROC_OFFLINE so the regular firmware boot
> > path is taken. The ready state is read first so that a missing SMP2P
> > entry -ENODEV is treated as "not running" before sysmon is queried.
> > 
> > qcom_pas_attach() keeps only the fatal check, since that is the one
> > signal that has to be acted upon once the rproc is attached.
> > 
> > Assisted-by: LLM
> > Reviewed-by: Stephan Gerhold <stephan.gerhold@linaro.org>
> > Fixes: 16472c99f469 ("remoteproc: qcom: pas: Add late attach support for subsystems")
> > Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
> 
> Cc: stable@vger.kernel.org
> 
> is still missing. Would be good to have these fixes backported, since
> the original change landed in 7.3. If you used b4 trailers -u and it
> didn't add the Cc tag after my message that would confirm my suspicion
> that b4 won't pick up that tag. :/

Oops! I should have added the tag myself.

> Bjorn might forget to add these, so it's likely easiest and most
> reliable if you resend again with the tag added in both patches.

Yes, will do.

Shawn