Hi,
A few days ago I sent the enclosed bug report to the address
advertised in Documentation/rocket.txt. Till now I got no reply.
While they think about it, I decided to air the problem here, too.
In a nutshell, the rocket module doesn't deregister its devices during
removal, they stay in /sys/class/tty causing grief on reinsert and
crippling udev.
Assuming it's an easy fix, can I plea for a patch against 2.6.23? Or
is there a workaround like manually deregistering the devices?
Thanks,
Feri.
-------------------- Start of forwarded message --------------------
From: Ferenc Wagner <[email protected]>
To: [email protected]
Subject: RocketPort Linux driver errors on module reload
Date: Fri, 12 Oct 2007 00:22:17 +0200
Message-ID: <[email protected]>
Hi,
I hope I send this message to the right address...
I experience the following with the 2.09 version of the driver, as
included in vanilla Linux 2.6.23. If I insert the module, I got some
pretty normal messages, like:
RocketPort device driver module, version 2.09, 12-June-2003
ACPI: PCI Interrupt 0000:01:08.0[A] -> GSI 20 (level, low) -> IRQ 21
Comtrol PCI controller #0 ID 0x802 found in bus:slot:fn 0000:01:08.0 at address d800, 1 AIOP(s) (RocketPort UPCI 8 port w/external I/F)
Installing RocketPort UPCI 8 port w/external I/F, creating /dev/ttyR0 - 7
ACPI: PCI Interrupt 0000:02:06.0[A] -> GSI 24 (level, low) -> IRQ 22
Comtrol PCI controller #1 ID 0x802 found in bus:slot:fn 0000:02:06.0 at address c800, 1 AIOP(s) (RocketPort UPCI 8 port w/external I/F)
Installing RocketPort UPCI 8 port w/external I/F, creating /dev/ttyR8 - 15
However, if I remove the module from the kernel, and then insert it
again, lots of error messages result:
RocketPort device driver module, version 2.09, 12-June-2003
Comtrol PCI controller #0 ID 0x802 found in bus:slot:fn 0000:01:08.0 at address d800, 1 AIOP(s) (RocketPort UPCI 8 port w/external I/F)
Installing RocketPort UPCI 8 port w/external I/F, creating /dev/ttyR0 - 7
kobject_add failed for ttyR0 with -EEXIST, don't try to register things with the same name in the same directory.
[<c01ccdb4>] kobject_shadow_add+0x156/0x188
[<c01cd095>] kobject_set_name+0x2b/0x92
[<c022d022>] device_add+0x87/0x50f
[<c01cce24>] kobject_init+0x2f/0x3f
[<c022da2c>] device_create+0x77/0x97
[<c02154cb>] tty_register_device+0xb5/0xbd
[<f8a130d3>] init_r_port+0x5f1/0x623 [rocket]
[<c02409a9>] pci_read+0x29/0x2e
[<f8b74ff7>] rp_init+0xff7/0x111a [rocket]
[<c013fd38>] __link_module+0x0/0x1f
[<c01421de>] sys_init_module+0x1470/0x15a9
[<c01296a7>] __request_region+0x0/0x80
[<c0103e12>] sysenter_past_esp+0x6b/0xa1
=======================
And so on for each device.
However, the card seems to operate all right. Still, the messages
suggest something isn't quite right and could use some fixing. Hope
you can find the problem.
--
Regards,
Ferenc Wagner
-------------------- End of forwarded message --------------------
> -------------------- Start of forwarded message --------------------
> From: Ferenc Wagner <[email protected]>
> To: [email protected]
> Subject: RocketPort Linux driver errors on module reload
> Date: Fri, 12 Oct 2007 00:22:17 +0200
> Message-ID: <[email protected]>
>
> Hi,
>
> I hope I send this message to the right address...
>
> I experience the following with the 2.09 version of the driver, as
> included in vanilla Linux 2.6.23. If I insert the module, I got some
> pretty normal messages, like:
>
> RocketPort device driver module, version 2.09, 12-June-2003
> ACPI: PCI Interrupt 0000:01:08.0[A] -> GSI 20 (level, low) -> IRQ 21
> Comtrol PCI controller #0 ID 0x802 found in bus:slot:fn 0000:01:08.0 at address d800, 1 AIOP(s) (RocketPort UPCI 8 port w/external I/F)
> Installing RocketPort UPCI 8 port w/external I/F, creating /dev/ttyR0 - 7
> ACPI: PCI Interrupt 0000:02:06.0[A] -> GSI 24 (level, low) -> IRQ 22
> Comtrol PCI controller #1 ID 0x802 found in bus:slot:fn 0000:02:06.0 at address c800, 1 AIOP(s) (RocketPort UPCI 8 port w/external I/F)
> Installing RocketPort UPCI 8 port w/external I/F, creating /dev/ttyR8 - 15
>
> However, if I remove the module from the kernel, and then insert it
> again, lots of error messages result:
>
> RocketPort device driver module, version 2.09, 12-June-2003
> Comtrol PCI controller #0 ID 0x802 found in bus:slot:fn 0000:01:08.0 at address d800, 1 AIOP(s) (RocketPort UPCI 8 port w/external I/F)
> Installing RocketPort UPCI 8 port w/external I/F, creating /dev/ttyR0 - 7
> kobject_add failed for ttyR0 with -EEXIST, don't try to register things with the same name in the same directory.
> [<c01ccdb4>] kobject_shadow_add+0x156/0x188
> [<c01cd095>] kobject_set_name+0x2b/0x92
> [<c022d022>] device_add+0x87/0x50f
> [<c01cce24>] kobject_init+0x2f/0x3f
> [<c022da2c>] device_create+0x77/0x97
> [<c02154cb>] tty_register_device+0xb5/0xbd
> [<f8a130d3>] init_r_port+0x5f1/0x623 [rocket]
> [<c02409a9>] pci_read+0x29/0x2e
> [<f8b74ff7>] rp_init+0xff7/0x111a [rocket]
> [<c013fd38>] __link_module+0x0/0x1f
> [<c01421de>] sys_init_module+0x1470/0x15a9
> [<c01296a7>] __request_region+0x0/0x80
> [<c0103e12>] sysenter_past_esp+0x6b/0xa1
> =======================
> And so on for each device.
>
> However, the card seems to operate all right. Still, the messages
> suggest something isn't quite right and could use some fixing. Hope
> you can find the problem.
Could you try the attached patch below?
--
diff --git a/drivers/char/rocket.c b/drivers/char/rocket.c
index 56cbba7..94bb3d0 100644
--- a/drivers/char/rocket.c
+++ b/drivers/char/rocket.c
@@ -699,8 +699,8 @@ static void init_r_port(int board, int aiop, int chan, struct pci_dev *pci_dev)
spin_lock_init(&info->slock);
mutex_init(&info->write_mtx);
rp_table[line] = info;
- if (pci_dev)
- tty_register_device(rocket_driver, line, &pci_dev->dev);
+ tty_register_device(rocket_driver, line, pci_dev ? &pci_dev->dev :
+ NULL);
}
/*
@@ -2434,7 +2434,7 @@ static int __init rp_init(void)
rocket_driver->init_termios.c_ispeed = 9600;
rocket_driver->init_termios.c_ospeed = 9600;
#ifdef ROCKET_SOFT_FLOW
- rocket_driver->flags |= TTY_DRIVER_REAL_RAW | TTY_DRIVER_DYNAMIC_DEV;
+ rocket_driver->flags |= TTY_DRIVER_REAL_RAW;
#endif
tty_set_operations(rocket_driver, &rocket_ops);
@@ -2491,10 +2491,14 @@ static void rp_cleanup_module(void)
if (retval)
printk(KERN_INFO "Error %d while trying to unregister "
"rocketport driver\n", -retval);
- put_tty_driver(rocket_driver);
for (i = 0; i < MAX_RP_PORTS; i++)
- kfree(rp_table[i]);
+ if (rp_table[i]) {
+ tty_unregister_device(rocket_driver, i);
+ kfree(rp_table[i]);
+ }
+
+ put_tty_driver(rocket_driver);
for (i = 0; i < NUM_BOARDS; i++) {
if (rcktpt_io_addr[i] <= 0 || is_PCI[i])
Jiri Slaby <[email protected]> writes:
>> -------------------- Start of forwarded message --------------------
>> From: Ferenc Wagner <[email protected]>
>> To: [email protected]
>> Subject: RocketPort Linux driver errors on module reload
>> Date: Fri, 12 Oct 2007 00:22:17 +0200
>> Message-ID: <[email protected]>
>>
>> [...]
>> However, if I remove the module from the kernel, and then insert it
>> again, lots of error messages result:
>>
>> RocketPort device driver module, version 2.09, 12-June-2003
>> Comtrol PCI controller #0 ID 0x802 found in bus:slot:fn 0000:01:08.0 at address d800, 1 AIOP(s) (RocketPort UPCI 8 port w/external I/F)
>> Installing RocketPort UPCI 8 port w/external I/F, creating /dev/ttyR0 - 7
>> kobject_add failed for ttyR0 with -EEXIST, don't try to register things with the same name in the same directory.
>> [<c01ccdb4>] kobject_shadow_add+0x156/0x188
>> [<c01cd095>] kobject_set_name+0x2b/0x92
>> [<c022d022>] device_add+0x87/0x50f
>> [<c01cce24>] kobject_init+0x2f/0x3f
>> [<c022da2c>] device_create+0x77/0x97
>> [<c02154cb>] tty_register_device+0xb5/0xbd
>> [<f8a130d3>] init_r_port+0x5f1/0x623 [rocket]
>> [<c02409a9>] pci_read+0x29/0x2e
>> [<f8b74ff7>] rp_init+0xff7/0x111a [rocket]
>> [<c013fd38>] __link_module+0x0/0x1f
>> [<c01421de>] sys_init_module+0x1470/0x15a9
>> [<c01296a7>] __request_region+0x0/0x80
>> [<c0103e12>] sysenter_past_esp+0x6b/0xa1
>> =======================
>> And so on for each device.
>>
>> However, the card seems to operate all right. Still, the messages
>> suggest something isn't quite right and could use some fixing. Hope
>> you can find the problem.
>
> Could you try the attached patch below?
> [...]
You are the man, Jiri! That indeed fixes the problem.
Thank you very much. What a turnaround...
Shouldn't Documentation/rocket.txt also be changed? I'm not sure
whether that support email is still valid.
--
Regards,
Feri.
On 10/15/2007 02:57 PM, Ferenc Wagner wrote:
> You are the man, Jiri! That indeed fixes the problem.
> Thank you very much. What a turnaround...
You're welcome, that's why we're here.
> Shouldn't Documentation/rocket.txt also be changed? I'm not sure
> whether that support email is still valid.
And so am I. I wouldn't change it, maybe they will contact you some later ;).
Anyway the driver faces another problem with pci refcounting (it doesn't
increment the counter) and the device might be removed from it any time the pci
bus code decides. Are you willing to test to-pci-probing patches (i.e. patches
which converts the driver to the model introduced in linux 2.4)? If not, I'll
only increment the counter on modprobe and decrement it on rmmod, since it would
be a safe (in the meaning of not changing that much code) way of fixing the problem.
thanks,
--
Jiri Slaby ([email protected])
Faculty of Informatics, Masaryk University
Jiri Slaby <[email protected]> writes:
> Anyway the driver faces another problem with pci refcounting (it
> doesn't increment the counter) and the device might be removed from
> it any time the pci bus code decides.
That doesn't sound too good... Do you mean the module could stop
working any time, even if its devices are being used continuously?
> Are you willing to test to-pci-probing patches (i.e. patches which
> converts the driver to the model introduced in linux 2.4)?
Well yes. We've got a copule of such cards, which raises some
interest in a proper driver. Just send the patches with some
instructions along, or point me to a git branch if you prefer.
> If not, I'll only increment the counter on modprobe and decrement it
> on rmmod, since it would be a safe (in the meaning of not changing
> that much code) way of fixing the problem.
And what are the drawbacks of this simple solution?
--
Regards,
Feri.
On 10/16/07, Wagner Ferenc <[email protected]> wrote:
> Jiri Slaby <[email protected]> writes:
>
> > Anyway the driver faces another problem with pci refcounting (it
> > doesn't increment the counter) and the device might be removed from
> > it any time the pci bus code decides.
>
> That doesn't sound too good... Do you mean the module could stop
> working any time, even if its devices are being used continuously?
Hmm, nobody holds the reference according to the current
implementation, so the pci layer doesn't know that anybody is working
with it.
> > Are you willing to test to-pci-probing patches (i.e. patches which
> > converts the driver to the model introduced in linux 2.4)?
>
> Well yes. We've got a copule of such cards, which raises some
> interest in a proper driver. Just send the patches with some
> instructions along, or point me to a git branch if you prefer.
Maybe the git with stand-alone module would be better...
> > If not, I'll only increment the counter on modprobe and decrement it
> > on rmmod, since it would be a safe (in the meaning of not changing
> > that much code) way of fixing the problem.
>
> And what are the drawbacks of this simple solution?
Nothing, but it's not the proper way -- just a safe fallback. But you
can still say no :).
regards,
--js
>On 10/15/2007 02:57 PM, Ferenc Wagner wrote:
>> You are the man, Jiri! That indeed fixes the problem.
>> Thank you very much. What a turnaround...
>
>You're welcome, that's why we're here.
>
>> Shouldn't Documentation/rocket.txt also be changed? I'm not sure
>> whether that support email is still valid.
>
>And so am I. I wouldn't change it, maybe they will contact you some later ;).
>
Darn. I don't read the mailing list for one day and there is a Comtrol related post. ;)
Anyhow, as far as the support address, Comtrol and Comtrol UK are now separate companies. I work for Comtrol. The address you will want to send Linux related Comtrol issues to is [email protected]. You can also email me directly if you wish, as I handle Linux issues here in tech support at Comtrol. As far as changing the address in the rocket.txt file, it would be a good idea to change it to [email protected].
>Anyway the driver faces another problem with pci refcounting (it doesn't
>increment the counter) and the device might be removed from it any time the pci
>bus code decides. Are you willing to test to-pci-probing patches (i.e. patches
>which converts the driver to the model introduced in linux 2.4)? If not, I'll
>only increment the counter on modprobe and decrement it on rmmod, since it would
>be a safe (in the meaning of not changing that much code) way of fixing the problem.
>
>thanks,
>--
>Jiri Slaby ([email protected])
>Faculty of Informatics, Masaryk University
I've been wanting to get the driver that is included in the kernel up to date, and there is an active project here at comtrol to get the current code (driver version 3.08 beta) up to Linux kernel programming standards. The driver version that is included in the kernel (and has been patched a bit I'm sure since it's been in there a while) is version 2.09. The latest version (3.08 beta) can be obtained from:
ftp://ftp.comtrol.com/beta/rport/drivers/u_pci/linux/rocketport-linux-3.08.tar.gz
If anyone has any helpful pointers (no pun intended) or comments on the code, I'd love to listen.
Regards,
Nick
Nick Thompson
Technical Support Specialist [email protected]
Comtrol Corporation ftp://ftp.comtrol.com
6655 Wedgwood Rd. Ste 120 http://www.comtrol.com
Maple Grove, MN. 55311 Sales: (800)GO-ROCKET
On 10/17/2007 07:06 PM, Nick Thompson wrote:
> I've been wanting to get the driver that is included in the kernel up to date, and there is an active project here at comtrol to get the current code (driver version 3.08 beta) up to Linux kernel programming standards. The driver version that is included in the kernel (and has been patched a bit I'm sure since it's been in there a while) is version 2.09. The latest version (3.08 beta) can be obtained from:
the easiest way is to get diff -u 2.09 3.08 and port it by hand, at least I
ususally do it this way.
> ftp://ftp.comtrol.com/beta/rport/drivers/u_pci/linux/rocketport-linux-3.08.tar.gz
>
> If anyone has any helpful pointers (no pun intended) or comments on the code, I'd love to listen.
Convert to pci probing and in-kernel firmware loading :). The code is big mess
due to ifdefs and much unneeded material, it's likely impossible to say this is
wrong and this not, if you won't post a patch, where people will see the changes
you want to make. Then you will have feedback :).
regards,
--
Jiri Slaby ([email protected])
Faculty of Informatics, Masaryk University
>-----Original Message-----
>From: Jiri Slaby [mailto:[email protected]]
>Sent: Wednesday, October 17, 2007 2:35 PM
>To: Nick Thompson
>Cc: [email protected]
>Subject: Re: RocketPort Linux driver errors on module reload
>
>
>On 10/17/2007 07:06 PM, Nick Thompson wrote:
>> I've been wanting to get the driver that is included in the kernel up to date, and there >>is an active project here at comtrol to get the current code (driver version 3.08 beta) up >>to Linux kernel programming standards. The driver version that is included in the kernel >>(and has been patched a bit I'm sure since it's been in there a while)is version 2.09. The >>latest version (3.08 beta) can be obtained from:
>
>the easiest way is to get diff -u 2.09 3.08 and port it by hand, at least I
>ususally do it this way.
>
>> ftp://ftp.comtrol.com/beta/rport/drivers/u_pci/linux/rocketport-linux-3.08.tar.gz
>>
>> If anyone has any helpful pointers (no pun intended) or comments on the code, I'd love to >>listen.
>
>Convert to pci probing and in-kernel firmware loading :). The code is big mess
>due to ifdefs and much unneeded material, it's likely impossible to say this is
>wrong and this not, if you won't post a patch, where people will see the changes
>you want to make. Then you will have feedback :).
>
>regards,
>--
>Jiri Slaby ([email protected])
>Faculty of Informatics, Masaryk University
Jiri,
Thanks a lot for the feedback, it's very much appreciated. Like I said, there is an active project here at Comtrol to get 3.08 beta up to Linux kernel coding standards, once that gets somewhere near done, a patch will be forthcoming.
Thanks for taking the time to write.
Regards,
Nick
Nick Thompson
Technical Support Specialist [email protected]
Comtrol Corporation ftp://ftp.comtrol.com
6655 Wedgwood Rd. Ste 120 http://www.comtrol.com
Maple Grove, MN. 55311 Sales: (800)GO-ROCKET
"Jiri Slaby" <[email protected]> writes:
> On 10/16/07, Wagner Ferenc <[email protected]> wrote:
>
>> Jiri Slaby <[email protected]> writes:
>>
>>> Are you willing to test to-pci-probing patches (i.e. patches which
>>> converts the driver to the model introduced in linux 2.4)?
>>
>> Well yes. We've got a copule of such cards, which raises some
>> interest in a proper driver. Just send the patches with some
>> instructions along, or point me to a git branch if you prefer.
>
> Maybe the git with stand-alone module would be better...
Sorry, I don't understand this suggestion. I don't read LKML, please
don't suppose any prior knowledge of the jargon used here... Do you
mean I should use the bleeding edge git source of the kernel? Not
something I'm eager to do, but can do, actually. And would you send
me patches separately on top of that?
>>> If not, I'll only increment the counter on modprobe and decrement it
>>> on rmmod, since it would be a safe (in the meaning of not changing
>>> that much code) way of fixing the problem.
>>
>> And what are the drawbacks of this simple solution?
>
> Nothing, but it's not the proper way -- just a safe fallback. But you
> can still say no :).
I expected an improper way to have some disadvantages at least. :)
Anyway, I can tolerate some glitches during the porting of this
module, resulting in interruptions of the serial devices, but leaving
the rest of the system mostly stable; it's a production system after
all. If the changes are more threatening, I'll use another system for
the tests. In short: suggest a method and let's give a chance for the
proper solution. Just please enclose some risk assessment.
--
Regards,
Feri.
On 10/18/2007 11:53 PM, Ferenc Wagner wrote:
> "Jiri Slaby" <[email protected]> writes:
>
>> On 10/16/07, Wagner Ferenc <[email protected]> wrote:
>>
>>> Jiri Slaby <[email protected]> writes:
>>>
>>>> Are you willing to test to-pci-probing patches (i.e. patches which
>>>> converts the driver to the model introduced in linux 2.4)?
>>> Well yes. We've got a copule of such cards, which raises some
>>> interest in a proper driver. Just send the patches with some
>>> instructions along, or point me to a git branch if you prefer.
>> Maybe the git with stand-alone module would be better...
>
> Sorry, I don't understand this suggestion. I don't read LKML, please
> don't suppose any prior knowledge of the jargon used here... Do you
> mean I should use the bleeding edge git source of the kernel? Not
> something I'm eager to do, but can do, actually. And would you send
> me patches separately on top of that?
I meant the creating of a git repository with only the module would be the
easiest possible and most comfortable way for you :). Otherwise I can post you a
patch serie.
>>>> If not, I'll only increment the counter on modprobe and decrement it
>>>> on rmmod, since it would be a safe (in the meaning of not changing
>>>> that much code) way of fixing the problem.
>>> And what are the drawbacks of this simple solution?
>> Nothing, but it's not the proper way -- just a safe fallback. But you
>> can still say no :).
>
> I expected an improper way to have some disadvantages at least. :)
Yes, if you have pci hotpluggable motherboard :). Pci probing (the new method)
allows you adding/probing pci devices on the fly, not only when the module is
loading.
> Anyway, I can tolerate some glitches during the porting of this
> module, resulting in interruptions of the serial devices, but leaving
> the rest of the system mostly stable; it's a production system after
> all. If the changes are more threatening, I'll use another system for
> the tests. In short: suggest a method and let's give a chance for the
> proper solution. Just please enclose some risk assessment.
I did such switches in drivers several times yet, but I can't assure you, that I
won't make any mistake, but this driver seems not to need too many changes.
Maybe functionality regressions would occur rather than instability of system.
Anyway I would rather wait for the changes from comtrol to not break their
upcoming patches (if they post them in some short term) and then do these changes.
thanks,
--
Jiri Slaby ([email protected])
Faculty of Informatics, Masaryk University
On 10/17/2007 09:48 PM, Nick Thompson wrote:
> Thanks a lot for the feedback, it's very much appreciated. Like I said, there is an active project here at Comtrol to get 3.08 beta up to Linux kernel coding standards, once that gets somewhere near done, a patch will be forthcoming.
And the last question, when do you expect/estimate this would happen?
thanks,
--
Jiri Slaby ([email protected])
Faculty of Informatics, Masaryk University
Jiri Slaby <[email protected]> writes:
> I meant the creating of a git repository with only the module would be the
> easiest possible and most comfortable way for you :). Otherwise I can post you a
> patch serie.
We can go either way, as you prefer.
> On 10/18/2007 11:53 PM, Ferenc Wagner wrote:
>
>> I expected an improper way to have some disadvantages at least. :)
>
> Yes, if you have pci hotpluggable motherboard :). Pci probing (the new method)
> allows you adding/probing pci devices on the fly, not only when the module is
> loading.
Thanks for the explanation. Maybe one day the E15k-s in the basement
will make pretty good serial port concentrators.
> I did such switches in drivers several times yet, but I can't assure you, that I
> won't make any mistake, but this driver seems not to need too many changes.
> Maybe functionality regressions would occur rather than instability of system.
All right.
> Anyway I would rather wait for the changes from comtrol to not break their
> upcoming patches (if they post them in some short term) and then do these changes.
Ah, I didn't know you were in contact with them. Till now I only got
a notice that my request had been forwarded to another continent with
the Linux developer. :) Sure, let's wait for the answer.
--
Regards,
Feri.
>-----Original Message-----
>From: Jiri Slaby [mailto:[email protected]]
>Sent: Thursday, October 18, 2007 5:08 PM
>To: Nick Thompson
>Cc: Jiri Slaby; [email protected]; Ferenc Wagner
>Subject: Re: RocketPort Linux driver errors on module reload
>
>
>>On 10/17/2007 09:48 PM, Nick Thompson wrote:
>> Thanks a lot for the feedback, it's very much appreciated. Like I said, there is an >>active project here at Comtrol to get 3.08 beta up to Linux kernel coding standards, once >>that gets somewhere near done, a patch will be forthcoming.
>
>And the last question, when do you expect/estimate this would happen?
>
>thanks,
>--
>Jiri Slaby ([email protected])
>Faculty of Informatics, Masaryk University
Jiri,
To be honest, it would be hard to estimate at this point. I've discussed it with one of our software engineers, but we do not know how long it will be at this point, as there is a lot of work to do to get it up to kernel coding standards. I will definitely keep the list up to date.
Regards,
Nick
Nick Thompson
Technical Support Specialist [email protected]
Comtrol Corporation ftp://ftp.comtrol.com
6655 Wedgwood Rd. Ste 120 http://www.comtrol.com
Maple Grove, MN. 55311 Sales: (800)GO-ROCKET
On Oct 19, 2007 12:02 AM, Nick Thompson <[email protected]> wrote:
> >From: Jiri Slaby [mailto:[email protected]]
> >
> >And the last question, when do you expect/estimate this would happen?
>
> Jiri,
> To be honest, it would be hard to estimate at this point. I've discussed it with one of our software engineers, but we do not know how long it will be at this point, as there is a lot of work to do to get it up to kernel coding standards. I will definitely keep the list up to date.
Hi Nick, any progress, any problems?
thanks.