All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.