On Sun, Jan 31, 2021 at 01:18:47PM +0000, Måns Rullgård wrote: > Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> writes: > > > On Thu, Jan 28, 2021 at 05:22:44PM +0000, Mans Rullgard wrote: > >> On systems that do not have the traditional PC ISA serial ports, the > >> 8250 driver still creates non-functional device nodes. This change > >> makes only ports that actually exist (PCI, DT, ...) get device nodes. > >> > >> Signed-off-by: Mans Rullgard <mans@xxxxxxxxx> > >> --- > >> drivers/tty/serial/8250/8250_core.c | 26 ++++++++++++++++++++------ > >> drivers/tty/serial/8250/Kconfig | 5 +++++ > >> 2 files changed, 25 insertions(+), 6 deletions(-) > >> > >> diff --git a/drivers/tty/serial/8250/8250_core.c b/drivers/tty/serial/8250/8250_core.c > >> index cae61d1ebec5..49695dd3677c 100644 > >> --- a/drivers/tty/serial/8250/8250_core.c > >> +++ b/drivers/tty/serial/8250/8250_core.c > >> @@ -555,6 +555,7 @@ static void __init serial8250_isa_init_ports(void) > >> } > >> } > >> > >> +#ifdef CONFIG_SERIAL_8250_ISA > > > > This is just making a mess of the code. > > It was already a mess. True, but don't make it a worse one please. > > > To do this right, pull the isa code out into a separate file and put > > the #ifdef in a .h file, so we can properly maintain and support this > > code over time. This change as-is is not going to make that any > > easier :( > > I might put in that effort if there's a reasonable chance this change > will be accepted. If it's going to be rejected regardless, I'd rather > not waste my time. > > >> +config SERIAL_8250_ISA > >> + bool "8250/16550 ISA device support" if EXPERT > > > > So, no one will set this? > > I followed the pattern of the existing SERIAL_8250_PNP option. Was that > a mistake? How would you prefer it? I don't know, I'm just asking. > > What userspace visable change will be caused by this? > > There won't be /dev/ttyS devices for ports that don't exist. > > > Will ports get renumbered? > > Not if they had predictable numbers to begin with. So that would be "yes"? If so, obviously we couldn't take this, right? thanks, greg k-h
