netdev - Re: [PATCH V4 1/8] drivers/acpi: Add support for Wifi band RF mitigations

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJZ5v0gnTt0pV4nF+jcYCyZuZXDNuRn3mS0bDoAv-ZDpetyxVg@mail.gmail.com>
Date: Fri, 23 Jun 2023 18:28:01 +0200
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: "Limonciello, Mario" <mario.limonciello@....com>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>, Evan Quan <evan.quan@....com>, lenb@...nel.org, 
	alexander.deucher@....com, christian.koenig@....com, Xinhui.Pan@....com, 
	airlied@...il.com, daniel@...ll.ch, johannes@...solutions.net, 
	davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com, 
	mdaenzer@...hat.com, maarten.lankhorst@...ux.intel.com, tzimmermann@...e.de, 
	hdegoede@...hat.com, jingyuwang_vip@....com, lijo.lazar@....com, 
	jim.cromie@...il.com, bellosilicio@...il.com, andrealmeid@...lia.com, 
	trix@...hat.com, jsg@....id.au, arnd@...db.de, linux-kernel@...r.kernel.org, 
	linux-acpi@...r.kernel.org, amd-gfx@...ts.freedesktop.org, 
	dri-devel@...ts.freedesktop.org, linux-wireless@...r.kernel.org, 
	netdev@...r.kernel.org
Subject: Re: [PATCH V4 1/8] drivers/acpi: Add support for Wifi band RF mitigations

On Fri, Jun 23, 2023 at 5:57 PM Limonciello, Mario
<mario.limonciello@....com> wrote:
>
>
> On 6/23/2023 9:52 AM, Rafael J. Wysocki wrote:
> > On Wed, Jun 21, 2023 at 7:47 AM Evan Quan <evan.quan@....com> wrote:
> >> From: Mario Limonciello <mario.limonciello@....com>
> >>
> >> Due to electrical and mechanical constraints in certain platform designs
> >> there may be likely interference of relatively high-powered harmonics of
> >> the (G-)DDR memory clocks with local radio module frequency bands used
> >> by Wifi 6/6e/7.
> >>
> >> To mitigate this, AMD has introduced an ACPI based mechanism that
> >> devices can use to notify active use of particular frequencies so
> >> that devices can make relative internal adjustments as necessary
> >> to avoid this resonance.
> >>
> >> In order for a device to support this, the expected flow for device
> >> driver or subsystems:
> >>
> >> Drivers/subsystems contributing frequencies:
> >>
> >> 1) During probe, check `wbrf_supported_producer` to see if WBRF supported
> > The prefix should be acpi_wbrf_ or acpi_amd_wbrf_ even, so it is clear
> > that this uses ACPI and is AMD-specific.
>
> I guess if we end up with an intermediary library approach
> wbrf_supported_producer makes sense and that could call acpi_wbrf_*.
>
> But with no intermediate library your suggestion makes sense.
>
> I would prefer not to make it acpi_amd as there is no reason that
> this exact same problem couldn't happen on an
> Wifi 6e + Intel SOC + AMD dGPU design too and OEMs could use the
> same mitigation mechanism as Wifi6e + AMD SOC + AMD dGPU too.

The mitigation mechanism might be the same, but the AML interface very
well may be different.

My point is that this particular interface is AMD-specific ATM and I'm
not aware of any plans to make it "standard" in some way.

Also if the given interface is specified somewhere, it would be good
to have a pointer to that place.

> >
> > Whether or not there needs to be an intermediate library wrapped
> > around this is a different matter.

IMO individual drivers should not be expected to use this interface
directly, as that would add to boilerplate code and overall bloat.

Also whoever uses it, would first need to check if the device in
question has an ACPI companion.