>>> On 18.11.10 at 04:55, Benjamin Herrenschmidt
>>> wrote:
> On Mon, 2010-10-25 at 17:03 +1100, Stephen Rothwell wrote:
>> Hi Arnaud,
>>
>> On Sun, 24 Oct 2010 23:47:09 -0400 Arnaud Lacombe wrote:
>> >
>> > The following patch should fix this warning.
>>
>> I think the following is preferable
On Thu, 2010-11-18 at 13:32 +1100, Michael Neuling wrote:
> In:
> powerpc/mm: Fix pgtable cache cleanup with CONFIG_PPC_SUBPAGE_PROT
> commit d28513bc7f675d28b479db666d572e078ecf182d
> Author: David Gibson
>
> subpage_protection() was changed to to take an mm rather a pgdir but it
> didn't
On Wed, 2010-11-17 at 16:03 -0600, steven@teradyne.com wrote:
> My application needs a fast way to access a specific physical DDR
> memory region. The application runs on an MPC8548 PowerPC which has an
> MMU. I've tried two approaches that are typical for Linux, mmap() and
> using a kernel mod
> On Wed, 2010-11-17 at 16:03 -0600, steven@teradyne.com wrote:
> > My application needs a fast way to access a specific physical DDR
> > memory region. The application runs on an MPC8548 PowerPC which has
an
> > MMU. I've tried two approaches that are typical for Linux, mmap()
and
> > using
On Thu, Nov 18, 2010 at 11:24:22PM +1100, Michael Ellerman wrote:
> On Wed, 2010-11-17 at 16:03 -0600, steven@teradyne.com wrote:
> > My application needs a fast way to access a specific physical DDR
> > memory region. The application runs on an MPC8548 PowerPC which has an
> > MMU. I've tried
From: "Matthew L. Creech"
Date: Tue, 2 Nov 2010 18:29:08 -0400
> An upgrade from 2.6.34 to 2.6.35 caused networking to stop working on
> my MPC8313-based board. It turned out that TCP checksums were
> invalid, so I dug through the .35 changelog to try and isolate the
> reason. The change "tcp:
Thanks for the replies.
In the Linux Device Drivers book regarding mmap(), it states:
Mapping a device means associating a range of user-space addresses to
device memory.
Whenever the program reads or writes in the assigned address range, it
is actually
accessing the device. In the
On Thu, 2010-11-18 at 13:32 +1100, Michael Neuling wrote:
> In:
> powerpc/mm: Fix pgtable cache cleanup with CONFIG_PPC_SUBPAGE_PROT
> commit d28513bc7f675d28b479db666d572e078ecf182d
> Author: David Gibson
>
> subpage_protection() was changed to to take an mm rather a pgdir but it
> didn't
On Thu, Nov 18, 2010 at 12:06 PM, David Miller wrote:
>
> Can someone please follow up Matthew to get this bug resolved? It has
> been sitting around for a long time.
>
> I suspect the gianfar driver, for these chip revisions, will need to
> do a software checksum when the offset matches the crit
From: "Matthew L. Creech"
Date: Thu, 18 Nov 2010 14:31:46 -0500
> On Thu, Nov 18, 2010 at 12:06 PM, David Miller wrote:
>>
>> Can someone please follow up Matthew to get this bug resolved? It has
>> been sitting around for a long time.
>>
>> I suspect the gianfar driver, for these chip revision
On Thu, 18 Nov 2010 10:55:21 -0600
wrote:
> Thanks for the replies.
>
> In the Linux Device Drivers book regarding mmap(), it states:
>
>Mapping a device means associating a range of user-space addresses to
>device memory.
>Whenever the program reads or writes in the assigned addres
On Fri, 5 Nov 2010, Jesper Juhl wrote:
> On Tue, 2 Nov 2010, Michael Ellerman wrote:
>
> > On Mon, 2010-11-01 at 22:20 +0100, Jesper Juhl wrote:
> > > Hi Stephen,
> > >
> > > On Tue, 2 Nov 2010, Stephen Rothwell wrote:
> > >
> > > > On Mon, 1 Nov 2010 21:06:23 +0100 (CET) Jesper Juhl
> > > >
Fix head_64.S so that we can build a relocatable kernel
that isn't necessarily a crash-dump kernel
Signed-off-by: Milton Miller
Signed-off-by: Sonny Rao
---
arch/powerpc/kernel/head_64.S |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kernel/head_64.S
remove stale declaration of setup_pci_ptrs, aparently from ppc before 2.4.0
remove #ifdef around struct existance delcaration
fix spelling of linear
Signed-off-by: Milton Miller
Signed-off-by: Sonny Rao
---
arch/powerpc/include/asm/machdep.h |6 +-
1 files changed, 1 insertions(+), 5
On Thu, 2010-11-18 at 10:23 -0800, Jim Keniston wrote:
> FWIW, this failure isn't an obstacle for me. I'm in no way attached to
> my legacy configuration; pseries_defconfig is fine for me. On the other
> hand, I can continue testing fixes, and/or make my system available to
> other IBMers when I
> On Thu, 2010-11-18 at 13:32 +1100, Michael Neuling wrote:
> > In:=20
> > powerpc/mm: Fix pgtable cache cleanup with CONFIG_PPC_SUBPAGE_PROT
> > commit d28513bc7f675d28b479db666d572e078ecf182d
> > Author: David Gibson
> >=20
> > subpage_protection() was changed to to take an mm rather a pgd
On Thu, 18 Nov 2010 14:46:16 -0600
wrote:
> Hello Scott,
>
> Do you know whether this patch is necessary if I were to use alloc_bootmem
> () (to set aside a region of contiguous physical memory) instead of the
> kernel parameter "mem=256"?
It should not be needed in that case.
-Scott
> Michael Neuling (1):
> powerpc: Fix call to subpage_protection()
Well that's annoying...
Looks like the bottom of my commit got chopped as the oops message has a
"---" in it. We lost the cc: sta...@kernel.org :-(
Comparing the original post to the final commit:
http://lists.ozlabs.or
On Fri, 2010-11-19 at 07:24 +1100, Michael Neuling wrote:
> > On Thu, 2010-11-18 at 13:32 +1100, Michael Neuling wrote:
> > > In:=20
> > > powerpc/mm: Fix pgtable cache cleanup with CONFIG_PPC_SUBPAGE_PROT
> > > commit d28513bc7f675d28b479db666d572e078ecf182d
> > > Author: David Gibson
> > >
On Thu, 2010-11-18 at 20:45 +0100, Jesper Juhl wrote:
> On Fri, 5 Nov 2010, Jesper Juhl wrote:
> >
> > static int mf_src_proc_open(struct inode *inode, struct file *file)
> PING.
>
> Is this going to get merged somewhere or is there a problem?
Yes, no.
It won't get lost:
http://patchwork.ozl
On Fri, 19 Nov 2010, Michael Ellerman wrote:
> On Thu, 2010-11-18 at 20:45 +0100, Jesper Juhl wrote:
> > On Fri, 5 Nov 2010, Jesper Juhl wrote:
> > >
> > > static int mf_src_proc_open(struct inode *inode, struct file *file)
>
> > PING.
> >
> > Is this going to get merged somewhere or is there
On Fri, 2010-11-19 at 08:42 +1100, Michael Neuling wrote:
> > Michael Neuling (1):
> > powerpc: Fix call to subpage_protection()
>
> Well that's annoying...
>
> Looks like the bottom of my commit got chopped as the oops message has a
> "---" in it. We lost the cc: sta...@kernel.org :-(
>
Currently, fdt blobs are handled solely at boot time. However,
it may be useful to parse blobs into device trees after boot time. For
instance, a PCIe device may have an FPGA which includes a device
tree. This set of patches locally refactors the existing code to enable
this.
Patch 1 an
The device tree code is now in two pieces: some which can be used generically
on any platform which selects CONFIG_OF_FLATTREE, and some early which is used
at boot time on only a few architectures. This patch segregates the early
code so that only those architectures which care about it need comp
A few support device-tree related support functions that x86 didn't
have before.
Signed-off-by: Stephen Neuendorffer
Looks like just some irq related junk left!
---
arch/x86/include/asm/irq.h |2 ++
arch/x86/kernel/irq.c | 11 +++
2 files changed, 13 insertions(+), 0 de
unflatten_device_tree has two dependencies on things that happen
during boot time. Firstly, it references the initial device tree
directly. Secondly, it allocates memory using the early boot
allocator. This patch factors out these dependencies and uses
the new __unflatten_device_tree function to
In preparation for providing run-time handling of device trees, factor
out some of the basic functions so that they take an arbitrary blob,
rather than relying on the single boot-time tree.
Signed-off-by: Stephen Neuendorffer
--
V2: functions have of_fdt_* names
removed find_flat_dt_string
unflatten_dt_node is a helper function that does most of the work to
convert a device tree blob into tree of device nodes. This code
now uses a passed-in blob instead of using the single boot-time blob,
allowing it to be called in more contexts.
Signed-off-by: Stephen Neuendorffer
---
V2: don'
Testing patch to verify that the device tree code can be compiled on X86.
---
arch/x86/Kconfig |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index cea0cd9..0f2ed5b 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -59,6 +59,8 @@
Move unflatten_dt_node to be grouped with non-__init functions.
Signed-off-by: Stephen Neuendorffer
---
drivers/of/fdt.c | 218 +++---
1 files changed, 109 insertions(+), 109 deletions(-)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index a07
Hello Scott,
Do you know whether this patch is necessary if I were to use alloc_bootmem
() (to set aside a region of contiguous physical memory) instead of the
kernel parameter "mem=256"?
-Steve Lin
Scot
Since STACK_FRAME_OVERHEAD is defined in asm/ptrace.h and that
is ASSEMBER safe, we can just include that instead of going via
asm-offsets.h.
Signed-off-by: Stephen Rothwell
---
arch/powerpc/kernel/asm-offsets.c |1 -
arch/powerpc/kernel/entry_32.S |1 +
arch/powerpc/kerne
Hi Arnd,
Today's linux-next merge of the bkl-config tree got a conflict in
arch/powerpc/kernel/setup_64.c between commit
0f6b77ca12bea571e0a97b0588f62aa5f6012d61 ("powerpc: Update a BKL related
comment") from Linus' tree and commit
bb2d384ab8184eb7f7146897e47fa5b38583112c ("BKL: remove references
On Fri, 2010-11-19 at 16:31 +1100, Stephen Rothwell wrote:
> On Fri, 19 Nov 2010 09:08:02 +1100 Michael Ellerman
> wrote:
> >
> > I vote for:
> >
> > -> Exception: 401 (Instruction Access) at f7937794
>
> Or:
>
> ☛ Exception: 401 (Instruction Access) at f7937794
Let's get ser
> On Fri, 2010-11-19 at 16:31 +1100, Stephen Rothwell wrote:
> > On Fri, 19 Nov 2010 09:08:02 +1100 Michael Ellerman au> wrote:
> > >
> > > I vote for:
> > >=20
> > > -> Exception: 401 (Instruction Access) at f7937794
> >=20
> > Or:
> >=20
> > =E2=98=9B Exception: 401 (Instruction Access)
35 matches
Mail list logo
