linux-kernel - Re: [PATCH 0/9] Support Wifi RFI interference mitigation feature

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] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 30 May 2023 10:34:13 -0500
From:   "Limonciello, Mario" <mario.limonciello@....com>
To:     Felix Fietkau <nbd@....name>, Evan Quan <evan.quan@....com>,
        rafael@...nel.org, lenb@...nel.org, alexander.deucher@....com,
        christian.koenig@....com, Xinhui.Pan@....com, airlied@...il.com,
        daniel@...ll.ch, kvalo@...nel.org, lorenzo@...nel.org,
        ryder.lee@...iatek.com, shayne.chen@...iatek.com,
        sean.wang@...iatek.com, matthias.bgg@...il.com,
        angelogioacchino.delregno@...labora.com, Lijo.Lazar@....com
Cc:     linux-kernel@...r.kernel.org, linux-acpi@...r.kernel.org,
        amd-gfx@...ts.freedesktop.org, dri-devel@...ts.freedesktop.org,
        linux-wireless@...r.kernel.org, ath11k@...ts.infradead.org,
        ath12k@...ts.infradead.org
Subject: Re: [PATCH 0/9] Support Wifi RFI interference mitigation feature


On 5/30/2023 1:22 AM, Felix Fietkau wrote:
> On 30.05.23 04:42, Evan Quan wrote:
>> Due to electrical and mechanical constraints in certain platform 
>> designs there may
>> be likely interference of relatively high-powered harmonics of the 
>> (G-)DDR memory
>> clocks with local radio module frequency bands used by Wifi 6/6e/7. 
>> To mitigate
>> possible RFI interference producers can advertise the frequencies in 
>> use and
>> consumers can use this information to avoid using these frequencies for
>> sensitive features.
>>
>> The whole patch set is based on 6.4-rc3. With some brief 
>> introductions as below:
>> Patch1:     Core ACPI interfaces needed to support WBRF feature.
>> Patch2 - 4: Enable WBRF support for some Mediatek and Qualcomm wifi 
>> drivers.
>> Patch5 - 9: Enable WBRF support for AMD graphics driver.
>>
>> Anson Tsao (1):
>>    wifi: ath11k: Add support to the Qualcomm ath11k for ACPI WBRF
>>
>> Evan Quan (6):
>>    wifi: ath12k: Add support to the Qualcomm ath12k for ACPI WBRF
>>    drm/amd/pm: update driver_if and ppsmc headers for coming wbrf 
>> feature
>>    drm/amd/pm: setup the framework to support Wifi RFI mitigation 
>> feature
>>    drm/amd/pm: add flood detection for wbrf events
>>    drm/amd/pm: enable Wifi RFI mitigation feature support for SMU13.0.0
>>    drm/amd/pm: enable Wifi RFI mitigation feature support for SMU13.0.7
>>
>> Mario Limonciello (2):
>>    drivers/acpi: Add support for Wifi band RF mitigations
>>    mt76: Add support to the Mediatek MT7921 for ACPI WBRF
> Wouldn't it make more sense to put this in mac80211 or cfg80211 
> instead of duplicating the logic in different drivers?
>
> - Felix
>
I think it's generally a sensible proposal, but there are a few things 
that need to be agreed upon to find the right places
for everything.

1) The actual notifying, would it make sense to put it directly into 
these functions?

ieee80211_add_chanctx / ieee80211_del_chanctx

2) "Where" should the WBRF support detection need to happen?

wbrf_supported_producer needs to have an argument of the ACPI companion 
for the device.
What level *should* the ACPI device be found?
Should that still be individual drivers calling a mac80211 helper 
function to indicate they're opting in?
Or should there there be some CONFIG_ACPI_WBRF gated helper as part of a 
driver registration?