Re: [Madwifi-devel] ANNOUNCE: SFLC helps developers assess ar5k (enabling free Atheros HAL)

2006-11-16 Thread Nick Kossifidis

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 linux/moduleparam.h
+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.phpp=sourceforgeCID=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)

2006-11-16 Thread Dan Williams
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)

2006-11-16 Thread Michael Renzmann
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)

2006-11-15 Thread Ben Greear

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


Re: [Madwifi-devel] ANNOUNCE: SFLC helps developers assess ar5k (enabling free Atheros HAL)

2006-11-15 Thread Pavel Roskin
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)

2006-11-15 Thread Michael Buesch
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)

2006-11-15 Thread Michael Renzmann

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