From: Kyle McMartin <kyle@hera.kernel.org>
To: linux-parisc@vger.kernel.org
Subject: [git] parisc: Changes to ref refs/heads/master
Date: Thu, 2 Apr 2009 01:43:48 GMT [thread overview]
Message-ID: <200904020143.n321hmK4011043@hera.kernel.org> (raw)
New commits:
commit 7cec2ef4a298605b010f1c80041de884e777ea67
Merge: 91400ac365da35b18036b46bdda27ddbcee4a663 9bc181d8d7cb6462de0c315e364780ad275f7c57
Author: Kyle McMartin <kyle@mcmartin.ca>
Date: Thu Apr 2 01:43:14 2009 +0000
Merge branch 'rusty-cpumask-parisc' into parisc
commit 9bc181d8d7cb6462de0c315e364780ad275f7c57
Author: Rusty Russell <rusty@rustcorp.com.au>
Date: Mon Mar 16 14:19:38 2009 +1030
cpumask: Use accessors code.: parisc
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>
commit bd071e1a371d31db243edc4714ff9e8d1ea1309e
Author: Rusty Russell <rusty@rustcorp.com.au>
Date: Mon Mar 16 14:19:37 2009 +1030
cpumask: prepare for iterators to only go to nr_cpu_ids/nr_cpumask_bits.: parisc
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>
commit 91887a362984324e254473e92820758c8e658f78
Author: Rusty Russell <rusty@rustcorp.com.au>
Date: Mon Mar 16 14:19:37 2009 +1030
cpumask: arch_send_call_function_ipi_mask: parisc
We're weaning the core code off handing cpumask's around on-stack.
This introduces arch_send_call_function_ipi_mask(), and by defining
it, the old arch_send_call_function_ipi is defined by the core code.
We also take the chance to change send_IPI_mask() and use the new
for_each_cpu() iterator.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
next reply other threads:[~2009-04-02 1:43 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-02 1:43 Kyle McMartin [this message]
-- strict thread matches above, loose matches on Subject: below --
2010-10-14 1:04 [git] parisc: Changes to ref refs/heads/master Kyle McMartin
2009-12-16 4:18 Kyle McMartin
2009-04-02 4:16 Kyle McMartin
2009-04-02 2:46 Kyle McMartin
2009-04-02 1:34 Kyle McMartin
2009-04-02 0:20 Kyle McMartin
2009-04-02 0:13 Kyle McMartin
2009-04-02 0:20 ` Alexander Beregalov
2009-04-02 0:33 ` Kyle McMartin
2009-03-31 2:52 Kyle McMartin
2009-03-31 21:05 ` Helge Deller
2009-01-05 19:19 Kyle McMartin
2008-12-23 6:36 Kyle McMartin
2008-12-22 23:59 Kyle McMartin
2008-12-22 17:32 Kyle McMartin
2008-12-21 0:41 Kyle McMartin
2008-12-17 23:40 Kyle McMartin
2008-12-14 2:57 Kyle McMartin
2008-12-09 22:16 Kyle McMartin
2008-12-08 2:13 Kyle McMartin
2008-12-08 2:06 Kyle McMartin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200904020143.n321hmK4011043@hera.kernel.org \
--to=kyle@hera.kernel.org \
--cc=linux-parisc@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.