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
next prev parent 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