Re: [PATCH v2 3/6] serial: sb1250-duart: Convert to use a platform device

On Fri, 10 Jul 2026, Greg Kroah-Hartman wrote:

> > Conversely only starting the console port so late lets the reset code
> > fully utilise our delay handlers, so switch from udelay() to fsleep()
> > for transmitter draining so as to avoid busy-waiting for an excessive
> > amount of time.
> 
> That's a different thing than "convert to a platform device" why are you
> mixing this up?

 With the move of this code to execute past the initialisation of the time 
subsystem (a consequence of converting to a platform device) retaining 
udelay() would introduce a functional bug where this busy loop would hold 
onto the CPU rather than making it available to the scheduler.  The bug 
would then have to be fixed with a separate change.  Perhaps I didn't make 
it clear enough in the change description.

 That said I investigated this situation further and I think this should 
have been implemented differently in 1/6, because pre-3/6 this code is 
executed early enough that even udelay() does not work correctly, since 
BogoMIPS haven't been calculated yet, and consequently line corruption 
remains.  Conversely when this code is executed late, such as in the 
non-console or even modular case, using udelay() is the very same 
functional bug.

 So with the rewrite in v3 I've come up with two variants, one for the 
early-boot case and the other for the late execution case, and then with 
the conversion to a platform device the early-boot case becomes dead code, 
the removal of which hopefully will raise no controversy.

 NB a similar approach should have been taken with commit ca904f4b4235 
("serial: dz: Fix bootconsole message clobbering at chip reset").

> > Since there is one way only remaining to reach sbd_init_port() now, drop 
> > the port initialisation marker as no longer needed and go through the 
> > channel resets unconditionally.
> > 
> > Fixes: 84a9582fd203 ("serial: core: Start managing serial controllers to enable runtime PM")
> > Signed-off-by: Maciej W. Rozycki <[email protected]>
> > Cc: [email protected] # needs to use .remove_new for <= 6.10
> 
> The first 3 patches in this series are cc: stable, the rest not, which
> is a mix I don't really know how to handle.  Please break things up into
> series that can go for this release, and those that can wait for the
> next onen (i.e. fsleep() stuff).

 I gather this is because you merge via different trees depending on 
whether a change is to be backported or not, right?  In any case I guess 
the other fix from the set can wait a couple of months until this has 
propagated.  And I'll post the MAINTAINERS update right away.

 Thank you for your review.

  Maciej