Linux wireless drivers development
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Abhishek Rajkapur Suryawanshi
	<abhishek.suryawanshi@oss.qualcomm.com>,
	 ath12k@lists.infradead.org, hostap@lists.infradead.org
Cc: linux-wireless@vger.kernel.org
Subject: Re: [DESIGN RFC v3] AP Architecture for Wi-Fi-8 Multi-AP Coordination (MAPC)
Date: Mon, 12 Jan 2026 20:18:24 +0100	[thread overview]
Message-ID: <59cec65b29ded381c85d1be943d88e956a4b7e74.camel@sipsolutions.net> (raw)
In-Reply-To: <05381371a41f154058429f0a1079204c4a454f45.camel@sipsolutions.net> (sfid-20260112_201230_217667_8E744336)

On Mon, 2026-01-12 at 20:12 +0100, Johannes Berg wrote:
> 
> Why do you always want to let firmware be in control of everything?
> Seems at least for some of this you'd really want the upper layers to
> control it for purposes of coordination? How does the FW even know which
> other AP it can coordinate with, isn't that something a network
> controller would determine?

A less generous reading of this could be: you guys want everything to be
controlled by FW, so you don't have to open-source it in hostapd. Now
you realize oops, don't really want to do all the security handshake in
FW, so we need to ask hostapd and then we need keys and stations and all
this stuff. So let's build something nobody else can use, upstream it
and we get the best of both worlds - others will maintain the mac80211
code for us anyway.

Am I wrong? Is there a technical reason for not simply doing MAPC
discovery/agreement negotiation etc. in hostapd as well, based on
driver/hw/fw capabilities, and then you don't need all these strange
"triggered by firmware" flows?

johannes

  reply	other threads:[~2026-01-12 19:18 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-12 18:52 [DESIGN RFC v3] AP Architecture for Wi-Fi-8 Multi-AP Coordination (MAPC) Abhishek Rajkapur Suryawanshi
2026-01-12 19:12 ` Johannes Berg
2026-01-12 19:18   ` Johannes Berg [this message]
2026-01-14 19:15     ` Jeff Johnson
2026-01-15 14:17       ` Johannes Berg
2026-01-22  8:42         ` Abhishek Rajkapur Suryawanshi
2026-01-27 13:57           ` Johannes Berg
2026-02-28 17:34             ` Abhishek Rajkapur Suryawanshi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=59cec65b29ded381c85d1be943d88e956a4b7e74.camel@sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=abhishek.suryawanshi@oss.qualcomm.com \
    --cc=ath12k@lists.infradead.org \
    --cc=hostap@lists.infradead.org \
    --cc=linux-wireless@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox