netdev - Re: [PATCH] Marvell Libertas 8388 802.11b/g USB driver (v2)

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: <1169056884.9175.66.camel@johannes.berg>
Date:	Wed, 17 Jan 2007 18:01:24 +0000
From:	Johannes Berg <johannes@...solutions.net>
To:	Dan Williams <dcbw@...hat.com>
Cc:	Jiri Benc <jbenc@...e.cz>, Marcelo Tosatti <marcelo@...ck.org>,
	netdev <netdev@...r.kernel.org>, Jeff Garzik <jgarzik@...ox.com>,
	"John W. Linville" <linville@...hat.com>,
	"Luis R. Rodriguez" <mcgrof@...il.com>,
	Arnd Bergmann <arnd@...db.de>,
	Arnaldo Carvalho de Melo <acme@...stprotocols.net>
Subject: Re: [PATCH] Marvell Libertas 8388 802.11b/g USB driver (v2)

On Wed, 2007-01-17 at 12:43 -0500, Dan Williams wrote:

> I said "mostly" fullmac.  Sort of like ipw2100 (IIRC) is softmac but it
> does all the association stuff in firmware.  It doesn't fit fullmac, but
> it's a lot more fullmac than atheros.  There isn't any management frame
> processing, it doesn't do any data frame processing.

Right. I hadn't looked at data frames but suspected this is the case.

> The 8388 architecture is typical of a thick firmware architecture, where
> the firmware handles all 802.11 MAC management tasks.  The host driver
> downloads standard 802.3 frames to the firmware to be transmitted over
> the link as 802.11 frames.
> 
> I thought these 2 things were essentially _the_ definition of fullmac,
> please correct me if I'm wrong.

Well we'll need more terms here. I had a short chat with Jouni and we
agree that what the Marvell card is doing is exposing the MLME
interface, and what d80211 is doing is implementing most of the MLME.

I guess the thing I'm saying is that exposing the MLME interface which
changes fairly frequently is a bad thing and I'd love to have firmware
that exposes lower level stuff like .

> Perhaps I just don't understand how flexible d80211 has become; when we
> last were talking about it 8 months ago, it appears that it could not
> handle parts that did significant pieces of work in firmware, like the
> 8388 does.  Do we have the functionality in d80211 yet to handle pieces
> that are a full mix of hybrid full/soft mac?

No, we don't have that yet, and we might never have. But I think I'm
starting to understand the issues at hand a bit better and it seems that
we'll need cfg80211 to be redefined.

> 1) What, if any of this, could actually fit into the d80211 stack, given
> the mostly fullmac operations of this part? 

Can we rephrase this in terms of the MLME interface etc that the 802.11
standard speaks about? That'd be easier I think.

> 3) Could you enumerate your issues with the command dispatching?  Right
> now, many of the commands are blocking, which is suboptimal.  This is an
> artifact of the embedded history of the part.  We need to eventually fix
> that and make the upper layers not expect to block stuff like auth/assoc
> and scanning.  What other stuff are you thinking of?

Well, one thing is that the whole command processing goes through a
single function for no real benefit. You're basically saying
command(...,CMD_NUM,...) and in command() you do switch(cmd_num) and
multiplex it to a lot of functions again. I suppose I'd rather it called
the functions directly and those in turn called the little common code
there is in the dispatch routine.

johannes

Download attachment "signature.asc" of type "application/pgp-signature" (191 bytes)