public inbox for linux-serial@vger.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Scott Wood <scottwood@freescale.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Stuart Yoder <stuart.yoder@freescale.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-serial@vger.kernel.org
Subject: Re: [PATCH] serial: Enable Freescale 16550 workaround on arm
Date: Tue, 06 Oct 2015 15:09:45 +0200	[thread overview]
Message-ID: <6203935.y4enCic7De@wuerfel> (raw)
In-Reply-To: <1443829764.5336.213.camel@freescale.com>

On Friday 02 October 2015 18:49:24 Scott Wood wrote:
> > Other than that, I wonder if we should do this completely differently
> > and have the respective entries in of_platform_serial_table[] with
> > an appropriate PORT_* constant to handle the freescale case.
> 
> I'd considered that, but it seemed like it would be more complicated, with no 
> real benefit.  We'd need to add a new PORT for the non-fifo64 case, and it 
> would need to otherwise behave like PORT_16550A.  There's no room for an 
> extra 8250-style PORT number unless we break PORT_MAX_8250 or renumber the 
> "ARM specific type numbers", and for some reason these PORT numbers are 
> defined in uapi (even if there's some legacy reason for that, do we really 
> need to keep adding to it?).  We'd also need to make sure that autoconfig() 
> doesn't overwrite the new PORT number (or ignore the fact that it gets 
> overwritten after using it to substitute handle_irq).  It would also increase 
> the discrepancy between how the same issue is handled on ARM versus PPC (with 
> the latter using arch/powerpc/kernel/legacy_serial.c which doesn't supply 
> PORT numbers).
> 
> The above check wouldn't go away, as it's not something currently addressed 
> by struct serial8250_config (unless you're also asking for a new flag for 
> that struct, in which case it would merely be moved elsewhere); it would just 
> require a bunch of changes elsewhere to support changing it from a simple 
> compatible check to a PORT check.

Ok, let's keep your version then, unless someone has a better idea.

FWIW, I think we should just move of_serial.c to drivers/tty/serial/8250/
now and remove the nwp specific bits.

Looking for a volunteer to actually do that work ;-)

	Arnd

  reply	other threads:[~2015-10-06 13:09 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-02  0:16 [PATCH] serial: Enable Freescale 16550 workaround on arm Scott Wood
2015-10-02 22:22 ` Arnd Bergmann
2015-10-02 23:49   ` Scott Wood
2015-10-06 13:09     ` Arnd Bergmann [this message]
2015-10-07 22:31 ` [PATCH v2] " Scott Wood
2015-10-08  7:45   ` Arnd Bergmann

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=6203935.y4enCic7De@wuerfel \
    --to=arnd@arndb.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=scottwood@freescale.com \
    --cc=stuart.yoder@freescale.com \
    /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