From: Lee Jones <lee.jones@linaro.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: MFD for v5.9
Date: Thu, 13 Aug 2020 08:19:49 +0100 [thread overview]
Message-ID: <20200813071949.GG4354@dell> (raw)
In-Reply-To: <CAHk-=wgF6Ld0-E0Ych_s=jyS4ssaabK08QR4NOzfRrde0LVHfg@mail.gmail.com>
On Wed, 12 Aug 2020, Linus Torvalds wrote:
> On Tue, Aug 11, 2020 at 12:46 AM Lee Jones <lee.jones@linaro.org> wrote:
> >
> > Enjoy!
>
> No.
>
> This causes new compiler warnings.
Hmm... that's frustrating.
Mea culpa. Apologies for this.
As you know this is unheard of from me.
> I pulled, did a basic test-compile, and unpulled.
>
> I refuse to pull garbage that hasn't even seen the most trivial build-test.
>
> And no, "I built it but didn't check for warnings" is not a build
> test. That's just complete garbage. It's showing the code to the
> compiler, and not bothering to look at what the compiler said about
> it.
Let me give you my 'reason' (I know there is no 'excuse').
I've been grafting on an attempt to rid the kernel of W=1 warnings
this cycle. Starting with MFD then working through Backlight, SCSI,
Regulator, RemoteProc, IIO, USB, Misc, Pinctrl, GPIO, etc etc, I've
managed to extinguish almost 3000 warnings to date. I hope to do
something similar this cycle.
Anyway, I forgot to turn W=1 off when testing MFD. I saw that there
were a couple of warnings, but I (stupidly) assumed that these were
just residue W=1 issues that I would clean-up next cycle. Not
realising there were 2 real 'unused variable' problems present.
> You can try again next merge window, by now it's too late to send me
> completely untested garbage and try to fix it up.
Could I please urge you to reconsider. The branch is well tested (in
-next, by private 'kernel test robot' tests and by extensive TuxBuild
testing). I have cleaned up the offending line (it was just one line
causing the 2 new 'unused variable' issues) and all of my tests are
now passing (with W=1 turned off). The branch also extinguishes well
over 100 W=1 warnings to boot. It certainly does more good than
harm.
If you decide stick with your decision however, I'll also understand.
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
next prev parent reply other threads:[~2020-08-13 7:19 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-11 7:46 MFD for v5.9 Lee Jones
2020-08-12 6:39 ` [GIT PULL] " Lee Jones
2020-08-12 19:05 ` Linus Torvalds
2020-08-13 7:19 ` Lee Jones [this message]
2020-08-14 14:42 ` [GIT PULL v2] " Lee Jones
2020-08-15 15:16 ` Linus Torvalds
2020-08-17 8:14 ` Lee Jones
2020-08-15 15:23 ` pr-tracker-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200813071949.GG4354@dell \
--to=lee.jones@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox