Re: [RFC PATCH v2 1/1] of: introduce event tracepoints for dynamic device_node lifecyle

On 01/24/18 22:48, Frank Rowand wrote: > On 01/21/18 06:31, Wolfram Sang wrote: >> From: Tyrel Datwyler >> >> This patch introduces event tracepoints for tracking a device_nodes >> reference cycle as well as reconfig notifications generated in response >> to

Re: [RFC PATCH v2 0/1] of: easier debugging for node life cycle issues

Hi Steve, On 01/21/18 06:31, Wolfram Sang wrote: > I got a bug report for a DT node refcounting problem in the I2C subsystem. > This > patch was a huge help in validating the bug report and the proposed solution. > So, I thought I bring it to attention again. Thanks Tyrel, for the initial >

Re: [RFC PATCH v2 1/1] of: introduce event tracepoints for dynamic device_node lifecyle

On 01/21/18 06:31, Wolfram Sang wrote: > From: Tyrel Datwyler > > This patch introduces event tracepoints for tracking a device_nodes > reference cycle as well as reconfig notifications generated in response > to node/property manipulations. > > With the recent

Re: [RFC PATCH v2 0/1] of: easier debugging for node life cycle issues

On 01/21/18 06:31, Wolfram Sang wrote: > I got a bug report for a DT node refcounting problem in the I2C subsystem. > This > patch was a huge help in validating the bug report and the proposed solution. > So, I thought I bring it to attention again. Thanks Tyrel, for the initial > work! > > Note

Re: [RFC PATCH v2 0/1] of: easier debugging for node life cycle issues

On 01/22/18 03:49, Wolfram Sang wrote: > Hi Frank, > >> Please go back and read the thread for version 1. Simply resubmitting a >> forward port is ignoring that whole conversation. >> >> There is a lot of good info in that thread. I certainly learned stuff in it. > > Yes, I did that and

Re: [PATCH] powerpc: pseries: use irq_of_parse_and_map helper

Rob Herring writes: > On Tue, Jan 23, 2018 at 12:53 AM, Michael Ellerman > wrote: >> Rob Herring writes: >> >>> Instead of calling both of_irq_parse_one and irq_create_of_mapping, call >>> of_irq_parse_and_map instead which does the same

[RFC PATCH] powerpc/powernv: Provide a way to force a core into SMT4 mode

POWER9 processors up to and including "Nimbus" v2.2 have hardware bugs relating to transactional memory and thread reconfiguration. One of these bugs has a workaround which is to get the core into SMT4 state temporarily. This workaround is only needed when running bare-metal. This patch provides

Re: [PATCH 5/5] powerpc/ftw: Document FTW API/usage

Randy Dunlap [rdun...@infradead.org] wrote: > > +struct ftw_setup_attr ftwattr; > > + > > +fd = open("/dev/ftw", O_RDWR); > > + > > +memset(, 0, sizeof(rxattr)); > > Is that supposed to be ftwattr (2x above)? Yes. I agree with your other comments as well and will send a

Re: [PATCH 5/5] powerpc/ftw: Document FTW API/usage

On 01/16/2018 06:50 PM, Sukadev Bhattiprolu wrote: > Document the usage of the VAS Fast thread-wakeup API and add an entry in > MAINTAINERS file. > > Thanks for input/comments from Benjamin Herrenschmidt, Michael Neuling, > Michael Ellerman, Robert Blackmore, Ian Munsie, Haren Myneni and Paul >

Re: Are those hacks still valid on powerpc kernel ?

On Wed, 2018-01-24 at 11:17 +0100, Christophe LEROY wrote: > Below comments are very old. > > Aren't new glibc and binutils now able to go without this ? > > Note that the code inside the #if 0 is wrong as we have no vma defined > in the function. > > Or does it just have no performance impact

[PATCH] powerpc: dts: use 'atmel' as at24 manufacturer for kmcent2

Using compatible strings without the part for at24 is now deprecated. Use a correct 'atmel,' value. Signed-off-by: Bartosz Golaszewski --- arch/powerpc/boot/dts/fsl/kmcent2.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH] powerpc: dts: use a correct at24 compatible fallback in ac14xx

Using 'at24' as fallback is now deprecated - use the full 'atmel,' string. Signed-off-by: Bartosz Golaszewski --- arch/powerpc/boot/dts/ac14xx.dts | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/arch/powerpc/boot/dts/ac14xx.dts

[PATCH] powerpc: dts: use 'atmel' as at24 anufacturer for pdm360ng

Using 'at' as the part of the compatible string is now deprecated. Use a correct string: 'atmel,'. Signed-off-by: Bartosz Golaszewski --- arch/powerpc/boot/dts/pdm360ng.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/boot/dts/pdm360ng.dts

Re: [PATCH v4 3/7] platforms/pseries: Set eeh_pe of EEH_PE_VF type

On 1/23/18 7:14 PM, Michael Ellerman wrote: > "Bryant G. Ly" writes: > >> To correctly use EEH code one has to make >> sure that the EEH_PE_VF is set for dynamic created >> VFs. Therefore this patch allocates an eeh_pe of >> eeh type EEH_PE_VF and associates PE with

Re: [PATCH] macintosh/ams-input: Use true and false for boolean values

On 24.01.2018 02:48, Gustavo A. R. Silva wrote: > Assign true or false to boolean variables instead of an integer value. > > This issue was detected with the help of Coccinelle > > Signed-off-by: Gustavo A. R. Silva Reviewed-by: Michael Hanselmann

Re: [PATCH v3 5/5] powerpc/mm: Fix growth direction for hugepages mmaps with slice

Le 24/01/2018 à 11:08, Aneesh Kumar K.V a écrit : On 01/24/2018 03:33 PM, Christophe LEROY wrote: Le 24/01/2018 à 10:51, Aneesh Kumar K.V a écrit : On 01/24/2018 03:09 PM, Christophe LEROY wrote: Le 24/01/2018 à 10:35, Aneesh Kumar K.V a écrit : Did you try with

Are those hacks still valid on powerpc kernel ?

Below comments are very old. Aren't new glibc and binutils now able to go without this ? Note that the code inside the #if 0 is wrong as we have no vma defined in the function. Or does it just have no performance impact anyway ? From /arch/powerpc/mm/mem.c: void clear_user_page(void

Re: [PATCH v3 5/5] powerpc/mm: Fix growth direction for hugepages mmaps with slice

On 01/24/2018 03:33 PM, Christophe LEROY wrote: Le 24/01/2018 à 10:51, Aneesh Kumar K.V a écrit : On 01/24/2018 03:09 PM, Christophe LEROY wrote: Le 24/01/2018 à 10:35, Aneesh Kumar K.V a écrit : Did you try with HUGETLB_MORECORE_HEAPBASE=0x1100 on PPC64 as I suggested in my

Re: [PATCH v3 5/5] powerpc/mm: Fix growth direction for hugepages mmaps with slice

Le 24/01/2018 à 10:51, Aneesh Kumar K.V a écrit : On 01/24/2018 03:09 PM, Christophe LEROY wrote: Le 24/01/2018 à 10:35, Aneesh Kumar K.V a écrit : Did you try with HUGETLB_MORECORE_HEAPBASE=0x1100 on PPC64 as I suggested in my last email on this subject (22/01/2018 9:22) ?

Re: [PATCH v3 5/5] powerpc/mm: Fix growth direction for hugepages mmaps with slice

On 01/24/2018 03:09 PM, Christophe LEROY wrote: Le 24/01/2018 à 10:35, Aneesh Kumar K.V a écrit : Did you try with HUGETLB_MORECORE_HEAPBASE=0x1100 on PPC64 as I suggested in my last email on this subject (22/01/2018 9:22) ? yes. The test ran fine for me You tried with

Re: [PATCH 25/26] KVM: PPC: Book3S PR: Support TAR handling for PR KVM HTM.

On Thu, Jan 11, 2018 at 06:11:38PM +0800, wei.guo.si...@gmail.com wrote: > From: Simon Guo > > Currently guest kernel doesn't handle TAR fac unavailable and it always > runs with TAR bit on. PR KVM will lazily enable TAR. TAR is not a > frequent-use reg and it is not

Re: [PATCH v3 5/5] powerpc/mm: Fix growth direction for hugepages mmaps with slice

Le 24/01/2018 à 10:35, Aneesh Kumar K.V a écrit : On 01/24/2018 02:57 PM, Christophe LEROY wrote: Le 24/01/2018 à 10:15, Aneesh Kumar K.V a écrit : On 01/24/2018 02:32 PM, Christophe Leroy wrote: An application running with libhugetlbfs fails to allocate additional pages to HEAP due

Re: [PATCH v3 5/5] powerpc/mm: Fix growth direction for hugepages mmaps with slice

On 01/24/2018 02:57 PM, Christophe LEROY wrote: Le 24/01/2018 à 10:15, Aneesh Kumar K.V a écrit : On 01/24/2018 02:32 PM, Christophe Leroy wrote: An application running with libhugetlbfs fails to allocate additional pages to HEAP due to the hugemap being done inconditionally as topdown

Re: [PATCH v3 5/5] powerpc/mm: Fix growth direction for hugepages mmaps with slice

Le 24/01/2018 à 10:15, Aneesh Kumar K.V a écrit : On 01/24/2018 02:32 PM, Christophe Leroy wrote: An application running with libhugetlbfs fails to allocate additional pages to HEAP due to the hugemap being done inconditionally as topdown mapping: mmap(0x1008, 1572864,

Re: [PATCH v3 5/5] powerpc/mm: Fix growth direction for hugepages mmaps with slice

On 01/24/2018 02:32 PM, Christophe Leroy wrote: An application running with libhugetlbfs fails to allocate additional pages to HEAP due to the hugemap being done inconditionally as topdown mapping: mmap(0x1008, 1572864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|0x4, -1, 0) =

[PATCH v3 5/5] powerpc/mm: Fix growth direction for hugepages mmaps with slice

An application running with libhugetlbfs fails to allocate additional pages to HEAP due to the hugemap being done inconditionally as topdown mapping: mmap(0x1008, 1572864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|0x4, -1, 0) = 0x73e8 [...] mmap(0x7400, 1048576,

[PATCH v3 4/5] powerpc/mm: Allow up to 64 low slices

While the implementation of the "slices" address space allows a significant amount of high slices, it limits the number of low slices to 16 due to the use of a single u64 low_slices_psize element in struct mm_context_t On the 8xx, the minimum slice size is the size of the area covered by a single

[PATCH v3 3/5] powerpc/32: Fix hugepage allocation on 8xx at hint address

On the 8xx, the page size is set in the PMD entry and applies to all pages of the page table pointed by the said PMD entry. When an app has some regular pages allocated (e.g. see below) and tries to mmap() a huge page at a hint address covered by the same PMD entry, the kernel accepts the hint

[PATCH v3 2/5] powerpc/mm: Enhance 'slice' for supporting PPC32

In preparation for the following patch which will fix an issue on the 8xx by re-using the 'slices', this patch enhances the 'slices' implementation to support 32 bits CPUs. On PPC32, the address space is limited to 4Gbytes, hence only the low slices will be used. This patch moves "slices"

[PATCH v3 1/5] powerpc/mm: Remove intermediate bitmap copy in 'slices'

bitmap_or() and bitmap_andnot() can work properly with dst identical to src1 or src2. There is no need of an intermediate result bitmap that is copied back to dst in a second step. Signed-off-by: Christophe Leroy --- v2: New in v2 v3: patch moved up front of the serie