| Message ID | 1417039306-2384-1-git-send-email-bigeasy@linutronix.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
* 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. > >Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> >--- >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
* Sebastian Andrzej Siewior <bigeasy@linutronix.de> [141129 01:50]: > * 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. > > > >Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> > >--- > >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. 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
> 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. Thata a udev problem not a kernel one surely. Alan
* One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> [141201 06:11]: > > 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. > > 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
On 12/01/2014 05:38 PM, Tony Lindgren wrote: > * One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> [141201 06:11]: >>> 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. >> >> 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. > Regards, > > Tony > Sebastian
* Sebastian Andrzej Siewior <bigeasy@linutronix.de> [141201 09:27]: > On 12/01/2014 05:38 PM, Tony Lindgren wrote: > > * One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> [141201 06:11]: > >>> 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. > >> > >> 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. 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, On Mon, Dec 01, 2014 at 02:09:14PM +0000, One Thousand Gnomes wrote: > > 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. > > 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.
On Tue, Dec 02, 2014 at 01:13:38AM +0200, Aaro Koskinen wrote: > Hi, > > On Mon, Dec 01, 2014 at 02:09:14PM +0000, One Thousand Gnomes wrote: > > > 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. > > > > 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
On Mon, 1 Dec 2014 19:51:18 -0600 Felipe Balbi <balbi@ti.com> wrote: > On Tue, Dec 02, 2014 at 01:13:38AM +0200, Aaro Koskinen wrote: > > Hi, > > > > On Mon, Dec 01, 2014 at 02:09:14PM +0000, One Thousand Gnomes wrote: > > > > 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. > > > > > > 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.
diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig index e71a28b4b94e..1b1bdf946fee 100644 --- a/drivers/tty/serial/Kconfig +++ b/drivers/tty/serial/Kconfig @@ -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
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. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> --- 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(-)