2002-10-02 10:52:26

by DevilKin

[permalink] [raw]
Subject: 2.4.50 - 8250_cs does NOT work

Hello all,

I'm trying to get my pcmcia modem to work, it's a
product info: "Psion Dacom", "Gold Card Global 56K+Fax", "56K+Fax", "V8.25"
manfid: 0x016c, 0x0005
function: 2 (serial)

If i load the 8250_cs module, I get _nothing_ at all. No text in system logs,
nothing. Modem doesn't respond under the old /dev/ttyS1, I've tried all other
/dev/ttySx's to see if it hasn't been remapped. Unfortunately, no.

Is there anything else I can try? I really need my modem back...

It seems that the Config.help entry is wrong aswell.

diff -Nru drivers/serial/Config.help.old drivers/serial/Config.help
--- drivers/serial/Config.help.old Wed Oct 2 12:54:32 2002
+++ drivers/serial/Config.help Wed Oct 2 12:54:55 2002
@@ -56,7 +56,7 @@

This driver 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 serial_cs.o. If you want to compile it as
+ The module will be called 8250_cs.o. If you want to compile it as
a module, say M here and read <file:Documentation/modules.txt>.
If unsure, say N.

DK

--
"There is hopeful symbolism in the fact that flags do not wave in a
vacuum."
-- Arthur C. Clarke


2002-10-02 11:00:21

by Russell King

[permalink] [raw]
Subject: Re: 2.4.50 - 8250_cs does NOT work

On Wed, Oct 02, 2002 at 12:57:42PM +0200, DevilKin wrote:
> If i load the 8250_cs module, I get _nothing_ at all. No text in system logs,
> nothing. Modem doesn't respond under the old /dev/ttyS1, I've tried all other
> /dev/ttySx's to see if it hasn't been remapped. Unfortunately, no.
>
> Is there anything else I can try? I really need my modem back...

Known problem. I've sent a fix to someone else for it but iirc they
never came back. The following patch is completely untested - I'm
still trying to get 2.5.40 to build at present.

diff -ur orig/drivers/serial/8250.c linux/drivers/serial/8250.c
--- orig/drivers/serial/8250.c Fri Aug 2 21:13:31 2002
+++ linux/drivers/serial/8250.c Sun Sep 29 10:37:49 2002
@@ -31,7 +31,8 @@
#include <linux/console.h>
#include <linux/sysrq.h>
#include <linux/serial_reg.h>
-#include <linux/serialP.h>
+#include <linux/circ_buf.h>
+#include <linux/serial.h>
#include <linux/delay.h>

#include <asm/io.h>
@@ -1560,21 +1561,22 @@
{
struct uart_8250_port *up = (struct uart_8250_port *)port;
struct resource *res = NULL, *res_rsa = NULL;
- int ret = -EBUSY;
+ int ret = 0;

- if (up->port.type == PORT_RSA) {
- ret = serial8250_request_rsa_resource(up, &res_rsa);
- if (ret)
- return ret;
- }
+ if (up->port.flags & UPF_RESOURCES) {
+ if (up->port.type == PORT_RSA) {
+ ret = serial8250_request_rsa_resource(up, &res_rsa);
+ if (ret)
+ return ret;
+ }

- ret = serial8250_request_std_resource(up, &res);
+ ret = serial8250_request_std_resource(up, &res);
+ }

/*
* If we have a mapbase, then request that as well.
*/
- if (res != NULL && up->port.iotype == SERIAL_IO_MEM &&
- up->port.mapbase) {
+ if (ret == 0 && up->port.flags & UPF_IOREMAP) {
int size = res->end - res->start + 1;

up->port.membase = ioremap(up->port.mapbase, size);
@@ -1610,13 +1612,17 @@
* Find the region that we can probe for. This in turn
* tells us whether we can probe for the type of port.
*/
- ret = serial8250_request_std_resource(up, &res_std);
- if (ret)
- return;
+ if (up->port.flags & UPF_RESOURCES) {
+ ret = serial8250_request_std_resource(up, &res_std);
+ if (ret)
+ return;

- ret = serial8250_request_rsa_resource(up, &res_rsa);
- if (ret)
+ ret = serial8250_request_rsa_resource(up, &res_rsa);
+ if (ret)
+ probeflags &= ~PROBE_RSA;
+ } else {
probeflags &= ~PROBE_RSA;
+ }

if (flags & UART_CONFIG_TYPE)
autoconfig(up, probeflags);
@@ -1678,6 +1684,7 @@

static void __init serial8250_isa_init_ports(void)
{
+ struct uart_8250_port *up;
static int first = 1;
int i;

@@ -1685,13 +1692,21 @@
return;
first = 0;

- for (i = 0; i < ARRAY_SIZE(old_serial_port); i++) {
- serial8250_ports[i].port.iobase = old_serial_port[i].port;
- serial8250_ports[i].port.irq = irq_cannonicalize(old_serial_port[i].irq);
- serial8250_ports[i].port.uartclk = old_serial_port[i].base_baud * 16;
- serial8250_ports[i].port.flags = old_serial_port[i].flags;
- serial8250_ports[i].port.hub6 = old_serial_port[i].hub6;
- serial8250_ports[i].port.ops = &serial8250_pops;
+ for (i = 0, up = serial8250_ports; i < ARRAY_SIZE(old_serial_port);
+ i++, up++) {
+ up->port.iobase = old_serial_port[i].port;
+ up->port.irq = irq_cannonicalize(old_serial_port[i].irq);
+ up->port.uartclk = old_serial_port[i].baud_base * 16;
+ up->port.flags = old_serial_port[i].flags |
+ UPF_RESOURCES;
+ up->port.hub6 = old_serial_port[i].hub6;
+ up->port.membase = old_serial_port[i].iomem_base;
+ up->port.iotype = old_serial_port[i].io_type;
+ up->port.regshift = old_serial_port[i].iomem_reg_shift;
+ up->port.ops = &serial8250_pops;
+
+ if (up->port.iotype == SERIAL_IO_MEM && up->port.mapbase)
+ up->port.flags |= UPF_IOREMAP;
}
}

diff -ur orig/drivers/serial/8250.h linux/drivers/serial/8250.h
--- orig/drivers/serial/8250.h Sat Jul 27 13:55:21 2002
+++ linux/drivers/serial/8250.h Sun Sep 29 10:37:32 2002
@@ -12,7 +12,7 @@
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
- * $Id: 8250.h,v 1.8 2002/07/21 21:32:30 rmk Exp $
+ * $Id: 8250.h,v 1.9 2002/07/27 12:42:16 rmk Exp $
*/

#include <linux/config.h>
@@ -30,11 +30,14 @@

struct old_serial_port {
unsigned int uart;
- unsigned int base_baud;
+ unsigned int baud_base;
unsigned int port;
unsigned int irq;
unsigned int flags;
unsigned char hub6;
+ unsigned char io_type;
+ unsigned char *iomem_base;
+ unsigned short iomem_reg_shift;
};

#undef SERIAL_DEBUG_PCI
--- orig/include/linux/serial_core.h Sun Aug 11 12:29:31 2002
+++ linux/include/linux/serial_core.h Sun Sep 29 10:17:57 2002
@@ -17,7 +17,7 @@
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*
- * $Id: serial_core.h,v 1.49 2002/07/20 18:06:32 rmk Exp $
+ * $Id: serial_core.h,v 1.53 2002/08/02 12:55:08 rmk Exp $
*/

/*
@@ -168,6 +168,8 @@
#define UPF_BUGGY_UART (1 << 14)
#define UPF_AUTOPROBE (1 << 15)
#define UPF_BOOT_AUTOCONF (1 << 28)
+#define UPF_RESOURCES (1 << 30)
+#define UPF_IOREMAP (1 << 31)

#define UPF_FLAGS (0x7fff)
#define UPF_USR_MASK (UPF_SPD_MASK|UPF_LOW_LATENCY)


--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html

2002-10-02 11:43:37

by DevilKin

[permalink] [raw]
Subject: Re: 2.4.50 - 8250_cs does NOT work

On Wednesday 02 October 2002 13:05, Russell King wrote:
> On Wed, Oct 02, 2002 at 12:57:42PM +0200, DevilKin wrote:
> > If i load the 8250_cs module, I get _nothing_ at all. No text in system
> > logs, nothing. Modem doesn't respond under the old /dev/ttyS1, I've tried
> > all other /dev/ttySx's to see if it hasn't been remapped. Unfortunately,
> > no.
> >
> > Is there anything else I can try? I really need my modem back...
>
> Known problem. I've sent a fix to someone else for it but iirc they
> never came back. The following patch is completely untested - I'm
> still trying to get 2.5.40 to build at present.
>
Had to manually apply it (for some weird reason it didn't work with patch),

compiled it and got this compilation error:

make[3]: Entering directory `/usr/src/linux-2.5/drivers/serial'
gcc -Wp,-MD,./.core.o.d -D__KERNEL__ -I/usr/src/linux-2.5/include -Wall
-Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer
-fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2
-march=i686 -I/usr/src/linux-2.5/arch/i386/mach-generic -nostdinc
-iwithprefix include -DKBUILD_BASENAME=core -DEXPORT_SYMTAB -c -o core.o
core.c
gcc -Wp,-MD,./.8250.o.d -D__KERNEL__ -I/usr/src/linux-2.5/include -Wall
-Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer
-fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2
-march=i686 -I/usr/src/linux-2.5/arch/i386/mach-generic -nostdinc
-iwithprefix include -DKBUILD_BASENAME=8250 -DEXPORT_SYMTAB -c -o 8250.o
8250.c
drivers/serial/8250.c: In function `serial8250_set_mctrl':
drivers/serial/8250.c:1061: `ALPHA_KLUDGE_MCR' undeclared (first use in this
function)
drivers/serial/8250.c:1061: (Each undeclared identifier is reported only once
drivers/serial/8250.c:1061: for each function it appears in.)
drivers/serial/8250.c: In function `serial8250_isa_init_ports':
drivers/serial/8250.c:1701: structure has no member named `io_type'
gcc -Wp,-MD,./.8250_pci.o.d -D__KERNEL__ -I/usr/src/linux-2.5/include -Wall
-Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer
-fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2
-march=i686 -I/usr/src/linux-2.5/arch/i386/mach-generic -nostdinc
-iwithprefix include -DKBUILD_BASENAME=8250_pci -c -o 8250_pci.o
8250_pci.c
ld -m elf_i386 -r -o built-in.o core.o 8250.o 8250_pci.o
ld: cannot open 8250.o: No such file or directory
make[3]: *** [built-in.o] Error 1
make[3]: Leaving directory `/usr/src/linux-2.5/drivers/serial'
make[2]: *** [serial] Error 2
make[2]: Leaving directory `/usr/src/linux-2.5/drivers'
make[1]: *** [drivers] Error 2
make[1]: Leaving directory `/usr/src/linux-2.5'
make: *** [bzImage] Error 2

So i guess it doesn't work...

DK
--
"... one of the main causes of the fall of the Roman Empire was that,
lacking zero, they had no way to indicate successful termination of
their C programs."
-- Robert Firth

2002-10-02 12:18:05

by DevilKin

[permalink] [raw]
Subject: Re: 2.4.50 - 8250_cs does NOT work

On Wednesday 02 October 2002 13:48, DevilKin wrote:
> make[3]: Entering directory `/usr/src/linux-2.5/drivers/serial'
> gcc -Wp,-MD,./.8250.o.d -D__KERNEL__ -I/usr/src/linux-2.5/include -Wall
> -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer
> -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2
> -march=i686 -I/usr/src/linux-2.5/arch/i386/mach-generic -nostdinc
> -iwithprefix include -DKBUILD_BASENAME=8250 -DEXPORT_SYMTAB -c -o
> 8250.o 8250.c
> drivers/serial/8250.c: In function `serial8250_set_mctrl':
> drivers/serial/8250.c:1061: `ALPHA_KLUDGE_MCR' undeclared (first use in
> this function)
> drivers/serial/8250.c:1061: (Each undeclared identifier is reported only
> once drivers/serial/8250.c:1061: for each function it appears in.)

Fixed this one by re-introducing
#include <linux/serialP.h>

> drivers/serial/8250.c: In function `serial8250_isa_init_ports':
> drivers/serial/8250.c:1701: structure has no member named `io_type'
> gcc -Wp,-MD,./.8250_pci.o.d -D__KERNEL__ -I/usr/src/linux-2.5/include
> -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer
> -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2
> -march=i686 -I/usr/src/linux-2.5/arch/i386/mach-generic -nostdinc
> -iwithprefix include -DKBUILD_BASENAME=8250_pci -c -o 8250_pci.o
> 8250_pci.c
> ld -m elf_i386 -r -o built-in.o core.o 8250.o 8250_pci.o

This one was my mistake...

I'm happy to report that my modem now works as it should :-))

Thanks!

DK


2002-10-07 08:29:02

by David Woodhouse

[permalink] [raw]
Subject: Re: 2.4.50 - 8250_cs does NOT work


[email protected] said:
> > If i load the 8250_cs module, I get _nothing_ at all. No text in
> > system logs, nothing. Modem doesn't respond under the old /dev/ttyS1,
> > I've tried all other /dev/ttySx's to see if it hasn't been remapped.
> > Unfortunately, no.
> >
> > Is there anything else I can try? I really need my modem back...

> Known problem. I've sent a fix to someone else for it but iirc they
> never came back. The following patch is completely untested - I'm
> still trying to get 2.5.40 to build at present.

Doesn't compile. ALPHA_KLUDGE_MCR undefined. That crap in the generic 8250
code should go away in favour of some mask bits set by the platform-specific
code when it registers the ports. You probably want to set the default _and_
the permitted bits that way.

--
dwmw2


2002-10-07 08:34:55

by Russell King

[permalink] [raw]
Subject: Re: 2.4.50 - 8250_cs does NOT work

On Mon, Oct 07, 2002 at 09:34:27AM +0100, David Woodhouse wrote:
> Doesn't compile. ALPHA_KLUDGE_MCR undefined. That crap in the generic 8250
> code should go away in favour of some mask bits set by the platform-specific
> code when it registers the ports. You probably want to set the default _and_
> the permitted bits that way.

Oddly, thats what DevilKin reported. This isn't the patch I sent Linus.
8)

--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html