<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/arch/parisc/kernel/processor.c, branch v2.6.30</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>Merge branch 'rusty-cpumask-parisc' into parisc</title>
<updated>2009-04-02T01:43:14+00:00</updated>
<author>
<name>Kyle McMartin</name>
<email>kyle@mcmartin.ca</email>
</author>
<published>2009-04-02T01:43:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=7cec2ef4a298605b010f1c80041de884e777ea67'/>
<id>7cec2ef4a298605b010f1c80041de884e777ea67</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>parisc: expose 32/64-bit capabilities in cpuinfo</title>
<updated>2009-03-31T02:51:33+00:00</updated>
<author>
<name>Colin Watson</name>
<email>cjwatson@canonical.com</email>
</author>
<published>2009-01-30T01:03:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=445c088f88d63db49598390be3525252d211688f'/>
<id>445c088f88d63db49598390be3525252d211688f</id>
<content type='text'>
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 &lt;cjwatson@canonical.com&gt;
Signed-off-by: Kyle McMartin &lt;kyle@mcmartin.ca&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;cjwatson@canonical.com&gt;
Signed-off-by: Kyle McMartin &lt;kyle@mcmartin.ca&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>cpumask: Use accessors code.: parisc</title>
<updated>2009-03-16T03:49:38+00:00</updated>
<author>
<name>Rusty Russell</name>
<email>rusty@rustcorp.com.au</email>
</author>
<published>2009-03-16T03:49:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=9bc181d8d7cb6462de0c315e364780ad275f7c57'/>
<id>9bc181d8d7cb6462de0c315e364780ad275f7c57</id>
<content type='text'>
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 &lt;rusty@rustcorp.com.au&gt;
Signed-off-by: Mike Travis &lt;travis@sgi.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;rusty@rustcorp.com.au&gt;
Signed-off-by: Mike Travis &lt;travis@sgi.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>cpumask: prepare for iterators to only go to nr_cpu_ids/nr_cpumask_bits.: parisc</title>
<updated>2009-03-16T03:49:37+00:00</updated>
<author>
<name>Rusty Russell</name>
<email>rusty@rustcorp.com.au</email>
</author>
<published>2009-03-16T03:49:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=bd071e1a371d31db243edc4714ff9e8d1ea1309e'/>
<id>bd071e1a371d31db243edc4714ff9e8d1ea1309e</id>
<content type='text'>
Impact: cleanup, futureproof

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

This is always safe: no cpu number can be &gt;= nr_cpu_ids, and
nr_cpu_ids is initialized to NR_CPUS at boot.

Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
Signed-off-by: Mike Travis &lt;travis@sgi.com&gt;
Acked-by: Ingo Molnar &lt;mingo@elte.hu&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Impact: cleanup, futureproof

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

This is always safe: no cpu number can be &gt;= nr_cpu_ids, and
nr_cpu_ids is initialized to NR_CPUS at boot.

Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
Signed-off-by: Mike Travis &lt;travis@sgi.com&gt;
Acked-by: Ingo Molnar &lt;mingo@elte.hu&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>parisc: Replace NR_CPUS in parisc code</title>
<updated>2009-01-05T19:09:02+00:00</updated>
<author>
<name>Helge Deller</name>
<email>deller@gmx.de</email>
</author>
<published>2008-12-31T03:12:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=ef017bebd01c1b4e075d649eee0c8c1c79f9ceb9'/>
<id>ef017bebd01c1b4e075d649eee0c8c1c79f9ceb9</id>
<content type='text'>
parisc: Replace most arrays sized by NR_CPUS with percpu variables.

Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
Signed-off-by: Kyle McMartin &lt;kyle@mcmartin.ca&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
parisc: Replace most arrays sized by NR_CPUS with percpu variables.

Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
Signed-off-by: Kyle McMartin &lt;kyle@mcmartin.ca&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[PARISC] Unbreak processor_probe when we have more than NR_CPUS</title>
<updated>2007-10-18T07:58:57+00:00</updated>
<author>
<name>Kyle McMartin</name>
<email>kyle@mcmartin.ca</email>
</author>
<published>2007-10-18T07:03:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=f8b9e5945738d25c04d6735c2a070f574d2b34c5'/>
<id>f8b9e5945738d25c04d6735c2a070f574d2b34c5</id>
<content type='text'>
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 &lt;kyle@mcmartin.ca&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;kyle@mcmartin.ca&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[PARISC] fix section mismatches in arch/parisc/kernel</title>
<updated>2007-05-27T17:36:27+00:00</updated>
<author>
<name>Helge Deller</name>
<email>deller@gmx.de</email>
</author>
<published>2007-05-27T17:30:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=e9541d0ca2a5d713c5d8dcb635d3f41e75c90bfb'/>
<id>e9541d0ca2a5d713c5d8dcb635d3f41e75c90bfb</id>
<content type='text'>
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 &lt;deller@gmx.de&gt;
Signed-off-by: Kyle McMartin &lt;kyle@parisc-linux.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;deller@gmx.de&gt;
Signed-off-by: Kyle McMartin &lt;kyle@parisc-linux.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[PARISC] spelling fixes: arch/parisc/</title>
<updated>2007-05-23T02:52:16+00:00</updated>
<author>
<name>Simon Arlott</name>
<email>simon@fire.lp0.eu</email>
</author>
<published>2007-05-11T19:42:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=7022672e4046fac4699aa5f8ff2a5213b7ec4ff9'/>
<id>7022672e4046fac4699aa5f8ff2a5213b7ec4ff9</id>
<content type='text'>
Spelling fixes in arch/parisc/.

Signed-off-by: Simon Arlott &lt;simon@fire.lp0.eu&gt;
Acked-by: Grant Grundler &lt;grundler@parisc-linux.org&gt;
Signed-off-by: Kyle McMartin &lt;kyle@parisc-linux.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Spelling fixes in arch/parisc/.

Signed-off-by: Simon Arlott &lt;simon@fire.lp0.eu&gt;
Acked-by: Grant Grundler &lt;grundler@parisc-linux.org&gt;
Signed-off-by: Kyle McMartin &lt;kyle@parisc-linux.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Detach sched.h from mm.h</title>
<updated>2007-05-21T16:18:19+00:00</updated>
<author>
<name>Alexey Dobriyan</name>
<email>adobriyan@gmail.com</email>
</author>
<published>2007-05-20T21:22:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=e8edc6e03a5c8562dc70a6d969f732bdb355a7e7'/>
<id>e8edc6e03a5c8562dc70a6d969f732bdb355a7e7</id>
<content type='text'>
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: Alexey Dobriyan &lt;adobriyan@gmail.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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: Alexey Dobriyan &lt;adobriyan@gmail.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[PARISC] clocksource: Move update_cr16_clocksource later in boot</title>
<updated>2007-02-27T03:21:22+00:00</updated>
<author>
<name>Kyle McMartin</name>
<email>kyle@mako.i.cabal.ca</email>
</author>
<published>2007-02-27T03:21:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=01363220f5d23ef68276db8974e46a502e43d01d'/>
<id>01363220f5d23ef68276db8974e46a502e43d01d</id>
<content type='text'>
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: Kyle McMartin &lt;kyle@parisc-linux.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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: Kyle McMartin &lt;kyle@parisc-linux.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
