Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Atheros and rt2x00 driver

0 views
Skip to first unread message

Jon Jahren

unread,
Aug 17, 2005, 1:15:43 PM8/17/05
to Linux Kernel Mailing List
Hello, I'm new to the mailling list, and couldn't find any traces of
discussing this anywhere. I was wondering why neither the atheros driver
http://madwifi.sourceforge.net, or the rt2x00 driver
http://rt2x00.serialmonkey.com/wiki/index.php/Main_Page is included in
the kernel?
Regards
Jon Jahren

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

joe...@spamtest.viacore.net

unread,
Aug 17, 2005, 1:47:47 PM8/17/05
to Jon Jahren, Linux Kernel Mailing List
On Wed, 17 Aug 2005, Jon Jahren wrote:
> Hello, I'm new to the mailling list, and couldn't find any traces of
> discussing this anywhere. I was wondering why neither the atheros driver
> http://madwifi.sourceforge.net, or the rt2x00 driver
> http://rt2x00.serialmonkey.com/wiki/index.php/Main_Page is included in
> the kernel?

That's because a) these drivers are not "proven stable" -- ie they have
not released a well-tested, known-good, working version of the software
and b) they haven't asked for their software to be included in the kernel
(at least in the case of madwifi, anyways). c) madwifi also will probably
never be integrated into the mainstream kernel because it contains
binary-only proprietary software licensed by atheros communications (under
NDA by the developer). Since the kernel is released GPL, the source must
be made available for all parts of the kernel if desired. Code released
closed source cannot be included else we violate the terms of the GPL.
I'm not sure about rt2x00, but it may have a similar deficiency.

By the way, the best place to ask about why XX isn't included in the
kernel is with the developers of XX unless they tell you to ask here :)

Hope this clears some stuff up for you. ciao.

-kelsey

Daniel J Blueman

unread,
Aug 17, 2005, 2:11:41 PM8/17/05
to Linux Kernel, rt2400-...@lists.sourceforge.net
On Wed, 17 Aug 2005, Jon Jahren wrote:
> Hello, I'm new to the mailling list, and couldn't find any traces of
> discussing this anywhere. I was wondering why neither the atheros driver
> http://madwifi.sourceforge.net, or the rt2x00 driver
> http://rt2x00.serialmonkey.com /wiki/index.php/Main_Page is included in
> the kernel?

There is a good chance the rt2x00 driver will get into the kernel tree
in time, since there is no firmware to upload - Ralink Tech
(www.ralink.com.tw) took a design decision to incorporate the firmware
into an EEPROM on-board, allowing their driver to be GPL'd, and the
rt2x00 is a Linux-specific rewrite which is stabilising well.
___
Daniel J Blueman

David S. Miller

unread,
Aug 17, 2005, 2:45:58 PM8/17/05
to shaor...@gmail.com, linux-...@vger.kernel.org
From: Jon Jahren <shaor...@gmail.com>
Date: Wed, 17 Aug 2005 19:15:43 +0200

> Hello, I'm new to the mailling list, and couldn't find any traces of
> discussing this anywhere. I was wondering why neither the atheros driver
> http://madwifi.sourceforge.net, or the rt2x00 driver
> http://rt2x00.serialmonkey.com/wiki/index.php/Main_Page is included in
> the kernel?

Because the Atheros driver has binary-only components.

Mateusz Berezecki

unread,
Aug 18, 2005, 4:53:39 PM8/18/05
to Linux Kernel
Daniel J Blueman <daniel....@gmail.com> wrote:
->
-> There is a good chance the rt2x00 driver will get into the kernel tree
-> in time, since there is no firmware to upload - Ralink Tech
-> (www.ralink.com.tw) took a design decision to incorporate the firmware
-> into an EEPROM on-board, allowing their driver to be GPL'd, and the
-> rt2x00 is a Linux-specific rewrite which is stabilising well.

the same applies to atheros. they got stuff either in eeprom or in
driver. no firmware necessary.

there is an ongoing project for atheros cards.
work in progress located at http://mateusz.agrest.org/atheros/


/M

--
@..@ Mateusz Berezecki
(----) mate...@gmail.com http://mateusz.agrest.org
( >__< ) PGP: 5F1C 86DF 89DB BFE9 899E 8CBE EB60 B7A7 43F9 5808
^^ ~~ ^^

signature.asc

Jeff Garzik

unread,
Aug 18, 2005, 5:05:57 PM8/18/05
to Mateusz Berezecki, Linux Kernel, Andrew Morton, David S. Miller
Mateusz Berezecki wrote:
> Daniel J Blueman <daniel....@gmail.com> wrote:
> ->
> -> There is a good chance the rt2x00 driver will get into the kernel tree
> -> in time, since there is no firmware to upload - Ralink Tech
> -> (www.ralink.com.tw) took a design decision to incorporate the firmware
> -> into an EEPROM on-board, allowing their driver to be GPL'd, and the
> -> rt2x00 is a Linux-specific rewrite which is stabilising well.
>
> the same applies to atheros. they got stuff either in eeprom or in
> driver. no firmware necessary.
>
> there is an ongoing project for atheros cards.
> work in progress located at http://mateusz.agrest.org/atheros/


There is still the open question of whether this is legal enough to
include in the kernel :(

I really would have preferred a cleanroom approach, like that taken by
the forcedeth driver authors.

Jeff

Lee Revell

unread,
Aug 19, 2005, 8:33:25 PM8/19/05
to Daniel J Blueman, Linux Kernel, rt2400-...@lists.sourceforge.net
On Wed, 2005-08-17 at 19:11 +0100, Daniel J Blueman wrote:
> Ralink Tech (www.ralink.com.tw) took a design decision to incorporate
> the firmware into an EEPROM on-board, allowing their driver to be
> GPL'd

Binary only firmware and firmware loading is perfectly compatible with
the GPL, as long as the vendor includes a license to redistribute the
firmware. The problem was that vendors were distributing the firmware
embedded in the driver code as a big hex string, without a separate
license, which made the firmware fall under the GPL, which make the
whole kernel undistributable as there's no source code for the firmware.

Lee

Florian Weimer

unread,
Aug 31, 2005, 3:57:56 AM8/31/05
to Jeff Garzik, Mateusz Berezecki, Linux Kernel, Andrew Morton, David S. Miller
* Jeff Garzik:

> There is still the open question of whether this is legal enough to
> include in the kernel :(

Are you referring to FTC issues, or potential copyright/trade secret
issues?

The FTC issues are shared by many (most?) wireless drivers. The
copyright/trade secret issues might be worked around by basing the
work on the OpenBSD version of that driver (and someone is actually
working on that).

Mateusz Berezecki

unread,
Aug 31, 2005, 4:12:06 AM8/31/05
to Florian Weimer, Jeff Garzik, Linux Kernel, Andrew Morton, David S. Miller
Florian Weimer <f...@deneb.enyo.de> wrote:
-> The FTC issues are shared by many (most?) wireless drivers. The
-> copyright/trade secret issues might be worked around by basing the
-> work on the OpenBSD version of that driver (and someone is actually
-> working on that).

the problem with openbsd version of the hal is that it is - sorry to
say that - fundamentally broken, at least it was last time I was
checking. It misses just too much functionality. Apart from that, the
work I'm doing is partially based on that openbsd stuff :)
(no, this doesn't contradict what I wrote above)

Mateusz

Florian Weimer

unread,
Aug 31, 2005, 4:29:26 AM8/31/05
to Jeff Garzik, Linux Kernel, Andrew Morton, David S. Miller
* Mateusz Berezecki:

> Florian Weimer <f...@deneb.enyo.de> wrote:
> -> The FTC issues are shared by many (most?) wireless drivers. The
> -> copyright/trade secret issues might be worked around by basing the
> -> work on the OpenBSD version of that driver (and someone is actually
> -> working on that).
>
> the problem with openbsd version of the hal is that it is - sorry to
> say that - fundamentally broken, at least it was last time I was
> checking.

It's better than nothing, that is, it worked for us when we gave it a
try. And it seems to be relatively unencumbered.

Denis Vlasenko

unread,
Aug 31, 2005, 5:28:49 AM8/31/05
to Mateusz Berezecki, Florian Weimer, Jeff Garzik, Linux Kernel, Andrew Morton, David S. Miller
On Wednesday 31 August 2005 11:16, Mateusz Berezecki wrote:
> Florian Weimer <f...@deneb.enyo.de> wrote:
> -> The FTC issues are shared by many (most?) wireless drivers. The
> -> copyright/trade secret issues might be worked around by basing the
> -> work on the OpenBSD version of that driver (and someone is actually
> -> working on that).
>
> the problem with openbsd version of the hal is that it is - sorry to
> say that - fundamentally broken, at least it was last time I was
> checking. It misses just too much functionality. Apart from that, the

What it can do? In particular, can it:
* send packets with arbitrary contents? In particular, packets
shorter than 3-address 802.11 header? packets with WEP bit set?
Does it allow to do WEP encoding by host instead of hal?
Any weird limitations?
* receive packets?
* tune to the given channel (or freq)?

If it can do that, everything else IIRC can be done in software.
Really, what prevents us from, say, beacons every 1/10s?

> work I'm doing is partially based on that openbsd stuff :)
> (no, this doesn't contradict what I wrote above)

Nice to see you are in "release early" crowd.

http://mateusz.agrest.org/atheros/:
may I suggest using atheros-20050805 instead of atheros-08052005
(will maintain correct sorting order in 2006,2007...)
--
vda

Mateusz Berezecki

unread,
Aug 31, 2005, 6:20:53 AM8/31/05
to Florian Weimer, Jeff Garzik, Linux Kernel
Florian Weimer <f...@deneb.enyo.de> wrote:
-> > the problem with openbsd version of the hal is that it is - sorry to
-> > say that - fundamentally broken, at least it was last time I was
-> > checking.
->
-> It's better than nothing, that is, it worked for us when we gave it a
-> try. And it seems to be relatively unencumbered.

ok, maybe it sounded to harsh. What I really meant was that when I
was doing my research on the atheros chipset I revealed some
differences between what is actually in HAL and what is in openbsd
driver. It could have been due to the update schedule of madwifi. It
is always easier to be up to date with the vendor supported driver
than with reverse engineered one. Anyways what I saw was that some
parts were missing in openbsd. I don't know how much in overall.

Mateusz Berezecki

unread,
Aug 31, 2005, 6:31:02 AM8/31/05
to Denis Vlasenko, Florian Weimer, Jeff Garzik, Linux Kernel
Denis Vlasenko <v...@ilport.com.ua> wrote:
-> What it can do? In particular, can it:
-> * send packets with arbitrary contents? In particular, packets
-> shorter than 3-address 802.11 header? packets with WEP bit set?
-> Does it allow to do WEP encoding by host instead of hal?
-> Any weird limitations?
-> * receive packets?
-> * tune to the given channel (or freq)?
->

I don't really know to which version you are referring to. If you
wrote about OpenBSD then I can't give an authoritative answer.

-> If it can do that, everything else IIRC can be done in software.
-> Really, what prevents us from, say, beacons every 1/10s?

Yes, that is a very nature of atheros radio chips. It is simplier to
tell what you can't do in software with these chipsets. This
complicates writing a driver a bit too ;-)

->
-> Nice to see you are in "release early" crowd.
->
-> http://mateusz.agrest.org/atheros/:
-> may I suggest using atheros-20050805 instead of atheros-08052005
-> (will maintain correct sorting order in 2006,2007...)

Hummm... these are old patches :) the new site is located at

http://www.ath-driver.org

As I'm going to put separate patch snapshots out there too, I will
change the naming order.

0 new messages