[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <397723b7-9f04-4cb1-b718-2396ea9d1b91@suse.cz>
Date: Tue, 22 Apr 2025 12:20:42 +0200
From: Vlastimil Babka <vbabka@...e.cz>
To: Greg KH <gregkh@...uxfoundation.org>, Ryo Takakura <ryotkkr98@...il.com>
Cc: alex@...ti.fr, aou@...s.berkeley.edu, bigeasy@...utronix.de,
conor.dooley@...rochip.com, jirislaby@...nel.org, john.ogness@...utronix.de,
palmer@...belt.com, paul.walmsley@...ive.com, pmladek@...e.com,
samuel.holland@...ive.com, u.kleine-koenig@...libre.com,
linux-kernel@...r.kernel.org, linux-riscv@...ts.infradead.org,
linux-serial@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH v4 1/2] serial: sifive: lock port in startup()/shutdown()
callbacks
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@...il.com>
>> Cc: stable@...r.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?
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?
Thanks,
Vlastimil
> thanks,
>
> greg k-h
Powered by blists - more mailing lists