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: <07ad6860-8ffb-cc6c-a8e5-e8dc4db4e87a@amd.com>
Date:   Wed, 21 Jun 2023 13:50:34 -0500
From:   "Limonciello, Mario" <mario.limonciello@....com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Johannes Berg <johannes@...solutions.net>,
        Evan Quan <evan.quan@....com>, rafael@...nel.org,
        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
Subject: Re: [PATCH V4 1/8] drivers/acpi: Add support for Wifi band RF
 mitigations

So if we go down this path of CONFIG_WBRF and CONFIG_WBRF_ACPI, another
question would be where should the new "wbrf.c" be stored?  The ACPI only
version most certainly made sense in drivers/acpi/wbrf.c, but a generic
version that only has an ACPI implementation right now not so much.

On 6/21/2023 1:30 PM, Andrew Lunn wrote:
>> And consumer would need to call it, but only if CONFIG_WBRF_ACPI isn't set.
> Why? How is ACPI special that it does not need notifiers?
ACPI core does has notifiers that are used, but they don't work the same.
If you look at patch 4, you'll see amdgpu registers and unregisters using
both

acpi_install_notify_handler()
and
acpi_remove_notify_handler()

If we supported both ACPI notifications and non-ACPI notifications
all consumers would have to have support to register and use both types.

>
>> I don't see why it couldn't be a DT/ACPI hybrid solution for ARM64.
> As said somewhere else, nobody does hybrid. In fact, turn it
> around. Why not implement all this in DT, and make X86 hybrid? That
> will make arm, powerpc, risc-v and mips much simpler :-)
>
> 	Andrew
Doesn't coreboot do something hybrid with device tree?  I thought they
generate their ACPI tables from a combination of DT and some static ASL.