How to start with a Marvell driver (non-USB, non-OLPC)

How to start with a Marvell driver (non-USB, non-OLPC)

[Holger Schurig]

Hi all !

This mail is an attempt to get some feedback about the way we 
should go :-)   "We" are several people interested in 802.11bg 
cards in Compact-Flash format with an Marvell 8385 (AFAIK) chip. 
See the list of people at 
http://projects.linuxtogo.org/projects/marvell8385/   A driver 
for this cards would be quite nice for PDAs and other embedded 
Linux systems.



Two months ago I sent an e-mail to Marvell for support, or at 
least to put me in contact with the product manager. There was 
no response. Maybe they don't care for sales.

However, Marvell released a GPL driver for the OLPC project, 
which is now in Linux mainline. This driver is for a different 
chip (8388 AFAIK), a different firmware (with Mesh capability) 
and a different host interface (USB). During the last month the 
libertas driver got rid of more and more code that applied to 
non-8388, non-USB, non-mesh-firmware versions of the Libertas 
chip set family. Those cleanups made the in-kernel libertas 
driver more and more unusable for the cards that I have in mind. 
They did not only clean up, they also added their specific stuff 
for their mesh solution.

I think the biggest problem here is the firmware. The OLPC people 
have a special firmware for their USB dongle, which is not used 
in other chips, so a driver that has been heavily adapted to 
this firmware isn't easy to mangle to a different firmware.

Fortunately, because of the involvement of Marvell into the OLPC 
project, they posted in a public mailing list reference 
documenentation about their firmware !  :-)



So, what I (and several other people, see want to take the OLPC 
driver, get rid of the USB stuff, add in back stuff that is 
needed for CF-Card, add mangle and treat this until we get 
something that is working.





Now, linux-2.6.20 still has Softmac. Some projects, like the 
bcm43xx, are very lively in the softwac area. d80211 is supposed 
to come into the kernel since months. I guess it's an endless 
task?  Will it ever arive?  What 80211 version should we use if 
our aim is inclusion in the stock kernel?  We don't plan, like 
so many other project, divide our working time into a year-long 
maintainance of two 80211 versions.

Re: How to start with a Marvell driver (non-USB, non-OLPC)

[John W. Linville]

On Fri, Feb 09, 2007 at 08:58:26AM +0100, Holger Schurig wrote:

> Now, linux-2.6.20 still has Softmac. Some projects, like the 
> bcm43xx, are very lively in the softwac area. d80211 is supposed 
> to come into the kernel since months. I guess it's an endless 
> task?  Will it ever arive?  What 80211 version should we use if 
> our aim is inclusion in the stock kernel?  We don't plan, like 
> so many other project, divide our working time into a year-long 
> maintainance of two 80211 versions.

d80211

John
-- 
John W. Linville
linville@tuxdriver.com

Re: How to start with a Marvell driver (non-USB, non-OLPC)

[Dan Williams]

On Fri, 2007-02-09 at 08:58 +0100, Holger Schurig wrote:
> Hi all !
> 
> This mail is an attempt to get some feedback about the way we 
> should go :-)   "We" are several people interested in 802.11bg 
> cards in Compact-Flash format with an Marvell 8385 (AFAIK) chip. 
> See the list of people at 
> http://projects.linuxtogo.org/projects/marvell8385/   A driver 
> for this cards would be quite nice for PDAs and other embedded 
> Linux systems.
> 
> 
> 
> Two months ago I sent an e-mail to Marvell for support, or at 
> least to put me in contact with the product manager. There was 
> no response. Maybe they don't care for sales.
> 
> However, Marvell released a GPL driver for the OLPC project, 
> which is now in Linux mainline. This driver is for a different 

Actually, it's not in mainline.  It's still being reviewed and hasn't
been merged.

> chip (8388 AFAIK), a different firmware (with Mesh capability) 
> and a different host interface (USB). During the last month the 
> libertas driver got rid of more and more code that applied to 
> non-8388, non-USB, non-mesh-firmware versions of the Libertas 

The only reason code was removed was because nobody was using it.  The
people who review things (rightly) consider dead code a merge blocker.
If you to keep stuff, please speak up.  It's not too late, please join
the libertas-dev mailing list at infradead.org and say what you need.
Patches are even better.

> chip set family. Those cleanups made the in-kernel libertas 
> driver more and more unusable for the cards that I have in mind. 

Again, the cleanups were because the code was unused.  Nobody said
anything about that code being required, and it wasn't required for the
card that the driver currently supports, and the kernel review people
said to drop it.

Kernel people also hate unnecessary hardware abstraction.  At the time
the driver was reviewed, the only supported card type was USB because
nobody stepped up and said they had other cards to support.  Therefore,
pieces of the driver that abstracted the hardware bits got removed.  If
you need to support CF type cards, we should add support for that
hardware rather than making a new driver.

> They did not only clean up, they also added their specific stuff 
> for their mesh solution.

If there's mesh-specific stuff that's _not_ bounded by checks for
mesh-enabled firmware, then please point them out.  Those parts, if any,
should be fixed.

> I think the biggest problem here is the firmware. The OLPC people 
> have a special firmware for their USB dongle, which is not used 
> in other chips, so a driver that has been heavily adapted to 
> this firmware isn't easy to mangle to a different firmware.

No, it really hasn't.  The mesh-specific bits are a separate code path,
and we routinely run non-mesh firmware using this driver.  If there are
places that are missing run-time firmware version checks, then we need
to fix those places.

> So, what I (and several other people, see want to take the OLPC 
> driver, get rid of the USB stuff, add in back stuff that is 
> needed for CF-Card, add mangle and treat this until we get 
> something that is working.

You probably won't get that merged.  If the 8388 OLPC driver and the
8385 CF driver share a lot of code, or if the chips are largely the same
(they are) then there will rightfully be questions about why the same
driver can't handle both chips.  And those questions are correct.

Again, why don't we work together?  We are _not_ intentionally screwing
over anybody else, and if there are pieces that you need, why don't we
put those pieces back in?

> Now, linux-2.6.20 still has Softmac. Some projects, like the 
> bcm43xx, are very lively in the softwac area. d80211 is supposed 
> to come into the kernel since months. I guess it's an endless 
> task?  Will it ever arive?  What 80211 version should we use if 
> our aim is inclusion in the stock kernel?  We don't plan, like 
> so many other project, divide our working time into a year-long 
> maintainance of two 80211 versions.

The problem is that unless you've got a radically different firmware,
you simply cannot use any of the existing 802.11 stacks.  The Marvell
part, and the firmware, are inherently full-mac type devices and cannot
be used with d80211 or ieee80211.

The long and short of it is, please don't start a forked driver, because
you may likely get denied a merge if the driver is too similar to an
existing one.  Or both of us get denied merge and then we have to work
together anyway.

There's _no_ reason we shouldn't all work together.  If you have changes
to the driver, please speak up and post them.  The original libertas
hardware abstraction bits really sucked.  Rewriting them is probably a
better use of your time than working on a forked driver.  If there are
pieces of the libertas driver that are specific to the OLPC firmware, we
need to protect those pieces with runtime checks.  We're happy to do
that.  We've even got some 8388 USB dongles we can send you for testing.

Dan

Re: How to start with a Marvell driver (non-USB, non-OLPC)

[Holger Schurig]

> > I think the biggest problem here is the firmware. The OLPC
> > people have a special firmware for their USB dongle, which
> > is not used in other chips, so a driver that has been
> > heavily adapted to this firmware isn't easy to mangle to a
> > different firmware.
>
> No, it really hasn't.  The mesh-specific bits are a separate
> code path, and we routinely run non-mesh firmware using this
> driver.  If there are places that are missing run-time
> firmware version checks, then we need to fix those places.

In the libertas mailing list someone published the "WLAN Firmware 
Spec v5.1" spec, so I guess that you're now using this firmware. 
But the Windows driver that I got hold on (to extract the 
firmware) all had a 5.0 in their driver name, so I guess they 
have a v5.0 firmware.

But I guess this can be handled with if (fw_version >= 
FW_VERSION_5_1) or something like this.


> Again, why don't we work together?  We are _not_ intentionally
> screwing over anybody else, and if there are pieces that you
> need, why don't we put those pieces back in?

Based on the things you said, I see no reason NOT to work 
together.


> We are _not_ intentionally screwing over anybody else, and if
> there are pieces that you need, why don't we put those pieces
> back in?

I did not say this. I just saw in GIT that you remove misc things 
or discussed the removed of things (e.g. CIS related code), so I 
guessed that you only go into the USB dongle direction. But 
maybe you weren't aware that other WLAN devices with similar 
chips, but different host interface are available.


> The original libertas hardware abstraction bits really sucked.

Did they release them as GPL as well?  Or do you refer to the 
copyrighted driver that is downloadable from some vendors?



I'm already in libertas-dev, so when I have time to look at the 
driver, I'll post some patches there. Rigth now I don't have 
much, e.g. I just put the infrastructure in place so that the 
PCMCIA subsystem detects the card and loads my driver.

Re: How to start with a Marvell driver (non-USB, non-OLPC)

[Dan Williams]

On Fri, 2007-02-09 at 15:24 +0100, Holger Schurig wrote:
> > > I think the biggest problem here is the firmware. The OLPC
> > > people have a special firmware for their USB dongle, which
> > > is not used in other chips, so a driver that has been
> > > heavily adapted to this firmware isn't easy to mangle to a
> > > different firmware.
> >
> > No, it really hasn't.  The mesh-specific bits are a separate
> > code path, and we routinely run non-mesh firmware using this
> > driver.  If there are places that are missing run-time
> > firmware version checks, then we need to fix those places.
> 
> In the libertas mailing list someone published the "WLAN Firmware 
> Spec v5.1" spec, so I guess that you're now using this firmware. 

Right; I think that was an inadvertent error on Ronak's part; but the
document is out there now and there's no way it can be taken back.

> But the Windows driver that I got hold on (to extract the 
> firmware) all had a 5.0 in their driver name, so I guess they 
> have a v5.0 firmware.

The WLAN Firmware document has a changelog at the end, so that might
give you the ability to figure out what pieces had been added to the
v5.1 firmware.

> But I guess this can be handled with if (fw_version >= 
> FW_VERSION_5_1) or something like this.

Exactly.  The v5.1 firmware is available on Marvell's site here; perhaps
it would work for you?  There's nothing really OLPC specific in this
particular firmware version AFAIK.  But it might be USB-only, I'm not
sure.  It would also be interesting figure out what the Boot2 firmware
version for your variant is.

http://marvell.com/drivers/driverDisplay.do?dId=160&pId=38

> > Again, why don't we work together?  We are _not_ intentionally
> > screwing over anybody else, and if there are pieces that you
> > need, why don't we put those pieces back in?
> 
> Based on the things you said, I see no reason NOT to work 
> together.

Ok, great.

> 
> > We are _not_ intentionally screwing over anybody else, and if
> > there are pieces that you need, why don't we put those pieces
> > back in?
> 
> I did not say this. I just saw in GIT that you remove misc things 
> or discussed the removed of things (e.g. CIS related code), so I 
> guessed that you only go into the USB dongle direction. But 
> maybe you weren't aware that other WLAN devices with similar 
> chips, but different host interface are available.

Right; we knew of the existence of the 8385 chip, but not much seemed to
be happening (nobody had touched the tree after an import of
libertas.git in a few weeks last I looked).  Plus arguing to keep the
ugly HAL code on the basis of future support for a chip which didn't
have any code yet doesn't fly as an argument upstream.

But that's OK, we should probably re-write the HAL bits anyway if we
need to.  AFAIK there was no CIS support really in the GPL drop from
Marvell; only the abstraction layer that would allow an if_cf.c to be
plugged in.  But trust me, it was _really_  hard to follow that code.

> > The original libertas hardware abstraction bits really sucked.
> 
> Did they release them as GPL as well?  Or do you refer to the 
> copyrighted driver that is downloadable from some vendors?

Yes, there were abstraction bits.  All the sbi_* functions were part of
the base hardware-independent layer, and the if_usb_* bits were
USB-specific.  But having a hardware abstraction layer that supported
only _one_ chip variant doesn't fly upstream, and we were asked to
remove it as a condition of merge.

> I'm already in libertas-dev, so when I have time to look at the 

And I or Marcelo should probably join 8385-devel or something too.  The
libertas-dev list hasn't been very active because only a few people are
working on it.  Who knows, if you have questions you might even get
Ronak to answer them by posting to libertas-dev :)  It might be worth a
shot.

> driver, I'll post some patches there. Rigth now I don't have 
> much, e.g. I just put the infrastructure in place so that the 
> PCMCIA subsystem detects the card and loads my driver.

Hey, that's a start.  I think the next step would be to figure out what
hardware-specific pieces need to be abstracted and to start rebuilding a
sane HAL, based on what other wireless drivers like airo & orinoco do
for the different variants (plx, pci, pcmcia, etc).

dan

Re: How to start with a Marvell driver (non-USB, non-OLPC)

[Holger Schurig]

Okay, I got encouraging replies to my initial mail. Later I 
produced some patches for discussion and posted them into 
libertas-dev and marvell8385-devel@linuxtogo.org.

But besides "please make a git repository" no one really cared 
(about the patches --- there were other reactions). No patch has 
been commented, ridiculed or applied.


If someone is interested, the patches are at
 
http://projects.linuxtogo.org/plugins/scmsvn/viewcvs.php/trunk/patches/?root=marvell8385



I consider

remove-unused-var.patch
remove-boot-command-define.patch
rename-functions.patch
remove-libertas-sbi-get-priv.patch

as applyable to libertas-2.6, the others are work-in-progress.


I'm now in the process to create a git repository at 
infradead.org, maybe this can help the process. However, I don't 
have any idea what I can do if I pushed a changeset to infradead 
and later learn that this is crap. Can I rebase the HEAD of a 
remote git repository?