tty: serial: serial-omap: depend on !8250_omap
PATCH 1/1 tty: serial: serial-omap: depend on !8250_omap
Technically speaking this is not required. If both are enabled then the Maikefile order says that 8250 one wins, the second is never probed.
If we choose to enable 8250_omap via defconfig then one might get supprised that his console isn't working anymore since nothing says use ttySx instead ttyOx.
This patch _tries_ to bring this to the users' attention by not showing the serial-omap driver once the 8250 one is enabled. So the user might choose to use the help text which says that this driver (8250_omap) uses ttySx instead ttyOx.
---
This is my attempt to warn the defconfig user of the defconfig change (which did not yet happen). Any suggestions?
drivers/tty/serial/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/tty/serial/Kconfig +1 -1
@@ -1125,7 +1125,7 @@ config SERIAL_OF_PLATFORM config SERIAL_OMAP tristate "OMAP serial port support" - depends on ARCH_OMAP2PLUS + depends on ARCH_OMAP2PLUS && !SERIAL_8250_OMAP select SERIAL_CORE help If you have a machine based on an Texas Instruments OMAP CPU you
Signature · 1 line
2.1.3
Quoted 11 lines · * Sebastian Andrzej Siewior | 2014-11-26 23:01:46 [+0100]:
Technically speaking this is not required. If both are enabled then the Maikefile order says that 8250 one wins, the second is never probed.
If we choose to enable 8250_omap via defconfig then one might get supprised that his console isn't working anymore since nothing says use ttySx instead ttyOx.
This patch _tries_ to bring this to the users' attention by not showing the serial-omap driver once the 8250 one is enabled. So the user might choose to use the help text which says that this driver (8250_omap) uses ttySx instead ttyOx.
Quoted 4 lines
Signed-off-by Sebastian Andrzej Siewior <[email protected]>---
This is my attempt to warn the defconfig user of the defconfig change (which did not yet happen). Any suggestions?
This is was Uwe Kleine-K?nig suggested off-list:
|Currently there are two drivers for the serial device. Until the new one |matured enough to drop the old one, let them conflict each other. They |both handle the same devices, but only one can be responsible for a |single device. There is no technical need, but having two drivers in the |same kernel might result in surprises.
I personally don't mind having two drivers enabled since the makefile order is always the same. My main concern is the ttyOx -> ttySx switch after the newer driver is enabled by default via defconfig (and the user does not know it). "make oldconfig" is covered by "default n". Uwe's has a point about "matured enough to drop the old one". It isn't mentioned anywhere that the newer driver supports also DMA. Is this something we want to add to the help text?
Could someone that will probably be dealling with possible fallout comment on this? This patch shouldn't go in without an ACK.
Sebastian
Quoted 26 lines · Sebastian Andrzej Siewior
Quoted 11 lines · * Sebastian Andrzej Siewior | 2014-11-26 23:01:46 [+0100]:
Technically speaking this is not required. If both are enabled then the Maikefile order says that 8250 one wins, the second is never probed.
If we choose to enable 8250_omap via defconfig then one might get supprised that his console isn't working anymore since nothing says use ttySx instead ttyOx.
This patch _tries_ to bring this to the users' attention by not showing the serial-omap driver once the 8250 one is enabled. So the user might choose to use the help text which says that this driver (8250_omap) uses ttySx instead ttyOx.Quoted 4 lines
Signed-off-by Sebastian Andrzej Siewior <[email protected]>---
This is my attempt to warn the defconfig user of the defconfig change (which did not yet happen). Any suggestions?This is was Uwe Kleine-K?nig suggested off-list:
|Currently there are two drivers for the serial device. Until the new one |matured enough to drop the old one, let them conflict each other. They |both handle the same devices, but only one can be responsible for a |single device. There is no technical need, but having two drivers in the |same kernel might result in surprises.
Quoted 9 lines
I personally don't mind having two drivers enabled since the makefile order is always the same. My main concern is the ttyOx -> ttySx switch after the newer driver is enabled by default via defconfig (and the user does not know it). "make oldconfig" is covered by "default n". Uwe's has a point about "matured enough to drop the old one". It isn't mentioned anywhere that the newer driver supports also DMA. Is this something we want to add to the help text?
Could someone that will probably be dealling with possible fallout comment on this? This patch shouldn't go in without an ACK.
Well the nightmare userspace switch from ttyS to ttyO few years ago is something we want to avoid.. I think the best solution would be to make serial-omap.c transparently provide support for ttyO using the new 8250 code so both ttyS and ttyO devices would just work. Otherwise it will be years of "my serial port stopped working" questions again.
Regards,
Tony
Quoted 5 lines
Well the nightmare userspace switch from ttyS to ttyO few years ago is something we want to avoid.. I think the best solution would be to make
serial-omap.ctransparently provide support for ttyO using the new 8250 code so both ttyS and ttyO devices would just work. Otherwise it will be years of "my serial port stopped working" questions again.
Thata a udev problem not a kernel one surely.
Alan
Quoted 7 lines · One Thousand Gnomes
Quoted 5 lines
Well the nightmare userspace switch from ttyS to ttyO few years ago is something we want to avoid.. I think the best solution would be to make
serial-omap.ctransparently provide support for ttyO using the new 8250 code so both ttyS and ttyO devices would just work. Otherwise it will be years of "my serial port stopped working" questions again.Thata a udev problem not a kernel one surely.
How do you suggest we get people to update their kernel command line and inittab? Udev may not even be installed.
Regards,
Tony
Quoted 11 lines · Tony Lindgren
Quoted 7 lines · One Thousand Gnomes
Quoted 5 lines
Well the nightmare userspace switch from ttyS to ttyO few years ago is something we want to avoid.. I think the best solution would be to make
serial-omap.ctransparently provide support for ttyO using the new 8250 code so both ttyS and ttyO devices would just work. Otherwise it will be years of "my serial port stopped working" questions again.Thata a udev problem not a kernel one surely.
How do you suggest we get people to update their kernel command line and inittab? Udev may not even be installed.
There are three use cases that I can think of right now:
- people that enable that new driver via oldconfig
I would expect that they read the help message in Kconfig. No worry about them.
- people that get a complete system via magic_build_tool (may yocto or whatever)
If $TOOL decides to use the new driver, then it should update commandline in bootloader. Those things create usually bootloader + kernel + rootfile system. If the commandline is saved on flash/mmc then it won't be reset from default. However udev should help here. So not a problem either (udev can't fix the kernel boot output but we should see atleast the login console).
- people that build omap2plus_defconfig and we switch to the new driver Those people get switched from one driver to the other without knowing. This is what I tried to bring to everyone's attention. The defconfig hasn't been changed yet so it is not problem for next release (yet).
I agree that this is a user problem. We agreed not to introduce a console proxy in kernel _or_ hack the command line in kernel (to replace O with S).
So I think the problem boils down to educate the user about this change. Making the old driver disappear was one way of getting the user's attention. Another idea would be to introduce a #warning which is also activated by the defconfig and informs the user about the change. Ideally this #warning could be switched off by Kconfig once the user reads & deactivates it. This requires the pay attention to warnings during build. #error would make sure he does but it breaks auto-builds so it is not an option.
Quoted 4 lines
Regards,
Tony
Sebastian
Quoted 33 lines · Sebastian Andrzej Siewior
Quoted 11 lines · Tony Lindgren
Quoted 7 lines · One Thousand Gnomes
Quoted 5 lines
Well the nightmare userspace switch from ttyS to ttyO few years ago is something we want to avoid.. I think the best solution would be to make
serial-omap.ctransparently provide support for ttyO using the new 8250 code so both ttyS and ttyO devices would just work. Otherwise it will be years of "my serial port stopped working" questions again.Thata a udev problem not a kernel one surely.
How do you suggest we get people to update their kernel command line and inittab? Udev may not even be installed.
There are three use cases that I can think of right now:
- people that enable that new driver via oldconfig
I would expect that they read the help message inKconfig. No worry about them.- people that get a complete system via
magic_build_tool(may yocto or whatever)
If $TOOL decides to use the new driver, then it should update commandline in bootloader. Those things create usually bootloader + kernel + rootfile system. If the commandline is saved on flash/mmc then it won't be reset from default. However udev should help here. So not a problem either (udev can't fix the kernel boot output but we should see atleast the login console).- people that build
omap2plus_defconfigand we switch to the new driver Those people get switched from one driver to the other without knowing. This is what I tried to bring to everyone's attention. The defconfig hasn't been changed yet so it is not problem for next release (yet).
Quoted 11 lines
I agree that this is a user problem. We agreed not to introduce a console proxy in kernel _or_ hack the command line in kernel (to replace O with S).
So I think the problem boils down to educate the user about this change. Making the old driver disappear was one way of getting the user's attention. Another idea would be to introduce a #warning which is also activated by the defconfig and informs the user about the change. Ideally this #warning could be switched off byKconfigonce the user reads & deactivates it. This requires the pay attention to warnings during build. #error would make sure he does but it breaks auto-builds so it is not an option.
The problem is the kernel will just mysteriously stop outputting anything if we enable the new driver. This is a "flag day" type problem that needs the user to somehow coordinate the kernel version, kernel .config, kernel cmdline, dev entries, and the inittab.
Regards,
Tony
Hi,
Quoted 7 lines · One Thousand Gnomes
Quoted 5 lines
Well the nightmare userspace switch from ttyS to ttyO few years ago is something we want to avoid.. I think the best solution would be to make
serial-omap.ctransparently provide support for ttyO using the new 8250 code so both ttyS and ttyO devices would just work. Otherwise it will be years of "my serial port stopped working" questions again.Thata a udev problem not a kernel one surely.
People also use serial console to observe the early kernel boot before the userspace is started.
A.
Quoted 9 lines · Aaro Koskinen
Hi,
Quoted 6 lines · One Thousand Gnomes
Quoted 5 lines
Well the nightmare userspace switch from ttyS to ttyO few years ago is something we want to avoid.. I think the best solution would be to make
serial-omap.ctransparently provide support for ttyO using the new 8250 code so both ttyS and ttyO devices would just work. Otherwise it will be years of "my serial port stopped working" questions again.
Quoted 4 lines
Quoted 1 line
Thata a udev problem not a kernel one surely.
People also use serial console to observe the early kernel boot before the userspace is started.
right, we need a way to tell the kernel that ttyO%d and ttyS%d are the exact same device so that console=ttyO0 and console=ttyS0 mean the same thing. That maintains backwards compatibility and lets people move on
Signature · 8 lines
balbi -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141201/4f5fda27/attachment.sig>
Quoted 10 lines · On Mon, 1 Dec 2014 19:51:18 -0600 Felipe Balbi <[email protected]> wrote:
Quoted 9 lines · Aaro Koskinen
Hi,
Quoted 6 lines · One Thousand Gnomes
Quoted 5 lines
Well the nightmare userspace switch from ttyS to ttyO few years ago is something we want to avoid.. I think the best solution would be to make
serial-omap.ctransparently provide support for ttyO using the new 8250 code so both ttyS and ttyO devices would just work. Otherwise it will be years of "my serial port stopped working" questions again.
Quoted 8 lines
Quoted 4 lines
Quoted 1 line
Thata a udev problem not a kernel one surely.
People also use serial console to observe the early kernel boot before the userspace is started.
right, we need a way to tell the kernel that ttyO%d and ttyS%d are the exact same device so that console=ttyO0 and console=ttyS0 mean the same thing. That maintains backwards compatibility and lets people move on
Yes.. and that possibly also means a temporary char driver that claims ttyO* and simply redirects the calls into the tty.
PATCH 1/1 tty: serial: 8250: omap: add ttySx console if the user didn't
This patch invokes add_preferred_console() with ttyS based on ttyO arguments if the user didn't specify it on its own. This ensures that the user will see the kernel booting on his serial console in case he forgot to update the command line.
---
While trying to to make a proxy driver like Alan suggested I wasn't sure how to obtain the ttyS console via "official" API. Then I stumbled upon update_console_cmdline() and then add_preferred_console().
drivers/tty/serial/8250/8250_omap.c | 40 +++++++++++++++++++++++++++++++++++++ drivers/tty/serial/8250/Kconfig | 19 ++++++++++++++++++ 2 files changed, 59 insertions(+)
drivers/tty/serial/8250/8250_omap.c +40 -0
@@ -1248,6 +1248,46 @@ static int omap8250_runtime_resume(struct device *dev) }#endif +#ifdef CONFIG_SERIAL_8250_OMAP_TTYO_FIXUP +static int __init omap8250_console_fixup (void ) +{ +char *omap_str; +char *options; +u8 idx; + +if (strstr (boot_command_line,"console=ttyS" )) +/* user set a ttyS based name for the console */ +return 0 ; + + omap_str =strstr (boot_command_line,"console=ttyO" ); +if (!omap_str) +/* user did not set ttyO based console, so we don't care */ +return 0 ; + + omap_str +=12 ; +if ('0' <= *omap_str && *omap_str <='9' ) + idx = *omap_str -'0' ; +else +return 0 ; + + omap_str++; +if (omap_str[0 ] ==',' ) { + omap_str++; + options = omap_str; + }else { + options =NULL ; + } + +add_preferred_console ("ttyS" , idx, options); +pr_err ("WARNING: Your 'console=ttyO%d' has been replaced by 'ttyS%d'\n" , + idx, idx); +pr_err ("This ensures that you still see kernel messages. Please\n" ); +pr_err ("update your kernel commandline.\n" ); +return 0 ; +} +console_initcall (omap8250_console_fixup); +#endif +static const struct dev_pm_ops omap8250_dev_pm_ops = { SET_SYSTEM_SLEEP_PM_OPS(omap8250_suspend, omap8250_resume) SET_RUNTIME_PM_OPS(omap8250_runtime_suspend,
drivers/tty/serial/8250/Kconfig +19 -0
@@ -308,6 +308,25 @@ config SERIAL_8250_OMAP This driver uses ttyS instead of ttyO. +config SERIAL_8250_OMAP_TTYO_FIXUP + bool "Replace ttyO with ttyS" + depends on SERIAL_8250_OMAP=y && SERIAL_8250_CONSOLE + default y + help + This option replaces the "console=ttyO" argument with the matching + ttyS argument if the user did not specified it on the command line. + This ensures that the user can see the kernel output during boot + which he wouldn't see otherwise. The getty has still to be configured + for ttyS instead of ttyO regardless of this option. + This option is intended for people who "automatically" enable this + driver without knowing that this driver requires a different console= + argument. If you read this, please keep this option disabled and + instead update your kernel command line. If you prepare a kernel for a + distribution or other kind of larger user base then you probably want + to keep this option enabled. Otherwise people might complain about a + not booting kernel because the serial console remains silent in case + they forgot to update the command line. + config SERIAL_8250_FINTEK tristate "Support for Fintek F81216A LPC to 4 UART" depends on SERIAL_8250 && PNP
Signature · 1 line
2.1.3
Re: [PATCH] tty: serial: 8250: omap: add ttySx console if the user didn't
Quoted 6 lines · On Thu, 18 Dec 2014 18:47:12 +0100 Sebastian Andrzej Siewior…
This patch invokes
add_preferred_console()with ttyS based on ttyO arguments if the user didn't specify it on its own. This ensures that the user will see the kernel booting on his serial console in case he forgot to update the command line.Signed-off-by Sebastian Andrzej Siewior <[email protected]>