On Tue, 1 Nov 2022, Martin Hundebøll wrote: > On Tue, Nov 01, 2022 at 03:22:33PM +0200, Ilpo Järvinen wrote: > > On Tue, 1 Nov 2022, Martin Hundebøll wrote: > > In addition, to me n useless ports just sitting there doesn't sound that > > serious issue that it would warrant breaking setups that currently depend > > on certain ttyS numbers (I suppose you actually agree with this point). > > Agreed. Although we have seen races between the DELETE and ADD uevents > mentioned below, leading to non-deterministical device numbers. No doubt there will be cases were the numbering is not as stable as we'd like but it seems an unrelated issue. > > > If you look at uevents from 8250 when the designware ports are discovered, > > > you'll see a DELETE of the built-in ttyS0 first, and then an ADD of the > > > designware ttyS0. My understanding is that we should never have had that > > > built-in ttyS0 in the first place? > > > > I certainly suspect the built-in one really isn't there (in ACPI) but I > > don't want to spend my time on confirming the obvious. > > >From a system booted with these patches, and 8250.nr_uarts=0, I get two > ports from ACPI PNP: > > # cat /sys/class/tty/ttyS0/port > 0x3F8 > # cat /sys/class/tty/ttyS1/port > 0x2F8 > > which matches the SERIAL_PORT_DNFS define in arch/x86/include/asm/serial.h I was talking about the system I was testing with. > > > > I'm not anymore sure about your goals really. Now it sounds one of the > > > > goals is preserving the non-discoverable ports, whereas previously it was > > > > just about allowing 0 of them. > > > > > > My initial goal was to rely on discoverable ports only. Some of our systems > > > have no built-in uarts, so the bash init script failed to even start, because > > > the kernel command line had console=ttyS0, and bash tried to do set terminal > > > attributes on it. I am only trying to fix the code "the right way", but that > > > might not be possible without breaking numbering fo existing systems. > > > > Again I don't follow the reasoning fully here. What is your end goal here > > in this scenario. You'd either want to have no ports to appear at all or > > have a non-discoverable (=bogus) port as ttyS0. Which way it is? > > > > If you, on the other hand, would have a discoverable port that will take > > over ttyS0, I don't understand why it fails so it seemingly leaves only > > those two options I gave. > > My endgoal is to avoid a bogus ttyS0, but a working driver (for the PCIe > connected ports). > > I still think it seems wrong to have non-working device nodes. They only > confuse both people and software: > > % sudo stty -F /dev/ttyS0 > stty: /dev/ttyS0: Input/output error So simply add the maximum number of non-discoverable ports? Something which isn't reusing nr_uarts or its related CONFIG, and pick such a default which doesn't break existing cmdlines. > > > That would work for me. But shouldn't we clean up the > > > SERIAL_8250_NR_UARTS vs. SERIAL_8250_RUNTIME_UARTS also? > > > > I'm not convinced there's something wrong with it. It's legacy yes, but > > the max ports compiled in vs max ports per boot is not wrong/buggy as is. > > Your interpretation of those two makes sense, but I don't really see a > usecase for setting 8250.nr_uarts at boot time though. You might not but we shouldn't change it to mean something else. -- i.
