Re: [PATCH] wifi: ath11k: Silence remoteproc probe deferral prints
From: Bjorn Andersson
Date: Thu Feb 12 2026 - 10:17:00 EST
On Thu, Feb 12, 2026 at 04:01:21PM +0100, Konrad Dybcio wrote:
> On 2/12/26 3:52 PM, Bjorn Andersson wrote:
> > Upon failing to resolve the remoteproc phandle one ath11k_dbg() and one
> > ath11k_err() is used to tell the user about the (presumably) temporary
> > failure.
> >
> > Reduce the log spam by removing the duplicate print and switching to
> > dev_err_probe(), in line with how ath12k handles this error.
> >
> > Signed-off-by: Bjorn Andersson <bjorn.andersson@xxxxxxxxxxxxxxxx>
> > ---
> > drivers/net/wireless/ath/ath11k/ahb.c | 10 +++-------
> > 1 file changed, 3 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/net/wireless/ath/ath11k/ahb.c b/drivers/net/wireless/ath/ath11k/ahb.c
> > index 8dfe9b40c12626649639fc1dd9da0e5e0c2dcaf1..08d3a0c8f105b26b1548c5d6006f6ea162fe58ff 100644
> > --- a/drivers/net/wireless/ath/ath11k/ahb.c
> > +++ b/drivers/net/wireless/ath/ath11k/ahb.c
> > @@ -807,10 +807,8 @@ static int ath11k_core_get_rproc(struct ath11k_base *ab)
> > }
> >
> > prproc = rproc_get_by_phandle(rproc_phandle);
> > - if (!prproc) {
> > - ath11k_dbg(ab, ATH11K_DBG_AHB, "failed to get rproc, deferring\n");
> > - return -EPROBE_DEFER;
> > - }
> > + if (!prproc)
> > + return dev_err_probe(&ab->pdev->dev, -EPROBE_DEFER, "failed to get rproc\n");
>
> I'd like to think this doesn't really change the behavior, but I'd rather
> see this that in-house print functions..
>
I'm having problems parsing your sentence. Are you saying you rather see
us keep using the ath11k_* functions?
>
> > ab_ahb->tgt_rproc = prproc;
> >
> > return 0;
> > @@ -1190,10 +1188,8 @@ static int ath11k_ahb_probe(struct platform_device *pdev)
> > ath11k_ahb_init_qmi_ce_config(ab);
> >
> > ret = ath11k_core_get_rproc(ab);
> > - if (ret) {
> > - ath11k_err(ab, "failed to get rproc: %d\n", ret);
> > + if (ret)
> > goto err_ce_free;
> > - }
>
> If the rproc handle is unavailable at this point, we undo quite a bit of work
> in .probe.. would it make sense to move this check way above?
>
Given that devlink doesn't covers this, but presumably cover several of
the above resources, I think that would make sense. It would be a
separate patch regardless...
Regards,
Bjorn
> Konrad