Hi Linus,
Here are the main MIPS changes for v5.3, a light batch this time around
but significant improvements for certain systems. Please pull.
There's one minor conflict in arch/mips/include/asm/mach-ralink/pinmux.h
when merging with current master. Commit 1d0ea0692ae3 ("treewide:
Replace GPLv2 boilerplate/reference with SPDX - rule 332") in master &
commit 017105478bb5 ("MIPS: ralink: Switch pinmux.h to SPDX header")
from the MIPS tree both add the SPDX header but a little differently in
terms of comment style & license name. Reading
Documentation/process/license-rules.rst suggests to me that the version
in the MIPS tree is correct in terms of license name ("GPL-2.0" without
the "-only" suffix) whilst the version in master is correct in terms of
comment style ("/* */" rather than "//"). That would make the correct
resolution something like this:
diff --cc arch/mips/include/asm/mach-ralink/pinmux.h
index e54d4e1533b4,33647f796140..06ff9b17e42e
--- a/arch/mips/include/asm/mach-ralink/pinmux.h
+++ b/arch/mips/include/asm/mach-ralink/pinmux.h
@@@ -1,6 -1,5 +1,5 @@@
- /* SPDX-License-Identifier: GPL-2.0-only */
-// SPDX-License-Identifier: GPL-2.0
++/* SPDX-License-Identifier: GPL-2.0 */
/*
- *
* Copyright (C) 2012 John Crispin <[email protected]>
*/
Thanks,
Paul
The following changes since commit cd6c84d8f0cdc911df435bb075ba22ce3c605b07:
Linux 5.2-rc2 (2019-05-26 16:49:19 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git tags/mips_5.3
for you to fetch changes up to e5793cd1b5fedb39337cfa62251a25030f526e56:
MIPS: fix some more fall through errors in arch/mips (2019-07-16 12:40:16 +0100)
----------------------------------------------------------------
The main MIPS changes for a pretty light v5.3 cycle, including:
- Removal of readq & writeq for MIPS32 kernels where they would simply
BUG() anyway, allowing drivers or other code that #ifdefs on their
presence to work properly.
- Improvements for Ingenic JZ4740 systems, including support for the
external memory controller & pinmuxing fixes for qi_lb60/NanoNote
systems.
- Improvements for Lantiq systems, in particular around SMP & IPIs.
- DT updates for ralink/MediaTek MT7628a systems to probe & configure a
bunch more devices.
- Miscellaneous cleanups & build fixes.
----------------------------------------------------------------
Anshuman Khandual (1):
mips/kprobes: Export kprobe_fault_handler()
Geert Uytterhoeven (2):
memory: jz4780-nemc: Grammar s/the its/its/
MIPS: ftrace: Reword prepare_ftrace_return() comment block
Krzysztof Kozlowski (2):
MIPS: config: Remove left-over BACKLIGHT_LCD_SUPPORT
MIPS: configs: Remove useless UEVENT_HELPER_PATH
Lubomir Rintel (1):
MIPS: ralink: Switch pinmux.h to SPDX header
Masahiro Yamada (1):
MIPS: replace MBIT_ULL() with BIT_ULL()
Paul Burton (1):
FDDI: defza: Include linux/io-64-nonatomic-lo-hi.h
Paul Cercueil (6):
MIPS: lb60: Fix pin mappings
memory: Kconfig: Drop dependency on MACH_JZ4780 for jz4780
dt-bindings: memory: jz4780: Add compatible string for JZ4740 SoC
memory: jz4780_nemc: Add support for the JZ4740
memory: jz4780-nemc: Reduce size of const array
MAINTAINERS: Add myself as Ingenic SoCs maintainer
Petr Cvek (7):
MIPS: lantiq: Move macro directly to iomem function
MIPS: lantiq: Change variables to the same type as the source
MIPS: lantiq: Fix attributes of of_device_id structure
MIPS: lantiq: Remove unused macros
MIPS: lantiq: Fix bitfield masking
MIPS: lantiq: Shorten register names, remove unused macros
MIPS: lantiq: Add SMP support for lantiq interrupt controller
Serge Semin (1):
mips: Remove q-accessors from non-64bit platforms
Stefan Roese (6):
MIPS: ralink: mt7628a.dtsi: Add SPDX GPL-2.0 license identifier
MIPS: ralink: mt7628a.dtsi: Add pinmux DT node
MIPS: ralink: mt7628a.dtsi: Add pinctrl DT properties to the UART nodes
MIPS: ralink: mt7628a.dtsi: Add GPIO controller DT node
MIPS: ralink: mt7628a.dtsi: Add SPI controller DT node
MIPS: ralink: mt7628a.dtsi: Add watchdog controller DT node
Stephen Rothwell (2):
MIPS: perf events: handle switch statement falling through warnings
MIPS: fix some more fall through errors in arch/mips
.../memory-controllers/ingenic,jz4780-nemc.txt | 1 +
MAINTAINERS | 27 ++++
arch/mips/ar7/setup.c | 1 +
arch/mips/ath79/setup.c | 2 +-
arch/mips/bcm63xx/dev-flash.c | 1 +
arch/mips/boot/dts/ralink/mt7628a.dtsi | 148 ++++++++++++++++-
arch/mips/cavium-octeon/executive/cvmx-pko.c | 2 +-
arch/mips/configs/ar7_defconfig | 1 -
arch/mips/configs/ath25_defconfig | 1 -
arch/mips/configs/ath79_defconfig | 1 -
arch/mips/configs/bcm63xx_defconfig | 1 -
arch/mips/configs/bigsur_defconfig | 1 -
arch/mips/configs/bmips_be_defconfig | 1 -
arch/mips/configs/bmips_stb_defconfig | 1 -
arch/mips/configs/cavium_octeon_defconfig | 1 -
arch/mips/configs/ci20_defconfig | 1 -
arch/mips/configs/cobalt_defconfig | 1 -
arch/mips/configs/fuloong2e_defconfig | 1 -
arch/mips/configs/gpr_defconfig | 1 -
arch/mips/configs/ip27_defconfig | 1 -
arch/mips/configs/ip32_defconfig | 1 -
arch/mips/configs/lemote2f_defconfig | 2 -
arch/mips/configs/loongson1b_defconfig | 1 -
arch/mips/configs/loongson1c_defconfig | 1 -
arch/mips/configs/loongson3_defconfig | 1 -
arch/mips/configs/malta_defconfig | 1 -
arch/mips/configs/malta_kvm_defconfig | 1 -
arch/mips/configs/malta_kvm_guest_defconfig | 1 -
arch/mips/configs/maltaup_xpa_defconfig | 1 -
arch/mips/configs/mips_paravirt_defconfig | 1 -
arch/mips/configs/omega2p_defconfig | 1 -
arch/mips/configs/pistachio_defconfig | 1 -
arch/mips/configs/pnx8335_stb225_defconfig | 1 -
arch/mips/configs/qi_lb60_defconfig | 2 -
arch/mips/configs/rb532_defconfig | 1 -
arch/mips/configs/rt305x_defconfig | 1 -
arch/mips/configs/sb1250_swarm_defconfig | 1 -
arch/mips/configs/tb0219_defconfig | 1 -
arch/mips/configs/tb0226_defconfig | 1 -
arch/mips/configs/tb0287_defconfig | 1 -
arch/mips/configs/vocore2_defconfig | 1 -
arch/mips/configs/xway_defconfig | 1 -
arch/mips/include/asm/cpu.h | 125 +++++++--------
arch/mips/include/asm/io.h | 11 ++
arch/mips/include/asm/kprobes.h | 1 +
arch/mips/include/asm/mach-ralink/pinmux.h | 5 +-
arch/mips/jz4740/board-qi_lb60.c | 16 +-
arch/mips/kernel/ftrace.c | 23 +--
arch/mips/kernel/kprobes.c | 2 +-
arch/mips/kernel/perf_event_mipsxx.c | 30 ++--
arch/mips/lantiq/irq.c | 177 +++++++++++++++------
drivers/memory/Kconfig | 2 +-
drivers/memory/jz4780-nemc.c | 28 +++-
drivers/net/fddi/defza.c | 1 +
54 files changed, 439 insertions(+), 201 deletions(-)
On Wed, Jul 17, 2019 at 8:25 AM Paul Burton <[email protected]> wrote:
>
> Documentation/process/license-rules.rst suggests to me that the version
> in the MIPS tree is correct in terms of license name ("GPL-2.0" without
> the "-only" suffix) whilst the version in master is correct in terms of
> comment style ("/* */" rather than "//").
It's actually license-rules.rst that just hasn't been updated. The
"GPL-.2.0" and "GPL-2.0+" naming was considered too terse, so the
modern spdx tag suggestions are "GPL-2.0-only" and "GPL-2.0-or-later".
The full list of all spdx license tags (many of which aren't relevant
for the kernel, of course) can be found at
https://spdx.org/licenses/
in case you care.
Linus
The pull request you sent on Wed, 17 Jul 2019 15:25:47 +0000:
> git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git tags/mips_5.3
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/fa121bb3fed6313b1f0af23952301e06cf6d32ed
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
On Sat, Sep 21, 2019 at 4:10 PM Paul Burton <[email protected]> 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.
I've fixed it in my tree, but this should have shown up in linux-next,
or in MIPS testing. The process clearly failed.
Linus
On 9/22/2019 11:35 AM, Linus Torvalds wrote:
> On Sat, Sep 21, 2019 at 4:10 PM Paul Burton <[email protected]> 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.
>
> I've fixed it in my tree, but this should have shown up in linux-next,
> or in MIPS testing. The process clearly failed.
Thanks for fixing that. The process worked, there was an email sent by
the kbuild robot but I saw it only now somehow and failed to address it
in time before Paul sent out the pull request.
--
Florian
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 <[email protected]> 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
On Mon, Sep 23, 2019 at 11:07 AM Paul Burton <[email protected]> wrote:
>
> Another issue is that there are currently 'expected' warnings dotted
> through the tree for various defconfigs
This is why I refuse to have _any_ warnings at all in my tree during
the merge window.
If you have expected warnings, you will ignore the new and valid ones.
So the only acceptable situation is "no warnings".
In honesty, I actually do have one warning in my tree:
samples/vfs/test-statx.c:24:15: warning: ‘struct foo’ declared
inside parameter list will not be visible outside of this definition
or declaration
24 | #define statx foo
| ^~~
but because it's in the sample code, it pretty much never gets rebuilt
for me unless I basically do a "git clean" to get rid of everything,
so I don't normally see it for any normal pull.
So I've ignored that one warning, although I've actually been tempted
to just remove the sample because of it.
Adding David and Al to the cc just in case they have some simple fixup
for it that is likely to work across different user headers.
I considered just adding a
struct foo;
declaration, but the whole thing is incredibly ugly.
Linus
Linus Torvalds <[email protected]> wrote:
> In honesty, I actually do have one warning in my tree:
>
> samples/vfs/test-statx.c:24:15: warning: ‘struct foo’ declared
> inside parameter list will not be visible outside of this definition
> or declaration
> 24 | #define statx foo
> | ^~~
Were there any note lines from the compiler associated with this? The warning
message can't actually be taking place on this line.
Another thing I'm wondering is why your compiler shows this warning - and mine
does not. I've seen this before with uninitialised variables too where you
get a warning and I don't.
> but because it's in the sample code, it pretty much never gets rebuilt
> for me unless I basically do a "git clean" to get rid of everything,
> so I don't normally see it for any normal pull.
>
> So I've ignored that one warning, although I've actually been tempted
> to just remove the sample because of it.
>
> Adding David and Al to the cc just in case they have some simple fixup
> for it that is likely to work across different user headers.
>
> I considered just adding a
>
> struct foo;
>
> declaration, but the whole thing is incredibly ugly.
Yeah - I'm not sure the best way to deal with this. The problem being that
userspace may have a conflicting definition - or no definition at all - and I
need to use the one from the kernel in preference as that may have changes in
it that aren't yet reflected in userspace.
I'd rather not remove the sample if I can avoid it as I use it occasionally,
but maybe I should switch to relying on glibc.
David
On Tue, Sep 24, 2019 at 5:40 AM David Howells <[email protected]> wrote:
>
> Linus Torvalds <[email protected]> wrote:
>
> > In honesty, I actually do have one warning in my tree:
> >
> > samples/vfs/test-statx.c:24:15: warning: ‘struct foo’ declared
> > inside parameter list
>
> Were there any note lines from the compiler associated with this? The warning
> message can't actually be taking place on this line.
That's the only thing that gcc says. I agree that it's not where the
problem occurs, but the gcc warning system tries to avoid warning
inside system header files, so it seems to have logic tracing it back
to the user.
But I have system header files that look like this:
/* Fill *BUF with information about PATH in DIRFD. */
int statx (int __dirfd, const char *__restrict __path, int __flags,
unsigned int __mask, struct statx *__restrict __buf)
__THROW __nonnull ((2, 5));
and I think that's the one that triggers.
You must have hit *something* similar too, since the only reason for that
#define statx foo
#define statx_timestamp foo_timestamp
#include <sys/stat.h>
#undef statx
#undef statx_timestamp
is that you're playing games with the kernel 'statx' clashing with
user 'statx' use.
And what I think happens is that you had the <sys/types.h> include
*without* that #define, so the 'struct statx' got declared there, and
then in <sys/stat.h> it gets used, but it gets used as 'struct foo',
so now the compiler complains (properly) that you're using this
undeclared 'struct foo' in the function declaration, and because of
namespace rules it's not the same thing as then a later 'struct foo'
would be.
Linus
Linus