On Thu, Jul 3, 2014 at 8:25 AM, Felipe Balbi <ba...@ti.com> wrote: > On Thu, Jul 03, 2014 at 12:34:11AM -0700, Tony Lindgren wrote: >> * Robert Nelson <robertcnel...@gmail.com> [140702 12:27]: >> > On Wed, Jul 2, 2014 at 2:09 PM, Aaro Koskinen <aaro.koski...@iki.fi> wrote: >> > > Hi, >> > > >> > > On Wed, Jul 02, 2014 at 11:09:32AM -0500, Felipe Balbi wrote: >> > >> > It has been only tested as console UART. >> > >> > The tty name is ttyS based instead of ttyO. How big is the pain here, >> > >> > what could be the easiest way to provide compatibility? >> > >> >> > >> have been considering that myself for months. You could pass an optional >> > >> argument to serial8250_register_8250_port() but that only solves part of >> > >> the problem :-( >> >> Some kind of compability layer sure would be nice. >> >> > > When ttyS -> ttyO change was done on OMAP, compatibility was not an >> > > issue. >> > > Why should we care about it now? >> > >> > It would be a good opportunity to force everyone to update their >> > bootloader. ;) >> > >> > Besides the BeagleBoard forum is quiet now, no one is complaining >> > about that old (ttyS -> ttyO) transition anymore.. >> >> How about a Kconfig option to provide ttyO by default? The not even >> do that if kernel has cmdline option nottyomap. > > what about single zImage ? I don't want to use ttyO on my > Allwinner/Exynos/Snapdragon/whatever SoC just because OMAP is in the > same image ;-)
What if we just kept it simple, leave the ttyO driver enabled and add a warning (pr_info) that it's deprecated. It's not like it's broken, it just won't get later features or devices support added. Regards, -- Robert Nelson http://www.rcn-ee.com/ -- 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
