[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200604123038.GG22511@kadam>
Date: Thu, 4 Jun 2020 15:30:38 +0300
From: Dan Carpenter <dan.carpenter@...cle.com>
To: Julia Lawall <julia.lawall@...ia.fr>
Cc: Joe Perches <joe@...ches.com>,
Linus Walleij <linus.walleij@...aro.org>,
Christophe JAILLET <christophe.jaillet@...adoo.fr>,
Robert Jarzmik <robert.jarzmik@...e.fr>,
Daniel Mack <daniel@...que.org>,
Haojian Zhuang <haojian.zhuang@...il.com>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
"open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
kernel-janitors@...r.kernel.org
Subject: Re: [PATCH] pinctrl: pxa: pxa2xx: Remove 'pxa2xx_pinctrl_exit()'
which is unused and broken
On Thu, Jun 04, 2020 at 01:42:12PM +0200, Julia Lawall wrote:
> OK, I recall a discussion with Dan where he suggested that some things
> that were not actually bug fixes could also merit a Fixes tag. But it's
> probably better if he weighs in directly.
I generally think Fixes should only be used for "real bug" fixes.
The one exception is when I'm reviewing a patch that fixes an "unused
assignment" static checker warning is that I know which commit
introduced the warning. I don't have strong feelings if it's in the
Fixes tag or if it's just mentioned in the commit message. But it
helps me when I'm reviewing if I don't have to grovel through git
history myself. Also I think that it's always a good exercise for
people fixing patches to look at how the bug was introduced.
regards,
dan carpenter
Powered by blists - more mailing lists