Re: [RFC PATCH] ARM: omap2plus_defconfig: Switch over to using 8250 driver

[Peter Hurley <peter@hurleysoftware.com>]

On 04/11/2015 02:27 PM, Nishanth Menon wrote:
> 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

Just an FYI - support for handling of _any_ console command line
string by _any_ driver was accepted for 4.01; the console can
declare a match() function which will be called at registration time
for every console command line, and can opt to perform console setup
using any criteria.

This provides a migration path for _any_ driver (and also allow any
earlycon-to-console handoff for non-8250 drivers by using a defined
match() function to match the appropriate earlycon= command line; the
particulars are in the univ8250_console_match() kernel-doc header in
-next).


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

I think for the moment we should just freeze omap-serial and let
most of userspace catch up first; a lot of the official and
unofficial vender support is still stuck in 3.14. By the time,
3.19+ is de rigueur we'll hopefully have figured out the ttyS
sharing and how to migrate without breaking userspace.

> Btw, I am not exactly proposing this for 4.1 kernel..

:) I knew that.

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

I agree -- thanks for bringing the topic up.

Regards,
Peter Hurley