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

[Konrad Dybcio]

On 2/12/26 4:16 PM, Bjorn Andersson wrote:
> 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 at oss.qualcomm.com>
>>> ---
>>>  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?

s/that/than

i.e. "no"

> 
>>
>>>  	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...

Yeah, I'm simply thinking out loud

For this one:

Reviewed-by: Konrad Dybcio <konrad.dybcio at oss.qualcomm.com>

Konrad