* How to start with a Marvell driver (non-USB, non-OLPC) @ 2007-02-09 7:58 Holger Schurig 2007-02-09 12:35 ` John W. Linville ` (2 more replies) 0 siblings, 3 replies; 6+ messages in thread From: Holger Schurig @ 2007-02-09 7:58 UTC (permalink / raw) To: linux-wireless, marvell8385-devel, frankh, rchokshi 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: How to start with a Marvell driver (non-USB, non-OLPC) 2007-02-09 7:58 How to start with a Marvell driver (non-USB, non-OLPC) Holger Schurig @ 2007-02-09 12:35 ` John W. Linville 2007-02-09 12:49 ` Dan Williams 2007-02-15 8:40 ` Holger Schurig 2 siblings, 0 replies; 6+ messages in thread From: John W. Linville @ 2007-02-09 12:35 UTC (permalink / raw) To: Holger Schurig; +Cc: linux-wireless, marvell8385-devel, frankh, rchokshi 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: How to start with a Marvell driver (non-USB, non-OLPC) 2007-02-09 7:58 How to start with a Marvell driver (non-USB, non-OLPC) Holger Schurig 2007-02-09 12:35 ` John W. Linville @ 2007-02-09 12:49 ` Dan Williams 2007-02-09 14:24 ` Holger Schurig 2007-02-15 8:40 ` Holger Schurig 2 siblings, 1 reply; 6+ messages in thread From: Dan Williams @ 2007-02-09 12:49 UTC (permalink / raw) To: Holger Schurig; +Cc: linux-wireless, marvell8385-devel, frankh, rchokshi 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: How to start with a Marvell driver (non-USB, non-OLPC) 2007-02-09 12:49 ` Dan Williams @ 2007-02-09 14:24 ` Holger Schurig 2007-02-09 15:49 ` Dan Williams 0 siblings, 1 reply; 6+ messages in thread From: Holger Schurig @ 2007-02-09 14:24 UTC (permalink / raw) To: Dan Williams; +Cc: linux-wireless, marvell8385-devel, frankh, rchokshi > > 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: How to start with a Marvell driver (non-USB, non-OLPC) 2007-02-09 14:24 ` Holger Schurig @ 2007-02-09 15:49 ` Dan Williams 0 siblings, 0 replies; 6+ messages in thread From: Dan Williams @ 2007-02-09 15:49 UTC (permalink / raw) To: Holger Schurig; +Cc: linux-wireless, marvell8385-devel, frankh, rchokshi 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: How to start with a Marvell driver (non-USB, non-OLPC) 2007-02-09 7:58 How to start with a Marvell driver (non-USB, non-OLPC) Holger Schurig 2007-02-09 12:35 ` John W. Linville 2007-02-09 12:49 ` Dan Williams @ 2007-02-15 8:40 ` Holger Schurig 2 siblings, 0 replies; 6+ messages in thread From: Holger Schurig @ 2007-02-15 8:40 UTC (permalink / raw) To: linux-wireless 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? ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2007-02-15 8:41 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2007-02-09 7:58 How to start with a Marvell driver (non-USB, non-OLPC) Holger Schurig 2007-02-09 12:35 ` John W. Linville 2007-02-09 12:49 ` Dan Williams 2007-02-09 14:24 ` Holger Schurig 2007-02-09 15:49 ` Dan Williams 2007-02-15 8:40 ` Holger Schurig
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.