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

[Mario Limonciello]

On 7/25/23 15:09, Andrew Lunn wrote:
> > 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's not yes/no for a "model" or "machine".  It's yes/no for a given 
*device*
within a machine.
> 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.
Which is exactly what wbrf_supported_producer() and 
wbrf_supported_consumer() do.
If there is another vendor's implementation introduced they can make 
those functions
return TRUE for their implementations.
> > 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.
It's not a function of "device" though, it's "device within machine".
> > 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
I don't see why other implementations can't just come up with other
platform specific ways to respond affirmatively to
wbrf_supported_producer() or
wbrf_supported_consumer().