From: Prarit Bhargava <prarit@redhat.com> To: Jeffrey Hugo <jhugo@codeaurora.org>, Ingo Molnar <mingo@kernel.org> Cc: Jonathan Corbet <corbet@lwn.net>, x86@kernel.org, linux-pm@vger.kernel.org, Catalin Marinas <catalin.marinas@arm.com>, Bhupesh Sharma <bhsharma@redhat.com>, linux-doc@vger.kernel.org, Will Deacon <will.deacon@arm.com>, linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, Ingo Molnar <mingo@redhat.com>, "Rafael J. Wysocki" <rjw@rjwysocki.net>, Lv Zheng <lv.zheng@intel.com>, linux-serial@vger.kernel.org, "H. Peter Anvin" <hpa@zytor.com>, Thomas Gleixner <tglx@linutronix.de>, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH 0/2] acpi, x86: Add SPCR table support Date: Fri, 8 Dec 2017 11:02:40 -0500 [thread overview] Message-ID: <c5441b79-91a3-719b-f435-3c9ea937a743@redhat.com> (raw) In-Reply-To: <bd727a15-c697-741f-864b-8b48b8e5e272@codeaurora.org> 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@redhat.com> 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. >
WARNING: multiple messages have this Message-ID (diff)
From: prarit@redhat.com (Prarit Bhargava) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH 0/2] acpi, x86: Add SPCR table support Date: Fri, 8 Dec 2017 11:02:40 -0500 [thread overview] Message-ID: <c5441b79-91a3-719b-f435-3c9ea937a743@redhat.com> (raw) In-Reply-To: <bd727a15-c697-741f-864b-8b48b8e5e272@codeaurora.org> 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@redhat.com> 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 at 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. >
next prev parent reply other threads:[~2017-12-08 16:02 UTC|newest] Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-12-07 17:29 [PATCH 0/2] acpi, x86: Add SPCR table support Prarit Bhargava 2017-12-07 17:29 ` Prarit Bhargava 2017-12-07 17:29 ` [PATCH 1/2] acpi, spcr: Make SPCR avialable to other architectures Prarit Bhargava 2017-12-07 17:29 ` Prarit Bhargava 2017-12-07 18:43 ` Timur Tabi 2017-12-07 18:43 ` Timur Tabi 2017-12-07 18:43 ` Timur Tabi 2017-12-07 19:05 ` Prarit Bhargava 2017-12-07 19:05 ` Prarit Bhargava 2017-12-07 19:05 ` Prarit Bhargava 2017-12-07 19:35 ` Timur Tabi 2017-12-07 19:35 ` Timur Tabi 2017-12-07 19:35 ` Timur Tabi 2017-12-08 19:42 ` Prarit Bhargava 2017-12-08 19:42 ` Prarit Bhargava 2017-12-08 19:42 ` Prarit Bhargava 2017-12-07 17:29 ` [PATCH 2/2] acpi, x86: Use SPCR table for earlycon on x86 Prarit Bhargava 2017-12-07 17:29 ` Prarit Bhargava 2017-12-07 18:46 ` Timur Tabi 2017-12-07 18:46 ` Timur Tabi 2017-12-07 18:46 ` Timur Tabi 2017-12-07 19:03 ` Prarit Bhargava 2017-12-07 19:03 ` Prarit Bhargava 2017-12-07 19:03 ` Prarit Bhargava 2017-12-08 6:29 ` [PATCH 0/2] acpi, x86: Add SPCR table support Ingo Molnar 2017-12-08 6:29 ` Ingo Molnar 2017-12-08 14:29 ` Prarit Bhargava 2017-12-08 14:29 ` Prarit Bhargava 2017-12-08 15:31 ` Jeffrey Hugo 2017-12-08 15:31 ` Jeffrey Hugo 2017-12-08 16:02 ` Prarit Bhargava [this message] 2017-12-08 16:02 ` Prarit Bhargava 2017-12-10 20:40 ` Jon Masters 2017-12-10 20:40 ` Jon Masters 2017-12-10 20:40 ` Jon Masters 2017-12-11 14:42 ` Ingo Molnar 2017-12-11 14:42 ` Ingo Molnar
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=c5441b79-91a3-719b-f435-3c9ea937a743@redhat.com \ --to=prarit@redhat.com \ --cc=bhsharma@redhat.com \ --cc=catalin.marinas@arm.com \ --cc=corbet@lwn.net \ --cc=hpa@zytor.com \ --cc=jhugo@codeaurora.org \ --cc=linux-acpi@vger.kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-doc@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-pm@vger.kernel.org \ --cc=linux-serial@vger.kernel.org \ --cc=lv.zheng@intel.com \ --cc=mingo@kernel.org \ --cc=mingo@redhat.com \ --cc=rjw@rjwysocki.net \ --cc=tglx@linutronix.de \ --cc=will.deacon@arm.com \ --cc=x86@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.