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 5e427ec2 ("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.

This removes all the parisc uses of the __cpuinit macros.

[1] https://lkml.org/lkml/2013/5/20/589Acked-by: NJames Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Helge Deller <deller@gmx.de>
Cc: linux-parisc@vger.kernel.org
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>

Signed-off-by: NHelge Deller <deller@gmx.de>
Cc: <stable@vger.kernel.org> # 3.10

The pa_pdc_cell struct can be kmalloc'd, so do that instead.
Signed-off-by: NKyle McMartin <kyle@mcmartin.ca>

Signed-off-by: NAlexander Beregalov <a.beregalov@gmail.com>
Acked-by: NMatthew Wilcox <willy@linux.intel.com>
Acked-by: NGrant Grundler <grundler@parisc-linux.org>
Signed-off-by: NKyle McMartin <kyle@mcmartin.ca>

It'd be rather useful for debian-installer if we could get hold of
accurate firmware information on whether only 32-bit kernels are
supported, only 64-bit kernels, or both; this would allow us to present
an accurate menu of kernel packages if more than one is available,
rather than the user having to guess. This patch attempts to expose it
in cpuinfo.

I adjusted pdc_model_capabilities to cope with a potential
PDC_INVALID_ARG return as the firmware manual instructs, by assuming
32-bit only. This may be the wrong place for it.

I made up user-visible capability names by total fiat and for the moment
ignored the other bits that may appear in the capabilities word.

I have no PA-RISC machine myself to test on, and no PA experience
either, so I rather hope that somebody will kind-heartedly take this and
fix it up if needed. I ran it past Dann Frazier on IRC and he said
"looks good to me", but I think without testing.

Also, this is against the Ubuntu 2.6.28 kernel tree since that's what I
had handy and I was a bit tight on disk space to slurp down another
tree. Sorry if it's skewed in any relevant way; I'll be happy to adjust
if necessary.

Thanks in advance!
Signed-off-by: NColin Watson <cjwatson@canonical.com>
Signed-off-by: NKyle McMartin <kyle@mcmartin.ca>

Impact: use new API

Use the accessors rather than frobbing bits directly.  Most of this is
in arch code I haven't even compiled, but it is mostly straightforward.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Signed-off-by: NMike Travis <travis@sgi.com>

Impact: cleanup, futureproof

In fact, all cpumask ops will only be valid (in general) for bit
numbers < nr_cpu_ids.  So use that instead of NR_CPUS in various
places.

This is always safe: no cpu number can be >= nr_cpu_ids, and
nr_cpu_ids is initialized to NR_CPUS at boot.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Signed-off-by: NMike Travis <travis@sgi.com>
Acked-by: NIngo Molnar <mingo@elte.hu>

parisc: Replace most arrays sized by NR_CPUS with percpu variables.
Signed-off-by: NHelge Deller <deller@gmx.de>
Signed-off-by: NKyle McMartin <kyle@mcmartin.ca>

If we already have NR_CPUS worth of cpus online, we obviously shouldn't
be trying to bring up more... Fixes a particularly vexing issue I had when
running another machines kernel on my rp3440.
Signed-off-by: NKyle McMartin <kyle@mcmartin.ca>

Hi Kyle,

this patch fixes two section mismatches in arch/parisc/kernel:
WARNING: arch/parisc/kernel/built-in.o(.data.read_mostly+0xd8): Section mismatch: reference to .init.text:processor_probe (between 'cpu_driver' and 'boot_cpu_data')
WARNING: arch/parisc/kernel/built-in.o(.text.alloc_pa_dev+0x140): Section mismatch: reference to .init.text:parisc_hardware_description (after 'alloc_pa_dev')

Additionally, mark some tables as constants.

Please apply, Helge
Signed-off-by: NHelge Deller <deller@gmx.de>
Signed-off-by: NKyle McMartin <kyle@parisc-linux.org>

Spelling fixes in arch/parisc/.
Signed-off-by: NSimon Arlott <simon@fire.lp0.eu>
Acked-by: NGrant Grundler <grundler@parisc-linux.org>
Signed-off-by: NKyle McMartin <kyle@parisc-linux.org>

First thing mm.h does is including sched.h solely for can_do_mlock() inline
function which has "current" dereference inside. By dealing with can_do_mlock()
mm.h can be detached from sched.h which is good. See below, why.

This patch
a) removes unconditional inclusion of sched.h from mm.h
b) makes can_do_mlock() normal function in mm/mlock.c
c) exports can_do_mlock() to not break compilation
d) adds sched.h inclusions back to files that were getting it indirectly.
e) adds less bloated headers to some files (asm/signal.h, jiffies.h) that were
   getting them indirectly

Net result is:
a) mm.h users would get less code to open, read, preprocess, parse, ... if
   they don't need sched.h
b) sched.h stops being dependency for significant number of files:
   on x86_64 allmodconfig touching sched.h results in recompile of 4083 files,
   after patch it's only 3744 (-8.3%).

Cross-compile tested on

	all arm defconfigs, all mips defconfigs, all powerpc defconfigs,
	alpha alpha-up
	arm
	i386 i386-up i386-defconfig i386-allnoconfig
	ia64 ia64-up
	m68k
	mips
	parisc parisc-up
	powerpc powerpc-up
	s390 s390-up
	sparc sparc-up
	sparc64 sparc64-up
	um-x86_64
	x86_64 x86_64-up x86_64-defconfig x86_64-allnoconfig

as well as my two usual configs.
Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

smp_cpus_done is too early for us... before we even do a device
inventory! Move update_cr16_clocksource into the tail end of
processor_probe() and stub it out on CONFIG_SMP=n builds.

Verified that clocksource0 is properly updated to use jiffies
on an SMP build.
Signed-off-by: NKyle McMartin <kyle@parisc-linux.org>

- additionally update my copyright timestamps
Signed-off-by: NHelge Deller <deller@gmx.de>
Signed-off-by: NKyle McMartin <kyle@parisc-linux.org>

it's unlikely iCOD will ever happen on parisc-linux now... ;-)
Signed-off-by: NKyle McMartin <kyle@parisc-linux.org>

Need to remove the initializer as well. Doh.
Signed-off-by: NKyle McMartin <kyle@parisc-linux.org>

processor_probe() shouldn't clobber cpu_data[0]
cpu_data[0].it_value (used by timer_interrupt()) is already set.
Signed-off-by: NGrant Grundler <grundler@parisc-linux.org>
Signed-off-by: NKyle McMartin <kyle@parisc-linux.org>

Signed-off-by: NJörn Engel <joern@wohnheim.fh-wedel.de>
Signed-off-by: NAdrian Bunk <bunk@stusta.de>

Flag a whole bunch of things as __read_mostly on parisc. Also flag a few
branches as unlikely() and cleanup a bit of code.
Signed-off-by: NHelge Deller <deller@parisc-linux.org>
Signed-off-by: NKyle McMartin <kyle@parisc-linux.org>

Convert pa_dev->hpa from an unsigned long to a struct resource.
Signed-off-by: NMatthew Wilcox <willy@parisc-linux.org>

Fix up users of ->hpa to use ->hpa.start instead.
Signed-off-by: NMatthew Wilcox <willy@parisc-linux.org>
Signed-off-by: NKyle McMartin <kyle@parisc-linux.org>

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!