Re: [PATCH 2.6.12-rc1-mm3] m32r: m32r_sio driver update (was Re: [PATCH] Re: Bitrotting serial drivers)
On Wed, Mar 30, 2005 at 09:59:48AM +0900, Hirokazu Takata wrote: > Here is an additional patch to update m32r_sio driver. > This patch is against 2.6.12-rc1-mm3. > > m32r_sio driver updates: > - Move m32r_sio specific description from asm-m32r/serial.h to > driver/serial/m32r_sio.c. > - Remove __register_m32r_sio, register_m32r_sio and unregister_m32r_sio > from driver/serial/m32r_sio.c. > > Thank you. Applied, thanks. -- Russell King Linux kernel2.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-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.12-rc1-mm3] m32r: m32r_sio driver update (was Re: [PATCH] Re: Bitrotting serial drivers)
Hello,
Here is an additional patch to update m32r_sio driver.
This patch is against 2.6.12-rc1-mm3.
m32r_sio driver updates:
- Move m32r_sio specific description from asm-m32r/serial.h to
driver/serial/m32r_sio.c.
- Remove __register_m32r_sio, register_m32r_sio and unregister_m32r_sio
from driver/serial/m32r_sio.c.
Thank you.
From: Russell King <[EMAIL PROTECTED]>
Subject: Re: [PATCH] Re: Bitrotting serial drivers
Date: Thu, 24 Mar 2005 12:17:46 +
> On Thu, Mar 24, 2005 at 07:14:24PM +0900, Hirokazu Takata wrote:
> > diff -ruNp a/include/asm-m32r/serial.h b/include/asm-m32r/serial.h
> > --- a/include/asm-m32r/serial.h 2004-12-25 06:35:40.0 +0900
> > +++ b/include/asm-m32r/serial.h 2005-03-24 17:25:05.812651363 +0900
>
> Can m32r accept PCMCIA cards? If so, this may mean that 8250.c gets
> built, which will use this file to determine where it should look for
> built-in 8250 ports.
>
> If this file is used to describe non-8250 compatible ports, you could
> end up with a nasty mess. Therefore, I recommend that you do not use
> asm-m32r/serial.h to describe your SIO ports.
>
> Instead, since these definitions are private to your own driver, you
> may consider moving them into the driver, or a header file closely
> associated with your driver in drivers/serial.
Signed-off-by: Hirokazu Takata <[EMAIL PROTECTED]>
---
drivers/serial/m32r_sio.c | 131 ++
include/asm-m32r/serial.h | 41 --
2 files changed, 31 insertions(+), 141 deletions(-)
diff -ruNp a/include/asm-m32r/serial.h b/include/asm-m32r/serial.h
--- a/include/asm-m32r/serial.h 2005-03-29 21:47:12.912822762 +0900
+++ b/include/asm-m32r/serial.h 2005-03-29 18:15:37.0 +0900
@@ -1,47 +1,10 @@
#ifndef _ASM_M32R_SERIAL_H
#define _ASM_M32R_SERIAL_H
-/*
- * include/asm-m32r/serial.h
- */
+/* include/asm-m32r/serial.h */
#include
-#include
-/*
- * This assumes you have a 1.8432 MHz clock for your UART.
- *
- * It'd be nice if someone built a serial card with a 24.576 MHz
- * clock, since the 16550A is capable of handling a top speed of 1.5
- * megabits/second; but this requires the faster clock.
- */
-#define BASE_BAUD ( 1843200 / 16 )
-
-/* Standard COM flags */
-#define STD_COM_FLAGS (ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST)
-
-/* Standard PORT definitions */
-#if defined(CONFIG_PLAT_USRV)
-
-#define STD_SERIAL_PORT_DEFNS \
- /* UART CLK PORT IRQFLAGS */ \
- { 0, BASE_BAUD, 0x3F8, PLD_IRQ_UART0, STD_COM_FLAGS }, /* ttyS0 */ \
- { 0, BASE_BAUD, 0x2F8, PLD_IRQ_UART1, STD_COM_FLAGS }, /* ttyS1 */
-
-#else /* !CONFIG_PLAT_USRV */
-
-#if defined(CONFIG_SERIAL_M32R_PLDSIO)
-#define STD_SERIAL_PORT_DEFNS \
- { 0, BASE_BAUD, ((unsigned long)PLD_ESIO0CR), PLD_IRQ_SIO0_RCV, \
- STD_COM_FLAGS }, /* ttyS0 */
-#else
-#define STD_SERIAL_PORT_DEFNS \
- { 0, BASE_BAUD, M32R_SIO_OFFSET, M32R_IRQ_SIO0_R, \
- STD_COM_FLAGS }, /* ttyS0 */
-#endif
-
-#endif /* !CONFIG_PLAT_USRV */
-
-#define SERIAL_PORT_DFNS STD_SERIAL_PORT_DEFNS
+#define BASE_BAUD 115200
#endif /* _ASM_M32R_SERIAL_H */
diff -ruNp a/drivers/serial/m32r_sio.c b/drivers/serial/m32r_sio.c
--- a/drivers/serial/m32r_sio.c 2005-03-29 21:47:12.924820913 +0900
+++ b/drivers/serial/m32r_sio.c 2005-03-29 21:56:38.001930365 +0900
@@ -54,13 +54,6 @@
#include "m32r_sio_reg.h"
/*
- * Configuration:
- * share_irqs - whether we pass SA_SHIRQ to request_irq(). This option
- *is unsafe when used on edge-triggered interrupts.
- */
-unsigned int share_irqs_sio = M32R_SIO_SHARE_IRQS;
-
-/*
* Debugging.
*/
#if 0
@@ -86,15 +79,36 @@ unsigned int share_irqs_sio = M32R_SIO_S
#include
+/* Standard COM flags */
+#define STD_COM_FLAGS (ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST)
+
/*
* SERIAL_PORT_DFNS tells us about built-in ports that have no
* standard enumeration mechanism. Platforms that can find all
* serial ports via mechanisms like ACPI or PCI need not supply it.
*/
-#ifndef SERIAL_PORT_DFNS
-#define SERIAL_PORT_DFNS
+#undef SERIAL_PORT_DFNS
+#if defined(CONFIG_PLAT_USRV)
+
+#define SERIAL_PORT_DFNS \
+ /* UART CLK PORT IRQFLAGS */ \
+ { 0, BASE_BAUD, 0x3F8, PLD_IRQ_UART0, STD_COM_FLAGS }, /* ttyS0 */ \
+ { 0, BASE_BAUD, 0x2F8, PLD_IRQ_UART1, STD_COM_FLAGS }, /* ttyS1 */
+
+#else /* !CONFIG_PLAT_USRV */
+
+#if defined(CONFIG_SERIAL_M32R_PLDSIO)
+#define SERIAL_PORT_DFNS \
+ { 0, BASE_BAUD, ((unsigned long)PLD_ESIO0CR), PLD_IRQ_SIO0_RCV, \
+ STD_COM_FLAGS }, /* ttyS0 */
+#else
+#define SERIAL_PORT_DFNS
Re: [PATCH] Re: Bitrotting serial drivers
From: Russell King <[EMAIL PROTECTED]> Date: Thu, 24 Mar 2005 12:17:46 + > On Thu, Mar 24, 2005 at 07:14:24PM +0900, Hirokazu Takata wrote: > > Could you please accept the following patch? > > Probably, but I'd like to have a reply to my comments below first. > > > diff -ruNp a/include/asm-m32r/serial.h b/include/asm-m32r/serial.h > > --- a/include/asm-m32r/serial.h 2004-12-25 06:35:40.0 +0900 > > +++ b/include/asm-m32r/serial.h 2005-03-24 17:25:05.812651363 +0900 > > Can m32r accept PCMCIA cards? If so, this may mean that 8250.c gets > built, which will use this file to determine where it should look for > built-in 8250 ports. > > If this file is used to describe non-8250 compatible ports, you could > end up with a nasty mess. Therefore, I recommend that you do not use > asm-m32r/serial.h to describe your SIO ports. I understand. You mean I have to keep 8250.c buildable for PCMCIA serial cards, if I make use of both m32r_sio and 8250 compatible drivers at a time, right? > Instead, since these definitions are private to your own driver, you > may consider moving them into the driver, or a header file closely > associated with your driver in drivers/serial. I will try to move these definitions into the m32r_sio driver. Please just a moment, I have no time to do it now... Thank you. -- Takata - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: Bitrotting serial drivers
On Thu, Mar 24, 2005 at 07:14:24PM +0900, Hirokazu Takata wrote: > Could you please accept the following patch? Probably, but I'd like to have a reply to my comments below first. > diff -ruNp a/include/asm-m32r/serial.h b/include/asm-m32r/serial.h > --- a/include/asm-m32r/serial.h 2004-12-25 06:35:40.0 +0900 > +++ b/include/asm-m32r/serial.h 2005-03-24 17:25:05.812651363 +0900 Can m32r accept PCMCIA cards? If so, this may mean that 8250.c gets built, which will use this file to determine where it should look for built-in 8250 ports. If this file is used to describe non-8250 compatible ports, you could end up with a nasty mess. Therefore, I recommend that you do not use asm-m32r/serial.h to describe your SIO ports. Instead, since these definitions are private to your own driver, you may consider moving them into the driver, or a header file closely associated with your driver in drivers/serial. -- Russell King Linux kernel2.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-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Re: Bitrotting serial drivers
Hi,
I made a patch to update m32r_sio driver.
Compile checked and tested on a M32700UT eva board with SMP kernel.
It looks working...
Could you please accept the following patch?
Thanks,
-- Takata
From: Russell King <[EMAIL PROTECTED]>
Date: Sat, 19 Mar 2005 17:21:01 +
> m32r_sio
>
>
> Maintainer: Hirokazu Takata
>
> Please clean up the m32r_sio driver, removing whatever bits of code
> aren't absolutely necessary.
>
> Specifically, I'd like to see the following addressed:
>
> - the usage of SERIAL_IO_HUB6
> (this driver doesn't support hub6 cards)
> - SERIAL_IO_* should be UPIO_*
> - __register_m32r_sio, register_m32r_sio, unregister_m32r_sio,
> m32r_sio_get_irq_map
> (this driver doesn't support PCMCIA cards, all of which are based on
>8250-compatible devices.)
__register_m32r_sio, register_m32r_sio, unregister_m32r_sio are
still remained. I'm going to take a look them after.
> - early_serial_setup
> (should we really have the function name duplicated across different
>hardware drivers?)
>
Signed-off-by: Hirokazu Takata <[EMAIL PROTECTED]>
---
drivers/serial/m32r_sio.c | 156 --
drivers/serial/m32r_sio.h |1
drivers/serial/m32r_sio_reg.h | 190 --
include/asm-m32r/serial.h | 142 ---
include/linux/serial_core.h |3
5 files changed, 59 insertions(+), 433 deletions(-)
diff -ruNp a/include/linux/serial_core.h b/include/linux/serial_core.h
--- a/include/linux/serial_core.h 2005-03-24 14:02:31.0 +0900
+++ b/include/linux/serial_core.h 2005-03-24 14:50:23.0 +0900
@@ -113,6 +113,9 @@
/* Samsung S3C2400 SoC */
#define PORT_S3C2400 67
+/* M32R SIO */
+#define PORT_M32R_SIO 68
+
#ifdef __KERNEL__
#include
diff -ruNp a/include/asm-m32r/serial.h b/include/asm-m32r/serial.h
--- a/include/asm-m32r/serial.h 2004-12-25 06:35:40.0 +0900
+++ b/include/asm-m32r/serial.h 2005-03-24 17:25:05.812651363 +0900
@@ -1,10 +1,6 @@
#ifndef _ASM_M32R_SERIAL_H
#define _ASM_M32R_SERIAL_H
-/* $Id$ */
-
-/* orig : i386 2.4.18 */
-
/*
* include/asm-m32r/serial.h
*/
@@ -21,131 +17,31 @@
*/
#define BASE_BAUD ( 1843200 / 16 )
-/* Standard COM flags (except for COM4, because of the 8514 problem) */
-#ifdef CONFIG_SERIAL_DETECT_IRQ
-#define STD_COM_FLAGS (ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST | ASYNC_AUTO_IRQ)
-#define STD_COM4_FLAGS (ASYNC_BOOT_AUTOCONF | ASYNC_AUTO_IRQ)
-#else
+/* Standard COM flags */
#define STD_COM_FLAGS (ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST)
-#define STD_COM4_FLAGS ASYNC_BOOT_AUTOCONF
-#endif
-
-#ifdef CONFIG_SERIAL_MANY_PORTS
-#define FOURPORT_FLAGS ASYNC_FOURPORT
-#define ACCENT_FLAGS 0
-#define BOCA_FLAGS 0
-#define HUB6_FLAGS 0
-#define RS_TABLE_SIZE 64
-#else
-#define RS_TABLE_SIZE
-#endif
-
-#define MCA_COM_FLAGS (STD_COM_FLAGS|ASYNC_BOOT_ONLYMCA)
-
-/*
- * The following define the access methods for the HUB6 card. All
- * access is through two ports for all 24 possible chips. The card is
- * selected through the high 2 bits, the port on that card with the
- * "middle" 3 bits, and the register on that port with the bottom
- * 3 bits.
- *
- * While the access port and interrupt is configurable, the default
- * port locations are 0x302 for the port control register, and 0x303
- * for the data read/write register. Normally, the interrupt is at irq3
- * but can be anything from 3 to 7 inclusive. Note that using 3 will
- * require disabling com2.
- */
-#define C_P(card,port) (((card)<<6|(port)<<3) + 1)
+/* Standard PORT definitions */
+#if defined(CONFIG_PLAT_USRV)
-#define STD_SERIAL_PORT_DEFNS \
- /* UART CLK PORT IRQ FLAGS*/ \
- { 0, BASE_BAUD, 0x3F8, 4, STD_COM_FLAGS }, /* ttyS0 */ \
- { 0, BASE_BAUD, 0x2F8, 3, STD_COM_FLAGS }, /* ttyS1 */ \
- { 0, BASE_BAUD, 0x3E8, 4, STD_COM_FLAGS }, /* ttyS2 */ \
- { 0, BASE_BAUD, 0x2E8, 3, STD_COM4_FLAGS }, /* ttyS3 */
-
-
-#ifdef CONFIG_SERIAL_MANY_PORTS
-#define EXTRA_SERIAL_PORT_DEFNS\
- { 0, BASE_BAUD, 0x1A0, 9, FOURPORT_FLAGS }, /* ttyS4 */ \
- { 0, BASE_BAUD, 0x1A8, 9, FOURPORT_FLAGS }, /* ttyS5 */ \
- { 0, BASE_BAUD, 0x1B0, 9, FOURPORT_FLAGS }, /* ttyS6 */ \
- { 0, BASE_BAUD, 0x1B8, 9, FOURPORT_FLAGS }, /* ttyS7 */ \
- { 0, BASE_BAUD, 0x2A0, 5, FOURPORT_FLAGS }, /* ttyS8 */ \
- { 0, BASE_BAUD, 0x2A8, 5, FOURPORT_FLAGS }, /* ttyS9 */ \
- { 0, BASE_BAUD, 0x2B0, 5, FOURPORT_FLAGS }, /* ttyS10 */\
- { 0, BASE_BAUD, 0x2B8, 5, FOURPORT_FLAGS }, /* ttyS11 */\
- { 0, BASE_BAUD, 0x330, 4, ACCENT_FLAGS }, /* ttyS12 */\
- { 0, BASE_BAUD, 0x338, 4, ACCENT_FLAGS }, /* ttyS13 */\
- { 0, BASE_BAUD, 0x000, 0, 0 }, /* ttyS14 (spare) */\
- { 0,
Re: Bitrotting serial drivers
If we leave the driver for the au1x00 as it is it should not have the register_serial / unregister_serial functions and it should be renamed to something else, e.g. ttySAxxx like it is done for the internal serial port of the strongarm (sa1100). I have thought about the serial driver and came along this. I we take a look at the hardware, we have a chip, the 8250 and its successors and the chip is integrated into some kind of hardware. So the chip has an interface. It has some address lines for register access, it has data lines and some controll lines. It also has an interrupt pin, some (GP)IO-Pins, that are freely programmable and a clock input. The chip is integrated thru some interface as I mentioned before. It can be an ISA-IO card or a PCI card or a multiport card, where more than one chip is accessed thru the same io-range and the hip to access is selected thru a single register. The au1x00 serial driver is like an ISA card except that the chip is mapped to a memory region instead of an io-region and the fact, that we can calculate the baud_base using the pll configuration of the au1x00, if we assume a 12MHz oscilator, which is standard for the au1x00. We need some access methods to access the chip registers, some way to handle intterupts, some way to deal with the gpio-pins, and we need a way to get the clock input of the chip. What should the serial-chip driver know about and what should the card driver know about. It's like the streams concept, where the chip driver does not know how to access the chip or what resources it uses, but what to do with the chip. Regards, Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bitrotting serial drivers
Russell King wrote: On Sun, Mar 20, 2005 at 02:51:40PM -0800, Pete Popov wrote: - __register_serial, register_serial, unregister_serial (this driver doesn't support PCMCIA cards, all of which are based on 8250-compatible devices.) I tried a couple of times to cleanly add support to the 8250 for the Au1x serial. The uart is just different enough to make that hard, though I admit I never spent too much time on it. Sounds like it's time to revisit it again. I would prefer to have a patch to remove (or ack to do so myself) the above three mentioned functions so I can avoid breaking your driver, rather than a large update to it. Go for it. I'll test the driver afterwards and think about getting it into the 8250 again. Thanks, Pete - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bitrotting serial drivers
On Sun, Mar 20, 2005 at 02:51:40PM -0800, Pete Popov wrote: > >>>- __register_serial, register_serial, unregister_serial > >>> (this driver doesn't support PCMCIA cards, all of which are based on > >>> 8250-compatible devices.) > > I tried a couple of times to cleanly add support to the 8250 for the Au1x > serial. The uart is just different enough to make that hard, though I admit I > never spent too much time on it. Sounds like it's time to revisit it again. I would prefer to have a patch to remove (or ack to do so myself) the above three mentioned functions so I can avoid breaking your driver, rather than a large update to it. Thanks. -- Russell King Linux kernel2.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-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bitrotting serial drivers
Ralf Baechle wrote: On Sat, Mar 19, 2005 at 02:13:51PM -0800, Andrew Morton wrote: au1x00_uart --- Maintainer: unknown (akpm - any ideas?) Ralf. Actually Pete Popov ([EMAIL PROTECTED]) who I put on the cc. Thanks :) This is a complete clone of 8250.c, which includes all the 8250-specific structure names. Specifically, I'd like to see the following addressed: - Please clean this up to use au1x00-specific names. - this driver is lagging behind with fixes that the other drivers are getting. Is au1x00_uart actually maintained? Sort of; much of the Alchemy development effort is still going into 2.4. It works and no one has complained about any bugs. But you're right, fixes going into other drivers have not made it into this one. - the usage of UPIO_HUB6 (this driver doesn't support hub6 cards) - __register_serial, register_serial, unregister_serial (this driver doesn't support PCMCIA cards, all of which are based on 8250-compatible devices.) - early_serial_setup (should we really have the function name duplicated across different hardware drivers?) No argument here. Pete says the AMD Alchemy UART is just different enough to be hard to handle in the 8250 and so the driver is just an ugly chainsawed version of the 8250.c The main reason is I wish to kill off uart_register_port and uart_unregister_port, but these drivers are using it. I tried a couple of times to cleanly add support to the 8250 for the Au1x serial. The uart is just different enough to make that hard, though I admit I never spent too much time on it. Sounds like it's time to revisit it again. Pete - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bitrotting serial drivers
On Sat, Mar 19, 2005 at 02:13:51PM -0800, Andrew Morton wrote: > > au1x00_uart > > --- > > > > Maintainer: unknown (akpm - any ideas?) > > Ralf. Actually Pete Popov ([EMAIL PROTECTED]) who I put on the cc. > > This is a complete clone of 8250.c, which includes all the 8250-specific > > structure names. > > > > Specifically, I'd like to see the following addressed: > > > > - Please clean this up to use au1x00-specific names. > > - this driver is lagging behind with fixes that the other drivers are > > getting. Is au1x00_uart actually maintained? Sort of; much of the Alchemy development effort is still going into 2.4. > > - the usage of UPIO_HUB6 > > (this driver doesn't support hub6 cards) > > - __register_serial, register_serial, unregister_serial > > (this driver doesn't support PCMCIA cards, all of which are based on > >8250-compatible devices.) > > - early_serial_setup > > (should we really have the function name duplicated across different > >hardware drivers?) No argument here. Pete says the AMD Alchemy UART is just different enough to be hard to handle in the 8250 and so the driver is just an ugly chainsawed version of the 8250.c > > The main reason is I wish to kill off uart_register_port and > > uart_unregister_port, but these drivers are using it. Ralf - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bitrotting serial drivers
Russell King <[EMAIL PROTECTED]> wrote: > > Hi, > > m32r_sio > > > Maintainer: Hirokazu Takata > > Please clean up the m32r_sio driver, removing whatever bits of code > aren't absolutely necessary. > > Specifically, I'd like to see the following addressed: > > - the usage of SERIAL_IO_HUB6 > (this driver doesn't support hub6 cards) > - SERIAL_IO_* should be UPIO_* > - __register_m32r_sio, register_m32r_sio, unregister_m32r_sio, > m32r_sio_get_irq_map > (this driver doesn't support PCMCIA cards, all of which are based on >8250-compatible devices.) > - early_serial_setup > (should we really have the function name duplicated across different >hardware drivers?) > > au1x00_uart > --- > > Maintainer: unknown (akpm - any ideas?) Ralf. > This is a complete clone of 8250.c, which includes all the 8250-specific > structure names. > > Specifically, I'd like to see the following addressed: > > - Please clean this up to use au1x00-specific names. > - this driver is lagging behind with fixes that the other drivers are > getting. Is au1x00_uart actually maintained? > - the usage of UPIO_HUB6 > (this driver doesn't support hub6 cards) > - __register_serial, register_serial, unregister_serial > (this driver doesn't support PCMCIA cards, all of which are based on >8250-compatible devices.) > - early_serial_setup > (should we really have the function name duplicated across different >hardware drivers?) > > The main reason is I wish to kill off uart_register_port and > uart_unregister_port, but these drivers are using it. > > Thanks. > > -- > Russell King > Linux kernel2.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-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Bitrotting serial drivers
Hi, m32r_sio Maintainer: Hirokazu Takata Please clean up the m32r_sio driver, removing whatever bits of code aren't absolutely necessary. Specifically, I'd like to see the following addressed: - the usage of SERIAL_IO_HUB6 (this driver doesn't support hub6 cards) - SERIAL_IO_* should be UPIO_* - __register_m32r_sio, register_m32r_sio, unregister_m32r_sio, m32r_sio_get_irq_map (this driver doesn't support PCMCIA cards, all of which are based on 8250-compatible devices.) - early_serial_setup (should we really have the function name duplicated across different hardware drivers?) au1x00_uart --- Maintainer: unknown (akpm - any ideas?) This is a complete clone of 8250.c, which includes all the 8250-specific structure names. Specifically, I'd like to see the following addressed: - Please clean this up to use au1x00-specific names. - this driver is lagging behind with fixes that the other drivers are getting. Is au1x00_uart actually maintained? - the usage of UPIO_HUB6 (this driver doesn't support hub6 cards) - __register_serial, register_serial, unregister_serial (this driver doesn't support PCMCIA cards, all of which are based on 8250-compatible devices.) - early_serial_setup (should we really have the function name duplicated across different hardware drivers?) The main reason is I wish to kill off uart_register_port and uart_unregister_port, but these drivers are using it. Thanks. -- Russell King Linux kernel2.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-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
