linux-kernel - 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: <4e522001-7b36-0e38-10d9-22c55de728ea@amd.com>
Date:   Thu, 22 Jun 2023 15:28:36 -0500
From:   "Limonciello, Mario" <mario.limonciello@....com>
To:     Andrew Lunn <andrew@...n.ch>,
        "Rafael J. Wysocki" <rafael@...nel.org>
Cc:     Evan Quan <evan.quan@....com>, lenb@...nel.org,
        alexander.deucher@....com, christian.koenig@....com,
        Xinhui.Pan@....com, airlied@...il.com, daniel@...ll.ch,
        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, Johannes Berg <johannes@...solutions.net>
Subject: Re: [PATCH V4 1/8] drivers/acpi: Add support for Wifi band RF
 mitigations


On 6/21/2023 8:55 PM, Andrew Lunn wrote:
>> Honestly I'm not sure though we need this complexity right now? I mean,
>> it'd be really easy to replace the calls in mac80211 with some other
>> more generalised calls in the future?
>>
>> You need some really deep platform/hardware level knowledge and
>> involvement to do this, so I don't think it's something that someone
>> will come up with very easily for a DT-based platform...
> What is this API about?
>
> It is a struct device says, i'm badly designed and make a mess of the
> following frequency bands. Optionally, if you ask me nicely, i might
> be able to tweak what i'm doing to avoid interfering with you.
>
> And it is about a struct device say, i'm using this particular
> frequency. If you can reduce the noise you make, i would be thankful.
Hey now - you're making assumptions about what's badly designed.

At it's core the issue here that prompts all of this is a
"platform" issue with the tiny Z heights laptops these days
strive for causing implied limitations for shielding.

Independently both components work just fine.

>
> The one generating the noise could be anything. The PWM driving my
> laptop display back light?, What is being interfered with?  The 3.5mm
> audio jack?
>
> How much deep system knowledge is needed to call pwm_set_state() to
> move the base frequency up above 20Khz so only my dog will hear it?
> But at the cost of a loss of efficiency and my battery going flatter
> faster?
>
> Is the DDR memory really the only badly designed component, when you
> think of the range of systems Linux is used on from PHC to tiny
> embedded systems?
>
> Ideally we want any sort of receiver with a low noise amplifier to
> just unconditionally use this API to let rest of the system know about
> it. And ideally we want anything which is a source of noise to declare
> itself. What happens after that should be up to the struct device
> causing the interference.
I do get your point here - but the problem with a PWM on your
laptop display interfering with the 3.5mm audio jack would
likely be localized to your specific model.

If you have the 16" version of the laptop and I have the 13"
version I might have the 3.5mm audio jack in another location,
that is better shielded and so making that assumption that we
both have the same components so need to make changes could be
totally wrong.

If you have EVERYTHING with an amplifier advertising frequencies
in use without any extra information about the location of the
component or the impacts that component can have you're going
to have a useless interface that is just a bunch of garbage data.

I really think the application of this type of software
mitigation should be reserved for system designers that made
those design decisions and know they are going to run into problems.

> Mario did say:
>
>    The way that WBRF has been architected, it's intended to be able to
>    scale to any type of device pair that has harmonic issues.
>
> Andrew
The types of things that we envisioned were high frequency devices
with larger power emissions. For example WWAN or USB4 devices.
These fit well into the ACPI device model.

When Evan gets back from holiday I'll discuss with him the ideas from
this thread.

However before then I would really appreciate if Rafael can provide
some comments on patch 1 as it stands today.