[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@lunn.ch>
Sent: Wednesday, July 26, 2023 4:10 AM
To: Limonciello, Mario <Mario.Limonciello@amd.com>
Cc: Quan, Evan <redacted>; rafael@kernel.org; lenb@kernel.org;
Deucher, Alexander [off-list ref]; Koenig, Christian
[off-list ref]; Pan, Xinhui [off-list ref];
airlied@gmail.com; daniel@ffwll.ch; johannes@sipsolutions.net;
davem@davemloft.net; edumazet@google.com; kuba@kernel.org;
pabeni@redhat.com; mdaenzer@redhat.com;
maarten.lankhorst@linux.intel.com; tzimmermann@suse.de;
hdegoede@redhat.com; jingyuwang_vip@163.com; Lazar, Lijo
[off-list ref]; jim.cromie@gmail.com; bellosilicio@gmail.com;
andrealmeid@igalia.com; trix@redhat.com; jsg@jsg.id.au; arnd@arndb.de;
linux-kernel@vger.kernel.org; linux-acpi@vger.kernel.org; amd-
gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org; linux-
wireless@vger.kernel.org; netdev@vger.kernel.org
Subject: Re: [PATCH V7 4/9] wifi: mac80211: Add support for ACPI WBRF

quoted

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.

quoted

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.

quoted

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.

quoted

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