Something similar to inotify in 2.4.
Hi all, Can anyone advice whether there is something similar to inotify in 2.4 kernel? Need efficient way to track file system changes. Maybe some other tools, approaches under 2.4? TIA, Vitaliy - 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/
Something similar to inotify in 2.4.
Hi all, Can anyone advice whether there is something similar to inotify in 2.4 kernel? Need efficient way to track file system changes. Maybe some other tools, approaches under 2.4? TIA, Vitaliy - 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.4 patch] Port of adutux driver from 2.6 kernel to 2.4.
Willy, On 11/4/07, Willy Tarreau <[EMAIL PROTECTED]> wrote: > I'm planning on issuing a new 2.4.36 prerelease soon. Have you made any > progress on your code after Pete's recommendations ? Yep. We just finalized 2.6 changes and now I'm working on 2.4 version. Will get back to you all soon. When are you plan to make prerelease? As always I'm too busy on my regular work and will try to put more time to this. Thanks, Vitaliy - 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.4 patch] Port of adutux driver from 2.6 kernel to 2.4.
Willy, On 11/4/07, Willy Tarreau [EMAIL PROTECTED] wrote: I'm planning on issuing a new 2.4.36 prerelease soon. Have you made any progress on your code after Pete's recommendations ? Yep. We just finalized 2.6 changes and now I'm working on 2.4 version. Will get back to you all soon. When are you plan to make prerelease? As always I'm too busy on my regular work and will try to put more time to this. Thanks, Vitaliy - 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: fixing usb-midi device support
David, On 10/31/07, David Griffith <[EMAIL PROTECTED]> wrote: > > I have a MOTU Fastlane and an Emu Xmidi 2x2 USB midi interfaces. The Emu > unit works fine with current kernels. The MOTU unit won't work with > kernels newer than 2.6.17. I stumbled over a patch that had something to > do with a MOTU Fastlane, but I haven't been able to find it again. Could > I get some advice on fixing MOTU Fastlane support? I can see that you already had a discussion on this issue: http://lkml.org/lkml/2007/8/10/102 Any results? Do you still can see the oops? Vitaliy - 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: USB: FIx locks and urb->status in adutux
On Thu, 2007-11-01 at 00:01, Pete Zaitcev wrote: > Sorry about that. I'll try to be more explicit in the future. OK, got it. Thanks. > > I just tried the latest patch and all seems to be good. > > BTW, slab corruption issue that I saw on the original driver we started > > fixing on is not an issue any more. > > Very well, I'll post this for Greg anew today. Great, tnx. > Do you still want to go ahead with a 2.4 backport? Yep. Will do it asap. In latest 2.4 patch we had just a locks issue. So do you think I should modify 2.4 patch with all modifications we done in 2.6 version included? Vitaliy - 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: USB: FIx locks and urb-status in adutux
On Thu, 2007-11-01 at 00:01, Pete Zaitcev wrote: Sorry about that. I'll try to be more explicit in the future. OK, got it. Thanks. I just tried the latest patch and all seems to be good. BTW, slab corruption issue that I saw on the original driver we started fixing on is not an issue any more. Very well, I'll post this for Greg anew today. Great, tnx. Do you still want to go ahead with a 2.4 backport? Yep. Will do it asap. In latest 2.4 patch we had just a locks issue. So do you think I should modify 2.4 patch with all modifications we done in 2.6 version included? Vitaliy - 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: fixing usb-midi device support
David, On 10/31/07, David Griffith [EMAIL PROTECTED] wrote: I have a MOTU Fastlane and an Emu Xmidi 2x2 USB midi interfaces. The Emu unit works fine with current kernels. The MOTU unit won't work with kernels newer than 2.6.17. I stumbled over a patch that had something to do with a MOTU Fastlane, but I haven't been able to find it again. Could I get some advice on fixing MOTU Fastlane support? I can see that you already had a discussion on this issue: http://lkml.org/lkml/2007/8/10/102 Any results? Do you still can see the oops? Vitaliy - 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: USB: FIx locks and urb->status in adutux
On Tue, 2007-10-30 at 23:54, Pete Zaitcev wrote: > One other small thing. I see you dropped the dev->mtx bracket that > I added around the initialization and submission. Notice that the > dev->udev is zeroed under dev->mtx, not the static lock. This is because > it has to be seen in read and write paths. If you don't like taking > across the submission, how about testing for it ahead of time? I thought it can be managed under static lock. But if you sure we can leave device lock too, I'm not familiar with all this on such deep level... at least for now;). I'm not sure what kind of testing do you mean by "ahead of time". I just tried the latest patch and all seems to be good. BTW, slab corruption issue that I saw on the original driver we started fixing on is not an issue any more. Vitaliy - 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: USB: FIx locks and urb-status in adutux
On Tue, 2007-10-30 at 23:54, Pete Zaitcev wrote: One other small thing. I see you dropped the dev-mtx bracket that I added around the initialization and submission. Notice that the dev-udev is zeroed under dev-mtx, not the static lock. This is because it has to be seen in read and write paths. If you don't like taking across the submission, how about testing for it ahead of time? I thought it can be managed under static lock. But if you sure we can leave device lock too, I'm not familiar with all this on such deep level... at least for now;). I'm not sure what kind of testing do you mean by ahead of time. I just tried the latest patch and all seems to be good. BTW, slab corruption issue that I saw on the original driver we started fixing on is not an issue any more. Vitaliy - 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.24-rc1: usb problem?
On 10/30/07, Oliver Neukum <[EMAIL PROTECTED]> wrote: > Am Dienstag 30 Oktober 2007 schrieb Harald Dunkel: > > Is this anything to worry about? Please mail if I can help to track this > > down. > > This is a known problem. A fix is in the queue. Here is original thread: http://lkml.org/lkml/2007/10/14/81 -- Vitaliy - 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: USB: FIx locks and urb->status in adutux
On Tue, 2007-10-30 at 06:24, Pete Zaitcev wrote:
> However, this looks wrong:
>
> > +dev->interrupt_in_endpoint->bInterval);
> > + dev->read_urb_finished = 0;
> > + retval = usb_submit_urb(dev->interrupt_in_urb, GFP_KERNEL);
> > + /* we ignore failure */
> > + /* end of fixup for first read */
> > +
> > + /* initialize out direction */
> > + dev->out_urb_finished = 1;
>
> The finished flag is only set when URB is not in use anymore. Did you
> observe an anomaly with my code? Any hangs? If so, I assure you this
> is not the fix. As it's written, even if we ignore the failure (e.g.
> do not pass it to userland), we sill have to maintain the correct
> flag state.
As about read_urb_finished probably it's OK. But we shouldn't decrease
open_count in the case of error as then we return normal exit value.
Here is what we had before:
dev->interrupt_in_endpoint->bInterval);
dev->read_urb_finished = 0;
retval = usb_submit_urb(dev->interrupt_in_urb, GFP_KERNEL);
if (retval) {
dev->read_urb_finished = 1;
--dev->open_count;
}
So I can left it but w/o this line:
--dev->open_count;
What is more critical is that I added:
/* initialize out direction */
dev->out_urb_finished = 1;
Without this we'll always have write timeouts.
Vitaliy
-
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: USB: FIx locks and urb-status in adutux
On Tue, 2007-10-30 at 06:24, Pete Zaitcev wrote:
However, this looks wrong:
+dev-interrupt_in_endpoint-bInterval);
+ dev-read_urb_finished = 0;
+ retval = usb_submit_urb(dev-interrupt_in_urb, GFP_KERNEL);
+ /* we ignore failure */
+ /* end of fixup for first read */
+
+ /* initialize out direction */
+ dev-out_urb_finished = 1;
The finished flag is only set when URB is not in use anymore. Did you
observe an anomaly with my code? Any hangs? If so, I assure you this
is not the fix. As it's written, even if we ignore the failure (e.g.
do not pass it to userland), we sill have to maintain the correct
flag state.
As about read_urb_finished probably it's OK. But we shouldn't decrease
open_count in the case of error as then we return normal exit value.
Here is what we had before:
dev-interrupt_in_endpoint-bInterval);
dev-read_urb_finished = 0;
retval = usb_submit_urb(dev-interrupt_in_urb, GFP_KERNEL);
if (retval) {
dev-read_urb_finished = 1;
--dev-open_count;
}
So I can left it but w/o this line:
--dev-open_count;
What is more critical is that I added:
/* initialize out direction */
dev-out_urb_finished = 1;
Without this we'll always have write timeouts.
Vitaliy
-
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.24-rc1: usb problem?
On 10/30/07, Oliver Neukum [EMAIL PROTECTED] wrote: Am Dienstag 30 Oktober 2007 schrieb Harald Dunkel: Is this anything to worry about? Please mail if I can help to track this down. This is a known problem. A fix is in the queue. Here is original thread: http://lkml.org/lkml/2007/10/14/81 -- Vitaliy - 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: USB: FIx locks and urb->status in adutux
Finally had a time on my weekend to perform tests and fix Pete's patch a
little. Now it seems to be correct.
Added a few changes:
1. One device per user space application. Old driver allowed many users
application to work with same device which can lead to IO mess.
2. GFP_KERNEL is used instead of GFP_ATOMIC as we are now out of spin locks.
3. Added myself to maintainers(already discussed this in 2.4). Does anyone mind?
(Diff between this latest patch and the one from Pete is in attach).
Also part of Pete's notes:
Two main issues fixed here are:
- An improper use of in-struct lock to protect an open count
- Use of urb status for -EINPROGRESS
Also, along the way:
- Change usb_unlink_urb to usb_kill_urb. Apparently there's no need
to use usb_unlink_urb whatsoever in this driver, and the old use of
usb_kill_urb was outright racy (it unlinked and immediately freed).
- Fix indentation in adu_write. Looks like it was damaged by a script.
- Remove sleep_on.
Here is the final patch. Comments are welcomed.
--
Signed-off-by: Pete Zaitcev <[EMAIL PROTECTED]>
Signed-off-by: Vitaliy Ivanov <[EMAIL PROTECTED]>
Tested-by: Vitaliy Ivanov <[EMAIL PROTECTED]>
--
diff -uprN -X linux-2.6.24-rc1.org/Documentation/dontdiff
linux-2.6.24-rc1.org/drivers/usb/misc/adutux.c
linux-2.6.24-rc1.my/drivers/usb/misc/adutux.c
--- linux-2.6.24-rc1.org/drivers/usb/misc/adutux.c 2007-10-29
19:25:00.0 +0200
+++ linux-2.6.24-rc1.my/drivers/usb/misc/adutux.c 2007-10-29
19:01:10.0 +0200
@@ -79,12 +79,22 @@ MODULE_DEVICE_TABLE(usb, device_table);
#define COMMAND_TIMEOUT(2*HZ) /* 60 second timeout for a command */
+/*
+ * The locking scheme is a vanilla 3-lock:
+ * adu_device.buflock: A spinlock, covers what IRQs touch.
+ * adutux_mutex: A Static lock to cover open_count. It would also cover
+ * any globals, but we don't have them in 2.6.
+ * adu_device.mtx: A mutex to hold across sleepers like copy_from_user.
+ * It covers all of adu_device, except the open_count
+ * and what .buflock covers.
+ */
+
/* Structure to hold all of our device specific stuff */
struct adu_device {
- struct mutexmtx; /* locks this structure */
+ struct mutexmtx;
struct usb_device* udev; /* save off the usb device pointer */
struct usb_interface* interface;
- unsigned char minor; /* the starting minor number for this
device */
+ unsigned intminor; /* the starting minor number for this
device */
charserial_number[8];
int open_count; /* number of times this port has
been opened */
@@ -107,8 +117,11 @@ struct adu_device {
char* interrupt_out_buffer;
struct usb_endpoint_descriptor* interrupt_out_endpoint;
struct urb* interrupt_out_urb;
+ int out_urb_finished;
};
+static DEFINE_MUTEX(adutux_mutex);
+
static struct usb_driver adu_driver;
static void adu_debug_data(int level, const char *function, int size,
@@ -132,27 +145,31 @@ static void adu_debug_data(int level, co
*/
static void adu_abort_transfers(struct adu_device *dev)
{
- dbg(2," %s : enter", __FUNCTION__);
+ unsigned long flags;
- if (dev == NULL) {
- dbg(1," %s : dev is null", __FUNCTION__);
- goto exit;
- }
+ dbg(2," %s : enter", __FUNCTION__);
if (dev->udev == NULL) {
dbg(1," %s : udev is null", __FUNCTION__);
goto exit;
}
- dbg(2," %s : udev state %d", __FUNCTION__, dev->udev->state);
- if (dev->udev->state == USB_STATE_NOTATTACHED) {
- dbg(1," %s : udev is not attached", __FUNCTION__);
- goto exit;
- }
-
/* shutdown transfer */
- usb_unlink_urb(dev->interrupt_in_urb);
- usb_unlink_urb(dev->interrupt_out_urb);
+
+ /* XXX Anchor these instead */
+ spin_lock_irqsave(>buflock, flags);
+ if (!dev->read_urb_finished) {
+ spin_unlock_irqrestore(>buflock, flags);
+ usb_kill_urb(dev->interrupt_in_urb);
+ } else
+ spin_unlock_irqrestore(>buflock, flags);
+
+ spin_lock_irqsave(>buflock, flags);
+ if (!dev->out_urb_finished) {
+ spin_unlock_irqrestore(>buflock, flags);
+ usb_kill_urb(dev->interrupt_out_urb);
+ } else
+ spin_unlock_irqrestore(>buflock, flags);
exit:
dbg(2," %s : leave", __FUNCTION__);
@@ -162,8 +179,6 @@ static void adu_delete(struct adu_device
{
dbg(2, "%s enter", __FUNCTION__);
- adu_abort_transfers(dev);
-
/* free data structures */
Re: USB: FIx locks and urb-status in adutux
Finally had a time on my weekend to perform tests and fix Pete's patch a
little. Now it seems to be correct.
Added a few changes:
1. One device per user space application. Old driver allowed many users
application to work with same device which can lead to IO mess.
2. GFP_KERNEL is used instead of GFP_ATOMIC as we are now out of spin locks.
3. Added myself to maintainers(already discussed this in 2.4). Does anyone mind?
(Diff between this latest patch and the one from Pete is in attach).
Also part of Pete's notes:
Two main issues fixed here are:
- An improper use of in-struct lock to protect an open count
- Use of urb status for -EINPROGRESS
Also, along the way:
- Change usb_unlink_urb to usb_kill_urb. Apparently there's no need
to use usb_unlink_urb whatsoever in this driver, and the old use of
usb_kill_urb was outright racy (it unlinked and immediately freed).
- Fix indentation in adu_write. Looks like it was damaged by a script.
- Remove sleep_on.
Here is the final patch. Comments are welcomed.
--
Signed-off-by: Pete Zaitcev [EMAIL PROTECTED]
Signed-off-by: Vitaliy Ivanov [EMAIL PROTECTED]
Tested-by: Vitaliy Ivanov [EMAIL PROTECTED]
--
diff -uprN -X linux-2.6.24-rc1.org/Documentation/dontdiff
linux-2.6.24-rc1.org/drivers/usb/misc/adutux.c
linux-2.6.24-rc1.my/drivers/usb/misc/adutux.c
--- linux-2.6.24-rc1.org/drivers/usb/misc/adutux.c 2007-10-29
19:25:00.0 +0200
+++ linux-2.6.24-rc1.my/drivers/usb/misc/adutux.c 2007-10-29
19:01:10.0 +0200
@@ -79,12 +79,22 @@ MODULE_DEVICE_TABLE(usb, device_table);
#define COMMAND_TIMEOUT(2*HZ) /* 60 second timeout for a command */
+/*
+ * The locking scheme is a vanilla 3-lock:
+ * adu_device.buflock: A spinlock, covers what IRQs touch.
+ * adutux_mutex: A Static lock to cover open_count. It would also cover
+ * any globals, but we don't have them in 2.6.
+ * adu_device.mtx: A mutex to hold across sleepers like copy_from_user.
+ * It covers all of adu_device, except the open_count
+ * and what .buflock covers.
+ */
+
/* Structure to hold all of our device specific stuff */
struct adu_device {
- struct mutexmtx; /* locks this structure */
+ struct mutexmtx;
struct usb_device* udev; /* save off the usb device pointer */
struct usb_interface* interface;
- unsigned char minor; /* the starting minor number for this
device */
+ unsigned intminor; /* the starting minor number for this
device */
charserial_number[8];
int open_count; /* number of times this port has
been opened */
@@ -107,8 +117,11 @@ struct adu_device {
char* interrupt_out_buffer;
struct usb_endpoint_descriptor* interrupt_out_endpoint;
struct urb* interrupt_out_urb;
+ int out_urb_finished;
};
+static DEFINE_MUTEX(adutux_mutex);
+
static struct usb_driver adu_driver;
static void adu_debug_data(int level, const char *function, int size,
@@ -132,27 +145,31 @@ static void adu_debug_data(int level, co
*/
static void adu_abort_transfers(struct adu_device *dev)
{
- dbg(2, %s : enter, __FUNCTION__);
+ unsigned long flags;
- if (dev == NULL) {
- dbg(1, %s : dev is null, __FUNCTION__);
- goto exit;
- }
+ dbg(2, %s : enter, __FUNCTION__);
if (dev-udev == NULL) {
dbg(1, %s : udev is null, __FUNCTION__);
goto exit;
}
- dbg(2, %s : udev state %d, __FUNCTION__, dev-udev-state);
- if (dev-udev-state == USB_STATE_NOTATTACHED) {
- dbg(1, %s : udev is not attached, __FUNCTION__);
- goto exit;
- }
-
/* shutdown transfer */
- usb_unlink_urb(dev-interrupt_in_urb);
- usb_unlink_urb(dev-interrupt_out_urb);
+
+ /* XXX Anchor these instead */
+ spin_lock_irqsave(dev-buflock, flags);
+ if (!dev-read_urb_finished) {
+ spin_unlock_irqrestore(dev-buflock, flags);
+ usb_kill_urb(dev-interrupt_in_urb);
+ } else
+ spin_unlock_irqrestore(dev-buflock, flags);
+
+ spin_lock_irqsave(dev-buflock, flags);
+ if (!dev-out_urb_finished) {
+ spin_unlock_irqrestore(dev-buflock, flags);
+ usb_kill_urb(dev-interrupt_out_urb);
+ } else
+ spin_unlock_irqrestore(dev-buflock, flags);
exit:
dbg(2, %s : leave, __FUNCTION__);
@@ -162,8 +179,6 @@ static void adu_delete(struct adu_device
{
dbg(2, %s enter, __FUNCTION__);
- adu_abort_transfers(dev);
-
/* free data structures */
usb_free_urb(dev-interrupt_in_urb);
usb_free_urb(dev-interrupt_out_urb);
@@ -239,7 +254,10 @@ static void adu_interrupt_out_callback(s
Re: USB: FIx locks and urb->status in adutux
Greg, On 10/25/07, Greg KH <[EMAIL PROTECTED]> wrote: > Hm, I think I'll wait for Pete and you to agree and send me a final > version before applying anything here :) I'm testing the final patch Pete created with all the notes. Will let you know if there are issues with it. If not it can be applied to your tree. Thanks, Vitaliy - 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: USB: FIx locks and urb-status in adutux
Greg, On 10/25/07, Greg KH [EMAIL PROTECTED] wrote: Hm, I think I'll wait for Pete and you to agree and send me a final version before applying anything here :) I'm testing the final patch Pete created with all the notes. Will let you know if there are issues with it. If not it can be applied to your tree. Thanks, Vitaliy - 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: USB: FIx locks and urb->status in adutux
Pete,
On Wed, 2007-10-24 at 04:53, Pete Zaitcev wrote:
1)
> +/*
> + * The locking scheme is a vanilla 3-lock:
> + * adu_device.buflock: A spinlock, covers what IRQs touch.
> + * adutux_mutex: A Static lock to cover open_count. It would also
> cover
> + * any globals, but we don't have them in 2.6.
> + * adu_device.mtx: A mutex to hold across sleepers like copy_from_user.
> + * It covers all of adu_device, except the open_count
> + * and what .buflock covers.
> + */
> static void adu_abort_transfers(struct adu_device *dev)
> {
...
> + mutex_lock(>mtx);
...
> + mutex_unlock(>mtx);
> }
Don't you think it's needed? You call adu_abort_transfers from adu_release only
where it's locked by adutux_mutex.
2)
Also one issue. adu_write has:
/* send off the urb */
usb_fill_int_urb(
dev->interrupt_out_urb,
dev->udev,
usb_sndintpipe(dev->udev,
dev->interrupt_out_endpoint->bEndpointAddress),
dev->interrupt_out_buffer,
bytes_to_write,
adu_interrupt_out_callback,
dev,
dev->interrupt_in_endpoint->bInterval);
Seems like there should be not:
dev->interrupt_in_endpoint->bInterval
but:
dev->interrupt_out_endpoint->bInterval
Typo? Seems like that.
I just tried your patch on the adutux from 2.6.24-rc1 but on my 2.6.20.7. It
failed with the following message:
-
[176188.466898] drivers/usb/misc/adutux.c : adu_open : enter
[176188.468000] drivers/usb/misc/adutux.c : adu_open : open count 1
[176188.468601] drivers/usb/misc/adutux.c : adu_open : leave, return value 0
[176188.486218] drivers/usb/misc/adutux.c : adu_interrupt_in_callback : enter,
status 0
[176188.486269] drivers/usb/misc/adutux.c: adu_interrupt_in_callback - length =
8, data = 00 00 00 00 00 00 00 00
[176188.486430] drivers/usb/misc/adutux.c: adu_interrupt_in_callback - length =
8, data = 00 00 00 00 00 00 00 00
[176188.486482] drivers/usb/misc/adutux.c : adu_interrupt_in_callback : leave,
status 0
[176191.303853] drivers/usb/misc/adutux.c : adu_write : enter, count = 8
[176193.301872] drivers/usb/misc/adutux.c : adu_write - command timed out.
[176193.301912] drivers/usb/misc/adutux.c : adu_write : leave, return value
-110
[176200.425157] drivers/usb/misc/adutux.c : adu_write : enter, count = 8
[176200.425776] list_add corruption. next->prev should be prev (c15e6c30), but
was . (next=c58bdf5c).
[176200.425776] list_add corruption. next->prev should be prev (c15e6c30), but
was . (next=c58bdf5c).
[176200.426475] [ cut here ]
[176200.426475] [ cut here ]
[176200.426536] kernel BUG at lib/list_debug.c:27!
[176200.426536] kernel BUG at lib/list_debug.c:28!
[176200.426647] invalid opcode: [#1]
[176200.426647] invalid opcode: [#1]
[176200.426736] Modules linked in: adutux(F) ppdev autofs4 hidp rfcomm l2cap
bluetooth sunrpc xt_tcpudp iptable_filter ip_tables x_tables dm_multipath video
button battery asus_acpi backlight ac ipv6 lp parport_pc parport floppy nvram
uhci_hcd sg snd_ens1371 gameport snd_rawmidi snd_ac97_codec ac97_bus
snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss
snd_mixer_oss snd_pcm pcnet32 snd_timer snd pcspkr mii soundcore i2c_piix4
i2c_core snd_page_alloc dm_snapshot dm_zero dm_mirror dm_mod ext3 jbd mptspi
scsi_transport_spi mptscsih sd_mod scsi_mod mptbase
[176200.426736] Modules linked in: adutux(F) ppdev autofs4 hidp rfcomm l2cap
bluetooth sunrpc xt_tcpudp iptable_filter ip_tables x_tables dm_multipath video
button battery asus_acpi backlight ac ipv6 lp parport_pc parport floppy nvram
uhci_hcd sg snd_ens1371 gameport snd_rawmidi snd_ac97_codec ac97_bus
snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss
snd_mixer_oss snd_pcm pcnet32 snd_timer snd pcspkr mii soundcore i2c_piix4
i2c_core snd_page_alloc dm_snapshot dm_zero dm_mirror dm_mod ext3 jbd mptspi
scsi_transport_spi mptscsih sd_mod scsi_mod mptbase
[176200.427025] CPU:0
[176200.427025] CPU:0
[176200.427027] EIP:0060:[]Tainted: GF VLI
[176200.427027] EIP:0060:[]Tainted: GF VLI
[176200.427029] EFLAGS: 00010082 (2.6.20.7 #1)
[176200.427029] EFLAGS: 00010082 (2.6.20.7 #1)
[176200.427405] EIP is at __list_add+0x29/0x60
[176200.427405] EIP is at __list_add+0x29/0x60
[176200.427448] eax: 0071 ebx: c58bdf5c ecx: c0117787 edx: d10e0ab0
[176200.427448] eax: 0071 ebx: c58bdf5c ecx: c0117787 edx: d10e0ab0
[176200.427481] esi: c15e6c08 edi: 0296 ebp: c58bded8 esp: c58bdec0
[176200.427481] esi: c15e6c08 edi: 0296 ebp: c58bded8 esp: c58bdec0
[176200.427503] ds: 007b es: 007b ss: 0068
[176200.427503] ds: 007b es: 007b ss: 0068
[176200.427532] Process aducmd (pid: 14413, ti=c58bd000 task=d10e0ab0
Re: USB: FIx locks and urb-status in adutux
Pete,
On Wed, 2007-10-24 at 04:53, Pete Zaitcev wrote:
1)
+/*
+ * The locking scheme is a vanilla 3-lock:
+ * adu_device.buflock: A spinlock, covers what IRQs touch.
+ * adutux_mutex: A Static lock to cover open_count. It would also
cover
+ * any globals, but we don't have them in 2.6.
+ * adu_device.mtx: A mutex to hold across sleepers like copy_from_user.
+ * It covers all of adu_device, except the open_count
+ * and what .buflock covers.
+ */
static void adu_abort_transfers(struct adu_device *dev)
{
...
+ mutex_lock(dev-mtx);
...
+ mutex_unlock(dev-mtx);
}
Don't you think it's needed? You call adu_abort_transfers from adu_release only
where it's locked by adutux_mutex.
2)
Also one issue. adu_write has:
/* send off the urb */
usb_fill_int_urb(
dev-interrupt_out_urb,
dev-udev,
usb_sndintpipe(dev-udev,
dev-interrupt_out_endpoint-bEndpointAddress),
dev-interrupt_out_buffer,
bytes_to_write,
adu_interrupt_out_callback,
dev,
dev-interrupt_in_endpoint-bInterval);
Seems like there should be not:
dev-interrupt_in_endpoint-bInterval
but:
dev-interrupt_out_endpoint-bInterval
Typo? Seems like that.
I just tried your patch on the adutux from 2.6.24-rc1 but on my 2.6.20.7. It
failed with the following message:
-
[176188.466898] drivers/usb/misc/adutux.c : adu_open : enter
[176188.468000] drivers/usb/misc/adutux.c : adu_open : open count 1
[176188.468601] drivers/usb/misc/adutux.c : adu_open : leave, return value 0
[176188.486218] drivers/usb/misc/adutux.c : adu_interrupt_in_callback : enter,
status 0
[176188.486269] drivers/usb/misc/adutux.c: adu_interrupt_in_callback - length =
8, data = 00 00 00 00 00 00 00 00
[176188.486430] drivers/usb/misc/adutux.c: adu_interrupt_in_callback - length =
8, data = 00 00 00 00 00 00 00 00
[176188.486482] drivers/usb/misc/adutux.c : adu_interrupt_in_callback : leave,
status 0
[176191.303853] drivers/usb/misc/adutux.c : adu_write : enter, count = 8
[176193.301872] drivers/usb/misc/adutux.c : adu_write - command timed out.
[176193.301912] drivers/usb/misc/adutux.c : adu_write : leave, return value
-110
[176200.425157] drivers/usb/misc/adutux.c : adu_write : enter, count = 8
[176200.425776] list_add corruption. next-prev should be prev (c15e6c30), but
was . (next=c58bdf5c).
[176200.425776] list_add corruption. next-prev should be prev (c15e6c30), but
was . (next=c58bdf5c).
[176200.426475] [ cut here ]
[176200.426475] [ cut here ]
[176200.426536] kernel BUG at lib/list_debug.c:27!
[176200.426536] kernel BUG at lib/list_debug.c:28!
[176200.426647] invalid opcode: [#1]
[176200.426647] invalid opcode: [#1]
[176200.426736] Modules linked in: adutux(F) ppdev autofs4 hidp rfcomm l2cap
bluetooth sunrpc xt_tcpudp iptable_filter ip_tables x_tables dm_multipath video
button battery asus_acpi backlight ac ipv6 lp parport_pc parport floppy nvram
uhci_hcd sg snd_ens1371 gameport snd_rawmidi snd_ac97_codec ac97_bus
snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss
snd_mixer_oss snd_pcm pcnet32 snd_timer snd pcspkr mii soundcore i2c_piix4
i2c_core snd_page_alloc dm_snapshot dm_zero dm_mirror dm_mod ext3 jbd mptspi
scsi_transport_spi mptscsih sd_mod scsi_mod mptbase
[176200.426736] Modules linked in: adutux(F) ppdev autofs4 hidp rfcomm l2cap
bluetooth sunrpc xt_tcpudp iptable_filter ip_tables x_tables dm_multipath video
button battery asus_acpi backlight ac ipv6 lp parport_pc parport floppy nvram
uhci_hcd sg snd_ens1371 gameport snd_rawmidi snd_ac97_codec ac97_bus
snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss
snd_mixer_oss snd_pcm pcnet32 snd_timer snd pcspkr mii soundcore i2c_piix4
i2c_core snd_page_alloc dm_snapshot dm_zero dm_mirror dm_mod ext3 jbd mptspi
scsi_transport_spi mptscsih sd_mod scsi_mod mptbase
[176200.427025] CPU:0
[176200.427025] CPU:0
[176200.427027] EIP:0060:[c01e31a2]Tainted: GF VLI
[176200.427027] EIP:0060:[c01e31a2]Tainted: GF VLI
[176200.427029] EFLAGS: 00010082 (2.6.20.7 #1)
[176200.427029] EFLAGS: 00010082 (2.6.20.7 #1)
[176200.427405] EIP is at __list_add+0x29/0x60
[176200.427405] EIP is at __list_add+0x29/0x60
[176200.427448] eax: 0071 ebx: c58bdf5c ecx: c0117787 edx: d10e0ab0
[176200.427448] eax: 0071 ebx: c58bdf5c ecx: c0117787 edx: d10e0ab0
[176200.427481] esi: c15e6c08 edi: 0296 ebp: c58bded8 esp: c58bdec0
[176200.427481] esi: c15e6c08 edi: 0296 ebp: c58bded8 esp: c58bdec0
[176200.427503] ds: 007b es: 007b ss: 0068
[176200.427503] ds: 007b es: 007b ss: 0068
[176200.427532] Process aducmd (pid: 14413, ti=c58bd000 task=d10e0ab0
Re: [2.4 patch] Port of adutux driver from 2.6 kernel to 2.4.
> > Didn't here anything on this? What is our final decision here? > > It's gotten worse, not better. Apparently, you aren't getting the > concept of protecting the open count with a static lock and my > explanations are just not vivid enough or something. So I decided > to fix it myself. Maybe then the patch in C will explain it better > than English. But I didn't have time to do it. Probably I'm not trying to do what you want. I analyzed locks for other usb drivers in 2.4 tree and used same ideas. Static lock minor_table_mutex is used for minor table structure. And dev->sem for dev manipulations and that's why for open_count. If you will simply browse /drivers/usb dir for 2.4 you will see that such approach is widely used there. What's not right? Certainly, you have more experience so I can't say that I'm right. > Also, there's an outright bug in the latest version. Your purge > of the wrong lock was incomplete and so there was an unbalanced up(). > But this is moot. Yes, got it. It's up for minor_table_mutex in adu_release. Corrected. > So, the version before the latest is borderline acceptable. If Willy > wants to take it, it's fine. I'll fix it up later together with 2.6. Let's do everything correctly for 2.4. V. - 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.4 patch] Port of adutux driver from 2.6 kernel to 2.4.
On 10/17/07, Vitaliy Ivanov <[EMAIL PROTECTED]> wrote: > Willy & Pete, > > On Tue, 2007-10-16 at 21:24, Vitaliy Ivanov wrote: > > Following Pete notes I will rework code and give it for review once again. > > As I said it's usb-skeleton approach that I reused during the port. > > > > Anyway, will get back to this soon. > > Reworked code a little. > > Issue with locks... > Now minor_table_mutex is used to protect the minor_table structure and > nothing else. > It was its first purpose. > > dev->sem is used to protect device manipulations. It's a normal practice in > 2.4. > So I leave it this way. I think it's OK, Pete? > > So the final patch, hope it's final, no?:) > > P.S. Willy all the details you asked before can be found in my previous > mail(description, device list, etc). > Hi all, Didn't here anything on this? What is our final decision here? Thanks, Vitaliy - 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.4 patch] Port of adutux driver from 2.6 kernel to 2.4.
Didn't here anything on this? What is our final decision here? It's gotten worse, not better. Apparently, you aren't getting the concept of protecting the open count with a static lock and my explanations are just not vivid enough or something. So I decided to fix it myself. Maybe then the patch in C will explain it better than English. But I didn't have time to do it. Probably I'm not trying to do what you want. I analyzed locks for other usb drivers in 2.4 tree and used same ideas. Static lock minor_table_mutex is used for minor table structure. And dev-sem for dev manipulations and that's why for open_count. If you will simply browse /drivers/usb dir for 2.4 you will see that such approach is widely used there. What's not right? Certainly, you have more experience so I can't say that I'm right. Also, there's an outright bug in the latest version. Your purge of the wrong lock was incomplete and so there was an unbalanced up(). But this is moot. Yes, got it. It's up for minor_table_mutex in adu_release. Corrected. So, the version before the latest is borderline acceptable. If Willy wants to take it, it's fine. I'll fix it up later together with 2.6. Let's do everything correctly for 2.4. V. - 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.4 patch] Port of adutux driver from 2.6 kernel to 2.4.
On 10/17/07, Vitaliy Ivanov [EMAIL PROTECTED] wrote: Willy Pete, On Tue, 2007-10-16 at 21:24, Vitaliy Ivanov wrote: Following Pete notes I will rework code and give it for review once again. As I said it's usb-skeleton approach that I reused during the port. Anyway, will get back to this soon. Reworked code a little. Issue with locks... Now minor_table_mutex is used to protect the minor_table structure and nothing else. It was its first purpose. dev-sem is used to protect device manipulations. It's a normal practice in 2.4. So I leave it this way. I think it's OK, Pete? So the final patch, hope it's final, no?:) P.S. Willy all the details you asked before can be found in my previous mail(description, device list, etc). Hi all, Didn't here anything on this? What is our final decision here? Thanks, Vitaliy - 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.4 patch] Port of adutux driver from 2.6 kernel to 2.4.
Willy & Pete,
On Tue, 2007-10-16 at 21:24, Vitaliy Ivanov wrote:
> Following Pete notes I will rework code and give it for review once again.
> As I said it's usb-skeleton approach that I reused during the port.
>
> Anyway, will get back to this soon.
Reworked code a little.
Issue with locks...
Now minor_table_mutex is used to protect the minor_table structure and nothing
else.
It was its first purpose.
dev->sem is used to protect device manipulations. It's a normal practice in 2.4.
So I leave it this way. I think it's OK, Pete?
So the final patch, hope it's final, no?:)
P.S. Willy all the details you asked before can be found in my previous
mail(description, device list, etc).
Signed-off-by: Vitaliy Ivanov <[EMAIL PROTECTED]>
Tested-by: Vitaliy Ivanov <[EMAIL PROTECTED]>
--
diff -uprN -X dontdiff linux-2.4.35.3/Documentation/Configure.help
linux-2.4.35.3.build/Documentation/Configure.help
--- linux-2.4.35.3/Documentation/Configure.help 2007-10-16 20:52:09.0
+0300
+++ linux-2.4.35.3.build/Documentation/Configure.help 2007-10-14
19:19:06.0 +0300
@@ -16123,6 +16123,17 @@ CONFIG_USB_RIO500
The module will be called rio500.o. If you want to compile it as
a module, say M here and read .
+Ontrak Control Systems ADU devices support
+CONFIG_USB_ADUTUX
+ Say Y here if you want to connect ADU 100/200 series devices to your
+ computer's USB port.
+ Details at: <http://www.ontrak.net/products.htm#Table%205>
+
+ This code is also available as a module ( = code which can be
+ inserted in and removed from the running kernel whenever you want).
+ The module will be called adutux.o. If you want to compile it as
+ a module, say M here and read .
+
Auerswald device support
CONFIG_USB_AUERSWALD
Say Y here if you want to connect an Auerswald USB ISDN Device
diff -uprN -X dontdiff linux-2.4.35.3/drivers/usb/adutux.c
linux-2.4.35.3.build/drivers/usb/adutux.c
--- linux-2.4.35.3/drivers/usb/adutux.c 1970-01-01 03:00:00.0 +0300
+++ linux-2.4.35.3.build/drivers/usb/adutux.c 2007-10-17 20:57:03.0
+0300
@@ -0,0 +1,1040 @@
+/*
+ * This is a 2.4.* kernel version of adutux driver that
+ * was originaly created by John Homppi for 2.6.* kernels.
+ *
+ * Copyright (c) 2007 Vitaliy Ivanov ([EMAIL PROTECTED])
+ *
+ * Original note:
+ *
+ * adutux - driver for ADU devices from Ontrak Control Systems
+ * This is an experimental driver. Use at your own risk.
+ * This driver is not supported by Ontrak Control Systems.
+ *
+ * Copyright (c) 2003 John Homppi (SCO, leave this notice here)
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * derived from the Lego USB Tower driver 0.56:
+ * Copyright (c) 2003 David Glance <[EMAIL PROTECTED]>
+ * 2001 Juergen Stuber <[EMAIL PROTECTED]>
+ * that was derived from USB Skeleton driver - 0.5
+ * Copyright (c) 2001 Greg Kroah-Hartman ([EMAIL PROTECTED])
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#ifdef CONFIG_USB_DEBUG
+static int debug = 5;
+#else
+static int debug = 1;
+#endif
+
+/* Use our own dbg macro */
+#undef dbg
+#define dbg(lvl, format, arg...) \
+do { \
+ if (debug >= lvl) \
+ printk(KERN_DEBUG __FILE__ " : " format " \n", ## arg); \
+} while (0)
+
+
+/* Version Information */
+#define DRIVER_VERSION "v0.0.13"
+#define DRIVER_AUTHOR "John Homppi, Vitaliy Ivanov"
+#define DRIVER_DESC "adutux (see www.ontrak.net)"
+
+/* Module parameters */
+module_param(debug, int, S_IRUGO | S_IWUSR);
+MODULE_PARM_DESC(debug, "Debug enabled or not");
+
+/* Define these values to match your device */
+#define ADU_VENDOR_ID 0x0a07
+#define ADU_PRODUCT_ID 0x0064
+
+/* table of devices that work with this driver */
+static struct usb_device_id device_table [] = {
+ { USB_DEVICE(ADU_VENDOR_ID, ADU_PRODUCT_ID) }, /* ADU100 */
+ { USB_DEVICE(ADU_VENDOR_ID, ADU_PRODUCT_ID+20) }, /* ADU120 */
+ { USB_DEVICE(ADU_VENDOR_ID, ADU_PRODUCT_ID+30) }, /* ADU130 */
+ { USB_DEVICE(ADU_VENDOR_ID, ADU_PRODUCT_ID+100) }, /* ADU200 */
+ { USB_DEVICE(ADU_VENDOR_ID, ADU_PRODUCT_ID+108) }, /* ADU208 */
+ { USB_DEVICE(ADU_VENDOR_ID, ADU_PRODUCT_ID+118) }, /* ADU218 */
+ { }/* Terminating entry */
+};
+
+MODULE_DEVICE_TABLE(usb, device_table);
+
+#define ADU_MINOR_BASE 67
+
+/* we can have up to this number of device plugged in at once */
+#define MAX_DEVICES16
+
+#define COMMAND_TIMEOUT(2*HZ) /* 6
Re: [2.4 patch] Port of adutux driver from 2.6 kernel to 2.4.
Willy Pete,
On Tue, 2007-10-16 at 21:24, Vitaliy Ivanov wrote:
Following Pete notes I will rework code and give it for review once again.
As I said it's usb-skeleton approach that I reused during the port.
Anyway, will get back to this soon.
Reworked code a little.
Issue with locks...
Now minor_table_mutex is used to protect the minor_table structure and nothing
else.
It was its first purpose.
dev-sem is used to protect device manipulations. It's a normal practice in 2.4.
So I leave it this way. I think it's OK, Pete?
So the final patch, hope it's final, no?:)
P.S. Willy all the details you asked before can be found in my previous
mail(description, device list, etc).
Signed-off-by: Vitaliy Ivanov [EMAIL PROTECTED]
Tested-by: Vitaliy Ivanov [EMAIL PROTECTED]
--
diff -uprN -X dontdiff linux-2.4.35.3/Documentation/Configure.help
linux-2.4.35.3.build/Documentation/Configure.help
--- linux-2.4.35.3/Documentation/Configure.help 2007-10-16 20:52:09.0
+0300
+++ linux-2.4.35.3.build/Documentation/Configure.help 2007-10-14
19:19:06.0 +0300
@@ -16123,6 +16123,17 @@ CONFIG_USB_RIO500
The module will be called rio500.o. If you want to compile it as
a module, say M here and read file:Documenatation/modules.txt.
+Ontrak Control Systems ADU devices support
+CONFIG_USB_ADUTUX
+ Say Y here if you want to connect ADU 100/200 series devices to your
+ computer's USB port.
+ Details at: http://www.ontrak.net/products.htm#Table%205
+
+ This code is also available as a module ( = code which can be
+ inserted in and removed from the running kernel whenever you want).
+ The module will be called adutux.o. If you want to compile it as
+ a module, say M here and read file:Documenatation/modules.txt.
+
Auerswald device support
CONFIG_USB_AUERSWALD
Say Y here if you want to connect an Auerswald USB ISDN Device
diff -uprN -X dontdiff linux-2.4.35.3/drivers/usb/adutux.c
linux-2.4.35.3.build/drivers/usb/adutux.c
--- linux-2.4.35.3/drivers/usb/adutux.c 1970-01-01 03:00:00.0 +0300
+++ linux-2.4.35.3.build/drivers/usb/adutux.c 2007-10-17 20:57:03.0
+0300
@@ -0,0 +1,1040 @@
+/*
+ * This is a 2.4.* kernel version of adutux driver that
+ * was originaly created by John Homppi for 2.6.* kernels.
+ *
+ * Copyright (c) 2007 Vitaliy Ivanov ([EMAIL PROTECTED])
+ *
+ * Original note:
+ *
+ * adutux - driver for ADU devices from Ontrak Control Systems
+ * This is an experimental driver. Use at your own risk.
+ * This driver is not supported by Ontrak Control Systems.
+ *
+ * Copyright (c) 2003 John Homppi (SCO, leave this notice here)
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * derived from the Lego USB Tower driver 0.56:
+ * Copyright (c) 2003 David Glance [EMAIL PROTECTED]
+ * 2001 Juergen Stuber [EMAIL PROTECTED]
+ * that was derived from USB Skeleton driver - 0.5
+ * Copyright (c) 2001 Greg Kroah-Hartman ([EMAIL PROTECTED])
+ *
+ */
+
+#include linux/kernel.h
+#include linux/errno.h
+#include linux/init.h
+#include linux/slab.h
+#include linux/module.h
+#include linux/moduleparam.h
+#include linux/devfs_fs_kernel.h
+#include linux/usb.h
+#include asm/uaccess.h
+
+#ifdef CONFIG_USB_DEBUG
+static int debug = 5;
+#else
+static int debug = 1;
+#endif
+
+/* Use our own dbg macro */
+#undef dbg
+#define dbg(lvl, format, arg...) \
+do { \
+ if (debug = lvl) \
+ printk(KERN_DEBUG __FILE__ : format \n, ## arg); \
+} while (0)
+
+
+/* Version Information */
+#define DRIVER_VERSION v0.0.13
+#define DRIVER_AUTHOR John Homppi, Vitaliy Ivanov
+#define DRIVER_DESC adutux (see www.ontrak.net)
+
+/* Module parameters */
+module_param(debug, int, S_IRUGO | S_IWUSR);
+MODULE_PARM_DESC(debug, Debug enabled or not);
+
+/* Define these values to match your device */
+#define ADU_VENDOR_ID 0x0a07
+#define ADU_PRODUCT_ID 0x0064
+
+/* table of devices that work with this driver */
+static struct usb_device_id device_table [] = {
+ { USB_DEVICE(ADU_VENDOR_ID, ADU_PRODUCT_ID) }, /* ADU100 */
+ { USB_DEVICE(ADU_VENDOR_ID, ADU_PRODUCT_ID+20) }, /* ADU120 */
+ { USB_DEVICE(ADU_VENDOR_ID, ADU_PRODUCT_ID+30) }, /* ADU130 */
+ { USB_DEVICE(ADU_VENDOR_ID, ADU_PRODUCT_ID+100) }, /* ADU200 */
+ { USB_DEVICE(ADU_VENDOR_ID, ADU_PRODUCT_ID+108) }, /* ADU208 */
+ { USB_DEVICE(ADU_VENDOR_ID, ADU_PRODUCT_ID+118) }, /* ADU218 */
+ { }/* Terminating entry */
+};
+
+MODULE_DEVICE_TABLE(usb, device_table);
+
+#define ADU_MINOR_BASE 67
+
+/* we can have up to this number of device plugged in at once */
+#define MAX_DEVICES16
Re: [2.4 patch] Port of adutux driver from 2.6 kernel to 2.4.
On Tue, 2007-10-16 at 18:41, Willy Tarreau wrote: > OK, I have no objection, but please apply the fixes the le16 problem as > suggested by Pete and Greg first. Also, you will probably receive more > comments, and/or criticisms from further reviews. This is normal and > expected. You just have to fix your code so that it can be merged. Done. Removed all le16_to_cpu's. Comments are OK. Just a little bit busy on my regular work. So can give responses not so quickly as you probably wanted. > > adutux is a simple Linux device driver for ADU boards from Ontrak Control > > Systems. > > The adutux driver exposes standard open/close/read/write API's to the user > > application. > > If this is going to be the commit message, please reduce lines to less > than 70 chars, and also enumerate the supportd devices and the one you > performed the tests with. It helps a lot when users encounter problems. > It's a driver description you asked for previously. Commit message should look like this probably: "Port of adutux driver from 2.6 kernel for Ontrak ADU boards." Devices list: As I said previously supported devices are: http://www.ontrak.net/products.htm#Table%205 Just to list them here: ADU100, ADU120, ADU130, ADU200, ADU208, ADU218. Testing is performed on ADU200. But command structure is identical for this devices and it is only individual command syntax that varies between different ADU devices. > Also, if you did not (I forgot to check), please ensure that the adutux > maintainer in 2.6 is CC'd. There is not maintainer for this device in 2.6. Following Pete notes I will rework code and give it for review once again. As I said it's usb-skeleton approach that I reused during the port. Anyway, will get back to this soon. Vitaliy - 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.4 patch] Port of adutux driver from 2.6 kernel to 2.4.
On Tue, 2007-10-16 at 20:56, Pete Zaitcev wrote: > On Tue, 16 Oct 2007 17:41:38 +0200, Willy Tarreau <[EMAIL PROTECTED]> wrote: > > > OK, I have no objection, but please apply the fixes the le16 problem as > > suggested by Pete and Greg first. Also, you will probably receive more > > comments, and/or criticisms from further reviews. This is normal and > > expected. You just have to fix your code so that it can be merged. > > I do not object to the driver (with byte order fixed), although it seems > written oddly... E.g. lots of trivial comments, the open count locked > by wrong lock. But I do not want to hold the 2.4 version hostage to > errors of the mainline. We should've caught them when we merged adutux > into Greg's tree. I have to admit I'm skipping reviewing a lot of 2.6. No Pete. Seems it's my changes. Actually such approach is proposed by usb-skeleton in 2.4. Will rework code to lock it correctly and clean code from trivial comments. Will back to this soon. Vitaliy - 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.4 patch] Port of adutux driver from 2.6 kernel to 2.4.
Willy,
On Mon, 2007-10-15 at 01:39, Willy Tarreau wrote:
> That's what I've seen. I can propose you something (unless someone
> else raises his hand saying "no") : you update your patch with a
> short description of what the hardware module is supposed to be used
> for, and you accept to step up as the maintainer for this backport,
> which will imply that you put your name and mail in the MAINTAINERS
> file. That way, if you're the only user, nobody will be annoyed, and
> if there are other users and some of them have problems, I don't waste
> my time on something I don't know at all. If you agree with this deal
> (which I think is fair), then I'm willing to merge your patch into
> 2.4.36-pre.
It's completely fair. I spent some time on lkml and I liked it.
I've a device and I can check/correct any issue we'll have with it(hope there
won't be any;)).
So it's OK for me to be a maintainer for this driver.
Here is final patch with all issues corrected.
Again, comments are welcomed.
Vitaliy
--
adutux is a simple Linux device driver for ADU boards from Ontrak Control
Systems.
The adutux driver exposes standard open/close/read/write API's to the user
application.
Signed-off-by: Vitaliy Ivanov <[EMAIL PROTECTED]>
Tested-by: Vitaliy Ivanov <[EMAIL PROTECTED]>
--
diff -uprN -X dontdiff KERNELS/linux-2.4.35.3/Documentation/Configure.help
linux-2.4.35.3.build/Documentation/Configure.help
--- KERNELS/linux-2.4.35.3/Documentation/Configure.help 2007-09-24
01:02:58.0 +0300
+++ linux-2.4.35.3.build/Documentation/Configure.help 2007-10-14
19:19:06.0 +0300
@@ -16123,6 +16123,17 @@ CONFIG_USB_RIO500
The module will be called rio500.o. If you want to compile it as
a module, say M here and read .
+Ontrak Control Systems ADU devices support
+CONFIG_USB_ADUTUX
+ Say Y here if you want to connect ADU 100/200 series devices to your
+ computer's USB port.
+ Details at: <http://www.ontrak.net/products.htm#Table%205>
+
+ This code is also available as a module ( = code which can be
+ inserted in and removed from the running kernel whenever you want).
+ The module will be called adutux.o. If you want to compile it as
+ a module, say M here and read .
+
Auerswald device support
CONFIG_USB_AUERSWALD
Say Y here if you want to connect an Auerswald USB ISDN Device
diff -uprN -X dontdiff KERNELS/linux-2.4.35.3/drivers/usb/adutux.c
linux-2.4.35.3.build/drivers/usb/adutux.c
--- KERNELS/linux-2.4.35.3/drivers/usb/adutux.c 1970-01-01 03:00:00.0
+0300
+++ linux-2.4.35.3.build/drivers/usb/adutux.c 2007-10-16 16:27:41.0
+0300
@@ -0,0 +1,1043 @@
+/*
+ * This is a 2.4.* kernel version of adutux driver that
+ * was originaly created by John Homppi for 2.6.* kernels.
+ *
+ * Copyright (c) 2007 Vitaliy Ivanov ([EMAIL PROTECTED])
+ *
+ * Original note:
+ *
+ * adutux - driver for ADU devices from Ontrak Control Systems
+ * This is an experimental driver. Use at your own risk.
+ * This driver is not supported by Ontrak Control Systems.
+ *
+ * Copyright (c) 2003 John Homppi (SCO, leave this notice here)
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * derived from the Lego USB Tower driver 0.56:
+ * Copyright (c) 2003 David Glance <[EMAIL PROTECTED]>
+ * 2001 Juergen Stuber <[EMAIL PROTECTED]>
+ * that was derived from USB Skeleton driver - 0.5
+ * Copyright (c) 2001 Greg Kroah-Hartman ([EMAIL PROTECTED])
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#ifdef CONFIG_USB_DEBUG
+static int debug = 5;
+#else
+static int debug = 1;
+#endif
+
+/* Use our own dbg macro */
+#undef dbg
+#define dbg(lvl, format, arg...) \
+do { \
+ if (debug >= lvl) \
+ printk(KERN_DEBUG __FILE__ " : " format " \n", ## arg); \
+} while (0)
+
+
+/* Version Information */
+#define DRIVER_VERSION "v0.0.13"
+#define DRIVER_AUTHOR "John Homppi, Vitaliy Ivanov"
+#define DRIVER_DESC "adutux (see www.ontrak.net)"
+
+/* Module parameters */
+module_param(debug, int, S_IRUGO | S_IWUSR);
+MODULE_PARM_DESC(debug, "Debug enabled or not");
+
+/* Define these values to match your device */
+#define ADU_VENDOR_ID 0x0a07
+#define ADU_PRODUCT_ID 0x0064
+
+/* table of devices that work with this driver */
+static struct usb_device_id device_table [] = {
+ { USB_DEVICE(ADU_VENDOR_ID, ADU_PRODUCT_ID) }, /* ADU100 */
+ { USB_DEVICE(ADU_VENDOR_ID, ADU_PRODUCT_ID+20) }, /* ADU120 */
+ { USB_DEV
Re: [2.4 patch] Port of adutux driver from 2.6 kernel to 2.4.
Pete,
On Mon, 2007-10-15 at 20:30, Pete Zaitcev wrote:
> > + in_end_size = le16_to_cpu(dev->interrupt_in_endpoint->wMaxPacketSize);
> > + out_end_size = le16_to_cpu(dev->interrupt_out_endpoint->wMaxPacketSize);
>
> Did you verify if this works? We use pre-swapped descriptors in 2.4.
> I suspect you allocate 256 times more memory than necessary.
Just checked. Seems to be OK. At least printk shows shows it.
>
> > +static void adu_delete(struct adu_device *dev)
> > + kfree(dev);
>
> > +static int adu_release_internal(struct adu_device *dev)
> > + if (dev->udev == NULL) {
> > + adu_delete(dev);
>
> > +static int adu_open(struct inode *inode, struct file *file)
> > + retval = adu_release_internal(dev);
> > + up(>sem);
>
> The above very clearly is a use-after-free, in case the device was
> open across a disconnect. Solution: Use minor_table_mutex to lock
> dev->open_count instead of dev->sem. There's no rule that the lock
> has to live inside the same structure with members it locks.
Yeah. You are right. Found similar issue in adu_release also.
It's a problem with 2.6 kernel driver.
So, I've got a material to create some fixes in 2.6 driver too.
I've reworked the code to avoid this issue.
Sending final patch as a reply to Willy's mail. Please check it.
Vitaliy
-
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.4 patch] Port of adutux driver from 2.6 kernel to 2.4.
Pete,
On Mon, 2007-10-15 at 20:30, Pete Zaitcev wrote:
+ in_end_size = le16_to_cpu(dev-interrupt_in_endpoint-wMaxPacketSize);
+ out_end_size = le16_to_cpu(dev-interrupt_out_endpoint-wMaxPacketSize);
Did you verify if this works? We use pre-swapped descriptors in 2.4.
I suspect you allocate 256 times more memory than necessary.
Just checked. Seems to be OK. At least printk shows shows it.
+static void adu_delete(struct adu_device *dev)
+ kfree(dev);
+static int adu_release_internal(struct adu_device *dev)
+ if (dev-udev == NULL) {
+ adu_delete(dev);
+static int adu_open(struct inode *inode, struct file *file)
+ retval = adu_release_internal(dev);
+ up(dev-sem);
The above very clearly is a use-after-free, in case the device was
open across a disconnect. Solution: Use minor_table_mutex to lock
dev-open_count instead of dev-sem. There's no rule that the lock
has to live inside the same structure with members it locks.
Yeah. You are right. Found similar issue in adu_release also.
It's a problem with 2.6 kernel driver.
So, I've got a material to create some fixes in 2.6 driver too.
I've reworked the code to avoid this issue.
Sending final patch as a reply to Willy's mail. Please check it.
Vitaliy
-
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.4 patch] Port of adutux driver from 2.6 kernel to 2.4.
Willy,
On Mon, 2007-10-15 at 01:39, Willy Tarreau wrote:
That's what I've seen. I can propose you something (unless someone
else raises his hand saying no) : you update your patch with a
short description of what the hardware module is supposed to be used
for, and you accept to step up as the maintainer for this backport,
which will imply that you put your name and mail in the MAINTAINERS
file. That way, if you're the only user, nobody will be annoyed, and
if there are other users and some of them have problems, I don't waste
my time on something I don't know at all. If you agree with this deal
(which I think is fair), then I'm willing to merge your patch into
2.4.36-pre.
It's completely fair. I spent some time on lkml and I liked it.
I've a device and I can check/correct any issue we'll have with it(hope there
won't be any;)).
So it's OK for me to be a maintainer for this driver.
Here is final patch with all issues corrected.
Again, comments are welcomed.
Vitaliy
--
adutux is a simple Linux device driver for ADU boards from Ontrak Control
Systems.
The adutux driver exposes standard open/close/read/write API's to the user
application.
Signed-off-by: Vitaliy Ivanov [EMAIL PROTECTED]
Tested-by: Vitaliy Ivanov [EMAIL PROTECTED]
--
diff -uprN -X dontdiff KERNELS/linux-2.4.35.3/Documentation/Configure.help
linux-2.4.35.3.build/Documentation/Configure.help
--- KERNELS/linux-2.4.35.3/Documentation/Configure.help 2007-09-24
01:02:58.0 +0300
+++ linux-2.4.35.3.build/Documentation/Configure.help 2007-10-14
19:19:06.0 +0300
@@ -16123,6 +16123,17 @@ CONFIG_USB_RIO500
The module will be called rio500.o. If you want to compile it as
a module, say M here and read file:Documenatation/modules.txt.
+Ontrak Control Systems ADU devices support
+CONFIG_USB_ADUTUX
+ Say Y here if you want to connect ADU 100/200 series devices to your
+ computer's USB port.
+ Details at: http://www.ontrak.net/products.htm#Table%205
+
+ This code is also available as a module ( = code which can be
+ inserted in and removed from the running kernel whenever you want).
+ The module will be called adutux.o. If you want to compile it as
+ a module, say M here and read file:Documenatation/modules.txt.
+
Auerswald device support
CONFIG_USB_AUERSWALD
Say Y here if you want to connect an Auerswald USB ISDN Device
diff -uprN -X dontdiff KERNELS/linux-2.4.35.3/drivers/usb/adutux.c
linux-2.4.35.3.build/drivers/usb/adutux.c
--- KERNELS/linux-2.4.35.3/drivers/usb/adutux.c 1970-01-01 03:00:00.0
+0300
+++ linux-2.4.35.3.build/drivers/usb/adutux.c 2007-10-16 16:27:41.0
+0300
@@ -0,0 +1,1043 @@
+/*
+ * This is a 2.4.* kernel version of adutux driver that
+ * was originaly created by John Homppi for 2.6.* kernels.
+ *
+ * Copyright (c) 2007 Vitaliy Ivanov ([EMAIL PROTECTED])
+ *
+ * Original note:
+ *
+ * adutux - driver for ADU devices from Ontrak Control Systems
+ * This is an experimental driver. Use at your own risk.
+ * This driver is not supported by Ontrak Control Systems.
+ *
+ * Copyright (c) 2003 John Homppi (SCO, leave this notice here)
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * derived from the Lego USB Tower driver 0.56:
+ * Copyright (c) 2003 David Glance [EMAIL PROTECTED]
+ * 2001 Juergen Stuber [EMAIL PROTECTED]
+ * that was derived from USB Skeleton driver - 0.5
+ * Copyright (c) 2001 Greg Kroah-Hartman ([EMAIL PROTECTED])
+ *
+ */
+
+#include linux/kernel.h
+#include linux/errno.h
+#include linux/init.h
+#include linux/slab.h
+#include linux/module.h
+#include linux/moduleparam.h
+#include linux/devfs_fs_kernel.h
+#include linux/usb.h
+#include asm/uaccess.h
+
+#ifdef CONFIG_USB_DEBUG
+static int debug = 5;
+#else
+static int debug = 1;
+#endif
+
+/* Use our own dbg macro */
+#undef dbg
+#define dbg(lvl, format, arg...) \
+do { \
+ if (debug = lvl) \
+ printk(KERN_DEBUG __FILE__ : format \n, ## arg); \
+} while (0)
+
+
+/* Version Information */
+#define DRIVER_VERSION v0.0.13
+#define DRIVER_AUTHOR John Homppi, Vitaliy Ivanov
+#define DRIVER_DESC adutux (see www.ontrak.net)
+
+/* Module parameters */
+module_param(debug, int, S_IRUGO | S_IWUSR);
+MODULE_PARM_DESC(debug, Debug enabled or not);
+
+/* Define these values to match your device */
+#define ADU_VENDOR_ID 0x0a07
+#define ADU_PRODUCT_ID 0x0064
+
+/* table of devices that work with this driver */
+static struct usb_device_id device_table [] = {
+ { USB_DEVICE(ADU_VENDOR_ID, ADU_PRODUCT_ID) }, /* ADU100 */
+ { USB_DEVICE(ADU_VENDOR_ID, ADU_PRODUCT_ID+20) }, /* ADU120
Re: [2.4 patch] Port of adutux driver from 2.6 kernel to 2.4.
On Tue, 2007-10-16 at 20:56, Pete Zaitcev wrote: On Tue, 16 Oct 2007 17:41:38 +0200, Willy Tarreau [EMAIL PROTECTED] wrote: OK, I have no objection, but please apply the fixes the le16 problem as suggested by Pete and Greg first. Also, you will probably receive more comments, and/or criticisms from further reviews. This is normal and expected. You just have to fix your code so that it can be merged. I do not object to the driver (with byte order fixed), although it seems written oddly... E.g. lots of trivial comments, the open count locked by wrong lock. But I do not want to hold the 2.4 version hostage to errors of the mainline. We should've caught them when we merged adutux into Greg's tree. I have to admit I'm skipping reviewing a lot of 2.6. No Pete. Seems it's my changes. Actually such approach is proposed by usb-skeleton in 2.4. Will rework code to lock it correctly and clean code from trivial comments. Will back to this soon. Vitaliy - 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.4 patch] Port of adutux driver from 2.6 kernel to 2.4.
On Tue, 2007-10-16 at 18:41, Willy Tarreau wrote: OK, I have no objection, but please apply the fixes the le16 problem as suggested by Pete and Greg first. Also, you will probably receive more comments, and/or criticisms from further reviews. This is normal and expected. You just have to fix your code so that it can be merged. Done. Removed all le16_to_cpu's. Comments are OK. Just a little bit busy on my regular work. So can give responses not so quickly as you probably wanted. adutux is a simple Linux device driver for ADU boards from Ontrak Control Systems. The adutux driver exposes standard open/close/read/write API's to the user application. If this is going to be the commit message, please reduce lines to less than 70 chars, and also enumerate the supportd devices and the one you performed the tests with. It helps a lot when users encounter problems. It's a driver description you asked for previously. Commit message should look like this probably: Port of adutux driver from 2.6 kernel for Ontrak ADU boards. Devices list: As I said previously supported devices are: http://www.ontrak.net/products.htm#Table%205 Just to list them here: ADU100, ADU120, ADU130, ADU200, ADU208, ADU218. Testing is performed on ADU200. But command structure is identical for this devices and it is only individual command syntax that varies between different ADU devices. Also, if you did not (I forgot to check), please ensure that the adutux maintainer in 2.6 is CC'd. There is not maintainer for this device in 2.6. Following Pete notes I will rework code and give it for review once again. As I said it's usb-skeleton approach that I reused during the port. Anyway, will get back to this soon. Vitaliy - 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.4 patch] Port of adutux driver from 2.6 kernel to 2.4.
Pete,
On 10/15/07, Pete Zaitcev <[EMAIL PROTECTED]> wrote:
> On Sun, 14 Oct 2007 23:45:36 +0300, "Vitaliy Ivanov" <[EMAIL PROTECTED]>
> wrote:
>
> > Also IMHO the more drivers are in the tree the more users will use it.
> > Once it will be merged in the mainline then it will be backported to
> > enterprise kernels and would gain wide usage.
>
> At least in case of RHEL, such backports never were automatic. In any
> case, RHEL 2.1 and 3 do not receive new drivers anymore. We only do
> bugfixes if something comes up. Realistically speaking, 2.4 kernels
> are just too old for anyone to use. So, I think it would be best for
> you to think in terms of Willy's tree only.
>
> > + in_end_size = le16_to_cpu(dev->interrupt_in_endpoint->wMaxPacketSize);
> > + out_end_size =
> > le16_to_cpu(dev->interrupt_out_endpoint->wMaxPacketSize);
>
> Did you verify if this works? We use pre-swapped descriptors in 2.4.
> I suspect you allocate 256 times more memory than necessary.
>
> > +static void adu_delete(struct adu_device *dev)
> > + kfree(dev);
>
> > +static int adu_release_internal(struct adu_device *dev)
> > + if (dev->udev == NULL) {
> > + adu_delete(dev);
>
> > +static int adu_open(struct inode *inode, struct file *file)
> > + retval = adu_release_internal(dev);
> > + up(>sem);
>
> The above very clearly is a use-after-free, in case the device was
> open across a disconnect. Solution: Use minor_table_mutex to lock
> dev->open_count instead of dev->sem. There's no rule that the lock
> has to live inside the same structure with members it locks.
Thanks for your notes. Will check and correct it asap.
Vitaliy
-
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.4 patch] Port of adutux driver from 2.6 kernel to 2.4.
Pete,
On 10/15/07, Pete Zaitcev [EMAIL PROTECTED] wrote:
On Sun, 14 Oct 2007 23:45:36 +0300, Vitaliy Ivanov [EMAIL PROTECTED]
wrote:
Also IMHO the more drivers are in the tree the more users will use it.
Once it will be merged in the mainline then it will be backported to
enterprise kernels and would gain wide usage.
At least in case of RHEL, such backports never were automatic. In any
case, RHEL 2.1 and 3 do not receive new drivers anymore. We only do
bugfixes if something comes up. Realistically speaking, 2.4 kernels
are just too old for anyone to use. So, I think it would be best for
you to think in terms of Willy's tree only.
+ in_end_size = le16_to_cpu(dev-interrupt_in_endpoint-wMaxPacketSize);
+ out_end_size =
le16_to_cpu(dev-interrupt_out_endpoint-wMaxPacketSize);
Did you verify if this works? We use pre-swapped descriptors in 2.4.
I suspect you allocate 256 times more memory than necessary.
+static void adu_delete(struct adu_device *dev)
+ kfree(dev);
+static int adu_release_internal(struct adu_device *dev)
+ if (dev-udev == NULL) {
+ adu_delete(dev);
+static int adu_open(struct inode *inode, struct file *file)
+ retval = adu_release_internal(dev);
+ up(dev-sem);
The above very clearly is a use-after-free, in case the device was
open across a disconnect. Solution: Use minor_table_mutex to lock
dev-open_count instead of dev-sem. There's no rule that the lock
has to live inside the same structure with members it locks.
Thanks for your notes. Will check and correct it asap.
Vitaliy
-
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.4 patch] Port of adutux driver from 2.6 kernel to 2.4.
Willy, On 10/14/07, Willy Tarreau <[EMAIL PROTECTED]> wrote: > Hello Vitaliy, > > On Sun, Oct 14, 2007 at 08:37:25PM +0300, Vitaliy Ivanov wrote: > > Hello Willy, Greg and list, > > > > I have ported adutux driver for ADU series device list from 2.6 to 2.4. > > More on devices: > > http://www.ontrak.net/products.htm#Table%205 > > > > Once I needed to make ADU200 work under 2.4 enterprise kernel and wasn't > > able to do this. > > My organization decided to use another device for our private purposes. > > > > I was always interested in kernel hacking and thought it's a good point to > > start it from. > > Just to add I'm not related to Ontrak in anyway. Also I'm not a Google > > person. > > Did it just for fun. > > > > A few technical notes: > > - I was trying to leave as much as possible adutux driver code from 2.6 as > > it's in the 2.6 mainline for a long time and seems like it works OK there. > > - Used one shot interrupt urbs that's why all intervals are 0. > > - Reused 67 minor number from 2.6 kernel for this device. > > - All 2.4 related changes are taken/reused from usb-skeleton. > > > > Patch is based on the latest 2.4.35.3. > > > > Performed a lot of tests but only under UHCI controller and ADU200 and all > > seems to be OK. > > > > I would like someone to perform code review as it's my first attempt to the > > kernel programming. > > Any comments, propositions are welcome. > > At first glance, your backport looks clean. I have one comment however, > about the author and version. Since it's a backport from an existing > driver and not one you wrote yourself (eventhough you did the backporting > work), the MODULE_AUTHOR should not be changed (but I think you can add > yourself to it after a comma). The version should reflect the version you > derived it from, at least for bug tracking purposes. Sounds good for me. Will correct it. > > Also, while I understand you would be very glad to get your work merged > (we all once had our first piece of code), I'd like to mention that you > seem to be the only user of this hardware under 2.4 (since it is currently > not supported). I'm not sure it's very reasonable to merge a driver in 2.4 > right now for just one user. Even more, I understand that you finally moved > to other hardware, so my feeling is that you did this work as an exercice > (which was cleanly performed, BTW), but that it will not get any real use > in 2.4. Yes, I would like it to be merged... But not just to see my name in the kernel sources. I'm the only one user of this hardware under 2.4 because it's some kind of trick to make it work under 2.4 w/o its support in the kernel. We moved to the other hardware because of our reasons and some customers can move to the other OS where this hardware will be supported. I'm sure that we're not the first who tried to make it work in 2.4. Original driver was created for 2.5 and > because interrupt out urbs were not supported in 2.4. Now it's not an issue. > > Since 2.4 is moving very slowly, there should be no problem applying > this patch to any version if you really need to use it. Maybe it would > even work with your 2.4 enterprise kernel. > > Note that I'm not radically opposed to merge support for new drivers. > If you provide us with really good arguments for a merge, maybe I'll > change my opinion, but I doubt about it, since the only users of this > device must currently be running 2.6. I'm not going to force you to do this, also I can't do this:). But after going through the recent news where Greg proposed to create drivers for companies for free it looks really reasonable. I understand that we are talking about 2.4 but if you will simply run diff for adutux of 2.4 and 2.6 you will see that changes are really trivial. Also IMHO the more drivers are in the tree the more users will use it. Once it will be merged in the mainline then it will be backported to enterprise kernels and would gain wide usage. Best, Vitaliy - 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/
[2.4 patch] Port of adutux driver from 2.6 kernel to 2.4.
Hello Willy, Greg and list,
I have ported adutux driver for ADU series device list from 2.6 to 2.4.
More on devices:
http://www.ontrak.net/products.htm#Table%205
Once I needed to make ADU200 work under 2.4 enterprise kernel and wasn't able
to do this.
My organization decided to use another device for our private purposes.
I was always interested in kernel hacking and thought it's a good point to
start it from.
Just to add I'm not related to Ontrak in anyway. Also I'm not a Google person.
Did it just for fun.
A few technical notes:
- I was trying to leave as much as possible adutux driver code from 2.6 as it's
in the 2.6 mainline for a long time and seems like it works OK there.
- Used one shot interrupt urbs that's why all intervals are 0.
- Reused 67 minor number from 2.6 kernel for this device.
- All 2.4 related changes are taken/reused from usb-skeleton.
Patch is based on the latest 2.4.35.3.
Performed a lot of tests but only under UHCI controller and ADU200 and all
seems to be OK.
I would like someone to perform code review as it's my first attempt to the
kernel programming.
Any comments, propositions are welcome.
Signed-off-by: Vitaliy Ivanov <[EMAIL PROTECTED]>
Tested-by: Vitaliy Ivanov <[EMAIL PROTECTED]>
--
diff -uprN -X dontdiff KERNELS/linux-2.4.35.3/Documentation/Configure.help
linux-2.4.35.3.build/Documentation/Configure.help
-- KERNELS/linux-2.4.35.3/Documentation/Configure.help 2007-09-24
01:02:58.0 +0300
+++ linux-2.4.35.3.build/Documentation/Configure.help 2007-10-14
19:19:06.0 +0300
@@ -16123,6 +16123,17 @@ CONFIG_USB_RIO500
The module will be called rio500.o. If you want to compile it as
a module, say M here and read .
+Ontrak Control Systems ADU devices support
+CONFIG_USB_ADUTUX
+ Say Y here if you want to connect ADU 100/200 series devices to your
+ computer's USB port.
+ Details at: <http://www.ontrak.net/products.htm#Table%205>
+
+ This code is also available as a module ( = code which can be
+ inserted in and removed from the running kernel whenever you want).
+ The module will be called adutux.o. If you want to compile it as
+ a module, say M here and read .
+
Auerswald device support
CONFIG_USB_AUERSWALD
Say Y here if you want to connect an Auerswald USB ISDN Device
diff -uprN -X dontdiff KERNELS/linux-2.4.35.3/drivers/usb/adutux.c
linux-2.4.35.3.build/drivers/usb/adutux.c
-- KERNELS/linux-2.4.35.3/drivers/usb/adutux.c 1970-01-01 03:00:00.0
+0300
+++ linux-2.4.35.3.build/drivers/usb/adutux.c 2007-10-14 19:08:59.0
+0300
@@ -0,0 +1,1035 @@
+/*
+ * This is a 2.4.* kernel version of adutux driver that
+ * was originaly created by John Homppi for 2.6.* kernels.
+ *
+ * Copyright (c) 2007 Vitaliy Ivanov ([EMAIL PROTECTED])
+ *
+ * Original note:
+ *
+ * adutux - driver for ADU devices from Ontrak Control Systems
+ * This is an experimental driver. Use at your own risk.
+ * This driver is not supported by Ontrak Control Systems.
+ *
+ * Copyright (c) 2003 John Homppi (SCO, leave this notice here)
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * derived from the Lego USB Tower driver 0.56:
+ * Copyright (c) 2003 David Glance <[EMAIL PROTECTED]>
+ * 2001 Juergen Stuber <[EMAIL PROTECTED]>
+ * that was derived from USB Skeleton driver - 0.5
+ * Copyright (c) 2001 Greg Kroah-Hartman ([EMAIL PROTECTED])
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#ifdef CONFIG_USB_DEBUG
+static int debug = 5;
+#else
+static int debug = 1;
+#endif
+
+/* Use our own dbg macro */
+#undef dbg
+#define dbg(lvl, format, arg...) \
+do { \
+ if (debug >= lvl) \
+ printk(KERN_DEBUG __FILE__ " : " format " \n", ## arg); \
+} while (0)
+
+
+/* Version Information */
+#define DRIVER_VERSION "v0.0.1"
+#define DRIVER_AUTHOR "Vitaliy Ivanov"
+#define DRIVER_DESC "adutux (see www.ontrak.net)"
+
+/* Module parameters */
+module_param(debug, int, S_IRUGO | S_IWUSR);
+MODULE_PARM_DESC(debug, "Debug enabled or not");
+
+/* Define these values to match your device */
+#define ADU_VENDOR_ID 0x0a07
+#define ADU_PRODUCT_ID 0x0064
+
+/* table of devices that work with this driver */
+static struct usb_device_id device_table [] = {
+ { USB_DEVICE(ADU_VENDOR_ID, ADU_PRODUCT_ID) }, /* ADU100 */
+ { USB_DEVICE(ADU_VENDOR_ID, ADU_PRODUCT_ID+20) }, /* ADU120 */
+ { USB_DEVICE(ADU_VENDOR_ID, ADU_PRODUCT_ID+30) }, /* ADU130 */
+ { USB_DEVICE(ADU_VENDOR_ID, AD
[2.4 patch] Port of adutux driver from 2.6 kernel to 2.4.
Hello Willy, Greg and list,
I have ported adutux driver for ADU series device list from 2.6 to 2.4.
More on devices:
http://www.ontrak.net/products.htm#Table%205
Once I needed to make ADU200 work under 2.4 enterprise kernel and wasn't able
to do this.
My organization decided to use another device for our private purposes.
I was always interested in kernel hacking and thought it's a good point to
start it from.
Just to add I'm not related to Ontrak in anyway. Also I'm not a Google person.
Did it just for fun.
A few technical notes:
- I was trying to leave as much as possible adutux driver code from 2.6 as it's
in the 2.6 mainline for a long time and seems like it works OK there.
- Used one shot interrupt urbs that's why all intervals are 0.
- Reused 67 minor number from 2.6 kernel for this device.
- All 2.4 related changes are taken/reused from usb-skeleton.
Patch is based on the latest 2.4.35.3.
Performed a lot of tests but only under UHCI controller and ADU200 and all
seems to be OK.
I would like someone to perform code review as it's my first attempt to the
kernel programming.
Any comments, propositions are welcome.
Signed-off-by: Vitaliy Ivanov [EMAIL PROTECTED]
Tested-by: Vitaliy Ivanov [EMAIL PROTECTED]
--
diff -uprN -X dontdiff KERNELS/linux-2.4.35.3/Documentation/Configure.help
linux-2.4.35.3.build/Documentation/Configure.help
-- KERNELS/linux-2.4.35.3/Documentation/Configure.help 2007-09-24
01:02:58.0 +0300
+++ linux-2.4.35.3.build/Documentation/Configure.help 2007-10-14
19:19:06.0 +0300
@@ -16123,6 +16123,17 @@ CONFIG_USB_RIO500
The module will be called rio500.o. If you want to compile it as
a module, say M here and read file:Documenatation/modules.txt.
+Ontrak Control Systems ADU devices support
+CONFIG_USB_ADUTUX
+ Say Y here if you want to connect ADU 100/200 series devices to your
+ computer's USB port.
+ Details at: http://www.ontrak.net/products.htm#Table%205
+
+ This code is also available as a module ( = code which can be
+ inserted in and removed from the running kernel whenever you want).
+ The module will be called adutux.o. If you want to compile it as
+ a module, say M here and read file:Documenatation/modules.txt.
+
Auerswald device support
CONFIG_USB_AUERSWALD
Say Y here if you want to connect an Auerswald USB ISDN Device
diff -uprN -X dontdiff KERNELS/linux-2.4.35.3/drivers/usb/adutux.c
linux-2.4.35.3.build/drivers/usb/adutux.c
-- KERNELS/linux-2.4.35.3/drivers/usb/adutux.c 1970-01-01 03:00:00.0
+0300
+++ linux-2.4.35.3.build/drivers/usb/adutux.c 2007-10-14 19:08:59.0
+0300
@@ -0,0 +1,1035 @@
+/*
+ * This is a 2.4.* kernel version of adutux driver that
+ * was originaly created by John Homppi for 2.6.* kernels.
+ *
+ * Copyright (c) 2007 Vitaliy Ivanov ([EMAIL PROTECTED])
+ *
+ * Original note:
+ *
+ * adutux - driver for ADU devices from Ontrak Control Systems
+ * This is an experimental driver. Use at your own risk.
+ * This driver is not supported by Ontrak Control Systems.
+ *
+ * Copyright (c) 2003 John Homppi (SCO, leave this notice here)
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * derived from the Lego USB Tower driver 0.56:
+ * Copyright (c) 2003 David Glance [EMAIL PROTECTED]
+ * 2001 Juergen Stuber [EMAIL PROTECTED]
+ * that was derived from USB Skeleton driver - 0.5
+ * Copyright (c) 2001 Greg Kroah-Hartman ([EMAIL PROTECTED])
+ *
+ */
+
+#include linux/kernel.h
+#include linux/errno.h
+#include linux/init.h
+#include linux/slab.h
+#include linux/module.h
+#include linux/moduleparam.h
+#include linux/devfs_fs_kernel.h
+#include linux/usb.h
+#include asm/uaccess.h
+
+#ifdef CONFIG_USB_DEBUG
+static int debug = 5;
+#else
+static int debug = 1;
+#endif
+
+/* Use our own dbg macro */
+#undef dbg
+#define dbg(lvl, format, arg...) \
+do { \
+ if (debug = lvl) \
+ printk(KERN_DEBUG __FILE__ : format \n, ## arg); \
+} while (0)
+
+
+/* Version Information */
+#define DRIVER_VERSION v0.0.1
+#define DRIVER_AUTHOR Vitaliy Ivanov
+#define DRIVER_DESC adutux (see www.ontrak.net)
+
+/* Module parameters */
+module_param(debug, int, S_IRUGO | S_IWUSR);
+MODULE_PARM_DESC(debug, Debug enabled or not);
+
+/* Define these values to match your device */
+#define ADU_VENDOR_ID 0x0a07
+#define ADU_PRODUCT_ID 0x0064
+
+/* table of devices that work with this driver */
+static struct usb_device_id device_table [] = {
+ { USB_DEVICE(ADU_VENDOR_ID, ADU_PRODUCT_ID) }, /* ADU100 */
+ { USB_DEVICE(ADU_VENDOR_ID, ADU_PRODUCT_ID+20) }, /* ADU120 */
+ { USB_DEVICE(ADU_VENDOR_ID
Re: [2.4 patch] Port of adutux driver from 2.6 kernel to 2.4.
Willy, On 10/14/07, Willy Tarreau [EMAIL PROTECTED] wrote: Hello Vitaliy, On Sun, Oct 14, 2007 at 08:37:25PM +0300, Vitaliy Ivanov wrote: Hello Willy, Greg and list, I have ported adutux driver for ADU series device list from 2.6 to 2.4. More on devices: http://www.ontrak.net/products.htm#Table%205 Once I needed to make ADU200 work under 2.4 enterprise kernel and wasn't able to do this. My organization decided to use another device for our private purposes. I was always interested in kernel hacking and thought it's a good point to start it from. Just to add I'm not related to Ontrak in anyway. Also I'm not a Google person. Did it just for fun. A few technical notes: - I was trying to leave as much as possible adutux driver code from 2.6 as it's in the 2.6 mainline for a long time and seems like it works OK there. - Used one shot interrupt urbs that's why all intervals are 0. - Reused 67 minor number from 2.6 kernel for this device. - All 2.4 related changes are taken/reused from usb-skeleton. Patch is based on the latest 2.4.35.3. Performed a lot of tests but only under UHCI controller and ADU200 and all seems to be OK. I would like someone to perform code review as it's my first attempt to the kernel programming. Any comments, propositions are welcome. At first glance, your backport looks clean. I have one comment however, about the author and version. Since it's a backport from an existing driver and not one you wrote yourself (eventhough you did the backporting work), the MODULE_AUTHOR should not be changed (but I think you can add yourself to it after a comma). The version should reflect the version you derived it from, at least for bug tracking purposes. Sounds good for me. Will correct it. Also, while I understand you would be very glad to get your work merged (we all once had our first piece of code), I'd like to mention that you seem to be the only user of this hardware under 2.4 (since it is currently not supported). I'm not sure it's very reasonable to merge a driver in 2.4 right now for just one user. Even more, I understand that you finally moved to other hardware, so my feeling is that you did this work as an exercice (which was cleanly performed, BTW), but that it will not get any real use in 2.4. Yes, I would like it to be merged... But not just to see my name in the kernel sources. I'm the only one user of this hardware under 2.4 because it's some kind of trick to make it work under 2.4 w/o its support in the kernel. We moved to the other hardware because of our reasons and some customers can move to the other OS where this hardware will be supported. I'm sure that we're not the first who tried to make it work in 2.4. Original driver was created for 2.5 and because interrupt out urbs were not supported in 2.4. Now it's not an issue. Since 2.4 is moving very slowly, there should be no problem applying this patch to any version if you really need to use it. Maybe it would even work with your 2.4 enterprise kernel. Note that I'm not radically opposed to merge support for new drivers. If you provide us with really good arguments for a merge, maybe I'll change my opinion, but I doubt about it, since the only users of this device must currently be running 2.6. I'm not going to force you to do this, also I can't do this:). But after going through the recent news where Greg proposed to create drivers for companies for free it looks really reasonable. I understand that we are talking about 2.4 but if you will simply run diff for adutux of 2.4 and 2.6 you will see that changes are really trivial. Also IMHO the more drivers are in the tree the more users will use it. Once it will be merged in the mainline then it will be backported to enterprise kernels and would gain wide usage. Best, Vitaliy - 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: Driver question: multiple instances of same char device
On 7/10/07, Jon Dufresne <[EMAIL PROTECTED]> wrote: I am relatively new to linux device development. And want to understand Linux conventions. Suppose I have a PCI card that is represented in the system by a character device. If I have two of those PCI cards in the system when the driver module loads, is it convention to have two different major numbers, or have one major number and two different minor numbers? Thanks, Jon You can start your kernel hacking way from ldd. It can be found at: http://lwn.net/Kernel/LDD3/ There are a few other books by R. Love or Greg KH that you can read. Such questions are fully covered there. Best, Vitaliy - 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: Driver question: multiple instances of same char device
On 7/10/07, Jon Dufresne [EMAIL PROTECTED] wrote: I am relatively new to linux device development. And want to understand Linux conventions. Suppose I have a PCI card that is represented in the system by a character device. If I have two of those PCI cards in the system when the driver module loads, is it convention to have two different major numbers, or have one major number and two different minor numbers? Thanks, Jon You can start your kernel hacking way from ldd. It can be found at: http://lwn.net/Kernel/LDD3/ There are a few other books by R. Love or Greg KH that you can read. Such questions are fully covered there. Best, Vitaliy - 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: USB adutux device number
Did any of USB fellows has a chance to look at this issue? It can be critical to customers as this 67 minor number is listed in the driver code only and not all of them going through the code. -- Vitaliy On 5/14/07, Vitaliy Ivanov <[EMAIL PROTECTED]> wrote: Hello, I'm not sure if it's correct place to deal with the issue. In Documentation/devices.txt there is no info about adutux driver that is included in the kernel: ... 65 = /dev/usb/usblcd USBLCD Interface ([EMAIL PROTECTED]) 66 = /dev/usb/cpad0Synaptics cPad (mouse/LCD) 96 = /dev/usb/hiddev0 1st USB HID device ... ... The driver itself includes the following (drivers/usb/misc/adutux.c): #ifdef CONFIG_USB_DYNAMIC_MINORS #define ADU_MINOR_BASE 0 #else #define ADU_MINOR_BASE 67 #endif We need to update Documentation/devices.txt with this information. The number of devices is 16. I found an old mail tread for this: http://www.uwsg.iu.edu/hypermail/linux/kernel/0609.3/2173.html But I don't see anything related to adu devices in devices.txt at all. Please let me know what is the reason of this. If needed I will create a patch for this. -- V - 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: USB adutux device number
Did any of USB fellows has a chance to look at this issue? It can be critical to customers as this 67 minor number is listed in the driver code only and not all of them going through the code. -- Vitaliy On 5/14/07, Vitaliy Ivanov [EMAIL PROTECTED] wrote: Hello, I'm not sure if it's correct place to deal with the issue. In Documentation/devices.txt there is no info about adutux driver that is included in the kernel: ... 65 = /dev/usb/usblcd USBLCD Interface ([EMAIL PROTECTED]) 66 = /dev/usb/cpad0Synaptics cPad (mouse/LCD) 96 = /dev/usb/hiddev0 1st USB HID device ... ... The driver itself includes the following (drivers/usb/misc/adutux.c): #ifdef CONFIG_USB_DYNAMIC_MINORS #define ADU_MINOR_BASE 0 #else #define ADU_MINOR_BASE 67 #endif We need to update Documentation/devices.txt with this information. The number of devices is 16. I found an old mail tread for this: http://www.uwsg.iu.edu/hypermail/linux/kernel/0609.3/2173.html But I don't see anything related to adu devices in devices.txt at all. Please let me know what is the reason of this. If needed I will create a patch for this. -- V - 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/
USB adutux device number
Hello, I'm not sure if it's correct place to deal with the issue. In Documentation/devices.txt there is no info about adutux driver that is included in the kernel: ... 65 = /dev/usb/usblcd USBLCD Interface ([EMAIL PROTECTED]) 66 = /dev/usb/cpad0Synaptics cPad (mouse/LCD) 96 = /dev/usb/hiddev0 1st USB HID device ... ... The driver itself includes the following (drivers/usb/misc/adutux.c): #ifdef CONFIG_USB_DYNAMIC_MINORS #define ADU_MINOR_BASE 0 #else #define ADU_MINOR_BASE 67 #endif We need to update Documentation/devices.txt with this information. The number of devices is 16. I found an old mail tread for this: http://www.uwsg.iu.edu/hypermail/linux/kernel/0609.3/2173.html But I don't see anything related to adu devices in devices.txt at all. Please let me know what is the reason of this. If needed I will create a patch for this. -- V - 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/
USB adutux device number
Hello, I'm not sure if it's correct place to deal with the issue. In Documentation/devices.txt there is no info about adutux driver that is included in the kernel: ... 65 = /dev/usb/usblcd USBLCD Interface ([EMAIL PROTECTED]) 66 = /dev/usb/cpad0Synaptics cPad (mouse/LCD) 96 = /dev/usb/hiddev0 1st USB HID device ... ... The driver itself includes the following (drivers/usb/misc/adutux.c): #ifdef CONFIG_USB_DYNAMIC_MINORS #define ADU_MINOR_BASE 0 #else #define ADU_MINOR_BASE 67 #endif We need to update Documentation/devices.txt with this information. The number of devices is 16. I found an old mail tread for this: http://www.uwsg.iu.edu/hypermail/linux/kernel/0609.3/2173.html But I don't see anything related to adu devices in devices.txt at all. Please let me know what is the reason of this. If needed I will create a patch for this. -- V - 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/
