Re: orinoco_cs & IrDA
On Tue, 24 Apr 2001, Jean Tourrilhes wrote: > > I've got a question... I would like where to send my driver > patches... Probably both me and Alan. [ General rules follow. Too few people seem to have seen them before ] Most importantly, when sending patches to me: - specify clearly that you really want to see them in the standard kernel, and why. I occasionally get patches that just say "this is a good idea". I don't apply them. Especially if they are cc'd to somebody else too, in which case I pretty much assume that it's a RFC, not a "real patch". - do NOT send patches in attachements. Send one patch per mail, in clear-text under your message, so that I can easily see the patch and decide then-and-there whether it looks ok. And if it doesn't look ok, and I do a "reply", the patch gets included in the reply so that I can point out which part of the patch I dislike. Don't worry about sending me five emails. That's FINE. I much prefer seeing five consecutive emails from the same person with five distinct subject lines and five distinct patches, than seeing one email with five attachements to it. - if your email system is broken, and you want to send patches as attachements to avoid whitspace damage, then please FIX YOUR EMAIL SYSTEM INSTEAD. - Don't point to web-sites. If I have to move the mouse outside my email xterm to work on the email, your email just got ignored. - Make your patches one sub-directory under the source tree you're working on. In short, your patches should look like something like --- clean/fs/inode.c ... +++ linux/fs/inode.c .. @@ -179,7 +179,7 @@ ... so that I can (regardless of where my source tree is) apply them with "patch -p1" from my linux top directory. Then I can just do a cd v2.4/linux patch -p1 < ~/multiple-emails-with-multiple-accepted-patches and not have to worry about three patches being based on /usr/src/linux, while two others not having a path at all and being individual filenames in linux/drivers/net. - and finally: re-send. If I had laser-eye surgery the fay you sent the patches, I won't have applied them. If I took a day off and spent it with the kids at the pool instead, I won't have applied them. If I decided that this weekend I'm not going to read email for a change, I won't have applied them. And when I come back to work a day or two later, I will have several hundred other emails to work through. I never go backwards in my emails. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: orinoco_cs IrDA
On Tue, 24 Apr 2001, Jean Tourrilhes wrote: I've got a question... I would like where to send my driver patches... Probably both me and Alan. [ General rules follow. Too few people seem to have seen them before ] Most importantly, when sending patches to me: - specify clearly that you really want to see them in the standard kernel, and why. I occasionally get patches that just say this is a good idea. I don't apply them. Especially if they are cc'd to somebody else too, in which case I pretty much assume that it's a RFC, not a real patch. - do NOT send patches in attachements. Send one patch per mail, in clear-text under your message, so that I can easily see the patch and decide then-and-there whether it looks ok. And if it doesn't look ok, and I do a reply, the patch gets included in the reply so that I can point out which part of the patch I dislike. Don't worry about sending me five emails. That's FINE. I much prefer seeing five consecutive emails from the same person with five distinct subject lines and five distinct patches, than seeing one email with five attachements to it. - if your email system is broken, and you want to send patches as attachements to avoid whitspace damage, then please FIX YOUR EMAIL SYSTEM INSTEAD. - Don't point to web-sites. If I have to move the mouse outside my email xterm to work on the email, your email just got ignored. - Make your patches one sub-directory under the source tree you're working on. In short, your patches should look like something like --- clean/fs/inode.c ... +++ linux/fs/inode.c .. @@ -179,7 +179,7 @@ ... so that I can (regardless of where my source tree is) apply them with patch -p1 from my linux top directory. Then I can just do a cd v2.4/linux patch -p1 ~/multiple-emails-with-multiple-accepted-patches and not have to worry about three patches being based on /usr/src/linux, while two others not having a path at all and being individual filenames in linux/drivers/net. - and finally: re-send. If I had laser-eye surgery the fay you sent the patches, I won't have applied them. If I took a day off and spent it with the kids at the pool instead, I won't have applied them. If I decided that this weekend I'm not going to read email for a change, I won't have applied them. And when I come back to work a day or two later, I will have several hundred other emails to work through. I never go backwards in my emails. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: orinoco_cs & IrDA
On Tue, Apr 24, 2001 at 06:25:50PM -0700, Jean Tourrilhes wrote: > > Ok, now to the second chapter. These are all the changes > accumulated since the patch I sent one month ago (cf previous e-mail). > Changes : > o more Prism2/Symbol compatibility goodies > o Tested D-Link cards and Lucent firmware 7.28 > o Cleanup, bug fixes from David Gibson > The whole is tested, as usual... 75% of the patch was on my > web pages for the last month and people seem to have liked it. > > I've made 2 patches, one for 2.4.4-pre6 and one for > 2.4.3-ac13. The difference between the two is minor (one line). > > Linus : please have a look at orinoco_v4b.diff (first > attachement). Of course, this patch will apply and work only if you > have applied the patch in my previous e-mail. > > Alan : orinoco_v4b-alan.diff is for you (second attachement). > > Have fun... > > Jean File attached this time... Jean diff -u -p linux/drivers/net/pcmcia/wireless.25b/hermes.h linux/drivers/net/pcmcia/hermes.h --- linux/drivers/net/pcmcia/wireless.25b/hermes.h Tue Apr 24 15:57:48 2001 +++ linux/drivers/net/pcmcia/hermes.h Tue Apr 24 16:04:34 2001 @@ -35,18 +35,18 @@ /* * Limits and constants */ -#defineHERMES_ALLOC_LEN_MIN((uint16_t)4) -#defineHERMES_ALLOC_LEN_MAX((uint16_t)2400) +#defineHERMES_ALLOC_LEN_MIN(4) +#defineHERMES_ALLOC_LEN_MAX(2400) #defineHERMES_LTV_LEN_MAX (34) -#defineHERMES_BAP_DATALEN_MAX ((uint16_t)4096) -#defineHERMES_BAP_OFFSET_MAX ((uint16_t)4096) -#defineHERMES_PORTID_MAX ((uint16_t)7) -#defineHERMES_NUMPORTS_MAX ((uint16_t)(HERMES_PORTID_MAX+1)) -#defineHERMES_PDR_LEN_MAX ((uint16_t)260) /* in bytes, from EK */ -#defineHERMES_PDA_RECS_MAX ((uint16_t)200) /* a guess */ -#defineHERMES_PDA_LEN_MAX ((uint16_t)1024)/* in bytes, from EK */ -#defineHERMES_SCANRESULT_MAX ((uint16_t)35) -#defineHERMES_CHINFORESULT_MAX ((uint16_t)8) +#defineHERMES_BAP_DATALEN_MAX (4096) +#defineHERMES_BAP_OFFSET_MAX (4096) +#defineHERMES_PORTID_MAX (7) +#defineHERMES_NUMPORTS_MAX (HERMES_PORTID_MAX+1) +#defineHERMES_PDR_LEN_MAX (260) /* in bytes, from EK */ +#defineHERMES_PDA_RECS_MAX (200) /* a guess */ +#defineHERMES_PDA_LEN_MAX (1024) /* in bytes, from EK */ +#defineHERMES_SCANRESULT_MAX (35) +#defineHERMES_CHINFORESULT_MAX (8) #defineHERMES_FRAME_LEN_MAX(2304) #defineHERMES_MAX_MULTICAST(16) #defineHERMES_MAGIC(0x7d1f) @@ -86,122 +86,125 @@ /* * CMD register bitmasks */ -#defineHERMES_CMD_BUSY ((uint16_t)0x8000) -#defineHERMES_CMD_AINFO((uint16_t)0x7f00) -#defineHERMES_CMD_MACPORT ((uint16_t)0x0700) -#defineHERMES_CMD_RECL ((uint16_t)0x0100) -#defineHERMES_CMD_WRITE((uint16_t)0x0100) -#defineHERMES_CMD_PROGMODE ((uint16_t)0x0300) -#defineHERMES_CMD_CMDCODE ((uint16_t)0x003f) +#defineHERMES_CMD_BUSY (0x8000) +#defineHERMES_CMD_AINFO(0x7f00) +#defineHERMES_CMD_MACPORT (0x0700) +#defineHERMES_CMD_RECL (0x0100) +#defineHERMES_CMD_WRITE(0x0100) +#defineHERMES_CMD_PROGMODE (0x0300) +#defineHERMES_CMD_CMDCODE (0x003f) /* * STATUS register bitmasks */ -#defineHERMES_STATUS_RESULT((uint16_t)0x7f00) -#defineHERMES_STATUS_CMDCODE ((uint16_t)0x003f) +#defineHERMES_STATUS_RESULT(0x7f00) +#defineHERMES_STATUS_CMDCODE (0x003f) /* * OFFSET refister bitmasks */ -#defineHERMES_OFFSET_BUSY ((uint16_t)0x8000) -#defineHERMES_OFFSET_ERR ((uint16_t)0x4000) -#defineHERMES_OFFSET_DATAOFF ((uint16_t)0x0ffe) +#defineHERMES_OFFSET_BUSY (0x8000) +#defineHERMES_OFFSET_ERR (0x4000) +#defineHERMES_OFFSET_DATAOFF
Re: orinoco_cs & IrDA
On Tue, Apr 24, 2001 at 03:56:37PM -0700, Jean Tourrilhes wrote: > On Tue, Apr 24, 2001 at 03:15:08PM -0700, Jean Tourrilhes wrote: > > > [...] > > Downloaded the patch again (patch-2.4.4-pre6), checked that it > > was complete, my patch is in. Oups ! Do I feel stupid... > > Let's finish this story. As indicated above, the first > fragment of the patch I sent on month ago is in the kernel. The two > other fragments didn't make it. They are attached... Ok, now to the second chapter. These are all the changes accumulated since the patch I sent one month ago (cf previous e-mail). Changes : o more Prism2/Symbol compatibility goodies o Tested D-Link cards and Lucent firmware 7.28 o Cleanup, bug fixes from David Gibson The whole is tested, as usual... 75% of the patch was on my web pages for the last month and people seem to have liked it. I've made 2 patches, one for 2.4.4-pre6 and one for 2.4.3-ac13. The difference between the two is minor (one line). Linus : please have a look at orinoco_v4b.diff (first attachement). Of course, this patch will apply and work only if you have applied the patch in my previous e-mail. Alan : orinoco_v4b-alan.diff is for you (second attachement). Have fun... Jean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: orinoco_cs & IrDA
On Tue, Apr 24, 2001 at 03:15:08PM -0700, Jean Tourrilhes wrote:
>
[...]
> Downloaded the patch again (patch-2.4.4-pre6), checked that it
> was complete, my patch is in. Oups ! Do I feel stupid...
Let's finish this story. As indicated above, the first
fragment of the patch I sent on month ago is in the kernel. The two
other fragments didn't make it. They are attached...
wireless.v11b.diff :
--
Update the various wireless LAN driver in the kernel to
version 11 (definition already in the kernel). This update is
necessary to avoid crashes in the user space utilities.
orinoco_w11.diff :
Same deal for the new orinoco_cs driver.
I've also added the retry limit setting, but this feature is
not enabled (priv->has_retry = 0).
Alan : those two are already in your last kernel, please ignore.
Linus : those are not in your kernel.
That's it...
Jean
diff -u -p linux/drivers/net/wireless.25/wavelan.c linux/drivers/net/wavelan.c
--- linux/drivers/net/wireless.25/wavelan.c Wed Mar 28 17:27:27 2001
+++ linux/drivers/net/wavelan.c Wed Mar 28 17:28:34 2001
@@ -2028,8 +2028,17 @@ static int wavelan_ioctl(struct net_devi
if (wrq->u.data.pointer != (caddr_t) 0) {
struct iw_range range;
- /* Set the length (useless: it's constant). */
+ /* Set the length (very important for backward
+* compatibility) */
wrq->u.data.length = sizeof(struct iw_range);
+
+ /* Set all the info we don't care or don't know
+* about to zero */
+ memset(, 0, sizeof(range));
+
+ /* Set the Wireless Extension versions */
+ range.we_version_compiled = WIRELESS_EXT;
+ range.we_version_source = 9;
/* Set information in the range struct. */
range.throughput = 1.6 * 1000 * 1000; /* don't argue on this
! */
diff -u -p linux/drivers/net/pcmcia/wireless.25/wavelan_cs.c
linux/drivers/net/pcmcia/wavelan_cs.c
--- linux/drivers/net/pcmcia/wireless.25/wavelan_cs.c Wed Mar 28 17:21:02 2001
+++ linux/drivers/net/pcmcia/wavelan_cs.c Wed Mar 28 17:23:19 2001
@@ -2239,8 +2239,15 @@ wavelan_ioctl(struct net_device *dev,/
{
struct iw_range range;
- /* Set the length (useless : its constant...) */
+ /* Set the length (very important for backward compatibility) */
wrq->u.data.length = sizeof(struct iw_range);
+
+ /* Set all the info we don't care or don't know about to zero */
+ memset(, 0, sizeof(range));
+
+ /* Set the Wireless Extension versions */
+ range.we_version_compiled = WIRELESS_EXT;
+ range.we_version_source = 9; /* Nothing for us in v10 and v11 */
/* Set information in the range struct */
range.throughput = 1.4 * 1000 * 1000; /* don't argue on this ! */
diff -u -p linux/drivers/net/pcmcia/wireless.25/netwave_cs.c
linux/drivers/net/pcmcia/netwave_cs.c
--- linux/drivers/net/pcmcia/wireless.25/netwave_cs.c Wed Mar 28 17:24:40 2001
+++ linux/drivers/net/pcmcia/netwave_cs.c Wed Mar 28 17:29:39 2001
@@ -710,8 +710,17 @@ static int netwave_ioctl(struct net_devi
if(wrq->u.data.pointer != (caddr_t) 0) {
struct iw_range range;
- /* Set the length (useless : its constant...) */
+ /* Set the length (very important for backward compatibility) */
wrq->u.data.length = sizeof(struct iw_range);
+
+ /* Set all the info we don't care or don't know about to zero */
+ memset(, 0, sizeof(range));
+
+#if WIRELESS_EXT > 10
+ /* Set the Wireless Extension versions */
+ range.we_version_compiled = WIRELESS_EXT;
+ range.we_version_source = 9; /* Nothing for us in v10 and v11 */
+#endif /* WIRELESS_EXT > 10 */
/* Set information in the range struct */
range.throughput = 450 * 1000; /* don't argue on this ! */
diff -u -p linux/drivers/net/pcmcia/wireless.25/ray_cs.c
linux/drivers/net/pcmcia/ray_cs.c
--- linux/drivers/net/pcmcia/wireless.25/ray_cs.c Wed Mar 28 17:21:57 2001
+++ linux/drivers/net/pcmcia/ray_cs.c Wed Mar 28 17:30:16 2001
@@ -1332,8 +1332,14 @@ static int ray_dev_ioctl(struct net_devi
struct iw_range range;
memset((char *) , 0, sizeof(struct iw_range));
- /* Set the length (useless : its constant...) */
+ /* Set the length (very important for backward compatibility) */
wrq->u.data.length = sizeof(struct iw_range);
+
+#if WIRELESS_EXT > 10
+ /* Set the Wireless Extension versions */
+ range.we_version_compiled = WIRELESS_EXT;
+ range.we_version_source = 9;
Re: orinoco_cs & IrDA
On Tue, Apr 24, 2001 at 08:47:30PM +0100, Alan Cox wrote: > > patch (without feedback), whereas Alan picked it up (if I remember > > correctly it was included in his 'patch-2.4.2-ac28'). > > So now, what should I do with the rest of my updates and the > > new one that have accumulated since ? Should I wait until you grab the > > first patch from Alan's tree ? Should I send the new patches directly > > to Alan so that he can accumulate a monster patch ? Should I just > > accumulate the patches on my web page ? > > Im happy to accumulate them but please send them to Linus too. I tend not to > submit stuff on to Linus where there is an active maintainer and assume the > maintainer will do it when ready. Oups ! Big mea culpa ! Apologies. While trying to compile my kernel, I've just realised the the patch I've downloaded wasn't complete. My browser cut it in the middle claiming that it was 100% complete. Downloaded the patch again (patch-2.4.4-pre6), checked that it was complete, my patch is in. Oups ! Do I feel stupid... Apologies to everybody... Sorry for the confusion... Jean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: orinoco_cs & IrDA
> patch (without feedback), whereas Alan picked it up (if I remember > correctly it was included in his 'patch-2.4.2-ac28'). > So now, what should I do with the rest of my updates and the > new one that have accumulated since ? Should I wait until you grab the > first patch from Alan's tree ? Should I send the new patches directly > to Alan so that he can accumulate a monster patch ? Should I just > accumulate the patches on my web page ? Im happy to accumulate them but please send them to Linus too. I tend not to submit stuff on to Linus where there is an active maintainer and assume the maintainer will do it when ready. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
orinoco_cs & IrDA
Hi Linus, I've got a question... I would like where to send my driver patches... One month ago, I sent a small update for the orinoco_cs driver and Wireless Extensions. I didn't put all the changes I had for orinoco_cs because I believe in small incremental updates limited to a specific area (even if all the changes are trivial). You ignored my patch (without feedback), whereas Alan picked it up (if I remember correctly it was included in his 'patch-2.4.2-ac28'). So now, what should I do with the rest of my updates and the new one that have accumulated since ? Should I wait until you grab the first patch from Alan's tree ? Should I send the new patches directly to Alan so that he can accumulate a monster patch ? Should I just accumulate the patches on my web page ? Another day, I will also tell you about the IrDA patches... Have fun... Jean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
orinoco_cs IrDA
Hi Linus, I've got a question... I would like where to send my driver patches... One month ago, I sent a small update for the orinoco_cs driver and Wireless Extensions. I didn't put all the changes I had for orinoco_cs because I believe in small incremental updates limited to a specific area (even if all the changes are trivial). You ignored my patch (without feedback), whereas Alan picked it up (if I remember correctly it was included in his 'patch-2.4.2-ac28'). So now, what should I do with the rest of my updates and the new one that have accumulated since ? Should I wait until you grab the first patch from Alan's tree ? Should I send the new patches directly to Alan so that he can accumulate a monster patch ? Should I just accumulate the patches on my web page ? Another day, I will also tell you about the IrDA patches... Have fun... Jean - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: orinoco_cs IrDA
patch (without feedback), whereas Alan picked it up (if I remember correctly it was included in his 'patch-2.4.2-ac28'). So now, what should I do with the rest of my updates and the new one that have accumulated since ? Should I wait until you grab the first patch from Alan's tree ? Should I send the new patches directly to Alan so that he can accumulate a monster patch ? Should I just accumulate the patches on my web page ? Im happy to accumulate them but please send them to Linus too. I tend not to submit stuff on to Linus where there is an active maintainer and assume the maintainer will do it when ready. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: orinoco_cs IrDA
On Tue, Apr 24, 2001 at 08:47:30PM +0100, Alan Cox wrote: patch (without feedback), whereas Alan picked it up (if I remember correctly it was included in his 'patch-2.4.2-ac28'). So now, what should I do with the rest of my updates and the new one that have accumulated since ? Should I wait until you grab the first patch from Alan's tree ? Should I send the new patches directly to Alan so that he can accumulate a monster patch ? Should I just accumulate the patches on my web page ? Im happy to accumulate them but please send them to Linus too. I tend not to submit stuff on to Linus where there is an active maintainer and assume the maintainer will do it when ready. Oups ! Big mea culpa ! Apologies. While trying to compile my kernel, I've just realised the the patch I've downloaded wasn't complete. My browser cut it in the middle claiming that it was 100% complete. Downloaded the patch again (patch-2.4.4-pre6), checked that it was complete, my patch is in. Oups ! Do I feel stupid... Apologies to everybody... Sorry for the confusion... Jean - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: orinoco_cs IrDA
On Tue, Apr 24, 2001 at 03:15:08PM -0700, Jean Tourrilhes wrote:
[...]
Downloaded the patch again (patch-2.4.4-pre6), checked that it
was complete, my patch is in. Oups ! Do I feel stupid...
Let's finish this story. As indicated above, the first
fragment of the patch I sent on month ago is in the kernel. The two
other fragments didn't make it. They are attached...
wireless.v11b.diff :
--
Update the various wireless LAN driver in the kernel to
version 11 (definition already in the kernel). This update is
necessary to avoid crashes in the user space utilities.
orinoco_w11.diff :
Same deal for the new orinoco_cs driver.
I've also added the retry limit setting, but this feature is
not enabled (priv-has_retry = 0).
Alan : those two are already in your last kernel, please ignore.
Linus : those are not in your kernel.
That's it...
Jean
diff -u -p linux/drivers/net/wireless.25/wavelan.c linux/drivers/net/wavelan.c
--- linux/drivers/net/wireless.25/wavelan.c Wed Mar 28 17:27:27 2001
+++ linux/drivers/net/wavelan.c Wed Mar 28 17:28:34 2001
@@ -2028,8 +2028,17 @@ static int wavelan_ioctl(struct net_devi
if (wrq-u.data.pointer != (caddr_t) 0) {
struct iw_range range;
- /* Set the length (useless: it's constant). */
+ /* Set the length (very important for backward
+* compatibility) */
wrq-u.data.length = sizeof(struct iw_range);
+
+ /* Set all the info we don't care or don't know
+* about to zero */
+ memset(range, 0, sizeof(range));
+
+ /* Set the Wireless Extension versions */
+ range.we_version_compiled = WIRELESS_EXT;
+ range.we_version_source = 9;
/* Set information in the range struct. */
range.throughput = 1.6 * 1000 * 1000; /* don't argue on this
! */
diff -u -p linux/drivers/net/pcmcia/wireless.25/wavelan_cs.c
linux/drivers/net/pcmcia/wavelan_cs.c
--- linux/drivers/net/pcmcia/wireless.25/wavelan_cs.c Wed Mar 28 17:21:02 2001
+++ linux/drivers/net/pcmcia/wavelan_cs.c Wed Mar 28 17:23:19 2001
@@ -2239,8 +2239,15 @@ wavelan_ioctl(struct net_device *dev,/
{
struct iw_range range;
- /* Set the length (useless : its constant...) */
+ /* Set the length (very important for backward compatibility) */
wrq-u.data.length = sizeof(struct iw_range);
+
+ /* Set all the info we don't care or don't know about to zero */
+ memset(range, 0, sizeof(range));
+
+ /* Set the Wireless Extension versions */
+ range.we_version_compiled = WIRELESS_EXT;
+ range.we_version_source = 9; /* Nothing for us in v10 and v11 */
/* Set information in the range struct */
range.throughput = 1.4 * 1000 * 1000; /* don't argue on this ! */
diff -u -p linux/drivers/net/pcmcia/wireless.25/netwave_cs.c
linux/drivers/net/pcmcia/netwave_cs.c
--- linux/drivers/net/pcmcia/wireless.25/netwave_cs.c Wed Mar 28 17:24:40 2001
+++ linux/drivers/net/pcmcia/netwave_cs.c Wed Mar 28 17:29:39 2001
@@ -710,8 +710,17 @@ static int netwave_ioctl(struct net_devi
if(wrq-u.data.pointer != (caddr_t) 0) {
struct iw_range range;
- /* Set the length (useless : its constant...) */
+ /* Set the length (very important for backward compatibility) */
wrq-u.data.length = sizeof(struct iw_range);
+
+ /* Set all the info we don't care or don't know about to zero */
+ memset(range, 0, sizeof(range));
+
+#if WIRELESS_EXT 10
+ /* Set the Wireless Extension versions */
+ range.we_version_compiled = WIRELESS_EXT;
+ range.we_version_source = 9; /* Nothing for us in v10 and v11 */
+#endif /* WIRELESS_EXT 10 */
/* Set information in the range struct */
range.throughput = 450 * 1000; /* don't argue on this ! */
diff -u -p linux/drivers/net/pcmcia/wireless.25/ray_cs.c
linux/drivers/net/pcmcia/ray_cs.c
--- linux/drivers/net/pcmcia/wireless.25/ray_cs.c Wed Mar 28 17:21:57 2001
+++ linux/drivers/net/pcmcia/ray_cs.c Wed Mar 28 17:30:16 2001
@@ -1332,8 +1332,14 @@ static int ray_dev_ioctl(struct net_devi
struct iw_range range;
memset((char *) range, 0, sizeof(struct iw_range));
- /* Set the length (useless : its constant...) */
+ /* Set the length (very important for backward compatibility) */
wrq-u.data.length = sizeof(struct iw_range);
+
+#if WIRELESS_EXT 10
+ /* Set the Wireless Extension versions */
+ range.we_version_compiled = WIRELESS_EXT;
+ range.we_version_source
Re: orinoco_cs IrDA
On Tue, Apr 24, 2001 at 03:56:37PM -0700, Jean Tourrilhes wrote: On Tue, Apr 24, 2001 at 03:15:08PM -0700, Jean Tourrilhes wrote: [...] Downloaded the patch again (patch-2.4.4-pre6), checked that it was complete, my patch is in. Oups ! Do I feel stupid... Let's finish this story. As indicated above, the first fragment of the patch I sent on month ago is in the kernel. The two other fragments didn't make it. They are attached... Ok, now to the second chapter. These are all the changes accumulated since the patch I sent one month ago (cf previous e-mail). Changes : o more Prism2/Symbol compatibility goodies o Tested D-Link cards and Lucent firmware 7.28 o Cleanup, bug fixes from David Gibson The whole is tested, as usual... 75% of the patch was on my web pages for the last month and people seem to have liked it. I've made 2 patches, one for 2.4.4-pre6 and one for 2.4.3-ac13. The difference between the two is minor (one line). Linus : please have a look at orinoco_v4b.diff (first attachement). Of course, this patch will apply and work only if you have applied the patch in my previous e-mail. Alan : orinoco_v4b-alan.diff is for you (second attachement). Have fun... Jean - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: orinoco_cs IrDA
On Tue, Apr 24, 2001 at 06:25:50PM -0700, Jean Tourrilhes wrote: Ok, now to the second chapter. These are all the changes accumulated since the patch I sent one month ago (cf previous e-mail). Changes : o more Prism2/Symbol compatibility goodies o Tested D-Link cards and Lucent firmware 7.28 o Cleanup, bug fixes from David Gibson The whole is tested, as usual... 75% of the patch was on my web pages for the last month and people seem to have liked it. I've made 2 patches, one for 2.4.4-pre6 and one for 2.4.3-ac13. The difference between the two is minor (one line). Linus : please have a look at orinoco_v4b.diff (first attachement). Of course, this patch will apply and work only if you have applied the patch in my previous e-mail. Alan : orinoco_v4b-alan.diff is for you (second attachement). Have fun... Jean File attached this time... Jean diff -u -p linux/drivers/net/pcmcia/wireless.25b/hermes.h linux/drivers/net/pcmcia/hermes.h --- linux/drivers/net/pcmcia/wireless.25b/hermes.h Tue Apr 24 15:57:48 2001 +++ linux/drivers/net/pcmcia/hermes.h Tue Apr 24 16:04:34 2001 @@ -35,18 +35,18 @@ /* * Limits and constants */ -#defineHERMES_ALLOC_LEN_MIN((uint16_t)4) -#defineHERMES_ALLOC_LEN_MAX((uint16_t)2400) +#defineHERMES_ALLOC_LEN_MIN(4) +#defineHERMES_ALLOC_LEN_MAX(2400) #defineHERMES_LTV_LEN_MAX (34) -#defineHERMES_BAP_DATALEN_MAX ((uint16_t)4096) -#defineHERMES_BAP_OFFSET_MAX ((uint16_t)4096) -#defineHERMES_PORTID_MAX ((uint16_t)7) -#defineHERMES_NUMPORTS_MAX ((uint16_t)(HERMES_PORTID_MAX+1)) -#defineHERMES_PDR_LEN_MAX ((uint16_t)260) /* in bytes, from EK */ -#defineHERMES_PDA_RECS_MAX ((uint16_t)200) /* a guess */ -#defineHERMES_PDA_LEN_MAX ((uint16_t)1024)/* in bytes, from EK */ -#defineHERMES_SCANRESULT_MAX ((uint16_t)35) -#defineHERMES_CHINFORESULT_MAX ((uint16_t)8) +#defineHERMES_BAP_DATALEN_MAX (4096) +#defineHERMES_BAP_OFFSET_MAX (4096) +#defineHERMES_PORTID_MAX (7) +#defineHERMES_NUMPORTS_MAX (HERMES_PORTID_MAX+1) +#defineHERMES_PDR_LEN_MAX (260) /* in bytes, from EK */ +#defineHERMES_PDA_RECS_MAX (200) /* a guess */ +#defineHERMES_PDA_LEN_MAX (1024) /* in bytes, from EK */ +#defineHERMES_SCANRESULT_MAX (35) +#defineHERMES_CHINFORESULT_MAX (8) #defineHERMES_FRAME_LEN_MAX(2304) #defineHERMES_MAX_MULTICAST(16) #defineHERMES_MAGIC(0x7d1f) @@ -86,122 +86,125 @@ /* * CMD register bitmasks */ -#defineHERMES_CMD_BUSY ((uint16_t)0x8000) -#defineHERMES_CMD_AINFO((uint16_t)0x7f00) -#defineHERMES_CMD_MACPORT ((uint16_t)0x0700) -#defineHERMES_CMD_RECL ((uint16_t)0x0100) -#defineHERMES_CMD_WRITE((uint16_t)0x0100) -#defineHERMES_CMD_PROGMODE ((uint16_t)0x0300) -#defineHERMES_CMD_CMDCODE ((uint16_t)0x003f) +#defineHERMES_CMD_BUSY (0x8000) +#defineHERMES_CMD_AINFO(0x7f00) +#defineHERMES_CMD_MACPORT (0x0700) +#defineHERMES_CMD_RECL (0x0100) +#defineHERMES_CMD_WRITE(0x0100) +#defineHERMES_CMD_PROGMODE (0x0300) +#defineHERMES_CMD_CMDCODE (0x003f) /* * STATUS register bitmasks */ -#defineHERMES_STATUS_RESULT((uint16_t)0x7f00) -#defineHERMES_STATUS_CMDCODE ((uint16_t)0x003f) +#defineHERMES_STATUS_RESULT(0x7f00) +#defineHERMES_STATUS_CMDCODE (0x003f) /* * OFFSET refister bitmasks */ -#defineHERMES_OFFSET_BUSY ((uint16_t)0x8000) -#defineHERMES_OFFSET_ERR ((uint16_t)0x4000) -#defineHERMES_OFFSET_DATAOFF ((uint16_t)0x0ffe) +#defineHERMES_OFFSET_BUSY (0x8000) +#defineHERMES_OFFSET_ERR (0x4000) +#defineHERMES_OFFSET_DATAOFF (0x0ffe) /*
