[PATCH v2 0/6] MIPS: SiByte: Fix serial device regressions

From: Maciej W. Rozycki

Date: Sun May 24 2026 - 19:20:52 EST


Hi,

This is v2 of the series addressing feedback to original 4/4 where the
plain revert was questioned.

I proposed using a spinlock instead of the atomic counter, which was then
agreed upon. In the course of making the change I have realised that from
the algorithm's correctness point of view the request and release of the
resource in question needs to be done under the spinlock as well, because
in particular setserial(8) can cause port resources to be released and
requested in parallel for individual channels of a single DUART. It makes
that change a fix rather than a cleanup.

I chose to keep the revert anyway as it's a regression that oughtn't to
have happened in the first place, and it's a self-contained change, as is
the newly-added fix. This will help backporting the new fix too, should
someone wish to, although I don't think we need to rush pushing it to
-stable.

I've added a MAINTAINERS entry on top too, as previously stated. No
change except for the patch headings to patches 1/4 through 4/4, which
have become 1/6 through 4/6 now. The original cover letter follows.

Starting from commit 84a9582fd203 ("serial: core: Start managing serial
controllers to enable runtime PM") the driver for the SiByte onchip DUART
has stopped working due to a null pointer dereference in the serial core,
which means a kernel crash at bootstrap if the driver has been enabled, as
is usually the case for the system console.

This patch series addresses the issue by switching the driver away from
legacy probing to using platform devices. A notable consequence of this
is the serial console is only switched from the bootconsole handler that
uses firmware calls over to our serial driver at the time the driver is
being properly brought up. This causes messages to be produced to the
console between the device reset and console setup, which in turn causes
the firmware still being called via the bootconsole handler to loop
forever owing to the transmitter having been disabled.

Therefore introductory change 2/4 is included to fix the issue by doing a
rudimentary device setup right after reset, using parameters compatible
with those used by the firmware (115200n8). There is auxiliary change 1/4
included as well that prevents message corruption from happening at reset,
which becomes more prominent due to the change in timing, with the driver
switch to the platform device, of messages produced to the console.

Additionally there is a revert included as change 4/4 for a regression
introduced by an earlier change that caused previously good code to fail
requesting the control register resource shared between DUART channels,
and issue a warning to the kernel log. Not to be backported as strictly
speaking the driver works just fine despite the missing reservation.

See individual change descriptions for details. Verified with a SWARM
(BCM91250A) system.

Please apply.

Previous iterations:

- v1 at: <https://lore.kernel.org/r/alpine.DEB.2.21.2604130239560.29980@xxxxxxxxxxxxxxxxx/>.

Maciej