[PATCH v4 1/2] serial: sifive: lock port in startup()/shutdown() callbacks

[Greg KH]

On Tue, Apr 22, 2025 at 12:20:42PM +0200, Vlastimil Babka wrote:
> On 4/5/25 09:35, Greg KH wrote:
> > On Sat, Apr 05, 2025 at 01:43:38PM +0900, Ryo Takakura wrote:
> >> startup()/shutdown() callbacks access SIFIVE_SERIAL_IE_OFFS.
> >> The register is also accessed from write() callback.
> >> 
> >> If console were printing and startup()/shutdown() callback
> >> gets called, its access to the register could be overwritten.
> >> 
> >> Add port->lock to startup()/shutdown() callbacks to make sure
> >> their access to SIFIVE_SERIAL_IE_OFFS is synchronized against
> >> write() callback.
> >> 
> >> Signed-off-by: Ryo Takakura <ryotkkr98 at gmail.com>
> >> Cc: stable at vger.kernel.org
> > 
> > What commit id does this fix?
> 
> > Why does patch 1/2 need to go to stable, but patch 2/2 does not?  Please
> > do not mix changes like this in the same series, otherwise we have to
> > split them up manually when we apply them to the different branches,
> > right?
> 
> I admit it's surprising to see such a request as AFAIK it's normally done to
> mix stable fixes and new features in the same series (especially when the
> patches depend on each other), and ordering the fixes first and marking only
> them as stable should be sufficient. We do that all the time in -mm. I
> thought that stable works with stable marked commits primarily, not series?

Yes, but when picking which "branch" to apply a series to, what would
you do if you have some "fix some bugs, then add some new features" in a
single patch series?  The one to go to -final or the one for the next
-rc1?

I see a lot of bugfixes delayed until -rc1 because of this issue, and
it's really not a good idea at all.

> Also since the patches are AFAIU dependent on each other, sending them
> separately makes the mainline development process more difficult, as
> evidenced by the later revisions having to add notes in the diffstat area
> etc. This would go against the goal that stable process does not add extra
> burden to the mainline process, no?

If they are dependent on each other, that's the creator's issue, not the
maintainer's issue, no?  :)

Submit the bug fixes, get them merged, and then submit the new features.

thanks,

greg k-h