[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070117184204.GA3899@dmt>
Date: Wed, 17 Jan 2007 16:42:04 -0200
From: Marcelo Tosatti <marcelo@...ck.org>
To: Johannes Berg <johannes@...solutions.net>
Cc: Marcelo Tosatti <marcelo@...ck.org>,
netdev <netdev@...r.kernel.org>, Jeff Garzik <jgarzik@...ox.com>,
"John W. Linville" <linville@...hat.com>,
Dan Williams <dcbw@...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, Jan 17, 2007 at 07:52:13AM +0000, Johannes Berg wrote:
> On Tue, 2007-01-16 at 16:55 -0200, Marcelo Tosatti wrote:
>
> > _Please_ review, this driver is targeted for mainline inclusion.
> >
> > There have been almost no comments resulting from the first submission.
>
> We had looked over the previous version a few days ago and noticed that
> the biggest part of the code is a mostly generic wireless stack that
> you're including along with the driver, essentially all the wlan_*
> files. I don't think that's going to fly.
How come is it a generic wireless stack? As Dan mentioned, the driver is
large, but the wireless stack is _inside_ the firmware.
It does not implement a wireless stack. Its simply an interface to the
firmware.
And using the Marvell provided firmware is a requirement for OLPC
machines, where the CPU will be shut down but the chip+firmware will
continue to forward packets in the mesh network (there are extreme power
saving constraints on these machines).
Quoting Dan Williams, who quoted the device documentation:
"This basic architecture is typical of a thick firmware architecture,
where the WLAN firmware handles all 802.11 MAC Management tasks."
"The host driver downloads standard 802.3 frames to the firmware to
transmit over the wireless link as 802.11 frames."
So it really looks like a fullmac chip, although it might require higher
interaction from the driver part, in comparison with IPW.
Its also important to note, regarding the size in LOC, that the driver
implements most of the firmware/chip configuration knobs, and there are
a _lot_ of them, unlike smaller in-tree drivers. (ie. the driver is
highly configurable). See the README file for a list.
> Also a bunch of minor things but I'd rather look over this version again
> before commenting on that.
Please go ahead and comment on all minor issues you see so we can fix
them.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists