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: <b2d9a7ef53c5ab4212617e8edf202bbafe52e2f8.camel@sipsolutions.net>
Date: Wed, 20 Mar 2024 10:12:45 +0100
From: Johannes Berg <johannes@...solutions.net>
To: David Lin <yu-hao.lin@....com>, Brian Norris <briannorris@...omium.org>,
  Francesco Dolcini <francesco@...cini.it>
Cc: "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 Wed, 2024-03-20 at 01:10 +0000, David Lin wrote:
> > > 
> > > Also decl.h should probably _shrink_ rather than grow, a number of
> > > things just replicate ieee80211.h (such as MWIFIEX_MGMT_HEADER_LEN
> > > really is just
> > > sizeof(ieee80211_mgmt) or so? Not quite correctly.)
> > > 
> > 
> > This can be done for feature patches.

But this is a feature patch :-)

> > > So yeah, agree with Brian, not only would this be the first, but it's
> > > also something we don't really _want_. All other drivers that want
> > > stuff like this are stuck in staging ...
> > > 
> > > So why is this needed for a supposedly "firmware does it all" driver,
> > > and why can it not be integrated with mac80211 if it's no longer "firmware
> > does it all"?
> > > 
> > > Johannes
> > 
> > Our proprietary driver is cfg80211 driver, it is very hard to create a brand new
> > mac80211 driver and still can port all tested stuffs from our proprietary driver.

That basically doesn't matter for upstream at all.

> 
> BTW, vendor should have the choice to use cfg80211 or mac80211 for their chips, right?

No, that's not how it works. The choice should be what makes sense
architecturally.

johannes