linuxkpi: do not call link_sta_rc_update before the sta is added

[ashafer]

Summary

lkpi_sta_sync_from_ni() is called from lkpi_lsta_alloc() during node
allocation. At that point the sta has not gone through sta_state, so the
driver has no state for it, and we are also not holding the wiphy lock.
Since 0d3cd54642f6 the function ends with a link_sta_rc_update()
call whenever a rate control field changed, which is nearly always
the case on a fresh sta.

Only make the downcall once the sta was added to the driver. The sync in
lkpi_sta_assoc_to_run() runs with the lock held after the sta exists and
reports the changes then.

Tested on a Dell precision 5690, this change was needed to fix a
regression which caused a panic when wlan0 started.

Fixes: 0d3cd54642f6 ("LinuxKPI: 802.11: add function to update some rate related fields")
Assisted-by: Claude Code (Fable 5.1)

[ashafer]

+bz, not sure if this is a known issue? I hadn't updated my local tree in a while but it seems like this regression happened back in June.

[bz]

I'll have to go and look; I wonder if there was a mis-merge somewhere. Due to other generic LinuxKPI changes which were in review for quite a long time I had to rebase the entire code back then to get it in and only the recent changes (which were backed out as they broke drm-kmod as we know) would actually make all the lock assertions work again on a GENERIC kernel.

sys/compat/linuxkpi/common/src/linux_80211.c

961

Couldn't the entire change be simplified to if (updchnctx && rc_changed != 0)?