Acked-by: Ian Munsie
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
If we open a context but do not start it (either because we do not attempt
to start it, or because it fails to start for some reason), we are left
with a context in state OPENED. Previously, cxl_release_context() only
allowed releasing contexts in state CLOSED, so attempting to release an
OPENED co
On Fri, 2015-14-08 at 02:55:14 UTC, Sam bobroff wrote:
> The paca display is already more than 24 lines, which can be problematic
> if you have an old school 80x24 terminal, or more likely you are on a
> virtual terminal which does not scroll for whatever reason.
>
> This adds an optional letter t
Hi Andrew,
On Tue, 18 Aug 2015 07:53:15 +0200 Christoph Hellwig wrote:
>
> On Mon, Aug 17, 2015 at 10:45:52PM -0700, Andrew Morton wrote:
> > > >
> > > > I'll merge these 5 patches for 4.3. That means I'll release them into
> > > > linux-next after 4.2 is released.
> > >
> > > So you only add
On Mon, Aug 17, 2015 at 10:45:52PM -0700, Andrew Morton wrote:
> > >
> > > I'll merge these 5 patches for 4.3. That means I'll release them into
> > > linux-next after 4.2 is released.
> >
> > So you only add for-4.3 code to -next after 4.2 is odd? Isn't thast the
> > wrong way around?
>
> Lin
On Tue, 18 Aug 2015 07:38:25 +0200 Christoph Hellwig wrote:
> On Mon, Aug 17, 2015 at 02:24:29PM -0700, Andrew Morton wrote:
> > 110254 bytes saved, shrinking the kernel by a whopping 0.17%.
> > Thoughts?
>
> Sounds fine to me.
OK, I'll clean it up a bit, check that each uninlining actually ma
Andrey Ryabinin writes:
> 2015-08-17 12:50 GMT+03:00 Aneesh Kumar K.V :
>> Because of the above I concluded that we may not be able to do
>> inline instrumentation. Now if we are not doing inline instrumentation,
>> we can simplify kasan support by not creating a shadow mapping at all
>> for vmal
On Mon, Aug 17, 2015 at 02:24:29PM -0700, Andrew Morton wrote:
> 110254 bytes saved, shrinking the kernel by a whopping 0.17%.
> Thoughts?
Sounds fine to me.
>
> I'll merge these 5 patches for 4.3. That means I'll release them into
> linux-next after 4.2 is released.
So you only add for-4.3 c
Andrey Ryabinin writes:
> 2015-08-17 15:13 GMT+03:00 Andrey Ryabinin :
>>
>> Did you disable stack instrumentation (in scripts/Makefile.kasa),
>> or you version of gcc doesn't support it (e.g. like 4.9.x on x86) ?
>>
>> Because this can't work with stack instrumentation as you don't have shadow
Andrey Ryabinin writes:
> On 08/17/2015 09:36 AM, Aneesh Kumar K.V wrote:
>> We use the region with region ID 0xe as the kasan shadow region. Since
>> we use hash page table, we can't have the early zero page based shadow
>> region support. Hence we disable kasan in the early code and runtime
>>
Andrey Ryabinin writes:
> On 08/17/2015 09:36 AM, Aneesh Kumar K.V wrote:
>> We can't use generic functions like print_hex_dump to access kasan
>> shadow region. This require us to setup another kasan shadow region
>> for the address passed (kasan shadow address). Most architecture won't
>> be ab
On Mon, Aug 17, 2015 at 8:24 AM, Ran Shalit wrote:
> Hello,
>
>
> I have strange behaviour with external IRQ:
> The registration on external IRQ is successful, but on simulating
> interrupt the interrupt handler called.
> It seems that the interrupt was received according to SEPNR which
> shows th
On Tue, 2015-08-18 at 14:51 +1000, Michael Ellerman wrote:
> On Sat, 2015-18-07 at 20:08:51 UTC, Scott Wood wrote:
> > booted_from_exec is similar to __run_at_load, except that it is set for
> ^
> missing k.
>
> Also do you mind using __booted_from_kexec to keep the namin
On Sat, 2015-18-07 at 20:08:51 UTC, Scott Wood wrote:
> booted_from_exec is similar to __run_at_load, except that it is set for
^
missing k.
Also do you mind using __booted_from_kexec to keep the naming similar to the
other variables down there, and also make it clear i
Highlights include 32-bit memcpy/memset optimizations, checksum
optimizations, 85xx config fragments and updates, device tree updates,
e6500 fixes for non-SMP, and misc cleanup and minor fixes.
The following changes since commit 79cd95200035fb4b39b089dd01c13302eee6ee03:
powerpc/eeh: Dump PHB di
On Mon, 2015-08-17 at 22:30 -0500, Scott Wood wrote:
> On Tue, 2015-08-18 at 12:51 +1000, Michael Ellerman wrote:
> > On Mon, 2015-08-17 at 13:59 -0500, Scott Wood wrote:
> > > On Sat, 2015-07-18 at 14:57 -0500, Scott Wood wrote:
> > > > It needs to know this because the SMP release mechanism for F
On Tue, 2015-08-18 at 12:51 +1000, Michael Ellerman wrote:
> On Mon, 2015-08-17 at 13:59 -0500, Scott Wood wrote:
> > On Sat, 2015-07-18 at 14:57 -0500, Scott Wood wrote:
> > > It needs to know this because the SMP release mechanism for Freescale
> > > book3e is different from when booting with nor
On Tue, 2015-08-11 at 15:25 +0530, Nikunj A Dadhania wrote:
> Hi Michael,
>
> Nikunj A Dadhania writes:
> > In some situations, a NUMA guest that supports
> > ibm,dynamic-memory-reconfiguration node will end up having flat NUMA
> > distances between nodes. This is because of two problems in the
>
On Mon, 2015-08-17 at 13:59 -0500, Scott Wood wrote:
> On Sat, 2015-07-18 at 14:57 -0500, Scott Wood wrote:
> > It needs to know this because the SMP release mechanism for Freescale
> > book3e is different from when booting with normal hardware. In theory
> > we could simulate the normal spin tabl
This adds include/uapi/asm/eeh.h to kbuild so that the header
file will be exported automatically with below command. The
header file was added by commit ed3e81f ("powerpc/eeh: Move PE
state constants around")
make INSTALL_HDR_PATH=/tmp/headers \
SRCARCH=powerpc headers_install
Signed-
On Mon, 17 Aug 2015 09:06:51 +0200 Christoph Hellwig wrote:
> Since 2009 we have a nice asm-generic header implementing lots of DMA API
> functions for architectures using struct dma_map_ops, but unfortunately
> it's still missing a lot of APIs that all architectures still have to
> duplicate.
>
On Mon, 2015-08-17 at 19:16 +0800, Kevin Hao wrote:
> On Fri, Aug 14, 2015 at 09:44:28PM -0500, Scott Wood wrote:
> > I tried a couple different benchmarks and didn't find a significant
> > difference, relative to the variability of the results running on the
> > same
> > kernel. A patch that c
On Sat, 2015-08-15 at 08:44 -0700, Dan Williams wrote:
> On Sat, Aug 15, 2015 at 2:19 AM, Christoph Hellwig wrote:
> > On Thu, Aug 13, 2015 at 10:51:11AM -0600, Ross Zwisler wrote:
> >> Update the annotation for the kaddr pointer returned by direct_access()
> >> so that it is a __pmem pointer. Th
Looks fine,
Reviewed-by: Christoph Hellwig
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Sat, 2015-07-18 at 14:57 -0500, Scott Wood wrote:
> It needs to know this because the SMP release mechanism for Freescale
> book3e is different from when booting with normal hardware. In theory
> we could simulate the normal spin table mechanism, but not (easily) at
> the addresses U-Boot put i
Update the annotation for the kaddr pointer returned by direct_access()
so that it is a __pmem pointer. This is consistent with the PMEM driver
and with how this direct_access() pointer is used in the DAX code.
Signed-off-by: Ross Zwisler
---
Documentation/filesystems/Locking | 3 ++-
arch/pow
The goal of this series is to enhance the DAX I/O path so that all operations
that store data (I/O writes, zeroing blocks, punching holes, etc.) properly
synchronize the stores to media using the PMEM API. This ensures that the data
DAX is writing is durable on media before the operation completes
On 08/10/2015 10:48 AM, Ran Shalit wrote:
> Hello,
>
> MPC8349 has general IRQ numbered 0-7,
> It is required to bind these IRQs with some routine , i.e. they are
> not used with any specific driver.
>
> - Should they be configured as gpios in device tree so that we can use
> the gpio as irq in l
Le 17/08/2015 13:00, leroy christophe a écrit :
Le 17/08/2015 12:56, leroy christophe a écrit :
Le 07/08/2015 01:25, Segher Boessenkool a écrit :
On Thu, Aug 06, 2015 at 05:45:45PM -0500, Scott Wood wrote:
If this makes performance non-negligibly worse on other 32-bit
chips, and is
an im
Wang Dongsheng wrote:
Thanks Timur.
@Scott,
Could you apply this patch?
You need to ask the fbdev maintainer to apply it, because it has to go
through his tree.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/l
2015-08-17 15:13 GMT+03:00 Andrey Ryabinin :
>
> Did you disable stack instrumentation (in scripts/Makefile.kasa),
> or you version of gcc doesn't support it (e.g. like 4.9.x on x86) ?
>
> Because this can't work with stack instrumentation as you don't have shadow
> for stack in early code.
>
> Bu
On 08/17/2015 09:36 AM, Aneesh Kumar K.V wrote:
> We use the region with region ID 0xe as the kasan shadow region. Since
> we use hash page table, we can't have the early zero page based shadow
> region support. Hence we disable kasan in the early code and runtime
> enable this. We could imporve th
On 08/17/2015 09:36 AM, Aneesh Kumar K.V wrote:
> We can't use generic functions like print_hex_dump to access kasan
> shadow region. This require us to setup another kasan shadow region
> for the address passed (kasan shadow address). Most architecture won't
> be able to do that. Hence remove dump
2015-08-17 12:50 GMT+03:00 Aneesh Kumar K.V :
> Because of the above I concluded that we may not be able to do
> inline instrumentation. Now if we are not doing inline instrumentation,
> we can simplify kasan support by not creating a shadow mapping at all
> for vmalloc and vmemmap region. Hence th
On Mon, 2015-08-17 at 16:20 +0530, Aneesh Kumar K.V wrote:
> Benjamin Herrenschmidt writes:
>
> > On Mon, 2015-08-17 at 15:20 +0530, Aneesh Kumar K.V wrote:
> >
> > > For kernel linear mapping, our address space looks like
> > > 0xc000 - 0xc0003fff (64TB)
> > >
> > > We can
On Fri, Aug 14, 2015 at 07:44:23PM -0500, Scott Wood wrote:
> On Fri, 2015-08-14 at 15:13 +0800, Kevin Hao wrote:
> > On Thu, Aug 13, 2015 at 10:39:19PM -0500, Scott Wood wrote:
> > > On Thu, 2015-08-13 at 19:51 +0800, Kevin Hao wrote:
> > > > I didn't find anything unusual. But I think we do need
On Fri, Aug 14, 2015 at 09:44:28PM -0500, Scott Wood wrote:
> I tried a couple different benchmarks and didn't find a significant
> difference, relative to the variability of the results running on the same
> kernel. A patch that claims to "optimize a bit" as its main purpose ought to
> show so
Le 17/08/2015 12:56, leroy christophe a écrit :
Le 07/08/2015 01:25, Segher Boessenkool a écrit :
On Thu, Aug 06, 2015 at 05:45:45PM -0500, Scott Wood wrote:
If this makes performance non-negligibly worse on other 32-bit
chips, and is
an important improvement on 8xx, then we can use an ifde
Le 07/08/2015 01:25, Segher Boessenkool a écrit :
On Thu, Aug 06, 2015 at 05:45:45PM -0500, Scott Wood wrote:
If this makes performance non-negligibly worse on other 32-bit chips, and is
an important improvement on 8xx, then we can use an ifdef since 8xx already
requires its own kernel build.
Benjamin Herrenschmidt writes:
> On Mon, 2015-08-17 at 15:20 +0530, Aneesh Kumar K.V wrote:
>
>> For kernel linear mapping, our address space looks like
>> 0xc000 - 0xc0003fff (64TB)
>>
>> We can't have virtual address(effective address) above that range
>> in 0xc region. He
On Mon, 2015-08-17 at 15:20 +0530, Aneesh Kumar K.V wrote:
> For kernel linear mapping, our address space looks like
> 0xc000 - 0xc0003fff (64TB)
>
> We can't have virtual address(effective address) above that range
> in 0xc region. Hence in-order to shadow the linear mapping
Benjamin Herrenschmidt writes:
> On Mon, 2015-08-17 at 12:06 +0530, Aneesh Kumar K.V wrote:
>> Hi,
>>
>> This patchset implements kernel address sanitizer for ppc64.
>> Since ppc64 virtual address range is divided into different regions,
>> we can't have one contigous area for the kasan shadow r
On Fri, Aug 14, 2015 at 09:26:21PM +0100, Bjorn Helgaas wrote:
> On Fri, Aug 14, 2015 at 11:43 AM, Will Deacon wrote:
> > On Fri, Aug 14, 2015 at 05:40:51PM +0100, Bjorn Helgaas wrote:
> >> Do we need support for pci-probe-only in pci-host-generic at all?
> >> You're removing the use in amd-overdr
On Mon, 17 Aug 2015, Geert Uytterhoeven wrote:
> On Mon, Aug 17, 2015 at 10:04 AM, Finn Thain
> wrote:
> >> BTW, checkpatch reported a few newly-introduced whitespace errors in
> >> patches 03, 05, 16, 24, and 25.
> >
> > I will check again, but I'm sure those are all deliberate. I examined
>
Hi Finn,
On Mon, Aug 17, 2015 at 10:04 AM, Finn Thain wrote:
>> BTW, checkpatch reported a few newly-introduced whitespace errors in
>> patches 03, 05, 16, 24, and 25.
>
> I will check again, but I'm sure those are all deliberate. I examined all
> the "errors" and "warnings" before submitting.
>
On Sun, 16 Aug 2015, Geert Uytterhoeven wrote:
> Hi Finn,
>
> On Sat, Jul 25, 2015 at 9:45 AM, Finn Thain
> wrote:
> > The generic NVRAM module, drivers/char/generic_nvram, implements a
> > /dev/nvram misc device. It is used only by 32-bit PowerPC platforms
> > and isn't generic enough to be
On Fri, 2015-14-08 at 06:03:19 UTC, Daniel Axtens wrote:
> In the complete hotplug case, EEH PEs are supposed to be released
> and set to NULL. Normally, this is done by eeh_remove_device(),
> which is called from pcibios_release_device().
>
> However, if something is holding a kref to the device,
On Wed, 2015-05-08 at 07:08:31 UTC, "Gautham R. Shenoy" wrote:
> Section 3.7 of Version 1.2 of the Power8 Processor User's Manual
> prescribes that updates to HID0 be preceded by a SYNC instruction and
> followed by an ISYNC instruction (Page 91).
>
> Create an inline function name update_power8_h
On Fri, 2015-14-08 at 06:58:38 UTC, Vaibhav Jain wrote:
> This patch plugs the leak of irq_bitmap, allocated as part of
> initialization of cxl_context struct; during the call to
> afu_allocate_irqs. The bitmap is now release during the call to function
> afu_release_irqs.
>
> Reported-by: Matthew
On Fri, 2015-14-08 at 07:41:17 UTC, Daniel Axtens wrote:
> We're about to make these more complex, so make them functions
> first.
>
> Signed-off-by: Daniel Axtens
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/588b34be20bc3dd7441c
cheers
_
From: Jason Jin
In u-boot, when set the video as console, the name 'vga' is used
as a general name for the video device, during the fdt_fixup_stdout
process, the 'vga' name is used to search in the dtb to setup the
'linux,stdout-path' node. Though the P1022 DIU is not VGA-compatible
device, to me
The coherent DMA allocator works the same over all architectures supporting
dma_map operations.
This patch consolidates them and converges the minor differences:
- the debug_dma helpers are now called from all architectures, including
those that were previously missing them
- dma_alloc_from_
Most architectures do not support non-coherent allocations and either
define dma_{alloc,free}_noncoherent to their coherent versions or stub
them out.
Openrisc uses dma_{alloc,free}_attrs to implement them, and only Mips
implements them directly.
This patch moves the Openrisc version to common co
Almost everyone implements dma_set_mask the same way, although some time
that's hidden in ->set_dma_mask methods.
This patch consolidates those into a common implementation that either
calls ->set_dma_mask if present or otherwise uses the default
implementation. Some architectures used to only ca
Most architectures just call into ->dma_supported, but some also return 1
if the method is not present, or 0 if no dma ops are present (although
that should never happeb). Consolidate this more broad version into
common code.
Also fix h8300 which inorrectly always returned 0, which would have been
Currently there are three valid implementations of dma_mapping_error:
(1) call ->mapping_error
(2) check for a hardcoded error code
(3) always return 0
This patch provides a common implementation that calls ->mapping_error
if present, then checks for DMA_ERROR_CODE if defined or otherwise
retu
Since 2009 we have a nice asm-generic header implementing lots of DMA API
functions for architectures using struct dma_map_ops, but unfortunately
it's still missing a lot of APIs that all architectures still have to
duplicate.
This series consolidates the remaining functions, although we still
nee
57 matches
Mail list logo
