erator at
the start of the line will produce a better result. (I'd actually
suggest that in *most* cases.)
> Also, using perl, it's hard to distinguish between a
> logical "&" and the address-of "&" as well as the
> multiplication "*" and indirec
On Tue, Jan 20, 2015 at 02:02:00PM -0600, Kim Phillips wrote:
> It's possible to configure DEBUG_PAGEALLOC without PAGE_POISONING on
> ppc. Fix building the generic kernel_map_pages() implementation in
> this case:
>
> LD init/built-in.o
> mm/built-in.o: In function `free_pages_prepare':
>
t;> Huh? ppc64le or ppc64el?
>
> ppc64el. Commit message is wrong. Fixed below.
Yay! Just like every other architecture, we continue to have the deb
based distros call it one thing, and the RPM based distros call it
another. At least we'
#x27;s suggestion of falling back to the link-time
>diagnostic
>does simplify things a bit, and might be a good approach.
Agreed on both fronts; I don't think we should add any significant complexity
just to turn link errors into compile errors.
- Josh Triplett
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
g be done.
>/* Flash invalidate on 44x because we are passed kmapped addresses and
> this doesn't work for userspace pages due to the virtually tagged
> icache. Sigh. */
>iccci0, r0
>#endif
So. I think the code is already doing what you think it should?
josh
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
ppears that unlike the other plarforms handled by 3fb7933850fa
>"powerpc/4xx: Adding PCIe MSI support" this platform does not use
>address-cells=2.
Right, it's a 405, not a 440. I should have caught that in the initial
review.
>Signed-off-by: Ian Campbell
>Cc: Rupjyot
on't think anybody have tried booting a 403 in a long time. I
> would be surprised if it still worked.
I think I have one buried somewhere in my garage. I'm not digging it out.
josh
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Thu, Mar 14, 2013 at 9:47 AM, Paul Bolle wrote:
> The last user of Kconfig symbol 405GPR got removed in release v3.2.
> Remove this symbol too.
>
> Signed-off-by: Paul Bolle
Acked-by: Josh Boyer
> ---
> arch/powerpc/platforms/40x/Kconfig | 3 ---
> 1 file changed, 3
On Mon, Apr 8, 2013 at 7:27 AM, Paul Bolle wrote:
> All users of Kconfig symbol 405EP were removed in release v2.6.27.
> Remove this symbol (and a useless select of it) too.
>
> Signed-off-by: Paul Bolle
Acked-by: Josh Boyer
> ---
> 0) Tested by grepping the tree only.
>
. If you're
going to change anything, just remove the comment.
josh
> ---
> arch/powerpc/sysdev/uic.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/sysdev/uic.c b/arch/powerpc/sysdev/uic.c
> index 9203393..f95010a 100644
&
ppears that unlike the other platforms handled by 3fb7933850fa
> "powerpc/4xx: Adding PCIe MSI support" this platform does not use
> address-cells=2.
>
> Signed-off-by: Ian Campbell
> Acked-by: Josh Boyer
> Cc: Rupjyoti Sarmah
> Cc: Tirumala R Marri
> C
:5: warning: no previous prototype for
> ‘hvc_poll_init’ [-Wmissing-prototypes]
>
> Signed-off-by: Rashika Kheria
Reviewed-by: Josh Triplett
> drivers/tty/hvc/hvc_console.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/tty/hvc/hvc_conso
ignment 4K always,
or does it need to be aligned to PAGE_SIZE?
josh
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Alistair Popple has volunteered to take over maintainership of the ppc4xx
stuff upstream. Switch the MAINTAINERS entry over to him.
Signed-off-by: Josh Boyer
---
MAINTAINERS | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 1ecfde1..6d220c8
vepatch/core.c
> index bc2c85c064c1..9ad597faa57f 100644
> --- a/kernel/livepatch/core.c
> +++ b/kernel/livepatch/core.c
> @@ -298,22 +298,39 @@ unlock:
> rcu_read_unlock();
> }
>
> +/*
> + * Convert a function address into the appropriate ftrace location.
>
mary worry there is what Torsten pointed out, i.e. functions with
> either varargs or more than 8 args needing special care.
>
> Also, I'd like to have this positively reviewed by at least one more
> livepatching maintainer (I am currently looking into it myself, but my
>
are patched one
> +by one. It means that the patch must _not_ change the semantic
> +of the function.
> +
> +
> + + Kretprobes using the ftrace framework conflict with the patched
> functions.
> +
> +Both Kretprobes and LivePatches use a ftrace handler that modifies
> +the return address. The first user wins. Either the probe or the patch
> +is rejected when the handler is already in use by the other.
> +
> +
> + + Kprobes in the original function are ignored when the code is redirected
> +to the new implementation.
> +
> +There is a work in progress to add warnings about this situations.
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 4029c63d8a7d..0e7049688862 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6590,6 +6590,7 @@ F: kernel/livepatch/
> F: include/linux/livepatch.h
> F: arch/x86/include/asm/livepatch.h
> F: arch/x86/kernel/livepatch.c
> +F: Documentation/livepatch/
> F: Documentation/ABI/testing/sysfs-kernel-livepatch
> F: samples/livepatch/
> L: live-patch...@vger.kernel.org
> --
> 1.8.5.6
>
--
Josh
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
gt; > > certain consistency
> > > models...
> >
> > OK. I'm not quite sure what you mean but post them and we'll see I guess :)
>
> It's *roughly* the ppc64 equivalent of Josh Poimboeuf's Mar 25
> | [RFC PATCH v1.9 14/14] livepatch: update tas
On Fri, Apr 15, 2016 at 09:22:49PM +1000, Michael Ellerman wrote:
> On Thu, 2016-04-14 at 11:41 -0500, Josh Poimboeuf wrote:
> > On Thu, Apr 14, 2016 at 05:20:29PM +0200, Torsten Duwe wrote:
> > > On Thu, Apr 14, 2016 at 11:08:02PM +1000, Michael Ellerman wrote:
> > > &g
ework itself.
>
> Signed-off-by: Petr Mladek
My only comment is s/LivePatch/livepatch/ here and in the subject.
Otherwise it looks great to me. Really nice work!
--
Josh
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.o
fset() errors from EINVAL -> ENOENT
- change proc file permissions S_IRUGO -> USR
- use klp_for_each_object/func helpers
Jiri Slaby (1):
livepatch/s390: reorganize TIF thread flag bits
Josh Poimboeuf (16):
x86/asm/head: clean up initial stack variable
x86/asm/head: use a common fun
d cleanups:
- Remove the unused init_rsp variable declaration.
- Remove the ".word 0" statement after the initial_stack definition
because it has no apparent function.
Signed-off-by: Josh Poimboeuf
---
arch/x86/include/asm/realmode.h | 2 +-
arch/x86/include/asm/smp.h | 3 ---
There are two different pieces of code for starting a CPU: start_cpu0()
and the end of secondary_startup_64(). They're identical except for the
stack setup. Combine the common parts into a shared start_cpu()
function.
Signed-off-by: Josh Poimboeuf
---
arch/x86/kernel/head_64.S
a stack at all
Make the idle tasks conform to the new stack bottom convention by
starting their stack at a sizeof(pt_regs) offset from the end of the
stack page.
Signed-off-by: Josh Poimboeuf
---
arch/x86/kernel/head_64.S | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git
h the
intent of other users of the _stext symbol, and it also seems consistent
with what other architectures are already doing.
Signed-off-by: Josh Poimboeuf
---
arch/x86/kernel/vmlinux.lds.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/vmlinux.lds.S b/arc
-off-by: Josh Poimboeuf
---
include/linux/sched.h | 1 +
kernel/fork.c | 2 +-
kernel/sched/core.c | 4
3 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 3d31572..fb364a0 100644
--- a/include/linux/sched.h
+++ b/include
In preparation for being able to determine whether a given stack trace
is reliable, allow the stacktrace_ops functions to propagate errors to
dump_trace().
Signed-off-by: Josh Poimboeuf
---
arch/x86/include/asm/stacktrace.h | 36 +++---
arch/x86/kernel/dumpstack.c | 31
Signed-off-by: Josh Poimboeuf
---
arch/Kconfig | 6
arch/x86/Kconfig | 1 +
arch/x86/kernel/dumpstack.c | 77
arch/x86/kernel/stacktrace.c | 24 ++
include/linux/kernel.h | 1 +
include/linux/stac
Create temporary stubs for klp_patch_pending() and klp_patch_task() so
we can add TIF_PATCH_PENDING to different architectures in separate
patches without breaking build bisectability.
Signed-off-by: Josh Poimboeuf
---
include/linux/livepatch.h | 7 ++-
kernel/livepatch/core.c | 3 +++
2
flags
so that it gets automatically included in the _TIF_ALLWORK_MASK macro.
This results in exit_to_usermode_loop() and klp_patch_task() getting
called when the bit is set.
Signed-off-by: Josh Poimboeuf
---
arch/x86/entry/common.c| 9 ++---
arch/x86/include/asm/thread_info.h | 2
do_notify_resume() and klp_patch_task() get called when the bit is set.
Signed-off-by: Josh Poimboeuf
---
arch/powerpc/include/asm/thread_info.h | 4 +++-
arch/powerpc/kernel/signal.c | 4
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/thread_info.h
From: Jiri Slaby
Group the TIF thread flag bits by their inclusion in the _TIF_WORK and
_TIF_TRACE macros.
Signed-off-by: Jiri Slaby
Signed-off-by: Josh Poimboeuf
---
arch/s390/include/asm/thread_info.h | 22 ++
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git
sk
is correctly migrated in all return paths from a syscall.
Signed-off-by: Miroslav Benes
Signed-off-by: Josh Poimboeuf
---
arch/s390/include/asm/thread_info.h | 2 ++
arch/s390/kernel/entry.S| 31 ++-
2 files changed, 32 insertions(+), 1 deletion(-)
diff --
gistered with ftrace and
added to the klp_ops func stack.
Also, since these states are binary, represent them with booleans
instead of ints.
Signed-off-by: Josh Poimboeuf
---
include/linux/livepatch.h | 17 ---
kernel/livepatch/core.c | 72 +++-
klp_patch_object()'s callers already ensure that the object is loaded,
so its call to klp_is_object_loaded() is unnecessary.
This will also make it possible to move the patching code into a
separate file.
Signed-off-by: Josh Poimboeuf
---
kernel/livepatch/core.c | 3 ---
1 file chang
Move functions related to the actual patching of functions and objects
into a new patch.c file.
Signed-off-by: Josh Poimboeuf
---
kernel/livepatch/Makefile | 2 +-
kernel/livepatch/core.c | 202 +--
kernel/livepatch/patch.c | 213
For the consistency model we'll need to know the sizes of the old and
new functions to determine if they're on the stacks of any tasks.
Signed-off-by: Josh Poimboeuf
---
include/linux/livepatch.h | 3 +++
kernel/livepatch/core.c | 16
2 files changed, 19 insertion
the /sys/kernel/livepatch//enabled file while
the transition is in progress. Then all the tasks will attempt to
converge back to the original patch state.
[1] https://lkml.kernel.org/r/20141107140458.ga21...@suse.cz
Signed-off-by: Josh Poimboeuf
---
Documentation/ABI/testing/sysfs-kernel-livepa
Expose the per-task patch state value so users can determine which tasks
are holding up completion of a patching operation.
Signed-off-by: Josh Poimboeuf
---
Documentation/filesystems/proc.txt | 18 ++
fs/proc/base.c | 15 +++
2 files changed, 33
a "tlbie r4" in power4 mode, a newer CPU
>> will see it as a "tlbie r4,r0" and do the wrong thing.
>
> Yeah, it would basically maintain the existing behaviour which is wrong but a
> known quantity. I suspect no one has ever run this on Power7 or
On Wed, Oct 7, 2015 at 8:10 PM, Michael Ellerman wrote:
> On Wed, 2015-10-07 at 10:31 -0400, Josh Boyer wrote:
>> On Wed, Oct 7, 2015 at 5:13 AM, Michael Ellerman wrote:
>> > On Wed, 2015-10-07 at 02:19 -0500, Segher Boessenkool wrote:
>> >> On Wed, Oct 07, 201
27;s vulnerable.
- cpu_spec_mitigations=auto,nosmt: Enable all the default mitigations,
disabling SMT if needed by a mitigation.
Josh Poimboeuf (5):
cpu/speculation: Add 'cpu_spec_mitigations=' cmdline options
x86/speculation: Add support for 'cpu_spec_mitigations=' cmdline
Configure x86 runtime CPU speculation bug mitigations in accordance with
the 'cpu_spec_mitigations=' cmdline options. This affects Meltdown,
Spectre v2, Speculative Store Bypass, and L1TF.
The default behavior is unchanged.
Signed-off-by: Josh Poimboeuf
---
.../admin-gu
27;s vulnerable.
- cpu_spec_mitigations=auto,nosmt: Enable all the default mitigations,
disabling SMT if needed by a mitigation.
Currently, these options are placeholders which don't actually do
anything. They will be fleshed out in upcoming patches.
Signed-off-by: Josh Poimboeuf
---
.../admin-guide/k
Configure powerpc CPU runtime speculation bug mitigations in accordance
with the 'cpu_spec_mitigations=' cmdline options. This affects
Meltdown, Spectre v1, Spectre v2, and Speculative Store Bypass.
The default behavior is unchanged.
Signed-off-by: Josh Poimboeuf
---
Documentation/a
Configure s390 runtime CPU speculation bug mitigations in accordance
with the 'cpu_spec_mitigations=' cmdline options. This affects Spectre
v1 and Spectre v2.
The default behavior is unchanged.
Signed-off-by: Josh Poimboeuf
---
Documentation/admin-guide/kernel-parameters.txt | 7 +++
Configure arm64 runtime CPU speculation bug mitigations in accordance
with the 'cpu_spec_mitigations=' cmdline options. This affects
Meltdown and Speculative Store Bypass.
The default behavior is unchanged.
Signed-off-by: Josh Poimboeuf
---
Documentation/admin-guide/kernel-paramete
On Thu, Apr 04, 2019 at 11:44:11AM -0500, Josh Poimboeuf wrote:
> Keeping track of the number of mitigations for all the CPU speculation
> bugs has become overwhelming for many users. It's getting more and more
> complicated to decide which mitigations are needed for a given
On Fri, Apr 05, 2019 at 03:12:11PM +0200, Borislav Petkov wrote:
> On Thu, Apr 04, 2019 at 11:44:11AM -0500, Josh Poimboeuf wrote:
> > Keeping track of the number of mitigations for all the CPU speculation
> > bugs has become overwhelming for many users. It's getting more and
)
> > case L1TF_MITIGATION_FLUSH_NOWARN:
> > case L1TF_MITIGATION_FLUSH:
> > case L1TF_MITIGATION_FLUSH_NOSMT:
> > + case L1TF_MITIGATION_DEFAULT:
> > l1tf = VMENTER_L1D_FLUSH_COND;
> > break;
> > case L1TF_MITIGATION_FULL:
> > @@ -6686,6 +6687,7 @@ static int vmx_vm_init(struct kvm *kvm)
> > case L1TF_MITIGATION_FLUSH:
> > case L1TF_MITIGATION_FLUSH_NOSMT:
> > case L1TF_MITIGATION_FULL:
> > + case L1TF_MITIGATION_DEFAULT:
> > /*
> > * Warn upon starting the first VM in a potentially
> > * insecure environment.
>
> The L1TF bits need to be a separate patch.
I assume you mean just the part where L1TF_MITIGATION_DEFAULT is added?
--
Josh
On Fri, Apr 05, 2019 at 03:39:58PM +0100, Steven Price wrote:
> On 04/04/2019 17:44, Josh Poimboeuf wrote:
> > Configure arm64 runtime CPU speculation bug mitigations in accordance
> > with the 'cpu_spec_mitigations=' cmdline options. This affects
> > Meltdo
On Fri, Apr 05, 2019 at 08:18:09AM -0700, Randy Dunlap wrote:
> On 4/5/19 6:57 AM, Borislav Petkov wrote:
> > On Thu, Apr 04, 2019 at 11:44:12AM -0500, Josh Poimboeuf wrote:
> >> Configure x86 runtime CPU speculation bug mitigations in accordance with
> >> the
On Fri, Apr 05, 2019 at 03:44:14PM +0100, Will Deacon wrote:
> Hi Josh,
>
> On Thu, Apr 04, 2019 at 11:44:15AM -0500, Josh Poimboeuf wrote:
> > Configure arm64 runtime CPU speculation bug mitigations in accordance
> > with the 'cpu_spec_mitigations=' cmdline opti
On Fri, Apr 05, 2019 at 05:26:50PM +0200, Borislav Petkov wrote:
> On Fri, Apr 05, 2019 at 09:31:01AM -0500, Josh Poimboeuf wrote:
> > My thinking was that the individual options could be used to override
> > the global option. But maybe that's overkill? I dunno.
>
t have "cpu_" prefixes too so...
Sure, I'm ok with renaming it to that, if there are no objections.
--
Josh
On Wed, Apr 10, 2019 at 04:06:50PM +1000, Michael Ellerman wrote:
> Josh Poimboeuf writes:
> > Configure powerpc CPU runtime speculation bug mitigations in accordance
> > with the 'cpu_spec_mitigations=' cmdline options. This affects
> > Meltdown, Spectre v1, Sp
On Wed, Apr 10, 2019 at 02:10:01PM +0200, Thomas Gleixner wrote:
> On Wed, 10 Apr 2019, Michael Ellerman wrote:
> > Josh Poimboeuf writes:
> >
> > > On Fri, Apr 05, 2019 at 06:01:36PM +0200, Borislav Petkov wrote:
> > >> Thinking about this more, we can sha
gations=auto: [default] Enable all the default mitigations, but
leave SMT enabled, even if it's vulnerable.
- mitigations=auto,nosmt: Enable all the default mitigations, disabling
SMT if needed by a mitigation.
Josh Poimboeuf (5):
cpu/speculation: Add 'mitigations=' cmd
smt: Enable all the default mitigations, disabling
SMT if needed by a mitigation.
Currently, these options are placeholders which don't actually do
anything. They will be fleshed out in upcoming patches.
Signed-off-by: Josh Poimboeuf
---
.../admin-guide/kernel-paramet
Configure x86 runtime CPU speculation bug mitigations in accordance with
the 'mitigations=' cmdline option. This affects Meltdown, Spectre v2,
Speculative Store Bypass, and L1TF.
The default behavior is unchanged.
Signed-off-by: Josh Poimboeuf
---
Documentation/admin-gu
Configure powerpc CPU runtime speculation bug mitigations in accordance
with the 'mitigations=' cmdline option. This affects Meltdown, Spectre
v1, Spectre v2, and Speculative Store Bypass.
The default behavior is unchanged.
Signed-off-by: Josh Poimboeuf
---
Documentation/admin-gu
Configure s390 runtime CPU speculation bug mitigations in accordance
with the 'mitigations=' cmdline option. This affects Spectre v1 and
Spectre v2.
The default behavior is unchanged.
Signed-off-by: Josh Poimboeuf
---
Documentation/admin-guide/kernel-parameters.txt | 5 +++--
arch/s
Configure arm64 runtime CPU speculation bug mitigations in accordance
with the 'mitigations=' cmdline option. This affects Meltdown, Spectre
v2, and Speculative Store Bypass.
The default behavior is unchanged.
Signed-off-by: Josh Poimboeuf
---
NOTE: This is based on top of Jerem
Add ARM64 to the legend of architectures. It's already used in several
places in kernel-parameters.txt.
Suggested-by: Randy Dunlap
Signed-off-by: Josh Poimboeuf
---
Documentation/admin-guide/kernel-parameters.rst | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/admin-
On Tue, Apr 16, 2019 at 04:13:35PM +0200, Borislav Petkov wrote:
> On Fri, Apr 12, 2019 at 03:39:28PM -0500, Josh Poimboeuf wrote:
> > diff --git a/kernel/cpu.c b/kernel/cpu.c
> > index 38890f62f9a8..aed9083f8eac 100644
> > --- a/kernel/cpu.c
> > +++ b/kernel/cpu.c
>
On Tue, Apr 16, 2019 at 09:26:13PM +0200, Thomas Gleixner wrote:
> On Fri, 12 Apr 2019, Josh Poimboeuf wrote:
>
> > Configure arm64 runtime CPU speculation bug mitigations in accordance
> > with the 'mitigations=' cmdline option. This affects Meltdown, Spectre
&
On Fri, Oct 19, 2018 at 02:09:48PM +0200, Christoph Hellwig wrote:
> Various powerpc boards select the PCI_MSI config option without selecting
> PCI, resulting in potentially not compilable configurations if the by
> default enabled PCI option is disabled. Explicitly select PCI to ensure
> we alwa
, causing it to 'goto next' on all
future iterations?
--
Josh
eption return
>
> arch/powerpc/Kconfig | 2 +-
> arch/powerpc/kernel/entry_64.S | 7 +++
> arch/powerpc/kernel/stacktrace.c | 74 +---
> 3 files changed, 47 insertions(+), 36 deletions(-)
Reviewed-by: Josh Poimboeuf
--
Josh
On Wed, Aug 10, 2011 at 2:26 PM, Josh Boyer wrote:
> Hi Ben,
>
> Finally somewhat caught up. Now that -rc1 is out, here are some
> patches for the next merge window.
>
> josh
>
> The following changes since commit 53d1e658df6e26d62500410719aaee2b82067c03:
>
> Merg
Each time, more comments and fixes need. Par for
the course with a vendor driver, but in this case Pratyush thought the
APM guys had let it die and tried to carry it forward. I guess APM
has been sitting on it for more than 4 months now.
Anyway, hope that clears up some of the confus
---
> arch/powerpc/platforms/embedded6xx/Kconfig | 4
> arch/powerpc/platforms/prep/Kconfig | 9 -
> arch/powerpc/platforms/wsp/Kconfig | 5 -
> 6 files changed, 0 insertions(+), 53 deletions(-)
For the 40x change:
Acked-by: Josh Boyer
josh
and comments are welcome.
>From c88ae39da0c0352f411aca8d9636990a442d47da Mon Sep 17 00:00:00 2001
From: Josh Poimboeuf
Date: Wed, 2 Nov 2011 16:41:24 -0500
Subject: [PATCH] Flush relocated instructions from data cache
After updating instructions with relocated addresses, flush them from
the da
On Fri, 2011-11-04 at 14:06 +0530, Suzuki Poulose wrote:
> On 11/03/11 05:06, Josh Poimboeuf wrote:
> > On Tue, 2011-10-25 at 17:23 +0530, Suzuki K. Poulose wrote:
> > @@ -137,6 +137,9 @@ get_type:
> > lwz r0, 8(r9) /* r_addend */
> > add r0,
or flushing the entire
d-cache. relocate() could then call the platform-independent
clean_dcache().
For i-cache invalidation there's already the (incorrectly named?)
flush_instruction_cache(). It uses the appropriate platform-specific
methods (e.g. iccci for 44x) to invalidate the en
On Wed, 2011-11-09 at 12:03 +0530, Suzuki Poulose wrote:
> On Tue, 08 Nov 2011 10:19:05 -0600
> Josh Poimboeuf wrote:
>
> > On Tue, 2011-11-08 at 12:41 +0530, Suzuki Poulose wrote:
> > > What I was suggesting is, instead of flushing the cache in
> >
ASE are "safe"?
> >
> I think we could simply replace the occurrences of KERNELBASE (after the
> relocate())
> with '_stext' which would give the virtual start address of the kernel.
Yeah, that would work.
Josh
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
rough that tree.
josh
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
commit log to "clear up" instead of fix?
josh
> ---
> arch/powerpc/boot/dts/canyonlands.dts | 16 ++--
> 1 files changed, 6 insertions(+), 10 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/canyonlands.dts
> b/arch/powerpc/boot/dts/canyonlands.d
On Tue, Nov 22, 2011 at 9:15 AM, Tanmay Inamdar wrote:
>
> On Tue, Nov 22, 2011 at 5:00 PM, Josh Boyer wrote:
>>
>> On Tue, Nov 22, 2011 at 2:11 AM, Tanmay Inamdar wrote:
>> > Fixing interrupt mapping of EMAC for canyonlands
>> >
>> > Signed-off-b
On Tue, Nov 22, 2011 at 6:50 PM, Tony Breeds wrote:
> Signed-off-by: Tony Breeds
Acked-by: Josh Boyer
Ben, I don't have anything particularly urgent for 3.2 and this seems
like it is well within the 3.2 window (defconfig updates usually come
later). Want to pick this up yourself, o
On Tue, Nov 22, 2011 at 8:34 PM, Benjamin Herrenschmidt
wrote:
> On Tue, 2011-11-22 at 20:04 -0500, Josh Boyer wrote:
>> On Tue, Nov 22, 2011 at 6:50 PM, Tony Breeds wrote:
>> > Signed-off-by: Tony Breeds
>>
>> Acked-by: Josh Boyer
>>
>> Ben, I don&#
On Wed, Nov 23, 2011 at 4:44 AM, Tanmay Inamdar wrote:
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index b177caa..3f2cc36 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -978,3 +978,9 @@ config PPC_LIB_RHEAP
> bool
>
> source "arch/powerpc/kvm/Kconf
. Poulose
> Cc: Kumar Gala
> Cc: Josh Boyer
> Cc: linux ppc dev
Ben already took this one for 3.2. I should have added my Acked-by a while ago.
josh
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
p;& !(defined(CONFIG_NONSTATIC_KERNEL))
instead of this:
default "0x0200" if PPC_STD_MMU && CRASH_DUMP &&
!(RELOCATABLE || DYNAMIC_MEMSTART)
#if defined(CONFIG_CRASH_DUMP) && !(defined(CONFIG_RELOCATABLE) || \
defined(CONFIG_DYNAMIC_MEMSTART))
while still allowing for differences between RELOCATABLE and DYNAMIC_MEMSTART.
Thoughts?
josh
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
1,179c165,167
> < sm501 0001:00:06.0: SM501 At f548: Version 050100c0, 64 Mb, IRQ 19
> ---
>> sm501 0001:00:06.0: incorrect device id c105
Something is reading the device ID in the wrong endian (and probably
everything else).
josh
_
CE"},
>> +#ifdef CONFIG_BOOKE
>> {MSR_DE, "DE"},
>> +#else
>> + {MSR_SE, "SE"},
>> + {MSR_BE, "BE"},
>> +#endif
>> {MSR_IR, "IR"},
&g
On Mon, Nov 28, 2011 at 2:30 PM, Scott Wood wrote:
> On 11/28/2011 10:23 AM, Josh Boyer wrote:
>> On Mon, Nov 28, 2011 at 11:04 AM, Kumar Gala
>> wrote:
>>>
>>> Since you're fixing this can you add the following for CONFIG_BOOKE:
>>>
>>> M
On Mon, Nov 28, 2011 at 3:04 PM, Scott Wood wrote:
> On 11/28/2011 01:46 PM, Josh Boyer wrote:
>> On Mon, Nov 28, 2011 at 2:30 PM, Scott Wood wrote:
>>> On 11/28/2011 10:23 AM, Josh Boyer wrote:
>>>> On Mon, Nov 28, 2011 at 11:04 AM, Kumar Gala
>>>> w
44x_TLB_SR | PPC44x_TLB_SX | PPC44x_TLB_G),
> -#endif
That doesn't look right. The code is there doing something, why is it
just being removed? I would think the change would be to use
CONFIG_PPC_47x?
Or if the code there isn't needed any longer, the changelog should say why.
josh
_
arch/powerpc/boot/div64.S | 52
>> +
>> 1 files changed, 52 insertions(+), 0 deletions(-)
>
> Should we just link with libgcc ? :-)
Please tell me you're joking.
However, adding this code and wonderful and all but why do we need to
add it? Changelog should say why.
josh
On Mon, Nov 28, 2011 at 5:59 PM, Scott Wood wrote:
> On 11/23/2011 10:47 AM, Josh Boyer wrote:
>> On Mon, Nov 14, 2011 at 12:41 AM, Suzuki K. Poulose
>> wrote:
>>> The current implementation of CONFIG_RELOCATABLE in BookE is based
>>> on mapping the pa
is instead?
josh
The following changes since commit fa8cbaaf5a68f62db3f9a8444ecbb940b47984cb:
powerpc+sparc64/mm: Remove hack in mmap randomize layout (2011-11-28
11:42:09 +1100)
are available in the git repository at:
git://git.infradead.org/users/jwboyer/powerpc-4xx.git next
Jos
; Thanks, looks much better.
Yes, agreed. So much better I already sent it to Ben in a pull request.
josh
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Thu, Dec 1, 2011 at 12:39 AM, Benjamin Herrenschmidt
wrote:
> Hi Josh !
>
> I was helping Tony with some of the Currituck stuff when I noticed an
> oddity...
>
> So we have various "SoC" config symbols such as 440EP, 460SX, etc...
> that in turn select various bi
powerpc/configs/40x/obs600_defconfig | 83
>
> A new single-board defconfig? On arm that is a strong NACK, I'd say
> it's a bad idea on powerpc as well.
I like them. Particularly when they're the output of savedefconfig.
josh
_
aggy's last name :-)
>
> Rats!
>
> Looks like I stuffed it up once. Do you need me to respin with these
> changes or are the minor enough to be done as the patches are applied?
If the plan is to have them go through my tree, I can fix them up when
I apply them.
josh
_
On Wed, Dec 7, 2011 at 7:40 AM, Suzuki Poulose wrote:
> Josh,
>
> I rebased my patches to 3.2.0-rc3 and was able to verify it on my QEMU
> setup.
> However I am facing problems getting the my boards booted with the network
> cards
> (even without the patches). Here is what I
On Thu, Dec 8, 2011 at 8:38 PM, Stephen Rothwell wrote:
> Hi Josh,
>
> Today's linux-next merge of the 4xx tree got a conflict in
> arch/powerpc/platforms/40x/ppc40x_simple.c between commit 11eab297f57b
> ("powerpc: Add support for OpenBlockS 600") from the powerpc
On Fri, Dec 9, 2011 at 6:47 AM, Suzuki K. Poulose wrote:
>
> Signed-off-by: Suzuki K. Poulose
> Signed-off-by: Josh Poimboeuf
> Cc: Paul Mackerras
> Cc: Benjamin Herrenschmidt
> Cc: Alan Modra
> Cc: Kumar Gala
> Cc: linuxppc-dev
> ---
>
> arch/po
1 - 100 of 1742 matches
Mail list logo
