+++ This bug was initially created as a clone of Bug #2047878 +++ 1. Please describe the problem: The Qualcomm NFA765 is used on a number of 2021 AMD platforms and will be used on some 2022 platforms. Support for this device has landed so I'd like to get supported added to Fedora. I've tested a build from os-build from kernel-ark and all that is needed with that is to install the firmware files to make it work. Note - I don't believe the driver support is present in the F35 branch yet, but will be there with 5.16.5 rebase. On the FW side of things I've tested the updates here: https://github.com/kvalo/ath11k-firmware/tree/master/WCN6855/hw2.0 I needed: - board-2.bin and regdb.bin from WCN6855/hw2.0 - amss.bin and m3.bin from WCN6855/hw2.0/1.1/WLAN.HSP.1.1-02892.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1 (though the 03003 version is good too) to be placed in /lib/firmware/ath11k/WCN6855/hw2.0 Unfortunately I don't see these in the linux-firmware repository yet - but is there a way we can pull this into the Fedora release somehow please? 2. What is the Version-Release number of the kernel: 5.16 3. Did it work previously in Fedora? If so, what kernel version did the issue *first* appear? Old kernels are available for download at https://koji.fedoraproject.org/koji/packageinfo?packageID=8 : No 4. Can you reproduce this issue? If so, please provide the steps to reproduce the issue below: Yes - and happy to help with testing for this one. 5. Does this problem occur with the latest Rawhide kernel? To install the Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by ``sudo dnf update --enablerepo=rawhide kernel``: Yes 6. Are you running any modules that not shipped with directly Fedora's kernel?: No 7. Please attach the kernel logs. You can get the complete kernel log for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the issue occurred on a previous boot, use the journalctl ``-b`` flag. I'll add these if you need them - but they're not very exciting and I'll have to go extract them from the DUT
> Unfortunately I don't see these in the linux-firmware repository yet - but > is there a way we can pull this into the Fedora release somehow please? We generally don't ship firmware that isn't upstream in linux-firmware because that covers various legal review. Are these firmware generic QCom modules or are they Lenovo specific, if the former has Lenovo engaged with QCom to get them submitted upstream? I don't see reference to them on the list [1] [1] https://lore.kernel.org/linux-firmware/
Hi Peter, These are generic - not Lenovo specific. And they are supposed to be going upstream, I just don't think they've made it. I'll ping the Qualcomm folks on it to get details and confirm, but with it being Chinese New Year I won't hear back until at least next week. It might be worth checking with Íñigo Huguet <ihuguet> as I believe they've pulled this in for RHEL so he might have found some details I missed. Mark
(In reply to Mark Pearson from comment #2) > It might be worth checking with Íñigo Huguet <ihuguet> as I > believe they've pulled this in for RHEL so he might have found some details > I missed. We've made some testing using the mentioned firmware to confirm that it's working, but like in Fedora, it will not be packaged into RHEL until it's included in linux-firmware repo.
Got it! Thanks for the clarification. I got an auto-reply from the folk at Qualcomm that they are out this week so I'll chase this next week and get an update. Mark
(In reply to Peter Robinson from comment #1) > > Unfortunately I don't see these in the linux-firmware repository yet - but > > is there a way we can pull this into the Fedora release somehow please? > > We generally don't ship firmware that isn't upstream in linux-firmware > because that covers various legal review. Right, note though that the repo used by Mark to test: https://github.com/kvalo/ath11k-firmware/tree/master/WCN6855/hw2.0 Is the offical upstream repository from the qca/ath kernel driver folks. So one can be reasonably sure that any firmware there has been pushed there with permission from qca/ath. So my initial thought here was that someone (e.g. me) could just take the files form there and submit them to linux-firmware, but unfortunately that repo uses a slightly different license as the linux-firmware repo, comparing: https://raw.githubusercontent.com/kvalo/ath11k-firmware/master/LICENSE.qca_firmware and: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/LICENSE.QualcommAtheros_ar3k Shows that the latter has the following extra section: "Limited patent license. Qualcomm Atheros, Inc. (“Licensor”) grants you (“Licensee”) a limited, worldwide, royalty-free, non-exclusive license under the Patents to make, have made, use, import, offer to sell and sell the Software. No hardware per se is licensed hereunder. The term “Patents” as used in this agreement means only those patents or patent applications owned solely and exclusively by Licensor as of the date of Licensor’s submission of the Software and any patents deriving priority (i.e., having a first effective filing date) therefrom. The term “Software” as used in this agreement means the firmware image submitted by Licensor, under the terms of this license, to git://git.kernel.org/pub/scm/linux/kernel/git/firmware/ linux-firmware.git. Notwithstanding anything to the contrary herein, Licensor does not grant and Licensee does not receive, by virtue of this agreement or the Licensor’s submission of any Software, any license or other rights under any patent or patent application owned by any affiliate of Licensor or any other entity (other than Licensor), whether expressly, impliedly, by virtue of estoppel or exhaustion, or otherwise." What is esp. relevant here is the "the firmware image submitted by Licensor", which seems to indicate that someone from Qualcomm, or at least someone acting on behalf of Qualcomm needs to submit these. So Mark, it seems that to get this resolved you will need to get Qualcomm to submit the necessary firmware files themselves.
Thanks Hans, I heard from Qualcomm this morning and they are working on getting it into linux-firmware, and were resolving some 'licence issues' - which I suspect is related to the above. I'll keep pushing them to complete the submission to linux-firmware, they know it is gating doing a Fedora release on the P14s AMD platform. Thanks for looking at this - those licence files make me go cross-eyed ;) Mark
> So my initial thought here was that someone (e.g. me) could just take the > files form there and submit them to linux-firmware, but unfortunately that > repo uses a slightly different license as the linux-firmware repo, comparing: I don't believe that is sustainable, are you going to follow the repository and upstream CVEs and ensure all new versions that add new HW variants or fix CVEs and ensure that legal things haven't changed and get them upstreamed? I think Qualcomm should have someone actively doing this to ensure a good experience for all QCom atheros devices. From experience of dealing with other QCom atheros devices in the past, check the linux-firmware bugs both open and closed, their ability to "maintain" the firmware to a reasonable stability is doubtful to me but if Lenovo can push to get them to at least have a process and escalation contacts for them I for one would welcome that, personally until QCom actually maintain them themselves I don't thing random engineers should not be enabling the support of these devices, as it will just become a millstone around your neck.
(In reply to Peter Robinson from comment #7) > > So my initial thought here was that someone (e.g. me) could just take the > > files form there and submit them to linux-firmware, but unfortunately that > > repo uses a slightly different license as the linux-firmware repo, comparing: > > I don't believe that is sustainable, are you going to follow the repository > and upstream CVEs and ensure all new versions that add new HW variants or > fix CVEs and ensure that legal things haven't changed and get them > upstreamed? I think Qualcomm should have someone actively doing this to > ensure a good experience for all QCom atheros devices. I agree, I merely thought that this might be a short term fix to remove the blocker for Lenovo here, but as mentioned unfortunately that is not possible either.
For reference these updates are in the latest linux-firmware: - QCA: Add Bluetooth nvm file for WCN685x - QCA: Update Bluetooth WCN685x 2.1 firmware to 2.1.0-00324 - QCA: Update Bluetooth WCN685x 2.0 firmware to 2.0.0-00609 I don't believe they're the ones needed but just for reference.
Qualcomm have delivered the firmware up to linux-firmware now. All under https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/ath11k/WCN6855/hw2.0 I believe the relevant commits are: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=05b5dc0014b2775d775a493f7f3560169b50c5e2 https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=36f2ea9f7931a09918a2cdd4a30f5a611c2d7f32 https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=e8bc0db413b4ab7f8e540ffa17991ff61252de9c I checked and these are the same files I tested from the Qualcomm repository (https://github.com/kvalo/ath11k-firmware) Can we get these pulled into Fedora to support the AMD platforms (both 2021 and 2022) please? Let me know if that's something I can help with - never done that process before though :) Thanks Mark
So we generally will rebase to each of the upstream tagged releases which are generally monthly so we should have another release shortly.
(In reply to Peter Robinson from comment #11) > So we generally will rebase to each of the upstream tagged releases which > are generally monthly so we should have another release shortly. Available now.
(In reply to Josh Boyer from comment #12) > (In reply to Peter Robinson from comment #11) > > So we generally will rebase to each of the upstream tagged releases which > > are generally monthly so we should have another release shortly. > > Available now. As if by magic :-D thanks Josh
Wow! Thanks guys - that's fantastic So what's the recommended way of picking this up to test it (I have a system ready to go here)? And for it then making it's way into the F35 release? Mark
> So what's the recommended way of picking this up to test it (I have a system > ready to go here)? And for it then making it's way into the F35 release? The usual fedora updates process ;-)
FEDORA-2022-21cd9a78e2 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-21cd9a78e2
FEDORA-2022-1229886987 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-1229886987
FEDORA-2022-e5c03af85e has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2022-e5c03af85e
FEDORA-2022-1229886987 has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-1229886987` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-1229886987 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-e5c03af85e has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-e5c03af85e` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-e5c03af85e See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-21cd9a78e2 has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-21cd9a78e2` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-21cd9a78e2 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-1229886987 has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report.
Just a note - tested updated F35 on an L15G2 with the Qualcomm Wifi and it all worked beautifully. Thanks for making this happen so fast - it's amazing! Mark
FEDORA-2022-e5c03af85e has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2022-21cd9a78e2 has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report.