[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190923180728.flp6jx4jc2bh7cys@pburton-laptop>
Date: Mon, 23 Sep 2019 18:07:30 +0000
From: Paul Burton <paul.burton@...s.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-mips@...r.kernel.org" <linux-mips@...r.kernel.org>,
Florian Fainelli <f.fainelli@...il.com>
Subject: Re: [GIT PULL] MIPS changes
Hi Linus,
On Sun, Sep 22, 2019 at 11:35:36AM -0700, Linus Torvalds wrote:
> On Sat, Sep 21, 2019 at 4:10 PM Paul Burton <paul.burton@...s.com> wrote:
> >
> > Here are the main MIPS changes for v5.4; please pull.
>
> Hmm. I pulled and because initial tests didn't show any issues, I
> already pushed out.
>
> But some unrelated further testing then shows that this:
>
> > Florian Fainelli (2):
> > firmware: bcm47xx_nvram: Correct size_t printf format
> > firmware: bcm47xx_nvram: Allow COMPILE_TEST
>
> causes problems, and commit feb4eb060c3a ("firmware: bcm47xx_nvram:
> Correct size_t printf format") is buggy:
>
> drivers/firmware/broadcom/bcm47xx_nvram.c: In function ‘nvram_init’:
> drivers/firmware/broadcom/bcm47xx_nvram.c:151: warning: format ‘%zu’
> expects argument of type ‘size_t’, but argument 2 has type ‘u32’ {aka
> ‘unsigned int’} [-Wformat=]
>
> and the change to use %zu was completely wrong.
>
> It prints out 'header.len', which is an u32, not nvram_len which is a size_t.
>
> Tssk tssk.
Oopsie.
> I've fixed it in my tree, but this should have shown up in linux-next,
> or in MIPS testing. The process clearly failed.
Looking back I do see that the kbuild test robot reported an issue here,
so one aspect of the failure is squarely on my not having caught up on
email properly yet.
Another issue is that there are currently 'expected' warnings dotted
through the tree for various defconfigs, so whilst I do perform test
builds before submitting pull requests I generally don't pay too much
attention to warnings... So an improvement I'll look at is fixing up
those warnings & building with -Werror, or at least not ignoring
warnings.
My apologies and thanks for fixing this up,
Paul
Powered by blists - more mailing lists