On Mon, 20 Oct 2008, Jon Smirl wrote:
> On Mon, Oct 20, 2008 at 1:55 AM, Guennadi Liakhovetski
> <[EMAIL PROTECTED]> wrote:
> > On Sun, 19 Oct 2008, Jon Smirl wrote:
> >
> >> Is i2c-mpc built into your kernel? It's not going to module auto-load
> >> because the names don't match - fsl-i2c and i2c-
On Mon, 2008-10-20 at 22:05 +, Linux Kernel Mailing List wrote:
> Gitweb:
> http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=0c5d1eb77a8be917b638344a22afe1398236482b
> Commit: 0c5d1eb77a8be917b638344a22afe1398236482b
> Parent: d6d5aeb661fc14655c417f35
On Mon, 2008-10-20 at 23:03 -0500, Milton Miller wrote:
> These functions should have been static, and inspection shows they
> are no longer used. (We used to parse mem= but we now defer that
> to early_param).
Actually the last user was the crashkernel= handling, but that was
removed a while ag
Jeff Kirsher wrote:
Add a bool IGB_DCA defined to y if IGB and DCA are enabled, but IGB isn't y
while DCA=m. And thus remove the need to select INTEL_IOATDMA when IGB is
enabled, so that non-x86 architectures can build the igb driver.
Based on work/patch from Brice Goglin <[EMAIL PROTECTED]>
Hannes Hering wrote:
This patch implements the memory notifier to update the busmap instantly
instead of rebuilding the whole map. This is necessary because
walk_memory_resource provides different information than required during memory
hotplug.
Signed-off-by: Hannes Hering <[EMAIL PROTECTED]>
-
On Mon, 2008-10-20 at 15:04 +0530, Mohan Kumar M wrote:
> Michael Ellerman wrote:
> >>> #ifdef CONFIG_CRASH_DUMP
> >>> +#ifdef CONFIG_RELOCATABLE
> >>> +
> >>> +static inline void reserve_kdump_trampoline(void) { ; }
> >>> +static inline void setup_kdump_trampoline(void) { ; }
> >>> +
> >>> +#else
> Thanks. The fdt_del_node approach works pretty nicely. I added a
> dt_ops hook since fdt is static in libfdt-wrapper.c.
.../...
David says your patch is ok, However it's not in the right form. Could
you repost it please with a proper changeset comment and signed-off-by:
line ?
Thanks !
Ch
Chris Friesen writes:
> The current -git fails to build on 64-bit powerpc (failure log below) .
> Initially I tried using my older toolchain, when I first saw the
> problem I built a new toolchain with crosstool (gcc 4.1.2 and binutils
> 2.16.1) and tried again but got the same problem.
It's
Benjamin Herrenschmidt wrote:
On Thu, 2008-10-16 at 10:38 -0400, Josh Boyer wrote:
On Thu, Oct 16, 2008 at 03:56:50PM +1100, Benjamin Herrenschmidt wrote:
drivers/net/ibm_newemac/mal.c: In function 'mal_txeob':
drivers/net/ibm_newemac/mal.c:284: error: implicit declaration of function
'mtdcri'
On Oct 17, 2008, at 1:56 PM, Anton Vorontsov wrote:
The RTC is sitting on the I2C2 bus at address 0x68. RTC interrupt
signal
is connected to the IPIC's EXT2 interrupt line, the line is shared
with
Vitesse 8201 Ethernet PHY.
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
arch/powerp
On Oct 17, 2008, at 1:57 PM, Anton Vorontsov wrote:
MCU is an external Freescale MC9S08QG8 microcontroller, mainly used to
provide soft power-off function, but also exports two GPIOs (wired to
the LEDs and also available from the external headers).
Signed-off-by: Anton Vorontsov <[EMAIL PROTEC
Please pull from 'for-2.6.28' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git for-2.6.28
to receive the following updates:
Documentation/powerpc/booting-without-of.txt |2 +
Documentation/powerpc/dts-bindings/fsl/board.txt |4 +--
arch/powerpc/boot/dt
X-Patchwork-Id: 5144
On Mon Oct 20, 2008 near 12:19:21 GMT, Brian King wrote:
>
> A new field has been added to the VPA as a method for
> the client OS to communicate to firmware the number of
> page ins it is performing when running collaborative
> memory overcommit. The hypervisor will use this
Oh, I forgot to metion just now. The linux is based on a custom built
kernel 2.4.22, not from Freescale.
On 10/20/08, mike zheng <[EMAIL PROTECTED]> wrote:
> On 10/20/08, Kim Phillips <[EMAIL PROTECTED]> wrote:
> > On Mon, 20 Oct 2008 15:00:33 -0700
> > "mike zheng" <[EMAIL PROTECTED]> wrote:
> >
On 10/20/08, Kim Phillips <[EMAIL PROTECTED]> wrote:
> On Mon, 20 Oct 2008 15:00:33 -0700
> "mike zheng" <[EMAIL PROTECTED]> wrote:
>
> > I have following kernel Oops when I run ifconfig to setup the UEC0 of
> > MPC8360MDS board. There is no hardware problem, the UEC0 runs well
> > under Uboot.
>
>
Change the top-level #address-cells and #size-cells to <2> so the
mpc8572ds.dts is easier to deal with both a true 32-bit physical
or 36-bit physical address space.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/mpc8572ds.dts | 27 +--
1 files ch
On Oct 20, 2008, at 10:51 PM, Benjamin Herrenschmidt wrote:
On Mon, 2008-10-20 at 22:45 -0500, Kumar Gala wrote:
If you had conventions on naming this is the first I've heard of
them. I know Paul asked about the [POWERPC] to powerpc: change on
list.
Well, they weren't official, but others
These functions should have been static, and inspection shows they
are no longer used. (We used to parse mem= but we now defer that
to early_param).
Signed-off-by: Milton Miller <[EMAIL PROTECTED]>
---
This version removes them
Index: next.git/arch/powerpc/kernel/prom_init.c
===
A patch of mine was recently committed to fix up STRICT_MM_TYPECHECKS
behaviour on powerpc (f5ea64dcbad89875d130596df14c9b25d994a737).
However, something which breaks it again seems to have slipped in
afterwards. So, here's another small fix.
Signed-off-by: David Gibson <[EMAIL PROTECTED]>
Index
On Mon, 2008-10-20 at 22:45 -0500, Kumar Gala wrote:
>
> If you had conventions on naming this is the first I've heard of
> them. I know Paul asked about the [POWERPC] to powerpc: change on
> list.
Well, they weren't official, but others seem to have picked them up, no
big deal but heh, here n
On Oct 20, 2008, at 7:11 PM, Benjamin Herrenschmidt wrote:
On Mon, 2008-10-20 at 13:04 -0500, Kumar Gala wrote:
Please pull from 'for-2.6.28' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git
for-2.6.28
to receive the following updates:
Ok so I'm not too happy. Ku
> - Finally, the Kconfig change shouldn't have been in your tree at all,
> or at least not without my or paulus ack and prior argeement that it
> should be merged that way. No big deal with this obviously correct
> patch but where do we put the limit ?
Same with the CONFIG_RELOCATABLE build fix.
Commit 9b09c6d909dfd8de96b99b9b9c808b94b0a71614 ("powerpc: Change the
default link address for pSeries zImage kernels") changed the
real-base value in the CHRP note added by addnote to the zImage from
12MB to 32MB. It turns out that this causes unnecessary extra reboots
on old 32-bit CHRP machines
On Oct 20, 2008, at 6:37 PM, Benjamin Herrenschmidt wrote:
On Mon, 2008-10-20 at 13:04 -0500, Kumar Gala wrote:
Please pull from 'for-2.6.28' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git
for-2.6.28
to receive the following updates:
Argh, that's not based on m
On Oct 20, 2008, at 6:29 PM, Benjamin Herrenschmidt wrote:
On Mon, 2008-10-20 at 13:04 -0500, Kumar Gala wrote:
Please pull from 'for-2.6.28' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git
for-2.6.28
It would be nice if you didn't create new branches all the time
Commit 9b09c6d909dfd8de96b99b9b9c808b94b0a71614 ("powerpc: Change the
default link address for pSeries zImage kernels") changed the
real-base value in the CHRP note added by addnote to the zImage from
12MB to 32MB. It turns out that this causes unnecessary extra reboots
on old 32-bit CHRP machines
Format string bug. Not exploitable, as this is only writable by root,
but worth fixing all the same.
See 326f6a5c9c9e1a62aec37bdc0c3f8d53adabe77b
Signed-off-by: Jon Smirl <[EMAIL PROTECTED]>
---
drivers/of/of_i2c.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/driver
On Mon, 2008-10-20 at 08:13 -0400, Jon Smirl wrote:
> Format string bug. Not exploitable, as this is only writable by root,
> but worth fixing all the same.
Where is your signed-off-by ?
Cheers,
Ben.
> See 326f6a5c9c9e1a62aec37bdc0c3f8d53adabe77b
> ---
> drivers/of/of_i2c.c |2 +-
> 1 file
On Fri, Oct 17, 2008 at 07:14:05PM -0700, Mike Ditto wrote:
> David Gibson wrote:
> > Deleting the irrelevant parts or picking a device tree to pass to
> > fdt_init() are both reasonable solutions. libfdt which is included in
> > the bootwrapper has functions for removing unwanted nodes: either
>
With the new generic smp call function helpers, I noticed the code in
smp_message_recv was a single function call in many cases. While
getting the message number from the ipi data is easy, we can reduce
the path length by a function and data dependent switch by registering
separate ipi actions for
64 bit powerpc requires the kexec user space tools avoid overwriting
the static kernel image and translation hash table when choosing
where to put memory image data because it copies the data into place
using the kernels virtual memory system. Kexec userspace determines
these and other areas block
We used to assume that even numbered threads were the primary
threads, ie those that would be listed and started as a cpu from
open firmware. Replace a left over is even (% 2) check with a check
for it being a primary thread and update the comments.
Tested with a debug print on pseries, identical
These functions should have been static, and inspection shows they
are no longer used. (We used to parse mem= but now we defer that
to early_param, and move the initrd and move the device tree if
needed).
Signed-off-by: Milton Miller <[EMAIL PROTECTED]>
---
X-Patchwork-ID: 19580
Changelog edited
numa_enforce_memory_limit tried to be smart and only call lmb_end_of_DRAM
when a memory limit was set via mem= on the command line. However,
the early boot code will also limit memory added to the lmb system
when iommu=off is specified. When this happens, the page allocator
is given pages not in
Ben,
Please do a:
git pull \
git://git.kernel.org/pub/scm/linux/kernel/git/jk/spufs.git merge
For a few more spufs changes for .28
Cheers,
Jeremy
---
diffstat:
arch/powerpc/platforms/cell/spufs/file.c | 155 ++
arch/powerpc/platforms/cell/spufs/run.c|3
Anton, is your mmc_spi driver (of_mmc_spi.c) going in any time soon?
I've been running it in my local tree for several months.
--
Jon Smirl
[EMAIL PROTECTED]
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linux
On Mon, 20 Oct 2008 15:00:33 -0700
"mike zheng" <[EMAIL PROTECTED]> wrote:
> I have following kernel Oops when I run ifconfig to setup the UEC0 of
> MPC8360MDS board. There is no hardware problem, the UEC0 runs well
> under Uboot.
does this occur on vanilla u-boot and kernel versions? if so, whi
Add the of_find_i2c_device_by_node function. This allows you to follow
a reference in the device tree to an i2c device node and then locate
the linux device instantiated by the device tree. Example use, an i2s
codec controlled by i2c.
Anton - this version is based off from your patches
Signed-off
On Mon, 2008-10-20 at 13:04 -0500, Kumar Gala wrote:
> Please pull from 'for-2.6.28' branch of
>
> master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git for-2.6.28
>
> to receive the following updates:
Ok so I'm not too happy. Kumar, you need to be a little bit more careful
with yo
Hi Mike,
Just a first small thing:
On Mon, 20 Oct 2008 10:03:20 -0700 Mike Travis <[EMAIL PROTECTED]> wrote:
>
> 1) The #ifdef CONFIG_HOTPLUG_CPU seems unnecessary these days.
> 2) The loop can simply skip over offline cpus, rather than creating a tmp
> mask.
> 3) set_mask is set to either a sin
On Mon, Oct 20, 2008 at 09:14:02AM -0400, Josh Boyer wrote:
>Hi Ben,
>
>Please pull the 'next' branch of the 4xx tree to pick up what should be
>most of the remaining changes for 2.6.28. Defconfig updates will come
>after -rc1.
>
>josh
>
>The following changes since commit 6dc6472581f693b5fc95aebe
On Mon, 2008-10-20 at 13:03 -0500, Kumar Gala wrote:
> There are no users of PPC_MERGE in tree so we can get rid of it.
> It was a hold over from the arch/ppc days.
That's is all good but shouldn't be in your git tree for merge.
Ben.
> Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
> ---
> arch/
On Thu, 2008-10-16 at 17:31 +0800, Jason Jin wrote:
> Signed-off-by: Jason Jin <[EMAIL PROTECTED]>
> ---
> arch/powerpc/boot/dts/mpc8536ds.dts |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/mpc8536ds.dts
> b/arch/powerpc/boot/dts/mpc8536ds.
On Thu, 2008-10-16 at 10:38 -0400, Josh Boyer wrote:
> On Thu, Oct 16, 2008 at 03:56:50PM +1100, Benjamin Herrenschmidt wrote:
> >> drivers/net/ibm_newemac/mal.c: In function 'mal_txeob':
> >> drivers/net/ibm_newemac/mal.c:284: error: implicit declaration of function
> >> 'mtdcri'
> >> drivers/net
On Mon, 2008-10-20 at 13:04 -0500, Kumar Gala wrote:
> Please pull from 'for-2.6.28' branch of
>
> master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git for-2.6.28
>
> to receive the following updates:
Argh, that's not based on my current powerpc, if you needed me to move
fwd, plea
On Mon, 2008-10-20 at 13:04 -0500, Kumar Gala wrote:
> Please pull from 'for-2.6.28' branch of
>
> master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git for-2.6.28
It would be nice if you didn't create new branches all the time so I
don't have to change my git remotes config :-)
An
On Tue, 2008-10-21 at 10:21 +1100, Benjamin Herrenschmidt wrote:
> Didn't make it to patchwork initially, resending.
Ignore me, it made it and was superseeded...
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/lis
On Tue, 2008-10-14 at 11:12 +0200, Hendrik Brueckner wrote:
> Hello,
>
> I work on a network-based hvc console backend for s390 that allows
> to get "full-screen" terminal access to z/VM guest machines.
> The solution consists of a HVC backend that provides the terminal interface;
> and a tool to
Didn't make it to patchwork initially, resending.
Forwarded Message
From: Hendrik Brueckner <[EMAIL PROTECTED]>
To: Benjamin Herrenschmidt <[EMAIL PROTECTED]>, Linux PPC devel
, Jeremy Fitzhardinge <[EMAIL PROTECTED]>, Rusty
Russell <[EMAIL PROTECTED]>, Ryan S. Arnold <[EMAIL PRO
On Monday, October 20, 2008 4:06 pm Benjamin Herrenschmidt wrote:
> Some firmware fail to properly configure P2P bridges, leaving them
> with invalid bus numbers. In some cases, this happens on some embedded
> 4xx boards as the result of the kernel allocating different bus space
> than the firmware
Forwarded Message
From: Arjan van de Ven <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED], Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Subject: [PATCH] fix WARN() for PPC
Date: Mon, 20 Oct 2008 14:50:56 -0700
From: Arjan van de
Some firmware fail to properly configure P2P bridges, leaving them
with invalid bus numbers. In some cases, this happens on some embedded
4xx boards as the result of the kernel allocating different bus space
than the firmware does to host bridges while not setting
pcibios_assign_all_busses() for va
2008/10/20 Steven Rostedt <[EMAIL PROTECTED]>:
> I believe MIPS has the same issues as PPC. Doesn't it use a trampoline
> too?
No it doesn't seem to. If I'm not wrong, MIPS uses only the elf
relocation table to relocate
its addresses.
> I want to make the generic code handle trampolines a bit bet
2008/10/20 Josh Boyer <[EMAIL PROTECTED]>:
> That seems like a good plan. Should we mark dynamic ftrace as X86 only
> in Kconfig for .28 to prevent people from inadvertently setting it?
Hi Josh.
There are other arch that support ftrace as well like sh or sparc64
(I'm currently working on
an impl
> The part that didn't look correct is this line (note the operators)
>
>((buses >> 8) & 0xff) != <= bus->number) {
>
>Operators ^^ ^^
Ooohhh ... nice typo :-) The right one is <=, thanks for catching this !
> >From reading through the code and your textual description of w
A new field has been added to the VPA as a method for
the client OS to communicate to firmware the number of
page ins it is performing when running collaborative
memory overcommit. The hypervisor will use this information
to better determine if a partition is experiencing memory
pressure and needs
Benjamin Herrenschmidt wrote:
>>>
>>> + /* Check if setup is sensible at all */
>>> + if ((buses & 0xff) != bus->number ||
>>> + ((buses >> 8) & 0xff) != <= bus->number) {
>>
>> Note that I removed the <= from the above line -- I did not think it
>> was correct. Please let me know if
Hi All,
I have following kernel Oops when I run ifconfig to setup the UEC0 of
MPC8360MDS board. There is no hardware problem, the UEC0 runs well
under Uboot.
Any idea on this issue?
Thanks,
Mike
[EMAIL PROTECTED] root]# ifconfig eth0 47.135.148.158
Oops: machine check, sig: 7
NIP: C0126910 XE
On Mon, 2008-10-20 at 16:03 -0500, Ayman El-Khashab wrote:
> Thank you Ben, I've had success with the patch, details below ...
>
> Benjamin Herrenschmidt wrote:
>
> > Can you try this (untested) patch and send me the resulting dmesg log
> > (along with whether it helps).
> >
> > Index: linux-wo
Thank you Ben, I've had success with the patch, details below ...
Benjamin Herrenschmidt wrote:
> Can you try this (untested) patch and send me the resulting dmesg log
> (along with whether it helps).
>
> Index: linux-work/drivers/pci/probe.c
> ==
On Mon, Oct 20, 2008 at 02:32:21PM -0500, Kumar Gala wrote:
>
> On Oct 20, 2008, at 2:17 PM, Anton Vorontsov wrote:
>
>> Hi Kumar,
>>
>> On Mon, Oct 20, 2008 at 01:04:36PM -0500, Kumar Gala wrote:
>>> Please pull from 'for-2.6.28' branch of
>>>
>>> master.kernel.org:/pub/scm/linux/kernel/git/ga
On Oct 20, 2008, at 2:17 PM, Anton Vorontsov wrote:
Hi Kumar,
On Mon, Oct 20, 2008 at 01:04:36PM -0500, Kumar Gala wrote:
Please pull from 'for-2.6.28' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git
for-2.6.28
Could you tell the status of this patch?
[1/4] powe
Hi Kumar,
On Mon, Oct 20, 2008 at 01:04:36PM -0500, Kumar Gala wrote:
> Please pull from 'for-2.6.28' branch of
>
> master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git for-2.6.28
Could you tell the status of this patch?
[1/4] powerpc/QE: implement QE Pin Multiplexing API
http://
Please pull from 'for-2.6.28' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git for-2.6.28
to receive the following updates:
Documentation/powerpc/booting-without-of.txt |2 ++
Documentation/powerpc/dts-bindings/fsl/board.txt |4 ++--
arch/powerpc/Kconf
There are no users of PPC_MERGE in tree so we can get rid of it.
It was a hold over from the arch/ppc days.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
arch/powerpc/Kconfig |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
On Mon, 20 Oct 2008, Fr?d?ric Weisbecker wrote:
> There are other arch that support ftrace as well like sh or sparc64
> (I'm currently working on
> an implementation for mips).
> So the choice would be better between waiting for a fix or disable
> dynamic ftrace
> on Kconfig only for PowerPC.
Hi
On Mon, 20 Oct 2008, Josh Boyer wrote:
> On Mon, Oct 20, 2008 at 12:30:33PM -0400, Steven Rostedt wrote:
> >> Anyway, if you want a tester let me know. It seems 2.6.27.1 should be
> >> fine since FTRACE was disabled, but for .28-rc1 it would be cool if it
> >> worked :).
> >
> >Hi Josh,
> >
> >I
On Mon, Oct 20, 2008 at 12:30:33PM -0400, Steven Rostedt wrote:
>> Anyway, if you want a tester let me know. It seems 2.6.27.1 should be
>> fine since FTRACE was disabled, but for .28-rc1 it would be cool if it
>> worked :).
>
>Hi Josh,
>
>I've been looking deeper at the code for PPC. I realized t
nr_cpu_ids is the (badly named) runtime limit on possible CPU numbers;
ie. the variable version of NR_CPUS.
If we use this in *all* the cpu ops it simplifies the API, and will
be possible to allocate cpumasks of the minimal length at runtime.
From: Rusty Russell <[EMAIL PROTECTED]>
Signed-off-by:
We want to move cpumasks off the stack: no local decls, no passing by
copy. Linus suggested we use the array-or-pointer trick for on-stack
vars; we introduce a new cpumask_var_t for this.
Rather than pick an arbitrary limit, I chose a new config option so
arch maintainers can decide where their t
It's useful to check that no one is accessing > nr_cpumask_bits for
cpumasks. This also allows you to turn on CONFIG_CPUMASKS_OFFSTACK
even for smaller CONFIG_NR_CPUS.
From: Rusty Russell <[EMAIL PROTECTED]>
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
Signed-off-by: Mike Travis <[EMAIL PROTE
cpumask.h is pretty chaotic. Now we've replaced most of it, let's
group things together a bit better.
From: Rusty Russell <[EMAIL PROTECTED]>
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
Signed-off-by: Mike Travis <[EMAIL PROTECTED]>
---
include/linux/cpumask.h | 72 ++-
There's a common case where we want any online cpu except a particular
one. This creates a helper to do that, otherwise we need a temp var
and cpumask_andnot().
From: Rusty Russell <[EMAIL PROTECTED]>
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
Signed-off-by: Mike Travis <[EMAIL PROTECTED]>
In order to hide the definition of struct cpumask, we need to expose
only pointers. Plus, it fits the new API far better to have pointers.
This deprecates the old _map versions, and defines them in terms of the
_mask versions. It also centralizes the definitions (finally!).
From: Rusty Russell
Pointer-taking variants of first_cpu/next_cpu.
From: Rusty Russell <[EMAIL PROTECTED]>
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
Signed-off-by: Mike Travis <[EMAIL PROTECTED]>
---
include/linux/cpumask.h | 18 +-
lib/cpumask.c | 10 +-
2 files changed,
Instead of CPU_MASK_ALL_PTR and the SMP-only cpu_mask_all, this makes
cpu_all_mask and cpu_none_mask which are const cpumask pointers which
always exist.
From: Rusty Russell <[EMAIL PROTECTED]>
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
Signed-off-by: Mike Travis <[EMAIL PROTECTED]>
---
inc
Since cpumasks are to become pointers to undefined structs, we need to
replace assignments. Also, dynamically allocated ones will eventually
be nr_cpu_ids bits (<= NR_CPUS), so assignment is a definite no-no.
From: Rusty Russell <[EMAIL PROTECTED]>
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
nr_cpu_ids is going to become a constant under some configs, so don't
assign it. Currently only x86 seems to anyway.
From: Rusty Russell <[EMAIL PROTECTED]>
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
Signed-off-by: Mike Travis <[EMAIL PROTECTED]>
---
arch/x86/kernel/smpboot.c |4 ++--
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.
From: Rusty Russell <[EMAIL PROTECTED]>
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
Signed-off-by: Mike Travis <[EMAIL PROTECTED]>
---
arch/alpha/kernel/i
Since we're now preferring raw bitmaps for (eventually rare) static
cpumasks, we replace CPU_MASK_X with CPU_BITS_X.
From: Rusty Russell <[EMAIL PROTECTED]>
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
Signed-off-by: Mike Travis <[EMAIL PROTECTED]>
---
include/linux/cpumask.h | 44 +
Use the accessors rather than frobbing bits directly. Most of this is
in arch code I haven't even compiled, but is straightforward.
From: Rusty Russell <[EMAIL PROTECTED]>
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
Signed-off-by: Mike Travis <[EMAIL PROTECTED]>
---
arch/arm/mach-realview/p
This deprecates cpumask_of_cpu(), which returns a cpumask_t
(cpumask_of() returns a const pointer, instead).
From: Rusty Russell <[EMAIL PROTECTED]>
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
Signed-off-by: Mike Travis <[EMAIL PROTECTED]>
---
include/linux/cpumask.h | 16
nr_cpu_ids is the (badly named) runtime limit on possible CPU numbers;
ie. the variable version of NR_CPUS.
This makes is valid in all configs, including UP.
From: Rusty Russell <[EMAIL PROTECTED]>
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
Signed-off-by: Mike Travis <[EMAIL PROTECTED]>
---
Transition from cpumask_t-taking smp_call_function_mask() to a new
smp_call_function_many() which takes a struct cpumask *.
(Naming is inspired by smp_call_function_single).
Note that the new one returns void: the old one couldn't fail either
unless there was a logic bug.
From: Rusty Russell <[E
Since we are moving to const cpumask pointers for the maps, we need a
way to legitimately access them. Simple accessors work well.
From: Rusty Russell <[EMAIL PROTECTED]>
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
Signed-off-by: Mike Travis <[EMAIL PROTECTED]>
---
include/linux/cpumask.h |
Currently we have NR_CPUS, which is 1 on UP, and CONFIG_NR_CPUS on
SMP. If we make CONFIG_NR_CPUS always valid (and always 1 on !SMP),
we can skip the middleman.
This also allows us to find and check all the remaining NR_CPUS users.
From: Rusty Russell <[EMAIL PROTECTED]>
Signed-off-by: Rusty Ru
We want to move cpumasks off the stack: no local decls, no passing by
copy.
Most cpumask functions started with cpus_: these have been replaced by
cpumask_ ones which take struct cpumask pointers as expected, and macro
stubs used for the transition.
These four functions don't have good replacemen
There are times when we really want a static cpumask. Yet we don't
want to expose the struct cpumask definition, to avoid casual on-stack
usage and assignment.
So this macro allows you to do DECLARE_BITMAP(map, CONFIG_NR_CPUS); then use
to_cpumask() to turn it into a cpumask as needed.
Ugly? Ye
* Change genapic interfaces to accept cpumask_t pointers where possible.
* Modify external callers to use cpumask_t pointers in function calls.
* Create new send_IPI_mask_allbutself which is the same as the
send_IPI_mask functions but removes smp_processor_id() from list.
This remov
Set MAXSMP to enable a configuration with the maximum amount of CPUS and
NODES. Also enables CONFIG_CPUMASK_OFFSTACK which moves cpumask's off
the stack (and in structs) when using cpumask_var_t.
From: Mike Travis <[EMAIL PROTECTED]>
Acked-by: Rusty Russell <[EMAIL PROTECTED]>
---
arch/x86/Kconf
Using lots of allocs rather than one big alloc is less efficient, but
who cares for this setup function?
From: Rusty Russell <[EMAIL PROTECTED]>
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
Signed-off-by: Mike Travis <[EMAIL PROTECTED]>
---
kernel/sched.c | 133 --
We want to wean people off handing around cpumask_t's, and have them
pass by pointer instead. This does for_each_cpu_mask().
We immediately convert core files who were doing
"for_each_cpu_mask(... *mask)" since this is clearer.
From: Rusty Russell <[EMAIL PROTECTED]>
Signed-off-by: Rusty Russell
any_online_cpu() is a good name, but it takes a cpumask_t, not a
pointer.
From: Rusty Russell <[EMAIL PROTECTED]>
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
Signed-off-by: Mike Travis <[EMAIL PROTECTED]>
---
include/linux/cpumask.h | 11 ++-
lib/cpumask.c | 12
Remove CPUMASK_ALLOC() in favor of alloc_cpumask_var().
From: Rusty Russell <[EMAIL PROTECTED]>
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
Signed-off-by: Mike Travis <[EMAIL PROTECTED]>
---
include/linux/cpumask.h | 46 --
1 file changed, 8 inse
* use node_to_cpumask_ptr in place of node_to_cpumask to reduce stack
requirements in sched.c
Applies to linux-2.6.tip/master.
Signed-off-by: Mike Travis <[EMAIL PROTECTED]>
Acked-by: Rusty Russell <[EMAIL PROTECTED]>
---
kernel/sched.c | 13 +++--
1 file changed, 7 insertions(+)
Instead of accessing ->bits, we use cpumask_bits(). This will be very
useful when 'struct cpumask' has a hidden definition.
From: Rusty Russell <[EMAIL PROTECTED]>
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
Signed-off-by: Mike Travis <[EMAIL PROTECTED]>
---
include/linux/cpumask.h | 70
When nr_cpu_ids is set to CONFIG_NR_CPUS then references to nr_cpu_ids
will return the maximum index of the configured NR_CPUS (+1) instead
of the maximum index of the possible number of cpus (+1). This results
in extra unused memory being allocated by functions that are setting up
arrays of struc
Percpu areas are only allocated for possible cpus. In general, you
shouldn't access random cpu's percpu areas: you're corrupting memory.
From: Rusty Russell <[EMAIL PROTECTED]>
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
Signed-off-by: Mike Travis <[EMAIL PROTECTED]>
---
arch/m32r/kernel/sm
Add for_each_cpu_mask_and() function to eliminate need for a common use
of a temporary cpumask_t variable. When the following procedure is being
used:
funcproto(const cpumask_t *mask, ...)
{
cpumask_t temp;
cpus_and(temp, mask, cpu_online_map);
for_each_cpu_mask(c
1) The #ifdef CONFIG_HOTPLUG_CPU seems unnecessary these days.
2) The loop can simply skip over offline cpus, rather than creating a tmp mask.
3) set_mask is set to either a single cpu or all online cpus in a policy.
Since it's just used for set_cpus_allowed(), any offline cpus in a policy
do
1 - 100 of 117 matches
Mail list logo
