[PATCH v4 1/2] serial: sifive: lock port in startup()/shutdown() callbacks
Greg KH
gregkh at linuxfoundation.org
Tue Apr 22 03:50:52 PDT 2025
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
More information about the linux-riscv
mailing list