linux-kernel - Re: [EXT] Re: [PATCH v9 0/2] wifi: mwifiex: add code to support host mlme

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <7a08dbcaded25ec0d32865647d571afbd66062fe.camel@sipsolutions.net>
Date: Thu, 11 Apr 2024 10:02:58 +0200
From: Johannes Berg <johannes@...solutions.net>
To: David Lin <yu-hao.lin@....com>, Brian Norris <briannorris@...omium.org>
Cc: Francesco Dolcini <francesco@...cini.it>, "kvalo@...nel.org"
 <kvalo@...nel.org>, "linux-wireless@...r.kernel.org"
 <linux-wireless@...r.kernel.org>, "linux-kernel@...r.kernel.org"
 <linux-kernel@...r.kernel.org>, Pete Hsieh <tsung-hsien.hsieh@....com>, 
 "rafael.beims" <rafael.beims@...adex.com>, Francesco Dolcini
 <francesco.dolcini@...adex.com>
Subject: Re: [EXT] Re: [PATCH v9 0/2] wifi: mwifiex: add code to support
 host mlme

On Thu, 2024-04-11 at 07:57 +0000, David Lin wrote:
> 
> 
> Following jobs are done by FW:
> 
> 1. MAC 802.11 Rx processes except for BA buffering/reordering and AMSDU.
> 2. Convert 802.11 frame to 802.3 frame.
> 3. Embedded MAC 802.11 header information to Rx descriptor for driver to do BA buffering/reordering.
> 
> If this FW wants to leverage mac80211:
> 
> 1. Use 802.11 frame:
>   Driver should restructure 802.11 frame and mac80211 will redo jobs done by FW. I think this does not make sense.
> 2. Use 802.3 frame:
>   Driver still needs to do BA buffering/reordering (mac80211 can help with AMSDU with flag IEEE80211_RX_AMSDU,
>   but cfg80211 also supports function ieee80211_amsdu_to_8023s() to help this job).
>   If this is the case, it becomes redundant to pass 802.3 frame to kernel stack via mac80211.
> 
> So I think cfg80211 will be more suitable for existing FW.

I agree with most of the above, but I don't really think this is an
argument either way. It just means the datapath won't be hugely
different between such two drivers, and we have to look for details to
make a decision elsewhere.

> > I think the question is about the design, but I also think the differences in the
> > association process are much more fundamental, and you _don't_ (seem to)
> > handle that in the way mac80211 does/expects, though you also don't seem to
> > handle it in the way most other full-MAC devices do (which [can] offload even
> > BSS selection.)
> > 
> 
> FW only supports add station command for AP mode. Association command is used to request and add client station to FW.
> FW will help to connect to AP and reply result to driver.
> This is another reason that we need to use cfg80211 instead of mac80211. For mac80211, management frames are passed
> through ieee80211_ops.tx and station is added via ieee80211_ops.sta_add. 
> This way can't work with FW for client mode, FW can't not be bypassed for association process for client mode.

Right, this is the important distinction here, and indeed that leave
pretty much no choice other than doing a cfg80211 driver, and I don't
think it'd make sense in mac80211 to support offloading that either.

> Thanks for your comments and suggestions. I wonder can I prepare patch v10 to let this patch be accepted?

Yes please.

johannes