linux-serial.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Scott Wood <scottwood@freescale.com>
To: Arnd Bergmann <arnd@arndb.de>
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: Fri, 2 Oct 2015 18:49:24 -0500	[thread overview]
Message-ID: <1443829764.5336.213.camel@freescale.com> (raw)
In-Reply-To: <5286230.7Dic6OMiYf@wuerfel>

On Sat, 2015-10-03 at 00:22 +0200, Arnd Bergmann wrote:
> On Thursday 01 October 2015 19:16:16 Scott Wood wrote:
> > 
> > +#ifdef CONFIG_SERIAL_8250_FSL
> > +       if (of_device_is_compatible(np, "fsl,ns16550") ||
> > +           of_device_is_compatible(np, "fsl,16550-FIFO64"))
> > +               port->handle_irq = fsl8250_handle_irq;
> > +#endif
> > +
> > 
> 
> Can you change this to use
> 
>       if (IS_ENABLED(CONFIG_SERIAL_8250_FSL)) && ...
> 
> The resulting code will be the same, it just get a little easier
> on the eye.

Sure.

> 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.

-Scott

  reply	other threads:[~2015-10-02 23:49 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 [this message]
2015-10-06 13:09     ` Arnd Bergmann
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=1443829764.5336.213.camel@freescale.com \
    --to=scottwood@freescale.com \
    --cc=arnd@arndb.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-serial@vger.kernel.org \
    --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;
as well as URLs for NNTP newsgroup(s).