[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 <and...@lunn.ch> > Sent: Wednesday, July 26, 2023 4:10 AM > To: Limonciello, Mario <mario.limoncie...@amd.com> > Cc: Quan, Evan <evan.q...@amd.com>; raf...@kernel.org; l...@kernel.org; > Deucher, Alexander <alexander.deuc...@amd.com>; Koenig, Christian > <christian.koe...@amd.com>; Pan, Xinhui <xinhui....@amd.com>; > airl...@gmail.com; dan...@ffwll.ch; johan...@sipsolutions.net; > da...@davemloft.net; eduma...@google.com; k...@kernel.org; > pab...@redhat.com; mdaen...@redhat.com; > maarten.lankho...@linux.intel.com; tzimmerm...@suse.de; > hdego...@redhat.com; jingyuwang_...@163.com; Lazar, Lijo > <lijo.la...@amd.com>; jim.cro...@gmail.com; bellosili...@gmail.com; > andrealm...@igalia.com; t...@redhat.com; j...@jsg.id.au; a...@arndb.de; > linux-ker...@vger.kernel.org; linux-a...@vger.kernel.org; amd- > g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org; linux- > wirel...@vger.kernel.org; net...@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
