[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e3ae392a16491b9ddeb1f0b2b74fdf05628b1996.camel@perches.com>
Date: Fri, 28 Jan 2022 11:11:55 -0800
From: Joe Perches <joe@...ches.com>
To: Tom Rix <trix@...hat.com>, Bart Van Assche <bvanassche@....org>,
kashyap.desai@...adcom.com, sumit.saxena@...adcom.com,
shivasharan.srikanteshwara@...adcom.com, jejb@...ux.ibm.com,
martin.petersen@...cle.com, nathan@...nel.org,
ndesaulniers@...gle.com
Cc: megaraidlinux.pdl@...adcom.com, linux-scsi@...r.kernel.org,
linux-kernel@...r.kernel.org, llvm@...ts.linux.dev
Subject: Re: [PATCH] scsi: megaraid: cleanup formatting of megaraid
On Fri, 2022-01-28 at 09:59 -0800, Tom Rix wrote:
> On 1/28/22 9:42 AM, Bart Van Assche wrote:
> > On 1/27/22 07:19, trix@...hat.com wrote:
> > > From: Tom Rix <trix@...hat.com>
> > >
> > > checkpatch reports several hundred formatting errors.
> > > Run these files through clang-format and knock off
> > > some of them.
> >
> > Isn't this the kind of patches that carries more risk than value?
Risk for whitespace style reformatting patches is quite low.
Nominally, clang-format changes should not produce a different
compiled object file unless __LINE__/__DATE__/__TIME__ style
changes occur.
If it does, the clang-format tool is broken.
> > Additionally, this patch conflicts with a patch series that I plan to
> > post soon.
[]
> Long term, it would be good have a reliable way to automatically fix
> either new files or really broken old files.
That's really a maintainer preference no?
Especially so for any automation.
Powered by blists - more mailing lists