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

[Mario Limonciello <mario.limonciello@amd.com>]

On 2/27/23 06:36, Kalle Valo wrote:
> Mario Limonciello <mario.limonciello@amd.com> 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@amd.com/
>> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
> 
> [...]
> 
>> +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?