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@angie.orcam.me.uk/>.

  Maciej