[PATCH V6 1/9] drivers core: Add support for Wifi band RF mitigations

[Quan, Evan]

[AMD Official Use Only - General]

Personally I would like to treat the wbrf core as a water pool. Any stream can flow in. Also any needed can drain water from it at any time.
The way to allow producers to report only when there is consumer existing does not work. Since the consumer might come after the producer.
Just considering the scenario below:
Wifi core/driver started --> wifi driver reports its frequency in-use  --> proper action taken by wbrf core --> amdgpu driver(consumer) started
What should be the proper action taken by wbrf core then? Stop the producer to report its frequency in-use? That might lead consumer to never have a chance to know that.

The wbrf_supported_producer and wbrf_supported_consumer APIs seem unnecessary for the generic implementation.
But to support AMD ACPI implementation(or future device tree implementation), they are needed. The wbrf core needs to check whether the necessary AML codes are there.
It needs those information to judge whether a producer can report(will be accepted) or a consumer can retrieve needed information.

> > +struct wbrf_ranges_out {
> > +   u32                     num_of_ranges;
> > +   struct exclusion_range  band_list[MAX_NUM_OF_WBRF_RANGES];
> > +} __packed;
>
> Seems odd using packed here. It is the only structure which is
> packed. I would also move the u32 after the struct so it is naturally
> aligned on 64 bit systems.
This is to align with the AMD ACPI implementation.
But I can make this AMD ACPI specific and bring a more generic version here.

Evan
> -----Original Message-----
> From: Andrew Lunn <andrew at lunn.ch>
> Sent: Thursday, July 13, 2023 7:12 AM
> To: Quan, Evan <Evan.Quan at amd.com>
> Cc: rafael at kernel.org; lenb at kernel.org; Deucher, Alexander
> <Alexander.Deucher at amd.com>; Koenig, Christian
> <Christian.Koenig at amd.com>; Pan, Xinhui <Xinhui.Pan at amd.com>;
> airlied at gmail.com; daniel at ffwll.ch; johannes at sipsolutions.net;
> davem at davemloft.net; edumazet at google.com; kuba at kernel.org;
> pabeni at redhat.com; Limonciello, Mario <Mario.Limonciello at amd.com>;
> mdaenzer at redhat.com; maarten.lankhorst at linux.intel.com;
> tzimmermann at suse.de; hdegoede at redhat.com; jingyuwang_vip at 163.com;
> Lazar, Lijo <Lijo.Lazar at amd.com>; jim.cromie at gmail.com;
> bellosilicio at gmail.com; andrealmeid at igalia.com; trix at redhat.com;
> jsg at jsg.id.au; arnd at arndb.de; linux-kernel at vger.kernel.org; linux-
> acpi at vger.kernel.org; amd-gfx at lists.freedesktop.org; dri-
> devel at lists.freedesktop.org; linux-wireless at vger.kernel.org;
> netdev at vger.kernel.org
> Subject: Re: [PATCH V6 1/9] drivers core: Add support for Wifi band RF
> mitigations
>
> > +/**
> > + * wbrf_supported_producer - Determine if the device can report
> frequencies
> > + *
> > + * @dev: device pointer
> > + *
> > + * WBRF is used to mitigate devices that cause harmonic interference.
> > + * This function will determine if this device needs to report such
> frequencies.
>
> How is the WBRF core supposed to answer this question? That it knows
> there is at least one device which has registered with WBRF saying it
> can change its behaviour to avoid causing interference?
>
> Rather than "Determine if the device can report frequencies" should it be
> "Determine if the device should report frequencies"
>
> A WiFi device can always report frequencies, since it knows what
> frequency is it currently using. However, it is pointless making such
> reports if there is no device which can actually make use of the
> information.
>
> > +bool wbrf_supported_producer(struct device *dev)
> > +{
> > +   return true;
> > +}
>
> I found the default implementation of true being odd. It makes me
> wounder, what is the point of this call. I would expect this to see if
> a linked list is empty or not.
>
> > +/**
> > + * wbrf_supported_consumer - Determine if the device can react to
> frequencies
>
> This again seems odd. A device should know if it can react to
> frequencies or not. WBRF core should not need to tell it. What makes
> more sense to me is that this call is about a device telling the WBRF
> core it is able to react to frequencies. The WBRF core then can give a
> good answer to wbrf_supported_producer(), yes, i know of some other
> device who might be able to do something to avoid causing interference
> to you, so please do tell me about frequencies you want to use.
>
> What is missing here in this API is policy information. The WBRF core
> knows it has zero or more devices which can report what frequencies
> they are using, and it has zero or more devices which maybe can do
> something. But then you need policy to say this particular board needs
> any registered devices to actually do something because of poor
> shielding. Should this policy be as simple as a bool, or should it
> actually say the board has shielding issues for a list of frequencies?
> I think the answer to what will depend on the cost of taking action
> when no action is actually required.
>
> > + * wbrf_register_notifier - Register for notifications of frequency changes
> > + *
> > + * @nb: driver notifier block
> > + *
> > + * WBRF is used to mitigate devices that cause harmonic interference.
> > + * This function will allow consumers to register for frequency notifications.
> > + */
> > +int wbrf_register_notifier(struct notifier_block *nb)
> > +{
> > +   return blocking_notifier_chain_register(&wbrf_chain_head, nb);
> > +}
>
> What are the timing requirements for the handler? Should the handler
> block until the device has finished doing what it needs to do and the
> frequency response has settled? We don't want the WiFi device doing a
> SNR measurement until we know local noise is at a minimum. I think it
> would be good to document things like this here.
>
> > +struct wbrf_ranges_out {
> > +   u32                     num_of_ranges;
> > +   struct exclusion_range  band_list[MAX_NUM_OF_WBRF_RANGES];
> > +} __packed;
>
> Seems odd using packed here. It is the only structure which is
> packed. I would also move the u32 after the struct so it is naturally
> aligned on 64 bit systems.
>
>       Andrew