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
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);
+
+#i
2.4.2-ac3 and wavelan driver
Hi Alan (and the others)
A few notes related to you *-ac* patches, the IrDA stack and
the Wavelan driver.
First, IrDA :
> --- linux.vanilla/net/irda/irlap.cThu Feb 22 09:06:21 2001
> +++ linux.ac/net/irda/irlap.c Wed Feb 21 11:55:26 2001
> @@ -51,6 +51,7 @@
> hashbin_t *irlap = NULL;
> int sysctl_slot_timeout = SLOT_TIMEOUT * 1000 / HZ;
>
> +extern void irlap_queue_xmit(struct irlap_cb *self, struct sk_buff *skb);
> static void __irlap_close(struct irlap_cb *self);
>
> static char *lap_reasons[] = {
The above patch is unnecessary. The definition of
irlap_queue_xmit() has been added in irlap_frame.h as part of
2.4.2 (I've just checked). So, you can drop this snipset.
By the way, I'm updating the IrDA patches in the pipeline (USB
driver and co) and will send that to Dag soon.
> --- linux.vanilla/net/irda/irnet/Config.inSun Nov 12 02:11:23 2000
> +++ linux.ac/net/irda/irnet/Config.in Wed Jan 31 22:02:24 2001
> @@ -1 +1,4 @@
> -dep_tristate ' IrNET protocol' CONFIG_IRNET $CONFIG_IRDA
> +if [ "$CONFIG_NETDEVICES" != "n" ]; then
> + dep_tristate ' IrNET protocol' CONFIG_IRNET $CONFIG_IRDA $CONFIG_PPP
> +fi
> +
This one is good. As you have it, we won't resend it to Linus.
By the way, thanks to whoever spent time to correct my
spelling mistakes...
> 2.4.2-ac3
> o Remove dead wavelan prototype (Jeff Garzik)
I confirm again that I'm totally opposed to this patch of the
wavelan driver you have in your tree (see below).
Replacing a perfectly valid inline function with a ugly define
it totally backward. If you look closely, the initial code was correct
and clean. I don't know anyone with taste who could advocate such a
patch without remorse.
As we discussed earlier, this patch is only necessary because
gcc 2.96 miscompile the complex definition of udelay(). If gcc 2.96
miscompile the kernel, people should fix it or use a compiler that
works properly, not uglify my driver ;-)
On the other hand, thanks infinitely to Jeff for having
updated the wavelan_cs driver (I'm still using Pcmcia outside the
kernel).
> --- linux.vanilla/drivers/net/wavelan.c Thu Feb 22 09:05:59 2001
> +++ linux.ac/drivers/net/wavelan.cFri Feb 16 21:07:55 2001
> @@ -405,16 +405,13 @@
> * Wait for the frequency EEPROM to complete a command.
> * I hope this one will be optimally inlined.
> */
> -static inline void fee_wait(unsigned long ioaddr,/* I/O port of the card */
> - int delay, /* Base delay to wait for */
> - int number)
> -{/* Number of time to wait */
> - int count = 0; /* Wait only a limited time */
> -
> - while ((count++ < number) &&
> -(mmc_in(ioaddr, mmroff(0, mmr_fee_status)) &
> - MMR_FEE_STATUS_BUSY)) udelay(delay);
> -}
> +
> +#define fee_wait(ioaddr,delay,number) do { \
> + int count = 0; /* Wait only a limited time */ \
> + while ((count++ < number) &&\
> +(mmc_in(ioaddr, mmroff(0, mmr_fee_status)) & \
> + MMR_FEE_STATUS_BUSY)) udelay(delay);\
> + } while (0)
>
That's it, have a good week end...
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: [patch] patch-2.4.2-irda1 (irda-usb)
On Tue, Feb 27, 2001 at 01:58:11PM -0800, Greg KH wrote: > On Tue, Feb 27, 2001 at 08:32:28PM +, Dag Brattli wrote: > > > I'd recommend that this file be in the /drivers/usb directory, much like > > > almost all other USB drivers are. > > > > Yes, but do we want to spread the IrDA code around? The same argument > > applies to IrDA device drivers!? > > I agree, and am not saying that it _has_ to be there. Just a > suggestion, and if you're comfortable with it in the irda directory, > that's fine. > > thanks, > > greg k-h Hi, First thanks for Dag for bringing me into the conversation. I may add my little bit of spice, especially that I was the one pushing for having the driver in .../drivers/net/irda. By the way, Greg, sorry if I hurt your feeling, I don't want to put down any of the great work that has been done on the USB stack. My feeling is that devices are mostly defined by their higher level interface, because this is what is closer to the user. If I look at a Pcmcia Ethernet card, I will tend to associate more with a PCI Ethernet card rather than a Pcmcia SCSI card. Both card have the same high level interface (TCP/IP) even if their low level interface is different (Pcmcia, PCI). People tend to agree with that, and that's why you have directories called drivers/net, drivers/scsi and driver/sound, rather that drivers/pci, drivers/isa, drivers/mca and drivers/pcmcia. If I get an IrDA-USB dongle, the feature that matter the most is that it does IrDA, the fact that it connect to my PC via USB is rather secondary. That's it. I hope it explain some of the rationale and why we departed from the usual drivers/usb arrangement. Actually, I think that stuffing all USB drivers in drivers/usb is not that great, but that's not my call... 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/
Nasty bug in the IrDA stack
Hi,
I've found a really convoluted bug in the IrDA stack (spend
the week chasing it). As it is not trivial, I would like you to check
and comment on my description and my fix.
My patch definitely fix the problem on the PC where I was
seeing it, and I can't crash it anymore (whereas it was very
reproducible before).
The crash :
---
-> irda_release(); // Close IrDA socket
<- irda_release()
-> irlap_update_nr_received(); // Receive IrLAP ack
-> kfree_skb(); // Free acked packet
-> sock_wfree();
-> sock_def_write_space(); // Increase socket write buffer
-> __wake_up(); // Wake up writer
Crash
What I believe is happening :
The socket is closing. We remove all the packet associated
with the socket instance (in IrTTP and the socket layer).
Unfortunately, there are packets in IrLAP, waiting for
retransmission, and as IrLAP doesn't know about sockets, those packets
are not freed at this point.
When IrLAP try to free those packets, they refer to a socket
that no longer exist, and we go into the cosmos.
In fact, it was worse. The packet still had a reference to the
socket when we were calling dev_queue_xmit(skb), and as the device
layer can also queue skbs, the same problem can happen (even if it
would be much more difficult to trigger).
The fix :
skb_clone() and skb_free() the packet before passing them to
the LAP layer. This way, they don't refer any socket.
Alan :
Is there in the kernel a function doing the equivalent of the
following but optimised (avoiding malloc/free of the skb structure) :
---
skb2 = skb_clone(skb1);
kfree_skb(skb1);
skb1 = skb2;
---
The point there is to remove the reference to skb->sk, so I
want something that do the opposite of skb_set_owner_w(). Something I
would call skb_set_owner_none()...
Thanks, and good week end...
Jean
P.S. : I also removed all the skb_set_owner_w() in IrLAP, they are now
totally useless.
P.S.2 : Dag : Do not put this patch yet in the kernel, we need a bit
more testing and comments...
diff -u -p linux/net/irda/irttp.j2.c linux/net/irda/irttp.c
--- linux/net/irda/irttp.j2.c Fri Mar 2 14:10:29 2001
+++ linux/net/irda/irttp.c Fri Mar 2 14:22:10 2001
@@ -404,6 +404,7 @@ int irttp_data_request(struct tsap_cb *s
static void irttp_run_tx_queue(struct tsap_cb *self)
{
struct sk_buff *skb;
+ struct sk_buff *tx_skb;
unsigned long flags;
int n;
@@ -454,7 +455,40 @@ static void irttp_run_tx_queue(struct ts
*/
skb->data[0] |= (n & 0x7f);
- irlmp_data_request(self->lsap, skb);
+ /* Detach from socket.
+* The current skb has a reference to the socket that sent
+* it (skb->sk). When we pass it to IrLMP, the skb will be
+* stored in in IrLAP (self->wx_list). When we are within
+* IrLAP, we loose the notion of socket, so we should not
+* have a reference to a socket. So, we drop it here.
+*
+* Why does it matter ?
+* When the skb is freed (kfree_skb), if it is associated
+* with a socket, it release buffer space on the socket
+* (through sock_wfree() and sock_def_write_space()).
+* If the socket no longer exist, we may crash. Hard.
+* When we close a socket, we make sure that associated packets
+* in IrTTP are freed. However, we have no way to cancel
+* the packet that we have passed to IrLAP. So, if a packet
+* remains in IrLAP (retry on the link or else) after we
+* close the socket, we are dead !
+* Jean II */
+ if (skb->sk != NULL) {
+ IRDA_DEBUG(4, __FUNCTION__ "() : Detaching SKB from
+socket.\n");
+ /* Get another skb on the same buffer, but without
+* a reference to the socket (skb->sk = NULL) */
+ tx_skb = skb_clone(skb, GFP_ATOMIC);
+ if (tx_skb != NULL) {
+ /* Release the skb associated with the
+* socket, and use the new skb insted */
+ kfree_skb(skb);
+ }
+ } else {
+ IRDA_DEBUG(3, __FUNCTION__ "() : Got SKB not attached to a
+socket.\n");
+ tx_skb = skb;
+ }
+
+ irlmp_data_request(self->lsap, tx_skb);
self->stats.tx_packets++;
/* Check if we can accept more frames from client */
diff -
Re: wavelan has fatal error with 2.4.0 (but worked in 2.4.0-test12)
On Tue, Jan 09, 2001 at 07:17:01AM -0500, John Ruttenberg wrote: > I get: > > Jan 9 07:04:51 mojo cardmgr[511]: socket 1: Digital RoamAbout/DS > Jan 9 07:04:52 mojo cardmgr[511]: executing: 'modprobe wavelan_cs' > Jan 9 07:04:52 mojo cardmgr[511]: + >/lib/modules/2.4.0-test11/pcmcia/wavelan_cs.o: unresolved symbol __bad_udelay > Jan 9 07:04:52 mojo cardmgr[511]: + >/lib/modules/2.4.0-test11/pcmcia/wavelan_cs.o: insmod >/lib/modules/2.4.0-test11/pcmcia/wavelan_cs.o failed > Jan 9 07:04:52 mojo cardmgr[511]: + >/lib/modules/2.4.0-test11/pcmcia/wavelan_cs.o: insmod wavelan_cs failed > Jan 9 07:04:52 mojo cardmgr[511]: modprobe exited with status 255 > Jan 9 07:04:52 mojo cardmgr[511]: executing: 'insmod >/lib/modules/2.4.0/pcmcia/wavelan_cs.o' > Jan 9 07:04:52 mojo cardmgr[511]: + /lib/modules/2.4.0/pcmcia/wavelan_cs.o: >unresolved symbol __bad_udelay > Jan 9 07:04:52 mojo cardmgr[511]: insmod exited with status 1 This is a bug with the definition of udelay(). Somebody tried to be too clever with udelay(), and the end result is that it breaks perfectly good and valid code. Therefore, it should be reported as such on LKML, a bug in udelay(). I think that Alan has a ugly workaround for this driver (or maybe it's only for wavelan.c) in the ac4 tree, so please check there. For my part, I insist that the code is correct, that replacing an inline function by a #define is going backwards and that udelay() should be fixed one way or another (easy, just define __bad_udelay() as returning a compilation warning or an error message). Also, please remember that the version of wavelan_cs.c in the kernel is outdated with respect to the version in the Pcmcia package. That's it... Jean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: wavelan has fatal error with 2.4.0 (but worked in 2.4.0-test12)
On Tue, Jan 09, 2001 at 05:13:42PM +, Alan Cox wrote: > > This is a bug with the definition of udelay(). Somebody tried > > to be too clever with udelay(), and the end result is that it breaks > > perfectly good and valid code. > > Therefore, it should be reported as such on LKML, a bug in udelay(). > > It is a bug in the driver. Please check again the code and point me the invalid udelay(). You will realise that there is no delay in the driver that is longer than 100ms. The bug is that udelay() can't be passed a variable but only a constant. Therefore bug in udelay(). > > there. For my part, I insist that the code is correct, that replacing > > an inline function by a #define is going backwards and that udelay() > > should be fixed one way or another (easy, just define __bad_udelay() > > as returning a compilation warning or an error message). > > You can't #define a function to a #warning or #error in C. Language limitation Yes. Tough. Jean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: wavelan has fatal error with 2.4.0 (but worked in 2.4.0-test12)
On Tue, Jan 09, 2001 at 05:48:47PM +, Alan Cox wrote: > > > It is a bug in the driver. > > > > Please check again the code and point me the invalid > > udelay(). You will realise that there is no delay in the driver that > > is longer than 100ms. > > The udelay limit is set a lot lower than 100mS. It has to be somewhat lower > otherwise you have to do two levels of loops which will throw small udelay > timings a fair whack. Sorry, I mixed up my units. All the delays are lower than 100us. > > The bug is that udelay() can't be passed a variable but only a > > constant. Therefore bug in udelay(). > > Sounds like a compiler bug. > > #define udelay(n) (__builtin_constant_p(n) ? \ > ((n) > 2 ? __bad_udelay() : __const_udelay((n) * 0x10c6ul)) : \ > __udelay(n)) > > non constants are covered. Therefore, compiler bug. Ouch ! Jean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RANT] Linux-IrDA status
On Tue, Nov 07, 2000 at 08:24:38PM -0500, Jeff Garzik wrote: > > Take a look at > http://www.uwsg.iu.edu/hypermail/linux/kernel/9908.0/0669.html This > happened with ISDN. Slightly different situation, but similar. I'm familiar with that. The *BIG* difference is that Dag has always sent his patch to Linus from the very start, when it was still small, whereas ISDN did stay on their patch from a long time. > IMHO Dag should send break up his patches into small chunks, and feed > those to Linus, with an explanation of each chunk. That's what > everybody else does... :) If you can break up stuff that has accumulated over one year, please tell me so. Most of the original patches have been lost in the mist of time. We could send it file by file, but that would give some interesting results ;-) There is also a tradeoff between having the maintainer doing the filtering to make sure that what's get checked in is safe and getting junk in the kernel. With IrDA, Dag make sure to test and integrate each patch before sending it to Linus, which of course make bigger chunks. Also, some of the contribution on the IrDA mailing list are big chunks of patches by themselves. Anyway, Linus should read the Linux-IrDA mailing list if he really want to keep up with the gory details ;-) > Jeff Ciao... Jean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: The IrDA patches !!! (+ more flames)
On Thu, Nov 09, 2000 at 07:24:04PM -0800, Jean Tourrilhes wrote: > > I spent my full day going through my archives and splitting > the big patch of Dag into lots of small patches (see attached). I'm > glad I've got a big hard drive full of junk. By the way, while I'm in flaming mode, could somebody tell ESR that this patch split (as well as most of the patches themselves) was sponsored by HP ? He should check his fact more carefully before jumping on his guns, he seem one of the few who haven't visited the Wireless LAN Howto... Now I can cool down... Jean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: The IrDA patches !!! (was Re: [RANT] Linux-IrDA status)
On Fri, Nov 10, 2000 at 11:56:57AM -0800, Linus Torvalds wrote: > > When I say multiple mails, I mean multiple mails. NOT "26 attachements in > one mail". In fact, not a single attachment at all, please. Send me > patches as a regular text body, with the explanation at the top, and the > patch just appended. No problem, they are going to come this way. Your mailbox should be full by tonight. Please remember that they are *incremental*, skipping some of them may work, skipping others may fail. I can't do much about that because this is the way things are developped (patch of a patch). > I can reply to it individually, and that patch (and nothing else) will be > automatically set up for the reply so that I can easily quote whatever > parts I want to point out. Good. I didn't know this featured existed ;-) > You are WRONG. > > 10 emails with 1000-line patches are _much_ easier to handle. I can > clearly see the parts that belong together (nothing is mixed up with other > issues), and I can keep the explanation in mind. I do not have to remind > myself what that particular piece is doing. > > It has other advantages too. With a single 1-line patch, if I don't > like something, I have a hard time just removing THAT part. So I have to > reject the whole f*cking patch, and the person who sent it to me has to > fix up the whole thing (assuming I'd bother answering to it, poitning out > the parts that I don't like from the large patch, which I will not). > > With 10 1000-line emails, I can decide to apply 8 of them outright, apply > one with comments, and discard one that does something particularly > nauseating. And I can much more easily explain to the submitter which one > I hate, without having to edit it down. Yes, you are right, and I realised it looking back to some of the patches. But this needs to be balanced against the cost of context switches, especially for IrDA code. > See? > > Linus I hope you realise that I'm only acting as a facilitator and doing the work of Dag, because I need to get IrDA in proper shape in 2.4 (because I need IrNET), and because most of the patches are mines (see comments). So yes, I did flame, but it was only to get things moving and remove the deadlock, so let's forget about the bad words... Dag will keep being the IrDA maintainer (I hope he will have learned his lesson), and I hope you will finish the whole process with Dag, because next week is a Wireless LAN week for me ;-) And I should also look at BlueTooth PAN if ever I've got time :-( For the patches : I'll send them to you personally, there is no need to abuse further the LKML (they have the attachement version). They will be formated as described above. I hope my little fingers won't do any mistakes ;-) Have fun, and thanks again for taking the time to sort out the issues ;-) Jean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: The IrDA patches !!! (was Re: [RANT] Linux-IrDA status)
On Sat, Nov 11, 2000 at 06:43:26PM -0800, Linus Torvalds wrote: > > > Ok, thanks to the work of Jean, everything seems to be applied now. > > I'll make a test3 one of these days (probably tomorrow), please verify > that everything looks happy. > > Linus Linus, Sorry to bother you again, but a important note... I sent you the whole serie of patches. Then Dag sent it to you again today. The patches were the same *except* for #14. Dag did replace the original #14 patch that you didn't like with a cleaner version (using empty packet to trigger speed changes). I'm sorry for the confusion. But don't worry, we will adjust for whatever you put in test3 and work from there, so please don't do anything ;-) And yes, I'll put it to the usual tests... And thanks again for taking the time to go through the patches so quickly. We do appreciate your great work ;-) Have fun ;-) Jean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
GlobeCom 2000 -> Networking papers
Hi, I was a GlobeCom 2 weeks ago, and I noticed a few articles relevant to Linux networking that you might be interested in reading... On ECN : -- Archan Misra, John Baras & Teunis Ott. Generalised TCP Congestion Avoidance and its Effect on Bandwidth Sharing and Variability. GlobeCom 2000 (GI2b-2). The response to an ECN by the end node should not be as drastic as to a packet loss (divide window by two) to make traffic smoother. Can't find paper on the web, but they have the full PhD Dissertation : http://www.isr.umd.edu/TechReports/CSHCN/2000/CSHCN_PhD_2000-1/CSHCN_PhD_2000-1.pdf Srisankar Kunniyur & R. Srikant. A Decentralised Adaptive ECN Marking Algorithm. How to optiomally mark packets with ECN in the routers. Good, but fail to address cohexistence problem (mix of ECN and non ECN traffic). Available at : http://www.comm.csl.uiuc.edu/~kunniyur/research.html On Header compression : - Lars-Ake Larzon, Hans Hannu, Lars-Erik Jonsson, Krister Svanbro. Efficient Transport of Voice over IP over Cellular Links. Describes ROCCO, a RTP robust header compression scheme. No paper available, but the IETF working group has more recent work : http://www.ietf.org/ids.by.wg/rohc.html My personal comment : It would be nice if someone would allow the use of those header compression schemes (ROCCO as well as regular VJ) over regular Ethernet adapters and not only within PPP. The reason is that IP over IrDA (IrLAN) and IP over BlueTooth (PAN) use Ethernet encapsulation, and don't use PPP. 802.11 and other wireless LANs use regular Ethernet frames natively. All those technologies, due to their low bandwidth, could make good use of it... Have fun... Jean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re : Configuring synchronous interfaces in Linux
Ivan Passos wrote : > For synchronous network interfaces, besides configuring network parameters > such as IP address, netmask, MTU, etc., the system should also configure > parameters specific to these sync i/f's, such as media (e.g V.35, X.21, > T1, E1), clock (internal or external, and value if int.), protocol (e.g > PPP, HDLC, Frame Relay), etc. > > What I noticed was that each synchronous board in Linux provides a > different way of doing this, and it would be good for users to have a > single, standard interface (such as ifconfig) to do this type of > configuration. Maybe even patch ifconfig itself, I don't know ... Sorry to be late to the flame war, but I'll just add my 2 cents... In 96, I was exactly in the same situation, but with Wireless LAN cards. I had 3 Wireless LAN cards, and each had a different interface to configure various parameters and report statistics. I did solve that by creating the Wireless Extensions. It has grown slowly over the years, but kept the original attributes. I'll tell you what I've learned from this experience. The most problematic part of the whole exercise is acceptance. Driver writers tend to overlook those details and do their own stuff. This may be because they can't be bothered to learn it, or because they beleive that they can do a better job, or they don't see the value in standardising these stuff. The end result is that currently there is only half of the Wireless LANs drivers supporting Wireless Extensions. Of this half, half have *minimalistic* support for it (less than 10% of the interface exposed). The other half are the driver that I've patched myself ;-) In fact, as you as noticed, many people on the list have commented that "we have this interface, XXX, but no driver use it". That's exactly what I'm talking about... If you can manage to overcome this big hurdle, tell me how you did it ;-) The second issue is to strike a balance on what to standardise and how to evolve. Other type of configuration goes into a single place (like the TCP/IP stack), so things are very easy to define and evolve. On the other hand, most of this configuration is handled in the device driver, and all those devices are different and present unique configuration options. You can't offer everyting in your interface, but you must offer enough to be able to configure it. The goal there is to find the most usefull common subset. For additional parameters too specific, let the driver use a private interface. Then, you also need flexibility, and you need to standardise the representation of values. And you need to foresee what new devices could need, to make sure that the API is stable enough... But don't overengineer, because nobody likes complex APIs. In other words, don't rush, and learn about what all those devices need. Then, the actual way of implementing it is only technical issues. I can see the following options : o module parameters : the easiest, but not dynamic and write only o /proc interface : nice looking, but heavy on driver side o sysctl : quite simple, but tricky for multiple interfaces o ioctl : most standard, but require user tools Most drivers end up having a combination of module parameters and /proc interface, the most important setting available through both. If you want, you can check what I did for Wireless Extensions. I did use ioctl because at that time sysctl didn't exist and /proc was read only. Actually, ioctl *enforce* standardisation... Check : /usr/src/linux/include/wireless.h http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html You are welcome to reuse any of the stuff already defined, but I will strongly resist any changes to Wireless Extensions unless it fits neatly in it and don't disturb any driver. In particular, have a look at the 'iwpriv' stuff. This is generic, and you could reuse it... Otherwise, have fun, be patient, and don't despair... Jean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re : [RFC-2] Configuring Synchronous Interfaces in Linux
Alan wrote : > struct wireless_physical > struct wireless_80211 > struct wireless_auth Please do not underestimate 802.11 (and others). Even two cards based on the same MAC controller can have very different way to handle bit rate setting (fixed, auto with fallback, range, ...). Check wvlan_cs.c and airo.c for details... And also remember that 802.11 is not the only Wireless LAN out there, there are more Symphony + HomeRF sold through retail than 802.11 combined. Not talking of HiperLAN 1/2... Regards, Jean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Wireless Extension update
Hi Linus and Alan, This is a totally trivial update of the Wireless Extensions definition. It just adds a few more #define, so no troubles or pain expected. The patch attached applies cleanly to *both* 2.4.0-test12 and 2.2.18 (tested), and I would suggest including it in both kernel series... Changes : o Power Management update (max, min & capa) -> Needed by the Symbol/Intel/3Com 802.11b driver o Support for read only "encoding" keys o Support for TxPower parameter -> Both needed by the Cisco/Aironet 802.11b driver By the way, don't look in the kernel for the driver mentionned above, the majority of the Wireless LAN drivers are not in the kernel (but in the Pcmcia package or elsewhere), and some in the kernel are not up to date with the version in the Pcmcia package. Thanks... Jean diff -u -p linux/include/linux/wireless.9.h linux/include/linux/wireless.h --- linux/include/linux/wireless.9.hTue Nov 14 10:55:46 2000 +++ linux/include/linux/wireless.h Tue Dec 19 14:42:02 2000 @@ -63,7 +63,7 @@ * (there is some stuff that will be added in the future...) * I just plan to increment with each new version. */ -#define WIRELESS_EXT 9 +#define WIRELESS_EXT 10 /* * Changes : @@ -104,26 +104,33 @@ * - Change encoding to support larger tokens (>64 bits) * - Updated iw_params (disable, flags) and use it for NWID * - Extracted iw_point from iwreq for clarity + * + * V9 to V10 + * - + * - Add PM capability to range structure + * - Add PM modifier : MAX/MIN/RELATIVE + * - Add encoding option : IW_ENCODE_NOKEY + * - Add TxPower ioctls (work like TxRate) */ /* -- IOCTL LIST -- */ /* Basic operations */ -#define SIOCSIWNAME0x8B00 /* Unused ??? */ -#define SIOCGIWNAME0x8B01 /* get name */ +#define SIOCSIWNAME0x8B00 /* Unused */ +#define SIOCGIWNAME0x8B01 /* get name == wireless protocol */ #define SIOCSIWNWID0x8B02 /* set network id (the cell) */ #define SIOCGIWNWID0x8B03 /* get network id */ -#define SIOCSIWFREQ0x8B04 /* set channel/frequency */ -#define SIOCGIWFREQ0x8B05 /* get channel/frequency */ +#define SIOCSIWFREQ0x8B04 /* set channel/frequency (Hz) */ +#define SIOCGIWFREQ0x8B05 /* get channel/frequency (Hz) */ #define SIOCSIWMODE0x8B06 /* set operation mode */ #define SIOCGIWMODE0x8B07 /* get operation mode */ -#define SIOCSIWSENS0x8B08 /* set sensitivity */ -#define SIOCGIWSENS0x8B09 /* get sensitivity */ +#define SIOCSIWSENS0x8B08 /* set sensitivity (dBm) */ +#define SIOCGIWSENS0x8B09 /* get sensitivity (dBm) */ /* Informative stuff */ -#define SIOCSIWRANGE 0x8B0A /* Unused ??? */ +#define SIOCSIWRANGE 0x8B0A /* Unused */ #define SIOCGIWRANGE 0x8B0B /* Get range of parameters */ -#define SIOCSIWPRIV0x8B0C /* Unused ??? */ +#define SIOCSIWPRIV0x8B0C /* Unused */ #define SIOCGIWPRIV0x8B0D /* get private ioctl interface info */ /* Mobile IP support */ @@ -153,6 +160,8 @@ #define SIOCGIWRTS 0x8B23 /* get RTS/CTS threshold (bytes) */ #define SIOCSIWFRAG0x8B24 /* set fragmentation thr (bytes) */ #define SIOCGIWFRAG0x8B25 /* get fragmentation thr (bytes) */ +#define SIOCSIWTXPOW 0x8B26 /* set transmit power (dBm) */ +#define SIOCGIWTXPOW 0x8B27 /* get transmit power (dBm) */ /* Encoding stuff (scrambling, hardware security, WEP...) */ #define SIOCSIWENCODE 0x8B2A /* set encoding token & mode */ @@ -205,6 +214,9 @@ /* Maximum bit rates in the range struct */ #define IW_MAX_BITRATES8 +/* Maximum tx powers in the range struct */ +#define IW_MAX_TXPOWER 8 + /* Maximum of address that you may set with SPY */ #define IW_MAX_SPY 8 @@ -232,11 +244,13 @@ /* Flags for encoding (along with the token) */ #define IW_ENCODE_INDEX0x00FF /* Token index (if needed) */ -#define IW_ENCODE_FLAGS0xF000 /* Flags defined below */ +#define IW_ENCODE_FLAGS0xFF00 /* Flags defined below */ +#define IW_ENCODE_MODE 0xF000 /* Modes defined below */ #define IW_ENCODE_DISABLED 0x8000 /* Encoding disabled */ #define IW_ENCODE_ENABLED 0x /* Encoding enabled */ #define IW_ENCODE_RESTRICTED 0x4000 /* Refuse non-encoded packets */ #define IW_ENCODE_OPEN 0x2000 /* Accept non-encoded packets */ +#define IW_ENCODE_NOKEY 0x0800 /* Key is write only, so not present */ /* Power management flags available (along with the value, if any) */ #define IW_POWER_ON0x
Re : 16 potential locking bugs in 2.4.1 (wavelan patch attached)
Andy Chou :
> Here are some more results from the MC project. These are 16 errors found
> in 2.4.1 related to inconsistent use of locks. As usual, if you can
> verify any of these or show that they are false positives, please let us
> know by CC'ing [EMAIL PROTECTED]
>
> -Andy Chou
>
> -
>
> [BUG] error condition
>
>/u2/acc/oses/linux/2.4.1/drivers/net/pcmcia/wavelan_cs.c:2561:wavelan_get_wireless_stats:
> ERROR:LOCK:2528:2561: Inconsistent
> lock using `spin_lock':2528
>
> static iw_stats *
> wavelan_get_wireless_stats(device * dev)
> {
> ...
> --> Lock
> spin_lock_irqsave (&lp->lock, flags);
>
> if(lp == (net_local *) NULL)
> --> Missing unlock?
> return (iw_stats *) NULL;
>
> -
Thanks for the hint (actually, also thanks to LWN for
reporting this, I don't read the list).
At first, I felt offended to have such an obvious bug in my
driver, and then I check the master copy of the driver in the Pcmcia
package that I maintain, and it doesn't contain this bug. So whoever
did the port from Pcmcia -> kernel introduced this one :-(
Patch attached. Have fun...
Jean
diff -u -p linux/drivers/net/pcmcia/wireless.24d/wavelan_cs.c
linux/drivers/net/pcmcia/wavelan_cs.c
--- linux/drivers/net/pcmcia/wireless.24d/wavelan_cs.c Thu Mar 22 15:08:46 2001
+++ linux/drivers/net/pcmcia/wavelan_cs.c Thu Mar 22 15:10:25 2001
@@ -2524,11 +2524,13 @@ wavelan_get_wireless_stats(device * dev)
printk(KERN_DEBUG "%s: ->wavelan_get_wireless_stats()\n", dev->name);
#endif
+ /* Pure paranoia */
+ if(lp == (net_local *) NULL)
+return (iw_stats *) NULL;
+
/* Disable interrupts & save flags */
spin_lock_irqsave (&lp->lock, flags);
- if(lp == (net_local *) NULL)
-return (iw_stats *) NULL;
wstats = &lp->wstats;
/* Get data from the mmc */
Re : [CHECKER] 28 potential interrupt errors
Junfeng Yang wrote :
> Hi,
>
> Here are yet more results from the MC project. This checker looks for
> inconsistent usage of interrupt functions.
[...]
> -
> [BUG] error path
>
> /u2/acc/oses/linux/2.4.1/drivers/net/irda/irport.c:943:irport_net_ioctl:
>ERROR:INTR:947:997: Interrupts inconsistent, severity `20':997
>
> /* Disable interrupts & save flags */
> save_flags(flags);
> Start --->
> cli();
>
> switch (cmd) {
> case SIOCSBANDWIDTH: /* Set bandwidth */
> if (!capable(CAP_NET_ADMIN))
> return -EPERM;
> irda_task_execute(self, __irport_change_speed, NULL, NULL,
>
> ... DELETED 40 lines ...
>
> }
>
> restore_flags(flags);
>
> Error --->
> return ret;
> }
>
> static struct net_device_stats *irport_net_get_stats(struct net_device *dev)
> {
> -
I agree that the IrDA stack is full of irq/locking bugs (there
is a patch of mine waiting in Dag's mailbox), but this one is not a
bug, it's a false positive.
The restore_flags(flags); will restore the state of the
interrupt register before the cli happened, so will automatically
reenable interrupts. The exact same code was used all over the kernel
before spinlock were introduced.
So, if you see :
save_flags(flags);
cli();
...
restore_flags(flags);
It's correct (but a bit outdated).
> -
> [BUG] error path. this bug is interesting
>
>
>/u2/acc/oses/linux/2.4.1/drivers/net/pcmcia/wavelan_cs.c:2561:wavelan_get_wireless_stats:
> ERROR:INTR:2528:2561: Interrupts inconsistent, severity `20':2561
>
>
> /* Disable interrupts & save flags */
> Start --->
> spin_lock_irqsave (&lp->lock, flags);
>
> if(lp == (net_local *) NULL)
> return (iw_stats *) NULL;
> wstats = &lp->wstats;
>
> /* Get data from the mmc */
>
> ... DELETED 23 lines ...
>
>
> #ifdef DEBUG_IOCTL_TRACE
> printk(KERN_DEBUG "%s: <-wavelan_get_wireless_stats()\n", dev->name);
> #endif
> Error --->
> return &lp->wstats;
> }
> #endif /* WIRELESS_EXT */
>
> -
Didn't look into 2.4.1, but in 2.4.2 the irq_restore is just
above the printk, in the part that is "DELETED". It even has a nice
comments to that effect. Check the code by yourself.
So, I guess it's another false positive and a bug in your
parser. That's why it's so "interesting" ;-)
Good luck...
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: Re : [CHECKER] 28 potential interrupt errors
On Thu, Mar 22, 2001 at 03:49:31PM -0800, Junfeng Yang wrote: > > Sometimes the line number reported by the checker is not correct. > But if you go into the function, you can find the bug. Gotcha. It in fact indicate the error at the end of the function instead of the place where the error is. Very confusing. So, mea culpa, I was wrong... 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/
Wireless Extension update...
Hi, Now that I got away from IrDA, I've been taking care of my todo list on the Wireless side. The most critical feature is versionning. Since distributions started shipping separate kernel header in /usr/include/linux, drivers and tools can be out of sync (== core dump when reading iwrange). A lot of user have been caught by that moving from 2.2.X to 2.4.X. This patch provide a way to detect that and to fix the problem. Also, I added a new extension (retry), and implemented it in the orinoco_cs driver. However, it is not enabled in orinoco_cs (has_retry=0) because we are in stable kernels ;-) Would you mind adding that in the kernel ? Thanks... Jean P.S. : A new version of Wireless Tools with all those goodies will be soon on my web page... diff -u -p linux/include/linux/wireless.25.h linux/include/linux/wireless.h --- linux/include/linux/wireless.25.h Wed Mar 28 10:33:47 2001 +++ linux/include/linux/wireless.h Wed Mar 28 17:31:42 2001 @@ -1,7 +1,7 @@ /* * This file define a set of standard wireless extensions * - * Version : 9 16.10.99 + * Version : 11 28.3.01 * * Authors : Jean Tourrilhes - HPL - <[EMAIL PROTECTED]> */ @@ -63,7 +63,7 @@ * (there is some stuff that will be added in the future...) * I just plan to increment with each new version. */ -#define WIRELESS_EXT 10 +#define WIRELESS_EXT 11 /* * Changes : @@ -111,6 +111,11 @@ * - Add PM modifier : MAX/MIN/RELATIVE * - Add encoding option : IW_ENCODE_NOKEY * - Add TxPower ioctls (work like TxRate) + * + * V10 to V11 + * -- + * - Add WE version in range (help backward/forward compatibility) + * - Add retry ioctls (work like PM) */ /* -- IOCTL LIST -- */ @@ -162,6 +167,8 @@ #define SIOCGIWFRAG0x8B25 /* get fragmentation thr (bytes) */ #define SIOCSIWTXPOW 0x8B26 /* set transmit power (dBm) */ #define SIOCGIWTXPOW 0x8B27 /* get transmit power (dBm) */ +#define SIOCSIWRETRY 0x8B28 /* set retry limits and lifetime */ +#define SIOCGIWRETRY 0x8B29 /* get retry limits and lifetime */ /* Encoding stuff (scrambling, hardware security, WEP...) */ #define SIOCSIWENCODE 0x8B2A /* set encoding token & mode */ @@ -272,6 +279,16 @@ #define IW_TXPOW_DBM 0x /* Value is in dBm */ #define IW_TXPOW_MWATT 0x0001 /* Value is in mW */ +/* Retry limits and lifetime flags available */ +#define IW_RETRY_ON0x /* No details... */ +#define IW_RETRY_TYPE 0xF000 /* Type of parameter */ +#define IW_RETRY_LIMIT 0x1000 /* Maximum number of retries*/ +#define IW_RETRY_LIFETIME 0x2000 /* Maximum duration of retries in us */ +#define IW_RETRY_MODIFIER 0x000F /* Modify a parameter */ +#define IW_RETRY_MIN 0x0001 /* Value is a minimum */ +#define IW_RETRY_MAX 0x0002 /* Value is a maximum */ +#define IW_RETRY_RELATIVE 0x0004 /* Value is not in seconds/ms/us */ + /** TYPES **/ /* --- SUBTYPES --- */ @@ -385,6 +402,7 @@ struct iwreq struct iw_param rts;/* RTS threshold threshold */ struct iw_param frag; /* Fragmentation threshold */ __u32 mode; /* Operation mode */ + struct iw_param retry; /* Retry limits & lifetime */ struct iw_point encoding; /* Encoding stuff : tokens */ struct iw_param power; /* PM duration/timeout */ @@ -462,6 +480,19 @@ struct iw_range __u16 txpower_capa; /* What options are supported */ __u8num_txpower;/* Number of entries in the list */ __s32 txpower[IW_MAX_TXPOWER];/* list, in bps */ + + /* Wireless Extension version info */ + __u8we_version_compiled;/* Must be WIRELESS_EXT */ + __u8we_version_source; /* Last update of source */ + + /* Retry limits and lifetime */ + __u16 retry_capa; /* What retry options are supported */ + __u16 retry_flags;/* How to decode max/min retry limit */ + __u16 r_time_flags; /* How to decode max/min retry life */ + __s32 min_retry; /* Minimal number of retries */ + __s32 max_retry; /* Maximal number of retries */ + __s32 min_r_time; /* Minimal retry lifetime */ + __s32 max_r_time; /* Maximal retry lifetime */ }; /* 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 M
Re: [IrDA] Oops with NULL deref in irda_device_set_media_busy
On Tue, Apr 05, 2005 at 11:02:26AM +0200, Michal Rokos wrote: > Hello, > > I've problems with IrDA - when debug is off, I'm getting oops for obvious > reason... > (I don't have a log, this is just rewrite from screen: > EIP: irda_device_set_media_busy+0x15/0x40 [irda] > ali_ircc_sir_receive+0x4a/0x70 > ali_ircc_sir_interrupt+0x66/0x70 > ali_ircc_interrupt+0x5e/0x80 > . > ) > When I turn debug on, I get just > Assertion failed! net/irda/irda_device.c:irda_device_set_media_busy:128 > self != NULL > > The obvious reason is that I don't have irlap module in that inits > dev->atalk_ptr, so I'm getting assertion exception in irda_device.c:489. I'm unclear here. The default IrDA stack intitialise properly dev->atalk_ptr in every case, and is not expected to work if you don't. I don't understand why dev->atalk_ptr would not be initialised, is it something you did or something specific to the mr kernel (I only test mainline kernels). > A few info that could be handy: > > $ uname -a # It's yesterday bk snapshot > Linux csas 2.6.12-rc1-mr #14 Mon Apr 4 13:42:14 CEST 2005 i686 GNU/Linux 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: [IrDA] Oops with NULL deref in irda_device_set_media_busy
On Wed, Apr 06, 2005 at 09:22:48AM +0200, Michal Rokos wrote:
> Hello again,
>
> I'm gonna provide more info this time...
>
> > > When I turn debug on, I get just
> > > Assertion failed! net/irda/irda_device.c:irda_device_set_media_busy:128
> > > self != NULL
> > >
> > > The obvious reason is that I don't have irlap module in that inits
> > > dev->atalk_ptr, so I'm getting assertion exception in irda_device.c:489.
>
> The assertion is seen when ifup -a is called so it's when 'ifconfig irda0 up'
> is used.
That was the crucial bit that was missing. Now I get it. A
good night of sleep also did help.
Patch attached.
Jean
-
diff -u -p linux/net/irda/irda_device.d2.c linux/net/irda/irda_device.c
--- linux/net/irda/irda_device.d2.c Wed Apr 6 09:40:09 2005
+++ linux/net/irda/irda_device.cWed Apr 6 09:45:22 2005
@@ -125,8 +125,15 @@ void irda_device_set_media_busy(struct n
self = (struct irlap_cb *) dev->atalk_ptr;
- IRDA_ASSERT(self != NULL, return;);
- IRDA_ASSERT(self->magic == LAP_MAGIC, return;);
+ /* Some drivers may enable the receive interrupt before calling
+* irlap_open(), or they may disable the receive interrupt
+* after calling irlap_close().
+* The IrDA stack is protected from this in irlap_driver_rcv().
+* However, the driver calls directly the wrapper, that calls
+* us directly. Make sure we protect ourselves.
+* Jean II */
+ if (!self || self->magic != LAP_MAGIC)
+ return;
if (status) {
self->media_busy = TRUE;
-
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: [IrDA] Oops with NULL deref in irda_device_set_media_busy
On Thu, Apr 07, 2005 at 08:22:52AM +0200, Michal Rokos wrote: > Hello, > > On Wednesday 06 April 2005 18:49, Jean Tourrilhes wrote: > > Patch attached. > > and is working fine - of course. > > Thank you for patience. :) > > Michal No, thank you for pushing me harder ;-) Note that the comments is in my mind more important than the patch, next time someone hack in there, he will need to be aware of that. I've also decided that it was harder to enforce an ordering on the driver... 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: [PATCH] net #9
On Tue, May 29, 2001 at 09:13:34PM -0400, Jeff Garzik wrote: > > This is standard kernel cleanup that makes the resulting image smaller. > These patches have been going into all areas of the kernel for quite > some time. This doesn't make it right. Ok, while we are on the topic : could somebody explain me why we can't get gcc to do that for us ? What is preventing adding a gcc command line flag to do exactly that ? It's not like rocket science (simple test) and would avoid to have tediously to go through all source code, past, present and *future* to make those changes. Bah, maybe it's too straightforward... 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: [PATCH] net #9
On Tue, May 29, 2001 at 10:13:02PM -0400, Jeff Garzik wrote: > *shrug* Well, if you want to go against the kernel standard that's fine > with me. I won't put Andrzej's changes to your drivers upstream. You > are going to continually see patches to clean that up, though, because > it makes the end user's kernel smaller. Please consider noting this > special case in a comment in each of your drivers "do not clean up > static initializers" or similar. > > It's really a pain in the ass to remember special cases like this, so > please reconsider. Being not-like-the-others is detrimental to the long > term maintainability of the overall kernel. > > Regards, > > Jeff I agree with you on the special case. I don't like it either. Anyway, most patch to my drivers are applied wether I like it or not, so I guess that I should be happy that I was notified and I should sut up my big mouth because it won't make a difference. If I reject the patch now, I will be applied behind my back. Been there, done that. In other words : yes, please apply the patch. 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: [PATCH] net #9
On Tue, May 29, 2001 at 09:47:19PM -0400, Jeff Garzik wrote: > > This is ANSI C standard stuff. If a static object with a scalar type is > not explicitly initialized, it is initialized to zero by default. > > Sure we can get gcc to recognize that case, but why use gcc to work > around code that avoids an ANSI feature? Apart from this stupid flame that I'm making, I've got my Intel/Symbol card to work properly with the Orinoco driver. This mean that we are not far away to have the 4 main flavor of 802.11b working in 2.4.X (i.e. Lucent/Symbol/PrismII/Aironet). See : http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Orinoco.html#patches Just to make sure we end on a positive note ;-) Now, if I could get the card of Alan to work... Have fun, don't take it seriously... 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: net-irda-possible-cleanups.patch added to -mm tree
On Tue, Aug 16, 2005 at 08:46:34PM -0700, David S. Miller wrote: > > I've put this into the net-2.6.14 tree. Great. Thanks ! 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/
[PATCH 2.6.11] WE-18 (aka WPA)
Hi Jeff, This is version 18 of the Wireless Extensions. The main change is that it adds all the necessary APIs for WPA and WPA2 support. This work was entirely done by Jouni Malinen, so let's thank him for both his hard work and deep expertise on the subject ;-) This APIs obviously doesn't do much by itself and works in concert with driver support (Jouni already sent you the HostAP changes) and userspace (Jouni is updating wpa_supplicant). This is also orthogonal with the ongoing work on in-kernel IEEE support (but potentially useful). The patch is attached, tested with 2.6.11. Normally, I would ask you to push that directly in the kernel (99% of the patch has been on my web page for ages and it does not affect non-WPA stuff), but Jouni convinced me that it should bake a few weeks in wireless-2.6 first, so that other driver maintainers can get up to speed with it. So, would you mind pushing that in wireless-2.6 ? Thanks in advance... Jean diff -upr linux-2.6.11/include/linux/wireless.h linux-2.6.11-WE18/include/linux/wireless.h --- linux-2.6.11/include/linux/wireless.h 2004-12-24 13:35:01.0 -0800 +++ linux-2.6.11-WE18/include/linux/wireless.h 2005-03-12 09:53:02.0 -0800 @@ -1,10 +1,10 @@ /* * This file define a set of standard wireless extensions * - * Version : 17 21.6.04 + * Version : 18 12.3.05 * * Authors : Jean Tourrilhes - HPL - <[EMAIL PROTECTED]> - * Copyright (c) 1997-2004 Jean Tourrilhes, All Rights Reserved. + * Copyright (c) 1997-2005 Jean Tourrilhes, All Rights Reserved. */ #ifndef _LINUX_WIRELESS_H @@ -82,7 +82,7 @@ * (there is some stuff that will be added in the future...) * I just plan to increment with each new version. */ -#define WIRELESS_EXT 17 +#define WIRELESS_EXT 18 /* * Changes : @@ -182,6 +182,21 @@ * - Document (struct iw_quality *)->updated, add new flags (INVALID) * - Wireless Event capability in struct iw_range * - Add support for relative TxPower (yick !) + * + * V17 to V18 (From Jouni Malinen <[EMAIL PROTECTED]>) + * -- + * - Add support for WPA/WPA2 + * - Add extended encoding configuration (SIOCSIWENCODEEXT and + * SIOCGIWENCODEEXT) + * - Add SIOCSIWGENIE/SIOCGIWGENIE + * - Add SIOCSIWMLME + * - Add SIOCSIWPMKSA + * - Add struct iw_range bit field for supported encoding capabilities + * - Add optional scan request parameters for SIOCSIWSCAN + * - Add SIOCSIWAUTH/SIOCGIWAUTH for setting authentication and WPA + * related parameters (extensible up to 4096 parameter values) + * - Add wireless events: IWEVGENIE, IWEVMICHAELMICFAILURE, + * IWEVASSOCREQIE, IWEVASSOCRESPIE, IWEVPMKIDCAND */ / CONSTANTS / @@ -256,6 +271,30 @@ #define SIOCSIWPOWER 0x8B2C /* set Power Management settings */ #define SIOCGIWPOWER 0x8B2D /* get Power Management settings */ +/* WPA : Generic IEEE 802.11 informatiom element (e.g., for WPA/RSN/WMM). + * This ioctl uses struct iw_point and data buffer that includes IE id and len + * fields. More than one IE may be included in the request. Setting the generic + * IE to empty buffer (len=0) removes the generic IE from the driver. Drivers + * are allowed to generate their own WPA/RSN IEs, but in these cases, drivers + * are required to report the used IE as a wireless event, e.g., when + * associating with an AP. */ +#define SIOCSIWGENIE 0x8B30 /* set generic IE */ +#define SIOCGIWGENIE 0x8B31 /* get generic IE */ + +/* WPA : IEEE 802.11 MLME requests */ +#define SIOCSIWMLME0x8B16 /* request MLME operation; uses +* struct iw_mlme */ +/* WPA : Authentication mode parameters */ +#define SIOCSIWAUTH0x8B32 /* set authentication mode params */ +#define SIOCGIWAUTH0x8B33 /* get authentication mode params */ + +/* WPA : Extended version of encoding configuration */ +#define SIOCSIWENCODEEXT 0x8B34/* set encoding token & mode */ +#define SIOCGIWENCODEEXT 0x8B35/* get encoding token & mode */ + +/* WPA2 : PMKSA cache management */ +#define SIOCSIWPMKSA 0x8B36 /* PMKSA cache operation */ + /* DEV PRIVATE IOCTL LIST */ /* These 32 ioctl are wireless device private, for 16 commands. @@ -297,6 +336,34 @@ #define IWEVCUSTOM 0x8C02 /* Driver specific ascii string */ #define IWEVREGISTERED 0x8C03 /* Discovered a new node (AP mode) */ #define IWEVEXPIRED0x8C04 /* Expired a node (AP mode) */ +#define IWEVGENIE 0x8C05 /* Generic IE (WPA, RSN, WMM, ..) +* (scan results); This includes id and +*
[PATCH 2.4] SIOCSIFNAME wildcard support
Hi Marcelo,
This patch adds wildcard support for the SIOCSIFNAME ioctl,
like what was done in 2.6.1. SIOCSIFNAME allow a user space tool to
change network interface names (such as nameif, ifrename, or ip link),
this patch allow those tools to specify a pattern, such as "eth%d" or
"wlan%d", and the kernel use the lowest available slot.
The reason I'm sending you this patch is that I've got some
2.4.X users who requested the feature...
This patch was initially done for 2.4.23, and I rediffed and
retested with 2.4.29. It's somewhat different from the patch Stephen
and me added to 2.6.1, because the netdev init code is different and
also this patch is more conservative.
Have fun...
Jean
-
diff -u -p linux/net/core/dev.j1.c linux/net/core/dev.c
--- linux/net/core/dev.j1.c Wed Dec 3 14:29:21 2003
+++ linux/net/core/dev.cWed Dec 3 18:55:27 2003
@@ -2179,10 +2179,26 @@ static int dev_ifsioc(struct ifreq *ifr,
case SIOCSIFNAME:
if (dev->flags&IFF_UP)
return -EBUSY;
- if (__dev_get_by_name(ifr->ifr_newname))
- return -EEXIST;
- memcpy(dev->name, ifr->ifr_newname, IFNAMSIZ);
- dev->name[IFNAMSIZ-1] = 0;
+ /* Check if name contains a wildcard */
+ if (strchr(ifr->ifr_newname, '%')) {
+ char format[IFNAMSIZ + 1];
+ int ret;
+ memcpy(format, ifr->ifr_newname, IFNAMSIZ);
+ format[IFNAMSIZ-1] = 0;
+ /* Find a free name based on format.
+* dev_alloc_name() replaces "%d" with at max
+* 2 digits, so no name overflow. - Jean II */
+ ret = dev_alloc_name(dev, format);
+ if (ret < 0)
+ return ret;
+ /* Copy the new name back to caller. */
+ strncpy(ifr->ifr_newname, dev->name, IFNAMSIZ);
+ } else {
+ if (__dev_get_by_name(ifr->ifr_newname))
+ return -EEXIST;
+ memcpy(dev->name, ifr->ifr_newname, IFNAMSIZ);
+ dev->name[IFNAMSIZ-1] = 0;
+ }
notifier_call_chain(&netdev_chain, NETDEV_CHANGENAME,
dev);
return 0;
@@ -2315,6 +2331,7 @@ int dev_ioctl(unsigned int cmd, void *ar
* - return a value
*/
+ case SIOCSIFNAME:
case SIOCGMIIPHY:
case SIOCGMIIREG:
if (!capable(CAP_NET_ADMIN))
@@ -2350,7 +2367,6 @@ int dev_ioctl(unsigned int cmd, void *ar
case SIOCDELMULTI:
case SIOCSIFHWBROADCAST:
case SIOCSIFTXQLEN:
- case SIOCSIFNAME:
case SIOCSMIIREG:
case SIOCBONDENSLAVE:
case SIOCBONDRELEASE:
-
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/
[PATCH 2.4] Wireless Extension v17
Hi Marcelo, This patch adds Wireless Extensions v17 to kernel 2.4.X. This patch is the same as what went into 2.6.10-rc1, except for the minor differences between 2.4.X and 2.6.X. This was tested on 2.4.29. The main reason of this patch is wireless driver outside the kernel tree. Some of them already support WE-17 (HostAP, Prism54), so having this patch in 2.4.X will allow then simplify their code. The changelog : * - Add flags to frequency -> auto/fixed * - Document (struct iw_quality *)->updated, add new flags (INVALID) * - Wireless Event capability in struct iw_range * - Add support for relative TxPower (yick !) * - Change the way we get to spy_data method for added safety and hostap * - Remove spy #ifdef, they are always on -> cleaner code * - Allow any size GET request if user specifies length > max * - Start migrating get_wireless_stats to struct iw_handler_def * Based on patch from Pavel Roskin <[EMAIL PROTECTED]> : * - Fix kernel data leak to user space in private handler handling Have fun... Jean diff -u -p linux/include/linux/netdevice.we16.h linux/include/linux/netdevice.h --- linux/include/linux/netdevice.we16.h2005-02-03 14:54:56.0 -0800 +++ linux/include/linux/netdevice.h 2005-02-03 15:43:30.0 -0800 @@ -295,7 +295,9 @@ struct net_device /* List of functions to handle Wireless Extensions (instead of ioctl). * See for details. Jean II */ - struct iw_handler_def * wireless_handlers; + const struct iw_handler_def * wireless_handlers; + /* Instance data managed by the core of Wireless Extensions. */ + struct iw_public_data * wireless_data; struct ethtool_ops *ethtool_ops; diff -u -p linux/include/linux/wireless.we16.h linux/include/linux/wireless.h --- linux/include/linux/wireless.we16.h 2005-02-03 14:55:04.0 -0800 +++ linux/include/linux/wireless.h 2005-02-03 15:44:48.0 -0800 @@ -1,10 +1,10 @@ /* * This file define a set of standard wireless extensions * - * Version : 16 2.4.03 + * Version : 17 21.6.04 * * Authors : Jean Tourrilhes - HPL - <[EMAIL PROTECTED]> - * Copyright (c) 1997-2002 Jean Tourrilhes, All Rights Reserved. + * Copyright (c) 1997-2004 Jean Tourrilhes, All Rights Reserved. */ #ifndef _LINUX_WIRELESS_H @@ -47,12 +47,12 @@ * # include/net/iw_handler.h * * Note as well that /proc/net/wireless implementation has now moved in : - * # include/linux/wireless.c + * # net/core/wireless.c * * Wireless Events (2002 -> onward) : * * Events are defined at the end of this file, and implemented in : - * # include/linux/wireless.c + * # net/core/wireless.c * * Other comments : * -- @@ -82,7 +82,7 @@ * (there is some stuff that will be added in the future...) * I just plan to increment with each new version. */ -#define WIRELESS_EXT 16 +#define WIRELESS_EXT 17 /* * Changes : @@ -175,6 +175,13 @@ * - Remove IW_MAX_GET_SPY because conflict with enhanced spy support * - Add SIOCSIWTHRSPY/SIOCGIWTHRSPY and "struct iw_thrspy" * - Add IW_ENCODE_TEMP and iw_range->encoding_login_index + * + * V16 to V17 + * -- + * - Add flags to frequency -> auto/fixed + * - Document (struct iw_quality *)->updated, add new flags (INVALID) + * - Wireless Event capability in struct iw_range + * - Add support for relative TxPower (yick !) */ / CONSTANTS / @@ -251,7 +258,7 @@ /* DEV PRIVATE IOCTL LIST */ -/* These 16 ioctl are wireless device private. +/* These 32 ioctl are wireless device private, for 16 commands. * Each driver is free to use them for whatever purpose it chooses, * however the driver *must* export the description of those ioctls * with SIOCGIWPRIV and *must* use arguments as defined below. @@ -266,8 +273,8 @@ * We now have 32 commands, so a bit more space ;-). * Also, all 'odd' commands are only usable by root and don't return the * content of ifr/iwr to user (but you are not obliged to use the set/get - * convention, just use every other two command). - * And I repeat : you are not obliged to use them with iwspy, but you + * convention, just use every other two command). More details in iwpriv.c. + * And I repeat : you are not forced to use them with iwpriv, but you * must be compliant with it. */ @@ -352,6 +359,18 @@ #define IW_MODE_SECOND 5 /* Secondary master/repeater (backup) */ #define IW_MODE_MONITOR6 /* Passive monitor (listen only) */ +/* Statistics flags (bitmask in updated) */ +#define IW_QUAL_QUAL_UPDATED 0x1 /* Value was updated si
[PATCH 2.4] SIOCSIFNAME wildcard support (resend)
Hi Marcelo,
I did not receive any feedback on this e-mail, so I assume it
was lost on the way. Would you mind pushing that in 2.4.x ?
Thanks...
Jean
- Forwarded message from jt -
Subject: [PATCH 2.4] SIOCSIFNAME wildcard support
E-mail: [EMAIL PROTECTED]
Hi Marcelo,
This patch adds wildcard support for the SIOCSIFNAME ioctl,
like what was done in 2.6.1. SIOCSIFNAME allow a user space tool to
change network interface names (such as nameif, ifrename, or ip link),
this patch allow those tools to specify a pattern, such as "eth%d" or
"wlan%d", and the kernel use the lowest available slot.
The reason I'm sending you this patch is that I've got some
2.4.X users who requested the feature...
This patch was initially done for 2.4.23, and I rediffed and
retested with 2.4.29. It's somewhat different from the patch Stephen
and me added to 2.6.1, because the netdev init code is different and
also this patch is more conservative.
Have fun...
Jean
-
diff -u -p linux/net/core/dev.j1.c linux/net/core/dev.c
--- linux/net/core/dev.j1.c Wed Dec 3 14:29:21 2003
+++ linux/net/core/dev.cWed Dec 3 18:55:27 2003
@@ -2179,10 +2179,26 @@ static int dev_ifsioc(struct ifreq *ifr,
case SIOCSIFNAME:
if (dev->flags&IFF_UP)
return -EBUSY;
- if (__dev_get_by_name(ifr->ifr_newname))
- return -EEXIST;
- memcpy(dev->name, ifr->ifr_newname, IFNAMSIZ);
- dev->name[IFNAMSIZ-1] = 0;
+ /* Check if name contains a wildcard */
+ if (strchr(ifr->ifr_newname, '%')) {
+ char format[IFNAMSIZ + 1];
+ int ret;
+ memcpy(format, ifr->ifr_newname, IFNAMSIZ);
+ format[IFNAMSIZ-1] = 0;
+ /* Find a free name based on format.
+* dev_alloc_name() replaces "%d" with at max
+* 2 digits, so no name overflow. - Jean II */
+ ret = dev_alloc_name(dev, format);
+ if (ret < 0)
+ return ret;
+ /* Copy the new name back to caller. */
+ strncpy(ifr->ifr_newname, dev->name, IFNAMSIZ);
+ } else {
+ if (__dev_get_by_name(ifr->ifr_newname))
+ return -EEXIST;
+ memcpy(dev->name, ifr->ifr_newname, IFNAMSIZ);
+ dev->name[IFNAMSIZ-1] = 0;
+ }
notifier_call_chain(&netdev_chain, NETDEV_CHANGENAME,
dev);
return 0;
@@ -2315,6 +2331,7 @@ int dev_ioctl(unsigned int cmd, void *ar
* - return a value
*/
+ case SIOCSIFNAME:
case SIOCGMIIPHY:
case SIOCGMIIREG:
if (!capable(CAP_NET_ADMIN))
@@ -2350,7 +2367,6 @@ int dev_ioctl(unsigned int cmd, void *ar
case SIOCDELMULTI:
case SIOCSIFHWBROADCAST:
case SIOCSIFTXQLEN:
- case SIOCSIFNAME:
case SIOCSMIIREG:
case SIOCBONDENSLAVE:
case SIOCBONDRELEASE:
-
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/
[PATCH 2.4] Wireless Extension v17 (resend)
Hi Marcelo, I did not receive any feedback on this e-mail either, so I assume it was also lost on the way. Would you mind pushing that in 2.4.x ? Thanks... Jean - Forwarded message from jt - Subject: [PATCH 2.4] Wireless Extension v17 E-mail: [EMAIL PROTECTED] Hi Marcelo, This patch adds Wireless Extensions v17 to kernel 2.4.X. This patch is the same as what went into 2.6.10-rc1, except for the minor differences between 2.4.X and 2.6.X. This was tested on 2.4.29. The main reason of this patch is wireless driver outside the kernel tree. Some of them already support WE-17 (HostAP, Prism54), so having this patch in 2.4.X will allow then simplify their code. The changelog : * - Add flags to frequency -> auto/fixed * - Document (struct iw_quality *)->updated, add new flags (INVALID) * - Wireless Event capability in struct iw_range * - Add support for relative TxPower (yick !) * - Change the way we get to spy_data method for added safety and hostap * - Remove spy #ifdef, they are always on -> cleaner code * - Allow any size GET request if user specifies length > max * - Start migrating get_wireless_stats to struct iw_handler_def * Based on patch from Pavel Roskin <[EMAIL PROTECTED]> : * - Fix kernel data leak to user space in private handler handling Have fun... Jean diff -u -p linux/include/linux/netdevice.we16.h linux/include/linux/netdevice.h --- linux/include/linux/netdevice.we16.h2005-02-03 14:54:56.0 -0800 +++ linux/include/linux/netdevice.h 2005-02-03 15:43:30.0 -0800 @@ -295,7 +295,9 @@ struct net_device /* List of functions to handle Wireless Extensions (instead of ioctl). * See for details. Jean II */ - struct iw_handler_def * wireless_handlers; + const struct iw_handler_def * wireless_handlers; + /* Instance data managed by the core of Wireless Extensions. */ + struct iw_public_data * wireless_data; struct ethtool_ops *ethtool_ops; diff -u -p linux/include/linux/wireless.we16.h linux/include/linux/wireless.h --- linux/include/linux/wireless.we16.h 2005-02-03 14:55:04.0 -0800 +++ linux/include/linux/wireless.h 2005-02-03 15:44:48.0 -0800 @@ -1,10 +1,10 @@ /* * This file define a set of standard wireless extensions * - * Version : 16 2.4.03 + * Version : 17 21.6.04 * * Authors : Jean Tourrilhes - HPL - <[EMAIL PROTECTED]> - * Copyright (c) 1997-2002 Jean Tourrilhes, All Rights Reserved. + * Copyright (c) 1997-2004 Jean Tourrilhes, All Rights Reserved. */ #ifndef _LINUX_WIRELESS_H @@ -47,12 +47,12 @@ * # include/net/iw_handler.h * * Note as well that /proc/net/wireless implementation has now moved in : - * # include/linux/wireless.c + * # net/core/wireless.c * * Wireless Events (2002 -> onward) : * * Events are defined at the end of this file, and implemented in : - * # include/linux/wireless.c + * # net/core/wireless.c * * Other comments : * -- @@ -82,7 +82,7 @@ * (there is some stuff that will be added in the future...) * I just plan to increment with each new version. */ -#define WIRELESS_EXT 16 +#define WIRELESS_EXT 17 /* * Changes : @@ -175,6 +175,13 @@ * - Remove IW_MAX_GET_SPY because conflict with enhanced spy support * - Add SIOCSIWTHRSPY/SIOCGIWTHRSPY and "struct iw_thrspy" * - Add IW_ENCODE_TEMP and iw_range->encoding_login_index + * + * V16 to V17 + * -- + * - Add flags to frequency -> auto/fixed + * - Document (struct iw_quality *)->updated, add new flags (INVALID) + * - Wireless Event capability in struct iw_range + * - Add support for relative TxPower (yick !) */ / CONSTANTS / @@ -251,7 +258,7 @@ /* DEV PRIVATE IOCTL LIST */ -/* These 16 ioctl are wireless device private. +/* These 32 ioctl are wireless device private, for 16 commands. * Each driver is free to use them for whatever purpose it chooses, * however the driver *must* export the description of those ioctls * with SIOCGIWPRIV and *must* use arguments as defined below. @@ -266,8 +273,8 @@ * We now have 32 commands, so a bit more space ;-). * Also, all 'odd' commands are only usable by root and don't return the * content of ifr/iwr to user (but you are not obliged to use the set/get - * convention, just use every other two command). - * And I repeat : you are not obliged to use them with iwspy, but you + * convention, just use every other two command). More details in iwpriv.c. + * And I repeat : you are not forced to use them with iwpriv, but you * mu
Re: [PATCH 2.4] Wireless Extension v17 (resend)
On Tue, Feb 08, 2005 at 04:01:16PM -0200, Marcelo Tosatti wrote: > > Hi Jean, > > I'm very ignorant about wireless but it doesnt appear to me that "Wireless > Extension v17" > is a critical feature. You are right, it's not critical, and I was already thinking of not pushing WE-18 to you (the WPA update). I'll stop updating 2.4.X with respect to wireless, the patches will be available on my web page for people who needs it. We may revisit this if there is a public outcry... > It seems more appropriate to declare it as 2.6 functionality ? There need to be some unique features in 2.6.X to force people to upgrade, I guess... > Cheers Thanks. 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: [PATCH 2.4] SIOCSIFNAME wildcard support (resend)
On Tue, Feb 08, 2005 at 02:24:22PM -0800, David S. Miller wrote: > On Tue, 8 Feb 2005 16:04:45 -0200 > Marcelo Tosatti <[EMAIL PROTECTED]> wrote: > > > On Tue, Feb 08, 2005 at 10:14:36AM -0800, Jean Tourrilhes wrote: > > > Hi Marcelo, > > > > > > I did not receive any feedback on this e-mail, so I assume it > > > was lost on the way. Would you mind pushing that in 2.4.x ? > > > Thanks... > > > > As an ignorant person I have no problems with it. > > > > David, what is your opinion? > > If networking patches are sent purely to linux-kernel, they will often > be missed. Please use netdev@oss.sgi.com, Jean of all people should be > more than aware of netdev@oss.sgi.com as the place to post and discuss > networking patches, not linux-kernel and not privately to Marcelo or > myself. > > I only happened to spot this post by accident this time, I'm being > asked a question and I'm not even CC:'d on the email. :-) It was sent to netdev : http://marc.theaimsgroup.com/?l=linux-netdev&m=110747857226852&w=2 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: [PATCH 2.4] Wireless Extension v17 (resend)
On Tue, Feb 08, 2005 at 04:41:46PM -0200, Marcelo Tosatti wrote: > On Tue, Feb 08, 2005 at 01:51:12PM -0800, Jean Tourrilhes wrote: > > > > You are right, it's not critical, and I was already thinking > > of not pushing WE-18 to you (the WPA update). I'll stop updating 2.4.X > > with respect to wireless, the patches will be available on my web page > > for people who needs it. > > Please dont miss bugfixes for present functionality. Gracias. Depend what you call "bugfix". Fortunately, with the long beta period I do with the WE, bugs are few. There are only two "bugs" in WE-16 I'm aware off (fixed in WE-17), but I don't think they are worth fixing. The first is the handling of spyoffset which is potentially unsafe. Unfortunately, the fix involve some API/infrastructure change, so is not transparent. Fortunately drivers are clever enough to not trigger this bug. The second is a potential leak of kernel data to user space in private handler handling. Few drivers use that feature, there is no risk of crash or direct attack, so I would not worry about it. > Faster, cleaner, way more elegant, handles intense loads more gracefully, > handles highmem decently, LSM/SELinux, etc, etc... > > IMO everyone should upgrade whenever appropriate. If people want to use 2.4.X, I won't prevent them... 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: [PATCH 2.4] Wireless Extension v17 (resend)
On Tue, Feb 08, 2005 at 05:51:29PM -0800, Chris Wright wrote:
> * Jean Tourrilhes ([EMAIL PROTECTED]) wrote:
> > The first is the handling of spyoffset which is potentially
> > unsafe. Unfortunately, the fix involve some API/infrastructure change,
> > so is not transparent. Fortunately drivers are clever enough to not
> > trigger this bug.
> > The second is a potential leak of kernel data to user space in
> > private handler handling. Few drivers use that feature, there is no
> > risk of crash or direct attack, so I would not worry about it.
>
> Hmm, having ability to read kernel data is not so nice.
It's not like you can read any arbitrary address, exploiting
such a flaw is in my mind theoritical. Let's not overblow things,
there are some real bugs to take care of.
> prism54 uses
> this, and is a reasonably popular card. Looks to me like this should be
> plugged. Is the patch below sufficient? (stolen from full 2.6 patch)
Yep, except that you have an extra chunk that should not be
in. You probably did not use the latest version of the patch (and that
was not in the one sent to Marcelo). I would not like to introduce a
real bug in 2.4.X :-(
> thanks,
> -chris
This chunk is erroneous :
> @@ -731,7 +749,7 @@ static inline int ioctl_private_call(str
> return -EFAULT;
>
> /* Does it fits within bounds ? */
> - if(iwr->u.data.length > (descr->set_args &
> + if(iwr->u.data.length > (descr->get_args &
>IW_PRIV_SIZE_MASK))
> return -E2BIG;
> } else {
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: [PATCH] net #9
On Wed, May 30, 2001 at 02:48:24AM +0200, Andrzej Krzysztofowicz wrote: > > The following patch removes some zero initializers from statics > > Andrzej If I were you, I would fix gcc rather than making my code unreadable. I write source code in C rather than coding ASM in hex because of the semantic attached to what I write, which make the code readable by me and by other, and make my code portable to other environments (for example user space). Initialisating a variable to zero as opposed to leaving it undefined has plenty of semantic attached to it. It's the job of the compiler to make sure that all this kind of stupid optimisation are done and the code produced is as efficient as possible and adapted to the exact characteristics of the operating envirtonment. Especially that it's probably 10 lines to add the proper option to gcc command line. Therefore, Alan, please do not apply those kind of patches to my drivers. Thanks... 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/
[PATCH 2.6 IrDA] support NSC PC8738x
ir261_nsc_38x.diff :
~~
o [FEATURE] support NSC PC8738x chipset (IBM x40 & ...)
Signed-off-by: Jean Tourrilhes <[EMAIL PROTECTED]>
diff -u -p linux/drivers/net/irda/nsc-ircc.d0.c
linux/drivers/net/irda/nsc-ircc.c
--- linux/drivers/net/irda/nsc-ircc.d0.cFri Feb 4 16:17:07 2005
+++ linux/drivers/net/irda/nsc-ircc.c Mon Feb 7 14:35:05 2005
@@ -94,16 +94,13 @@ static nsc_chip_t chips[] = {
nsc_ircc_probe_108, nsc_ircc_init_108 },
{ "PC87338", { 0x398, 0x15c, 0x2e }, 0x08, 0xb0, 0xf8,
nsc_ircc_probe_338, nsc_ircc_init_338 },
+ /* Contributed by Steffen Pingel - IBM X40 */
+ { "PC8738x", { 0x164e, 0x4e, 0x0 }, 0x20, 0xf4, 0xff,
+ nsc_ircc_probe_39x, nsc_ircc_init_39x },
/* Contributed by Jan Frey - IBM A30/A31 */
{ "PC8739x", { 0x2e, 0x4e, 0x0 }, 0x20, 0xea, 0xff,
nsc_ircc_probe_39x, nsc_ircc_init_39x },
{ NULL }
-#if 0
- /* Probably bogus, "PC8739x" should be the real thing. Jean II */
- /* Contributed by Kevin Thayer - OmniBook 6100 */
- { "PC87338?", { 0x2e, 0x15c, 0x398 }, 0x08, 0x00, 0xf8,
- nsc_ircc_probe_338, nsc_ircc_init_338 },
-#endif
};
/* Max 4 instances for now */
-
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/
[PATCH 2.6 IrDA] arbitrary lsap connect
ir261_connect_lsap-2.diff :
~
o [FEATURE] allow IrDA socket to connect on arbitrary LSAPs
Signed-off-by: Jean Tourrilhes <[EMAIL PROTECTED]>
diff -u -p linux/net/irda/af_irda.d0.c linux/net/irda/af_irda.c
--- linux/net/irda/af_irda.d0.c Fri Feb 4 14:45:33 2005
+++ linux/net/irda/af_irda.cFri Feb 4 15:16:26 2005
@@ -1012,11 +1012,23 @@ static int irda_connect(struct socket *s
self->daddr = addr->sir_addr;
IRDA_DEBUG(1, "%s(), daddr = %08x\n", __FUNCTION__,
self->daddr);
- /* Query remote LM-IAS */
- err = irda_find_lsap_sel(self, addr->sir_name);
- if (err) {
- IRDA_DEBUG(0, "%s(), connect failed!\n", __FUNCTION__);
- return err;
+ /* If we don't have a valid service name, we assume the
+* user want to connect on a specific LSAP. Prevent
+* the use of invalid LSAPs (IrLMP 1.1 p10). Jean II */
+ if((addr->sir_name[0] != '\0') ||
+ (addr->sir_lsap_sel >= 0x70)) {
+ /* Query remote LM-IAS using service name */
+ err = irda_find_lsap_sel(self, addr->sir_name);
+ if (err) {
+ IRDA_DEBUG(0, "%s(), connect failed!\n",
__FUNCTION__);
+ return err;
+ }
+ } else {
+ /* Directly connect to the remote LSAP
+* specified by the sir_lsap field.
+* Please use with caution, in IrDA LSAPs are
+* dynamic and there is no "well-known" LSAP. */
+ self->dtsap_sel = addr->sir_lsap_sel;
}
}
-
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/
[PATCH 2.6 IrDA] cleanup obsolete construct in IrCOMM
ir261_ircomm_write_cleanup.diff :
~~~
o [FEATURE] cleanup some construct obsoleted by Linus's patch
Signed-off-by: Jean Tourrilhes <[EMAIL PROTECTED]>
diff -u -p linux/net/irda/ircomm/ircomm_tty.d0.c
linux/net/irda/ircomm/ircomm_tty.c
--- linux/net/irda/ircomm/ircomm_tty.d0.c Fri Feb 4 16:19:03 2005
+++ linux/net/irda/ircomm/ircomm_tty.c Fri Feb 4 16:20:54 2005
@@ -671,10 +671,9 @@ static void ircomm_tty_do_softint(void *
*accepted for writing. This routine is mandatory.
*/
static int ircomm_tty_write(struct tty_struct *tty,
- const unsigned char *ubuf, int count)
+ const unsigned char *buf, int count)
{
struct ircomm_tty_cb *self = (struct ircomm_tty_cb *) tty->driver_data;
- unsigned char *kbuf;/* Buffer in kernel space */
unsigned long flags;
struct sk_buff *skb;
int tailroom = 0;
@@ -714,9 +713,6 @@ static int ircomm_tty_write(struct tty_s
if (count < 1)
return 0;
- /* The buffer is already in kernel space */
- kbuf = (unsigned char *) ubuf;
-
/* Protect our manipulation of self->tx_skb and related */
spin_lock_irqsave(&self->spinlock, flags);
@@ -779,7 +775,7 @@ static int ircomm_tty_write(struct tty_s
}
/* Copy data */
- memcpy(skb_put(skb,size), kbuf + len, size);
+ memcpy(skb_put(skb,size), buf + len, size);
count -= size;
len += size;
-
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/
[PATCH 2.6 IrDA] Mark exit code properly in VIA driver
irXXX_via_devexit.diff :
~~
o [CORRECT] Mark exit code properly in VIA driver
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
Signed-off-by: Jean Tourrilhes <[EMAIL PROTECTED]>
diff -Naurp ./drivers/net/irda/via-ircc.c~irda_via_devexit
./drivers/net/irda/via-ircc.c
--- ./drivers/net/irda/via-ircc.c~irda_via_devexit 2004-12-24
13:33:47.0 -0800
+++ ./drivers/net/irda/via-ircc.c 2005-01-06 21:18:49.742203456 -0800
@@ -83,7 +83,7 @@ static struct via_ircc_cb *dev_self[] =
/* Some prototypes */
static int via_ircc_open(int i, chipio_t * info, unsigned int id);
-static int __exit via_ircc_close(struct via_ircc_cb *self);
+static int via_ircc_close(struct via_ircc_cb *self);
static int via_ircc_dma_receive(struct via_ircc_cb *self);
static int via_ircc_dma_receive_complete(struct via_ircc_cb *self,
int iobase);
@@ -111,7 +111,7 @@ static void hwreset(struct via_ircc_cb *
static int via_ircc_dma_xmit(struct via_ircc_cb *self, u16 iobase);
static int upload_rxdata(struct via_ircc_cb *self, int iobase);
static int __devinit via_init_one (struct pci_dev *pcidev, const struct
pci_device_id *id);
-static void __exit via_remove_one (struct pci_dev *pdev);
+static void __devexit via_remove_one (struct pci_dev *pdev);
/* FIXME : Should use udelay() instead, even if we are x86 only - Jean II */
static void iodelay(int udelay)
@@ -140,7 +140,7 @@ static struct pci_driver via_driver = {
.name = VIA_MODULE_NAME,
.id_table = via_pci_tbl,
.probe = via_init_one,
- .remove = via_remove_one,
+ .remove = __devexit_p(via_remove_one),
};
@@ -273,7 +273,7 @@ static int __devinit via_init_one (struc
*Close all configured chips
*
*/
-static void __exit via_ircc_clean(void)
+static void via_ircc_clean(void)
{
int i;
@@ -285,7 +285,7 @@ static void __exit via_ircc_clean(void)
}
}
-static void __exit via_remove_one (struct pci_dev *pdev)
+static void __devexit via_remove_one (struct pci_dev *pdev)
{
IRDA_DEBUG(3, "%s()\n", __FUNCTION__);
@@ -468,7 +468,7 @@ static __devinit int via_ircc_open(int i
*Close driver instance
*
*/
-static int __exit via_ircc_close(struct via_ircc_cb *self)
+static int via_ircc_close(struct via_ircc_cb *self)
{
int iobase;
-
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/
[PATCH 2.6 IrDA] remove unneeded EXPORT_SYMBOL's from irport.c
irXXX_irport_exports.diff :
~
o [FEATURE] make needlessly global code static
o [FEATURE] remove unneeded EXPORT_SYMBOL's from irport.c
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Signed-off-by: Jean Tourrilhes <[EMAIL PROTECTED]>
--- linux-2.6.11-rc3-mm2-full/drivers/net/irda/irtty-sir.c.old 2005-02-16
15:40:41.0 +0100
+++ linux-2.6.11-rc3-mm2-full/drivers/net/irda/irtty-sir.c 2005-02-16
15:40:52.0 +0100
@@ -413,7 +413,7 @@
/* --- */
-struct sir_driver sir_tty_drv = {
+static struct sir_driver sir_tty_drv = {
.owner = THIS_MODULE,
.driver_name= "sir_tty",
.start_dev = irtty_start_dev,
--- linux-2.6.11-rc3-mm2-full/drivers/net/irda/smsc-ircc2.c.old 2005-02-16
15:41:08.0 +0100
+++ linux-2.6.11-rc3-mm2-full/drivers/net/irda/smsc-ircc2.c 2005-02-16
15:41:17.0 +0100
@@ -203,7 +203,7 @@
/* Transceivers for SMSC-ircc */
-smsc_transceiver_t smsc_transceivers[]=
+static smsc_transceiver_t smsc_transceivers[]=
{
{ "Toshiba Satellite 1800 (GP data pin select)",
smsc_ircc_set_transceiver_toshiba_sat1800,
smsc_ircc_probe_transceiver_toshiba_sat1800},
{ "Fast pin select",
smsc_ircc_set_transceiver_smsc_ircc_fast_pin_select,
smsc_ircc_probe_transceiver_smsc_ircc_fast_pin_select},
--- linux-2.6.11-rc3-mm2-full/drivers/net/irda/irport.h.old 2005-02-16
15:42:36.0 +0100
+++ linux-2.6.11-rc3-mm2-full/drivers/net/irda/irport.h 2005-02-16
15:43:24.0 +0100
@@ -77,14 +77,4 @@
int (*interrupt)(int irq, void *dev_id, struct pt_regs *regs);
};
-struct irport_cb *irport_open(int i, unsigned int iobase, unsigned int irq);
-int irport_close(struct irport_cb *self);
-void irport_start(struct irport_cb *self);
-void irport_stop(struct irport_cb *self);
-void irport_change_speed(void *priv, __u32 speed);
-irqreturn_t irport_interrupt(int irq, void *dev_id, struct pt_regs *regs);
-int irport_hard_xmit(struct sk_buff *skb, struct net_device *dev);
-int irport_net_open(struct net_device *dev);
-int irport_net_close(struct net_device *dev);
-
#endif /* IRPORT_H */
--- linux-2.6.11-rc3-mm2-full/drivers/net/irda/irport.c.old 2005-02-16
15:43:34.0 +0100
+++ linux-2.6.11-rc3-mm2-full/drivers/net/irda/irport.c 2005-02-16
15:49:06.0 +0100
@@ -87,50 +87,14 @@
static int irport_change_speed_complete(struct irda_task *task);
static void irport_timeout(struct net_device *dev);
-EXPORT_SYMBOL(irport_open);
-EXPORT_SYMBOL(irport_close);
-EXPORT_SYMBOL(irport_start);
-EXPORT_SYMBOL(irport_stop);
-EXPORT_SYMBOL(irport_interrupt);
-EXPORT_SYMBOL(irport_hard_xmit);
-EXPORT_SYMBOL(irport_timeout);
-EXPORT_SYMBOL(irport_change_speed);
-EXPORT_SYMBOL(irport_net_open);
-EXPORT_SYMBOL(irport_net_close);
+static irqreturn_t irport_interrupt(int irq, void *dev_id,
+ struct pt_regs *regs);
+static int irport_hard_xmit(struct sk_buff *skb, struct net_device *dev);
+static void irport_change_speed(void *priv, __u32 speed);
+static int irport_net_open(struct net_device *dev);
+static int irport_net_close(struct net_device *dev);
-static int __init irport_init(void)
-{
- int i;
-
- for (i=0; (io[i] < 2000) && (i < 4); i++) {
- if (irport_open(i, io[i], irq[i]) != NULL)
- return 0;
- }
- /*
-* Maybe something failed, but we can still be usable for FIR drivers
-*/
- return 0;
-}
-
-/*
- * Function irport_cleanup ()
- *
- *Close all configured ports
- *
- */
-static void __exit irport_cleanup(void)
-{
- int i;
-
-IRDA_DEBUG( 4, "%s()\n", __FUNCTION__);
-
- for (i=0; i < 4; i++) {
- if (dev_self[i])
- irport_close(dev_self[i]);
- }
-}
-
-struct irport_cb *
+static struct irport_cb *
irport_open(int i, unsigned int iobase, unsigned int irq)
{
struct net_device *dev;
@@ -254,7 +218,7 @@
return NULL;
}
-int irport_close(struct irport_cb *self)
+static int irport_close(struct irport_cb *self)
{
ASSERT(self != NULL, return -1;);
@@ -285,40 +249,40 @@
return 0;
}
-void irport_start(struct irport_cb *self)
+static void irport_stop(struct irport_cb *self)
{
int iobase;
iobase = self->io.sir_base;
- irport_stop(self);
-
/* We can't lock, we may be called from a FIR driver - Jean II */
- /* Initialize UART */
- outb(UART_LCR_WLEN8, iobase+UART_LCR); /* Reset DLAB */
- outb((UART_MCR_DTR | UART_MCR_RTS | UART_MCR_OUT2), iobase+UART_MCR);
+ /* We are not transmitting any more */
+ self->transmitting = 0;
+
+ /* Reset UART */
+ outb(0, iobase+UART_MCR);
- /*
[PATCH 2.6 IrDA] stir4200 turnaround calculation fix
ir261_stir_turn.diff :
o [CORRECT] Proper turnaround computations in the stir4200 driver
o [CORRECT] Take care of Tx packet without IrDA metadata (speed)
Signed-off-by: John K. Luebs <[EMAIL PROTECTED]>
Signed-off-by: Jean Tourrilhes <[EMAIL PROTECTED]>
diff -u -p linux/drivers/net/irda/stir4200.d0.c
linux/drivers/net/irda/stir4200.c
--- linux/drivers/net/irda/stir4200.d0.cMon Feb 7 16:35:45 2005
+++ linux/drivers/net/irda/stir4200.c Mon Feb 7 16:37:25 2005
@@ -671,7 +671,8 @@ static void turnaround_delay(const struc
return;
do_gettimeofday(&now);
- us -= (now.tv_sec - stir->rx_time.tv_sec) * USEC_PER_SEC;
+ if (now.tv_sec - stir->rx_time.tv_sec > 0)
+ us -= USEC_PER_SEC;
us -= now.tv_usec - stir->rx_time.tv_usec;
if (us < 10)
return;
@@ -787,7 +788,7 @@ static int stir_transmit_thread(void *ar
stir_send(stir, skb);
dev_kfree_skb(skb);
- if (stir->speed != new_speed) {
+ if ((new_speed != -1) && (stir->speed != new_speed)) {
if (fifo_txwait(stir, -1) ||
change_speed(stir, new_speed))
break;
-
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/
[PATCH 2.6 IrDA] irda-usb sysfs support
ir261_irda-usb_sysfs-kill_urb-2.diff :
o [CORRECT] Forgot to convert a few usb_unlink_urb() in usb_kill_urb()
o [FEATURE] Proper sysfs support
Signed-off-by: John K. Luebs <[EMAIL PROTECTED]>
Signed-off-by: Jean Tourrilhes <[EMAIL PROTECTED]>
diff -u -p linux/drivers/net/irda/irda-usb.d0.c
linux/drivers/net/irda/irda-usb.c
--- linux/drivers/net/irda/irda-usb.d0.cFri Mar 4 15:37:25 2005
+++ linux/drivers/net/irda/irda-usb.c Fri Mar 4 15:38:38 2005
@@ -998,7 +998,7 @@ static int irda_usb_net_close(struct net
struct urb *urb = self->rx_urb[i];
struct sk_buff *skb = (struct sk_buff *) urb->context;
/* Cancel the receive command */
- usb_unlink_urb(urb);
+ usb_kill_urb(urb);
/* The skb is ours, free it */
if(skb) {
dev_kfree_skb(skb);
@@ -1367,12 +1367,12 @@ static int irda_usb_probe(struct usb_int
if (!net)
goto err_out;
+ SET_MODULE_OWNER(net);
+ SET_NETDEV_DEV(net, &intf->dev);
self = net->priv;
self->netdev = net;
spin_lock_init(&self->lock);
- SET_MODULE_OWNER(net);
-
/* Create all of the needed urbs */
for (i = 0; i < IU_MAX_RX_URBS; i++) {
self->rx_urb[i] = usb_alloc_urb(0, GFP_KERNEL);
@@ -1516,7 +1516,7 @@ static void irda_usb_disconnect(struct u
netif_stop_queue(self->netdev);
/* Stop all the receive URBs */
for (i = 0; i < IU_MAX_RX_URBS; i++)
- usb_unlink_urb(self->rx_urb[i]);
+ usb_kill_urb(self->rx_urb[i]);
/* Cancel Tx and speed URB.
* Toggle flags to make sure it's synchronous. */
self->tx_urb->transfer_flags &= ~URB_ASYNC_UNLINK;
-
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/
[PATCH 2.6 IrDA] fix IrNET poll with empty disco log
ir261_irnet_poll_fix-2.diff :
~~~
o [CORRECT] poll would improperly exit when the discovery log was empty
Signed-off-by: Jean Tourrilhes <[EMAIL PROTECTED]>
diff -u -p linux/net/irda/irnet/irnet_irda.j1.c
linux/net/irda/irnet/irnet_irda.c
--- linux/net/irda/irnet/irnet_irda.j1.cFri Feb 4 16:28:22 2005
+++ linux/net/irda/irnet/irnet_irda.c Fri Feb 4 16:28:58 2005
@@ -632,7 +632,7 @@ irda_irnet_destroy(irnet_socket * self)
self->iriap = NULL;
}
- /* Cleanup eventual discoveries from connection attempt */
+ /* Cleanup eventual discoveries from connection attempt or control channel */
if(self->discoveries != NULL)
{
/* Cleanup our copy of the discovery log */
diff -u -p linux/net/irda/irnet/irnet_ppp.j1.c linux/net/irda/irnet/irnet_ppp.c
--- linux/net/irda/irnet/irnet_ppp.j1.c Fri Feb 4 16:28:30 2005
+++ linux/net/irda/irnet/irnet_ppp.cFri Feb 4 16:28:58 2005
@@ -171,18 +171,44 @@ irnet_ctrl_write(irnet_socket * ap,
#ifdef INITIAL_DISCOVERY
/*--*/
/*
- * Function irnet_read_discovery_log (self)
+ * Function irnet_get_discovery_log (self)
+ *
+ *Query the content on the discovery log if not done
+ *
+ * This function query the current content of the discovery log
+ * at the startup of the event channel and save it in the internal struct.
+ */
+static void
+irnet_get_discovery_log(irnet_socket * ap)
+{
+ __u16mask = irlmp_service_to_hint(S_LAN);
+
+ /* Ask IrLMP for the current discovery log */
+ ap->discoveries = irlmp_get_discoveries(&ap->disco_number, mask,
+ DISCOVERY_DEFAULT_SLOTS);
+
+ /* Check if the we got some results */
+ if(ap->discoveries == NULL)
+ap->disco_number = -1;
+
+ DEBUG(CTRL_INFO, "Got the log (0x%p), size is %d\n",
+ ap->discoveries, ap->disco_number);
+}
+
+/*--*/
+/*
+ * Function irnet_read_discovery_log (self, event)
*
*Read the content on the discovery log
*
* This function dump the current content of the discovery log
* at the startup of the event channel.
- * Return 1 if written on the control channel...
+ * Return 1 if wrote an event on the control channel...
*
* State of the ap->disco_XXX variables :
- * at socket creation :disco_index = 0 ; disco_number = 0
- * while reading : disco_index = X ; disco_number = Y
- * After reading : disco_index = Y ; disco_number = -1
+ * Socket creation : discoveries = NULL ; disco_index = 0 ; disco_number = 0
+ * While reading :discoveries = ptr ; disco_index = X ; disco_number = Y
+ * After reading :discoveries = NULL ; disco_index = Y ; disco_number = -1
*/
static inline int
irnet_read_discovery_log(irnet_socket *ap,
@@ -201,19 +227,8 @@ irnet_read_discovery_log(irnet_socket *
}
/* Test if it's the first time and therefore we need to get the log */
- if(ap->disco_index == 0)
-{
- __u16mask = irlmp_service_to_hint(S_LAN);
-
- /* Ask IrLMP for the current discovery log */
- ap->discoveries = irlmp_get_discoveries(&ap->disco_number, mask,
- DISCOVERY_DEFAULT_SLOTS);
- /* Check if the we got some results */
- if(ap->discoveries == NULL)
- ap->disco_number = -1;
- DEBUG(CTRL_INFO, "Got the log (0x%p), size is %d\n",
- ap->discoveries, ap->disco_number);
-}
+ if(ap->discoveries == NULL)
+irnet_get_discovery_log(ap);
/* Check if we have more item to dump */
if(ap->disco_index < ap->disco_number)
@@ -417,7 +432,14 @@ irnet_ctrl_poll(irnet_socket * ap,
mask |= POLLIN | POLLRDNORM;
#ifdef INITIAL_DISCOVERY
if(ap->disco_number != -1)
-mask |= POLLIN | POLLRDNORM;
+{
+ /* Test if it's the first time and therefore we need to get the log */
+ if(ap->discoveries == NULL)
+ irnet_get_discovery_log(ap);
+ /* Recheck */
+ if(ap->disco_number != -1)
+ mask |= POLLIN | POLLRDNORM;
+}
#endif /* INITIAL_DISCOVERY */
DEXIT(CTRL_TRACE, " - mask=0x%X\n", mask);
-
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/
IrDA patches for 2.6.12-rc1
Hi David, More trivial fixes in various places of the IrDA stack and driver, no biggies. Freshly tested on 2.6.11, most have been on my web pages for a while. This should go in 2.6.12-rc1. Thanks ! Jean --- [FEATURE] : Add a new feature to the IrDA stack [CORRECT] : Fix to have the correct/expected behaviour [CRITICA] : Fix potential kernel crash ir261_irnet_poll_fix-2.diff : ~~~ o [CORRECT] poll would improperly exit when the discovery log was empty Signed-off-by: Jean Tourrilhes <[EMAIL PROTECTED]> ir261_irda-usb_sysfs-kill_urb-2.diff : o [CORRECT] Forgot to convert a few usb_unlink_urb() in usb_kill_urb() o [FEATURE] Proper sysfs support Signed-off-by: John K. Luebs <[EMAIL PROTECTED]> Signed-off-by: Jean Tourrilhes <[EMAIL PROTECTED]> ir261_stir_turn.diff : o [CORRECT] Proper turnaround computations in the stir4200 driver o [CORRECT] Take care of Tx packet without IrDA metadata (speed) Signed-off-by: John K. Luebs <[EMAIL PROTECTED]> Signed-off-by: Jean Tourrilhes <[EMAIL PROTECTED]> irXXX_via_devexit.diff : ~~ o [CORRECT] Make exit code properly in VIA driver Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]> Signed-off-by: Jean Tourrilhes <[EMAIL PROTECTED]> ir261_connect_lsap-2.diff : ~ o [FEATURE] allow IrDA socket to connect on arbitrary LSAPs Signed-off-by: Jean Tourrilhes <[EMAIL PROTECTED]> ir261_nsc_38x.diff : ~~ o [FEATURE] support NSC PC8738x chipset (IBM x40 & ...) Signed-off-by: Jean Tourrilhes <[EMAIL PROTECTED]> ir261_ircomm_write_cleanup.diff : ~~~ o [FEATURE] cleanup some construct obsoleted by Linus's patch Signed-off-by: Jean Tourrilhes <[EMAIL PROTECTED]> irXXX_irport_exports.diff : ~ o [FEATURE] make needlessly global code static o [FEATURE] remove unneeded EXPORT_SYMBOL's from irport.c Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> Signed-off-by: Jean Tourrilhes <[EMAIL PROTECTED]> - 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: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_E
[BUG] MODULE_PARM conversions introduces bug in Wavelan driver
Hi Rusty, (If you are not the culprit, please forward to the guilty party). The patch the the Wavelan driver that I quote below introduces a nice bug that can crash the kernel. Maybe you want to think about fixing it, or maybe I should revert the patch... As a side note... I personally don't like the "string pointer" module parameter, previously 'p' and currently 'charp', because I can easily lead to this kind of bug, add extra bloat in the module for various checks and doesn't have a clean way to return the error to user space. I personally introduced the "double char array" module parameter, 'c', to fix that. I even sent you the patch to add 'c' support in your new module loader (see set_obsolete()). Would it be possible to carry this feature with the new module_param_array ? Thanks in advance... Jean - diff -Nru a/drivers/net/wireless/wavelan.c b/drivers/net/wireless/wavelan.c --- a/drivers/net/wireless/wavelan.c2005-01-11 20:03:09 -08:00 +++ b/drivers/net/wireless/wavelan.c2005-01-11 20:03:09 -08:00 @@ -4344,7 +4344,8 @@ struct net_device *dev = alloc_etherdev(sizeof(net_local)); if (!dev) break; - memcpy(dev->name, name[i], IFNAMSIZ); /* Copy name */ + if (name[i]) + strcpy(dev->name, name[i]); /* Copy name */ dev->base_addr = io[i]; dev->irq = irq[i]; diff -Nru a/drivers/net/wireless/wavelan.p.h b/drivers/net/wireless/wavelan.p.h --- a/drivers/net/wireless/wavelan.p.h 2005-01-11 20:03:07 -08:00 +++ b/drivers/net/wireless/wavelan.p.h 2005-01-11 20:03:07 -08:00 @@ -703,10 +703,11 @@ /* Parameters set by insmod */ static int io[4]; static int irq[4]; -static charname[4][IFNAMSIZ]; -MODULE_PARM(io, "1-4i"); -MODULE_PARM(irq, "1-4i"); -MODULE_PARM(name, "1-4c" __MODULE_STRING(IFNAMSIZ)); +static char*name[4]; +module_param_array(io, int, NULL, 0); +module_param_array(irq, int, NULL, 0); +module_param_array(name, charp, NULL, 0); + MODULE_PARM_DESC(io, "WaveLAN I/O base address(es),required"); MODULE_PARM_DESC(irq, "WaveLAN IRQ number(s)"); MODULE_PARM_DESC(name, "WaveLAN interface neme(s)"); - 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: [BUG] MODULE_PARM conversions introduces bug in Wavelan driver
On Wed, Jan 19, 2005 at 01:42:33PM +1100, Rusty Russell wrote: > On Tue, 2005-01-18 at 16:47 -0800, Jean Tourrilhes wrote: > > Hi Rusty, > > > > (If you are not the culprit, please forward to the guilty party). > > Almost certainly me. We gave people warning, we even marked MODULE_PARM > deprecated, but eventually I had to roll through and try to autoconvert. I have nothing against the change to module_param_array(), and I even think that it's a good idea. Just doing my job of peer review. > > I personally introduced the "double char array" module > > parameter, 'c', to fix that. I even sent you the patch to add 'c' > > support in your new module loader (see set_obsolete()). Would it be > > possible to carry this feature with the new module_param_array ? > > Thanks in advance... > > Actually, it's designed so you can extend it yourself: at its base, > module_param_call() is just a callback mechanism. Yes, I could do my little hack in my corner, but I think it would be counter productive. I'm sure that compared to adding a check on strlen, it would be more bloat. But, more importantly, I would make the code more obscure and unmaintanable. But, I think you are missing the point I'm making. We are striving to make APIs that are simple, efficient and avoid users to make stupid mistakes. The conversion from MODULE_PARM to module_param goes exactly in this direction, as it adds more type safety. This is good, as module_param is probably the most used user/kernel interface. I believe that buffer overrun is the number one security problem in Linux. It seems that it even happens to the best of us. So, it would seem to me that making the module_param API a bit more bullet proof with regard to buffer overrun might be a good idea. So, I'm not advocating that you build this feature just for me, but that you make it the standard and force people to use it. > Thanks! > Rusty. 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/
[PATCH 2.6.20] kobject net ifindex + rename
Hi all,
Various hotplug packages have had trouble dealing with network
interface being renamed. I've decided to tackle this issue from two
angles :
o export ifindex to those apps, as ifindex is persistent.
o expose interface renaming as a hotplug event.
Those two changes are complementary, even an application that
would track interface by ifindex would sometime needs to know about
ifname change. My assumption is that most apps would still use ifname
for a long while to be backward compatible with older kernels.
The kobject framework is well designed, so adding these
features is trivial change and won't run the risk of breaking anything
(famous last words). Obviously, hotplug apps are free to ignore those
additional features.
Patch for 2.6.20 is attached. The patch was tested on a system
running the hotplug scripts, and on another system running udev.
Have fun...
Jean
Signed-off-by: Jean Tourrilhes <[EMAIL PROTECTED]>
-
diff -u -p linux/include/linux/kobject.j1.h linux/include/linux/kobject.h
--- linux/include/linux/kobject.j1.h2007-02-26 18:37:55.0 -0800
+++ linux/include/linux/kobject.h 2007-02-26 18:38:42.0 -0800
@@ -48,6 +48,7 @@ enum kobject_action {
KOBJ_OFFLINE= (__force kobject_action_t) 0x06, /* device
offline */
KOBJ_ONLINE = (__force kobject_action_t) 0x07, /* device
online */
KOBJ_MOVE = (__force kobject_action_t) 0x08, /* device move
*/
+ KOBJ_RENAME = (__force kobject_action_t) 0x09, /* device
renamed */
};
struct kobject {
diff -u -p linux/net/core/net-sysfs.j1.c linux/net/core/net-sysfs.c
--- linux/net/core/net-sysfs.j1.c 2007-02-27 15:01:08.0 -0800
+++ linux/net/core/net-sysfs.c 2007-02-27 15:06:49.0 -0800
@@ -412,6 +412,17 @@ static int netdev_uevent(struct class_de
if ((size <= 0) || (i >= num_envp))
return -ENOMEM;
+ /* pass ifindex to uevent.
+* ifindex is useful as it won't change (interface name may change)
+* and is what RtNetlink uses natively. */
+ envp[i++] = buf;
+ n = snprintf(buf, size, "IFINDEX=%d", dev->ifindex) + 1;
+ buf += n;
+ size -= n;
+
+ if ((size <= 0) || (i >= num_envp))
+ return -ENOMEM;
+
envp[i] = NULL;
return 0;
}
diff -u -p linux/lib/kobject_uevent.j1.c linux/lib/kobject_uevent.c
--- linux/lib/kobject_uevent.j1.c 2007-02-26 18:38:02.0 -0800
+++ linux/lib/kobject_uevent.c 2007-02-26 18:38:42.0 -0800
@@ -52,6 +52,8 @@ static char *action_to_string(enum kobje
return "online";
case KOBJ_MOVE:
return "move";
+ case KOBJ_RENAME:
+ return "rename";
default:
return NULL;
}
diff -u -p linux/drivers/base/class.j1.c linux/drivers/base/class.c
--- linux/drivers/base/class.j1.c 2007-02-26 18:38:10.0 -0800
+++ linux/drivers/base/class.c 2007-02-27 15:52:37.0 -0800
@@ -841,6 +841,8 @@ int class_device_rename(struct class_dev
{
int error = 0;
char *old_class_name = NULL, *new_class_name = NULL;
+ char *devname_string = NULL;
+ char *envp[2];
class_dev = class_device_get(class_dev);
if (!class_dev)
@@ -849,6 +851,15 @@ int class_device_rename(struct class_dev
pr_debug("CLASS: renaming '%s' to '%s'\n", class_dev->class_id,
new_name);
+ devname_string = kmalloc(strlen(class_dev->class_id) + 15, GFP_KERNEL);
+ if (!devname_string) {
+ class_device_put(class_dev);
+ return -ENOMEM;
+ }
+ sprintf(devname_string, "INTERFACE_OLD=%s", class_dev->class_id);
+ envp[0] = devname_string;
+ envp[1] = NULL;
+
#ifdef CONFIG_SYSFS_DEPRECATED
if (class_dev->dev)
old_class_name = make_class_name(class_dev->class->name,
@@ -868,8 +879,16 @@ int class_device_rename(struct class_dev
sysfs_remove_link(&class_dev->dev->kobj, old_class_name);
}
#endif
+
+ /* This function is only used for network interface.
+* Some hotplug package track interfaces by their name and
+* therefore want to know when the name is changed by the user. */
+ if(!error)
+ kobject_uevent_env(&class_dev->kobj, KOBJ_RENAME, envp);
+
class_device_put(class_dev);
+ kfree(devname_string);
kfree(old_class_name);
kfree(new_class_name);
-
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: [PATCH 2.6.20] kobject net ifindex + rename
On Wed, Feb 28, 2007 at 07:36:17AM -0800, Greg KH wrote: > On Tue, Feb 27, 2007 at 05:27:41PM -0800, Jean Tourrilhes wrote: > > diff -u -p linux/drivers/base/class.j1.c linux/drivers/base/class.c > > --- linux/drivers/base/class.j1.c 2007-02-26 18:38:10.0 -0800 > > +++ linux/drivers/base/class.c 2007-02-27 15:52:37.0 -0800 > > @@ -841,6 +841,8 @@ int class_device_rename(struct class_dev > > This function is not in the 2.6.21-rc2 kernel, so you might want to > rework this patch a bit :) It was a trial balloon to gather feedback. I will do. > Also, it's userspace that causes the rename to happen, so it knows it > did it, why should the kernel have to emit a message to tell userspace > again what just happened? Username is not one big program, but a collection of program, and one program does not know what another program do. In particular, udev does not know when people are using iproute2 to rename interface and loose its marbles. We don't really want to ban iproute2 or udev ;-) > thanks, > > greg k-h 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: [PATCH 2.6.20] kobject net ifindex + rename
On Wed, Feb 28, 2007 at 10:34:37AM +0100, Jarek Poplawski wrote: > On 28-02-2007 02:27, Jean Tourrilhes wrote: > > Hi all, > ... > > Patch for 2.6.20 is attached. The patch was tested on a system > > running the hotplug scripts, and on another system running udev. > > > > Have fun... > > > > Jean > > > > Signed-off-by: Jean Tourrilhes <[EMAIL PROTECTED]> > > > > - > ... > > diff -u -p linux/net/core/net-sysfs.j1.c linux/net/core/net-sysfs.c > > --- linux/net/core/net-sysfs.j1.c 2007-02-27 15:01:08.0 -0800 > > +++ linux/net/core/net-sysfs.c 2007-02-27 15:06:49.0 -0800 > > @@ -412,6 +412,17 @@ static int netdev_uevent(struct class_de > > if ((size <= 0) || (i >= num_envp)) > > return -ENOMEM; > > > > + /* pass ifindex to uevent. > > +* ifindex is useful as it won't change (interface name may change) > > +* and is what RtNetlink uses natively. */ > > + envp[i++] = buf; > > + n = snprintf(buf, size, "IFINDEX=%d", dev->ifindex) + 1; > > + buf += n; > > + size -= n; > > + > > + if ((size <= 0) || (i >= num_envp)) > > Btw.: > 1. if size == 10 and snprintf returns 9 (without NULL) >then n == 10 (with NULL), so isn't it enough (here and above): > > if ((size < 0) || (i >= num_envp)) I just cut'n'pasted the code a few line above. If the original code is incorrect, it need fixing. And it will need fixing in probably a lot of places. > 2. shouldn't there be (here and above): > > envp[--i] = NULL; > No, envp is local, so who cares. Thanks. 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: [PATCH 2.6.20] kobject net ifindex + rename
On Wed, Feb 28, 2007 at 10:16:05AM +0100, Johannes Berg wrote: > Hi, > > > Patch for 2.6.20 is attached. > > ... and in the meantime netdevices aren't class_device any more :) IOW, > your patch isn't going to work any more. That's why I always specify the kernel version. I'll look into that, I'm sure it's not the end of the world ;-) > Also, I think wireless could benefit from this as well. In which sense ? Wireless interface are regular netdevices. > > The kobject framework is well designed, so adding these > > features is trivial change and won't run the risk of breaking anything > > (famous last words). Obviously, hotplug apps are free to ignore those > > additional features. > > Why not just add this to base kobject_rename instead? That way, > userspace is notified for all renames in sysfs. > The patch then collapses down to the change in net's sysfs code to add > the ifindex to the environment, and another change in kobject to invoke > a new event when a name changes and show the old name. I'm just trying to follow the established pattern. Both class_device_add() and class_device_del() are generating the event. Also, I'm not sure if other subsystem would benefit from it, I don't want to generate too many useless events. > johannes Thanks ! 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: [PATCH 2.6.20] kobject net ifindex + rename
On Wed, Feb 28, 2007 at 07:36:17AM -0800, Greg KH wrote:
> On Tue, Feb 27, 2007 at 05:27:41PM -0800, Jean Tourrilhes wrote:
> > diff -u -p linux/drivers/base/class.j1.c linux/drivers/base/class.c
> > --- linux/drivers/base/class.j1.c 2007-02-26 18:38:10.0 -0800
> > +++ linux/drivers/base/class.c 2007-02-27 15:52:37.0 -0800
> > @@ -841,6 +841,8 @@ int class_device_rename(struct class_dev
>
> This function is not in the 2.6.21-rc2 kernel, so you might want to
> rework this patch a bit :)
Thanks for all you good comments. I ported my patch to
2.6.21-rc2, and tested it both on a hotplug and a udev system. Patch
is attached, I would be glad if you could push that through the usual
channels.
Also, I realised that I forgot to say in my original e-mail
that migrating udev to use ifindex instead of ifname would fix the
remove/add race condition for network devices. But that's not going to
happen overnight...
Have fun...
Jean
Signed-off-by: Jean Tourrilhes <[EMAIL PROTECTED]>
-
diff -u -p linux/include/linux/kobject.j1.h linux/include/linux/kobject.h
--- linux/include/linux/kobject.j1.h2007-02-28 14:26:29.0 -0800
+++ linux/include/linux/kobject.h 2007-02-28 14:27:54.0 -0800
@@ -48,6 +48,7 @@ enum kobject_action {
KOBJ_OFFLINE= (__force kobject_action_t) 0x06, /* device
offline */
KOBJ_ONLINE = (__force kobject_action_t) 0x07, /* device
online */
KOBJ_MOVE = (__force kobject_action_t) 0x08, /* device move
*/
+ KOBJ_RENAME = (__force kobject_action_t) 0x09, /* device
renamed */
};
struct kobject {
diff -u -p linux/net/core/net-sysfs.j1.c linux/net/core/net-sysfs.c
--- linux/net/core/net-sysfs.j1.c 2007-02-28 14:26:45.0 -0800
+++ linux/net/core/net-sysfs.c 2007-02-28 14:27:54.0 -0800
@@ -424,6 +424,17 @@ static int netdev_uevent(struct device *
if ((size <= 0) || (i >= num_envp))
return -ENOMEM;
+ /* pass ifindex to uevent.
+* ifindex is useful as it won't change (interface name may change)
+* and is what RtNetlink uses natively. */
+ envp[i++] = buf;
+ n = snprintf(buf, size, "IFINDEX=%d", dev->ifindex) + 1;
+ buf += n;
+ size -= n;
+
+ if ((size <= 0) || (i >= num_envp))
+ return -ENOMEM;
+
envp[i] = NULL;
return 0;
}
diff -u -p linux/lib/kobject_uevent.j1.c linux/lib/kobject_uevent.c
--- linux/lib/kobject_uevent.j1.c 2007-02-28 14:26:58.0 -0800
+++ linux/lib/kobject_uevent.c 2007-02-28 14:27:54.0 -0800
@@ -52,6 +52,8 @@ static char *action_to_string(enum kobje
return "online";
case KOBJ_MOVE:
return "move";
+ case KOBJ_RENAME:
+ return "rename";
default:
return NULL;
}
diff -u -p linux/drivers/base/core.j1.c linux/drivers/base/core.c
--- linux/drivers/base/core.j1.c2007-02-28 15:45:45.0 -0800
+++ linux/drivers/base/core.c 2007-02-28 15:47:30.0 -0800
@@ -1007,6 +1007,8 @@ int device_rename(struct device *dev, ch
char *new_class_name = NULL;
char *old_symlink_name = NULL;
int error;
+ char *devname_string = NULL;
+ char *envp[2];
dev = get_device(dev);
if (!dev)
@@ -1014,6 +1016,15 @@ int device_rename(struct device *dev, ch
pr_debug("DEVICE: renaming '%s' to '%s'\n", dev->bus_id, new_name);
+ devname_string = kmalloc(strlen(dev->bus_id) + 15, GFP_KERNEL);
+ if (!devname_string) {
+ put_device(dev);
+ return -ENOMEM;
+ }
+ sprintf(devname_string, "INTERFACE_OLD=%s", dev->bus_id);
+ envp[0] = devname_string;
+ envp[1] = NULL;
+
#ifdef CONFIG_SYSFS_DEPRECATED
if ((dev->class) && (dev->parent))
old_class_name = make_class_name(dev->class->name, &dev->kobj);
@@ -1049,12 +1060,20 @@ int device_rename(struct device *dev, ch
sysfs_create_link(&dev->class->subsys.kset.kobj, &dev->kobj,
dev->bus_id);
}
+
+ /* This function is only used for network interface.
+* Some hotplug package track interfaces by their name and
+* therefore want to know when the name is changed by the user. */
+ if(!error)
+ kobject_uevent_env(&dev->kobj, KOBJ_RENAME, envp);
+
put_device(dev);
kfree(new_class_name);
kfree(old_symlink_name);
out_free_old_class:
kfree(old_class_name);
+ kfree(devname_string);
return error;
}
-
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: [PATCH 2.6.20] kobject net ifindex + rename
On Thu, Mar 01, 2007 at 01:37:46AM +0100, Johannes Berg wrote: > On Wed, 2007-02-28 at 16:26 -0800, Jean Tourrilhes wrote: > > > + /* This function is only used for network interface. > > +* Some hotplug package track interfaces by their name and > > +* therefore want to know when the name is changed by the user. */ > > Right now, that's true, but wireless is going to start using > device_rename pretty soon as well. Could you rephrase this comment? > > johannes I would prefer to fix the comment when this change actually happens. I prefer comments to refer to the current reality, rather than past/future situation. When you introduce wireless renaming, you will need to verify the whole chain anyway, so you might as well fix the comment while merging wireless renaming. Note also that my comment is technically correct. I did not say 'netdev' but the more generic term 'network interface', and I believe your wireless interface is a 'network interface', even if it's not a netdev ;-) But if this really bugs you, please feel free to respin my patch. 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: 2.6.19-rc6-mm2
On Tue, Nov 28, 2006 at 04:58:28PM -0800, Andrew Morton wrote: > On Tue, 28 Nov 2006 19:24:45 -0500 > Thomas Tuttle <[EMAIL PROTECTED]> wrote: > > > 2. I'm not sure if this bug is in the kernel, wireless tools, or the > > ipw3945 driver, but I haven't changed the version of anything but the > > kernel. When I do `iwconfig eth1 essid foobar' something drops the > > last character of the essid, and a subsequent `iwconfig eth1' shows > > "fooba" as the essid. And it's actually set as "fooba", since I had > > to do `iwconfig eth1 essid MyUsualEssid_' (note underscore) to get on > > to my usual network. > > This could be version skew between the wireless APIs in the kernel.org kernel, > the wireless userspace, the out-of-tree ipw3945 driver and conceivably one > of the git trees in -mm (although I suspect not the latter). > > I don't know, but I know who to cc ;) Probably they will want to knwo which > version of wireless-tools userspace you are running. Yes, it's a problem because the driver is out-of-tree. I sent a patch to the maintainer to make the driver compatible with kernel before/after, and it's actually integrated in the version 1.1.2 of the driver (Nov 1st). So, please upgrade your driver and tell us how it works... 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/
[PATCH 2.6.20] pwc : Cisco VT Camera support
Hi,
I already sent this e-mail to Luc and on the pwc mailing list,
and got no answer. I'm trying again with the hope that this patch
would go in the kernel...
I have a Cisco VT Camera, and it was just collecting dust. I
decided to try connecting it to my Linux box at home.
Just a disgression about the product. The Cisco VT Camera is a
webcam Cisco sold to work with their IP phone hardware and
software. It's mostly useless on Windows, as it interfaces only to
Cisco software. You can find some for cheap on eBay...
Physically, it's just a Logitech Pro 4000. The only difference
with the Pro 4000 is the Cisco logo and that it's grey like the Pro
3000.
I believe Cisco is now selling the Cisco VT Camera II, which
look to be something else...
So, assuming that it was a Pro 4000 inside, I created the
little patch attached.
I'm new to webcam under Linux, but I managed to get an image
from it using xawtv, and the image looked all right, so I consider
that a success. The imaged seemed a bit small and I could not get the
microphone driver loaded, but I assume it's my lack of experience.
Note that I did not try any other type_id, but this one works
great.
Have fun...
Jean
---
diff -u -p linux/drivers/media/video/pwc/pwc-if.c~
linux/drivers/media/video/pwc/pwc-if.c
--- linux/drivers/media/video/pwc/pwc-if.c~ 2007-02-23 22:08:40.0
-0800
+++ linux/drivers/media/video/pwc/pwc-if.c 2007-03-04 22:42:43.0
-0800
@@ -1547,6 +1547,10 @@ static int usb_pwc_probe(struct usb_inte
features |= FEATURE_MOTOR_PANTILT;
break;
case 0x08b6:
+ PWC_INFO("Logitech/Cisco VT Camera webcam detected.\n");
+ name = "Cisco VT Camera";
+ type_id = 740; /* CCD sensor */
+ break;
case 0x08b7:
case 0x08b8:
PWC_INFO("Logitech QuickCam detected (reserved ID).\n");
-
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: [PATCH 2.6.20] kobject net ifindex + rename
On Thu, Mar 01, 2007 at 08:42:09AM +0100, Jarek Poplawski wrote: > On Wed, Feb 28, 2007 at 10:45:41AM -0800, Jean Tourrilhes wrote: > > > > + > > > > + if ((size <= 0) || (i >= num_envp)) > > > > > > Btw.: > > > 1. if size == 10 and snprintf returns 9 (without NULL) > > >then n == 10 (with NULL), so isn't it enough (here and above): > > > > > > if ((size < 0) || (i >= num_envp)) > > > > I just cut'n'pasted the code a few line above. If the original > > code is incorrect, it need fixing. And it will need fixing in probably > > a lot of places. > > I think you're kind of responsible for your part, at least. I personally don't go fixing stuff without having a full undersunding of the context and why it was done this way. To me it look this test was intentionally done this way, so there may be something I don't know about. I guess I would need to double check more closely what weid calculation the caller does with the buffer size. That's why I would prefer a separate patch about those issues that give the opportunity for the stakeholder to really talk about this, rather than slipping it under the carpet. In the worse case, this is not a bug, this just means that we may not use the last char of the buffer. > > > 2. shouldn't there be (here and above): > > > > > > envp[--i] = NULL; > > > > > > > No, envp is local, so who cares. > > But envp[i] isn't (at least here). So, I guess, a caller > of this function could care. Check the full source code of the caller, and you will see that the caller does not care (and it's local to the caller). > > > > + if ((size <= 0) || (i >= num_envp)) > > > > + return -ENOMEM; > > And one more thing (not necessarily for you): > ENOBUFS is probably more adequate here. This error should never happen. If it happens, the caller need to be fixed. > Cheers, > Jarek P. Note that there are various other things that are puzzling in this function. The internal object name and the symlinks are changed even if the kcore rename returns an error. That does not seem right. But, this is separate from this patch... 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/
[PATCH] kthread: export park/unpark facility
Hi,
The kthread park/unpark facility is not used in the kernel, so
one would assume that it's made for kernel modules. This patch should
definitely help most modules.
Patch untested, at your own risks...
Regards,
Jean
Signed-off-by: Jean Tourrilhes
diff -u -p linux-3.18.17/kernel/kthread.j2.c linux-3.18.17/kernel/kthread.c
--- linux-3.18.17/kernel/kthread.j2.c 2015-07-08 17:01:39.010554169 -0700
+++ linux-3.18.17/kernel/kthread.c 2015-07-08 17:09:13.016096189 -0700
@@ -97,6 +97,7 @@ bool kthread_should_park(void)
{
return test_bit(KTHREAD_SHOULD_PARK, &to_kthread(current)->flags);
}
+EXPORT_SYMBOL(kthread_should_park);
/**
* kthread_freezable_should_stop - should this freezable kthread return now?
@@ -171,6 +172,7 @@ void kthread_parkme(void)
{
__kthread_parkme(to_kthread(current));
}
+EXPORT_SYMBOL(kthread_parkme);
static int kthread(void *_create)
{
@@ -411,6 +413,7 @@ void kthread_unpark(struct task_struct *
if (kthread)
__kthread_unpark(k, kthread);
}
+EXPORT_SYMBOL(kthread_unpark);
/**
* kthread_park - park a thread created by kthread_create().
@@ -441,6 +444,7 @@ int kthread_park(struct task_struct *k)
}
return ret;
}
+EXPORT_SYMBOL(kthread_park);
/**
* kthread_stop - stop a thread created by kthread_create().
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kthread: export park/unpark facility
On Wed, Jul 08, 2015 at 11:23:41PM -0400, Peter Hurley wrote: > On 07/08/2015 08:40 PM, Jean Tourrilhes wrote: > > Hi, > > > > The kthread park/unpark facility is not used in the kernel > > kernel/smpboot.c ? Got me, I should have said hardly used. Sorry for the gross exageration ;-) Jean -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kthread: export park/unpark facility
On Thu, Jul 09, 2015 at 10:05:02AM +0200, Thomas Gleixner wrote: > > > This patch should definitely help most modules. > > And how exactly would this help modules? Putting kthread to sleep and waking them up later is slightly tricky : http://www.linuxjournal.com/article/8144 The park and unpark API encapsulate this functionality in a pretty nice and clean API, and avoid duplicating this code in various modules. I'm all for sharing the joy ;-) > Thanks, > > tglx Regards, Jean -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kthread: export park/unpark facility
On Thu, Jul 09, 2015 at 06:49:21PM +0200, Thomas Gleixner wrote: > > If you can come up with a proper use case, i.e. patch for a module, > then we can certainly talk about the exports. But without a user it > does not make any sense. My module is currently out of the tree, so obviously it does not count. Regards, Jean -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Possible race in nsc-ircc.ko
On Fri, Aug 25, 2017 at 05:05:25PM +0300, Anton Volkov wrote: > Hello. > > While searching for races in the Linux kernel I've come across > "drivers/net/irda/nsc-ircc.ko" module. Here is a question that I came up > with while analyzing results. Lines are given using the info from Linux > v4.12. > > Consider the following case: > > Thread 1: Thread 2: > nsc_ircc_init > ->nsc_ircc_open > self = netdev_priv(dev) > register_netdev(dev) > nsc_ircc_net_ioctl > ->nsc_ircc_change_speed > self->dongle_id = ... io.dongle_id> > (nsc-ircc.c: line 485) (nsc-ircc.c: line 1318) > platform_device_register_simple > > Before the initialization of self->dongle_id in msc_ircc_open() its value is > 0. Thus if read access to its value in nsc_ircc_change_speed occurs before > the initialization there will be an attempt to change speed of dongle with > undesired id (if the dongle with id 0 exists). Is this case feasible from > your point of view? > > Thank you for your time. > > -- Anton Volkov A first glance, that seems like a valid race. I'm not sure if there is a netdev lock/status to protect the driver, because it looks like doing any operation on a device before "open" has completed would be dangerous for most drivers. I don't have time to check the code paths, as I have not looked at that code in ages. Good luck ! Jean
