On 8/19/2023 5:50 AM, Greg KH wrote:
On Fri, Aug 18, 2023 at 05:49:14PM -0500, Limonciello, Mario wrote:
On 8/18/2023 4:24 PM, Greg KH wrote:
On Fri, Aug 18, 2023 at 11:26:11AM +0800, Evan Quan wrote:
drivers/base/Makefile | 1 +
drivers/base/wbrf.c | 280 ++++++++++++++++++
Why is a wifi-specific thing going into drivers/base/?
confused,
greg k-h
The original problem statement was at a high level 'there can be
interference between different devices operating at high frequencies'. The
original patches introduced some ACPI library code that enabled a mitigated
for this interference between mac80211 devices and amdgpu devices.
Andrew Lunn wanted to see something more generic, so the series has morphed
into base code for things to advertise frequencies in use and other things
to listen to frequencies in use and react.
The idea is supposed to be that if the platform knows that these mitigations
are needed then the producers send the frequencies in use, consumers react
to them. The AMD implementation of getting this info from the platform
plugs into the base code (patch 2).
If users don't want this behavior they can turn it off on kernel command
line.
If the platform doesn't know mitigations are needed but user wants to turn
them on anyway they can turn it on kernel command line.
That's all fine, I don't object to that at all. But bus/device-specific
stuff should NOT be in drivers/base/ if at all possible (yes, we do have
some exceptions with hypervisor.c and memory and cpu stuff) but for a
frequency thing like this, why can't it live with the other
wifi/frequency code in drivers/net/wireless/?
In other words, what's the benefit to having me be the maintainer of
this, someone who knows nothing about this subsystem, other than you
passing off that work to me? :)
thanks,
greg k-h
The reason drivers/base was proposed was because although the initial
implementation is for producers from mac80211, Andrew pointed out that
many other things can technically be producers and cause interference
if not properly shielded.
So by making it part of base that sets up the policy that if something
"can" produce certain problematic harmonics that it can participate.
Whether or not other devices /will/ use this is another question though.
You need deep platform knowledge and proper equipment to diagnose a
problem and conclude it can be helped with this kind of mitigation.
So I wonder if the right answer is to put it in drivers/net/wireless
initially and if we come up with a need later for non wifi producers we
can discuss moving it at that time.
