[PATCH 1/1] Char: mxsers, correct tty driver name

[PATCH 1/1] Char: mxsers, correct tty driver name

[Jiri Slaby]

mxsers, correct tty driver name

Mxser tty driver name should be ttyMI, not ttyM. Correct this in both
drivers (mxser, mxser_new) to avoid conflicts with isicom driver, which is
ttyM.

Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Jiri Slaby <jirislaby@gmail.com>

---
commit 3202b22139e878e0e4366c82fe166b51f0b920eb
tree 6126febd2a79c4b87751c259745fa40c442b5d60
parent d84ab77817b1844e1f813c58d0a0eaf2f33c3206
author Jiri Slaby <jirislaby@gmail.com> Thu, 19 Oct 2006 16:04:49 +0200
committer Jiri Slaby <jirislaby@gmail.com> Thu, 19 Oct 2006 16:04:49 +0200

 drivers/char/mxser.c     |    4 ++--
 drivers/char/mxser_new.c |    2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/char/mxser.c b/drivers/char/mxser.c
index 5e69e45..7416b9b 100644
--- a/drivers/char/mxser.c
+++ b/drivers/char/mxser.c
@@ -557,7 +557,7 @@ static int mxser_initbrd(int board, stru
 	n = board * MXSER_PORTS_PER_BOARD;
 	info = &mxvar_table[n];
 	/*if (verbose) */  {
-		printk(KERN_DEBUG "        ttyM%d - ttyM%d ",
+		printk(KERN_DEBUG "        ttyMI%d - ttyMI%d ",
 			n, n + hwconf->ports - 1);
 		printk(" max. baud rate = %d bps.\n",
 			hwconf->MaxCanSetBaudRate[0]);
@@ -718,7 +718,7 @@ static int mxser_init(void)
 	/* Initialize the tty_driver structure */
 	memset(mxvar_sdriver, 0, sizeof(struct tty_driver));
 	mxvar_sdriver->magic = TTY_DRIVER_MAGIC;
-	mxvar_sdriver->name = "ttyM";
+	mxvar_sdriver->name = "ttyMI";
 	mxvar_sdriver->major = ttymajor;
 	mxvar_sdriver->minor_start = 0;
 	mxvar_sdriver->num = MXSER_PORTS + 1;
diff --git a/drivers/char/mxser_new.c b/drivers/char/mxser_new.c
index d212ae6..074f84c 100644
--- a/drivers/char/mxser_new.c
+++ b/drivers/char/mxser_new.c
@@ -2683,7 +2683,7 @@ static int __init mxser_module_init(void
 
 	/* Initialize the tty_driver structure */
 	mxvar_sdriver->magic = TTY_DRIVER_MAGIC;
-	mxvar_sdriver->name = "ttyM";
+	mxvar_sdriver->name = "ttyMI";
 	mxvar_sdriver->major = ttymajor;
 	mxvar_sdriver->minor_start = 0;
 	mxvar_sdriver->num = MXSER_PORTS + 1;

Re: [PATCH 1/1] Char: mxsers, correct tty driver name

[Alan Cox]

Ar Iau, 2006-10-19 am 16:10 +0200, ysgrifennodd Jiri Slaby:
> mxsers, correct tty driver name
> 
> Mxser tty driver name should be ttyMI, not ttyM. Correct this in both
> drivers (mxser, mxser_new) to avoid conflicts with isicom driver, which is
> ttyM.
> 
> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
> Signed-off-by: Jiri Slaby <jirislaby@gmail.com>

Acked-by: Alan Cox <alan@redhat.com>

Re: [PATCH 1/1] Char: mxsers, correct tty driver name

[Andrew Morton]

On Thu, 19 Oct 2006 16:10:10 +0200
Jiri Slaby <jirislaby@gmail.com> wrote:

> Mxser tty driver name should be ttyMI, not ttyM. Correct this in both
> drivers (mxser, mxser_new) to avoid conflicts with isicom driver, which is
> ttyM.

Is the mxser.c part needed in mainline?

Re: [PATCH 1/1] Char: mxsers, correct tty driver name

[Jiri Slaby]

Andrew Morton wrote:
> On Thu, 19 Oct 2006 16:10:10 +0200
> Jiri Slaby <jirislaby@gmail.com> wrote:
> 
>> Mxser tty driver name should be ttyMI, not ttyM. Correct this in both
>> drivers (mxser, mxser_new) to avoid conflicts with isicom driver, which is
>> ttyM.
> 
> Is the mxser.c part needed in mainline?

Anybody more responsible doesn't tell anything; I say "no", but it may be
irrelevant.

regards,
-- 
http://www.fi.muni.cz/~xslaby/            Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8  22A0 32CC 55C3 39D4 7A7E

Re: [PATCH 1/1] Char: mxsers, correct tty driver name

[Alan Cox]

Ar Sad, 2006-10-21 am 00:56 +0159, ysgrifennodd Jiri Slaby:
> Andrew Morton wrote:
> > On Thu, 19 Oct 2006 16:10:10 +0200
> > Jiri Slaby <jirislaby@gmail.com> wrote:
> > 
> >> Mxser tty driver name should be ttyMI, not ttyM. Correct this in both
> >> drivers (mxser, mxser_new) to avoid conflicts with isicom driver, which is
> >> ttyM.
> > 
> > Is the mxser.c part needed in mainline?
> 
> Anybody more responsible doesn't tell anything; I say "no", but it may be
> irrelevant.

I think it should go into -mm for a first cut just in case it blows
anything up. I don't think the hardware has many users any more so
hopefully it wont be disruptive.