public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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