AMD Revises WiFi RFI Mitigation Feature For Linux

[phoronix]

Phoronix: AMD Revises WiFi RFI Mitigation Feature For Linux

Besides Bcachefs missing out on Linux 6.5, another patch series that didn't get buttoned up in time for the v6.5 merge window was AMD's work on radio frequency interference (RFI) mitigation between WiFi 6/6e/7 hardware and AMD's newest SoCs with RDNA3 graphics...

https://www.phoronix.com/news/AMD-WiFi-RFI-Linux-v6

[zexelon]

While its amazing what you can do in software these days, isn't this exactly the sort of thing that the FCC type organizations are supposed to enforce in hardware?

[Vorpal]

How does this work? Does it make the memory run at a different frequency if you are connected to a network on one of the affected frequencies? That would make sense.

But from the description it almost sound like the reverse? Where it prevents the WiFi chipset from using certain frequencies? Which doesn't make sense, since it is typically the channel that the AP is on that decides the frequency. So the user wouldn't be able to use certain networks? Which seems utterly backwards.

EDIT: Went and read the patches. It is the former. It was just Michael's article that was a bit ambiguous.

[stormcrow]

While its amazing what you can do in software these days, isn't this exactly the sort of thing that the FCC type organizations are supposed to enforce in hardware?

Only on a 30k foot level.

Inside the unlicensed bands that WIFI, BlueTooth, and other standards work in it's up to those standards to work out implementations that allow each standard to work together without stepping over each other. It's also up to the standards and implementations to work out how to make these standards such that users aren't completely trampling over each other as well even when using the same technologies in the same frequency bands.

But as far as this goes, this is also about board level RFI which is below the radar of FCC. The enforcement bodies are only concerned if you exceed certain thresholds, which are above this kind of mutual interference. Much of electrical engineering is about managing circuit level details in minimizing the noise between different parts of electronic systems in the same product let alone different products. Too much noise and your signal is drowned. This holds true regardless of whether you're designing a computer component, audio component, or just a simple table clock. At least, this is the desired outcome... There's a reason PRC made lighting is notorious with regulatory bodies, commercial & amateur radio operators, audio enthusiasts, and green house owners. Course... the narco squads love it.

[kiffmet]

This issue stems from physical memory clocks now being around the 2.4Ghz mark, which is exactly the frequency that 802.11bgn and Bluetooth are using.

By communicating the exact clockspeed to the wifi-driver, it can choose a channel with less overlap with the RAM or a smaller frequency band. If the communication works the other way around, than the system firmware may be able to also adjust the RAM clocks by ±40mhz (2 channels) or so in order to minimize overlap.

This idea is basically the same as with spread spectrum clocking, but implemented in a cooperative/"smart" way. People using 5Ghz Wifi will be unaffected until DDRx-10000 becomes a thing.

[Gro_]

Wow ! That's great ! Is there any official protocol used to announce/advise used frequency in a system ?
Are you aware of something like that used in MS or APPLE Os ?
I have never hear such a thing but it will certainly be a need since all freqs will converge to the upper level ... and everybody will have to deal with shared frequencys.

[kiffmet]

@Gro There's an ACPI firmware interface, so other OSes can utilize this feature aswell. Still needs driver support though. The interface itself is AMD specific, but Intel got something similar - no standardization here.