Linux wireless drivers development
 help / color / mirror / Atom feed
From: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
To: Nazar Mokrynskyi <nazar@mokrynskyi.com>, ath12k@lists.infradead.org
Cc: linux-wireless@vger.kernel.org, jeff.johnson@oss.qualcomm.com
Subject: Re: [PATCH 1/2] wifi: ath12k: skip PCIe global reset on initial power-up
Date: Mon, 13 Jul 2026 11:03:59 +0800	[thread overview]
Message-ID: <fe668799-6024-4370-acfc-ee64fb3a4d5c@oss.qualcomm.com> (raw)
In-Reply-To: <20260505172415.566328-2-nazar@mokrynskyi.com>



On 5/6/2026 1:24 AM, Nazar Mokrynskyi wrote:
> ath12k_pci_sw_reset() unconditionally calls ath12k_pci_soc_global_reset()
> regardless of whether the device is being powered up for the first time or
> recovering from a previous run. The global reset drops the PCIe link and
> relies on the host root complex to perform physical link retraining before
> the MHI BHI register can be accessed.
> 
> When the device is passed through to a VM via VFIO, no physical link
> retraining occurs after the reset since QEMU's virtual PCIe bridge does
> not implement hardware LTSSM negotiation. As a result, all subsequent
> MMIO reads return 0xffffffff and MHI initialization fails with -EREMOTEIO.
> 
> On initial power-up, vfio-pci has already performed a Function Level
> Reset before handing the device to the guest driver, placing it in a
> known clean state equivalent to what the global reset achieves. The global

AFAIK this is not the fact. Some internal registers are not cleanly reset without a global
reset.

> reset is therefore redundant on power-up and only necessary on the
> shutdown/recovery path where it tears down an already-running firmware.

is ath12k recovery working in Qemu in your setup? I doubt it since recovery would also hit
the link retraining issue ? Also how about the rmmod / insmod sequence in Qemu, since
rmmod also triggers global reset ?

To me this is more like a Qemu/vfio issue than a driver issue. The QEMU's behavior that
virtual PCIe bridge does not implement hardware LTSSM negotiation basically breaks all
hardware requiring runtime PCIe link retraining. Not sure why it is designed like this. If
it can not be fixed/changed in Qemu, can we do it in the host vfio?

> 
> Skip ath12k_pci_soc_global_reset() when power_on is true to allow MHI
> initialization to succeed under VFIO passthrough without affecting bare
> metal behavior.
> 
> Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1
> 
> Signed-off-by: Nazar Mokrynskyi <nazar@mokrynskyi.com>
> ---
>  drivers/net/wireless/ath/ath12k/pci.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/wireless/ath/ath12k/pci.c b/drivers/net/wireless/ath/ath12k/pci.c
> index 375277ca2..a3d7aeb72 100644
> --- a/drivers/net/wireless/ath/ath12k/pci.c
> +++ b/drivers/net/wireless/ath/ath12k/pci.c
> @@ -303,7 +303,8 @@ static void ath12k_pci_sw_reset(struct ath12k_base *ab, bool power_on)
>  
>  	ath12k_mhi_clear_vector(ab);
>  	ath12k_pci_clear_dbg_registers(ab);
> -	ath12k_pci_soc_global_reset(ab);
> +	if (!power_on)
> +		ath12k_pci_soc_global_reset(ab);
>  	ath12k_mhi_set_mhictrl_reset(ab);
>  }
>  


  reply	other threads:[~2026-07-13  3:04 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-05 17:24 [PATCH 0/2] wifi: ath12k: Fix operation under virtio Nazar Mokrynskyi
2026-05-05 17:24 ` [PATCH 1/2] wifi: ath12k: skip PCIe global reset on initial power-up Nazar Mokrynskyi
2026-07-13  3:03   ` Baochen Qiang [this message]
2026-07-13  3:34     ` Nazar Mokrynskyi
2026-05-05 17:24 ` [PATCH 2/2] wifi: ath12k: skip unknown direct buffer ring module IDs Nazar Mokrynskyi
2026-05-11 19:02   ` Jeff Johnson
2026-05-11 20:10     ` Nazar Mokrynskyi
2026-06-30  3:52       ` Nazar Mokrynskyi
2026-06-30 14:56         ` Jeff Johnson

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=fe668799-6024-4370-acfc-ee64fb3a4d5c@oss.qualcomm.com \
    --to=baochen.qiang@oss.qualcomm.com \
    --cc=ath12k@lists.infradead.org \
    --cc=jeff.johnson@oss.qualcomm.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=nazar@mokrynskyi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox