Re: [V9 1/9] drivers core: Add support for Wifi band RF mitigations

On Fri, Aug 18, 2023 at 05:49:14PM -0500, Limonciello, Mario wrote:

On 8/18/2023 4:24 PM, Greg KH wrote:

quoted

On Fri, Aug 18, 2023 at 11:26:11AM +0800, Evan Quan wrote:

quoted

  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