[PATCH 2.6] Intersil Prism54 wireless driver

[PATCH 2.6] Intersil Prism54 wireless driver

[Jean Tourrilhes]

[-- Attachment #1: Type: text/plain, Size: 549 bytes --]

	Hi Dave & Jeff,

	The attached .bz2 file is a patch for 2.6.3 adding the
Intersil Prism54 wireless driver. Sorry for the attachement, the file
is rather big, if you want inline+plaintext, I'll send that personal
to you.
	I've been using this driver with great success on 2.6.3 and
2.6.4-rc1 (SMP). This driver support various popular CardBus and PCI
802.11g cards (54 Mb/s) based on the Intersil PrismGT/PrismDuette
chipset.
	I would like this driver to go into 2.6.X. However, I
understand that it's lot's of code to review.

	Have fun...

	Jean


[-- Attachment #2: patch-2.6.3-prism54-cvs20040304.bz2 --]
[-- Type: application/octet-stream, Size: 43523 bytes --]

Re: [PATCH 2.6] Intersil Prism54 wireless driver

[Jeff Garzik]

Jean Tourrilhes wrote:
> 	Hi Dave & Jeff,
> 
> 	The attached .bz2 file is a patch for 2.6.3 adding the
> Intersil Prism54 wireless driver. Sorry for the attachement, the file
> is rather big, if you want inline+plaintext, I'll send that personal
> to you.
> 	I've been using this driver with great success on 2.6.3 and
> 2.6.4-rc1 (SMP). This driver support various popular CardBus and PCI
> 802.11g cards (54 Mb/s) based on the Intersil PrismGT/PrismDuette
> chipset.
> 	I would like this driver to go into 2.6.X. However, I
> understand that it's lot's of code to review.


I would like it to go into 2.6 too :)  I'm glad somebody submitted it.

I'll review it this weekend... and hopefully some other netdev denizens 
will review as well and post their comments.

	Jeff

Re: [PATCH 2.6] Intersil Prism54 wireless driver

[Jean Tourrilhes]

On Wed, Mar 03, 2004 at 09:37:55PM -0500, Jeff Garzik wrote:
> Jean Tourrilhes wrote:
> >	Hi Dave & Jeff,
> >
> >	The attached .bz2 file is a patch for 2.6.3 adding the
> >Intersil Prism54 wireless driver. Sorry for the attachement, the file
> >is rather big, if you want inline+plaintext, I'll send that personal
> >to you.
> >	I've been using this driver with great success on 2.6.3 and
> >2.6.4-rc1 (SMP). This driver support various popular CardBus and PCI
> >802.11g cards (54 Mb/s) based on the Intersil PrismGT/PrismDuette
> >chipset.
> >	I would like this driver to go into 2.6.X. However, I
> >understand that it's lot's of code to review.
> 
> 
> I would like it to go into 2.6 too :)  I'm glad somebody submitted it.
> 
> I'll review it this weekend... and hopefully some other netdev denizens 
> will review as well and post their comments.
> 
> 	Jeff

	By the way, I should note that during my test I had
difficulties to associate with Aironet cards, but it looked like it
was a firmware related issue (firmware timing out). The rest work fine
(managed to Lucent, Ad-Hoc to another Prism54, scanning,
WE). Actually, this is the driver I used to develop ifrename.
	Have fun...

	Jean

Re: [PATCH 2.6] Intersil Prism54 wireless driver

[Jean Tourrilhes]

On Wed, Mar 03, 2004 at 09:37:55PM -0500, Jeff Garzik wrote:
> Jean Tourrilhes wrote:
> >	Hi Dave & Jeff,
> >
> >	The attached .bz2 file is a patch for 2.6.3 adding the
> >Intersil Prism54 wireless driver. Sorry for the attachement, the file
> >is rather big, if you want inline+plaintext, I'll send that personal
> >to you.
> >	I've been using this driver with great success on 2.6.3 and
> >2.6.4-rc1 (SMP). This driver support various popular CardBus and PCI
> >802.11g cards (54 Mb/s) based on the Intersil PrismGT/PrismDuette
> >chipset.
> >	I would like this driver to go into 2.6.X. However, I
> >understand that it's lot's of code to review.
> 
> 
> I would like it to go into 2.6 too :)  I'm glad somebody submitted it.
> 
> I'll review it this weekend... and hopefully some other netdev denizens 
> will review as well and post their comments.
> 
> 	Jeff

	Any news, Jeff ?
	Thanks in advance...

	Jean

Re: [PATCH 2.6] Intersil Prism54 wireless driver

[Jeff Garzik]

Jean Tourrilhes wrote:
> On Wed, Mar 03, 2004 at 09:37:55PM -0500, Jeff Garzik wrote:
> 
>>Jean Tourrilhes wrote:
>>
>>>	Hi Dave & Jeff,
>>>
>>>	The attached .bz2 file is a patch for 2.6.3 adding the
>>>Intersil Prism54 wireless driver. Sorry for the attachement, the file
>>>is rather big, if you want inline+plaintext, I'll send that personal
>>>to you.
>>>	I've been using this driver with great success on 2.6.3 and
>>>2.6.4-rc1 (SMP). This driver support various popular CardBus and PCI
>>>802.11g cards (54 Mb/s) based on the Intersil PrismGT/PrismDuette
>>>chipset.
>>>	I would like this driver to go into 2.6.X. However, I
>>>understand that it's lot's of code to review.
>>
>>
>>I would like it to go into 2.6 too :)  I'm glad somebody submitted it.
>>
>>I'll review it this weekend... and hopefully some other netdev denizens 
>>will review as well and post their comments.
>>
>>	Jeff
> 
> 
> 	Any news, Jeff ?
> 	Thanks in advance...


Looks pretty decent to me.  I'm basically waiting on 2.6.4 release to 
merge it.  I might remove some of the more egregious #ifdefs.

	Jeff

Re: [PATCH 2.6] Intersil Prism54 wireless driver

[Christoph Hellwig]

On Wed, Mar 03, 2004 at 06:35:24PM -0800, Jean Tourrilhes wrote:
> 	Hi Dave & Jeff,
> 
> 	The attached .bz2 file is a patch for 2.6.3 adding the
> Intersil Prism54 wireless driver. Sorry for the attachement, the file
> is rather big, if you want inline+plaintext, I'll send that personal
> to you.
> 	I've been using this driver with great success on 2.6.3 and
> 2.6.4-rc1 (SMP). This driver support various popular CardBus and PCI
> 802.11g cards (54 Mb/s) based on the Intersil PrismGT/PrismDuette
> chipset.
> 	I would like this driver to go into 2.6.X. However, I
> understand that it's lot's of code to review.

Here's a few things I found.  It's not exactly a full review, there's
too much new snow to spend lots of time in front of a computer here :)

diff -Naur -X /home/mcgrof/lib/dontdiff linux-2.6.3/drivers/net/wireless/prism54/Makefile linux-2.6.3-prism54/drivers/net/wireless/prism54/Makefile
--- linux-2.6.3/drivers/net/wireless/prism54/Makefile	Thu Jan  1 00:00:00 1970
+++ linux-2.6.3-prism54/drivers/net/wireless/prism54/Makefile	Thu Mar  4 02:00:01 2004
@@ -0,0 +1,10 @@
+# $Id: Makefile.k26,v 1.7 2004/01/30 16:24:00 ajfa Exp $
+
+prism54-objs := islpci_eth.o islpci_mgt.o \
+                isl_38xx.o isl_ioctl.o islpci_dev.o \
+		islpci_hotplug.o isl_wds.o oid_mgt.o

	please use foo-y for new drivers.

+
+obj-$(CONFIG_PRISM54) += prism54.o
+
+EXTRA_CFLAGS = -I$(PWD) #-DCONFIG_PRISM54_WDS

	This is bogus, especially with srcdir != objdir.
	please fixup the includes instead

+#define __KERNEL_SYSCALLS__

	this shouldn't be used anymore.

+
+#include <linux/version.h>
+#include <linux/module.h>
+#include <linux/types.h>
+#include <linux/delay.h>
+
+#include "isl_38xx.h"
+#include <linux/firmware.h>
+
+#include <asm/uaccess.h>
+#include <asm/io.h>

	Please include headers in the following order <linux/*.h>,
	<asm/*.h>, driver-specific.

+#if (LINUX_VERSION_CODE > KERNEL_VERSION(2,5,75))
+#include <linux/device.h>
+# define _REQ_FW_DEV_T struct device *
+#else
+# define _REQ_FW_DEV_T char *
+#endif

	Eeek, why don't you simply pass the pci_dev down?


+typedef struct isl38xx_cb isl38xx_control_block;

	No useless typedefs please.

+MODULE_PARM(init_mode, "i");
+MODULE_PARM_DESC(init_mode,
+		 "Set card mode:\n0: Auto\n1: Ad-Hoc\n2: Managed Client (Default)\n3: Master / Access Point\n4: Repeater (Not supported yet)\n5: Secondary (Not supported yet)\n6: Monitor");

	Please use module_param

diff -Naur -X /home/mcgrof/lib/dontdiff linux-2.6.3/drivers/net/wireless/prism54/isl_wds.c linux-2.6.3-prism54/drivers/net/wireless/prism54/isl_wds.c
--- linux-2.6.3/drivers/net/wireless/prism54/isl_wds.c	Thu Jan  1 00:00:00 1970
+++ linux-2.6.3-prism54/drivers/net/wireless/prism54/isl_wds.c	Thu Mar  4 02:00:01 2004

	WDS doesn't belong into a driver but in higher-level code.

Re: [PATCH 2.6] Intersil Prism54 wireless driver

[Jean Tourrilhes]

On Wed, Mar 10, 2004 at 04:55:48PM +0000, Christoph Hellwig wrote:
> On Wed, Mar 03, 2004 at 06:35:24PM -0800, Jean Tourrilhes wrote:
> > 	Hi Dave & Jeff,
> > 
> > 	The attached .bz2 file is a patch for 2.6.3 adding the
> > Intersil Prism54 wireless driver. Sorry for the attachement, the file
> > is rather big, if you want inline+plaintext, I'll send that personal
> > to you.
> > 	I've been using this driver with great success on 2.6.3 and
> > 2.6.4-rc1 (SMP). This driver support various popular CardBus and PCI
> > 802.11g cards (54 Mb/s) based on the Intersil PrismGT/PrismDuette
> > chipset.
> > 	I would like this driver to go into 2.6.X. However, I
> > understand that it's lot's of code to review.
> 
> Here's a few things I found.

	I'm forwarding to prism54-devel where the real developpers can
answer your questions.

>  It's not exactly a full review, there's
> too much new snow to spend lots of time in front of a computer here :)

	Grrr... This year, no snow for me.

> diff -Naur -X /home/mcgrof/lib/dontdiff linux-2.6.3/drivers/net/wireless/prism54/Makefile linux-2.6.3-prism54/drivers/net/wireless/prism54/Makefile
> --- linux-2.6.3/drivers/net/wireless/prism54/Makefile	Thu Jan  1 00:00:00 1970
> +++ linux-2.6.3-prism54/drivers/net/wireless/prism54/Makefile	Thu Mar  4 02:00:01 2004
> @@ -0,0 +1,10 @@
> +# $Id: Makefile.k26,v 1.7 2004/01/30 16:24:00 ajfa Exp $
> +
> +prism54-objs := islpci_eth.o islpci_mgt.o \
> +                isl_38xx.o isl_ioctl.o islpci_dev.o \
> +		islpci_hotplug.o isl_wds.o oid_mgt.o
> 
> 	please use foo-y for new drivers.
> 
> +
> +obj-$(CONFIG_PRISM54) += prism54.o
> +
> +EXTRA_CFLAGS = -I$(PWD) #-DCONFIG_PRISM54_WDS
> 
> 	This is bogus, especially with srcdir != objdir.
> 	please fixup the includes instead
> 
> +#define __KERNEL_SYSCALLS__
> 
> 	this shouldn't be used anymore.
> 
> +
> +#include <linux/version.h>
> +#include <linux/module.h>
> +#include <linux/types.h>
> +#include <linux/delay.h>
> +
> +#include "isl_38xx.h"
> +#include <linux/firmware.h>
> +
> +#include <asm/uaccess.h>
> +#include <asm/io.h>
> 
> 	Please include headers in the following order <linux/*.h>,
> 	<asm/*.h>, driver-specific.
> 
> +#if (LINUX_VERSION_CODE > KERNEL_VERSION(2,5,75))
> +#include <linux/device.h>
> +# define _REQ_FW_DEV_T struct device *
> +#else
> +# define _REQ_FW_DEV_T char *
> +#endif
> 
> 	Eeek, why don't you simply pass the pci_dev down?
> 
> 
> +typedef struct isl38xx_cb isl38xx_control_block;
> 
> 	No useless typedefs please.
> 
> +MODULE_PARM(init_mode, "i");
> +MODULE_PARM_DESC(init_mode,
> +		 "Set card mode:\n0: Auto\n1: Ad-Hoc\n2: Managed Client (Default)\n3: Master / Access Point\n4: Repeater (Not supported yet)\n5: Secondary (Not supported yet)\n6: Monitor");
> 
> 	Please use module_param

	I would even say that this is useless because the driver
support WE, and WE scripts set the mode before the card is up.

> diff -Naur -X /home/mcgrof/lib/dontdiff linux-2.6.3/drivers/net/wireless/prism54/isl_wds.c linux-2.6.3-prism54/drivers/net/wireless/prism54/isl_wds.c
> --- linux-2.6.3/drivers/net/wireless/prism54/isl_wds.c	Thu Jan  1 00:00:00 1970
> +++ linux-2.6.3-prism54/drivers/net/wireless/prism54/isl_wds.c	Thu Mar  4 02:00:01 2004
> 
> 	WDS doesn't belong into a driver but in higher-level code.

	The big 802.11 reorg can only happen when HostAP is in the
kernel.

	Regards,

	Jean

Re: [PATCH 2.6] Intersil Prism54 wireless driver

[Jean Tourrilhes]

On Wed, Mar 10, 2004 at 02:12:22AM -0500, Jeff Garzik wrote:
> 
> Looks pretty decent to me.  I'm basically waiting on 2.6.4 release to 
> merge it.  I might remove some of the more egregious #ifdefs.
> 
> 	Jeff

	Wonderful ! Thanks a lot !

	Jean

Re: [PATCH 2.6] Intersil Prism54 wireless driver

[Christoph Hellwig]

On Wed, Mar 10, 2004 at 09:21:14AM -0800, Jean Tourrilhes wrote:
> > --- linux-2.6.3/drivers/net/wireless/prism54/isl_wds.c	Thu Jan  1 00:00:00 1970
> > +++ linux-2.6.3-prism54/drivers/net/wireless/prism54/isl_wds.c	Thu Mar  4 02:00:01 2004
> > 
> > 	WDS doesn't belong into a driver but in higher-level code.
> 
> 	The big 802.11 reorg can only happen when HostAP is in the
> kernel.

I don't quite understand that comment.  This feature doesn't belong into
a driver.  Whether it's some day implemented in a hypothetic 802.11 midlayer
that can only be done with another driver merged is a different question,
isn't it?

> 
> 	Regards,
> 
> 	Jean
> 
---end quoted text---

Re: [PATCH 2.6] Intersil Prism54 wireless driver

[Jeff Garzik]

Jean Tourrilhes wrote:
> On Wed, Mar 10, 2004 at 04:55:48PM +0000, Christoph Hellwig wrote:
>>+MODULE_PARM(init_mode, "i");
>>+MODULE_PARM_DESC(init_mode,
>>+		 "Set card mode:\n0: Auto\n1: Ad-Hoc\n2: Managed Client (Default)\n3: Master / Access Point\n4: Repeater (Not supported yet)\n5: Secondary (Not supported yet)\n6: Monitor");
>>
>>	Please use module_param
> 
> 
> 	I would even say that this is useless because the driver
> support WE, and WE scripts set the mode before the card is up.

module_param() is a type-safe interface roughly identical to 
MODULE_PARM().  Therefore, if MODULE_PARM() works, module_param() works 
also.


>>diff -Naur -X /home/mcgrof/lib/dontdiff linux-2.6.3/drivers/net/wireless/prism54/isl_wds.c linux-2.6.3-prism54/drivers/net/wireless/prism54/isl_wds.c
>>--- linux-2.6.3/drivers/net/wireless/prism54/isl_wds.c	Thu Jan  1 00:00:00 1970
>>+++ linux-2.6.3-prism54/drivers/net/wireless/prism54/isl_wds.c	Thu Mar  4 02:00:01 2004
>>
>>	WDS doesn't belong into a driver but in higher-level code.
> 
> 
> 	The big 802.11 reorg can only happen when HostAP is in the
> kernel.

ISTR it needed some cleaning up before it could go in.

Further, in Linux, there is _never_ a requirement that "this driver be 
included before we can clean up."  You can start the re-org any time you 
wish.  Out-of-tree maintainers can follow the re-org, sometimes more easily.

	Jeff



P.S. I still need to look at your netlink thing.  Seems like a decent 
direction.

Re: [PATCH 2.6] Intersil Prism54 wireless driver

[Jean Tourrilhes]

On Wed, Mar 10, 2004 at 12:29:59PM -0500, Jeff Garzik wrote:
> Jean Tourrilhes wrote:
> >On Wed, Mar 10, 2004 at 04:55:48PM +0000, Christoph Hellwig wrote:
> >>+MODULE_PARM(init_mode, "i");
> >>+MODULE_PARM_DESC(init_mode,
> >>+		 "Set card mode:\n0: Auto\n1: Ad-Hoc\n2: Managed Client 
> >>(Default)\n3: Master / Access Point\n4: Repeater (Not supported yet)\n5: 
> >>Secondary (Not supported yet)\n6: Monitor");
> >>
> >>	Please use module_param
> >
> >
> >	I would even say that this is useless because the driver
> >support WE, and WE scripts set the mode before the card is up.
> 
> module_param() is a type-safe interface roughly identical to 
> MODULE_PARM().  Therefore, if MODULE_PARM() works, module_param() works 
> also.

	Yes, I know, I've been doing that for IrDA. What I meant was
that this specific module parameter could be remove entirely because
redundant.

> >>diff -Naur -X /home/mcgrof/lib/dontdiff 
> >>linux-2.6.3/drivers/net/wireless/prism54/isl_wds.c 
> >>linux-2.6.3-prism54/drivers/net/wireless/prism54/isl_wds.c
> >>--- linux-2.6.3/drivers/net/wireless/prism54/isl_wds.c	Thu Jan  1 
> >>00:00:00 1970
> >>+++ linux-2.6.3-prism54/drivers/net/wireless/prism54/isl_wds.c	Thu 
> >>Mar  4 02:00:01 2004
> >>
> >>	WDS doesn't belong into a driver but in higher-level code.
> >
> >
> >	The big 802.11 reorg can only happen when HostAP is in the
> >kernel.
> 
> ISTR it needed some cleaning up before it could go in.

	I think it would be nice to give some more explicit feedback
to Jouni.

> Further, in Linux, there is _never_ a requirement that "this driver be 
> included before we can clean up."  You can start the re-org any time you 
> wish.  Out-of-tree maintainers can follow the re-org, sometimes more easily.

	You misunderstood. The HostAP driver has a pretty much
complete generic 802.11 stack. However, other driver can't depend on
that code until it's in the kernel.
	By "big 802.11 reorg", I meant "make the other driver depend
on HostAP 802.11 code".
	Of course, I'm quite partial to the HostAP code because I'm
more familiar with it and I believe it's the most advanced (host WEP,
802.1x, WPA, AP...). Other candidated are linux-wlan-ng or the *BSD
stack (by the way of the MadWifi driver).

> 	Jeff
> 
> 
> 
> P.S. I still need to look at your netlink thing.  Seems like a decent 
> direction.

	Thanks ;-) I would need to make sure that there is no popular
driver still using the old driver API (orinoco_cs is converted in the
CVS).

	Jean

Re: [PATCH 2.6] Intersil Prism54 wireless driver

[Jeff Garzik]

Jean Tourrilhes wrote:
> 	You misunderstood. The HostAP driver has a pretty much
> complete generic 802.11 stack. However, other driver can't depend on
> that code until it's in the kernel.
> 	By "big 802.11 reorg", I meant "make the other driver depend
> on HostAP 802.11 code".
> 	Of course, I'm quite partial to the HostAP code because I'm
> more familiar with it and I believe it's the most advanced (host WEP,
> 802.1x, WPA, AP...). Other candidated are linux-wlan-ng or the *BSD
> stack (by the way of the MadWifi driver).

Ah!  I did indeed misunderstand.

Yes, it would be good to end the cycle of re-implementing 802.11 over 
and over again ;-)

So here is my suggested plan:
* I merge prism54 upstream
* I create wireless-2.6 queue
* somebody (you, Jouni(sp?)) submits HostAP to me
* I merge HostAP
* submit rtnetlink patches to me
* start working on generic 802.11 stack in wireless-2.6 queue
* at the same time, migrate away from iw_handler to "wireless_ops" (i.e. 
something like ethtool_ops)
* once things have stabilized again, merge upstream

I'm not sure about the order of the last few steps, you know better than 
I what dependencies exist.

	Jeff

Re: [PATCH 2.6] Intersil Prism54 wireless driver

[Jeff Garzik]

Jean Tourrilhes wrote:
> On Wed, Mar 10, 2004 at 04:55:48PM +0000, Christoph Hellwig wrote:
> 
>>On Wed, Mar 03, 2004 at 06:35:24PM -0800, Jean Tourrilhes wrote:
>>
>>>	Hi Dave & Jeff,
>>>
>>>	The attached .bz2 file is a patch for 2.6.3 adding the
>>>Intersil Prism54 wireless driver. Sorry for the attachement, the file
>>>is rather big, if you want inline+plaintext, I'll send that personal
>>>to you.
>>>	I've been using this driver with great success on 2.6.3 and
>>>2.6.4-rc1 (SMP). This driver support various popular CardBus and PCI
>>>802.11g cards (54 Mb/s) based on the Intersil PrismGT/PrismDuette
>>>chipset.
>>>	I would like this driver to go into 2.6.X. However, I
>>>understand that it's lot's of code to review.
>>
>>Here's a few things I found.
> 
> 
> 	I'm forwarding to prism54-devel where the real developpers can
> answer your questions.

since I'm not on the this list, I am getting a bunch of "your message 
for prism54-devel awaits moderator approval" responses.

Maybe the prism54 and hostAP developers could join us on netdev?  It 
would be nice to have everybody in one place, if we're all gonna be 
collaborating on a generic 802.11 stack.

	Jeff

Re: Re: [PATCH 2.6] Intersil Prism54 wireless driver

[Luis R. Rodriguez]

[-- Attachment #1: Type: text/plain, Size: 4381 bytes --]

On Wed, Mar 10, 2004 at 09:21:14AM -0800, Jean Tourrilhes wrote:
> On Wed, Mar 10, 2004 at 04:55:48PM +0000, Christoph Hellwig wrote:
> > On Wed, Mar 03, 2004 at 06:35:24PM -0800, Jean Tourrilhes wrote:
> > > 	Hi Dave & Jeff,
> > > 
> > > 	The attached .bz2 file is a patch for 2.6.3 adding the
> > > Intersil Prism54 wireless driver. Sorry for the attachement, the file
> > > is rather big, if you want inline+plaintext, I'll send that personal
> > > to you.
> > > 	I've been using this driver with great success on 2.6.3 and
> > > 2.6.4-rc1 (SMP). This driver support various popular CardBus and PCI
> > > 802.11g cards (54 Mb/s) based on the Intersil PrismGT/PrismDuette
> > > chipset.
> > > 	I would like this driver to go into 2.6.X. However, I
> > > understand that it's lot's of code to review.
> > 
> > Here's a few things I found.
> 
> 	I'm forwarding to prism54-devel where the real developpers can
> answer your questions.
> 
> >  It's not exactly a full review, there's
> > too much new snow to spend lots of time in front of a computer here :)
> 
> 	Grrr... This year, no snow for me.
> 
> > diff -Naur -X /home/mcgrof/lib/dontdiff linux-2.6.3/drivers/net/wireless/prism54/Makefile linux-2.6.3-prism54/drivers/net/wireless/prism54/Makefile
> > --- linux-2.6.3/drivers/net/wireless/prism54/Makefile	Thu Jan  1 00:00:00 1970
> > +++ linux-2.6.3-prism54/drivers/net/wireless/prism54/Makefile	Thu Mar  4 02:00:01 2004
> > @@ -0,0 +1,10 @@
> > +# $Id: Makefile.k26,v 1.7 2004/01/30 16:24:00 ajfa Exp $
> > +
> > +prism54-objs := islpci_eth.o islpci_mgt.o \
> > +                isl_38xx.o isl_ioctl.o islpci_dev.o \
> > +		islpci_hotplug.o isl_wds.o oid_mgt.o
> > 
> > 	please use foo-y for new drivers.

TODO

> > 
> > +
> > +obj-$(CONFIG_PRISM54) += prism54.o
> > +
> > +EXTRA_CFLAGS = -I$(PWD) #-DCONFIG_PRISM54_WDS
> > 
> > 	This is bogus, especially with srcdir != objdir.
> > 	please fixup the includes instead
> > 
> > +#define __KERNEL_SYSCALLS__
> > 
> > 	this shouldn't be used anymore.

Done

> > 
> > +
> > +#include <linux/version.h>
> > +#include <linux/module.h>
> > +#include <linux/types.h>
> > +#include <linux/delay.h>
> > +
> > +#include "isl_38xx.h"
> > +#include <linux/firmware.h>
> > +
> > +#include <asm/uaccess.h>
> > +#include <asm/io.h>
> > 
> > 	Please include headers in the following order <linux/*.h>,
> > 	<asm/*.h>, driver-specific.

Done

> > 
> > +#if (LINUX_VERSION_CODE > KERNEL_VERSION(2,5,75))
> > +#include <linux/device.h>
> > +# define _REQ_FW_DEV_T struct device *
> > +#else
> > +# define _REQ_FW_DEV_T char *
> > +#endif
> > 
> > 	Eeek, why don't you simply pass the pci_dev down?

TODO

> > 
> > 
> > +typedef struct isl38xx_cb isl38xx_control_block;
> > 
> > 	No useless typedefs please.
> > 
> > +MODULE_PARM(init_mode, "i");
> > +MODULE_PARM_DESC(init_mode,
> > +		 "Set card mode:\n0: Auto\n1: Ad-Hoc\n2: Managed Client (Default)\n3: Master / Access Point\n4: Repeater (Not supported yet)\n5: Secondary (Not supported yet)\n6: Monitor");
> > 
> > 	Please use module_param

Done

> 
> 	I would even say that this is useless because the driver
> support WE, and WE scripts set the mode before the card is up.

True, we can just remove the param for iw_mode.

> 
> > diff -Naur -X /home/mcgrof/lib/dontdiff linux-2.6.3/drivers/net/wireless/prism54/isl_wds.c linux-2.6.3-prism54/drivers/net/wireless/prism54/isl_wds.c
> > --- linux-2.6.3/drivers/net/wireless/prism54/isl_wds.c	Thu Jan  1 00:00:00 1970
> > +++ linux-2.6.3-prism54/drivers/net/wireless/prism54/isl_wds.c	Thu Mar  4 02:00:01 2004
> > 
> > 	WDS doesn't belong into a driver but in higher-level code.

The driver features some firmware-specific WDS functionality, such as
adding/removing WDS links. We haven't looked much into it yet though since
it's not high priority. Where exactly should this code go to then?

Elements noted as DONE were just committed into our CVS repository. You
can always find our latest 2.6 kernel patch at:

http://prism54.org/pub/linux/snapshot/kernel/v2.6/patch-2.6-prism54-cvs-latest.bz2

FWIW, the same driver code base supports 2.4:
http://prism54.org/pub/linux/snapshot/kernel/v2.4/patch-2.4-prism54-cvs-latest.bz2

	Luis

-- 
GnuPG Key fingerprint = 113F B290 C6D2 0251 4D84  A34A 6ADD 4937 E20A 525E

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH 2.6] Intersil Prism54 wireless driver

[James Ketrenos]

Jeff Garzik wrote:

 > Yes, it would be good to end the cycle of re-implementing 802.11 over
 > and over again ;-)

< snip >

 > * start working on generic 802.11 stack in wireless-2.6 queue

As we're currently walking the path of implementing the same thing for the 
IPW2100 driver,  being able to re-use this code would be _very nice_.

I'd like to get WEP into IPW2100 as soon as possible, and would like to do so in 
a way that would make transitioning to a common 802.11 layer seamless (or at 
least reasonably isolated).  Any suggestions on how to best do this, or where we 
might be able to help, would be much appreciated.

I'm very interested in these discussions, so if they move to or are being 
discussed on another list (besides netdev), please let me know where.

Thanks,
James

Re: [PATCH 2.6] Intersil Prism54 wireless driver

[Jouni Malinen]

On Wed, Mar 10, 2004 at 01:07:17PM -0500, Jeff Garzik wrote:

> Maybe the prism54 and hostAP developers could join us on netdev?  It 
> would be nice to have everybody in one place, if we're all gonna be 
> collaborating on a generic 802.11 stack.

I am (and have been for quite a while) on netdev, so as far as anything
related to IEEE 802.11 stack or Host AP driver is concerned, I certainly
do follow netdev list, too. 

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: [PATCH 2.6] Intersil Prism54 wireless driver

[Jouni Malinen]

On Wed, Mar 10, 2004 at 05:37:16PM -0600, James Ketrenos wrote:

> I'd like to get WEP into IPW2100 as soon as possible, and would like to do 
> so in a way that would make transitioning to a common 802.11 layer seamless 
> (or at least reasonably isolated).  Any suggestions on how to best do this, 
> or where we might be able to help, would be much appreciated.

Host AP driver (http://hostap.epitest.fi/) has generic (i.e., hardware
independent) implementation of IEEE 802.11 encryption for WEP, TKIP, and
CCMP. These functions take in skb's with IEEE 802.11 headers and
encrypt/decrypt the frames. I haven't yet taken a look at your IPW2100
driver, but if you are including IEEE 802.11 headers in the skb's at
some point, I would assume that the WEP implementation from Host AP
driver would work fine with that driver, too.

The current implementation has hardware independent module (hostap.ko)
that exports the crypto functions for IEEE 802.11 skb's. Both client
station and AP is supported. (To be honest, there is probably still
couple of small Prism2-specific parts in hostap.ko, but not in the
crypto parts and I'm in the process of getting rid of the remaining
wlan hardware dependent parts).

I'm in the process of replacing the algorithm parts (RC4, Michael MIC,
AES-CCM) with crypto API versions so that only the IEEE 802.11 specific
parts (like format of the IV/packet number, replay protection,
pseudo-header for authentication) remain in the implementation and
low-level crypto algorithms can share code with other uses. Once this is
done, I would hope to get the code merged into the kernel tree either
with full Host AP driver or separately. One option would be to first add
Host AP driver in its current structure (i.e., everything in
drivers/net/wireless) and then create a new directory (net/ieee80211 ?)
for generic IEEE 802.11 functionality and start moving things like the
IEEE 802.11 encryption into the new location.

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: [PATCH 2.6] Intersil Prism54 wireless driver

[Jeff Garzik]

Jouni Malinen wrote:
> done, I would hope to get the code merged into the kernel tree either
> with full Host AP driver or separately. One option would be to first add
> Host AP driver in its current structure (i.e., everything in
> drivers/net/wireless) and then create a new directory (net/ieee80211 ?)
> for generic IEEE 802.11 functionality and start moving things like the
> IEEE 802.11 encryption into the new location.

Given the discussion today, I think my preference is to merge all of 
HostAP into the wireless-2.6 tree I just created, then submit patches to 
that which create and populate net/802_11.  Once the work on that is 
mostly done, it can get merged back into the main upstream tree.

	Jeff

Re: [PATCH 2.6] Intersil Prism54 wireless driver

[Jouni Malinen]

On Wed, Mar 10, 2004 at 12:58:28PM -0500, Jeff Garzik wrote:

> So here is my suggested plan:
> * I merge prism54 upstream
> * I create wireless-2.6 queue
> * somebody (you, Jouni(sp?)) submits HostAP to me
> * I merge HostAP

Sounds good to me. I have the Kconfig/Makefile(etc.) patches ready and
the current CVS snapshot of Host AP driver supports 2.6.x kernel
versions, so in theory it is ready to be submitted.

When this topic came up some time ago, I got one concrete comment about
needed changes before the merge (I think it was from you) and that was
to replace the internal encryption algorithms with crypto API ones. I'm
currently in the process of doing this and submitting needed changes for
crypto API. WEP and TKIP have the needed parts as crypto API components
(RC4 is already in kernel tree, Michael MIC patch is pending). CCMP
requires some work (new encryption mode, counter with CBC-MAC, but AES
is already in crypto API).

What would be the preferred order for the HostAP submission? I'm
currently doing the crypto changes in the Host AP CVS repository, but I
can do this also in another repository since you mentioned a new
non-mainline queue for wireless-2.6. I have also some other cleanup
things in my to do list (like getting rid of 2.4 and old wireless
extensions compatibility code, because this would not be needed in the
kernel tree anymore). Again, this is currently proceeding in my CVS
repository, but it can also be done elsewhere, if that is desired.

I'm going to be at the IEEE 802.11 meeting for the next week which is
probably going to take more or less all of my time, but I should be able
to allocate more time after that. If people are interested in reviewing
the current Host AP code from the viewpoint of what would need to happen
before it can be merged into the kernel tree, the latest version is
available as a snapshot from my CVS tree (pserver or tarball) at
http://hostap.epitest.fi/. The current version is almost 20k lines, so
there is certainly quite a bit of code to review. I hope to get this to
about 15k lines, though, with the crypto API and backwards
compatibility cleanup.

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: [PATCH 2.6] Intersil Prism54 wireless driver

[Jeff Garzik]

Jouni Malinen wrote:
> I'm going to be at the IEEE 802.11 meeting for the next week which is
> probably going to take more or less all of my time, but I should be able
> to allocate more time after that. If people are interested in reviewing
> the current Host AP code from the viewpoint of what would need to happen
> before it can be merged into the kernel tree, the latest version is
> available as a snapshot from my CVS tree (pserver or tarball) at
> http://hostap.epitest.fi/. The current version is almost 20k lines, so
> there is certainly quite a bit of code to review. I hope to get this to
> about 15k lines, though, with the crypto API and backwards
> compatibility cleanup.

How about submitting a patch, when the CryptoAPI and backcompat cleanups 
are complete?  I will apply to the wireless-2.6 tree, and we can start 
working on the kernel's overall 802.11 support from there.  I don't 
pretend to be an 802.11 expert, so I'll let you and Jean and other 
developers drive that end of things.  I'm mainly interested in keeping 
the API simple and clean, and maintainable.

	Jeff

Re: [PATCH 2.6] Intersil Prism54 wireless driver

[Jouni Malinen]

On Wed, Mar 10, 2004 at 10:02:20PM -0500, Jeff Garzik wrote:

> How about submitting a patch, when the CryptoAPI and backcompat cleanups 
> are complete?  I will apply to the wireless-2.6 tree, and we can start 
> working on the kernel's overall 802.11 support from there.

OK, I'll do the cleanups in the Host AP CVS and submit the patch after
that. I'll make a new branch for this cleanup, so the changes will be
available there if people are interested in commenting the code before
the cleanup is complete.

-- 
Jouni Malinen                                            PGP id EFC895FA

Device naming for wireless NICs...

[James Ketrenos]

If this topic been hashed a lot already, please let me know the keywords I might 
search for in the archives to find the threads.

I've had a few requests by users of the IPW2100 wireless driver to switch the 
default interface name to be wlanX vs. ethX.  In my prior searches through the 
wireless drivers in the 2.6.3 kernel tree, I couldn't find any that changed from 
the default.

I don't mind adding a module parameter to change the default name (if that is 
the standard practice), but thought I'd see what others thing rather than just 
going off and doing something random.

Is there a technical or ease of use reason switching away from ethX?  My 
thinking in keeping it eth was that it then represents a greater chance of "just 
working" with most networking scripts and utilities that may assume ethX is the 
interface name.

Thanks,
James

Re: Device naming for wireless NICs...

[Tomasz Torcz]

On Thu, Mar 11, 2004 at 10:28:23AM -0600, James Ketrenos wrote:
> I don't mind adding a module parameter to change the default name (if that 
> is the standard practice), but thought I'd see what others thing rather 
> than just going off and doing something random.

 This could be handled by nameif in userspace.
 
> Is there a technical or ease of use reason switching away from ethX?  My 
> thinking in keeping it eth was that it then represents a greater chance of 
> "just working" with most networking scripts and utilities that may assume 
> ethX is the interface name.

 I personally find them broken. I had to remove checking the name from
ethtool to make it work. Ethtool checks for 'eth' or 'usb' in name,
which do not work with my e1000 renamed to 'ep0'.

-- 
Tomasz Torcz                Only gods can safely risk perfection,     
zdzichu@irc.-nie.spam-.pl     it's a dangerous thing for a man.  -- Alia

Re: Device naming for wireless NICs...

[Matthew Galgoci]

On Thu, 11 Mar 2004, James Ketrenos wrote:

> 
> If this topic been hashed a lot already, please let me know the keywords I might 
> search for in the archives to find the threads.
> 
> I've had a few requests by users of the IPW2100 wireless driver to switch the 
> default interface name to be wlanX vs. ethX.  In my prior searches through the 
> wireless drivers in the 2.6.3 kernel tree, I couldn't find any that changed from 
> the default.
> 
> I don't mind adding a module parameter to change the default name (if that is 
> the standard practice), but thought I'd see what others thing rather than just 
> going off and doing something random.
> 
> Is there a technical or ease of use reason switching away from ethX?  My 
> thinking in keeping it eth was that it then represents a greater chance of "just 
> working" with most networking scripts and utilities that may assume ethX is the 
> interface name.

TBH I don't think it much matters. I know that at least Red Hat's networking scripts 
(and possibly other distributions) did at one point assume that each interface would 
be named ethX, but I don't think that is the case anymore.

Some drivers even present both a wlanX and an ethX interface, which I think is an atavism
that goes back to networking scripts breaking horribly on non-ethX interface names.

Going forward it might be worth while to standardize all wireless interface names, just
to show at a glance that an interface is 802.11x, and also to differentiate the fact that
eventually 802.11 will be its own network stack.

-- 
Matthew Galgoci
System Administrator
Red Hat, Inc
919.754.3700 x44155

Re: Device naming for wireless NICs...

[Jean Tourrilhes]

James Ketrenos wrote :
> 
> If this topic been hashed a lot already, please let me know the
> keywords I might search for in the archives to find the threads.
> 
> I've had a few requests by users of the IPW2100 wireless driver to
> switch the default interface name to be wlanX vs. ethX.  In my prior
> searches through the wireless drivers in the 2.6.3 kernel tree, I
> couldn't find any that changed from the default.

	This is my personal rule of thumb :
	o if the interface use Ethernet frames (i.e. offer Ethernet
emulation), then it should be name 'ethX'.
	o if the interface use 802.11 frames (rawe/native), it should
use 'wifiX'.

	The Aironet driver is a good example of this, for each
hardware it offers two interfaces, 'ethX' and 'wifiY'.
	Personally, I've been converting a few drivers to use 'ethX'
and removing 'wlanX' hacks where I saw them..

> I don't mind adding a module parameter to change the default name
> (if that is the standard practice), but thought I'd see what others
> thing rather than just going off and doing something random.

	Just point them to :
http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/HOTPLUG.txt

> Is there a technical or ease of use reason switching away from ethX?
> My thinking in keeping it eth was that it then represents a greater
> chance of "just working" with most networking scripts and utilities
> that may assume ethX is the interface name.

	Note that the RedHat graphical configuration tool (neat) seems
to insist on only using 'ethX' names. Yes, only using 'ethX' is
generally safer (principle of least surprise).

	Have fun...

	Jean

Re: Device naming for wireless NICs...

[Jeff Garzik]

James Ketrenos wrote:
> 
> If this topic been hashed a lot already, please let me know the keywords 
> I might search for in the archives to find the threads.
> 
> I've had a few requests by users of the IPW2100 wireless driver to 
> switch the default interface name to be wlanX vs. ethX.  In my prior 
> searches through the wireless drivers in the 2.6.3 kernel tree, I 
> couldn't find any that changed from the default.

I lean towards wlan%d, but until we have the generic 802.11 stack going 
it's really up to the driver maintainer (you, in this case).

Like Matthew said, any code that assumes a specific interface prefix, be 
it eth%d or wlan%d, is buggy.  Users are allowed to choose random 
interface names for their interfaces, often via nameif(8) program.  My 
own ethtool program is broken in this regard...

	Jeff

Re: Device naming for wireless NICs...

[Jeff Garzik]

Matthew Galgoci wrote:
> Going forward it might be worth while to standardize all wireless interface names, just
> to show at a glance that an interface is 802.11x, and also to differentiate the fact that
> eventually 802.11 will be its own network stack.

I definitely want to standardize on something like wlan%d.  We should 
get that for free when a generic 802.11 stack is in place, which implies 
that there will be a common wireless helper as a peer to ether_setup() 
in the current tree.

	Jeff

Re: Device naming for wireless NICs...

[Matthew Galgoci]

> 	Note that the RedHat graphical configuration tool (neat) seems
> to insist on only using 'ethX' names. Yes, only using 'ethX' is
> generally safer (principle of least surprise).

neat is old and outdated :)

Have a look at the redhat-config-network tools in Red Hat Linux or in Fedora,
the system-config-network tools.

I am sure the author of the tools would appreciate feedback :)
 
-- 
Matthew Galgoci
System Administrator
Red Hat, Inc
919.754.3700 x44155

Re: Device naming for wireless NICs...

[Jean Tourrilhes]

On Thu, Mar 11, 2004 at 02:33:58PM -0500, Matthew Galgoci wrote:
> > 	Note that the RedHat graphical configuration tool (neat) seems
> > to insist on only using 'ethX' names. Yes, only using 'ethX' is
> > generally safer (principle of least surprise).
> 
> neat is old and outdated :)
> 
> Have a look at the redhat-config-network tools in Red Hat Linux or in Fedora,
> the system-config-network tools.

	I don't use Red-Hat, it's just that people here complain to me
when their Red-Hat doesn't work. The joy of being the "Linux expert".

> I am sure the author of the tools would appreciate feedback :)

	My approach has always been 'edit the darn text file', so I
may not be the most qualified on the subject of graphical tools. I
kept using the original Pcmcia scripts up to one month ago.
	Anyway, I write enough documentation on what I believe is "the
right way", but it's funny, the Red-Hat people never send me feedback
on those docs.
	But, somehow, life goes on and everything works ;-)

> Matthew Galgoci

	Jean

Re: Device naming for wireless NICs...

[P]

Jeff Garzik wrote:
> James Ketrenos wrote:
> 
> Like Matthew said, any code that assumes a specific interface prefix, be 
> it eth%d or wlan%d, is buggy.  Users are allowed to choose random 
> interface names for their interfaces, often via nameif(8) program.  My 
> own ethtool program is broken in this regard...

My trivial patch fixes that.
http://sourceforge.net/tracker/index.php?func=detail&aid=780937&group_id=3242&atid=303242

Just wondering about the release schedule for ethtool?

Pádraig.

Re: [PATCH 2.6] Intersil Prism54 wireless driver

[Pavel Machek]

On St 10-03-04 21:43:08, Jeff Garzik wrote:
> Jouni Malinen wrote:
> >done, I would hope to get the code merged into the kernel tree either
> >with full Host AP driver or separately. One option would be to first add
> >Host AP driver in its current structure (i.e., everything in
> >drivers/net/wireless) and then create a new directory (net/ieee80211 ?)
> >for generic IEEE 802.11 functionality and start moving things like the
> >IEEE 802.11 encryption into the new location.
> 
> Given the discussion today, I think my preference is to merge all of 
> HostAP into the wireless-2.6 tree I just created, then submit patches to 
> that which create and populate net/802_11.  Once the work on that is 
> mostly done, it can get merged back into the main upstream tree.

Can we have net/wifi? 802_11 looks ugly. 802.11 would be better, but
wifi seems best.
								Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: [PATCH 2.6] Intersil Prism54 wireless driver

[Jeff Garzik]

Pavel Machek wrote:
> Can we have net/wifi? 802_11 looks ugly. 802.11 would be better, but
> wifi seems best.

That's fine, I'm not picky about it...

	Jeff

Re: [PATCH 2.6] Intersil Prism54 wireless driver

[Jean Tourrilhes]

On Mon, Mar 15, 2004 at 11:18:26PM +0100, Pavel Machek wrote:
> On St 10-03-04 21:43:08, Jeff Garzik wrote:
> > Jouni Malinen wrote:
> > >done, I would hope to get the code merged into the kernel tree either
> > >with full Host AP driver or separately. One option would be to first add
> > >Host AP driver in its current structure (i.e., everything in
> > >drivers/net/wireless) and then create a new directory (net/ieee80211 ?)
> > >for generic IEEE 802.11 functionality and start moving things like the
> > >IEEE 802.11 encryption into the new location.
> > 
> > Given the discussion today, I think my preference is to merge all of 
> > HostAP into the wireless-2.6 tree I just created, then submit patches to 
> > that which create and populate net/802_11.  Once the work on that is 
> > mostly done, it can get merged back into the main upstream tree.
> 
> Can we have net/wifi? 802_11 looks ugly. 802.11 would be better, but
> wifi seems best.
> 								Pavel

	IEEE 802.11 is a technical standard. WiFi is a marketing
certification. There are 802.11 products which are not WiFi certified
(actually, there is one such driver already in the kernel).
	By the way, I don't really care about the final name, I'm hust
being pedantic ;-)
	Have fun...

	Jean