On 04/11/2015 02:40 PM, Peter Hurley wrote: > 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). OK. > > >> 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. > How about the folks stuck on older distros like Maemo N900? -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
