user/sven/linux.git/arch/sh/kernel/setup.c, branch v4.4.118

memblock: make memblock_set_node() support different memblock_type

2014-01-22T00:19:44Z

[sfr@canb.auug.org.au: fix powerpc build] Signed-off-by: Tang Chen Reviewed-by: Zhang Yanfei Cc: "H. Peter Anvin" Cc: "Rafael J . Wysocki" Cc: Chen Tang Cc: Gong Chen Cc: Ingo Molnar Cc: Jiang Liu Cc: Johannes Weiner Cc: Lai Jiangshan Cc: Larry Woodman Cc: Len Brown Cc: Liu Jiang Cc: Mel Gorman Cc: Michal Nazarewicz Cc: Minchan Kim Cc: Prarit Bhargava Cc: Rik van Riel Cc: Taku Izumi Cc: Tejun Heo Cc: Thomas Gleixner Cc: Thomas Renninger Cc: Toshi Kani Cc: Vasilis Liaskovitis Cc: Wanpeng Li Cc: Wen Congyang Cc: Yasuaki Ishimatsu Cc: Yinghai Lu Signed-off-by: Stephen Rothwell Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

sh: delete __cpuinit usage from all sh files

2013-07-14T23:36:53Z

The __cpuinit type of throwaway sections might have made sense some time ago when RAM was more constrained, but now the savings do not offset the cost and complications. For example, the fix in commit 5e427ec2d0 ("x86: Fix bit corruption at CPU resume time") is a good example of the nasty type of bugs that can be created with improper use of the various __init prefixes. After a discussion on LKML[1] it was decided that cpuinit should go the way of devinit and be phased out. Once all the users are gone, we can then finally remove the macros themselves from linux/init.h. Note that some harmless section mismatch warnings may result, since notify_cpu_starting() and cpu_up() are arch independent (kernel/cpu.c) are flagged as __cpuinit -- so if we remove the __cpuinit from arch specific callers, we will also get section mismatch warnings. As an intermediate step, we intend to turn the linux/init.h cpuinit content into no-ops as early as possible, since that will get rid of these warnings. In any case, they are temporary and harmless. This removes all the arch/sh uses of the __cpuinit macros from all C files. Currently sh does not have any __CPUINIT used in assembly files. [1] https://lkml.org/lkml/2013/5/20/589 Cc: Paul Mundt Cc: linux-sh@vger.kernel.org Signed-off-by: Paul Gortmaker

mtd/uclinux: Use generic __bss_stop instead of _ebss

2012-06-27T07:59:43Z

The standard (see BSS_SECTION() in and ) symbol for the end of BSS is __bss_stop. This allows to remove all local declarations that have been added to several architectures just to please CONFIG_MTD_UCLINUX. Signed-off-by: Geert Uytterhoeven Acked-by: Paul Mundt Acked-by: Mike Frysinger Acked-by: Michal Simek Acked-by: Greg Ungerer

SuperH: Use HAVE_MEMBLOCK_NODE_MAP

2011-12-08T18:22:08Z

sh doesn't access early_node_map[] directly and enabling HAVE_MEMBLOCK_NODE_MAP is trivial - replacing add_active_range() calls with memblock_set_node() and selecting HAVE_MEMBLOCK_NODE_MAP is enough. Signed-off-by: Tejun Heo Cc: Paul Mundt Cc: linux-sh@vger.kernel.org

sh: kexec: Register crashk_res

2011-09-05T04:10:50Z

Register crashk_res so that it can be used by kexec-tools via /proc/iomem. The crash kernel resource needs to be requested the same as the other kernel resources due to the fact that it's handled during the common path for adding new memory ranges, so it's added in to __add_active_range() with the others. This ensures that the crash kernel is properly reserved regardless of which memory range it's placed in. Signed-off-by: Simon Horman Signed-off-by: Paul Mundt

Fix common misspellings

2011-03-31T14:26:23Z

Fixes generated by 'codespell' and manually reviewed. Signed-off-by: Lucas De Marchi

sh: Break out cpuinfo_op procfs bits.

2010-11-09T07:40:16Z

Presently this is all inlined in setup.c, which is not really the place for it. Follow the x86 example and split it out into its own file. Signed-off-by: Paul Mundt

sh: Fix the sparsemem disabled build.

2010-10-27T05:24:34Z

The introduction of MAX_PHYSMEM_BITS in to the initial cpuinfo struct causes a build error when sparsemem is disabled and asm/sparsemem.h is not brought in by other means. Include it explicitly. Signed-off-by: Paul Mundt

sh: Expose physical addressing mode through cpuinfo.

2010-10-26T05:44:58Z

CPUs can be in either the legacy 29-bit or 32-bit physical addressing modes. This follows the x86 approach of tracking the phys bits in cpuinfo and exposing it to userspace through procfs. This change was requested to permit kexec-tools to detect the physical addressing mode in order to determine the appropriate address mangling. Signed-off-by: Paul Mundt

sh: Fix address calculation of Initrd

2010-10-06T07:53:28Z

Signed-off-by: Nobuhiro Iwamatsu Signed-off-by: Paul Mundt