Re: [CFT] Don't use ASYNC_* nor SERIAL_IO_* with serial_core

From: Hirokazu Takata
Date: Thu Feb 02 2006 - 09:09:06 EST


On m32r,
compile and boot test: OK

Thank you.

-- Takata

From: Russell King <rmk+lkml@xxxxxxxxxxxxxxxx>
Date: Thu, 02 Feb 2006 10:27:21 +0000
> Ping?
>
> On Sat, Jan 21, 2006 at 09:14:07PM +0000, Russell King wrote:
> > The serial_core layer has its own definitions for these, and I'd
> > appreciate it if folk would use them instead of the old ASYNC_* and
> > SERIAL_IO_* definitions.
> >
> > They're compatible _at the moment_ but I make no guarantees that they
> > will stay that way. Hence, it's in your interest to ensure that you're
> > using the correct definitions.
> >
> > MIPS, PPC seem to be the architectures which are stuck in the past on
> > this issue, as is the M32R SIO driver.
> >
> > The ioc4_serial driver is worse. It assumes that it can set/clear
> > ASYNC_CTS_FLOW in the uart_info flags field, which is private to
> > serial_core. It also seems to set TTY_IO_ERROR followed by immediately
> > clearing it (pointless), and then it writes to tty->alt_speed... which
> > isn't used by the serial layer so is also pointless.
> >
> > So, here's a patch to fix some of this crap up. Please test and
> > enjoy - I certainly didn't.
...
> > drivers/serial/m32r_sio.c | 2 +-
> > 18 files changed, 32 insertions(+), 51 deletions(-)
...
> > +++ b/arch/mips/cobalt/setup.c
> > diff --git a/drivers/serial/m32r_sio.c b/drivers/serial/m32r_sio.c
> > --- a/drivers/serial/m32r_sio.c
> > +++ b/drivers/serial/m32r_sio.c
> > @@ -80,7 +80,7 @@
> > #include <asm/serial.h>
> >
> > /* Standard COM flags */
> > -#define STD_COM_FLAGS (ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST)
> > +#define STD_COM_FLAGS (UPF_BOOT_AUTOCONF | UPF_SKIP_TEST)
> >
> > /*
> > * SERIAL_PORT_DFNS tells us about built-in ports that have no
>
> --
> 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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/