[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
