[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2023081919-mockup-bootleg-bdb9@gregkh>
Date: Sat, 19 Aug 2023 12:50:07 +0200
From: Greg KH <gregkh@...uxfoundation.org>
To: "Limonciello, Mario" <mario.limonciello@....com>
Cc: Evan Quan <evan.quan@....com>, Andrew Lunn <andrew@...n.ch>,
rafael@...nel.org, lenb@...nel.org, johannes@...solutions.net,
davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
pabeni@...hat.com, alexander.deucher@....com,
rdunlap@...radead.org, quic_jjohnson@...cinc.com, horms@...nel.org,
linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-acpi@...r.kernel.org, amd-gfx@...ts.freedesktop.org,
linux-wireless@...r.kernel.org, netdev@...r.kernel.org
Subject: 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:
> > 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
Powered by blists - more mailing lists