Re: [PATCH -next 01/10] wifi: cfg80211: pre-assign cookie for remain_on_channel, mgmt_tx, probe_peer and tx_control_port
Jeff Johnson <[email protected]> Sun, 26 Jul 2026 13:29:04 -0700
| Newsgroups | dev.linux.lists.brcm80211,org.kernel.vger.linux-wireless |
|---|---|
| Message-ID | <[email protected]> |
On 7/26/2026 12:37 PM, Johannes Berg wrote: > On Sun, 2026-07-26 at 21:25 +0200, Arend van Spriel wrote: >> Having a single place for cookie assignment and keeping that >> responsibility in the cfg80211 subsystem is a logical choice as it >> handles the userspace nl80211 API. add_nan_func already does this: >> cfg80211 calls cfg80211_assign_cookie() before invoking the driver. >> Apply the same pattern to remain_on_channel, mgmt_tx, probe_peer and >> tx_control_port by pre-assigning the cookie in the nl80211 command >> handlers before the rdev_* call. For tx_control_port the cookie is >> only pre-assigned when the caller requests an ack (cookie pointer >> non-NULL). >> >> Drivers may still overwrite the value for now; subsequent patches will >> remove per-driver cookie generation. Update the cfg80211_ops kerneldoc >> to note that the cookie is pre-assigned and drivers must not modify it. >> >> Assisted-by: Claude:claude-sonnet-4-6 > > Hah, I _knew_ it, just based on the text style, before even reading > beyond the cover letter ... I'm starting to even be able to tell the > companies apart (not models yet, i.e. you could've told me this was > Opus). E.g. "Patch 1 is the enabling change: [...]", "Non-obvious > aspects" or "This means the cookie field is threaded through" etc. > > Fun. What weird times we live in. Indeed. And yes, I tend to edit the LLM commit text since the tense is often wrong and the vocabulary often isn't want I'd use. > > But you forgot S-o-b. also wrong branch tag: s/-next/wireless-next/ > > johannes