Re: [PATCH] wifi: ath11k: Silence remoteproc probe deferral prints

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 <[email protected]>
> > ---
> >  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