From: Johannes Berg <johannes@sipsolutions.net>
To: Eric Biggers <ebiggers@kernel.org>
Cc: linux-wireless@vger.kernel.org, linux-crypto@vger.kernel.org,
linux-kernel@vger.kernel.org,
Herbert Xu <herbert@gondor.apana.org.au>
Subject: Re: [PATCH wireless-next 0/6] Consolidate Michael MIC code into mac80211
Date: Tue, 07 Apr 2026 08:22:54 +0200 [thread overview]
Message-ID: <feabff620b9e82bf7b530660b847ddad4741ece6.camel@sipsolutions.net> (raw)
In-Reply-To: <20260407061508.GA7934@sol>
On Mon, 2026-04-06 at 23:15 -0700, Eric Biggers wrote:
> On Tue, Apr 07, 2026 at 08:00:53AM +0200, Johannes Berg wrote:
> > The one thing that feels odd to me in this is moving it to *mac80211*
> > specifically, and then using that in the ancient drivers. Not only is
> > that a big module those don't (otherwise) need, but also it makes it
> > look like you need the softmac stack for those drivers, but they're
> > really hardmac so that's a bit confusing.
> >
> > I wouldn't want to have a separate module just for this, but I think
> > since it's going to be exported anyway, we could move the whole
> > michael.c file to net/wireless/ and make it part of cfg80211. All
> > wireless drivers ought to depend on that anyway.
>
> Just to clarify, mac80211 already contains the michael_mic() function.
Yes, for the SW crypto there, which apparently was never ported to the
crypto functions.
> And every driver that needs Michael MIC already depends on mac80211
> except for ipw2x00.
I'm actually surprised it's any of those (actually) mac80211 based
drivers at all, since they ought to just be able to hand the skb to
mac80211 for checking. Not sure what's going on there, but I haven't
looked carefully either.
> So bloat-wise I assumed it's probably better to
> make that one driver depend on mac80211, rather than make every driver
> pull in the Michael MIC code (by moving it from mac80211 to cfg80211).
> But if you prefer that the code be in cfg80211 we can do it that way.
I think you're probably right, but it's a pretty small function and
architecturally, having those drivers depend on mac80211 but not
actually use any of its "real" functionality is IMHO somewhat confusing,
maybe especially from a Kconfig POV.
Also most drivers already use mac80211 so for those it makes no
difference, but of course there are a number of non-mac80211 drivers
that would get this function.
So I think overall, it still makes more sense in cfg80211 - we've been
treating that as not just nl80211 but also "useful things for drivers"
(for obvious reasons, every WiFi driver must use it), so that'd be the
better place I think.
johannes
next prev parent reply other threads:[~2026-04-07 6:22 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-05 5:27 [PATCH wireless-next 0/6] Consolidate Michael MIC code into mac80211 Eric Biggers
2026-04-05 5:27 ` [PATCH wireless-next 1/6] wifi: mac80211: Export michael_mic() Eric Biggers
2026-04-05 5:27 ` [PATCH wireless-next 2/6] wifi: ath11k: Use michael_mic() from mac80211 Eric Biggers
2026-04-05 5:27 ` [PATCH wireless-next 3/6] wifi: ath12k: " Eric Biggers
2026-04-05 5:27 ` [PATCH wireless-next 4/6] wifi: ipw2x00: Depend on MAC80211 Eric Biggers
2026-04-05 22:41 ` Jeff Johnson
2026-04-06 16:06 ` Eric Biggers
2026-04-05 5:27 ` [PATCH wireless-next 5/6] wifi: ipw2x00: Use michael_mic() from mac80211 Eric Biggers
2026-04-05 5:27 ` [PATCH wireless-next 6/6] crypto: Remove michael_mic from crypto_shash API Eric Biggers
2026-04-07 7:53 ` Geert Uytterhoeven
2026-04-06 15:59 ` [PATCH wireless-next 0/6] Consolidate Michael MIC code into mac80211 Jeff Johnson
2026-04-06 16:02 ` Eric Biggers
2026-04-07 6:00 ` Johannes Berg
2026-04-07 6:15 ` Eric Biggers
2026-04-07 6:22 ` Johannes Berg [this message]
2026-04-07 6:24 ` Christoph Hellwig
2026-04-07 6:28 ` Johannes Berg
2026-04-07 6:33 ` Christoph Hellwig
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=feabff620b9e82bf7b530660b847ddad4741ece6.camel@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=ebiggers@kernel.org \
--cc=herbert@gondor.apana.org.au \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.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