Re: [PATCH] wifi: ath11k: Add a warning for wcn6855 spurious wakeup events

[Mario Limonciello]

On 2/27/23 06:36, Kalle Valo wrote:
> Mario Limonciello <mario.limonciello@xxxxxxx> writes:
>
> > When WCN6855 firmware versions less than 0x110B196E are used with
> > an AMD APU and the user puts the system into s2idle spurious wakeup
> > events can occur. These are difficult to attribute to the WLAN F/W
> > so add a warning to the kernel driver to give users a hint where
> > to look.
> >
> > This was tested on WCN6855 and a Lenovo Z13 with the following
> > firmware versions:
> > WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.9
> > WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.23
> >
> > Link: http://lists.infradead.org/pipermail/ath11k/2023-February/004024.html
> > Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2377
> > Link: https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/2006458
> > Link: https://lore.kernel.org/linux-gpio/20221012221028.4817-1-mario.limonciello@xxxxxxx/
> > Signed-off-by: Mario Limonciello <mario.limonciello@xxxxxxx>
>
> [...]
>
> > +static void ath11k_check_s2idle_bug(struct ath11k_base *ab)
> > +{
> > +	struct pci_dev *rdev;
> > +
> > +	if (pm_suspend_target_state != PM_SUSPEND_TO_IDLE)
> > +		return;
> > +
> > +	if (ab->id.device != WCN6855_DEVICE_ID)
> > +		return;
> > +
> > +	if (ab->qmi.target.fw_version >= WCN6855_S2IDLE_VER)
> > +		return;
> > +
> > +	rdev = pci_get_domain_bus_and_slot(0, 0, PCI_DEVFN(0, 0));
> > +	if (rdev->vendor == PCI_VENDOR_ID_AMD)
> > +		ath11k_warn(ab, "fw_version 0x%x may cause spurious wakeups. Upgrade to 0x%x or later.",
> > +			    ab->qmi.target.fw_version, WCN6855_S2IDLE_VER);
>
> I understand the reasons for this warning but I don't really trust the
> check 'ab->qmi.target.fw_version >= WCN6855_S2IDLE_VER'. I don't know
> how the firmware team populates the fw_version so I'm worried that if we
> ever switch to a different firmware branch (or similar) this warning
> might all of sudden start triggering for the users.

In that case, maybe would it be better to just have a list of the public 
firmware with issue and ensure it doesn't match one of those?