RE: [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@xxxxxxx>
> Sent: Wednesday, July 26, 2023 4:10 AM
> To: Limonciello, Mario <Mario.Limonciello@xxxxxxx>
> Cc: Quan, Evan <Evan.Quan@xxxxxxx>; rafael@xxxxxxxxxx; lenb@xxxxxxxxxx;
> Deucher, Alexander <Alexander.Deucher@xxxxxxx>; Koenig, Christian
> <Christian.Koenig@xxxxxxx>; Pan, Xinhui <Xinhui.Pan@xxxxxxx>;
> airlied@xxxxxxxxx; daniel@xxxxxxxx; johannes@xxxxxxxxxxxxxxxx;
> davem@xxxxxxxxxxxxx; edumazet@xxxxxxxxxx; kuba@xxxxxxxxxx;
> pabeni@xxxxxxxxxx; mdaenzer@xxxxxxxxxx;
> maarten.lankhorst@xxxxxxxxxxxxxxx; tzimmermann@xxxxxxx;
> hdegoede@xxxxxxxxxx; jingyuwang_vip@xxxxxxx; Lazar, Lijo
> <Lijo.Lazar@xxxxxxx>; jim.cromie@xxxxxxxxx; bellosilicio@xxxxxxxxx;
> andrealmeid@xxxxxxxxxx; trix@xxxxxxxxxx; jsg@xxxxxxxxx; arnd@xxxxxxxx;
> linux-kernel@xxxxxxxxxxxxxxx; linux-acpi@xxxxxxxxxxxxxxx; amd-
> gfx@xxxxxxxxxxxxxxxxxxxxx; dri-devel@xxxxxxxxxxxxxxxxxxxxx; linux-
> wireless@xxxxxxxxxxxxxxx; netdev@xxxxxxxxxxxxxxx
> 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