| Message ID | 20230530024227.2139632-1-evan.quan@amd.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Support Wifi RFI interference mitigation feature | expand |
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
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?