linux.git/arch/parisc/kernel/processor.c, branch v3.17

parisc: delete __cpuinit usage from all users

2013-07-14T23:36:51+00:00

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.

This removes all the parisc uses of the __cpuinit macros.

[1] https://lkml.org/lkml/2013/5/20/589

Acked-by: James Bottomley 
Cc: Helge Deller 
Cc: linux-parisc@vger.kernel.org
Signed-off-by: Paul Gortmaker

parisc: more capabilities info in /proc/cpuinfo

2013-07-09T20:09:17+00:00

Signed-off-by: Helge Deller 
Cc:  # 3.10

parisc: processor.c, fix bloated stack frame

2009-07-03T03:34:11+00:00

The pa_pdc_cell struct can be kmalloc'd, so do that instead.

Signed-off-by: Kyle McMartin

parisc: remove CVS keywords

2009-07-03T03:34:06+00:00

Signed-off-by: Alexander Beregalov 
Acked-by: Matthew Wilcox 
Acked-by: Grant Grundler 
Signed-off-by: Kyle McMartin

Merge branch 'rusty-cpumask-parisc' into parisc

2009-04-02T01:43:14+00:00

parisc: expose 32/64-bit capabilities in cpuinfo

2009-03-31T02:51:33+00:00

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: Colin Watson 
Signed-off-by: Kyle McMartin

cpumask: Use accessors code.: parisc

2009-03-16T03:49:38+00:00

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: Rusty Russell 
Signed-off-by: Mike Travis

cpumask: prepare for iterators to only go to nr_cpu_ids/nr_cpumask_bits.: parisc

2009-03-16T03:49:37+00:00

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: Rusty Russell 
Signed-off-by: Mike Travis 
Acked-by: Ingo Molnar

parisc: Replace NR_CPUS in parisc code

2009-01-05T19:09:02+00:00

parisc: Replace most arrays sized by NR_CPUS with percpu variables.

Signed-off-by: Helge Deller 
Signed-off-by: Kyle McMartin

[PARISC] Unbreak processor_probe when we have more than NR_CPUS

2007-10-18T07:58:57+00:00

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: Kyle McMartin