[PATCH V7 4/9] wifi: mac80211: Add support for ACPI WBRF

[Quan, Evan]

[AMD Official Use Only - General]

Hi Andrew,

I sent out a new V8 series last week.
A kernel parameter `wbrf` was introduced there to decide the policy.
Please help to check whether that makes sense to you.
Please share your insights there.

BR,
Evan
> -----Original Message-----
> From: Andrew Lunn <andrew at lunn.ch>
> Sent: Wednesday, July 26, 2023 4:10 AM
> To: Limonciello, Mario <Mario.Limonciello at amd.com>
> Cc: Quan, Evan <Evan.Quan at amd.com>; rafael at kernel.org; lenb at kernel.org;
> Deucher, Alexander <Alexander.Deucher at amd.com>; Koenig, Christian
> <Christian.Koenig at amd.com>; Pan, Xinhui <Xinhui.Pan at amd.com>;
> airlied at gmail.com; daniel at ffwll.ch; johannes at sipsolutions.net;
> davem at davemloft.net; edumazet at google.com; kuba at kernel.org;
> pabeni at redhat.com; mdaenzer at redhat.com;
> maarten.lankhorst at linux.intel.com; tzimmermann at suse.de;
> hdegoede at redhat.com; jingyuwang_vip at 163.com; Lazar, Lijo
> <Lijo.Lazar at amd.com>; jim.cromie at gmail.com; bellosilicio at gmail.com;
> andrealmeid at igalia.com; trix at redhat.com; jsg at jsg.id.au; arnd at arndb.de;
> linux-kernel at vger.kernel.org; linux-acpi at vger.kernel.org; amd-
> gfx at lists.freedesktop.org; dri-devel at lists.freedesktop.org; linux-
> wireless at vger.kernel.org; netdev at vger.kernel.org
> Subject: Re: [PATCH V7 4/9] wifi: mac80211: Add support for ACPI WBRF
> 
> > This comes back to the point that was mentioned by Johannes - you need
> > to have deep design understanding of the hardware to know whether or
> > not you will have producers that a consumer need to react to.
> 
> Yes, this is the policy is keep referring to. I would expect that there is something
> somewhere in ACPI which says for this machine, the policy is Yes/No.
> 
> It could well be that AMD based machine has a different ACPI extension to
> indicate this policy to what Intel machine has. As far as i understand it, you
> have not submitted this yet for formal approval, this is all vendor specific, so
> Intel could do it completely differently. Hence i would expect a generic API to
> tell the core what the policy is, and your glue code can call into ACPI to find out
> that information, and then tell the core.
> 
> > If all producers indicate their frequency and all consumers react to
> > it you may have activated mitigations that are unnecessary. The
> > hardware designer may have added extra shielding or done the layout
> > such that they're not needed.
> 
> And the policy will indicate No, nothing needs to be done. The core can then
> tell produces and consumes not to bother telling the core anything.
> 
> > So I don't think we're ever going to be in a situation that the
> > generic implementation should be turned on by default.  It's a "developer
> knob".
> 
> Wrong. You should have a generic core, which your AMD CPU DDR device
> plugs into. The Intel CPU DDR device can plug into, the nvidea GPU can plug
> into, your Radeon GPU can plug into, the intel ARC can plug into, the generic
> WiFi core plugs into, etc.
> 
> > If needed these can then be enabled using the AMD ACPI interface, a DT
> > one if one is developed or maybe even an allow-list of SMBIOS strings.
> 
> Notice i've not mentioned DT for a while. I just want a generic core, which
> AMD, Intel, nvidea, Ampare, Graviton, Qualcomm, Marvell, ..., etc can use. We
> should be solving this problem once, for everybody, not adding a solution for
> just one vendor.
> 
>       Andrew