From: "Maciej W. Rozycki" <macro@orcam.me.uk>
To: Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Jiri Slaby <jirislaby@kernel.org>
Cc: linux-mips@vger.kernel.org, linux-serial@vger.kernel.org,
linux-serial@vger.kernel.org
Subject: Re: [PATCH 6/8] serial: zs: Convert to use a platform device
Date: Tue, 28 Apr 2026 14:49:51 +0100 (BST) [thread overview]
Message-ID: <alpine.DEB.2.21.2604281415030.38805@angie.orcam.me.uk> (raw)
In-Reply-To: <alpine.DEB.2.21.2604110034160.29980@angie.orcam.me.uk>
On Mon, 13 Apr 2026, Maciej W. Rozycki wrote:
> An unfortunate consequence of the switch to a platform device is we now
> hand the console over from the bootconsole much later in the bootstrap.
> The firmware console handler appears good enough though to work so late
> and in particular with interrupts enabled.
Additional verification revealed actual fallout from this postponement of
console switching, where the kernel hangs in the 64-bit configuration at:
pid_max: default: 32768 minimum: 301
or somewhat later, but always before:
cblist_init_generic: Setting adjustable number of callback queues.
I have tracked down the cause to be the initial console output handler now
being called from other kernel threads beyond the initial one, and unlike
the latter they have their stack allocated in 64-bit XKPHYS segment rather
than 32-bit compatibility CKSEG0 segment.
Consequently the stack pointer is no longer a 32-bit value and when the
firmware console output handler being called uses 32-bit ALU operations to
manipulate the stack pointer, the calculated result is incorrect (in fact
in the 64-bit MIPS ISA it is UB for almost all 32-bit ALU operations to
execute on 64-bit data) and control goes astray.
We already have code in the generic call_o32() 32-bit firmware call stub
for 64-bit code to do optional stack switching, so all that has to be done
is making the platform supply the stub with a pointer to an alternative
stack located in CKSEG0, such as to a chunk of initdata space. This will
be straightforward to implement; I'll yet think whether to arrange for the
stack to be switched every time or only when the incoming stack pointer is
outside the 32-bit space.
In any case I'll respin the series shortly so as to include the platform
update required and prevent an unnecessary maintenance complication from
happening that a standalone fix would cause.
The other driver never runs on 64-bit hardware, so it causes no issue.
Maciej
next prev parent reply other threads:[~2026-04-28 13:49 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-13 3:27 [PATCH 0/8] MIPS: DEC: Fix serial device regressions + RTC cleanup Maciej W. Rozycki
2026-04-13 3:27 ` [PATCH 1/8] serial: dz: Fix bootconsole message clobbering at chip reset Maciej W. Rozycki
2026-04-13 3:28 ` [PATCH 2/8] serial: dz: Fix bootconsole handover lockup Maciej W. Rozycki
2026-04-13 3:28 ` [PATCH 3/8] serial: zs: " Maciej W. Rozycki
2026-04-13 3:28 ` [PATCH 4/8] serial: zs: Switch to using channel reset Maciej W. Rozycki
2026-04-13 3:28 ` [PATCH 5/8] serial: dz: Convert to use a platform device Maciej W. Rozycki
2026-04-13 3:28 ` [PATCH 6/8] serial: zs: " Maciej W. Rozycki
2026-04-28 13:49 ` Maciej W. Rozycki [this message]
2026-04-13 3:28 ` [PATCH 7/8] serial: dz: Enable modular build Maciej W. Rozycki
2026-04-13 3:28 ` [PATCH 8/8] MIPS: DEC: Ensure RTC platform device deregistration upon failure Maciej W. Rozycki
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=alpine.DEB.2.21.2604281415030.38805@angie.orcam.me.uk \
--to=macro@orcam.me.uk \
--cc=gregkh@linuxfoundation.org \
--cc=jirislaby@kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=tsbogend@alpha.franken.de \
/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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).