headers
Adrian Bunk | 1 Mar 2005 02:16
Picon

[2.6 patch] drivers/serial/8250.c: make a variable static

This patch makes a needlessly global variable static.

Signed-off-by: Adrian Bunk <bunk <at> stusta.de>

--- linux-2.6.11-rc4-mm1-full/drivers/serial/8250.c.old	2005-02-28 23:03:34.000000000 +0100
+++ linux-2.6.11-rc4-mm1-full/drivers/serial/8250.c	2005-02-28 23:06:55.000000000 +0100
 <at>  <at>  -51,7 +51,7  <at>  <at> 
  *   share_irqs - whether we pass SA_SHIRQ to request_irq().  This option
  *                is unsafe when used on edge-triggered interrupts.
  */
-unsigned int share_irqs = SERIAL8250_SHARE_IRQS;
+static unsigned int share_irqs = SERIAL8250_SHARE_IRQS;

 /*
  * Debugging.
-
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
David Howells | 2 Mar 2005 15:19
Picon
Favicon

Early serial port problems


Hi Russell,

I've got a couple of problems with registering serial ports with
early_serial_setup() on my FRV board with 2.6.11:

 (1) If I have no gdbstub compiled in, I try to register both serial ports
     early, but only ttyS0 works. The kernel knows both serial ports are there;
     both are mentioned in the boot console logs, both can be seen in
     /proc/tty/driver/serial, and both can be opened. However, all operations
     on ttyS0 give EIO.

     If either port is registered by itself then it works. I've changed the
     definitions in arch/frv/kernel/setup.c from what's in the standard kernel
     to include line IDs:

	static struct uart_port __initdata __frv_uart0 = {
		.uartclk		= 0,
		.membase		= (char *) UART0_BASE,
		.irq			= IRQ_CPU_UART0,
		.regshift		= 3,
		.iotype			= UPIO_MEM,
		.flags			= UPF_BOOT_AUTOCONF | UPF_SKIP_TEST,
 -->		.line			= 0,
	};

	static struct uart_port __initdata __frv_uart1 = {
		.uartclk		= 0,
		.membase		= (char *) UART1_BASE,
		.irq			= IRQ_CPU_UART1,
(Continue reading)

Permalink | Reply | 1 comment |
headers
Nishanth Aravamudan | 3 Mar 2005 19:53
Picon
Favicon

[PATCH] serial/68328serial: replace schedule_timeout() with msleep_interruptible()

Hi,

Russell, sorry if you are not responsible for this driver, but I figure
the more eyes the better.

Thanks,
Nish

Please consider applying.

Description: Use msleep_interruptible() instead of schedule_timeout() in
send_break() to guarantee the task delays as expected. Change
 <at> duration's units to milliseconds, and modify arguments in callers
appropriately.

Signed-off-by: Nishanth Aravamudan <nacc <at> us.ibm.com>

--- 2.6.11-kj-v/drivers/serial/68328serial.c	2005-03-01 23:38:32.000000000 -0800
+++ 2.6.11-kj/drivers/serial/68328serial.c	2005-03-03 10:51:12.000000000 -0800
 <at>  <at>  -992,18 +992,17  <at>  <at>  static int get_lsr_info(struct m68k_seri
 /*
  * This routine sends a break character out the serial port.
  */
-static void send_break(	struct m68k_serial * info, int duration)
+static void send_break(struct m68k_serial * info, unsigned int duration)
 {
 	m68328_uart *uart = &uart_addr[info->line];
         unsigned long flags;
         if (!info->port)
                 return;
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nishanth Aravamudan | 3 Mar 2005 19:54
Picon
Favicon

[PATCH] serial/68360serial: replace schedule_timeout() with msleep_interruptible()

Hi,

Russell, sorry if you are not responsible for this driver, but I figure
the more eyes the better.

Thanks,
Nish

Please consider applying.

Description: Use msleep_interruptible() instead of schedule_timeout() in
send_break() to guarantee the task delays as expected. Change
 <at> duration's units to milliseconds, and modify arguments in callers
appropriately.

Signed-off-by: Nishanth Aravamudan <nacc <at> us.ibm.com>

--- 2.6.11-kj-v/drivers/serial/68360serial.c	2005-03-01 23:38:26.000000000 -0800
+++ 2.6.11-kj/drivers/serial/68360serial.c	2005-03-02 14:40:38.000000000 -0800
 <at>  <at>  -1394,14 +1394,13  <at>  <at>  static void end_break(ser_info_t *info)
 /*
  * This routine sends a break character out the serial port.
  */
-static void send_break(ser_info_t *info, int duration)
+static void send_break(ser_info_t *info, unsigned int duration)
 {
-	set_current_state(TASK_INTERRUPTIBLE);
 #ifdef SERIAL_DEBUG_SEND_BREAK
 	printk("rs_send_break(%d) jiff=%lu...", duration, jiffies);
 #endif
(Continue reading)

Permalink | Reply | 0 comments |
headers
TProvoni | 4 Mar 2005 12:11
Picon
Favicon

Submitting a Linux Serial Driver

Hi,

I would like to get two new drivers incorporated into the Linux kernel.  They 
handle the CGI/Aurora Asynchronous only and Synch/Async serial cards.  Do I 
submit the kernel patches here to the linux-serial or to the linux-kernel 
lists?  If not here, where should I submit them.

Joachim Martillo

-
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Andrew Morton | 4 Mar 2005 13:01

Re: Submitting a Linux Serial Driver

TProvoni <at> aol.com wrote:
>
> I would like to get two new drivers incorporated into the Linux kernel.  They 
>  handle the CGI/Aurora Asynchronous only and Synch/Async serial cards.  Do I 
>  submit the kernel patches here to the linux-serial or to the linux-kernel 
>  lists?  If not here, where should I submit them.

When in doubt, use both lists.

See Documentation/SubmittingDrivers, Documentation/SubmittingPatches,
http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt and
http://linux.yyz.us/patch-format.html
-
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Wen Xiong | 4 Mar 2005 22:07
Picon
Favicon

Re: [ patch 3/7] drivers/serial/jsm: new serial device driver

Jeff Garzik wrote:

> Wen Xiong wrote:
>
>> +static inline void neo_set_rts_flow_control(struct channel_t *ch)
>> +{
>> +    uchar ier = readb(&ch->ch_neo_uart->ier);
>> +    uchar efr = readb(&ch->ch_neo_uart->efr);
>
>
> Do not invent new types like "ushort" or "uchar".
>
> For situations where specific size is required, use a size-specific 
> type:  u8, u16, u32, etc.
>
>> +static inline void neo_set_ixon_flow_control(struct channel_t *ch)
>
>
> This function is vaguely large.  Why is it inline
>
>> +static inline void neo_set_ixoff_flow_control(struct channel_t *ch)
>
>>
>> +    /* Give time for the UART to actually raise/drop the signals */
>> +    udelay(10);
>
>
> PCI posting
>
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chris Wedgwood | 6 Mar 2005 10:33
Favicon

[PATCH] fix for 8250.c *wrongly* detecting XScale UART(s) on x86 PC

Russell,

> 1.2073.10.1 05/03/04 21:19:20 gtj.member <at> com.rmk.(none)[rmk] +1 -0
> [ARM PATCH] 2472/1: Updates 8250.c to correctly detect XScale UARTs
>
> Patch from George Joseph
>
> Modifications to autoconfig_16550a to add a testcase
> to detect XScale UARTS.
>
> Signed-off-by: George Joseph
> Signed-off-by: Russell King

Breaks my UARTS.

I'm not thrilled with this patch but 8250.c has similar warts so I
guess it's not too bad.  Ideally we could refactor this a bit so if
this isn't acceptable let me know and I'll do that instead.

===== drivers/serial/8250.c 1.96 vs edited =====
Index: kernel-taniwha-2.6.11post-cw3/drivers/serial/8250.c
===================================================================
--- kernel-taniwha-2.6.11post-cw3.orig/drivers/serial/8250.c	2005-03-06 01:10:38.677251721 -0800
+++ kernel-taniwha-2.6.11post-cw3/drivers/serial/8250.c	2005-03-06 01:13:26.288802003 -0800
 <at>  <at>  -642,7 +642,9  <at>  <at> 
 static void autoconfig_16550a(struct uart_8250_port *up)
 {
 	unsigned char status1, status2;
+#ifdef CONFIG_ARM
 	unsigned int iersave;
(Continue reading)

Permalink | Reply | 0 comments |
headers
Russell King | 6 Mar 2005 11:19
Picon

Re: [PATCH] fix for 8250.c *wrongly* detecting XScale UART(s) on x86 PC

On Sun, Mar 06, 2005 at 01:33:21AM -0800, Chris Wedgwood wrote:
> Breaks my UARTS.
> 
> I'm not thrilled with this patch but 8250.c has similar warts so I
> guess it's not too bad.  Ideally we could refactor this a bit so if
> this isn't acceptable let me know and I'll do that instead.

If it breaks here (due to your ports being "embraced and extended") it
could well break elsewhere, and wrapping it in CONFIG_ARM doesn't solve
that.

I'm not sure what the solution to this is, but unless we can autodetect
the port "type", it rather screws the current direction of 8250, which
has been to move away from port types to a set of port capabilities.

I wonder if its possible to get hold of any documentation for your
misdetected serial port...

--

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core
-
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Chris Wedgwood | 6 Mar 2005 11:54
Favicon

Re: [PATCH] fix for 8250.c *wrongly* detecting XScale UART(s) on x86 PC

On Sun, Mar 06, 2005 at 10:19:12AM +0000, Russell King wrote:

> If it breaks here (due to your ports being "embraced and extended") it
> could well break elsewhere, and wrapping it in CONFIG_ARM doesn't solve
> that.

Yeah, I forgot other ARM stuff might have regular UART(s) which
potentially would break here too.

> I'm not sure what the solution to this is, but unless we can
> autodetect the port "type", it rather screws the current direction
> of 8250, which has been to move away from port types to a set of
> port capabilities.

Well, as I see it there are three types of serial port knowledge:

(1) Ports we know for (almost) certain we have.  For x86* we can
    probably assume ttyS0 has some fairly standard values like 0x3f8,4
    and if not expect the user to specify otherwise.

(2) Ports we know for (almost) certain we don't have.  We have
    #ifdef's for this in places already.  Basically things like PPC
    and ARM/XScale UARTs won't be found on PCs (though the reverse is
    clearly not true).

(3) Everything else.

If (1) & (2) end up being pretty limited and the bulk of 8250.c is
required for (3) then changing things around probably isn't worth
while at all.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane