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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
