From: Russell King <rmk+lkml@arm.linux.org.uk>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Linux Kernel list <linux-kernel@vger.kernel.org>
Subject: Re: uart_match_port() question
Date: Mon, 28 Nov 2005 11:30:20 +0000 [thread overview]
Message-ID: <20051128113020.GA30298@flint.arm.linux.org.uk> (raw)
In-Reply-To: <1133050906.7768.66.camel@gaston>
On Sun, Nov 27, 2005 at 11:21:46AM +1100, Benjamin Herrenschmidt wrote:
> Hi Russel, would you accept a patch like that:
s/l,/l&/
> Index: linux-work/drivers/serial/serial_core.c
> ===================================================================
> --- linux-work.orig/drivers/serial/serial_core.c 2005-11-14 20:32:16.000000000 +1100
> +++ linux-work/drivers/serial/serial_core.c 2005-11-27 11:13:54.000000000 +1100
> @@ -2307,7 +2307,8 @@
> return (port1->iobase == port2->iobase) &&
> (port1->hub6 == port2->hub6);
> case UPIO_MEM:
> - return (port1->membase == port2->membase);
> + return (port1->membase == port2->membase) ||
> + (port1->mapbase && port1->mapbase == port2->mapbase);
> }
> return 0;
> }
I don't think so. (see below)
> The reason is a bit complicated, but basically, we have some arch code
> that builds a list of available serial ports very early and registers that
> as a platform device. It also detects which one is the default firmware port
> and what speed it's been configured for and builds a proper config line to
> pass to add_preferred_console() so we get the default serial console setup
> properly automatically.
>
> This list includes however ports that are on PCI devices on some recent
> machines. Thus, we need to make sure that, when 8250_pci.c kicks in, it
> property detects that those platform ports are the same it's discovered
> and thus properly re-uses the same port & minor. However, while that works
> for PIO ports, it doesn't for MMIO since membase is obtained from ioremap,
> and thus will be different between the port registered at boot and the
> value passed by the PCI code. Only mapbase will be the same.
>
> If we just skipped PCI devices in our early discovery code (thus letting
> 8250_pci.c alone discover them), we would be unable to use them for very
> early console output, and we would be unable to "know" what their minor number
> will be, and thus build an appropriate argument string for add_preferred_console(),
> which means we would be unable to have the console automatically pick the port
> that we set by the firmware and at the right speed, which basically means
> console not working for users.
Looking at this deeper, I think we should _only_ use mapbase in this
case. membase is really a indeterminant cookie which bears no real
relationship to whether two ports are identical - in fact, if we are
going to compare two of these cookies, I think arch code should be
involved.
So how about:
- return (port1->membase == port2->membase);
+ return (port1->mapbase == port2->mapbase);
?
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
next prev parent reply other threads:[~2005-11-28 11:30 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-27 0:21 uart_match_port() question Benjamin Herrenschmidt
2005-11-28 11:30 ` Russell King [this message]
2005-11-28 11:36 ` Benjamin Herrenschmidt
2005-12-07 22:15 ` Bjorn Helgaas
2005-12-07 23:13 ` Benjamin Herrenschmidt
2005-12-07 23:36 ` Bjorn Helgaas
2005-12-08 0:17 ` Benjamin Herrenschmidt
2005-12-08 16:26 ` Bjorn Helgaas
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=20051128113020.GA30298@flint.arm.linux.org.uk \
--to=rmk+lkml@arm.linux.org.uk \
--cc=benh@kernel.crashing.org \
--cc=linux-kernel@vger.kernel.org \
/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