linux-kernel - RE: [PATCH] wifi: ath11k: Add a warning for wcn6855 spurious wakeup events

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <MN0PR12MB6101F8C3E851055F03FA37B7E2909@MN0PR12MB6101.namprd12.prod.outlook.com>
Date:   Wed, 5 Apr 2023 20:47:34 +0000
From:   "Limonciello, Mario" <Mario.Limonciello@....com>
To:     Kalle Valo <kvalo@...nel.org>
CC:     "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        "ath11k@...ts.infradead.org" <ath11k@...ts.infradead.org>,
        "linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] wifi: ath11k: Add a warning for wcn6855 spurious wakeup
 events

[Public]

> > On 2/27/23 07:14, Kalle Valo wrote:
> >
> >> Mario Limonciello <mario.limonciello@....com> writes:
> >>
> >>> On 2/27/23 06:36, Kalle Valo wrote:
> >>>
> >>>> Mario Limonciello <mario.limonciello@....com> writes:
> >>>>
> >>>>> +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?
> >>
> >> You mean ath11k checking for known broken versions and reporting that?
> >> We have so many different firmwares to support in ath11k, I'm not really
> >> keen on adding tests for a specific version.
> >
> > I checked and only found a total of 7 firmware versions published for
> > WCN6855 at your ath11k-firmware repo.  I'm not sure how many went to
> > linux-firmware.  But it seems like a relatively small list to have.
> 
> ath11k supports also other hardware families than just WCN6855, so there
> are a lot of different firmware versions and branches.

Right, but this change was explicitly checking the device ID matched WCN6855.

So it could be a single check for that device and any of the 5 bad firmware binaries.

> 
> >> We have a list of known important bugs in the wiki:
> >>
> >>
> https://wireless.wiki.kernel.org/en/users/drivers/ath11k#known_bugslimita
> tions
> >>
> >> What about adding the issue there, would that get more exposure to the
> >> bug and hopefully the users would upgrade the firmware?
> >>
> >
> > The problem is when this happens users have no way to know it's even
> > caused by wireless.  So why would they go looking at the wireless
> > wiki?
> >
> > The GPIO used for WLAN is different from design to design so we can't
> > put it in the GPIO driver.  There are plenty of designs that have
> > valid reasons to wakeup from other GPIOs as well so it can't just be
> > the GPIO driver IRQ.
> 
> I understand your problem but my problem is that I have three Qualcomm
> drivers to support and that's a major challenge itself. So I try to keep
> the drivers as simple as possible and avoid any hacks.

OK.