archive mirror
 help / color / mirror / Atom feed
From: Abhishek Kumar <>
To: Stephen Boyd <>
Cc: Matthias Kaehlcke <>,
	Kalle Valo <>,
	 LKML <>,
	ath10k <>,
	 linux-wireless <>,,  netdev <>,
	Govind Singh <>,
	 Youghandhar Chintala <>,
	Rakesh Pillai <>
Subject: Re: [PATCH] ath10k: Don't always treat modem stop events as crashes
Date: Wed, 8 Sep 2021 15:37:07 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

The way I see this, this issue is happening because of a much bigger
design constraint. On integrated(modem+wifi) solutions, if remote proc
service is shutdown, it has a trickle down effect. It deinitializes
the modem processor (which controls wifi as its subsystem) and the
wifi FW. As the fw de-initializes, we see the Delete server generated
by the wifi FW. The FW generates delete server qmi event and there is
no way on the host wifi driver to differentiate between delete event
generated from a FW crash and de-initialization due to remoteproc and
so we see the FW crash logs even during shutdown.

I would like to know what are Qualcomm's views on the design
constraint and any plans to reduce the rigidity. Also, will the FW
broadcast other qmi events(QRTR_TYPE_BYE for e.g.) during shutdown
(different from crash) ? If so then we can utilize that event and then
we don't even have to add dependency on remoteproc.

Overall this change should fix the issue, additionally I have one
comment below and would like other reviewers views.

>  #include <linux/regulator/consumer.h>
> +#include <linux/remoteproc/qcom_rproc.h>
>  #include <linux/of_address.h>
We are adding an external dependency here but since this is added in
snoc.c (which is for integrated solution only), I can expect if SNOC
is enabled, remote proc will be enabled as well, so it should be fine.

Reviewed-by: Abhishek Kumar <>

On Tue, Sep 7, 2021 at 12:48 PM Stephen Boyd <> wrote:
> Quoting Matthias Kaehlcke (2021-09-07 12:32:59)
> > On Sun, Sep 05, 2021 at 02:04:00PM -0700, Stephen Boyd wrote:
> > > @@ -1740,10 +1805,19 @@ static int ath10k_snoc_probe(struct platform_device *pdev)
> > >               goto err_fw_deinit;
> > >       }
> > >
> > > +     ret = ath10k_modem_init(ar);
> > > +     if (ret) {
> > > +             ath10k_err(ar, "failed to initialize modem notifier: %d\n", ret);
> >
> > nit: ath10k_modem_init() encapsulates/hides the setup of the notifier,
> > the error message should be inside the function, as for _deinit()
> Sure. I can fix it. I was also wondering if I should drop the debug
> prints for the cases that don't matter in the switch statement but I'll
> just leave that alone unless someone complains about it.

ath10k mailing list

  reply	other threads:[~2021-09-08 22:38 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-05 21:04 Stephen Boyd
2021-09-06  0:43 ` Steev Klimaszewski
2021-09-07 19:32 ` Matthias Kaehlcke
2021-09-07 19:48   ` Stephen Boyd
2021-09-08 22:37     ` Abhishek Kumar [this message]
2021-09-09  0:21       ` Stephen Boyd
     [not found] <002501d7af73$ae0a7620$0a1f6260$>
2021-09-22 22:20 ` Stephen Boyd
2021-09-24  7:59   ` Kalle Valo
2021-09-24  8:07     ` pillair

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: [PATCH] ath10k: Don'\''t always treat modem stop events as crashes' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).