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

[Vlastimil Babka]

On 4/22/25 12:50, Greg KH wrote:
> On Tue, Apr 22, 2025 at 12:20:42PM +0200, Vlastimil Babka wrote:
>> 
>> 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?

As a maintainer I could split it myself.

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

In my experience, most of the time these fixes are created because a dev:

- works on the code to implement the feature part
- while working at the code, spots an existing bug
- the bug can be old (Fixes: commit a number of releases ago)
- wants to be helpful so isolates the fix separately as an early patch of
the series and marks stable because the bug can be serious enough in theory
- at the same time there are no known reports of the bug being hit in the wild

In that case I don't see the urgency to fix it ASAP (unless it's e.g.
something obviously dangerously exploitable) so it might not be such a bad
idea just to put everything towards next rc1.

This very thread seems to be a good example of the above. I see the later
version added a
Fixes: 45c054d0815b ("tty: serial: add driver for the SiFive UART")
which is a v5.2 commit.

Thanks,
Vlastimil

>> 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