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().
