From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Russell King <rmk@arm.linux.org.uk>
Cc: Linux Kernel list <linux-kernel@vger.kernel.org>
Subject: uart_match_port() question
Date: Sun, 27 Nov 2005 11:21:46 +1100 [thread overview]
Message-ID: <1133050906.7768.66.camel@gaston> (raw)
Hi Russel, would you accept a patch like that:
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;
}
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.
Cheers,
Ben.
next reply other threads:[~2005-11-27 0:27 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-27 0:21 Benjamin Herrenschmidt [this message]
2005-11-28 11:30 ` uart_match_port() question Russell King
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=1133050906.7768.66.camel@gaston \
--to=benh@kernel.crashing.org \
--cc=linux-kernel@vger.kernel.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