* [PATCH] drivers/char/moxa.c, kernel 2.6.23.14
@ 2008-01-21 12:35 Oyvind Aabling
0 siblings, 0 replies; 6+ messages in thread
From: Oyvind Aabling @ 2008-01-21 12:35 UTC (permalink / raw)
To: linux-kernel; +Cc: Jiri Slaby
[-- Attachment #1: Type: TEXT/PLAIN, Size: 4186 bytes --]
moxa.c changes to MOXA_GET_CONF ioctl breaks moxaload (userspace
application for firmware download to MOXA Intellio CPU boards).
Attached (and included inline below) is a patch to solve a problem
introduced by changes to struct moxa_board_conf in drivers/char/moxa.c.
AFAICS from the changelogs, moxa.c was rewritten to a new API in 2.6.21,
but I've only tested it (and moxaload) on kernels up to 2.6.19.2
(where it works) and on 2.6.22.6 and various later kernels,
including the latest (2.6.23.14), where it doesn't work.
Steps to reproduce:
Call the moxaload program (from MOXA) to download the firmware.
moxaload will fail on most systems (all the ones I've tried), because it
thinks there is a memory conflict, although this behaviour will depend
on the exact contents of struct moxa_board_conf (in drivers/char/moxa.c).
The problem is, that moxaload uses the MOXA_GET_CONF ioctl,
which returns (verbatim) the contents of struct moxa_board_conf,
the structure (and contents) of which has changed heavily.
This patch corrects this problem by reverting the behaviour of the
MOXA_GET_CONF ioctl, so it returns the info that moxaload expects.
I'm not on the kernel list, so please CC:
me with any questions and/or comments.
To Jiri Slaby <jirislaby@gmail.com>:
I've CC'ed this to you, although linux/MAINTAINERS doesn't
mention you as the maintainer of moxa.c, since the changelogs
seems to indicate, that you're the current maintainer.
linux/MAINTAINERS mentions you (Jiri) as the maintainer
of mxser, but that is the driver for other MOXA
boards, so I hope that I've guessed right ...
Øyvind.
PS: Jiri, you may receive this twice (sorry 'bout that),
but it seems that pine doesn't encode the From: field
properly, so my first mail got rejected by vger.kernel.org
due to the iso-latin-1 Ooblique char in my name.
What a depressingly stupid program :-(
**************************************************************************
* Øyvind Aabling E-mail : Oyvind.Aabling@uni-c.dk /~\ The ASCII *
* UNI-C Lyngby Phone : +45 35 87 88 89 \ / Ribbon *
* DTU Building 304 Phone : +45 35 87 89 51 (direct) X Campaign *
* DK-2800 LYNGBY Fax : +45 35 87 89 90 / \ Against *
* Denmark HTML Email! *
**************************************************************************
--- linux-2.6.23.14/drivers/char/moxa.c 2008-01-14 21:49:56.000000000 +0100
+++ linux/drivers/char/moxa.c 2008-01-20 18:30:15.000000000 +0100
@@ -109,6 +109,8 @@
int busType;
int loadstat;
+ unsigned short busNum;
+ unsigned short devNum;
void __iomem *basemem;
void __iomem *intNdx;
@@ -116,6 +118,16 @@
void __iomem *intTable;
} moxa_boards[MAX_BOARDS];
+/* Used by userspace application moxaload (firmware download) */
+static struct moxa_board_info {
+ int boardType;
+ int numPorts;
+ unsigned long baseAddr;
+ int busType;
+ unsigned short busNum;
+ unsigned short devNum;
+} moxa_board_info[MAX_BOARDS];
+
struct mxser_mstatus {
tcflag_t cflag;
int cts;
@@ -304,6 +316,9 @@
goto err;
board->boardType = board_type;
+ board->baseAddr = pci_resource_start(pdev, 2);
+ board->busNum = pdev->bus->number;
+ board->devNum = PCI_SLOT(pdev->devfn);
switch (board_type) {
case MOXA_BOARD_C218_ISA:
case MOXA_BOARD_C218_PCI:
@@ -1494,8 +1509,16 @@
}
switch (cmd) {
case MOXA_GET_CONF:
- if(copy_to_user(argp, &moxa_boards, MAX_BOARDS *
- sizeof(struct moxa_board_conf)))
+ for (i = 0; i < MAX_BOARDS; i++) {
+ moxa_board_info[i].boardType = moxa_boards[i].boardType;
+ moxa_board_info[i].numPorts = moxa_boards[i].numPorts;
+ moxa_board_info[i].baseAddr = moxa_boards[i].baseAddr;
+ moxa_board_info[i].busType = moxa_boards[i].busType;
+ moxa_board_info[i].busNum = moxa_boards[i].busNum;
+ moxa_board_info[i].devNum = moxa_boards[i].devNum;
+ }
+ if(copy_to_user(argp, &moxa_board_info, MAX_BOARDS *
+ sizeof(struct moxa_board_info)))
return -EFAULT;
return (0);
case MOXA_INIT_DRIVER:
[-- Attachment #2: Type: TEXT/x-diff, Size: 1724 bytes --]
--- linux-2.6.23.14/drivers/char/moxa.c 2008-01-14 21:49:56.000000000 +0100
+++ linux/drivers/char/moxa.c 2008-01-20 18:30:15.000000000 +0100
@@ -109,6 +109,8 @@
int busType;
int loadstat;
+ unsigned short busNum;
+ unsigned short devNum;
void __iomem *basemem;
void __iomem *intNdx;
@@ -116,6 +118,16 @@
void __iomem *intTable;
} moxa_boards[MAX_BOARDS];
+/* Used by userspace application moxaload (firmware download) */
+static struct moxa_board_info {
+ int boardType;
+ int numPorts;
+ unsigned long baseAddr;
+ int busType;
+ unsigned short busNum;
+ unsigned short devNum;
+} moxa_board_info[MAX_BOARDS];
+
struct mxser_mstatus {
tcflag_t cflag;
int cts;
@@ -304,6 +316,9 @@
goto err;
board->boardType = board_type;
+ board->baseAddr = pci_resource_start(pdev, 2);
+ board->busNum = pdev->bus->number;
+ board->devNum = PCI_SLOT(pdev->devfn);
switch (board_type) {
case MOXA_BOARD_C218_ISA:
case MOXA_BOARD_C218_PCI:
@@ -1494,8 +1509,16 @@
}
switch (cmd) {
case MOXA_GET_CONF:
- if(copy_to_user(argp, &moxa_boards, MAX_BOARDS *
- sizeof(struct moxa_board_conf)))
+ for (i = 0; i < MAX_BOARDS; i++) {
+ moxa_board_info[i].boardType = moxa_boards[i].boardType;
+ moxa_board_info[i].numPorts = moxa_boards[i].numPorts;
+ moxa_board_info[i].baseAddr = moxa_boards[i].baseAddr;
+ moxa_board_info[i].busType = moxa_boards[i].busType;
+ moxa_board_info[i].busNum = moxa_boards[i].busNum;
+ moxa_board_info[i].devNum = moxa_boards[i].devNum;
+ }
+ if(copy_to_user(argp, &moxa_board_info, MAX_BOARDS *
+ sizeof(struct moxa_board_info)))
return -EFAULT;
return (0);
case MOXA_INIT_DRIVER:
^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <Pine.LNX.4.64.0801202145230.18101@dbs1.uni-c.dtu.dk>]
* Re: [PATCH] drivers/char/moxa.c, kernel 2.6.23.14
[not found] <Pine.LNX.4.64.0801202145230.18101@dbs1.uni-c.dtu.dk>
@ 2008-01-21 22:51 ` Jiri Slaby
2008-01-22 10:23 ` Oyvind Aabling
0 siblings, 1 reply; 6+ messages in thread
From: Jiri Slaby @ 2008-01-21 22:51 UTC (permalink / raw)
To: Øyvind Aabling; +Cc: linux-kernel
On 01/20/2008 10:45 PM, Øyvind Aabling wrote:
> moxa.c changes to MOXA_GET_CONF ioctl breaks moxaload (userspace
> application for firmware download to MOXA Intellio CPU boards).
>
> Attached (and included inline below) is a patch to solve a problem
> introduced by changes to struct moxa_board_conf in drivers/char/moxa.c.
>
> AFAICS from the changelogs, moxa.c was rewritten to a new API in 2.6.21,
> but I've only tested it (and moxaload) on kernels up to 2.6.19.2
> (where it works) and on 2.6.22.6 and various later kernels,
> including the latest (2.6.23.14), where it doesn't work.
>
> Steps to reproduce:
>
> Call the moxaload program (from MOXA) to download the firmware.
Thanks for pointing this out.
> moxaload will fail on most systems (all the ones I've tried), because it
> thinks there is a memory conflict, although this behaviour will depend
> on the exact contents of struct moxa_board_conf (in drivers/char/moxa.c).
>
> The problem is, that moxaload uses the MOXA_GET_CONF ioctl,
> which returns (verbatim) the contents of struct moxa_board_conf,
> the structure (and contents) of which has changed heavily.
>
> This patch corrects this problem by reverting the behaviour of the
> MOXA_GET_CONF ioctl, so it returns the info that moxaload expects.
>
> I'm not on the kernel list, so please CC:
> me with any questions and/or comments.
>
> To Jiri Slaby <jirislaby@gmail.com>:
>
> I've CC'ed this to you, although linux/MAINTAINERS doesn't
> mention you as the maintainer of moxa.c, since the changelogs
> seems to indicate, that you're the current maintainer.
>
> linux/MAINTAINERS mentions you (Jiri) as the maintainer
> of mxser, but that is the driver for other MOXA
> boards, so I hope that I've guessed right ...
Yeah, at least I know what's the problem about :).
> --- linux-2.6.23.14/drivers/char/moxa.c 2008-01-14 21:49:56.000000000
> +0100
> +++ linux/drivers/char/moxa.c 2008-01-20 18:30:15.000000000 +0100
> @@ -109,6 +109,8 @@
> int busType;
>
> int loadstat;
> + unsigned short busNum;
> + unsigned short devNum;
>
> void __iomem *basemem;
> void __iomem *intNdx;
> @@ -116,6 +118,16 @@
> void __iomem *intTable;
> } moxa_boards[MAX_BOARDS];
>
> +/* Used by userspace application moxaload (firmware download) */
> +static struct moxa_board_info {
> + int boardType;
> + int numPorts;
> + unsigned long baseAddr;
> + int busType;
> + unsigned short busNum;
> + unsigned short devNum;
> +} moxa_board_info[MAX_BOARDS];
> +
Hrm, too ugly (sadly as same as it was).
- not 32/64 bit compatible due to the ulong there.
- not exported to the world via include/linux (the reason why I removed it, they
use something, which they know nothing about).
- I would rather see true firmware loading.
Would you be willing to test such a patch for point no. 3?
> struct mxser_mstatus {
> tcflag_t cflag;
> int cts;
> @@ -304,6 +316,9 @@
> goto err;
>
> board->boardType = board_type;
> + board->baseAddr = pci_resource_start(pdev, 2);
you missed isa cards...
> + board->busNum = pdev->bus->number;
> + board->devNum = PCI_SLOT(pdev->devfn);
> switch (board_type) {
> case MOXA_BOARD_C218_ISA:
> case MOXA_BOARD_C218_PCI:
> @@ -1494,8 +1509,16 @@
> }
> switch (cmd) {
> case MOXA_GET_CONF:
> - if(copy_to_user(argp, &moxa_boards, MAX_BOARDS *
> - sizeof(struct moxa_board_conf)))
> + for (i = 0; i < MAX_BOARDS; i++) {
> + moxa_board_info[i].boardType = moxa_boards[i].boardType;
> + moxa_board_info[i].numPorts = moxa_boards[i].numPorts;
> + moxa_board_info[i].baseAddr = moxa_boards[i].baseAddr;
> + moxa_board_info[i].busType = moxa_boards[i].busType;
> + moxa_board_info[i].busNum = moxa_boards[i].busNum;
> + moxa_board_info[i].devNum = moxa_boards[i].devNum;
> + }
> + if(copy_to_user(argp, &moxa_board_info, MAX_BOARDS *
> + sizeof(struct moxa_board_info)))
> return -EFAULT;
> return (0);
> case MOXA_INIT_DRIVER:
thanks,
--js
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] drivers/char/moxa.c, kernel 2.6.23.14
2008-01-21 22:51 ` Jiri Slaby
@ 2008-01-22 10:23 ` Oyvind Aabling
2008-01-23 15:37 ` Jiri Slaby
0 siblings, 1 reply; 6+ messages in thread
From: Oyvind Aabling @ 2008-01-22 10:23 UTC (permalink / raw)
To: Jiri Slaby; +Cc: linux-kernel
[-- Attachment #1: Type: TEXT/PLAIN, Size: 6409 bytes --]
On Mon, 21 Jan 2008, Jiri Slaby wrote:
> On 01/20/2008 10:45 PM, Øyvind Aabling wrote:
>> moxa.c changes to MOXA_GET_CONF ioctl breaks moxaload (userspace
>> application for firmware download to MOXA Intellio CPU boards).
>>
>> Attached (and included inline below) is a patch to solve a problem
>> introduced by changes to struct moxa_board_conf in drivers/char/moxa.c.
>>
>> AFAICS from the changelogs, moxa.c was rewritten to a new API in 2.6.21,
>> but I've only tested it (and moxaload) on kernels up to 2.6.19.2
>> (where it works) and on 2.6.22.6 and various later kernels,
>> including the latest (2.6.23.14), where it doesn't work.
>>
>> Steps to reproduce:
>>
>> Call the moxaload program (from MOXA) to download the firmware.
>
> Thanks for pointing this out.
>
>> moxaload will fail on most systems (all the ones I've tried), because it
>> thinks there is a memory conflict, although this behaviour will depend
>> on the exact contents of struct moxa_board_conf (in drivers/char/moxa.c).
>>
>> The problem is, that moxaload uses the MOXA_GET_CONF ioctl,
>> which returns (verbatim) the contents of struct moxa_board_conf,
>> the structure (and contents) of which has changed heavily.
>>
>> This patch corrects this problem by reverting the behaviour of the
>> MOXA_GET_CONF ioctl, so it returns the info that moxaload expects.
>>
>> I'm not on the kernel list, so please CC:
>> me with any questions and/or comments.
>>
>> To Jiri Slaby <jirislaby@gmail.com>:
>>
>> I've CC'ed this to you, although linux/MAINTAINERS doesn't
>> mention you as the maintainer of moxa.c, since the changelogs
>> seems to indicate, that you're the current maintainer.
>>
>> linux/MAINTAINERS mentions you (Jiri) as the maintainer
>> of mxser, but that is the driver for other MOXA
>> boards, so I hope that I've guessed right ...
>
> Yeah, at least I know what's the problem about :).
:-)
>> --- linux-2.6.23.14/drivers/char/moxa.c 2008-01-14 21:49:56.000000000
>> +0100
>> +++ linux/drivers/char/moxa.c 2008-01-20 18:30:15.000000000 +0100
>> @@ -109,6 +109,8 @@
>> int busType;
>>
>> int loadstat;
>> + unsigned short busNum;
>> + unsigned short devNum;
>>
>> void __iomem *basemem;
>> void __iomem *intNdx;
>> @@ -116,6 +118,16 @@
>> void __iomem *intTable;
>> } moxa_boards[MAX_BOARDS];
>>
>> +/* Used by userspace application moxaload (firmware download) */
>> +static struct moxa_board_info {
>> + int boardType;
>> + int numPorts;
>> + unsigned long baseAddr;
>> + int busType;
>> + unsigned short busNum;
>> + unsigned short devNum;
>> +} moxa_board_info[MAX_BOARDS];
>> +
>
> Hrm, too ugly (sadly as same as it was).
Well, yes, it's ugly, but anything else breaks moxaload ...
> - not 32/64 bit compatible due to the ulong there.
> - not exported to the world via include/linux (the reason why I removed it,
> they use something, which they know nothing about).
> - I would rather see true firmware loading.
>
> Would you be willing to test such a patch for point no. 3?
Yes, I could do that.
I can see your point about the non-portability of it, but
how about this scenario, to provide backwards compatibility:
* We keep the (ugly and non-compatible) MOXA_GET_CONF
ioctl, to avoid breaking the old moxaload.
Let's rename it to MOXA_GET_CONF_OLD or MOXA_GET_CONF_BAD in the driver.
* Create a new MOXA_GET_CONF ioctl (with a new
number, of course), that does it "the right way".
If you don't like renaming ioctl's, we need a new name for this one.
* Rewrite moxaload to either do a kernel version check
and use the new ioctl if available or the old if not.
Or skip that and let it call the new ioctl first.
If it succeeds (system running a newer kernel): fine, and
if not (system running an older kernel), use the old ioctl.
The MOXA Intellio driver and moxaload have been "broken" ever since they
were written in 1999, and this way, we don't break anything - you can
use old or new kernel, and old or new moxaload in any combination.
Whaddaya think ?
>> struct mxser_mstatus {
>> tcflag_t cflag;
>> int cts;
>> @@ -304,6 +316,9 @@
>> goto err;
>>
>> board->boardType = board_type;
>> + board->baseAddr = pci_resource_start(pdev, 2);
>
> you missed isa cards...
Oops, you're right, I don't have any ISA cards,
so I totally forgot about those dinosaurs :-)
The necessary code is available in the old
version of moxa.c, so it's easily fixed.
I guess ISA isn't _quite_ dead yet, although I don't think I have a
single system with ISA cards (or even ISA slots) in it anymore ...
>> + board->busNum = pdev->bus->number;
>> + board->devNum = PCI_SLOT(pdev->devfn);
>> switch (board_type) {
>> case MOXA_BOARD_C218_ISA:
>> case MOXA_BOARD_C218_PCI:
>> @@ -1494,8 +1509,16 @@
>> }
>> switch (cmd) {
>> case MOXA_GET_CONF:
>> - if(copy_to_user(argp, &moxa_boards, MAX_BOARDS *
>> - sizeof(struct moxa_board_conf)))
>> + for (i = 0; i < MAX_BOARDS; i++) {
>> + moxa_board_info[i].boardType = moxa_boards[i].boardType;
>> + moxa_board_info[i].numPorts = moxa_boards[i].numPorts;
>> + moxa_board_info[i].baseAddr = moxa_boards[i].baseAddr;
>> + moxa_board_info[i].busType = moxa_boards[i].busType;
>> + moxa_board_info[i].busNum = moxa_boards[i].busNum;
>> + moxa_board_info[i].devNum = moxa_boards[i].devNum;
>> + }
>> + if(copy_to_user(argp, &moxa_board_info, MAX_BOARDS *
>> + sizeof(struct moxa_board_info)))
>> return -EFAULT;
>> return (0);
>> case MOXA_INIT_DRIVER:
>
> thanks,
> --js
Øyvind.
**************************************************************************
* Øyvind Aabling E-mail : Oyvind.Aabling@uni-c.dk /~\ The ASCII *
* UNI-C Lyngby Phone : +45 35 87 88 89 \ / Ribbon *
* DTU Building 304 Phone : +45 35 87 89 51 (direct) X Campaign *
* DK-2800 LYNGBY Fax : +45 35 87 89 90 / \ Against *
* Denmark HTML Email! *
**************************************************************************
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] drivers/char/moxa.c, kernel 2.6.23.14
2008-01-22 10:23 ` Oyvind Aabling
@ 2008-01-23 15:37 ` Jiri Slaby
2008-01-24 23:34 ` Oyvind Aabling
0 siblings, 1 reply; 6+ messages in thread
From: Jiri Slaby @ 2008-01-23 15:37 UTC (permalink / raw)
To: Oyvind Aabling; +Cc: linux-kernel
On 01/22/2008 11:23 AM, Oyvind Aabling wrote:
> On Mon, 21 Jan 2008, Jiri Slaby wrote:
>> Would you be willing to test such a patch for point no. 3?
>
> Yes, I could do that.
>
> I can see your point about the non-portability of it, but
> how about this scenario, to provide backwards compatibility:
>
> * We keep the (ugly and non-compatible) MOXA_GET_CONF
> ioctl, to avoid breaking the old moxaload.
> Let's rename it to MOXA_GET_CONF_OLD or MOXA_GET_CONF_BAD in the driver.
> * Create a new MOXA_GET_CONF ioctl (with a new
> number, of course), that does it "the right way".
> If you don't like renaming ioctl's, we need a new name for this one.
> * Rewrite moxaload to either do a kernel version check
> and use the new ioctl if available or the old if not.
> Or skip that and let it call the new ioctl first.
> If it succeeds (system running a newer kernel): fine, and
> if not (system running an older kernel), use the old ioctl.
>
> The MOXA Intellio driver and moxaload have been "broken" ever since they
> were written in 1999, and this way, we don't break anything - you can
> use old or new kernel, and old or new moxaload in any combination.
>
> Whaddaya think ?
We won't need anything from that. I'm almost done with firmware support. The
only thing you'll need to do is to copy the .cod file(s) into /lib/firmware or
wherever your firmware loader (probably udev nowadays) finds such files.
Could you post me lspci -vvxxx output of your moxa card?
thanks,
--js
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] drivers/char/moxa.c, kernel 2.6.23.14
2008-01-23 15:37 ` Jiri Slaby
@ 2008-01-24 23:34 ` Oyvind Aabling
2008-01-24 23:38 ` Jiri Slaby
0 siblings, 1 reply; 6+ messages in thread
From: Oyvind Aabling @ 2008-01-24 23:34 UTC (permalink / raw)
To: Jiri Slaby; +Cc: linux-kernel
[-- Attachment #1: Type: TEXT/PLAIN, Size: 3925 bytes --]
On Wed, 23 Jan 2008, Jiri Slaby wrote:
> On 01/22/2008 11:23 AM, Oyvind Aabling wrote:
>> On Mon, 21 Jan 2008, Jiri Slaby wrote:
>>> Would you be willing to test such a patch for point no. 3?
>>
>> Yes, I could do that.
>>
>> I can see your point about the non-portability of it, but
>> how about this scenario, to provide backwards compatibility:
>>
>> * We keep the (ugly and non-compatible) MOXA_GET_CONF
>> ioctl, to avoid breaking the old moxaload.
>> Let's rename it to MOXA_GET_CONF_OLD or MOXA_GET_CONF_BAD in the driver.
>> * Create a new MOXA_GET_CONF ioctl (with a new
>> number, of course), that does it "the right way".
>> If you don't like renaming ioctl's, we need a new name for this one.
>> * Rewrite moxaload to either do a kernel version check
>> and use the new ioctl if available or the old if not.
>> Or skip that and let it call the new ioctl first.
>> If it succeeds (system running a newer kernel): fine, and
>> if not (system running an older kernel), use the old ioctl.
>>
>> The MOXA Intellio driver and moxaload have been "broken" ever since they
>> were written in 1999, and this way, we don't break anything - you can
>> use old or new kernel, and old or new moxaload in any combination.
>>
>> Whaddaya think ?
>
> We won't need anything from that. I'm almost done with firmware support. The
> only thing you'll need to do is to copy the .cod file(s) into /lib/firmware
> or wherever your firmware loader (probably udev nowadays) finds such files.
>
> Could you post me lspci -vvxxx output of your moxa card?
>
> thanks,
> --js
Ah, I see, you want to get rid of moxaload altogether ...
I'll test your patch series as soon as I get a chance - need to put a
MOXA card into a non-production machine first, so it'll be a few days.
We have a few MOXA Intellio C320 Turbo PCI
cards, here's lspci -vvxxx for one of them:
02:02.0 Serial controller: Moxa Technologies Co Ltd Intellio C320 Turbo PCI (rev 02) (prog-if 80)
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin A routed to IRQ 16
Region 1: I/O ports at 9400 [size=128]
Region 2: Memory at fb200000 (32-bit, non-prefetchable) [size=16K]
00: 93 13 00 32 03 00 80 02 02 80 00 07 08 00 00 00
10: 00 00 00 00 01 94 00 00 00 00 20 fb 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 0b 01 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
The other cards looks identical, except for unimportant differences
in region mapping and IRQ allocation due to system differences.
Øyvind.
**************************************************************************
* Øyvind Aabling E-mail : Oyvind.Aabling@uni-c.dk /~\ The ASCII *
* UNI-C Lyngby Phone : +45 35 87 88 89 \ / Ribbon *
* DTU Building 304 Phone : +45 35 87 89 51 (direct) X Campaign *
* DK-2800 LYNGBY Fax : +45 35 87 89 90 / \ Against *
* Denmark HTML Email! *
**************************************************************************
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] drivers/char/moxa.c, kernel 2.6.23.14
2008-01-24 23:34 ` Oyvind Aabling
@ 2008-01-24 23:38 ` Jiri Slaby
0 siblings, 0 replies; 6+ messages in thread
From: Jiri Slaby @ 2008-01-24 23:38 UTC (permalink / raw)
To: Oyvind Aabling; +Cc: linux-kernel
On 01/25/2008 12:34 AM, Oyvind Aabling wrote:
> Ah, I see, you want to get rid of moxaload altogether ...
Yes, I don't like such a loaders :).
> I'll test your patch series as soon as I get a chance - need to put a
> MOXA card into a non-production machine first, so it'll be a few days.
Ok, thanks, no problem.
> We have a few MOXA Intellio C320 Turbo PCI
> cards, here's lspci -vvxxx for one of them:
>
> 02:02.0 Serial controller: Moxa Technologies Co Ltd Intellio C320 Turbo
> PCI (rev 02) (prog-if 80)
> Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B-
> Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
> <TAbort- <MAbort- >SERR- <PERR-
> Interrupt: pin A routed to IRQ 16
> Region 1: I/O ports at 9400 [size=128]
> Region 2: Memory at fb200000 (32-bit, non-prefetchable) [size=16K]
[...]
> The other cards looks identical, except for unimportant differences
> in region mapping and IRQ allocation due to system differences.
OK, doesn't matter, I was just curious if region 2 is really mem space.
thanks,
--js
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2008-01-24 23:38 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-01-21 12:35 [PATCH] drivers/char/moxa.c, kernel 2.6.23.14 Oyvind Aabling
[not found] <Pine.LNX.4.64.0801202145230.18101@dbs1.uni-c.dtu.dk>
2008-01-21 22:51 ` Jiri Slaby
2008-01-22 10:23 ` Oyvind Aabling
2008-01-23 15:37 ` Jiri Slaby
2008-01-24 23:34 ` Oyvind Aabling
2008-01-24 23:38 ` Jiri Slaby
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).