[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Yw4HALWWOWabR/l9@kroah.com>
Date: Tue, 30 Aug 2022 14:48:00 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Andy Shevchenko <andy.shevchenko@...il.com>
Cc: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
Jiri Slaby <jirislaby@...nel.org>,
"open list:SERIAL DRIVERS" <linux-serial@...r.kernel.org>,
Stephen Warren <swarren@...dia.com>,
Alan Cox <alan@...ux.intel.com>,
Laxman Dewangan <ldewangan@...dia.com>,
Thierry Reding <treding@...dia.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/3] serial: Create uart_xmit_advance()
On Tue, Aug 30, 2022 at 03:38:27PM +0300, Andy Shevchenko wrote:
> On Tue, Aug 30, 2022 at 3:31 PM Greg Kroah-Hartman
> <gregkh@...uxfoundation.org> wrote:
> >
> > On Thu, Aug 25, 2022 at 12:17:05PM +0300, Ilpo Järvinen wrote:
> > > A very common pattern in the drivers is to advance xmit tail
> > > index and do bookkeeping of Tx'ed characters. Create
> > > uart_xmit_advance() to handle it.
> > >
> > > Fixes: e9ea096dd225 ("serial: tegra: add serial driver")
> > > Fixes: 2d908b38d409 ("serial: Add Tegra Combined UART driver")
> >
> > This commit only adds a new function, it does not "Fix" anything :(
>
> I'm wondering how to tell stable maintainers about dependencies of
> (not yet applied) patches? In practice I saw that contributors use
> Fixes tag for the entire chain (for the preparatory patches + the real
> fix) when it's not easy / in a nice way to rebase to have a one-patch
> fix followed by refactoring, etc.
It's as if no one has ever had this issue before and wrote it down for
all to read and know what to do in the future.
{sigh}
Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.
If you don't know the git id, just use the subject line and it should
work the same.
greg "why even write documentation?" k-h
Powered by blists - more mailing lists