Linux wireless drivers development
 help / color / mirror / Atom feed
From: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
To: Johannes Berg <johannes@sipsolutions.net>,
	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: Wed, 14 Jan 2026 11:15:16 -0800	[thread overview]
Message-ID: <63ff0362-4ee4-4f13-a212-dc1351eefe08@oss.qualcomm.com> (raw)
In-Reply-To: <59cec65b29ded381c85d1be943d88e956a4b7e74.camel@sipsolutions.net>

On 1/12/2026 11:18 AM, Johannes Berg wrote:
> 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?

My perception is that Qualcomm would love for all the Wi-Fi 8 functionality to
be in userspace and nl/cfg/mac80211 since then there would be no code
maintenance overhead on our part -- just you and the userspace maintainers.
But there are concerns about latency, and internal consensus is that some
aspects of this functionality has to be handled in firmware (or even hardware)
in order to meet customer KPIs. This comes from our history of supporting
large-scale deployments of APs, and the expectations of how Wi-Fi 8 will make
things better. That is why we are posting design RFCs, so that you, as well as
engineers from other vendors, can review our proposals and give your feedback
and counter-proposals. We want to avoid developing what might be an
architecturally pure design that doesn't actually meet customer needs.

And apologies for the "firehose" of both design and code, but we have a desire
to ship Wi-Fi 8 products using upstream code. I've passed along information
that you want our engineering team to focus on the base NPCA patches so that
there is the appropriate foundation. But in parallel we do also hope there is
engagement from other vendors on the Design RFCs we are posting. Our goal is
to upstream as much AP functionality as you can absorb.

/jeff

  reply	other threads:[~2026-01-14 19:15 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
2026-01-14 19:15     ` Jeff Johnson [this message]
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=63ff0362-4ee4-4f13-a212-dc1351eefe08@oss.qualcomm.com \
    --to=jeff.johnson@oss.qualcomm.com \
    --cc=abhishek.suryawanshi@oss.qualcomm.com \
    --cc=ath12k@lists.infradead.org \
    --cc=hostap@lists.infradead.org \
    --cc=johannes@sipsolutions.net \
    --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