[PATCH] SME: Add configurable driver processing time

[Krishna Chaitanya]

On Tue, Sep 30, 2025 at 9:27 PM Jouni Malinen <j at w1.fi> wrote:
>
> On Fri, Jul 25, 2025 at 07:25:35PM +0530, Chaitanya Tata wrote:
> > Some drivers take longer than 100ms, and there by the keepalive is sent
> > after the keepalive period and this causes disconnections sometimes, so,
> > adjust for the driver's processing delay (a new driver capability) and
> > send the keepalive early (no harm in sending early).
>
> "take longer than 100 ms" to do what? What is "processing delay"? That
> sounds way too generic if this is just for the keepalive mechanism.
>
The issue itself is generic on resource-constrained hosts, e.g., MCU running
at 128MHz, any frame prepared in the supplicant takes too long to
reach the Wi-Fi
the chip and OTA. Specifically, we had seen issues with EAPoL frames and
keepalive frames. Unlike EAPoL for keepalive, we have a choice to send it early.
>
> > diff --git a/src/drivers/driver.h b/src/drivers/driver.h
> > @@ -2541,6 +2541,9 @@ struct wpa_driver_capa {
> > +     /* Driver TX processing delay in microseconds, used for TX delay compensation */
> > +     unsigned int driver_tx_processing_delay_ms;
>
> What exactly is included in such TX processing delay? Is this only for
> keepalive?
>
> This patch does not include any driver_*.c changes to indicate how this
> might be set. Would this be somehow determined from a driver or would
> there an out-of-tree driver_*.c implementation that would hardcode the
> value? Or something else?
For the in-tree drivers, this is not a problem (not that I know of), so this is
left unset. For out-of-tree drivers (ZephyrRTOS running on nRF5340 host
in this case), this delay is configured

(Ref: https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/wifi/nrf_wifi/src/wpa_supp_if.c#L1818)