Messages in this thread | | | Date | Tue, 25 Jul 2023 15:44:31 -0500 | Subject | Re: [PATCH V7 4/9] wifi: mac80211: Add support for ACPI WBRF | From | 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().
| |