On 12/08/2017 10:31 AM, Jeffrey Hugo wrote: > On 12/8/2017 7:29 AM, Prarit Bhargava wrote: >> >> >> On 12/08/2017 01:29 AM, Ingo Molnar wrote: >>> >>> * Prarit Bhargava <prarit@xxxxxxxxxx> wrote: >>> >>>> The SPCR (Serial Port Console Redirection) Table provides information >>>> about the configuration of serial port. This information can be used >>>> to configure the early console. >>> >>> s/about the configuration of serial port >>> /about the configuration of the serial port >>> >>>> SPCR support was added for arm64 and is made available across all arches >>>> in this patchset. The first patch adds a weak per-arch configuration function >>>> and moves the SPCR code into ACPI. The second patch adds support to x86. >>>> >>>> The existing behaviour on arm64 is maintained. If the SPCR exists the >>>> earlycon and console are automatically configured. >>> >>> s/arm64 >>> /ARM64 >>> >>> which is easier to read and it's also the prevalent spelling: >>> >>> triton:~/tip> for N in $(git grep -ih arm64 arch/arm64/ | sed >>> 's/[[:punct:]]/ /g'); do echo $N | grep -iw arm64; done | sort | uniq -c >>> 412 arm64 >>> 1 Arm64 >>> 854 ARM64 >>> >>>> The existing default behaviour on x86 is also maintained. If no console or >>>> earlycon parameter is defined and the SPCR exists , the serial port is not >>>> configured. If the earlycon parameter is used both the early console >>>> and the console are configured using the data from the SPCR. >>> >>> s/exists , the >>> /exists, the >>> >>> But, the logic to not use the SPCR looks confusing to me. >>> >>> The SPCR is only present if the user has explicitly configured a serial console >>> for that machine, either in the firmware, or remotely via IPMI, correct? I.e. >>> SPCR >>> will not be spuriously present by default on systems that have a serial console >>> but the user never expressed any interest for them, right? >> >> If I disable "Serial Port Console Debug" in my BIOS I still see the SPCR >> configured: >> >> [root@prarit-lab ~]# dmesg | grep SPCR >> [ 0.000000] ACPI: SPCR 0x0000000069031000 000050 (v01 >> 00000000 00000000) >> >> AFAICT the SPCR is always enabled on some systems. > > "Serial Port Console Debug" sounds like DBG2 to me, although I am unsure of the > specific platform you are referencing. > >> >>> >>> If so then we should pick up that serial console configuration and activate it, >>> regardless of any kernel boot options! >> >> I'm worried about someone who doesn't want a console on ttyS0 suddenly ending up >> with one. The SPCR could contain incorrect data, etc. >> >> I originally wanted this on by default, but the chances of breaking someone's >> setup seems significant doesn't it? Maybe I'm being too cautious. Anyone else >> want to weigh in? I'm not ignoring your idea Ingo, I'm just worried about being >> yelled at by a user :) because I broke their default console setup. >> > > SPCR is always present on QDF2400 (ARM64 platform). Firmware will automatically > update the SPCR table to point to the correct console (IE Serial-over-LAN or SOL > if configured via IPMI). Unless a user specifically chooses to override the > SPCR via "console=", we expect that a console will be present based on the data > in SPCR. Hey Jeffrey -- I think Ingo's & my conversation is x86-specific. I am *NOT* changing the behaviour on ARM64. P. > -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
