[PATCH v13 0/5] Introduce Automated Frequency Coordination (AFC) support

[Jouni Malinen]

On Tue, Aug 04, 2026 at 02:34:32PM +0800, Allen Ye wrote:
> This patch series introduces Automated Frequency Coordination (AFC) support
> for Standard Power Devices (SPDs) operating in the 6GHz UNII-5 and UNII-7
> bands. AFC is a regulatory requirement for SPDs to determine a list of
> available channels and their permissible power levels.
> 
> The implementation introduces a new standalone daemon, afcd, to manage
> communication with the AFC server. A client within hostapd then interacts
> with afcd via a Unix socket to fetch spectrum availability and update AP
> parameters accordingly. The series also includes hwsim tests for validation.

> Allen Ye (3):
>   hostapd: Fix ht40_plus_minus_allowed secondary channel selection
>   hostapd: Support 80/160/320 MHz widths in hostapd_is_usable_chans
>   tests: Add AFC hwsim tests
> 
> Lorenzo Bianconi (2):
>   AFC: Add AFC client support
>   AFC: Update TPE IE according to AFC

Thanks, I applied this with cleanup and fixes to make progress. Please
note that I change the encoding of the afc_freq_range configuration
parameter to use min-max for the ranges so that this is consistent with
other cases of frequency ranges and can use existing parsing functions
for that.

There is one significant issue in the current design that needs to be
addressed, but I did not want to push this out to yet another review
round at this point.

hostapd_afc_send_receive() uses a synchronous operation to send the
request and receive the response. That can block the hostapd process for
a significant amount of time while there could be multiple other BSSs
operating and those operations could be impacted. In other words, that
design should be changed to use asynchronous operations where the
request is sent out first and instead of the blocking wait for the
response within this functions, an eloop socket reader should be
registered to wait for the response to become available. The response
would then be processed from the eloop callback (which might need to
schedule additional callbacks if the full TCP response is not available
in one recv() call).

-- 
Jouni Malinen                                            PGP id EFC895FA