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: <d1e01e52-df5f-a595-eaa1-95466f7b4ff8@amd.com>
Date:   Wed, 21 Jun 2023 11:40:31 -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


On 6/21/2023 11:31 AM, Andrew Lunn wrote:
>> I think there is enough details for this to happen. It's done
>> so that either the AML can natively behave as a consumer or a
>> driver can behave as a consumer.
>>>>>> +/**
>>>>>> + * APIs needed by drivers/subsystems for contributing frequencies:
>>>>>> + * During probe, check `wbrf_supported_producer` to see if WBRF is supported.
>>>>>> + * If adding frequencies, then call `wbrf_add_exclusion` with the
>>>>>> + * start and end points specified for the frequency ranges added.
>>>>>> + * If removing frequencies, then call `wbrf_remove_exclusion` with
>>>>>> + * start and end points specified for the frequency ranges added.
>>>>>> + */
>>>>>> +bool wbrf_supported_producer(struct acpi_device *adev);
>>>>>> +int wbrf_add_exclusion(struct acpi_device *adev,
>>>>>> +		       struct wbrf_ranges_in *in);
>>>>>> +int wbrf_remove_exclusion(struct acpi_device *adev,
>>>>>> +			  struct wbrf_ranges_in *in);
>>>>> Could struct device be used here, to make the API agnostic to where
>>>>> the information is coming from? That would then allow somebody in the
>>>>> future to implement a device tree based information provider.
>>>> That does make sense, and it wouldn't even be that much harder if we
>>>> assume in a given platform there's only one provider
>>> That seems like a very reasonable assumption. It is theoretically
>>> possible to build an ACPI + DT hybrid, but i've never seen it actually
>>> done.
>>>
>>> If an ARM64 ACPI BIOS could implement this, then i would guess the low
>>> level bits would be solved, i guess jumping into the EL1
>>> firmware. Putting DT on top instead should not be too hard.
>>>
>>> 	Andrew
>> To make life easier I'll ask whether we can include snippets of
>> the matching ASL for this first implementation as part of the
>> public ACPI spec that matches this code when we release it.
> So it sounds like you are pretty open about this, there should be
> enough information for independent implementations. So please do make
> the APIs between the providers and the consumers abstract, struct
> device, not an ACPI object.
>
> 	Andrew
Think a little more about what a non-ACPI implementation
would look like:

1) Would producers and consumers still need you to set CONFIG_ACPI_WBRF?
2) How would you indicate you need WBRF support?
3) How would notifications from one device to another work?

I don't think those are trivial problems that can be solved by
just making the pointer 'struct device' particularly as with the
ACPI implementation consumers are expecting the notification from
ACPI.