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

Signed-off-by: Kyle McMartin <kyle@mcmartin.ca>

Signed-off-by: Alexander Beregalov <a.beregalov@gmail.com>
Acked-by: Matthew Wilcox <willy@linux.intel.com>
Acked-by: Grant Grundler <grundler@parisc-linux.org>
Signed-off-by: Kyle 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: Colin Watson <cjwatson@canonical.com>
Signed-off-by: Kyle 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: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Mike 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: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Mike Travis <travis@sgi.com>
Acked-by: Ingo Molnar <mingo@elte.hu>

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

Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Kyle 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: Kyle 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: Helge Deller <deller@gmx.de>
Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>

Spelling fixes in arch/parisc/.

Signed-off-by: Simon Arlott <simon@fire.lp0.eu>
Acked-by: Grant Grundler <grundler@parisc-linux.org>
Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>