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