summaryrefslogtreecommitdiffstats
path: root/arch/sh/kernel/cpu/sh2/probe.c
AgeCommit message (Collapse)Author
2013-07-14sh: delete __cpuinit usage from all sh filesPaul Gortmaker
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 <lethal@linux-sh.org> Cc: linux-sh@vger.kernel.org Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2010-04-21sh: Tidy CPU probing and fixup section annotations.Paul Mundt
This does a detect_cpu_and_cache_system() -> cpu_probe() rename, tidies up the unused return value, and stuffs it under __cpuinit in preparation for CPU hotplug. Signed-off-by: Paul Mundt <lethal@linux-sh.org>
2009-08-15sh: Track the CPU family in sh_cpuinfo.Paul Mundt
This adds a family member to struct sh_cpuinfo, which allows us to fall back more on the probe routines to work out what sort of subtype we are running on. This will be used by the CPU cache initialization code in order to first do family-level initialization, followed by subtype-level optimizations. Signed-off-by: Paul Mundt <lethal@linux-sh.org>
2007-09-27sh: Use boot_cpu_data for CPU probe.Paul Mundt
This moves off of smp_processor_id() and only sets the probe information for the boot CPU directly. This will be copied out for the secondaries, so there's no reason to do this each time. This also allows for some header tidying. Signed-off-by: Paul Mundt <lethal@linux-sh.org>
2007-06-11sh: Tidy up dependencies for SH-2 build.Paul Mundt
SH-2 can presently get in to some pretty bogus states, so we tidy up the dependencies a bit and get it all building again. This gets us a bit closer to a functional allyesconfig and allmodconfig, though there are still a few things to fix up. Signed-off-by: Paul Mundt <lethal@linux-sh.org>
2007-06-08sh: Kill off dead SH7604 support.Paul Mundt
This was added during 2.5.x, but was never moved along. This can easily be resurrected if someone has one they wish to work with, but it's not worth keeping around in its current form. Signed-off-by: Paul Mundt <lethal@linux-sh.org>
2007-02-13sh: Fixup cpu_data references for the non-boot CPUs.Paul Mundt
There are a lot of bogus cpu_data-> references that only end up working for the boot CPU, convert these to current_cpu_data to fixup SMP. Signed-off-by: Paul Mundt <lethal@linux-sh.org>
2006-12-06sh: Add support for SH7206 and SH7619 CPU subtypes.Yoshinori Sato
This implements initial support for the SH7206 (SH-2A) and SH7619 (SH-2) MMU-less CPUs. Signed-off-by: Yoshinori Sato <ysato@users.sourceforge.jp> Signed-off-by: Paul Mundt <lethal@linux-sh.org>
2005-04-16Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!