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

Greg KH
2023-08-19T10:52:30Z

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