Re: [Madwifi-devel] ANNOUNCE: SFLC helps developers assess ar5k (enabling free Atheros HAL)
Hi. > At least, this way we have a chance to get USB working as well (See > http://madwifi.org/ticket/33). It's not the HAL that prevents MadWifi implementing USB support. Replacing the binary-only HAL with OpenHAL and/or dissolving the HAL functionality in the driver source does not get us any closer to a working support of USB sticks. Quoting Sam Leffler on that topic: === cut === The Atheros-based USB devices work rather differently from the cardbus/pci cards. In particular there is no hal; instead there's an onboard processor that runs the hal and implements a special protocol. This means you can reuse some of madwifi but you also (probably) need to redo the code some to break out different interfaces. It's not a simple project. === cut === see: http://article.gmane.org/gmane.linux.drivers.madwifi.user/5380 > OpenBSD seems to have a working driver (if_uath.c) for these USB WLAN > sticks. Which, at least for some sticks, requires a not freely distributable binary firmware blob, by the way (see: http://archives.neohapsis.com/archives/openbsd/cvs/2006-09/0233.html ). Nevertheless, it would be nice to have that driver ported to Linux. Bye, Mike - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Madwifi-devel] ANNOUNCE: SFLC helps developers assess ar5k (enabling free Atheros HAL)
On Wed, 2006-11-15 at 14:39 -0500, Pavel Roskin wrote: > Hello! > > On Wed, 2006-11-15 at 14:21 -0500, John W. Linville wrote: > > On Wed, Nov 15, 2006 at 07:42:14PM +0100, Michael Buesch wrote: > > > > > Now that it seems to be ok to use these openbsd sources, should I port > > > them to my driver framework? > > > I looked over the ar5k code and, well, I don't like it. ;) > > > I don't really like having a HAL. I'd rather prefer a "real" driver > > > without that HAL obfuscation. > > > > I don't think anyone likes the HAL-based architecture. I don't think > > we will accept a HAL-based driver into the upstream kernel. > > I said it before, and it's worth repeating. Dissolving HAL in the > sources is easy. It's just a matter of moving functions around without > serious chances of breaking anything as long as the source compiles. > The whole "HAL-based architecture" can be reshuffled and eliminated by > one person in a few days. > > Making things work properly takes years. That's what MadWifi has been > working on for a long time, using contributions and bug reports from > scores of users and developers. > > Rejecting MadWifi because it's HAL based is like throwing away a diamond > ring because it's too narrow. No, I'd personally reject madwifi not because of the HAL but because it uses the net80211 stack [1]. We don't need another 802.11 stack in the Linux kernel, of course. But since the Devicescape people have already ported madwifi to d80211 (see David Kimdon's announcement on netdev on Oct. 17th), that appears to be a valid path to follow and at least some of the work has already been done. If the HAL bits were ported to ar5k and folded back into the driver, I think that would be a great start. Dan [1] nothing against net80211; it's a fine stack. But There Can Be Only One, if just for sanity's sake. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Madwifi-devel] ANNOUNCE: SFLC helps developers assess ar5k (enabling free Atheros HAL)
Hi. > Just in case you want to experiment, i have a working port of ar5k > that works on madwifi-old before the BSD - HEAD merge... Just to mention it: madwifi-old is no longer officially supported, and is a bad ground to start working on IMO (at least for anything that goes beyond a quick test). Interested parties should start from trunk instead (which is at r1809 as of now, by the way), or, even better, from the DadWifi branch. However, it will require some work to get the OpenHAL working in either of them. I suggest that related questions and discussions should be directed to the madwifi-devel list, since they might be of little interest (yet) on netdev or lkml. The MadWifi project is happy to provide resources (such as r/w access to our Subversion repository) to support these efforts, by the way. Please contact me offlist for details. Bye, Mike - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Madwifi-devel] ANNOUNCE: SFLC helps developers assess ar5k (enabling free Atheros HAL)
Just in case you want to experiment, i have a working port of ar5k
that works on madwifi-old before the BSD - HEAD merge...
well i'm no good programmer (yet), i did what i could (i'm sure those
define macros are nasty for most people :P) and hope that helps...
you can git clone from the following link
rsync://rsync.ath-driver.org/gnumonks_users/mb/openhal.git
I'm working with the following madwifi revision...
svn checkout http://svn.madwifi.org/branches/madwifi-old -r 1142 madwifi
Don't forget to remove the ending ) in line 175 at
net80211/ieee80211_radiotap.h ;-)
Also you'll need to do some modifications to make it work with newer
kernel versions (MODULE_PARM stuff in if_ath.c)...
diff -Naurp madwifi-openhal/ath/if_ath.c madwifi-openhal-fixed/ath/if_ath.c
--- madwifi-openhal/ath/if_ath.c2005-06-24 06:41:22.0 -0400
+++ madwifi-openhal-fixed/ath/if_ath.c 2006-08-04 14:49:38.0 -0400
@@ -245,13 +245,20 @@ enum {
#endif
static int countrycode = -1;
-MODULE_PARM(countrycode, "i");
-MODULE_PARM_DESC(countrycode, "Override default country code");
static int outdoor = -1;
-MODULE_PARM(outdoor, "i");
-MODULE_PARM_DESC(outdoor, "Enable/disable outdoor use");
static int xchanmode = -1;
+#if (LINUX_VERSION_CODE < KERNEL_VERSION(2,5,52))
+MODULE_PARM(countrycode, "i");
+MODULE_PARM(outdoor, "i");
MODULE_PARM(xchanmode, "i");
+#else
+#include
+module_param(countrycode, int, 0);
+module_param(outdoor, int, 0);
+module_param(xchanmode, int, 0);
+#endif
+MODULE_PARM_DESC(countrycode, "Override default country code");
+MODULE_PARM_DESC(outdoor, "Enable/disable outdoor use");
MODULE_PARM_DESC(xchanmode, "Enable/disable extended channel mode");
int
See README for more details
I haven't looked much the MadWiFi code since then, perhaps you can
help in making ar5k work with newer madwifi versions + improve it's
functionality to help both linux and OpenBSD.
(The name OpenHAL came from John Bicket's initial port)
Happy coding ;-)
Nick
2006/11/16, Michael Renzmann <[EMAIL PROTECTED]>:
Hi.
Michael Buesch wrote:
> Well, it never worked for me. But I gave up trying about
> half a year ago. But maybe it's just stupid me. ;)
Well, we have various support channels (an IRC channel besides two
mailing lists, for example) that you are welcome to make use of in case
of problems :)
Bye, Mike
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Madwifi-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/madwifi-devel
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Madwifi-devel] ANNOUNCE: SFLC helps developers assess ar5k (enabling free Atheros HAL)
Hi. Michael Buesch wrote: Well, it never worked for me. But I gave up trying about half a year ago. But maybe it's just stupid me. ;) Well, we have various support channels (an IRC channel besides two mailing lists, for example) that you are welcome to make use of in case of problems :) Bye, Mike - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Madwifi-devel] ANNOUNCE: SFLC helps developers assess ar5k (enabling free Atheros HAL)
On Wednesday 15 November 2006 20:39, Pavel Roskin wrote: > Hello! > > On Wed, 2006-11-15 at 14:21 -0500, John W. Linville wrote: > > On Wed, Nov 15, 2006 at 07:42:14PM +0100, Michael Buesch wrote: > > > > > Now that it seems to be ok to use these openbsd sources, should I port > > > them to my driver framework? > > > I looked over the ar5k code and, well, I don't like it. ;) > > > I don't really like having a HAL. I'd rather prefer a "real" driver > > > without that HAL obfuscation. > > > > I don't think anyone likes the HAL-based architecture. I don't think > > we will accept a HAL-based driver into the upstream kernel. > > I said it before, and it's worth repeating. Dissolving HAL in the > sources is easy. It's just a matter of moving functions around without > serious chances of breaking anything as long as the source compiles. > The whole "HAL-based architecture" can be reshuffled and eliminated by > one person in a few days. I'll look at it tomorrow. Probably best to merge this stuff into the tree somehow to get it working and clean it up afterwards. Shouldn't be too hard to merge. > Making things work properly takes years. That's what MadWifi has been > working on for a long time, using contributions and bug reports from > scores of users and developers. > > Rejecting MadWifi because it's HAL based is like throwing away a diamond > ring because it's too narrow. Well, it never worked for me. But I gave up trying about half a year ago. But maybe it's just stupid me. ;) -- Greetings Michael. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Madwifi-devel] ANNOUNCE: SFLC helps developers assess ar5k (enabling free Atheros HAL)
Hello! On Wed, 2006-11-15 at 14:21 -0500, John W. Linville wrote: > On Wed, Nov 15, 2006 at 07:42:14PM +0100, Michael Buesch wrote: > > > Now that it seems to be ok to use these openbsd sources, should I port > > them to my driver framework? > > I looked over the ar5k code and, well, I don't like it. ;) > > I don't really like having a HAL. I'd rather prefer a "real" driver > > without that HAL obfuscation. > > I don't think anyone likes the HAL-based architecture. I don't think > we will accept a HAL-based driver into the upstream kernel. I said it before, and it's worth repeating. Dissolving HAL in the sources is easy. It's just a matter of moving functions around without serious chances of breaking anything as long as the source compiles. The whole "HAL-based architecture" can be reshuffled and eliminated by one person in a few days. Making things work properly takes years. That's what MadWifi has been working on for a long time, using contributions and bug reports from scores of users and developers. Rejecting MadWifi because it's HAL based is like throwing away a diamond ring because it's too narrow. -- Regards, Pavel Roskin - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Madwifi-devel] ANNOUNCE: SFLC helps developers assess ar5k (enabling free Atheros HAL)
Michael Buesch wrote: Yeah, ok. I'll look what I can do. First I'll have to read the code. and understand it. DMA stuff seems to be really obfuscated though dozens of callbacks, heh. :) I'd certainly like to see solid Atheros chipset support in mainline. If you need any hardware or other resources to help with this effort, let me know. Thanks, Ben -- Ben Greear <[EMAIL PROTECTED]> Candela Technologies Inc http://www.candelatech.com - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
