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
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
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: [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 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: [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/
[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, _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/
[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 j...@hpl.hp.com
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/
[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/
[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/
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/
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: [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, >kobj);
@@ -1049,12 +1060,20 @@ int device_rename(struct device *dev, ch
sysfs_create_link(>class->subsys.kset.kobj, >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(>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 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 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 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 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/
[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(_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(_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/
[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: 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/
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/
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/
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/
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: [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: [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 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 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 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/
[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 +* length fi
[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 +* length fields. One IWEVGENIE may +* contain
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/
[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(>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(>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/
[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, >dev);
self = net->priv;
self->netdev = net;
spin_lock_init(>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] 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();
- 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] 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);
- /* Turn on in
[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] 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(>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] 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] support NSC PC8738x
ir261_nsc_38x.diff :
~~
Original patch from Steffen Pingel
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 :
~
Original patch from Iavor Fetvadjie
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 :
~~
Patch from Randy Dunlap
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 :
~
Patch from Adrian Bunk
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);
- /* Turn on interrups */
- outb(UART_IER_RLSI | UART_IER_RDI |UART_IER_THRI, iobase
[PATCH 2.6 IrDA] stir4200 turnaround calculation fix
ir261_stir_turn.diff :
Patch from John K. Luebs
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()
Patch from John K. Luebs
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() Patch from John K. Luebs o [FEATURE] Proper sysfs support Signed-off-by: John K. Luebs [EMAIL PROTECTED] Signed-off-by: Jean Tourrilhes [EMAIL PROTECTED] ir261_stir_turn.diff : Patch from John K. Luebs 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 : ~~ Patch from Randy Dunlap 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 : ~ Original patch from Iavor Fetvadjie o [FEATURE] allow IrDA socket to connect on arbitrary LSAPs Signed-off-by: Jean Tourrilhes [EMAIL PROTECTED] ir261_nsc_38x.diff : ~~ Original patch from Steffen Pingel 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 : ~ Patch from Adrian Bunk 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: [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 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] 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=110747857226852=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: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/
[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 * must be compliant
[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_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(_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] 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-flagsIFF_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 net/iw_handler.h 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
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-netdevm=110747857226852w=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/
[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 since last read *
[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_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(_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] 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-flagsIFF_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 net/iw_handler.h 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 since last read */ +#define IW_QUAL_LEVEL_UPDATED 0x2
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/
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/
[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/
[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: [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: [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 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/
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: [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/
Re: orinoco_cs & IrDA
On Tue, Apr 24, 2001 at 06:25:50PM -0700, Jean Tourrilhes wrote: > > Ok, now to the second chapter. These are all the changes > accumulated since the patch I sent one month ago (cf previous e-mail). > Changes : > o more Prism2/Symbol compatibility goodies > o Tested D-Link cards and Lucent firmware 7.28 > o Cleanup, bug fixes from David Gibson > The whole is tested, as usual... 75% of the patch was on my > web pages for the last month and people seem to have liked it. > > I've made 2 patches, one for 2.4.4-pre6 and one for > 2.4.3-ac13. The difference between the two is minor (one line). > > Linus : please have a look at orinoco_v4b.diff (first > attachement). Of course, this patch will apply and work only if you > have applied the patch in my previous e-mail. > > Alan : orinoco_v4b-alan.diff is for you (second attachement). > > Have fun... > > Jean File attached this time... Jean diff -u -p linux/drivers/net/pcmcia/wireless.25b/hermes.h linux/drivers/net/pcmcia/hermes.h --- linux/drivers/net/pcmcia/wireless.25b/hermes.h Tue Apr 24 15:57:48 2001 +++ linux/drivers/net/pcmcia/hermes.h Tue Apr 24 16:04:34 2001 @@ -35,18 +35,18 @@ /* * Limits and constants */ -#defineHERMES_ALLOC_LEN_MIN((uint16_t)4) -#defineHERMES_ALLOC_LEN_MAX((uint16_t)2400) +#defineHERMES_ALLOC_LEN_MIN(4) +#defineHERMES_ALLOC_LEN_MAX(2400) #defineHERMES_LTV_LEN_MAX (34) -#defineHERMES_BAP_DATALEN_MAX ((uint16_t)4096) -#defineHERMES_BAP_OFFSET_MAX ((uint16_t)4096) -#defineHERMES_PORTID_MAX ((uint16_t)7) -#defineHERMES_NUMPORTS_MAX ((uint16_t)(HERMES_PORTID_MAX+1)) -#defineHERMES_PDR_LEN_MAX ((uint16_t)260) /* in bytes, from EK */ -#defineHERMES_PDA_RECS_MAX ((uint16_t)200) /* a guess */ -#defineHERMES_PDA_LEN_MAX ((uint16_t)1024)/* in bytes, from EK */ -#defineHERMES_SCANRESULT_MAX ((uint16_t)35) -#defineHERMES_CHINFORESULT_MAX ((uint16_t)8) +#defineHERMES_BAP_DATALEN_MAX (4096) +#defineHERMES_BAP_OFFSET_MAX (4096) +#defineHERMES_PORTID_MAX (7) +#defineHERMES_NUMPORTS_MAX (HERMES_PORTID_MAX+1) +#defineHERMES_PDR_LEN_MAX (260) /* in bytes, from EK */ +#defineHERMES_PDA_RECS_MAX (200) /* a guess */ +#defineHERMES_PDA_LEN_MAX (1024) /* in bytes, from EK */ +#defineHERMES_SCANRESULT_MAX (35) +#defineHERMES_CHINFORESULT_MAX (8) #defineHERMES_FRAME_LEN_MAX(2304) #defineHERMES_MAX_MULTICAST(16) #defineHERMES_MAGIC(0x7d1f) @@ -86,122 +86,125 @@ /* * CMD register bitmasks */ -#defineHERMES_CMD_BUSY ((uint16_t)0x8000) -#defineHERMES_CMD_AINFO((uint16_t)0x7f00) -#defineHERMES_CMD_MACPORT ((uint16_t)0x0700) -#defineHERMES_CMD_RECL ((uint16_t)0x0100) -#defineHERMES_CMD_WRITE((uint16_t)0x0100) -#defineHERMES_CMD_PROGMODE ((uint16_t)0x0300) -#defineHERMES_CMD_CMDCODE ((uint16_t)0x003f) +#defineHERMES_CMD_BUSY (0x8000) +#defineHERMES_CMD_AINFO(0x7f00) +#defineHERMES_CMD_MACPORT (0x0700) +#defineHERMES_CMD_RECL (0x0100) +#defineHERMES_CMD_WRITE(0x0100) +#defineHERMES_CMD_PROGMODE (0x0300) +#defineHERMES_CMD_CMDCODE (0x003f) /* * STATUS register bitmasks */ -#defineHERMES_STATUS_RESULT((uint16_t)0x7f00) -#defineHERMES_STATUS_CMDCODE ((uint16_t)0x003f) +#defineHERMES_STATUS_RESULT(0x7f00) +#defineHERMES_STATUS_CMDCODE (0x003f) /* * OFFSET refister bitmasks */ -#defineHERMES_OFFSET_BUSY ((uint16_t)0x8000) -#defineHERMES_OFFSET_ERR ((uint16_t)0x4000) -#defineHERMES_OFFSET_DATAOFF ((uint16_t)0x0ffe) +#defineHERMES_OFFSET_BUSY (0x8000) +#defineHERMES_OFFSET_ERR
Re: orinoco_cs & IrDA
On Tue, Apr 24, 2001 at 03:56:37PM -0700, Jean Tourrilhes wrote: > On Tue, Apr 24, 2001 at 03:15:08PM -0700, Jean Tourrilhes wrote: > > > [...] > > Downloaded the patch again (patch-2.4.4-pre6), checked that it > > was complete, my patch is in. Oups ! Do I feel stupid... > > Let's finish this story. As indicated above, the first > fragment of the patch I sent on month ago is in the kernel. The two > other fragments didn't make it. They are attached... Ok, now to the second chapter. These are all the changes accumulated since the patch I sent one month ago (cf previous e-mail). Changes : o more Prism2/Symbol compatibility goodies o Tested D-Link cards and Lucent firmware 7.28 o Cleanup, bug fixes from David Gibson The whole is tested, as usual... 75% of the patch was on my web pages for the last month and people seem to have liked it. I've made 2 patches, one for 2.4.4-pre6 and one for 2.4.3-ac13. The difference between the two is minor (one line). Linus : please have a look at orinoco_v4b.diff (first attachement). Of course, this patch will apply and work only if you have applied the patch in my previous e-mail. Alan : orinoco_v4b-alan.diff is for you (second attachement). Have fun... Jean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: orinoco_cs & IrDA
On Tue, Apr 24, 2001 at 03:15:08PM -0700, Jean Tourrilhes wrote:
>
[...]
> Downloaded the patch again (patch-2.4.4-pre6), checked that it
> was complete, my patch is in. Oups ! Do I feel stupid...
Let's finish this story. As indicated above, the first
fragment of the patch I sent on month ago is in the kernel. The two
other fragments didn't make it. They are attached...
wireless.v11b.diff :
--
Update the various wireless LAN driver in the kernel to
version 11 (definition already in the kernel). This update is
necessary to avoid crashes in the user space utilities.
orinoco_w11.diff :
Same deal for the new orinoco_cs driver.
I've also added the retry limit setting, but this feature is
not enabled (priv->has_retry = 0).
Alan : those two are already in your last kernel, please ignore.
Linus : those are not in your kernel.
That's it...
Jean
diff -u -p linux/drivers/net/wireless.25/wavelan.c linux/drivers/net/wavelan.c
--- linux/drivers/net/wireless.25/wavelan.c Wed Mar 28 17:27:27 2001
+++ linux/drivers/net/wavelan.c Wed Mar 28 17:28:34 2001
@@ -2028,8 +2028,17 @@ static int wavelan_ioctl(struct net_devi
if (wrq->u.data.pointer != (caddr_t) 0) {
struct iw_range range;
- /* Set the length (useless: it's constant). */
+ /* Set the length (very important for backward
+* compatibility) */
wrq->u.data.length = sizeof(struct iw_range);
+
+ /* Set all the info we don't care or don't know
+* about to zero */
+ memset(, 0, sizeof(range));
+
+ /* Set the Wireless Extension versions */
+ range.we_version_compiled = WIRELESS_EXT;
+ range.we_version_source = 9;
/* Set information in the range struct. */
range.throughput = 1.6 * 1000 * 1000; /* don't argue on this
! */
diff -u -p linux/drivers/net/pcmcia/wireless.25/wavelan_cs.c
linux/drivers/net/pcmcia/wavelan_cs.c
--- linux/drivers/net/pcmcia/wireless.25/wavelan_cs.c Wed Mar 28 17:21:02 2001
+++ linux/drivers/net/pcmcia/wavelan_cs.c Wed Mar 28 17:23:19 2001
@@ -2239,8 +2239,15 @@ wavelan_ioctl(struct net_device *dev,/
{
struct iw_range range;
- /* Set the length (useless : its constant...) */
+ /* Set the length (very important for backward compatibility) */
wrq->u.data.length = sizeof(struct iw_range);
+
+ /* Set all the info we don't care or don't know about to zero */
+ memset(, 0, sizeof(range));
+
+ /* Set the Wireless Extension versions */
+ range.we_version_compiled = WIRELESS_EXT;
+ range.we_version_source = 9; /* Nothing for us in v10 and v11 */
/* Set information in the range struct */
range.throughput = 1.4 * 1000 * 1000; /* don't argue on this ! */
diff -u -p linux/drivers/net/pcmcia/wireless.25/netwave_cs.c
linux/drivers/net/pcmcia/netwave_cs.c
--- linux/drivers/net/pcmcia/wireless.25/netwave_cs.c Wed Mar 28 17:24:40 2001
+++ linux/drivers/net/pcmcia/netwave_cs.c Wed Mar 28 17:29:39 2001
@@ -710,8 +710,17 @@ static int netwave_ioctl(struct net_devi
if(wrq->u.data.pointer != (caddr_t) 0) {
struct iw_range range;
- /* Set the length (useless : its constant...) */
+ /* Set the length (very important for backward compatibility) */
wrq->u.data.length = sizeof(struct iw_range);
+
+ /* Set all the info we don't care or don't know about to zero */
+ memset(, 0, sizeof(range));
+
+#if WIRELESS_EXT > 10
+ /* Set the Wireless Extension versions */
+ range.we_version_compiled = WIRELESS_EXT;
+ range.we_version_source = 9; /* Nothing for us in v10 and v11 */
+#endif /* WIRELESS_EXT > 10 */
/* Set information in the range struct */
range.throughput = 450 * 1000; /* don't argue on this ! */
diff -u -p linux/drivers/net/pcmcia/wireless.25/ray_cs.c
linux/drivers/net/pcmcia/ray_cs.c
--- linux/drivers/net/pcmcia/wireless.25/ray_cs.c Wed Mar 28 17:21:57 2001
+++ linux/drivers/net/pcmcia/ray_cs.c Wed Mar 28 17:30:16 2001
@@ -1332,8 +1332,14 @@ static int ray_dev_ioctl(struct net_devi
struct iw_range range;
memset((char *) , 0, sizeof(struct iw_range));
- /* Set the length (useless : its constant...) */
+ /* Set the length (very important for backward compatibility) */
wrq->u.data.length = sizeof(struct iw_range);
+
+#if WIRELESS_EXT > 10
+ /* Set the Wireless Extension versions */
+ range.we_version_compiled = WIRELESS_EXT
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/
orinoco_cs & IrDA
Hi Linus, I've got a question... I would like where to send my driver patches... One month ago, I sent a small update for the orinoco_cs driver and Wireless Extensions. I didn't put all the changes I had for orinoco_cs because I believe in small incremental updates limited to a specific area (even if all the changes are trivial). You ignored my patch (without feedback), whereas Alan picked it up (if I remember correctly it was included in his 'patch-2.4.2-ac28'). So now, what should I do with the rest of my updates and the new one that have accumulated since ? Should I wait until you grab the first patch from Alan's tree ? Should I send the new patches directly to Alan so that he can accumulate a monster patch ? Should I just accumulate the patches on my web page ? Another day, I will also tell you about the IrDA patches... Have fun... Jean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
orinoco_cs IrDA
Hi Linus, I've got a question... I would like where to send my driver patches... One month ago, I sent a small update for the orinoco_cs driver and Wireless Extensions. I didn't put all the changes I had for orinoco_cs because I believe in small incremental updates limited to a specific area (even if all the changes are trivial). You ignored my patch (without feedback), whereas Alan picked it up (if I remember correctly it was included in his 'patch-2.4.2-ac28'). So now, what should I do with the rest of my updates and the new one that have accumulated since ? Should I wait until you grab the first patch from Alan's tree ? Should I send the new patches directly to Alan so that he can accumulate a monster patch ? Should I just accumulate the patches on my web page ? Another day, I will also tell you about the IrDA patches... Have fun... Jean - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: orinoco_cs IrDA
On Tue, Apr 24, 2001 at 08:47:30PM +0100, Alan Cox wrote: patch (without feedback), whereas Alan picked it up (if I remember correctly it was included in his 'patch-2.4.2-ac28'). So now, what should I do with the rest of my updates and the new one that have accumulated since ? Should I wait until you grab the first patch from Alan's tree ? Should I send the new patches directly to Alan so that he can accumulate a monster patch ? Should I just accumulate the patches on my web page ? Im happy to accumulate them but please send them to Linus too. I tend not to submit stuff on to Linus where there is an active maintainer and assume the maintainer will do it when ready. Oups ! Big mea culpa ! Apologies. While trying to compile my kernel, I've just realised the the patch I've downloaded wasn't complete. My browser cut it in the middle claiming that it was 100% complete. Downloaded the patch again (patch-2.4.4-pre6), checked that it was complete, my patch is in. Oups ! Do I feel stupid... Apologies to everybody... Sorry for the confusion... Jean - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: orinoco_cs IrDA
On Tue, Apr 24, 2001 at 03:15:08PM -0700, Jean Tourrilhes wrote:
[...]
Downloaded the patch again (patch-2.4.4-pre6), checked that it
was complete, my patch is in. Oups ! Do I feel stupid...
Let's finish this story. As indicated above, the first
fragment of the patch I sent on month ago is in the kernel. The two
other fragments didn't make it. They are attached...
wireless.v11b.diff :
--
Update the various wireless LAN driver in the kernel to
version 11 (definition already in the kernel). This update is
necessary to avoid crashes in the user space utilities.
orinoco_w11.diff :
Same deal for the new orinoco_cs driver.
I've also added the retry limit setting, but this feature is
not enabled (priv-has_retry = 0).
Alan : those two are already in your last kernel, please ignore.
Linus : those are not in your kernel.
That's it...
Jean
diff -u -p linux/drivers/net/wireless.25/wavelan.c linux/drivers/net/wavelan.c
--- linux/drivers/net/wireless.25/wavelan.c Wed Mar 28 17:27:27 2001
+++ linux/drivers/net/wavelan.c Wed Mar 28 17:28:34 2001
@@ -2028,8 +2028,17 @@ static int wavelan_ioctl(struct net_devi
if (wrq-u.data.pointer != (caddr_t) 0) {
struct iw_range range;
- /* Set the length (useless: it's constant). */
+ /* Set the length (very important for backward
+* compatibility) */
wrq-u.data.length = sizeof(struct iw_range);
+
+ /* Set all the info we don't care or don't know
+* about to zero */
+ memset(range, 0, sizeof(range));
+
+ /* Set the Wireless Extension versions */
+ range.we_version_compiled = WIRELESS_EXT;
+ range.we_version_source = 9;
/* Set information in the range struct. */
range.throughput = 1.6 * 1000 * 1000; /* don't argue on this
! */
diff -u -p linux/drivers/net/pcmcia/wireless.25/wavelan_cs.c
linux/drivers/net/pcmcia/wavelan_cs.c
--- linux/drivers/net/pcmcia/wireless.25/wavelan_cs.c Wed Mar 28 17:21:02 2001
+++ linux/drivers/net/pcmcia/wavelan_cs.c Wed Mar 28 17:23:19 2001
@@ -2239,8 +2239,15 @@ wavelan_ioctl(struct net_device *dev,/
{
struct iw_range range;
- /* Set the length (useless : its constant...) */
+ /* Set the length (very important for backward compatibility) */
wrq-u.data.length = sizeof(struct iw_range);
+
+ /* Set all the info we don't care or don't know about to zero */
+ memset(range, 0, sizeof(range));
+
+ /* Set the Wireless Extension versions */
+ range.we_version_compiled = WIRELESS_EXT;
+ range.we_version_source = 9; /* Nothing for us in v10 and v11 */
/* Set information in the range struct */
range.throughput = 1.4 * 1000 * 1000; /* don't argue on this ! */
diff -u -p linux/drivers/net/pcmcia/wireless.25/netwave_cs.c
linux/drivers/net/pcmcia/netwave_cs.c
--- linux/drivers/net/pcmcia/wireless.25/netwave_cs.c Wed Mar 28 17:24:40 2001
+++ linux/drivers/net/pcmcia/netwave_cs.c Wed Mar 28 17:29:39 2001
@@ -710,8 +710,17 @@ static int netwave_ioctl(struct net_devi
if(wrq-u.data.pointer != (caddr_t) 0) {
struct iw_range range;
- /* Set the length (useless : its constant...) */
+ /* Set the length (very important for backward compatibility) */
wrq-u.data.length = sizeof(struct iw_range);
+
+ /* Set all the info we don't care or don't know about to zero */
+ memset(range, 0, sizeof(range));
+
+#if WIRELESS_EXT 10
+ /* Set the Wireless Extension versions */
+ range.we_version_compiled = WIRELESS_EXT;
+ range.we_version_source = 9; /* Nothing for us in v10 and v11 */
+#endif /* WIRELESS_EXT 10 */
/* Set information in the range struct */
range.throughput = 450 * 1000; /* don't argue on this ! */
diff -u -p linux/drivers/net/pcmcia/wireless.25/ray_cs.c
linux/drivers/net/pcmcia/ray_cs.c
--- linux/drivers/net/pcmcia/wireless.25/ray_cs.c Wed Mar 28 17:21:57 2001
+++ linux/drivers/net/pcmcia/ray_cs.c Wed Mar 28 17:30:16 2001
@@ -1332,8 +1332,14 @@ static int ray_dev_ioctl(struct net_devi
struct iw_range range;
memset((char *) range, 0, sizeof(struct iw_range));
- /* Set the length (useless : its constant...) */
+ /* Set the length (very important for backward compatibility) */
wrq-u.data.length = sizeof(struct iw_range);
+
+#if WIRELESS_EXT 10
+ /* Set the Wireless Extension versions */
+ range.we_version_compiled = WIRELESS_EXT;
+ range.we_version_source
Re: orinoco_cs IrDA
On Tue, Apr 24, 2001 at 03:56:37PM -0700, Jean Tourrilhes wrote: On Tue, Apr 24, 2001 at 03:15:08PM -0700, Jean Tourrilhes wrote: [...] Downloaded the patch again (patch-2.4.4-pre6), checked that it was complete, my patch is in. Oups ! Do I feel stupid... Let's finish this story. As indicated above, the first fragment of the patch I sent on month ago is in the kernel. The two other fragments didn't make it. They are attached... Ok, now to the second chapter. These are all the changes accumulated since the patch I sent one month ago (cf previous e-mail). Changes : o more Prism2/Symbol compatibility goodies o Tested D-Link cards and Lucent firmware 7.28 o Cleanup, bug fixes from David Gibson The whole is tested, as usual... 75% of the patch was on my web pages for the last month and people seem to have liked it. I've made 2 patches, one for 2.4.4-pre6 and one for 2.4.3-ac13. The difference between the two is minor (one line). Linus : please have a look at orinoco_v4b.diff (first attachement). Of course, this patch will apply and work only if you have applied the patch in my previous e-mail. Alan : orinoco_v4b-alan.diff is for you (second attachement). Have fun... Jean - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: orinoco_cs IrDA
On Tue, Apr 24, 2001 at 06:25:50PM -0700, Jean Tourrilhes wrote: Ok, now to the second chapter. These are all the changes accumulated since the patch I sent one month ago (cf previous e-mail). Changes : o more Prism2/Symbol compatibility goodies o Tested D-Link cards and Lucent firmware 7.28 o Cleanup, bug fixes from David Gibson The whole is tested, as usual... 75% of the patch was on my web pages for the last month and people seem to have liked it. I've made 2 patches, one for 2.4.4-pre6 and one for 2.4.3-ac13. The difference between the two is minor (one line). Linus : please have a look at orinoco_v4b.diff (first attachement). Of course, this patch will apply and work only if you have applied the patch in my previous e-mail. Alan : orinoco_v4b-alan.diff is for you (second attachement). Have fun... Jean File attached this time... Jean diff -u -p linux/drivers/net/pcmcia/wireless.25b/hermes.h linux/drivers/net/pcmcia/hermes.h --- linux/drivers/net/pcmcia/wireless.25b/hermes.h Tue Apr 24 15:57:48 2001 +++ linux/drivers/net/pcmcia/hermes.h Tue Apr 24 16:04:34 2001 @@ -35,18 +35,18 @@ /* * Limits and constants */ -#defineHERMES_ALLOC_LEN_MIN((uint16_t)4) -#defineHERMES_ALLOC_LEN_MAX((uint16_t)2400) +#defineHERMES_ALLOC_LEN_MIN(4) +#defineHERMES_ALLOC_LEN_MAX(2400) #defineHERMES_LTV_LEN_MAX (34) -#defineHERMES_BAP_DATALEN_MAX ((uint16_t)4096) -#defineHERMES_BAP_OFFSET_MAX ((uint16_t)4096) -#defineHERMES_PORTID_MAX ((uint16_t)7) -#defineHERMES_NUMPORTS_MAX ((uint16_t)(HERMES_PORTID_MAX+1)) -#defineHERMES_PDR_LEN_MAX ((uint16_t)260) /* in bytes, from EK */ -#defineHERMES_PDA_RECS_MAX ((uint16_t)200) /* a guess */ -#defineHERMES_PDA_LEN_MAX ((uint16_t)1024)/* in bytes, from EK */ -#defineHERMES_SCANRESULT_MAX ((uint16_t)35) -#defineHERMES_CHINFORESULT_MAX ((uint16_t)8) +#defineHERMES_BAP_DATALEN_MAX (4096) +#defineHERMES_BAP_OFFSET_MAX (4096) +#defineHERMES_PORTID_MAX (7) +#defineHERMES_NUMPORTS_MAX (HERMES_PORTID_MAX+1) +#defineHERMES_PDR_LEN_MAX (260) /* in bytes, from EK */ +#defineHERMES_PDA_RECS_MAX (200) /* a guess */ +#defineHERMES_PDA_LEN_MAX (1024) /* in bytes, from EK */ +#defineHERMES_SCANRESULT_MAX (35) +#defineHERMES_CHINFORESULT_MAX (8) #defineHERMES_FRAME_LEN_MAX(2304) #defineHERMES_MAX_MULTICAST(16) #defineHERMES_MAGIC(0x7d1f) @@ -86,122 +86,125 @@ /* * CMD register bitmasks */ -#defineHERMES_CMD_BUSY ((uint16_t)0x8000) -#defineHERMES_CMD_AINFO((uint16_t)0x7f00) -#defineHERMES_CMD_MACPORT ((uint16_t)0x0700) -#defineHERMES_CMD_RECL ((uint16_t)0x0100) -#defineHERMES_CMD_WRITE((uint16_t)0x0100) -#defineHERMES_CMD_PROGMODE ((uint16_t)0x0300) -#defineHERMES_CMD_CMDCODE ((uint16_t)0x003f) +#defineHERMES_CMD_BUSY (0x8000) +#defineHERMES_CMD_AINFO(0x7f00) +#defineHERMES_CMD_MACPORT (0x0700) +#defineHERMES_CMD_RECL (0x0100) +#defineHERMES_CMD_WRITE(0x0100) +#defineHERMES_CMD_PROGMODE (0x0300) +#defineHERMES_CMD_CMDCODE (0x003f) /* * STATUS register bitmasks */ -#defineHERMES_STATUS_RESULT((uint16_t)0x7f00) -#defineHERMES_STATUS_CMDCODE ((uint16_t)0x003f) +#defineHERMES_STATUS_RESULT(0x7f00) +#defineHERMES_STATUS_CMDCODE (0x003f) /* * OFFSET refister bitmasks */ -#defineHERMES_OFFSET_BUSY ((uint16_t)0x8000) -#defineHERMES_OFFSET_ERR ((uint16_t)0x4000) -#defineHERMES_OFFSET_DATAOFF ((uint16_t)0x0ffe) +#defineHERMES_OFFSET_BUSY (0x8000) +#defineHERMES_OFFSET_ERR (0x4000) +#defineHERMES_OFFSET_DATAOFF (0x0ffe
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 Mar 28
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 Mar 28 17:28:34 2001
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/
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 (>lock, flags);
>
> if(lp == (net_local *) NULL)
> return (iw_stats *) NULL;
> wstats = >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 >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 : 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 (>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 (>lock, flags);
- if(lp == (net_local *) NULL)
-return (iw_stats *) NULL;
wstats = >wstats;
/* Get data from the mmc */
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 */
