Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: Sergei Shtylyov <sshtylyov@dev.rtsoft.ru>
To: Russell King <rmk@arm.linux.org.uk>
Cc: Atsushi Nemoto <anemo@mba.ocn.ne.jp>,
	linux-mips@linux-mips.org, ralf@linux-mips.org
Subject: Re: [PATCH] serial_txx9: forcibly init the spinlock for PCI UART used as a console
Date: Tue, 27 Dec 2005 22:31:53 +0300	[thread overview]
Message-ID: <43B196A9.8010608@dev.rtsoft.ru> (raw)
In-Reply-To: <43B18DD2.3090206@ru.mvista.com>

Hello.

Sergei Shtylylov wrote:

>> no need to pre-register all the uart ports at driver initialisation
>> time.  Consequently, there's no need to remove them all when you
>> remove the module.

>    Hm, then the driver would need to keep track of which ports it has 
> registered and which it has not...

    However, it does this already in a way, via port type.

>  > Secondly, the upshot of this is that you only call uart_add_one_port()
>  > when you initialise a PCI card.

>    Not the case as I've said; uart_add_one_port() should be called on 
> driver startup anyway...

>> This should result in a cleaner implementation, and the console will
>> not be started until you detect the PCI card.

>    It will still be started with the console_initcall() in this driver, 
> if that code is not also deleted...

    That doesn't matter. Driver init time uart_add_one_port() calls to 
register SOC UARTs will result in register_console() being called multiple 
times unsuccesfully anyway before we get to the PCI UART to which the console 
is assigned.
    All in all, the problem of uninit'ed PCI port spinlock will remain unless 
serial core is fixed (ot at least the driver). Proposed driver re-design 
wouldn't help as this is actually chicken-before-egg type problem -- 
uart_add_one_port() assumes that the console is setup beforehand, and this 
just can't happen in case of a PCI card.

WBR, Sergei

  reply	other threads:[~2005-12-27 19:28 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-26 22:24 [PATCH] serial_txx9: forcibly init the spinlock for PCI UART used as a console Sergei Shtylylov
2005-12-27  5:45 ` Atsushi Nemoto
2005-12-27 13:38   ` Sergei Shtylylov
2005-12-27 15:34     ` Atsushi Nemoto
2005-12-27 16:29       ` Sergei Shtylylov
2005-12-27 18:41       ` Russell King
2005-12-27 18:54         ` Sergei Shtylylov
2005-12-27 19:31           ` Sergei Shtylyov [this message]
2005-12-28  4:25         ` Atsushi Nemoto
2005-12-29 16:32           ` Atsushi Nemoto
2006-01-05 15:14         ` Atsushi Nemoto

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=43B196A9.8010608@dev.rtsoft.ru \
    --to=sshtylyov@dev.rtsoft.ru \
    --cc=anemo@mba.ocn.ne.jp \
    --cc=linux-mips@linux-mips.org \
    --cc=ralf@linux-mips.org \
    --cc=rmk@arm.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox