linux-omap.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nishanth Menon <nm@ti.com>
To: Peter Hurley <peter@hurleysoftware.com>, Sekhar Nori <nsekhar@ti.com>
Cc: linux-omap@vger.kernel.org,
	Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	Tony Lindgren <tony@atomide.com>
Subject: Re: [RFC PATCH] ARM: omap2plus_defconfig: Switch over to using 8250 driver
Date: Sat, 11 Apr 2015 13:27:44 -0500	[thread overview]
Message-ID: <552967A0.9080804@ti.com> (raw)
In-Reply-To: <55282737.8060407@hurleysoftware.com>

On 04/10/2015 02:40 PM, Peter Hurley wrote:
> [ +Sebastian, +Tony ]
> 
> On 04/10/2015 02:18 PM, Nishanth Menon wrote:
>> 8250 driver should be relatively feature complete. It can co-exist
>> with omap-serial driver
> 
> Not really; if the omap_8250 is selected then it is probed first
> and will be the only driver claiming omap UART ports.
> 
> omap-serial would just be dead-weight.

true.. my bad..

> 
>> , so just enable 8250 OMAP layer driver and
>> route all ttyOx references to ttySx through the standard 8250 driver
>> to ensure no breakage of userspace occurs.
> 
> Not quite; the only automatic handling is for console only, not for
> userspace. Expect lots of userspace breakage.
> 


Yep - overall, looking through individual logs, in my testing, it seems
to work at least for console for all platforms - even though the
filesystems are mostly going bonkers -> older fs did not have the udev
redirection to take care of this - mostly to do with the getty hooked on
to static consoles.


There are infact two issues:
a) bootloader change for cmdline -> O2 to S2 -> in many cases we are
lesser inclined to change the bootloader, hence the fixup configuration
b) fs changes - these are sometimes more realistic to do, but is a clear
breakage risk.


Overall, keeping two equally functional drivers in the system sounds a
bunch of maintenance burden for all of us and not to mention confusion
for the future.


Btw, I am not exactly proposing this for 4.1 kernel.. instead, we should
probably discuss how to best introduce this in and throw out the older
omap_serial driver - just reuse 8250 and co-exist with the rest of the
good world folks ;)..


-- 
Regards,
Nishanth Menon

  reply	other threads:[~2015-04-11 18:28 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-10 18:18 [RFC PATCH] ARM: omap2plus_defconfig: Switch over to using 8250 driver Nishanth Menon
2015-04-10 19:40 ` Peter Hurley
2015-04-11 18:27   ` Nishanth Menon [this message]
2015-04-11 19:40     ` Peter Hurley
2015-04-12  0:23       ` Nishanth Menon
2015-04-13  7:43         ` Sebastian Andrzej Siewior

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=552967A0.9080804@ti.com \
    --to=nm@ti.com \
    --cc=bigeasy@linutronix.de \
    --cc=linux-omap@vger.kernel.org \
    --cc=nsekhar@ti.com \
    --cc=peter@hurleysoftware.com \
    --cc=tony@atomide.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).