Re: invalid vht params rate 1920 100kbps nss 2 mcs 9
Dear Baochen,
Am 05.07.24 um 04:47 schrieb Baochen Qiang:
On 6/26/2024 5:12 PM, Paul Menzel wrote:
Am 26.06.24 um 10:53 schrieb Baochen Qiang:
On 6/18/2024 6:33 PM, Kalle Valo wrote:
+ baochen
James Prestwood writes:
On 6/17/24 8:27 AM, Kalle Valo wrote:
James Prestwood writes:
On 6/16/24 6:10 AM, Paul Menzel wrote:
Linux 6.10-rc3 (commit a3e18a540541) logged the warning below when
connecting to a public WiFi:
ath10k_pci :3a:00.0: invalid vht params rate 1920 100kbps nss 2 mcs 9
This has been reported/discussed [1]. It was hinted that there was a
firmware fix for this, but none that I tried got rid of it. I got fed
up enough with the logs filling up with this I patched our kernel to
remove the warning. AFAICT it appears benign (?). Removing the warning
was purely "cosmetic" so other devs stopped complaining about it :)
[1] https://www.mail-archive.com/ath10k@lists.infradead.org/msg13406.html
More reliable link to the discussion:
https://lore.kernel.org/ath10k/76a816d983e6c4d636311738396f97971b5523fb.1612915444.git.sk...@linuxfoundation.org/
I think we should add this workaround I mentioned in 2021:
"If the firmware still keeps sending invalid rates we should add a
specific check to ignore the known invalid values, but not all of
them."
https://lore.kernel.org/ath10k/87h7mktjgi@codeaurora.org/
I guess that would be mcs == 7 and rate == 1440?
I think its more than this combination (Paul's are different).
Good point.
So how many combinations are we willing to add here? Seems like that
could get out of hand if there are more than a few invalid
combinations.
Yeah, but there haven't been that many different values reported yet,
right? And I expect that ath10k user base will just get smaller in the
future so the chances are that we will get less reports.
Would we also want to restrict the workaround to specific
hardware/firmware?
Good idea, limiting per hardware would be simple to implement using
hw_params. Of course we could even limit this per firmware version using
enum ath10k_fw_features, but not sure if that's worth all the extra work.
Baochen, do you know more about this firmware bug? Any suggestions?
OK, there are two issues here:
1. invalid HT rate: "ath10k_pci :02:00.0: invalid ht params rate 1440 100kbps
nss 2 mcs 7".
As commented by Wen quite some time ago, this has been fixed from
firmware side, and firmware newer than [ver:241] has the fix
included.
This is the issue from 2021, correct?
2. invaid VHT rate: "ath10k_pci :3a:00.0: invalid vht params rate 1920 100kbps
nss 2 mcs 9".
After checking with firmware team, I thought this is because there is
a mismatch in rate definition between host and firmware: In host, the
rate for 'nss 2 mcs 9' is defined as {1560, 1733}, see
supported_vht_mcs_rate_nss2[]. While in firmware this is defined as
{1730, 1920}. So seems we can update host definition to avoid this
issue.
Looking through the logs since May 2024, I have four different logs:
1. invalid vht params rate 878 100kbps nss 3 mcs 2
which chip are you using when you hit this nss 3 issue? QCA6174
firmware does not support NSS 3 so really weird.
This is all from the same device Dell XPS 13 9360 with QCA6174 and
firmware 288.
```
Mai 20 12:07:09 abreu kernel: Linux version 6.9.0-09705-g08b269af52c0
(bu...@bohemianrhapsody.molgen.mpg.de) (gcc (Debian 13.2.0-23) 13.2.0,
GNU ld (GNU Binutils for Debian) 2.
42) #147 SMP PREEMPT_DYNAMIC Mon May 20 07:33:23 CEST 2024
[…]
Mai 20 12:07:11 abreu kernel: ath10k_pci :3a:00.0: firmware ver
WLAN.RM.4.4.1-00288- api 6 features wowlan,ignore-otp,mfp crc32 bf907c7c
[…]
Mai 20 15:37:55 abreu wpa_supplicant[613]: wlp58s0: Trying to associate
with e2:b3:70:83:01:af (SSID='public' freq=5500 MHz)
[…]
Mai 20 15:37:55 abreu kernel: wlp58s0: authenticate with
e2:b3:70:83:01:af (local address=9c:b6:d0:d1:6a:b1)
Mai 20 15:37:55 abreu kernel: wlp58s0: send auth to e2:b3:70:83:01:af
(try 1/3)
Mai 20 15:37:55 abreu kernel: wlp58s0: authenticated
Mai 20 15:37:55 abreu kernel: wlp58s0: associate with e2:b3:70:83:01:af
(try 1/3)
Mai 20 15:37:55 abreu kernel: wlp58s0: RX AssocResp from
e2:b3:70:83:01:af (capab=0x1501 status=0 aid=4)
[…]
Mai 20 15:39:29 abreu wpa_supplicant[613]: wlp58s0:
CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-55 noise=-97 txrate=30
[…]
Mai 20 15:54:44 abreu kernel: ath10k_pci :3a:00.0: invalid vht
params rate 878 100kbps nss 3 mcs 2
```
It was some public WiFi in some restaurant. No idea, what hardware they
use. Maybe you can deduce this from the MAC address.
2. invalid vht params rate 960 100kbps nss 1 mcs 9
3. invalid vht params rate 1730 100kbps nss 2 mcs 9
4. invalid vht params rate 1920 100kbps nss 2 mcs 9
OK, these are due to mismatch between host and QCA6174 firmware, we
can update host to fix them.
Nice. If there would be a test framework to test this, so I do not have
to search for a Cisco network, that’d be g
Re: invalid vht params rate 1920 100kbps nss 2 mcs 9
On 6/26/2024 5:12 PM, Paul Menzel wrote:
> Dear Baochen,
>
>
> Thank you for your reply.
>
> Am 26.06.24 um 10:53 schrieb Baochen Qiang:
>
>> On 6/18/2024 6:33 PM, Kalle Valo wrote:
>>> + baochen
>>>
>>> James Prestwood writes:
>
On 6/17/24 8:27 AM, Kalle Valo wrote:
> James Prestwood writes:
>
>> On 6/16/24 6:10 AM, Paul Menzel wrote:
>
>>> Linux 6.10-rc3 (commit a3e18a540541) logged the warning below when
>>> connecting to a public WiFi:
>>>
>>> ath10k_pci :3a:00.0: invalid vht params rate 1920 100kbps nss
>>> 2 mcs 9
>>
>> This has been reported/discussed [1]. It was hinted that there was a
>> firmware fix for this, but none that I tried got rid of it. I got fed
>> up enough with the logs filling up with this I patched our kernel to
>> remove the warning. AFAICT it appears benign (?). Removing the warning
>> was purely "cosmetic" so other devs stopped complaining about it :)
>>
>> [1] https://www.mail-archive.com/ath10k@lists.infradead.org/msg13406.html
>
> More reliable link to the discussion:
>
> https://lore.kernel.org/ath10k/76a816d983e6c4d636311738396f97971b5523fb.1612915444.git.sk...@linuxfoundation.org/
>
> I think we should add this workaround I mentioned in 2021:
>
> "If the firmware still keeps sending invalid rates we should add a
> specific check to ignore the known invalid values, but not all of
> them."
>
> https://lore.kernel.org/ath10k/87h7mktjgi@codeaurora.org/
>
> I guess that would be mcs == 7 and rate == 1440?
I think its more than this combination (Paul's are different).
>>>
>>> Good point.
>>>
So how many combinations are we willing to add here? Seems like that
could get out of hand if there are more than a few invalid
combinations.
>>>
>>> Yeah, but there haven't been that many different values reported yet,
>>> right? And I expect that ath10k user base will just get smaller in the
>>> future so the chances are that we will get less reports.
>>>
Would we also want to restrict the workaround to specific
hardware/firmware?
>>>
>>> Good idea, limiting per hardware would be simple to implement using
>>> hw_params. Of course we could even limit this per firmware version using
>>> enum ath10k_fw_features, but not sure if that's worth all the extra work.
>>>
>>> Baochen, do you know more about this firmware bug? Any suggestions?
>>
>> OK, there are two issues here:
>>
>> 1. invalid HT rate: "ath10k_pci :02:00.0: invalid ht params rate 1440
>> 100kbps nss 2 mcs 7".
>>
>> As commented by Wen quite some time ago, this has been fixed from
>> firmware side, and firmware newer than [ver:241] has the fix
>> included.
> This is the issue from 2021, correct?
>
>> 2. invaid VHT rate: "ath10k_pci :3a:00.0: invalid vht params rate 1920
>> 100kbps nss 2 mcs 9".
>>
>> After checking with firmware team, I thought this is because there is
>> a mismatch in rate definition between host and firmware: In host, the
>> rate for 'nss 2 mcs 9' is defined as {1560, 1733}, see
>> supported_vht_mcs_rate_nss2[]. While in firmware this is defined as
>> {1730, 1920}. So seems we can update host definition to avoid this
>> issue.
> Looking through the logs since May 2024, I have four different logs:
>
> 1. invalid vht params rate 878 100kbps nss 3 mcs 2
which chip are you using when you hit this nss 3 issue? QCA6174 firmware does
not support NSS 3 so really weird.
> 2. invalid vht params rate 960 100kbps nss 1 mcs 9
> 3. invalid vht params rate 1730 100kbps nss 2 mcs 9
> 4. invalid vht params rate 1920 100kbps nss 2 mcs 9
OK, these are due to mismatch between host and QCA6174 firmware, we can update
host to fix them.
>
> I believe it’s only happening with Cisco networks. I am happy to test a patch.
>
> By the way, is the firmware version logged by Linux?
>
> ath10k_pci :3a:00.0: qca6174 hw3.2 target 0x0503 chip_id
> 0x00340aff sub 1a56:1535
> ath10k_pci :3a:00.0: kconfig debug 0 debugfs 0 tracing 0 dfs 0
> testmode 0
> ath10k_pci :3a:00.0: firmware ver WLAN.RM.4.4.1-00288- api 6 features
> wowlan,ignore-otp,mfp crc32 bf907c7c
> ath10k_pci :3a:00.0: board_file api 2 bmi_id N/A crc32 d2863f91
> ath10k_pci :3a:00.0: htt-ver 3.87 wmi-op 4 htt-op 3 cal otp max-sta
> 32 raw 0 hwcrypto 1
>
> Is it 4.4.1-00288? How can I find the file in `/lib/firmware/`?
>
>
> Kind regards,
>
> Paul
[kvalo-ath:master] BUILD SUCCESS 73adcb561600d84aa21e06486766ca0ce64fc5a6
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git master branch HEAD: 73adcb561600d84aa21e06486766ca0ce64fc5a6 Add localversion-wireless-testing-ath elapsed time: 1453m configs tested: 178 configs skipped: 6 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: alpha allnoconfig gcc-13.2.0 alphaallyesconfig gcc-13.2.0 alpha defconfig gcc-13.2.0 arc allmodconfig gcc-13.2.0 arc allnoconfig gcc-13.2.0 arc allyesconfig gcc-13.2.0 arc defconfig gcc-13.2.0 arc nsimosci_hs_smp_defconfig gcc-13.2.0 arc randconfig-001-20240704 gcc-13.2.0 arc randconfig-002-20240704 gcc-13.2.0 arcvdk_hs38_defconfig gcc-13.2.0 arm allmodconfig gcc-13.2.0 arm allnoconfig gcc-13.2.0 arm allyesconfig gcc-13.2.0 arm defconfig gcc-13.2.0 arm lpc18xx_defconfig gcc-13.2.0 arm mv78xx0_defconfig gcc-13.2.0 arm mxs_defconfig gcc-13.2.0 arm orion5x_defconfig gcc-13.2.0 arm pxa168_defconfig gcc-13.2.0 arm randconfig-001-20240704 gcc-13.2.0 arm randconfig-002-20240704 gcc-13.2.0 arm randconfig-003-20240704 gcc-13.2.0 arm randconfig-004-20240704 gcc-13.2.0 arm rpc_defconfig gcc-13.2.0 arm64allmodconfig gcc-13.2.0 arm64 allnoconfig gcc-13.2.0 arm64 defconfig gcc-13.2.0 arm64 randconfig-001-20240704 gcc-13.2.0 arm64 randconfig-002-20240704 gcc-13.2.0 arm64 randconfig-003-20240704 gcc-13.2.0 arm64 randconfig-004-20240704 gcc-13.2.0 csky allnoconfig gcc-13.2.0 cskydefconfig gcc-13.2.0 csky randconfig-001-20240704 gcc-13.2.0 csky randconfig-002-20240704 gcc-13.2.0 i386 allmodconfig clang-18 i386 allnoconfig clang-18 i386 allyesconfig clang-18 i386 buildonly-randconfig-001-20240704 clang-18 i386 buildonly-randconfig-002-20240704 clang-18 i386 buildonly-randconfig-003-20240704 clang-18 i386 buildonly-randconfig-004-20240704 clang-18 i386 buildonly-randconfig-005-20240704 clang-18 i386 buildonly-randconfig-006-20240704 clang-18 i386defconfig clang-18 i386 randconfig-001-20240704 clang-18 i386 randconfig-002-20240704 clang-18 i386 randconfig-003-20240704 clang-18 i386 randconfig-004-20240704 clang-18 i386 randconfig-005-20240704 clang-18 i386 randconfig-006-20240704 clang-18 i386 randconfig-011-20240704 clang-18 i386 randconfig-012-20240704 clang-18 i386 randconfig-013-20240704 clang-18 i386 randconfig-014-20240704 clang-18 i386 randconfig-015-20240704 clang-18 i386 randconfig-016-20240704 clang-18 loongarchallmodconfig gcc-13.2.0 loongarch allnoconfig gcc-13.2.0 loongarch defconfig gcc-13.2.0 loongarch randconfig-001-20240704 gcc-13.2.0 loongarch randconfig-002-20240704 gcc-13.2.0 m68k allmodconfig gcc-13.2.0 m68k allnoconfig gcc-13.2.0 m68k allyesconfig gcc-13.2.0 m68k bvme6000_defconfig gcc-13.2.0 m68kdefconfig gcc-13.2.0 m68km5307c3_defconfig gcc-13.2.0 microblaze allmodconfig gcc-13.2.0 microblazeallnoconfig gcc-13.2.0 microblaze allyesconfig gcc-13.2.0 microblaze defconfig gcc-13.2.0 mips allnoconfig gcc-13.2.0 mips bmips_stb_defconfig gcc-13.2.0 mips db1xxx_defconfig gcc-13.2.0 mipsgpr_defconfig gcc-13.2.0 mips ip28_defconfig gcc-13.2.0 mips maltasmvp_eva_defconfig gcc-13.2.0 mips
[kvalo-ath:ath-next] BUILD SUCCESS c1cacb01f35589bd41360cdb7535afc792c08a7c
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git ath-next branch HEAD: c1cacb01f35589bd41360cdb7535afc792c08a7c Merge tag 'ath-next-20240702' of git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath elapsed time: 1450m configs tested: 185 configs skipped: 6 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: alpha allnoconfig gcc-13.2.0 alphaallyesconfig gcc-13.2.0 alpha defconfig gcc-13.2.0 arc allmodconfig gcc-13.2.0 arc allnoconfig gcc-13.2.0 arc allyesconfig gcc-13.2.0 arc defconfig gcc-13.2.0 arc nsimosci_hs_smp_defconfig gcc-13.2.0 arc randconfig-001-20240704 gcc-13.2.0 arc randconfig-002-20240704 gcc-13.2.0 arcvdk_hs38_defconfig gcc-13.2.0 arm allmodconfig gcc-13.2.0 arm allnoconfig gcc-13.2.0 arm allyesconfig gcc-13.2.0 arm defconfig gcc-13.2.0 arm lpc18xx_defconfig gcc-13.2.0 arm mv78xx0_defconfig gcc-13.2.0 arm mxs_defconfig gcc-13.2.0 arm orion5x_defconfig gcc-13.2.0 arm pxa168_defconfig gcc-13.2.0 arm randconfig-001-20240704 gcc-13.2.0 arm randconfig-002-20240704 gcc-13.2.0 arm randconfig-003-20240704 gcc-13.2.0 arm randconfig-004-20240704 gcc-13.2.0 arm rpc_defconfig gcc-13.2.0 arm64allmodconfig gcc-13.2.0 arm64 allnoconfig gcc-13.2.0 arm64 defconfig gcc-13.2.0 arm64 randconfig-001-20240704 gcc-13.2.0 arm64 randconfig-002-20240704 gcc-13.2.0 arm64 randconfig-003-20240704 gcc-13.2.0 arm64 randconfig-004-20240704 gcc-13.2.0 csky allnoconfig gcc-13.2.0 cskydefconfig gcc-13.2.0 csky randconfig-001-20240704 gcc-13.2.0 csky randconfig-002-20240704 gcc-13.2.0 i386 allmodconfig clang-18 i386 allnoconfig clang-18 i386 allyesconfig clang-18 i386 buildonly-randconfig-001-20240704 clang-18 i386 buildonly-randconfig-002-20240704 clang-18 i386 buildonly-randconfig-002-20240704 gcc-13 i386 buildonly-randconfig-003-20240704 clang-18 i386 buildonly-randconfig-003-20240704 gcc-13 i386 buildonly-randconfig-004-20240704 clang-18 i386 buildonly-randconfig-004-20240704 gcc-12 i386 buildonly-randconfig-005-20240704 clang-18 i386 buildonly-randconfig-005-20240704 gcc-12 i386 buildonly-randconfig-006-20240704 clang-18 i386 buildonly-randconfig-006-20240704 gcc-12 i386defconfig clang-18 i386 randconfig-001-20240704 clang-18 i386 randconfig-002-20240704 clang-18 i386 randconfig-002-20240704 gcc-13 i386 randconfig-003-20240704 clang-18 i386 randconfig-004-20240704 clang-18 i386 randconfig-004-20240704 gcc-13 i386 randconfig-005-20240704 clang-18 i386 randconfig-006-20240704 clang-18 i386 randconfig-006-20240704 gcc-12 i386 randconfig-011-20240704 clang-18 i386 randconfig-011-20240704 gcc-13 i386 randconfig-012-20240704 clang-18 i386 randconfig-013-20240704 clang-18 i386 randconfig-014-20240704 clang-18 i386 randconfig-015-20240704 clang-18 i386 randconfig-016-20240704 clang-18 loongarchallmodconfig gcc-13.2.0 loongarch allnoconfig gcc-13.2.0 loongarch defconfig gcc-13.2.0 loongarch randconfig-001-20240704 gcc-13.2.0 loongarch randconfig-002-20240704 gcc-13.2.0 m68k allmodconfig gcc-13.2.0 m68k allnoconfig gcc-13.2.0 m68k allyesconfig gcc-13.2.0 m68k bvme6000_defconfig gcc-13.2.0 m68kdefconfig gcc-13.2.0 m68km5307c3_defconfig gcc-13.2.0 microblaze allmodconfig
Re: [PATCH v3 00/21] iommu: Refactoring domain allocation interface
On Thu, Jul 04, 2024 at 10:24:52PM +0800, Baolu Lu wrote: > On 2024/7/4 22:18, Will Deacon wrote: > > On Mon, 10 Jun 2024 16:55:34 +0800, Lu Baolu wrote: > > > The IOMMU subsystem has undergone some changes, including the removal > > > of iommu_ops from the bus structure. Consequently, the existing domain > > > allocation interface, which relies on a bus type argument, is no longer > > > relevant: > > > > > > struct iommu_domain *iommu_domain_alloc(struct bus_type *bus) > > > > > > [...] > > Applied a few of these to iommu (iommufd/paging-domain-alloc), thanks! > > > > [01/21] iommu: Add iommu_paging_domain_alloc() interface > > https://git.kernel.org/iommu/c/a27bf2743cb8 > > [02/21] iommufd: Use iommu_paging_domain_alloc() > > https://git.kernel.org/iommu/c/26a581606fab > > [03/21] vfio/type1: Use iommu_paging_domain_alloc() > > https://git.kernel.org/iommu/c/60ffc4501722 > > [04/21] vhost-vdpa: Use iommu_paging_domain_alloc() > > https://git.kernel.org/iommu/c/9c159f6de1ae > > [05/21] drm/msm: Use iommu_paging_domain_alloc() > > https://git.kernel.org/iommu/c/45acf35af200 > > > > [10/21] wifi: ath10k: Use iommu_paging_domain_alloc() > > https://git.kernel.org/iommu/c/d5b7485588df > > [11/21] wifi: ath11k: Use iommu_paging_domain_alloc() > > https://git.kernel.org/iommu/c/ef50d41fbf1c > > > > [14/21] RDMA/usnic: Use iommu_paging_domain_alloc() > > https://git.kernel.org/iommu/c/3b10f25704be > > [15/21] iommu/vt-d: Add helper to allocate paging domain > > https://git.kernel.org/iommu/c/9e9ba576c259 > > Will, the patch [15/21] has already been included in my VT-d update pull > request. I have also addressed Yi's comment in that patch. So can you > please remove it from this branch? Heh, was just about to say the same thing as I noticed when I was re-creating 'next'. Yes, I'll drop it now. Since it's on the end, the other SHAs will remain the same. Sorry about that, Will
Re: [PATCH v3 00/21] iommu: Refactoring domain allocation interface
On 2024/7/4 22:18, Will Deacon wrote: On Mon, 10 Jun 2024 16:55:34 +0800, Lu Baolu wrote: The IOMMU subsystem has undergone some changes, including the removal of iommu_ops from the bus structure. Consequently, the existing domain allocation interface, which relies on a bus type argument, is no longer relevant: struct iommu_domain *iommu_domain_alloc(struct bus_type *bus) [...] Applied a few of these to iommu (iommufd/paging-domain-alloc), thanks! [01/21] iommu: Add iommu_paging_domain_alloc() interface https://git.kernel.org/iommu/c/a27bf2743cb8 [02/21] iommufd: Use iommu_paging_domain_alloc() https://git.kernel.org/iommu/c/26a581606fab [03/21] vfio/type1: Use iommu_paging_domain_alloc() https://git.kernel.org/iommu/c/60ffc4501722 [04/21] vhost-vdpa: Use iommu_paging_domain_alloc() https://git.kernel.org/iommu/c/9c159f6de1ae [05/21] drm/msm: Use iommu_paging_domain_alloc() https://git.kernel.org/iommu/c/45acf35af200 [10/21] wifi: ath10k: Use iommu_paging_domain_alloc() https://git.kernel.org/iommu/c/d5b7485588df [11/21] wifi: ath11k: Use iommu_paging_domain_alloc() https://git.kernel.org/iommu/c/ef50d41fbf1c [14/21] RDMA/usnic: Use iommu_paging_domain_alloc() https://git.kernel.org/iommu/c/3b10f25704be [15/21] iommu/vt-d: Add helper to allocate paging domain https://git.kernel.org/iommu/c/9e9ba576c259 Will, the patch [15/21] has already been included in my VT-d update pull request. I have also addressed Yi's comment in that patch. So can you please remove it from this branch? Thanks, baolu
Re: [PATCH v3 00/21] iommu: Refactoring domain allocation interface
On Mon, 10 Jun 2024 16:55:34 +0800, Lu Baolu wrote: > The IOMMU subsystem has undergone some changes, including the removal > of iommu_ops from the bus structure. Consequently, the existing domain > allocation interface, which relies on a bus type argument, is no longer > relevant: > > struct iommu_domain *iommu_domain_alloc(struct bus_type *bus) > > [...] Applied a few of these to iommu (iommufd/paging-domain-alloc), thanks! [01/21] iommu: Add iommu_paging_domain_alloc() interface https://git.kernel.org/iommu/c/a27bf2743cb8 [02/21] iommufd: Use iommu_paging_domain_alloc() https://git.kernel.org/iommu/c/26a581606fab [03/21] vfio/type1: Use iommu_paging_domain_alloc() https://git.kernel.org/iommu/c/60ffc4501722 [04/21] vhost-vdpa: Use iommu_paging_domain_alloc() https://git.kernel.org/iommu/c/9c159f6de1ae [05/21] drm/msm: Use iommu_paging_domain_alloc() https://git.kernel.org/iommu/c/45acf35af200 [10/21] wifi: ath10k: Use iommu_paging_domain_alloc() https://git.kernel.org/iommu/c/d5b7485588df [11/21] wifi: ath11k: Use iommu_paging_domain_alloc() https://git.kernel.org/iommu/c/ef50d41fbf1c [14/21] RDMA/usnic: Use iommu_paging_domain_alloc() https://git.kernel.org/iommu/c/3b10f25704be [15/21] iommu/vt-d: Add helper to allocate paging domain https://git.kernel.org/iommu/c/9e9ba576c259 Cheers, -- Will https://fixes.arm64.dev https://next.arm64.dev https://will.arm64.dev
Re: [PATCH v3 04/21] vhost-vdpa: Use iommu_paging_domain_alloc()
On Wed, Jul 03, 2024 at 12:32:06PM -0400, Michael S. Tsirkin wrote: > On Mon, Jun 10, 2024 at 04:55:38PM +0800, Lu Baolu wrote: > > Replace iommu_domain_alloc() with iommu_paging_domain_alloc(). > > > > Signed-off-by: Lu Baolu > > Acked-by: Michael S. Tsirkin > > > I assume it's merged with the rest of the stuff, right? Sure, I can grab this one in the iommu tree. It has to go along with the patch adding iommu_paging_domain_alloc() anyway. Will
