NPS customers are no longer doing active development, as evident from
rand config build failures reported in recent times, so drop support
for NPS platform.
Tested-by: kernel test robot <lkp@intel.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Based on 2 normalized pattern(s):
this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license version 2 as
published by the free software foundation
this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license version 2 as
published by the free software foundation #
extracted by the scancode license scanner the SPDX license identifier
GPL-2.0-only
has been chosen to replace the boilerplate/reference in 4122 file(s).
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Enrico Weigelt <info@metux.net>
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Allison Randal <allison@lohutok.net>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
vs. fixed 512M before.
But this still assumes that all of memory is under IOC which may not be
true for the SoC. Improve that later when this becomes a real issue, by
specifying this from DT.
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
The motivation is to identify ARC750 vs. ARC770 (we currently print
generic "ARC700").
A given ARC700 release could be 750 or 770, with same ARCNUM (or family
identifier which is unfortunate). The existing arc_cpu_tbl[] kept a single
concatenated string for core name and release which thus doesn't work
for 750 vs. 770 identification.
So split this into 2 tables, one with core names and other with release.
And while we are at it, get rid of the range checking for family numbers.
We just document the known to exist cores running Linux and ditch
others.
With this in place, we add detection of ARC750 which is
- cores 0x33 and before
- cores 0x34 and later with MMUv2
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Previously we would not print the case when IOC existed but was not
enabled.
And while at it, reduce one line off boot printing by consolidating
the Peripheral address space and IO-Coherency which in a way
applies to them
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
The default 256 bytes sometimes is just not enough.
We usually provide earlycon=... and console=... and ip=...
All this and more may need more room.
Signed-off-by: Noam Camus <noamc@ezchip.com>
Acked-by: Vineet Gupta <vgupta@synopsys.com>
* No active users of this flag anymore
* flag itself was no longer usable with new simualtor which acts just like
hardware, not providing the special chip-id = 0xffff which good old
ISS used to do.
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
They haven't '__init' in definition, but has '__init' in declaration.
And normal function start_kernel_secondary() may call setup_processor()
which will call arc_init_IRQ().
So need remove '__init' for both of them. The related warning (with
allmodconfig):
MODPOST vmlinux.o
WARNING: vmlinux.o(.text+0x3084): Section mismatch in reference from the function start_kernel_secondary() to the function .init.text:setup_processor()
The function start_kernel_secondary() references
the function __init setup_processor().
This is often because start_kernel_secondary lacks a __init
annotation or the annotation of setup_processor is wrong.
Signed-off-by: Chen Gang <gang.chen@asianux.com>
1. ./genfilelist.pl arch/arc/include/asm/
2. Create arch/arc/include/uapi/asm/Kbuild as follows
+# UAPI Header export list
+include include/uapi/asm-generic/Kbuild.asm
3. ./disintegrate-one.pl arch/arc/include/{,uapi/}asm/<above-list>
4. Edit arch/arc/include/asm/Kbuild to remove ref to
asm-generic/Kbuild.asm
- To work around empty uapi/asm/setup.h added a placholder comment.
- Also a manual #ifdef __ASSEMBLY__ for a late ptrace change
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Cc: David Howells <dhowells@redhat.com>