2.4.50 - 8250_cs does NOT work

2.4.50 - 8250_cs does NOT work

[DevilKin]

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

Re: 2.4.50 - 8250_cs does NOT work

[Russell King]

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 (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: 2.4.50 - 8250_cs does NOT work

[DevilKin]

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

Re: 2.4.50 - 8250_cs does NOT work

[DevilKin]

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

Re: 2.4.50 - 8250_cs does NOT work

[David Woodhouse]

rmk@arm.linux.org.uk 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

Re: 2.4.50 - 8250_cs does NOT work

[Russell King]

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 (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html