Re: [PATCH v2 05/18] powerpc/85xx: Load all early TLB entries at once

[Scott Wood]

On Wed, 2015-10-07 at 17:00 +0300, Laurentiu Tudor wrote:
> On 10/07/2015 06:48 AM, Scott Wood wrote:
> > Use an AS=1 trampoline TLB entry to allow all normal TLB1 entries to
> > be loaded at once.  This avoids the need to keep the translation that
> > code is executing from in the same TLB entry in the final TLB
> > configuration as during early boot, which in turn is helpful for
> > relocatable kernels (e.g. kdump) where the kernel is not running from
> > what would be the first TLB entry.
> > 
> > On e6500, we limit map_mem_in_cams() to the primary hwthread of a
> > core (the boot cpu is always considered primary, as a kdump kernel
> > can be entered on any cpu).  Each TLB only needs to be set up once,
> > and when we do, we don't want another thread to be running when we
> > create a temporary trampoline TLB1 entry.
> > 
> > Signed-off-by: Scott Wood 
> > ---
> >  arch/powerpc/kernel/setup_64.c   |  8 +
> >  arch/powerpc/mm/fsl_booke_mmu.c  | 15 --
> >  arch/powerpc/mm/mmu_decl.h   |  1 +
> >  arch/powerpc/mm/tlb_nohash.c | 19 +++-
> >  arch/powerpc/mm/tlb_nohash_low.S | 63 
> > 
> >  5 files changed, 102 insertions(+), 4 deletions(-)
> > 
> > diff --git a/arch/powerpc/kernel/setup_64.c 
> > b/arch/powerpc/kernel/setup_64.c
> > index bdcbb71..505ec2c 100644
> > --- a/arch/powerpc/kernel/setup_64.c
> > +++ b/arch/powerpc/kernel/setup_64.c
> > @@ -108,6 +108,14 @@ static void setup_tlb_core_data(void)
> > for_each_possible_cpu(cpu) {
> > int first = cpu_first_thread_sibling(cpu);
> >  
> > +   /*
> > +* If we boot via kdump on a non-primary thread,
> > +* make sure we point at the thread that actually
> > +* set up this TLB.
> > +*/
> > +   if (cpu_first_thread_sibling(boot_cpuid) == first)
> > +   first = boot_cpuid;
> > +
> > paca[cpu].tcd_ptr = [first].tcd;
> >  
> > /*
> > diff --git a/arch/powerpc/mm/fsl_booke_mmu.c 
> > b/arch/powerpc/mm/fsl_booke_mmu.c
> > index 354ba3c..36d3c55 100644
> > --- a/arch/powerpc/mm/fsl_booke_mmu.c
> > +++ b/arch/powerpc/mm/fsl_booke_mmu.c
> > @@ -105,8 +105,9 @@ unsigned long p_mapped_by_tlbcam(phys_addr_t pa)
> >   * an unsigned long (for example, 32-bit implementations cannot support a
> > 4GB
> >   * size).
> >   */
> > -static void settlbcam(int index, unsigned long virt, phys_addr_t phys,
> > -   unsigned long size, unsigned long flags, unsigned int pid)
> > +static void preptlbcam(int index, unsigned long virt, phys_addr_t phys,
> > +  unsigned long size, unsigned long flags,
> > +  unsigned int pid)
> >  {
> > unsigned int tsize;
> >  
> > @@ -141,7 +142,13 @@ static void settlbcam(int index, unsigned long virt, 
> > phys_addr_t phys,
> > tlbcam_addrs[index].start = virt;
> > tlbcam_addrs[index].limit = virt + size - 1;
> > tlbcam_addrs[index].phys = phys;
> > +}
> >  
> > +void settlbcam(int index, unsigned long virt, phys_addr_t phys,
> 
> 
> Nit: shouldn't this be left static? Also, now with this bulk TLB1 loading 
> is it still used? Maybe it can be dropped.

You're right, it's an unneeded leftover.  We might as well 
s/preptlbcam/settlbcam/ as well to reduce churn.

-Scott


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 1/5] powerpc/eeh: Don't unfreeze PHB PE after reset

[Gavin Shan]

On Wed, Oct 07, 2015 at 02:12:05PM +1100, Gavin Shan wrote:
>On PowerNV platform, the PE is kept in frozen state until the PE
>reset is completed to avoid recursive EEH error caused by MMIO
>access during the period of EEH reset. The PE's frozen state is
>cleared after BARs of PCI device included in the PE are restored
>and enabled. However, we needn't clear the frozen state for PHB PE
>explicitly at this point as there is no real PE for PHB PE. As the
>PHB PE is always binding with PE#0, we actually clear PE#0, which
>is wrong. It doesn't incur any problem though.
>
>This checks if the PE is PHB PE and doesn't clear the frozen state
>if it is.
>
>Signed-off-by: Gavin Shan 

Michael, please ignore this series for now. One or two patches are
still missed. Also, this series needs respin.

Thanks,
Gavin

>---
> arch/powerpc/kernel/eeh_driver.c | 14 ++
> 1 file changed, 10 insertions(+), 4 deletions(-)
>
>diff --git a/arch/powerpc/kernel/eeh_driver.c 
>b/arch/powerpc/kernel/eeh_driver.c
>index 89eb4bc..3a626ed 100644
>--- a/arch/powerpc/kernel/eeh_driver.c
>+++ b/arch/powerpc/kernel/eeh_driver.c
>@@ -587,10 +587,16 @@ static int eeh_reset_device(struct eeh_pe *pe, struct 
>pci_bus *bus)
>   eeh_ops->configure_bridge(pe);
>   eeh_pe_restore_bars(pe);
>
>-  /* Clear frozen state */
>-  rc = eeh_clear_pe_frozen_state(pe, false);
>-  if (rc)
>-  return rc;
>+  /*
>+   * If it's PHB PE, the frozen state on all available PEs should have
>+   * been cleared by the PHB reset. Otherwise, we unfreeze the PE and its
>+   * child PEs because they might be in frozen state.
>+   */
>+  if (!(pe->type & EEH_PE_PHB)) {
>+  rc = eeh_clear_pe_frozen_state(pe, false);
>+  if (rc)
>+  return rc;
>+  }
>
>   /* Give the system 5 seconds to finish running the user-space
>* hotplug shutdown scripts, e.g. ifdown for ethernet.  Yes,
>-- 
>2.1.0
>

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Missing operand for tlbie instruction on Power7

[Josh Boyer]

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, 2015 at 05:00:49PM +1100, Michael Ellerman wrote:
>> > > It's also worth noting that the __flush_power7 uses tlbiel instead of 
>> > > tlbie.
>> >
>> > Yeah that's a good point. It's not clear if the swsusp code wants to a 
>> > local or
>> > a global invalidate.
>>
>> If I read the code right, this is called on the boot CPU when all the
>> non-boot CPUs are still (potentially) down, so if you would do a global
>> invalidate the non-boot CPUs might not even notice, so those need to do
>> a (local) invalidate after being brought up anyway?  Or they probably
>> need it before being brought down at all?  You figure it out, it makes
>> my brain hurt :-)
>
> A good rule would be that every cpu does a local invalidate before turning on
> the MMU. That would work for this case and also for kexec, kdump, junk left by
> firmare etc. But I don't think we do that consistently in a way that works for
> this code at the moment.
>
>> > As an alternative, can you try adding a .machine push / .machine "power4" /
>> > .machine pop, around the tlbie. That should tell the assembler to drop 
>> > back to
>> > power4 mode for that instruction, which should then do the right thing. 
>> > There
>> > are some examples in that file.
>>
>> That will get the assembler to not complain, but it will assemble the wrong
>> instruction: the power7 instruction has the same opcode (but different
>> semantics).  So if you assemble 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 in fact
> anything other than G5 or Book3E.

Likely not, but leaving it broken just because it is known behavior
seems pretty weird to me.  I think Fedora will look at simply
disabling hibernation on ppc64 so the file isn't built at all.  Seems
to be a safer option.

josh
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

linux-next: build failure after merge of Linus' tree

[Stephen Rothwell]

Hi Linus,

After merging Linus' tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

lib/string.c: In function 'strscpy':
lib/string.c:209:4: error: implicit declaration of function 'zero_bytemask' 
[-Werror=implicit-function-declaration]
*(unsigned long *)(dest+res) = c & zero_bytemask(data);
^

Caused by commit

  30035e45753b ("string: provide strscpy()")

but only exposed by commit

  19c22f3a29fa ("word-at-a-time.h: fix some Kbuild files")

BIG_ENDIAN powerpc doesn't have a definition for this function ...

Isn't this why we have linux-next ... to find this stuff early?  :-(

Oh, well, I have applied the following (that just copies zero_bytemask
from asm-generic.  I have done no testing beyond compiling.

From: Stephen Rothwell 
Date: Thu, 8 Oct 2015 09:29:26 +1100
Subject: [PATCH] word-at-a-time.h: powerpc: implement define zero_bytemask

Signed-off-by: Stephen Rothwell 
---
 arch/powerpc/include/asm/word-at-a-time.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/powerpc/include/asm/word-at-a-time.h 
b/arch/powerpc/include/asm/word-at-a-time.h
index 5b3a903adae6..4f9b6b93c18f 100644
--- a/arch/powerpc/include/asm/word-at-a-time.h
+++ b/arch/powerpc/include/asm/word-at-a-time.h
@@ -40,6 +40,8 @@ static inline bool has_zero(unsigned long val, unsigned long 
*data, const struct
return (val + c->high_bits) & ~rhs;
 }
 
+#define zero_bytemask(mask) (~1ul << __fls(mask))
+
 #else
 
 #ifdef CONFIG_64BIT
-- 
2.5.1

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH FIX] powerpc: discard .exit.data at runtime

[Stephen Rothwell]

.exit.text is discarded at run time and there are some references from
that to .exit.data, so we need to discard .exit.data at run time as well.

Fixes these errors:

`.exit.data' referenced in section `.exit.text' of drivers/built-in.o: defined 
in discarded section `.exit.data' of drivers/built-in.o
`.exit.data' referenced in section `.exit.text' of drivers/built-in.o: defined 
in discarded section `.exit.data' of drivers/built-in.o

Signed-off-by: Stephen Rothwell 
---
 arch/powerpc/kernel/vmlinux.lds.S | 6 ++
 1 file changed, 6 insertions(+)

I have only seen this with an allyesconfig build which fails for other
reasons.

diff --git a/arch/powerpc/kernel/vmlinux.lds.S 
b/arch/powerpc/kernel/vmlinux.lds.S
index 1db685104ffc..d41fd0af8980 100644
--- a/arch/powerpc/kernel/vmlinux.lds.S
+++ b/arch/powerpc/kernel/vmlinux.lds.S
@@ -183,6 +183,12 @@ SECTIONS
*(.rela*)
}
 #endif
+   /* .exit.data is discarded at runtime, not link time,
+* to deal with references from .exit.text
+*/
+   .exit.data : AT(ADDR(.exit.data) - LOAD_OFFSET) {
+   EXIT_DATA
+   }
 
/* freed after init ends here */
. = ALIGN(PAGE_SIZE);
-- 
2.5.3

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v3 3/3] dmaengine: mpc512x: initialize with subsys_initcall()

[Alexander Popov]

On 07.10.2015 17:17, Vinod Koul wrote:
> On Thu, Sep 24, 2015 at 08:28:57PM +0300, Alexander Popov wrote:
>> Initialize Freescale MPC512x DMA driver with subsys_initcall()
>> to allow the depending drivers to call dma_request_slave_channel()
>> during their probe.
> 
> Why can't we use defered probe ? I have been asking people to not move init
> levels and esnure we have right solutions using defered probe

Thanks, Vinod, I'll do it in v4.

Best regards,
Alexander

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: powerpc: Fix _ALIGN_* errors due to type difference.

[Aneesh Kumar K.V]

Michael Ellerman  writes:

> On Fri, 2015-02-10 at 14:33:48 UTC, "Aneesh Kumar K.V" wrote:
>> This avoid errors like
>> 
>> unsigned int usize = 1 << 30;
>> int size = 1 << 30;
>> unsigned long addr = 64UL << 30 ;
>> 
>> value = _ALIGN_DOWN(addr, usize); -> 0
>> value = _ALIGN_DOWN(addr, size);  -> 0x10
>
> Are you actually seeing that anywhere? I assume not.

I hit that in new development. So not in the current kernel.


>
>> diff --git a/arch/powerpc/boot/page.h b/arch/powerpc/boot/page.h
>> index 14eca30fef64..87c42d7d283d 100644
>> --- a/arch/powerpc/boot/page.h
>> +++ b/arch/powerpc/boot/page.h
>> @@ -22,8 +22,8 @@
>>  #define PAGE_MASK   (~(PAGE_SIZE-1))
>>  
>>  /* align addr on a size boundary - adjust address up/down if needed */
>> -#define _ALIGN_UP(addr,size)(((addr)+((size)-1))&(~((size)-1)))
>> -#define _ALIGN_DOWN(addr,size)  ((addr)&(~((size)-1)))
>> +#define _ALIGN_UP(addr, size)   
>> (((addr)+((size)-1))&(~((typeof(addr))(size)-1)))
>> +#define _ALIGN_DOWN(addr, size) ((addr)&(~((typeof(addr))(size)-1)))
>>  
>>  /* align addr on a size boundary - adjust address up if needed */
>>  #define _ALIGN(addr,size) _ALIGN_UP(addr,size)
>> diff --git a/arch/powerpc/include/asm/page.h 
>> b/arch/powerpc/include/asm/page.h
>> index 71294a6e976e..1dd69774a31c 100644
>> --- a/arch/powerpc/include/asm/page.h
>> +++ b/arch/powerpc/include/asm/page.h
>> @@ -240,8 +240,8 @@ extern long long virt_phys_offset;
>>  #endif
>>  
>>  /* align addr on a size boundary - adjust address up/down if needed */
>> -#define _ALIGN_UP(addr,size)(((addr)+((size)-1))&(~((size)-1)))
>> -#define _ALIGN_DOWN(addr,size)  ((addr)&(~((size)-1)))
>> +#define _ALIGN_UP(addr, size)   
>> (((addr)+((size)-1))&(~((typeof(addr))(size)-1)))
>> +#define _ALIGN_DOWN(addr, size) ((addr)&(~((typeof(addr))(size)-1)))
>
>
> It looks like ALIGN() in kernel.h already does this right, so can we just use
> that instead for _ALIGN_UP() at least.
>

But we still can't get rid of _ALIGN_UP, because that is used in other
parts of the kernel and if you are suggesting use

#define _ALIGN_UP __ALIGN_KERNEL, IMHO that is unnecessary indirection
for no real benefit.

-aneesh

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v2] powerpc: Fix checkstop in native_hpte_clear() with lockdep

[Cyril Bur]

native_hpte_clear() is called in real mode from two places:
- Early in boot during htab initialisation if firmware assisted dump is
  active.
- Late in the kexec path.

In both contexts there is no need to disable interrupts are they are
already disabled. Furthermore, locking around the tlbie() is only required
for pre POWER5 hardware.

On POWER5 or newer hardware concurrent tlbie()s work as expected and on pre
POWER5 hardware concurrent tlbie()s could result in deadlock. This code
would only be executed at crashdump time, during which all bets are off,
concurrent tlbie()s are unlikely and taking locks is unsafe therefore the
best course of action is to simply do nothing. Concurrent tlbie()s are not
possible in the first case as secondary CPUs have not come up yet.

Signed-off-by: Cyril Bur 
---
Tested on POWER8 system by applying this patch to the petitboot kernel,
kexecing into Linus' tree with this patch applied and from there kexecing
into Ubuntu 3.19.0-26.

v2: No code change.
Addition of comment in machdep.h and phrasing tweaks elsewhere.

 arch/powerpc/include/asm/machdep.h |  9 +++--
 arch/powerpc/mm/hash_native_64.c   | 23 +++
 2 files changed, 18 insertions(+), 14 deletions(-)

diff --git a/arch/powerpc/include/asm/machdep.h 
b/arch/powerpc/include/asm/machdep.h
index cab6753..3f191f5 100644
--- a/arch/powerpc/include/asm/machdep.h
+++ b/arch/powerpc/include/asm/machdep.h
@@ -61,8 +61,13 @@ struct machdep_calls {
   unsigned long addr,
   unsigned char *hpte_slot_array,
   int psize, int ssize, int local);
-   /* special for kexec, to be called in real mode, linear mapping is
-* destroyed as well */
+   /*
+* Special for kexec.
+* To be called in real mode with interrupts disabled. No locks are
+* taken as such, concurrent access on pre POWER5 hardware could result
+* in a deadlock.
+* The linear mapping is destroyed as well.
+*/
void(*hpte_clear_all)(void);
 
void __iomem *  (*ioremap)(phys_addr_t addr, unsigned long size,
diff --git a/arch/powerpc/mm/hash_native_64.c b/arch/powerpc/mm/hash_native_64.c
index 13befa35..c8822af 100644
--- a/arch/powerpc/mm/hash_native_64.c
+++ b/arch/powerpc/mm/hash_native_64.c
@@ -582,13 +582,21 @@ static void hpte_decode(struct hash_pte *hpte, unsigned 
long slot,
  * be when they isi), and we are the only one left.  We rely on our kernel
  * mapping being 0xC0's and the hardware ignoring those two real bits.
  *
+ * This must be called with interrupts disabled.
+ *
+ * Taking the native_tlbie_lock is unsafe here due to the possibility of
+ * lockdep being on. On pre POWER5 hardware, not taking the lock could
+ * cause deadlock. POWER5 and newer not taking the lock is fine. This only
+ * gets called during boot before secondary CPUs have come up and during
+ * crashdump and all bets are off anyway.
+ *
  * TODO: add batching support when enabled.  remember, no dynamic memory here,
  * athough there is the control page available...
  */
 static void native_hpte_clear(void)
 {
unsigned long vpn = 0;
-   unsigned long slot, slots, flags;
+   unsigned long slot, slots;
struct hash_pte *hptep = htab_address;
unsigned long hpte_v;
unsigned long pteg_count;
@@ -596,13 +604,6 @@ static void native_hpte_clear(void)
 
pteg_count = htab_hash_mask + 1;
 
-   local_irq_save(flags);
-
-   /* we take the tlbie lock and hold it.  Some hardware will
-* deadlock if we try to tlbie from two processors at once.
-*/
-   raw_spin_lock(_tlbie_lock);
-
slots = pteg_count * HPTES_PER_GROUP;
 
for (slot = 0; slot < slots; slot++, hptep++) {
@@ -614,8 +615,8 @@ static void native_hpte_clear(void)
hpte_v = be64_to_cpu(hptep->v);
 
/*
-* Call __tlbie() here rather than tlbie() since we
-* already hold the native_tlbie_lock.
+* Call __tlbie() here rather than tlbie() since we can't take 
the
+* native_tlbie_lock.
 */
if (hpte_v & HPTE_V_VALID) {
hpte_decode(hptep, slot, , , , );
@@ -625,8 +626,6 @@ static void native_hpte_clear(void)
}
 
asm volatile("eieio; tlbsync; ptesync":::"memory");
-   raw_spin_unlock(_tlbie_lock);
-   local_irq_restore(flags);
 }
 
 /*
-- 
2.6.0

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [GIT PULL 0/1] perf/urgent fix

[Michael Ellerman]

On Wed, 2015-10-07 at 18:33 +0200, Ingo Molnar wrote:
> * Arnaldo Carvalho de Melo  wrote:
> > 
> > perf/urgent fix:
> > 
> > - Fix build break on (at least) powerpc due to sample_reg_masks, not being
> >   available for linking (Sukadev Bhattiprolu)
> > 
> > Signed-off-by: Arnaldo Carvalho de Melo 
> > 
> > 
> > Sukadev Bhattiprolu (1):
> >   perf tools: Fix build break on powerpc due to sample_reg_masks
> 
> Pulled, thanks Arnaldo!

Thanks guys.

cheers


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH v3 1/2] fsl: Add binding for RCPM

[Wang Dongsheng]

> > +++ b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > @@ -0,0 +1,63 @@
> > +* Run Control and Power Management
> > +---
> > +The RCPM performs all device-level tasks associated with device run
> > +control and power management.
> > +
> > +Required properites:
> > +  - reg : Offset and length of the register set of RCPM block.
> 
> s/RCPM block/the RCPM block/
> 
> > +  - fsl,#rcpm-wakeup-cells : The number of cells in rcpm-wakeup property.
> 
> s/rcpm-wakeup-property/the rcpm-wakeup-property/
> 
> > +  - compatible : Sould contain a chip-specific RCPM block compatible
> > + string
> 
> s/Sould/Should
> 
> "Should" means it is recommended, but does not mean "must".  Is it really
> optional?
> 

Thanks for your patient explain, change to "must".

Regards,
-Dongsheng

> > +   and (if applicable) may contain a chassis-version RCPM compatible
> > +   string. Chip-specific strings are of the form "fsl,-rcpm",
> > +   such as:
> > +   * "fsl,p2041-rcpm"
> > +   * "fsl,p3041-rcpm"
> > +   * "fsl,p4080-rcpm"
> > +   * "fsl,p5020-rcpm"
> > +   * "fsl,p5040-rcpm"
> > +   * "fsl,t4240-rcpm"
> > +   * "fsl,b4420-rcpm"
> > +   * "fsl,b4860-rcpm"
> 
> 2 or 3 examples is enough.
> 
> > +   Chassis-version strings are of the form "fsl,qoriq-rcpm-",
> > +   such as:
> > +   * "fsl,qoriq-rcpm-1.0": for chassis 1.0 rcpm
> > +   * "fsl,qoriq-rcpm-2.0": for chassis 2.0 rcpm
> > +   * "fsl,qoriq-rcpm-2.1": for chassis 2.1 rcpm
> > +
> > +All references to "1.0" and "2.0" refer to the QorIQ chassis version
> > +to which the chip complies.
> > +Chassis VersionExample Chips
> > +------
> > +1.0p4080, p5020, p5040, p2041, p3041
> > +2.0t4240, b4860, b4420
> > +2.1t1040, ls1021
> 
> Not sure this binding is the place to maintain a table of chassis versions to
> SoCs.
> 
> Thanks,
> Stuart
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v2 1/8] powerpc/eeh: Don't unfreeze PHB PE after reset

[Gavin Shan]

On PowerNV platform, the PE is kept in frozen state until the PE
reset is completed to avoid recursive EEH error caused by MMIO
access during the period of EEH reset. The PE's frozen state is
cleared after BARs of PCI device included in the PE are restored
and enabled. However, we needn't clear the frozen state for PHB PE
explicitly at this point as there is no real PE for PHB PE. As the
PHB PE is always binding with PE#0, we actually clear PE#0, which
is wrong. It doesn't incur any problem though.

This checks if the PE is PHB PE and doesn't clear the frozen state
if it is.

Signed-off-by: Gavin Shan 
---
 arch/powerpc/kernel/eeh_driver.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/kernel/eeh_driver.c b/arch/powerpc/kernel/eeh_driver.c
index 89eb4bc..3a626ed 100644
--- a/arch/powerpc/kernel/eeh_driver.c
+++ b/arch/powerpc/kernel/eeh_driver.c
@@ -587,10 +587,16 @@ static int eeh_reset_device(struct eeh_pe *pe, struct 
pci_bus *bus)
eeh_ops->configure_bridge(pe);
eeh_pe_restore_bars(pe);
 
-   /* Clear frozen state */
-   rc = eeh_clear_pe_frozen_state(pe, false);
-   if (rc)
-   return rc;
+   /*
+* If it's PHB PE, the frozen state on all available PEs should have
+* been cleared by the PHB reset. Otherwise, we unfreeze the PE and its
+* child PEs because they might be in frozen state.
+*/
+   if (!(pe->type & EEH_PE_PHB)) {
+   rc = eeh_clear_pe_frozen_state(pe, false);
+   if (rc)
+   return rc;
+   }
 
/* Give the system 5 seconds to finish running the user-space
 * hotplug shutdown scripts, e.g. ifdown for ethernet.  Yes,
-- 
2.1.0

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v2 2/8] powerpc/eeh: More relexed hotplug criterion

[Gavin Shan]

Currently, we rely on the existence of struct pci_driver::err_handler
to judge if the corresponding PCI device should be unplugged during
EEH recovery (partially hotplug case). However, it's not elaborate.
some device drivers are implementing part of the EEH error handlers
to collect diag-data. That means the driver still expects a hotplug
to recover from the EEH error.

This makes the hotplug criterion more relaxed: if the device driver
doesn't provide all necessary EEH error handlers, it will experience
hotplug during EEH recovery.

Signed-off-by: Gavin Shan 
---
 arch/powerpc/kernel/eeh_driver.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/eeh_driver.c b/arch/powerpc/kernel/eeh_driver.c
index 3a626ed..32178a4 100644
--- a/arch/powerpc/kernel/eeh_driver.c
+++ b/arch/powerpc/kernel/eeh_driver.c
@@ -416,7 +416,10 @@ static void *eeh_rmv_device(void *data, void *userdata)
driver = eeh_pcid_get(dev);
if (driver) {
eeh_pcid_put(dev);
-   if (driver->err_handler)
+   if (driver->err_handler &&
+   driver->err_handler->error_detected &&
+   driver->err_handler->slot_reset &&
+   driver->err_handler->resume)
return NULL;
}
 
-- 
2.1.0

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v2 3/8] powerpc/eeh: Force reset on fenced PHB

[Gavin Shan]

On fenced PHB, the error handlers in the drivers of its subordinate
devices could return PCI_ERS_RESULT_CAN_RECOVER, indicating no reset
will be issued during the recovery. It's conflicting with the fact
that fenced PHB won't be recovered without reset.

This limits the return value from the error handlers in the drivers
of the fenced PHB's subordinate devices to PCI_ERS_RESULT_NEED_NONE
or PCI_ERS_RESULT_NEED_RESET, to ensure reset will be issued during
recovery.

Signed-off-by: Gavin Shan 
---
 arch/powerpc/kernel/eeh_driver.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/powerpc/kernel/eeh_driver.c b/arch/powerpc/kernel/eeh_driver.c
index 32178a4..80dfe89 100644
--- a/arch/powerpc/kernel/eeh_driver.c
+++ b/arch/powerpc/kernel/eeh_driver.c
@@ -664,9 +664,17 @@ static void eeh_handle_normal_event(struct eeh_pe *pe)
 * to accomplish the reset.  Each child gets a report of the
 * status ... if any child can't handle the reset, then the entire
 * slot is dlpar removed and added.
+*
+* When the PHB is fenced, we have to issue a reset to recover from
+* the error. Override the result if necessary to have partially
+* hotplug for this case.
 */
pr_info("EEH: Notify device drivers to shutdown\n");
eeh_pe_dev_traverse(pe, eeh_report_error, );
+   if ((pe->type & EEH_PE_PHB) &&
+   result != PCI_ERS_RESULT_NONE &&
+   result != PCI_ERS_RESULT_NEED_RESET)
+   result = PCI_ERS_RESULT_NEED_RESET;
 
/* Get the current PCI slot state. This can take a long time,
 * sometimes over 300 seconds for certain systems.
-- 
2.1.0

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v2 4/8] powerpc/eeh: More relxed condition for enabled IO path

[Gavin Shan]

When one of below two flags or both of them are marked in the PE
state, the PE's IO path is regarded as enabled: EEH_STATE_MMIO_ACTIVE
or EEH_STATE_MMIO_ENABLED.

Signed-off-by: Gavin Shan 
---
 arch/powerpc/kernel/eeh.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
index e968533..ddbf406 100644
--- a/arch/powerpc/kernel/eeh.c
+++ b/arch/powerpc/kernel/eeh.c
@@ -630,7 +630,7 @@ int eeh_pci_enable(struct eeh_pe *pe, int function)
 */
switch (function) {
case EEH_OPT_THAW_MMIO:
-   active_flag = EEH_STATE_MMIO_ACTIVE;
+   active_flag = EEH_STATE_MMIO_ACTIVE | EEH_STATE_MMIO_ENABLED;
break;
case EEH_OPT_THAW_DMA:
active_flag = EEH_STATE_DMA_ACTIVE;
-- 
2.1.0

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v2 6/8] powerpc/powernv: Cleanup on EEH comments

[Gavin Shan]

This applies cleanup on eeh-powernv.c, no functional changes:

   * Remove unnecessary comments and empty line.
   * Correct inaccurate comments.

Signed-off-by: Gavin Shan 
---
 arch/powerpc/platforms/powernv/eeh-powernv.c | 13 ++---
 1 file changed, 2 insertions(+), 11 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/eeh-powernv.c 
b/arch/powerpc/platforms/powernv/eeh-powernv.c
index 3bb6acb..2032936 100644
--- a/arch/powerpc/platforms/powernv/eeh-powernv.c
+++ b/arch/powerpc/platforms/powernv/eeh-powernv.c
@@ -43,17 +43,11 @@
 static bool pnv_eeh_nb_init = false;
 static int eeh_event_irq = -EINVAL;
 
-/**
- * pnv_eeh_init - EEH platform dependent initialization
- *
- * EEH platform dependent initialization on powernv
- */
 static int pnv_eeh_init(void)
 {
struct pci_controller *hose;
struct pnv_phb *phb;
 
-   /* We require OPALv3 */
if (!firmware_has_feature(FW_FEATURE_OPALv3)) {
pr_warn("%s: OPALv3 is required !\n",
__func__);
@@ -77,9 +71,9 @@ static int pnv_eeh_init(void)
/*
 * PE#0 should be regarded as valid by EEH core
 * if it's not the reserved one. Currently, we
-* have the reserved PE#0 and PE#127 for PHB3
+* have the reserved PE#255 and PE#127 for PHB3
 * and P7IOC separately. So we should regard
-* PE#0 as valid for P7IOC.
+* PE#0 as valid for PHB3 and P7IOC.
 */
if (phb->ioda.reserved_pe != 0)
eeh_add_flag(EEH_VALID_PE_ZERO);
@@ -284,7 +278,6 @@ static int pnv_eeh_post_init(void)
 #endif /* CONFIG_DEBUG_FS */
}
 
-
return ret;
 }
 
@@ -490,7 +483,6 @@ static int pnv_eeh_set_option(struct eeh_pe *pe, int option)
int opt, ret = 0;
s64 rc;
 
-   /* Sanity check on option */
switch (option) {
case EEH_OPT_DISABLE:
return -EPERM;
@@ -1065,7 +1057,6 @@ static int pnv_eeh_err_inject(struct eeh_pe *pe, int 
type, int func,
struct pnv_phb *phb = hose->private_data;
s64 rc;
 
-   /* Sanity check on error type */
if (type != OPAL_ERR_INJECT_TYPE_IOA_BUS_ERR &&
type != OPAL_ERR_INJECT_TYPE_IOA_BUS_ERR64) {
pr_warn("%s: Invalid error type %d\n",
-- 
2.1.0

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Missing operand for tlbie instruction on Power7

[Josh Boyer]

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, 2015 at 05:00:49PM +1100, Michael Ellerman wrote:
>> >> > > It's also worth noting that the __flush_power7 uses tlbiel instead of 
>> >> > > tlbie.
>> >> >
>> >> > Yeah that's a good point. It's not clear if the swsusp code wants to a 
>> >> > local or
>> >> > a global invalidate.
>> >>
>> >> If I read the code right, this is called on the boot CPU when all the
>> >> non-boot CPUs are still (potentially) down, so if you would do a global
>> >> invalidate the non-boot CPUs might not even notice, so those need to do
>> >> a (local) invalidate after being brought up anyway?  Or they probably
>> >> need it before being brought down at all?  You figure it out, it makes
>> >> my brain hurt :-)
>> >
>> > A good rule would be that every cpu does a local invalidate before turning 
>> > on
>> > the MMU. That would work for this case and also for kexec, kdump, junk 
>> > left by
>> > firmare etc. But I don't think we do that consistently in a way that works 
>> > for
>> > this code at the moment.
>> >
>> >> > As an alternative, can you try adding a .machine push / .machine 
>> >> > "power4" /
>> >> > .machine pop, around the tlbie. That should tell the assembler to drop 
>> >> > back to
>> >> > power4 mode for that instruction, which should then do the right thing. 
>> >> > There
>> >> > are some examples in that file.
>> >>
>> >> That will get the assembler to not complain, but it will assemble the 
>> >> wrong
>> >> instruction: the power7 instruction has the same opcode (but different
>> >> semantics).  So if you assemble 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 in fact
>> > anything other than G5 or Book3E.
>>
>> Likely not, but leaving it broken just because it is known behavior
>> seems pretty weird to me.
>
> In a universe where I have infinite time to fix random things we would
> obviously do a proper fix :)
>
>> I think Fedora will look at simply disabling hibernation on ppc64 so the file
>> isn't built at all.  Seems to be a safer option.
>
> It's safer for sure. Though you might have some G5 users who are using it and
> notice it being disabled.

The 5 of them will notice it being disabled and then they'll realize
they either get a working kernel minus hibernation, or they get no
kernel at all because it doesn't compile.

josh
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v2 7/8] powerpc/powernv: Remove pnv_eeh_cap_start()

[Gavin Shan]

This moves the logic of pnv_eeh_cap_start() to pnv_eeh_find_cap()
as the function is only called by pnv_eeh_find_cap(). The logic
of both functions are pretty simple. No need to have separate
functions.

Signed-off-by: Gavin Shan 
---
 arch/powerpc/platforms/powernv/eeh-powernv.c | 19 +--
 1 file changed, 5 insertions(+), 14 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/eeh-powernv.c 
b/arch/powerpc/platforms/powernv/eeh-powernv.c
index 2032936..2b5c70b 100644
--- a/arch/powerpc/platforms/powernv/eeh-powernv.c
+++ b/arch/powerpc/platforms/powernv/eeh-powernv.c
@@ -281,29 +281,20 @@ static int pnv_eeh_post_init(void)
return ret;
 }
 
-static int pnv_eeh_cap_start(struct pci_dn *pdn)
+static int pnv_eeh_find_cap(struct pci_dn *pdn, int cap)
 {
-   u32 status;
+   int pos = PCI_CAPABILITY_LIST;
+   int cnt = 48;   /* Maximal number of capabilities */
+   u32 status, id;
 
if (!pdn)
return 0;
 
+   /* Check if the device supports capabilities */
pnv_pci_cfg_read(pdn, PCI_STATUS, 2, );
if (!(status & PCI_STATUS_CAP_LIST))
return 0;
 
-   return PCI_CAPABILITY_LIST;
-}
-
-static int pnv_eeh_find_cap(struct pci_dn *pdn, int cap)
-{
-   int pos = pnv_eeh_cap_start(pdn);
-   int cnt = 48;   /* Maximal number of capabilities */
-   u32 id;
-
-   if (!pos)
-   return 0;
-
while (cnt--) {
pnv_pci_cfg_read(pdn, pos, 1, );
if (pos < 0x40)
-- 
2.1.0

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v2 8/8] powerpc/powernv: Simplify pnv_eeh_set_option()

[Gavin Shan]

This simplifies pnv_eeh_set_option() to avoid unnecessary nested
if statements, to improve readability. No functional changes.

Signed-off-by: Gavin Shan 
---
 arch/powerpc/platforms/powernv/eeh-powernv.c | 51 ++--
 1 file changed, 25 insertions(+), 26 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/eeh-powernv.c 
b/arch/powerpc/platforms/powernv/eeh-powernv.c
index 2b5c70b..d62007f 100644
--- a/arch/powerpc/platforms/powernv/eeh-powernv.c
+++ b/arch/powerpc/platforms/powernv/eeh-powernv.c
@@ -471,7 +471,7 @@ static int pnv_eeh_set_option(struct eeh_pe *pe, int option)
struct pci_controller *hose = pe->phb;
struct pnv_phb *phb = hose->private_data;
bool freeze_pe = false;
-   int opt, ret = 0;
+   int opt;
s64 rc;
 
switch (option) {
@@ -494,38 +494,37 @@ static int pnv_eeh_set_option(struct eeh_pe *pe, int 
option)
return -EINVAL;
}
 
-   /* If PHB supports compound PE, to handle it */
+   /* Freeze master and slave PEs if PHB supports compound PEs */
if (freeze_pe) {
if (phb->freeze_pe) {
phb->freeze_pe(phb, pe->addr);
-   } else {
-   rc = opal_pci_eeh_freeze_set(phb->opal_id,
-pe->addr, opt);
-   if (rc != OPAL_SUCCESS) {
-   pr_warn("%s: Failure %lld freezing "
-   "PHB#%x-PE#%x\n",
-   __func__, rc,
-   phb->hose->global_number, pe->addr);
-   ret = -EIO;
-   }
+   return 0;
}
-   } else {
-   if (phb->unfreeze_pe) {
-   ret = phb->unfreeze_pe(phb, pe->addr, opt);
-   } else {
-   rc = opal_pci_eeh_freeze_clear(phb->opal_id,
-  pe->addr, opt);
-   if (rc != OPAL_SUCCESS) {
-   pr_warn("%s: Failure %lld enable %d "
-   "for PHB#%x-PE#%x\n",
-   __func__, rc, option,
-   phb->hose->global_number, pe->addr);
-   ret = -EIO;
-   }
+
+   rc = opal_pci_eeh_freeze_set(phb->opal_id, pe->addr, opt);
+   if (rc != OPAL_SUCCESS) {
+   pr_warn("%s: Failure %lld freezing PHB#%x-PE#%x\n",
+   __func__, rc, phb->hose->global_number,
+   pe->addr);
+   return -EIO;
}
+
+   return 0;
}
 
-   return ret;
+   /* Unfreeze master and slave PEs if PHB supports */
+   if (phb->unfreeze_pe)
+   return phb->unfreeze_pe(phb, pe->addr, opt);
+
+   rc = opal_pci_eeh_freeze_clear(phb->opal_id, pe->addr, opt);
+   if (rc != OPAL_SUCCESS) {
+   pr_warn("%s: Failure %lld enable %d for PHB#%x-PE#%x\n",
+   __func__, rc, option, phb->hose->global_number,
+   pe->addr);
+   return -EIO;
+   }
+
+   return 0;
 }
 
 /**
-- 
2.1.0

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v2 0/8] EEH Improvement and Cleanup

[Gavin Shan]

The PATCH[1] of this series skips unfreezing PHB PE after reset during
recovery because that's unnecessary. PATCH[2] makes the hotplug criterion
more realistic by validating all required error handlers. PATCH[3] fixes
the issue that reset isn't issued when the error handler (error_detected())
of device driver doesn't expect reset during recovery, leading to the error
can't be recovered. PATCH[4] fixes the issue of enabling IO path that has
been enabled on pSeries platform. PATCH[5-8] cleans up eeh_pseries.c and
eeh-powernv.c without introducing logical changes.

Gavin Shan (8):
  powerpc/eeh: Don't unfreeze PHB PE after reset
  powerpc/eeh: More relexed hotplug criterion
  powerpc/eeh: Force reset on fenced PHB
  powerpc/eeh: More relxed condition for enabled IO path
  powerpc/pseries: Cleanup on pseries_eeh_get_state()
  powerpc/powernv: Cleanup on EEH comments
  powerpc/powernv: Remove pnv_eeh_cap_start()
  powerpc/powernv: Simplify pnv_eeh_set_option()

 arch/powerpc/kernel/eeh.c|  2 +-
 arch/powerpc/kernel/eeh_driver.c | 27 +++--
 arch/powerpc/platforms/powernv/eeh-powernv.c | 83 +++-
 arch/powerpc/platforms/pseries/eeh_pseries.c | 60 +---
 4 files changed, 81 insertions(+), 91 deletions(-)

-- 
2.1.0

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 8/8] powerpc/powernv: Simplify pnv_eeh_set_option()

[Andrew Donnellan]

On 08/10/15 14:58, Gavin Shan wrote:

This simplifies pnv_eeh_set_option() to avoid unnecessary nested
if statements, to improve readability. No functional changes.

Signed-off-by: Gavin Shan 


Reviewed-by: Andrew Donnellan 

--
Andrew Donnellan  Software Engineer, OzLabs
andrew.donnel...@au1.ibm.com  Australia Development Lab, Canberra
+61 2 6201 8874 (work)IBM Australia Limited

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [kbuild-all] [PATCH 4/5 v2] pseries/iommu: implement DDW-aware dma_get_page_shift

[Michael Ellerman]

On Wed, 2015-10-07 at 21:56 +0800, Fengguang Wu wrote:
> On Tue, Oct 06, 2015 at 02:39:06PM +1100, Michael Ellerman wrote:
> > On Sat, 2015-10-03 at 04:33 +0800, kbuild test robot wrote:
> > > Hi Nishanth,
> > > 
> > > [auto build test results on v4.3-rc3 -- if it's inappropriate base, 
> > > please ignore]
> > > 
> > > config: powerpc-defconfig (attached as .config)
> > > reproduce:
> > > wget 
> > > https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
> > >  -O ~/bin/make.cross
> > > chmod +x ~/bin/make.cross
> > > # save the attached .config to linux build tree
> > > make.cross ARCH=powerpc 
> > > 
> > > All error/warnings (new ones prefixed by >>):
> > > 
> > >arch/powerpc/platforms/pseries/iommu.c: In function 
> > > 'iommu_init_early_pSeries':
> > > >> arch/powerpc/platforms/pseries/iommu.c:1433:9: error: 'struct 
> > > >> machdep_calls' has no member named 'dma_get_page_shift'
> > >   ppc_md.dma_get_page_shift = dma_get_page_shift_pSeriesLP;
> > 
> > It was added in patch 3/5, so I think this error is bogus. Unless there's a
> > typo I'm missing?
> 
> Yes sorry, the patchset was not detected correctly in your case,
> ending up the patches being tested as individual ones.
> 
> I'll fixup the robot.

Thanks.

How did the robot decide to build this series in the first place? Does it build
everything sent to one of the lists on CC?

cheers


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v3 0/2] powerpc/xmon: Paged output for paca display

[Sam Bobroff]

Changes v2 -> v3:

Moved the pagination implementation from xmon.c to nonstdio.c where it's much
easier to do and the code is significantly simplified.

As it's now trivial to do, add the capability to truncate the output or to stop
pagination and dump the rest of the output.

Changed function naming scheme to read more easily (e.g.
xmon_start_pagination()).


Changes v1 -> v2:

* Removed pagination parameters from commands, replaced with new command to set
  page size. This works better for multiple commands and produces simpler code.
* Switched from encoding the page position in the command buffer to using some
  globals. Saves some memory and is less invasive to the command code.
* Added a patch to paginate the kernel log buffer display.


Sam Bobroff (2):
  powerpc/xmon: Paged output for paca display
  powerpc/xmon: Paginate kernel log buffer display

 arch/powerpc/xmon/nonstdio.c | 57 ++--
 arch/powerpc/xmon/nonstdio.h |  3 +++
 arch/powerpc/xmon/xmon.c | 18 ++
 3 files changed, 76 insertions(+), 2 deletions(-)

-- 
2.1.4

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v3 2/2] powerpc/xmon: Paginate kernel log buffer display

[Sam Bobroff]

The kernel log buffer is often much longer than the size of a terminal
so paginate it's output.

Signed-off-by: Sam Bobroff 
---
 arch/powerpc/xmon/xmon.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index cc070c3..8ba8ea7 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -242,9 +242,7 @@ Commands:\n\
 "  u   dump TLB\n"
 #endif
 "  ?   help\n"
-#ifdef CONFIG_PPC64
-"  .#  limit output to # lines per page (dump paca only)\n"
-#endif
+"  .#  limit output to # lines per page (for dp#, dpa, dl)\n"
 "  zr  reboot\n\
   zh   halt\n"
 ;
@@ -2333,10 +2331,12 @@ dump_log_buf(void)
sync();
 
kmsg_dump_rewind_nolock();
+   xmon_start_pagination();
while (kmsg_dump_get_line_nolock(, false, buf, sizeof(buf), 
)) {
buf[len] = '\0';
printf("%s", buf);
}
+   xmon_end_pagination();
 
sync();
/* wait a little while to see if we get a machine check */
-- 
2.1.4

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 22/25] powerpc32: move xxxxx_dcache_range() functions inline

[Christophe Leroy]

Le 29/09/2015 02:29, Scott Wood a écrit :

On Tue, Sep 22, 2015 at 06:51:13PM +0200, Christophe Leroy wrote:

flush/clean/invalidate _dcache_range() functions are all very
similar and are quite short. They are mainly used in __dma_sync()
perf_event locate them in the top 3 consumming functions during
heavy ethernet activity

They are good candidate for inlining, as __dma_sync() does
almost nothing but calling them

Signed-off-by: Christophe Leroy 
---
New in v2

  arch/powerpc/include/asm/cacheflush.h | 55 +++--
  arch/powerpc/kernel/misc_32.S | 65 ---
  arch/powerpc/kernel/ppc_ksyms.c   |  2 ++
  3 files changed, 54 insertions(+), 68 deletions(-)

diff --git a/arch/powerpc/include/asm/cacheflush.h 
b/arch/powerpc/include/asm/cacheflush.h
index 6229e6b..6169604 100644
--- a/arch/powerpc/include/asm/cacheflush.h
+++ b/arch/powerpc/include/asm/cacheflush.h
@@ -47,12 +47,61 @@ static inline void __flush_dcache_icache_phys(unsigned long 
physaddr)
  }
  #endif
  
-extern void flush_dcache_range(unsigned long start, unsigned long stop);

  #ifdef CONFIG_PPC32
-extern void clean_dcache_range(unsigned long start, unsigned long stop);
-extern void invalidate_dcache_range(unsigned long start, unsigned long stop);
+/*
+ * Write any modified data cache blocks out to memory and invalidate them.
+ * Does not invalidate the corresponding instruction cache blocks.
+ */
+static inline void flush_dcache_range(unsigned long start, unsigned long stop)
+{
+   void *addr = (void *)(start & ~(L1_CACHE_BYTES - 1));
+   unsigned int size = stop - (unsigned long)addr + (L1_CACHE_BYTES - 1);
+   unsigned int i;
+
+   for (i = 0; i < size >> L1_CACHE_SHIFT; i++, addr += L1_CACHE_BYTES)
+   dcbf(addr);
+   if (i)
+   mb();   /* sync */
+}

I know this is 32-bit-specific code, but it's still bad practice to use
"unsigned int" for addresses or sizes thereof.


Ok, I can fix size, but what about start and stop ? If I change that, it 
means I also have to fix all caller. Do you expect me to do that ?


And it is very unlykely, but what if for some reason someone wants to 
invalidate the entire user address space which is 3Gbytes size ? A 
signed size would be negative here.


Christophe
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2] barriers: introduce smp_mb__release_acquire and update documentation

[Michael Ellerman]

On Wed, 2015-10-07 at 08:25 -0700, Paul E. McKenney wrote:
> On Wed, Oct 07, 2015 at 02:23:17PM +0100, Will Deacon wrote:
> > Hi Peter,
> > 
> > Thanks for the headache ;)
> > 
> > On Wed, Oct 07, 2015 at 01:19:15PM +0200, Peter Zijlstra wrote:
> > > On Wed, Oct 07, 2015 at 11:59:28AM +0100, Will Deacon wrote:
> > > > As much as we'd like to live in a world where RELEASE -> ACQUIRE is
> > > > always cheaply ordered and can be used to construct UNLOCK -> LOCK
> > > > definitions with similar guarantees, the grim reality is that this isn't
> > > > even possible on x86 (thanks to Paul for bringing us crashing down to
> > > > Earth).
> > > > 
> > > > This patch handles the issue by introducing a new barrier macro,
> > > > smp_mb__release_acquire, that can be placed between a RELEASE and a
> > > > subsequent ACQUIRE operation in order to upgrade them to a full memory
> > > > barrier. At the moment, it doesn't have any users, so its existence
> > > > serves mainly as a documentation aid.
> > > 
> > > Does we want to go revert 12d560f4ea87 ("rcu,locking: Privatize
> > > smp_mb__after_unlock_lock()") for that same reason?
> > 
> > I don't think we want a straight revert. smp_mb__after_unlock_lock could
> > largely die if PPC strengthened its locks, whereas smp_mb__release_acquire
> > is needed by quite a few architectures.
> 
> Currently, we do need smp_mb__after_unlock_lock() to be after the
> acquisition on PPC -- putting it between the unlock and the lock
> of course doesn't cut it for the cross-thread unlock/lock case.
> 
> I am with Peter -- we do need the benchmark results for PPC.

Urgh, sorry guys. I have been slowly doing some benchmarks, but time is not
plentiful at the moment.

If we do a straight lwsync -> sync conversion for unlock it looks like that
will cost us ~4.2% on Anton's standard context switch benchmark.

So that's not all that nice. But we also don't want to be the only arch that
has the weird lock semantics and has to find all the bugs.

cheers


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [kbuild-all] [PATCH 4/5 v2] pseries/iommu: implement DDW-aware dma_get_page_shift

[Michael Ellerman]

On Thu, 2015-10-08 at 09:16 +0800, Fengguang Wu wrote:
> On Thu, Oct 08, 2015 at 09:06:03AM +0800, Fengguang Wu wrote:
> > On Thu, Oct 08, 2015 at 11:11:59AM +1100, Michael Ellerman wrote:
> > > On Wed, 2015-10-07 at 21:56 +0800, Fengguang Wu wrote:
> > > > On Tue, Oct 06, 2015 at 02:39:06PM +1100, Michael Ellerman wrote:
> > > > > On Sat, 2015-10-03 at 04:33 +0800, kbuild test robot wrote:
> > > > > > Hi Nishanth,
> > > > > > 
> > > > > > [auto build test results on v4.3-rc3 -- if it's inappropriate base, 
> > > > > > please ignore]
> > > > > > 
> > > > > > config: powerpc-defconfig (attached as .config)
> > > > > > reproduce:
> > > > > > wget 
> > > > > > https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
> > > > > >  -O ~/bin/make.cross
> > > > > > chmod +x ~/bin/make.cross
> > > > > > # save the attached .config to linux build tree
> > > > > > make.cross ARCH=powerpc 
> > > > > > 
> > > > > > All error/warnings (new ones prefixed by >>):
> > > > > > 
> > > > > >arch/powerpc/platforms/pseries/iommu.c: In function 
> > > > > > 'iommu_init_early_pSeries':
> > > > > > >> arch/powerpc/platforms/pseries/iommu.c:1433:9: error: 'struct 
> > > > > > >> machdep_calls' has no member named 'dma_get_page_shift'
> > > > > >   ppc_md.dma_get_page_shift = dma_get_page_shift_pSeriesLP;
> > > > > 
> > > > > It was added in patch 3/5, so I think this error is bogus. Unless 
> > > > > there's a
> > > > > typo I'm missing?
> > > > 
> > > > Yes sorry, the patchset was not detected correctly in your case,
> > > > ending up the patches being tested as individual ones.
> > > > 
> > > > I'll fixup the robot.
> > > 
> > > Thanks.
> > > 
> > > How did the robot decide to build this series in the first place? Does it 
> > > build
> > > everything sent to one of the lists on CC?
> > 
> > Yes, currently the following mailing lists are subscribed.  Patches
> > sent to them will be tested if they can be git-am to RC or linux-next
> > kernels:
> > 
> > kvm
> > linux-acpi
> > linux-bluetooth
> > linux-btrfs
> > linux-embedded
> > linux-ext4
> > linux-fsdevel
> > linux-media
> > linux-mmc
> > linux-nfs
> > linux-omap
> > linux-pci
> > linux-pm
> > linux-raid
> > linux-rdma
> > linux-scsi
> > linux-usb
> > linux-wireless
> > netdev
> > netfilter-devel
> > linux-mm
> > driverdev-devel
> > intel-gfx
> 
> And of course linux-kernel. More lists could be added in future.

So do you mind adding linuxppc-dev@lists.ozlabs.org ? :)

It's pretty low traffic compared to lkml.

cheers


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 1/5] powerpc/eeh: Don't unfreeze PHB PE after reset

[Gavin Shan]

On Thu, Oct 08, 2015 at 10:20:14AM +1100, Gavin Shan wrote:
>On Wed, Oct 07, 2015 at 02:12:05PM +1100, Gavin Shan wrote:
>>On PowerNV platform, the PE is kept in frozen state until the PE
>>reset is completed to avoid recursive EEH error caused by MMIO
>>access during the period of EEH reset. The PE's frozen state is
>>cleared after BARs of PCI device included in the PE are restored
>>and enabled. However, we needn't clear the frozen state for PHB PE
>>explicitly at this point as there is no real PE for PHB PE. As the
>>PHB PE is always binding with PE#0, we actually clear PE#0, which
>>is wrong. It doesn't incur any problem though.
>>
>>This checks if the PE is PHB PE and doesn't clear the frozen state
>>if it is.
>>
>>Signed-off-by: Gavin Shan 
>
>Michael, please ignore this series for now. One or two patches are
>still missed. Also, this series needs respin.
>

v2 was just sent out. Please look at v2 instead of this one.

Thanks,
Gavin

>>---
>> arch/powerpc/kernel/eeh_driver.c | 14 ++
>> 1 file changed, 10 insertions(+), 4 deletions(-)
>>
>>diff --git a/arch/powerpc/kernel/eeh_driver.c 
>>b/arch/powerpc/kernel/eeh_driver.c
>>index 89eb4bc..3a626ed 100644
>>--- a/arch/powerpc/kernel/eeh_driver.c
>>+++ b/arch/powerpc/kernel/eeh_driver.c
>>@@ -587,10 +587,16 @@ static int eeh_reset_device(struct eeh_pe *pe, struct 
>>pci_bus *bus)
>>  eeh_ops->configure_bridge(pe);
>>  eeh_pe_restore_bars(pe);
>>
>>- /* Clear frozen state */
>>- rc = eeh_clear_pe_frozen_state(pe, false);
>>- if (rc)
>>- return rc;
>>+ /*
>>+  * If it's PHB PE, the frozen state on all available PEs should have
>>+  * been cleared by the PHB reset. Otherwise, we unfreeze the PE and its
>>+  * child PEs because they might be in frozen state.
>>+  */
>>+ if (!(pe->type & EEH_PE_PHB)) {
>>+ rc = eeh_clear_pe_frozen_state(pe, false);
>>+ if (rc)
>>+ return rc;
>>+ }
>>
>>  /* Give the system 5 seconds to finish running the user-space
>>   * hotplug shutdown scripts, e.g. ifdown for ethernet.  Yes,
>>-- 
>>2.1.0
>>

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [v2,1/2] powerpc/xmon: Paged output for paca display

[Sam Bobroff]

On Tue, Oct 06, 2015 at 10:05:38PM +1100, Michael Ellerman wrote:
> On Fri, 2015-21-08 at 04:24:27 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 patch adds a new command ".", which takes a single (hex) numeric
> > argument: lines per page. It will cause the output of "dp" and "dpa"
> > to be broken into pages, if necessary.
> > 
> > This is implemented by running over the entire output both for the
> > initial command and for each subsequent page: the visible part is
> > clipped out by checking line numbers. This is a simplistic approach
> > but minimally invasive; it is intended to be easily reusable for other
> > commands.
> > 
> > Sample output:
> > 
> > 0:mon> .10
> > 0:mon> dp1
> > paca for cpu 0x1 @ cfdc0480:
> >  possible = yes
> >  present  = yes
> >  online   = yes
> >  lock_token   = 0x8000  (0x8)
> >  paca_index   = 0x1 (0xa)
> >  kernel_toc   = 0xc0eb2400  (0x10)
> >  kernelbase   = 0xc000  (0x18)
> >  kernel_msr   = 0xb0001032  (0x20)
> >  emergency_sp = 0xc0003ffe8000  (0x28)
> >  mc_emergency_sp  = 0xc0003ffe4000  (0x2e0)
> >  in_mce   = 0x0 (0x2e8)
> >  data_offset  = 0x7f17  (0x30)
> >  hw_cpu_id= 0x8 (0x38)
> >  cpu_start= 0x1 (0x3a)
> >  kexec_state  = 0x0 (0x3b)
> > [Enter for next page]
> > 0:mon>
> >  __current= 0xc0007e696620  (0x290)
> >  kstack   = 0xc0007e6ebe30  (0x298)
> >  stab_rr  = 0xb (0x2a0)
> >  saved_r1 = 0xc0007ef37860  (0x2a8)
> >  trap_save= 0x0 (0x2b8)
> >  soft_enabled = 0x0 (0x2ba)
> >  irq_happened = 0x1 (0x2bb)
> >  io_sync  = 0x0 (0x2bc)
> >  irq_work_pending = 0x0 (0x2bd)
> >  nap_state_lost   = 0x0 (0x2be)
> > 0:mon>
> > 
> > (Based on a similar patch by Michael Ellerman 
> > "[v2] powerpc/xmon: Allow limiting the size of the paca display".
> > This patch is an alternative and cannot coexist with the original.)
> > 
> > Signed-off-by: Sam Bobroff 
> > ---
> >  arch/powerpc/xmon/xmon.c | 86 
> > +++-
> >  1 file changed, 71 insertions(+), 15 deletions(-)
> > 
> > diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
> > index e599259..9ce9e7d 100644
> > --- a/arch/powerpc/xmon/xmon.c
> > +++ b/arch/powerpc/xmon/xmon.c
> > @@ -72,6 +72,12 @@ static int xmon_gate;
> >  
> >  static unsigned long in_xmon __read_mostly = 0;
> >  
> > +#define XMON_PRINTF(...) do { if (paged_vis()) printf(__VA_ARGS__); } 
> > while (0)
> 
> Can you do this is a proper function. I know it will need to be varargs, but
> that shouldn't be too ugly.

Sure, but I think I'll re-work the core of the logic and place it directly into
nonstdio.c. That will allow me to implement it directly in xmon_write() and
there won't need to be any change here at all. It will also allow blocking
during the output which will remove the whole 'run the command several times
and print a slice of it' system.

I'll post a v3.

> 
> > +#define MAX_PAGED_SIZE 1024
> 
> Why do we need a max at all?

OK, removed.

> > +static unsigned long paged_size = 0, paged_pos, paged_cur_page;
> 
> > +#ifdef CONFIG_PPC64
> > +static unsigned long paca_cpu;
> > +#endif
> 
> That can just be static in dump_pacas() by the looks.

This won't be needed in the new version.

> >  static unsigned long adrs;
> >  static int size = 1;
> >  #define MAX_DUMP (128 * 1024)
> > @@ -242,6 +248,9 @@ Commands:\n\
> >  "  u   dump TLB\n"
> >  #endif
> >  "  ?   help\n"
> > +#ifdef CONFIG_PPC64
> > +"  .#  limit output to # lines per page (dump paca only)\n"
> > +#endif
> 
> Don't make it 64-bit only.

It's only because the paca display itself is 64 bit only.

> >  "  zr  reboot\n\
> >zh   halt\n"
> >  ;
> > @@ -833,6 +842,19 @@ static void remove_cpu_bpts(void)
> > write_ciabr(0);
> >  }
> >  
> > +static void paged_set_size(void)
> 
> "paged" isn't reading very well for me. Can we use "pagination" instead? I 
> know
> it's longer but monitors are wide these days.
> 
> Also I prefer verb first usually, so set_pagination_size() etc.

Sure thing.

> > +{
> > +   if (!scanhex(_size) || (paged_size > MAX_PAGED_SIZE)) {
> > +   printf("Invalid number of lines per page (max: %d).\n",
> > +  MAX_PAGED_SIZE);
> > +   paged_size = 0;
> > +   }
> > +}
> > +static void paged_reset(void)
> > +{
> > +   

Re: Missing operand for tlbie instruction on Power7

[Michael Ellerman]

On Wed, 2015-10-07 at 20:15 -0400, Josh Boyer wrote:
> 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, 2015 at 05:00:49PM +1100, Michael Ellerman wrote:
> >> >> > > It's also worth noting that the __flush_power7 uses tlbiel instead 
> >> >> > > of tlbie.
> >> >> >
> >> >> > Yeah that's a good point. It's not clear if the swsusp code wants to 
> >> >> > a local or
> >> >> > a global invalidate.
> >> >>
> >> >> If I read the code right, this is called on the boot CPU when all the
> >> >> non-boot CPUs are still (potentially) down, so if you would do a global
> >> >> invalidate the non-boot CPUs might not even notice, so those need to do
> >> >> a (local) invalidate after being brought up anyway?  Or they probably
> >> >> need it before being brought down at all?  You figure it out, it makes
> >> >> my brain hurt :-)
> >> >
> >> > A good rule would be that every cpu does a local invalidate before 
> >> > turning on
> >> > the MMU. That would work for this case and also for kexec, kdump, junk 
> >> > left by
> >> > firmare etc. But I don't think we do that consistently in a way that 
> >> > works for
> >> > this code at the moment.
> >> >
> >> >> > As an alternative, can you try adding a .machine push / .machine 
> >> >> > "power4" /
> >> >> > .machine pop, around the tlbie. That should tell the assembler to 
> >> >> > drop back to
> >> >> > power4 mode for that instruction, which should then do the right 
> >> >> > thing. There
> >> >> > are some examples in that file.
> >> >>
> >> >> That will get the assembler to not complain, but it will assemble the 
> >> >> wrong
> >> >> instruction: the power7 instruction has the same opcode (but different
> >> >> semantics).  So if you assemble 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 in fact
> >> > anything other than G5 or Book3E.
> >>
> >> Likely not, but leaving it broken just because it is known behavior
> >> seems pretty weird to me.
> >
> > In a universe where I have infinite time to fix random things we would
> > obviously do a proper fix :)
> >
> >> I think Fedora will look at simply disabling hibernation on ppc64 so the 
> >> file
> >> isn't built at all.  Seems to be a safer option.
> >
> > It's safer for sure. Though you might have some G5 users who are using it 
> > and
> > notice it being disabled.
> 
> The 5 of them will notice it being disabled and then they'll realize
> they either get a working kernel minus hibernation, or they get no
> kernel at all because it doesn't compile.

Sure. But if we do the machine push thing they'll get both :)

And I doubt it's 5, 2 is more likely.

cheers


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [kbuild-all] [PATCH 4/5 v2] pseries/iommu: implement DDW-aware dma_get_page_shift

[Fengguang Wu]

On Thu, Oct 08, 2015 at 09:06:03AM +0800, Fengguang Wu wrote:
> On Thu, Oct 08, 2015 at 11:11:59AM +1100, Michael Ellerman wrote:
> > On Wed, 2015-10-07 at 21:56 +0800, Fengguang Wu wrote:
> > > On Tue, Oct 06, 2015 at 02:39:06PM +1100, Michael Ellerman wrote:
> > > > On Sat, 2015-10-03 at 04:33 +0800, kbuild test robot wrote:
> > > > > Hi Nishanth,
> > > > > 
> > > > > [auto build test results on v4.3-rc3 -- if it's inappropriate base, 
> > > > > please ignore]
> > > > > 
> > > > > config: powerpc-defconfig (attached as .config)
> > > > > reproduce:
> > > > > wget 
> > > > > https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
> > > > >  -O ~/bin/make.cross
> > > > > chmod +x ~/bin/make.cross
> > > > > # save the attached .config to linux build tree
> > > > > make.cross ARCH=powerpc 
> > > > > 
> > > > > All error/warnings (new ones prefixed by >>):
> > > > > 
> > > > >arch/powerpc/platforms/pseries/iommu.c: In function 
> > > > > 'iommu_init_early_pSeries':
> > > > > >> arch/powerpc/platforms/pseries/iommu.c:1433:9: error: 'struct 
> > > > > >> machdep_calls' has no member named 'dma_get_page_shift'
> > > > >   ppc_md.dma_get_page_shift = dma_get_page_shift_pSeriesLP;
> > > > 
> > > > It was added in patch 3/5, so I think this error is bogus. Unless 
> > > > there's a
> > > > typo I'm missing?
> > > 
> > > Yes sorry, the patchset was not detected correctly in your case,
> > > ending up the patches being tested as individual ones.
> > > 
> > > I'll fixup the robot.
> > 
> > Thanks.
> > 
> > How did the robot decide to build this series in the first place? Does it 
> > build
> > everything sent to one of the lists on CC?
> 
> Yes, currently the following mailing lists are subscribed.  Patches
> sent to them will be tested if they can be git-am to RC or linux-next
> kernels:
> 
> kvm
> linux-acpi
> linux-bluetooth
> linux-btrfs
> linux-embedded
> linux-ext4
> linux-fsdevel
> linux-media
> linux-mmc
> linux-nfs
> linux-omap
> linux-pci
> linux-pm
> linux-raid
> linux-rdma
> linux-scsi
> linux-usb
> linux-wireless
> netdev
> netfilter-devel
> linux-mm
> driverdev-devel
> intel-gfx

And of course linux-kernel. More lists could be added in future.

Thanks,
Fengguang
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Missing operand for tlbie instruction on Power7

[Michael Ellerman]

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, 2015 at 05:00:49PM +1100, Michael Ellerman wrote:
> >> > > It's also worth noting that the __flush_power7 uses tlbiel instead of 
> >> > > tlbie.
> >> >
> >> > Yeah that's a good point. It's not clear if the swsusp code wants to a 
> >> > local or
> >> > a global invalidate.
> >>
> >> If I read the code right, this is called on the boot CPU when all the
> >> non-boot CPUs are still (potentially) down, so if you would do a global
> >> invalidate the non-boot CPUs might not even notice, so those need to do
> >> a (local) invalidate after being brought up anyway?  Or they probably
> >> need it before being brought down at all?  You figure it out, it makes
> >> my brain hurt :-)
> >
> > A good rule would be that every cpu does a local invalidate before turning 
> > on
> > the MMU. That would work for this case and also for kexec, kdump, junk left 
> > by
> > firmare etc. But I don't think we do that consistently in a way that works 
> > for
> > this code at the moment.
> >
> >> > As an alternative, can you try adding a .machine push / .machine 
> >> > "power4" /
> >> > .machine pop, around the tlbie. That should tell the assembler to drop 
> >> > back to
> >> > power4 mode for that instruction, which should then do the right thing. 
> >> > There
> >> > are some examples in that file.
> >>
> >> That will get the assembler to not complain, but it will assemble the wrong
> >> instruction: the power7 instruction has the same opcode (but different
> >> semantics).  So if you assemble 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 in fact
> > anything other than G5 or Book3E.
> 
> Likely not, but leaving it broken just because it is known behavior
> seems pretty weird to me.

In a universe where I have infinite time to fix random things we would
obviously do a proper fix :)

> I think Fedora will look at simply disabling hibernation on ppc64 so the file
> isn't built at all.  Seems to be a safer option.

It's safer for sure. Though you might have some G5 users who are using it and
notice it being disabled.

cheers


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[GIT PULL] strscpy powerpc fix for 3.4

[Chris Metcalf]

On 10/7/2015 6:44 PM, Stephen Rothwell wrote:

Hi Linus,

After merging Linus' tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

lib/string.c: In function 'strscpy':
lib/string.c:209:4: error: implicit declaration of function 'zero_bytemask' 
[-Werror=implicit-function-declaration]
 *(unsigned long *)(dest+res) = c & zero_bytemask(data);
 ^

Caused by commit

   30035e45753b ("string: provide strscpy()")


I posted a change equivalent to yours earlier today:

http://lkml.kernel.org/r/1444229188-19640-1-git-send-email-cmetc...@ezchip.com

I also did no testing, but since the rest of the PPC code is similar to the
asm-generic version, I believe the zero_bytemask() definition should be OK.

It probably should go through Linus' tree, like the previous set of patches.
I just pushed it up to the linux-tile tree for Linus to grab as:

git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile.git strscpy

Chris Metcalf (1):
  arch/powerpc: provide zero_bytemask() for big-endian

 arch/powerpc/include/asm/word-at-a-time.h | 5 +
 1 file changed, 5 insertions(+)

--
Chris Metcalf, EZChip Semiconductor
http://www.ezchip.com

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v3 1/2] powerpc/xmon: Paged output for paca display

[Sam Bobroff]

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 patch adds a new command ".", which takes a single (hex) numeric
argument: lines per page. It will cause the output of "dp" and "dpa"
to be broken into pages, if necessary.

Sample output:

0:mon> .10
0:mon> dp1
paca for cpu 0x1 @ cfdc0480:
 possible = yes
 present  = yes
 online   = yes
 lock_token   = 0x8000  (0x8)
 paca_index   = 0x1 (0xa)
 kernel_toc   = 0xc0eb2400  (0x10)
 kernelbase   = 0xc000  (0x18)
 kernel_msr   = 0xb0001032  (0x20)
 emergency_sp = 0xc0003ffe8000  (0x28)
 mc_emergency_sp  = 0xc0003ffe4000  (0x2e0)
 in_mce   = 0x0 (0x2e8)
 data_offset  = 0x7f17  (0x30)
 hw_cpu_id= 0x8 (0x38)
 cpu_start= 0x1 (0x3a)
 kexec_state  = 0x0 (0x3b)
[Hit a key (a:all, q:truncate, any:next page)]
0:mon>
 __current= 0xc0007e696620  (0x290)
 kstack   = 0xc0007e6ebe30  (0x298)
 stab_rr  = 0xb (0x2a0)
 saved_r1 = 0xc0007ef37860  (0x2a8)
 trap_save= 0x0 (0x2b8)
 soft_enabled = 0x0 (0x2ba)
 irq_happened = 0x1 (0x2bb)
 io_sync  = 0x0 (0x2bc)
 irq_work_pending = 0x0 (0x2bd)
 nap_state_lost   = 0x0 (0x2be)
0:mon>

(Based on a similar patch by Michael Ellerman 
"[v2] powerpc/xmon: Allow limiting the size of the paca display".
This patch is an alternative and cannot coexist with the original.)

Signed-off-by: Sam Bobroff 
---
 arch/powerpc/xmon/nonstdio.c | 57 ++--
 arch/powerpc/xmon/nonstdio.h |  3 +++
 arch/powerpc/xmon/xmon.c | 18 ++
 3 files changed, 76 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/xmon/nonstdio.c b/arch/powerpc/xmon/nonstdio.c
index c987486..18819d7 100644
--- a/arch/powerpc/xmon/nonstdio.c
+++ b/arch/powerpc/xmon/nonstdio.c
@@ -11,10 +11,25 @@
 #include 
 #include "nonstdio.h"
 
+int paginating = 0, paginate_skipping = 0;
+unsigned long paginate_lpp = 0 /* Lines Per Page */;
+unsigned long paginate_pos;
 
-static int xmon_write(const void *ptr, int nb)
+void xmon_start_pagination(void)
 {
-   return udbg_write(ptr, nb);
+   paginating = 1;
+   paginate_skipping = 0;
+   paginate_pos = 0;
+}
+
+void xmon_end_pagination(void)
+{
+   paginating = 0;
+}
+
+void xmon_set_pagination_lpp(unsigned long lpp)
+{
+   paginate_lpp = lpp;
 }
 
 static int xmon_readchar(void)
@@ -24,6 +39,44 @@ static int xmon_readchar(void)
return -1;
 }
 
+static int xmon_write(const char *ptr, int nb)
+{
+   int rv = 0;
+   const char *p = ptr, *q;
+   const char msg[] = "[Hit a key (a:all, q:truncate, any:next page)]";
+
+   if (nb <= 0)
+   return rv;
+   if (paginating && paginate_skipping)
+   return nb;
+   if (paginate_lpp) {
+   while (paginating && (q = strchr(p, '\n'))) {
+   rv += udbg_write(p, q - p + 1);
+   p = q + 1;
+   paginate_pos++;
+   if (paginate_pos >= paginate_lpp) {
+   udbg_write(msg, strlen(msg));
+   switch (xmon_readchar()) {
+   case 'a':
+   paginating = 0;
+   break;
+   case 'q':
+   paginate_skipping = 1;
+   break;
+   default:
+   /* nothing */
+   break;
+   }
+   paginate_pos = 0;
+   udbg_write("\r\n", 2);
+   if (paginate_skipping)
+   return nb;
+   }
+   }
+   }
+   return rv + udbg_write(p, nb - (p - ptr));
+}
+
 int xmon_putchar(int c)
 {
char ch = c;
diff --git a/arch/powerpc/xmon/nonstdio.h b/arch/powerpc/xmon/nonstdio.h
index 18a51de..f865336 100644
--- a/arch/powerpc/xmon/nonstdio.h
+++ b/arch/powerpc/xmon/nonstdio.h
@@ -3,6 +3,9 @@
 #define printf xmon_printf
 #define putcharxmon_putchar
 
+extern void xmon_set_pagination_lpp(unsigned long lpp);
+extern void xmon_start_pagination(void);
+extern void xmon_end_pagination(void);
 extern int xmon_putchar(int c);
 extern void xmon_puts(const char *);
 extern char *xmon_gets(char *, int);
diff 

Re: [kbuild-all] [PATCH 4/5 v2] pseries/iommu: implement DDW-aware dma_get_page_shift

[Fengguang Wu]

On Thu, Oct 08, 2015 at 11:11:59AM +1100, Michael Ellerman wrote:
> On Wed, 2015-10-07 at 21:56 +0800, Fengguang Wu wrote:
> > On Tue, Oct 06, 2015 at 02:39:06PM +1100, Michael Ellerman wrote:
> > > On Sat, 2015-10-03 at 04:33 +0800, kbuild test robot wrote:
> > > > Hi Nishanth,
> > > > 
> > > > [auto build test results on v4.3-rc3 -- if it's inappropriate base, 
> > > > please ignore]
> > > > 
> > > > config: powerpc-defconfig (attached as .config)
> > > > reproduce:
> > > > wget 
> > > > https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
> > > >  -O ~/bin/make.cross
> > > > chmod +x ~/bin/make.cross
> > > > # save the attached .config to linux build tree
> > > > make.cross ARCH=powerpc 
> > > > 
> > > > All error/warnings (new ones prefixed by >>):
> > > > 
> > > >arch/powerpc/platforms/pseries/iommu.c: In function 
> > > > 'iommu_init_early_pSeries':
> > > > >> arch/powerpc/platforms/pseries/iommu.c:1433:9: error: 'struct 
> > > > >> machdep_calls' has no member named 'dma_get_page_shift'
> > > >   ppc_md.dma_get_page_shift = dma_get_page_shift_pSeriesLP;
> > > 
> > > It was added in patch 3/5, so I think this error is bogus. Unless there's 
> > > a
> > > typo I'm missing?
> > 
> > Yes sorry, the patchset was not detected correctly in your case,
> > ending up the patches being tested as individual ones.
> > 
> > I'll fixup the robot.
> 
> Thanks.
> 
> How did the robot decide to build this series in the first place? Does it 
> build
> everything sent to one of the lists on CC?

Yes, currently the following mailing lists are subscribed.  Patches
sent to them will be tested if they can be git-am to RC or linux-next
kernels:

kvm
linux-acpi
linux-bluetooth
linux-btrfs
linux-embedded
linux-ext4
linux-fsdevel
linux-media
linux-mmc
linux-nfs
linux-omap
linux-pci
linux-pm
linux-raid
linux-rdma
linux-scsi
linux-usb
linux-wireless
netdev
netfilter-devel
linux-mm
driverdev-devel
intel-gfx

Thanks,
Fengguang

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 5/8] powerpc/pseries: Cleanup on pseries_eeh_get_state()

[Andrew Donnellan]

On 08/10/15 14:58, Gavin Shan wrote:

This cleans up pseries_eeh_get_state(), no functional changes:

* Return EEH_STATE_NOT_SUPPORT early when the 2nd RTAS output
  argument is zero to avoid nested if statements.
* Skip clearing bits in the PE state represented by variable
  "result" to simplify the code.

Signed-off-by: Gavin Shan 


Much easier to follow!

Reviewed-by: Andrew Donnellan 

--
Andrew Donnellan  Software Engineer, OzLabs
andrew.donnel...@au1.ibm.com  Australia Development Lab, Canberra
+61 2 6201 8874 (work)IBM Australia Limited

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 7/8] powerpc/powernv: Remove pnv_eeh_cap_start()

[Andrew Donnellan]

On 08/10/15 14:58, Gavin Shan wrote:

This moves the logic of pnv_eeh_cap_start() to pnv_eeh_find_cap()
as the function is only called by pnv_eeh_find_cap(). The logic
of both functions are pretty simple. No need to have separate
functions.

Signed-off-by: Gavin Shan 


Reviewed-by: Andrew Donnellan 

--
Andrew Donnellan  Software Engineer, OzLabs
andrew.donnel...@au1.ibm.com  Australia Development Lab, Canberra
+61 2 6201 8874 (work)IBM Australia Limited

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v2 5/8] powerpc/pseries: Cleanup on pseries_eeh_get_state()

[Gavin Shan]

This cleans up pseries_eeh_get_state(), no functional changes:

   * Return EEH_STATE_NOT_SUPPORT early when the 2nd RTAS output
 argument is zero to avoid nested if statements.
   * Skip clearing bits in the PE state represented by variable
 "result" to simplify the code.

Signed-off-by: Gavin Shan 
---
 arch/powerpc/platforms/pseries/eeh_pseries.c | 60 
 1 file changed, 26 insertions(+), 34 deletions(-)

diff --git a/arch/powerpc/platforms/pseries/eeh_pseries.c 
b/arch/powerpc/platforms/pseries/eeh_pseries.c
index 1ba55d0..ac3ffd9 100644
--- a/arch/powerpc/platforms/pseries/eeh_pseries.c
+++ b/arch/powerpc/platforms/pseries/eeh_pseries.c
@@ -433,42 +433,34 @@ static int pseries_eeh_get_state(struct eeh_pe *pe, int 
*state)
return ret;
 
/* Parse the result out */
-   result = 0;
-   if (rets[1]) {
-   switch(rets[0]) {
-   case 0:
-   result &= ~EEH_STATE_RESET_ACTIVE;
-   result |= EEH_STATE_MMIO_ACTIVE;
-   result |= EEH_STATE_DMA_ACTIVE;
-   break;
-   case 1:
-   result |= EEH_STATE_RESET_ACTIVE;
-   result |= EEH_STATE_MMIO_ACTIVE;
-   result |= EEH_STATE_DMA_ACTIVE;
-   break;
-   case 2:
-   result &= ~EEH_STATE_RESET_ACTIVE;
-   result &= ~EEH_STATE_MMIO_ACTIVE;
-   result &= ~EEH_STATE_DMA_ACTIVE;
-   break;
-   case 4:
-   result &= ~EEH_STATE_RESET_ACTIVE;
-   result &= ~EEH_STATE_MMIO_ACTIVE;
-   result &= ~EEH_STATE_DMA_ACTIVE;
-   result |= EEH_STATE_MMIO_ENABLED;
-   break;
-   case 5:
-   if (rets[2]) {
-   if (state) *state = rets[2];
-   result = EEH_STATE_UNAVAILABLE;
-   } else {
-   result = EEH_STATE_NOT_SUPPORT;
-   }
-   break;
-   default:
+   if (!rets[1])
+   return EEH_STATE_NOT_SUPPORT;
+
+   switch(rets[0]) {
+   case 0:
+   result = EEH_STATE_MMIO_ACTIVE |
+EEH_STATE_DMA_ACTIVE;
+   break;
+   case 1:
+   result = EEH_STATE_RESET_ACTIVE |
+EEH_STATE_MMIO_ACTIVE  |
+EEH_STATE_DMA_ACTIVE;
+   break;
+   case 2:
+   result = 0;
+   break;
+   case 4:
+   result = EEH_STATE_MMIO_ENABLED;
+   break;
+   case 5:
+   if (rets[2]) {
+   if (state) *state = rets[2];
+   result = EEH_STATE_UNAVAILABLE;
+   } else {
result = EEH_STATE_NOT_SUPPORT;
}
-   } else {
+   break;
+   default:
result = EEH_STATE_NOT_SUPPORT;
}
 
-- 
2.1.0

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: cxl: Fix number of allocated pages in SPA

[Michael Ellerman]

On Wed, 2015-07-10 at 05:07:40 UTC, Ian Munsie wrote:
> From: Christophe Lombard 
> 
> The scheduled process area is currently allocated before assigning the
> correct maximum processes to the AFU, which will mean we only ever
> allocate a fixed number of pages for the scheduled process area. This
> will limit us to 958 processes with 2 x 64K pages. If we try to use more
> processes than that we'd probably overrun the buffer and corrupt memory
> or crash.
> 
> AFUs that require three or more interrupts per process will not be
> affected as they are already limited to less processes than that, but we
> could hit it on an AFU that requires 0, 1 or 2 interrupts per process,
> or when using 4K pages.
> 
> This patch moves the initialisation of the num_procs to before the SPA
> allocation so that enough pages will be allocated for the number of
> processes that the AFU supports.
> 
> Signed-off-by: Christophe Lombard 
> Signed-off-by: Ian Munsie 
> Cc: stable  # 3.18+

Applied to powerpc fixes, thanks.

https://git.kernel.org/powerpc/c/4108efb02daa09cbb5db048a

cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Missing operand for tlbie instruction on Power7

[Michael Ellerman]

On Wed, 2015-10-07 at 02:19 -0500, Segher Boessenkool wrote:
> On Wed, Oct 07, 2015 at 05:00:49PM +1100, Michael Ellerman wrote:
> > > It's also worth noting that the __flush_power7 uses tlbiel instead of 
> > > tlbie.
> > 
> > Yeah that's a good point. It's not clear if the swsusp code wants to a 
> > local or
> > a global invalidate.
> 
> If I read the code right, this is called on the boot CPU when all the
> non-boot CPUs are still (potentially) down, so if you would do a global
> invalidate the non-boot CPUs might not even notice, so those need to do
> a (local) invalidate after being brought up anyway?  Or they probably
> need it before being brought down at all?  You figure it out, it makes
> my brain hurt :-)

A good rule would be that every cpu does a local invalidate before turning on
the MMU. That would work for this case and also for kexec, kdump, junk left by
firmare etc. But I don't think we do that consistently in a way that works for
this code at the moment.

> > As an alternative, can you try adding a .machine push / .machine "power4" /
> > .machine pop, around the tlbie. That should tell the assembler to drop back 
> > to
> > power4 mode for that instruction, which should then do the right thing. 
> > There
> > are some examples in that file.
> 
> That will get the assembler to not complain, but it will assemble the wrong
> instruction: the power7 instruction has the same opcode (but different
> semantics).  So if you assemble 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 in fact
anything other than G5 or Book3E.

cheers



___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: cxl: Workaround malformed pcie packets on some cards

[Michael Ellerman]

On Fri, 2015-02-10 at 05:23:33 UTC, Ian Munsie wrote:
> From: Philippe Bergheaud 
> 
> This works around a pcie host bridge defect on some cards, that can cause
> malformed Transaction Layer Packet (TLP) errors to be erroneously reported.
> 
> The upper nibble of the vendor section PSL revision is used to distinguish
> between different cards. The affected ones have it set to 0.
> 
> Signed-off-by: Philippe Bergheaud 
> Acked-by: Ian Munsie 

Applied to powerpc fixes, thanks.

https://git.kernel.org/powerpc/c/d79e6801b1868ff65f4c956d

cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: powerpc: Fix _ALIGN_* errors due to type difference.

[Michael Ellerman]

On Wed, 2015-10-07 at 14:16 +0530, Aneesh Kumar K.V wrote:
> Michael Ellerman  writes:
> 
> > On Fri, 2015-02-10 at 14:33:48 UTC, "Aneesh Kumar K.V" wrote:
> >> This avoid errors like
> >> 
> >> unsigned int usize = 1 << 30;
> >> int size = 1 << 30;
> >> unsigned long addr = 64UL << 30 ;
> >> 
> >> value = _ALIGN_DOWN(addr, usize); -> 0
> >> value = _ALIGN_DOWN(addr, size);  -> 0x10
> >
> > Are you actually seeing that anywhere? I assume not.
> 
> I hit that in new development. So not in the current kernel.

OK.

> >> diff --git a/arch/powerpc/boot/page.h b/arch/powerpc/boot/page.h
> >> index 14eca30fef64..87c42d7d283d 100644
> >> --- a/arch/powerpc/boot/page.h
> >> +++ b/arch/powerpc/boot/page.h
> >> @@ -22,8 +22,8 @@
> >>  #define PAGE_MASK (~(PAGE_SIZE-1))
> >>  
> >>  /* align addr on a size boundary - adjust address up/down if needed */
> >> -#define _ALIGN_UP(addr,size)  (((addr)+((size)-1))&(~((size)-1)))
> >> -#define _ALIGN_DOWN(addr,size)((addr)&(~((size)-1)))
> >> +#define _ALIGN_UP(addr, size) 
> >> (((addr)+((size)-1))&(~((typeof(addr))(size)-1)))
> >> +#define _ALIGN_DOWN(addr, size)   ((addr)&(~((typeof(addr))(size)-1)))
> >>  
> >>  /* align addr on a size boundary - adjust address up if needed */
> >>  #define _ALIGN(addr,size) _ALIGN_UP(addr,size)
> >> diff --git a/arch/powerpc/include/asm/page.h 
> >> b/arch/powerpc/include/asm/page.h
> >> index 71294a6e976e..1dd69774a31c 100644
> >> --- a/arch/powerpc/include/asm/page.h
> >> +++ b/arch/powerpc/include/asm/page.h
> >> @@ -240,8 +240,8 @@ extern long long virt_phys_offset;
> >>  #endif
> >>  
> >>  /* align addr on a size boundary - adjust address up/down if needed */
> >> -#define _ALIGN_UP(addr,size)  (((addr)+((size)-1))&(~((size)-1)))
> >> -#define _ALIGN_DOWN(addr,size)((addr)&(~((size)-1)))
> >> +#define _ALIGN_UP(addr, size) 
> >> (((addr)+((size)-1))&(~((typeof(addr))(size)-1)))
> >> +#define _ALIGN_DOWN(addr, size)   ((addr)&(~((typeof(addr))(size)-1)))
> >
> >
> > It looks like ALIGN() in kernel.h already does this right, so can we just 
> > use
> > that instead for _ALIGN_UP() at least.
> >
> 
> But we still can't get rid of _ALIGN_UP, because that is used in other
> parts of the kernel and if you are suggesting use
> 
> #define _ALIGN_UP __ALIGN_KERNEL, IMHO that is unnecessary indirection
> for no real benefit.

Huh? The benefit is not having to define the same macro twice, that seems like
a pretty clear win.

_ALIGN_UP is ALIGN, just with this bug unfixed.

In other words if _ALIGN_UP was already an alias for ALIGN then you would have
not seen the bug (except in _ALIGN_DOWN()).

cheers


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [3/3] cxl: fix leak of ctx->mapping when releasing kernel API contexts

[Michael Ellerman]

On Wed, 2015-30-09 at 01:58:07 UTC, Andrew Donnellan wrote:
> When a context is created via the kernel API, ctx->mapping is allocated
> within the kernel and thus needs to be freed when the context is freed.
> reclaim_ctx() attempts to do this for contexts with the ctx->kernelapi flag
> set, but afu_release() (which can be called from the kernel API through
> cxl_fd_release()) sets ctx->mapping to NULL before calling
> cxl_context_free() to free the context.
> 
> Add a check to afu_release() so that the mappings in contexts created via
> the kernel API are left alone so reclaim_ctx() can free them.
> 
> Reported-by: Matthew R. Ochs 
> Fixes: 6f7f0b3df6d4 ("cxl: Add AFU virtual PHB and kernel API")
> Signed-off-by: Andrew Donnellan 
> Acked-by: Ian Munsie 
> Reviewed-by: Matthew R. Ochs 

Applied to powerpc fixes, thanks.

https://git.kernel.org/powerpc/c/5f81b95fe2a2de4ec51d46ff

cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2] perf: Fix build break on powerpc due to sample_reg_masks

[Arnaldo Carvalho de Melo]

Em Wed, Oct 07, 2015 at 11:46:38AM +1100, Michael Ellerman escreveu:
> On Wed, 2015-09-30 at 16:45 -0300, Arnaldo Carvalho de Melo wrote:
> > Em Wed, Sep 30, 2015 at 09:09:09PM +0200, Jiri Olsa escreveu:
> > > On Wed, Sep 30, 2015 at 11:28:36AM -0700, Sukadev Bhattiprolu wrote:
> > > > From e29a7236122c4d807ec9ebc721b5d7d75c8d Mon Sep 17 00:00:00 2001
> > > > From: Sukadev Bhattiprolu 
> > > > Date: Thu, 24 Sep 2015 17:53:49 -0400
> > > > Subject: [PATCH v2] perf: Fix build break on powerpc due to 
> > > > sample_reg_masks
> > > > 
> > > > perf_regs.c does not get built on Powerpc as CONFIG_PERF_REGS is false.
> > > > So the weak definition for 'sample_regs_masks' doesn't get picked up.
> > > > 
> > > > Adding perf_regs.o to util/Build unconditionally, exposes a redefinition
> > > > error for 'perf_reg_value()' function (due to the static inline version
> > > > in util/perf_regs.h). So use #ifdef HAVE_PERF_REGS_SUPPORT' around that
> > > > function.
> > > > 
> > > > Signed-off-by: Sukadev Bhattiprolu 
> > > 
> > > Acked-by: Jiri Olsa 
> > 
> > Thanks, applied.
> 
> Is this going to Linus' tree any time soon?
> 
> I have folks pinging me to say that perf is broken on powerpc.

Checking this now.

- Arnaldo
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [kbuild-all] [PATCH 4/5 v2] pseries/iommu: implement DDW-aware dma_get_page_shift

[Fengguang Wu]

On Tue, Oct 06, 2015 at 02:39:06PM +1100, Michael Ellerman wrote:
> On Sat, 2015-10-03 at 04:33 +0800, kbuild test robot wrote:
> > Hi Nishanth,
> > 
> > [auto build test results on v4.3-rc3 -- if it's inappropriate base, please 
> > ignore]
> > 
> > config: powerpc-defconfig (attached as .config)
> > reproduce:
> > wget 
> > https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
> >  -O ~/bin/make.cross
> > chmod +x ~/bin/make.cross
> > # save the attached .config to linux build tree
> > make.cross ARCH=powerpc 
> > 
> > All error/warnings (new ones prefixed by >>):
> > 
> >arch/powerpc/platforms/pseries/iommu.c: In function 
> > 'iommu_init_early_pSeries':
> > >> arch/powerpc/platforms/pseries/iommu.c:1433:9: error: 'struct 
> > >> machdep_calls' has no member named 'dma_get_page_shift'
> >   ppc_md.dma_get_page_shift = dma_get_page_shift_pSeriesLP;
> 
> It was added in patch 3/5, so I think this error is bogus. Unless there's a
> typo I'm missing?

Yes sorry, the patchset was not detected correctly in your case,
ending up the patches being tested as individual ones.

I'll fixup the robot.

Thanks,
Fengguang
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 05/18] powerpc/85xx: Load all early TLB entries at once

[Laurentiu Tudor]

On 10/07/2015 06:48 AM, Scott Wood wrote:
> Use an AS=1 trampoline TLB entry to allow all normal TLB1 entries to
> be loaded at once.  This avoids the need to keep the translation that
> code is executing from in the same TLB entry in the final TLB
> configuration as during early boot, which in turn is helpful for
> relocatable kernels (e.g. kdump) where the kernel is not running from
> what would be the first TLB entry.
> 
> On e6500, we limit map_mem_in_cams() to the primary hwthread of a
> core (the boot cpu is always considered primary, as a kdump kernel
> can be entered on any cpu).  Each TLB only needs to be set up once,
> and when we do, we don't want another thread to be running when we
> create a temporary trampoline TLB1 entry.
> 
> Signed-off-by: Scott Wood 
> ---
>  arch/powerpc/kernel/setup_64.c   |  8 +
>  arch/powerpc/mm/fsl_booke_mmu.c  | 15 --
>  arch/powerpc/mm/mmu_decl.h   |  1 +
>  arch/powerpc/mm/tlb_nohash.c | 19 +++-
>  arch/powerpc/mm/tlb_nohash_low.S | 63 
> 
>  5 files changed, 102 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
> index bdcbb71..505ec2c 100644
> --- a/arch/powerpc/kernel/setup_64.c
> +++ b/arch/powerpc/kernel/setup_64.c
> @@ -108,6 +108,14 @@ static void setup_tlb_core_data(void)
>   for_each_possible_cpu(cpu) {
>   int first = cpu_first_thread_sibling(cpu);
>  
> + /*
> +  * If we boot via kdump on a non-primary thread,
> +  * make sure we point at the thread that actually
> +  * set up this TLB.
> +  */
> + if (cpu_first_thread_sibling(boot_cpuid) == first)
> + first = boot_cpuid;
> +
>   paca[cpu].tcd_ptr = [first].tcd;
>  
>   /*
> diff --git a/arch/powerpc/mm/fsl_booke_mmu.c b/arch/powerpc/mm/fsl_booke_mmu.c
> index 354ba3c..36d3c55 100644
> --- a/arch/powerpc/mm/fsl_booke_mmu.c
> +++ b/arch/powerpc/mm/fsl_booke_mmu.c
> @@ -105,8 +105,9 @@ unsigned long p_mapped_by_tlbcam(phys_addr_t pa)
>   * an unsigned long (for example, 32-bit implementations cannot support a 4GB
>   * size).
>   */
> -static void settlbcam(int index, unsigned long virt, phys_addr_t phys,
> - unsigned long size, unsigned long flags, unsigned int pid)
> +static void preptlbcam(int index, unsigned long virt, phys_addr_t phys,
> +unsigned long size, unsigned long flags,
> +unsigned int pid)
>  {
>   unsigned int tsize;
>  
> @@ -141,7 +142,13 @@ static void settlbcam(int index, unsigned long virt, 
> phys_addr_t phys,
>   tlbcam_addrs[index].start = virt;
>   tlbcam_addrs[index].limit = virt + size - 1;
>   tlbcam_addrs[index].phys = phys;
> +}
>  
> +void settlbcam(int index, unsigned long virt, phys_addr_t phys,


Nit: shouldn't this be left static? Also, now with this bulk TLB1 loading is it 
still used? Maybe it can be dropped.

---
Best Regards, Laurentiu

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v3 3/3] dmaengine: mpc512x: initialize with subsys_initcall()

[Vinod Koul]

On Thu, Sep 24, 2015 at 08:28:57PM +0300, Alexander Popov wrote:
> Initialize Freescale MPC512x DMA driver with subsys_initcall()
> to allow the depending drivers to call dma_request_slave_channel()
> during their probe.

Why can't we use defered probe ? I have been asking people to not move init
levels and esnure we have right solutions using defered probe

-- 
~Vinod
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Missing operand for tlbie instruction on Power7

[Michael Ellerman]

On Tue, 2015-10-06 at 11:25 -0700, Laura Abbott wrote:
> On 10/05/2015 08:35 PM, Michael Ellerman wrote:
> > On Fri, 2015-10-02 at 08:43 -0700, Laura Abbott wrote:
> >> Hi,
> >>
> >> We received a report (https://bugzilla.redhat.com/show_bug.cgi?id=1267395) 
> >> of bad assembly
> >> when compiling on powerpc with little endian
> >
> > ...
> >
> >> After some discussion with the binutils folks, it turns out that the tlbie
> >> instruction actually requires another operand and binutils was updated to
> >> check for this https://sourceware.org/ml/binutils/2015-05/msg00133.html .
> >>
> >> The code sequence in arch/powerpc/include/asm/ppc_asm.h now needs to be 
> >> updated:
> >>
> >> #if !defined(CONFIG_4xx) && !defined(CONFIG_8xx)
> >> #define tlbia   \
> >>   li  r4,1024;\
> >>   mtctr   r4; \
> >>   lis r4,KERNELBASE@h;\
> >> 0:  tlbie   r4; \
> >>   addir4,r4,0x1000;   \
> >>   bdnz0b
> >> #endif
> >>
> >> I don't know enough ppc assembly to properly fix this but I can test.
> >
> > How are you testing? This code is fairly old and I'm dubious if it still 
> > works.
> >
> > These days we have a ppc_md hook for flushing the TLB, ppc_md.flush_tlb().
> > Ideally the swsusp code would use that.
> 
> Testing would probably just be compile and maybe boot. I don't have regular
> access to the hardware. This problem just showed up for me when someone
> tried to compile Fedora rawhide with the latest binutils.

Right. The code in question is for software suspend, ie. hibernation, so that's
what needs testing if the code is going to change.

It was mostly written for G5 (543b9fd3528f6), though it later gained support
for 64-bit BookE (5a31057fc06c3).

I just tested it on a G5 here and amazingly it worked.

So it is working code, even if it is old and crufty.

>  From what I can tell, it looks like the .flush_tlb of the cpu_spec is only
> defined for power7 and power8 and I don't see a ppc_md.flush_tlb on the
> master branch.

Yes it's only defined for Power7 and Power8 at the moment. It definitely does
exist in Linus' master branch, but I'm not sure if that's the master branch
you're referring to.

> It's not clear what to do for the case where there is no
> flush_tlb function. Would filling in a .flush_tlb for all the PPC_BOOK3S_64
> with the existing tlbia sequence work?

It might, but it's not much of an improvement. Ideally we'd have an actually
correct sequence for each cpu type.

> It's also worth noting that the __flush_power7 uses tlbiel instead of tlbie.

Yeah that's a good point. It's not clear if the swsusp code wants to a local or
a global invalidate.


As an alternative, can you try adding a .machine push / .machine "power4" /
.machine pop, around the tlbie. That should tell the assembler to drop back to
power4 mode for that instruction, which should then do the right thing. There
are some examples in that file.

cheers


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Missing operand for tlbie instruction on Power7

[Segher Boessenkool]

On Wed, Oct 07, 2015 at 05:00:49PM +1100, Michael Ellerman wrote:
> > It's also worth noting that the __flush_power7 uses tlbiel instead of tlbie.
> 
> Yeah that's a good point. It's not clear if the swsusp code wants to a local 
> or
> a global invalidate.

If I read the code right, this is called on the boot CPU when all the
non-boot CPUs are still (potentially) down, so if you would do a global
invalidate the non-boot CPUs might not even notice, so those need to do
a (local) invalidate after being brought up anyway?  Or they probably
need it before being brought down at all?  You figure it out, it makes
my brain hurt :-)

> As an alternative, can you try adding a .machine push / .machine "power4" /
> .machine pop, around the tlbie. That should tell the assembler to drop back to
> power4 mode for that instruction, which should then do the right thing. There
> are some examples in that file.

That will get the assembler to not complain, but it will assemble the wrong
instruction: the power7 instruction has the same opcode (but different
semantics).  So if you assemble a "tlbie r4" in power4 mode, a newer CPU
will see it as a "tlbie r4,r0" and do the wrong thing.


Segher
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [GIT PULL 0/1] perf/urgent fix

[Ingo Molnar]

* Arnaldo Carvalho de Melo  wrote:

> From: Arnaldo Carvalho de Melo 
> 
> Hi Ingo,
> 
>   Please consider pulling,
> 
> - Arnaldo
> 
> The following changes since commit 097f70b3c4d84ffccca15195bdfde3a37c0a7c0f:
> 
>   Merge branch 'upstream' of 
> git://git.linux-mips.org/pub/scm/ralf/upstream-linus (2015-09-27 18:22:34 
> -0400)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git 
> tags/perf-urgent-for-mingo
> 
> for you to fetch changes up to 9fb4765451f22c5e782c1590747717550bff34b2:
> 
>   perf tools: Fix build break on powerpc due to sample_reg_masks (2015-10-07 
> 10:20:08 -0300)
> 
> 
> perf/urgent fix:
> 
> - Fix build break on (at least) powerpc due to sample_reg_masks, not being
>   available for linking (Sukadev Bhattiprolu)
> 
> Signed-off-by: Arnaldo Carvalho de Melo 
> 
> 
> Sukadev Bhattiprolu (1):
>   perf tools: Fix build break on powerpc due to sample_reg_masks
> 
>  tools/perf/util/Build   | 2 +-
>  tools/perf/util/perf_regs.c | 2 ++
>  tools/perf/util/perf_regs.h | 1 +
>  3 files changed, 4 insertions(+), 1 deletion(-)

Pulled, thanks Arnaldo!

Ingo
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 1/1] perf tools: Fix build break on powerpc due to sample_reg_masks

[Arnaldo Carvalho de Melo]

From: Sukadev Bhattiprolu 

perf_regs.c does not get built on Powerpc as CONFIG_PERF_REGS is false.
So the weak definition for 'sample_regs_masks' doesn't get picked up.

Adding perf_regs.o to util/Build unconditionally, exposes a redefinition
error for 'perf_reg_value()' function (due to the static inline version
in util/perf_regs.h). So use #ifdef HAVE_PERF_REGS_SUPPORT' around that
function.

Signed-off-by: Sukadev Bhattiprolu 
Acked-by: Jiri Olsa 
Cc: Naveen N. Rao 
Cc: Stephane Eranian 
Cc: linuxppc-...@ozlabs.org
Link: http://lkml.kernel.org/r/20150930182836.ga27...@us.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/Build   | 2 +-
 tools/perf/util/perf_regs.c | 2 ++
 tools/perf/util/perf_regs.h | 1 +
 3 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/Build b/tools/perf/util/Build
index 349bc96ca1fe..e5f18a288b74 100644
--- a/tools/perf/util/Build
+++ b/tools/perf/util/Build
@@ -17,6 +17,7 @@ libperf-y += levenshtein.o
 libperf-y += llvm-utils.o
 libperf-y += parse-options.o
 libperf-y += parse-events.o
+libperf-y += perf_regs.o
 libperf-y += path.o
 libperf-y += rbtree.o
 libperf-y += bitmap.o
@@ -103,7 +104,6 @@ libperf-$(CONFIG_LIBBABELTRACE) += data-convert-bt.o
 
 libperf-y += scripting-engines/
 
-libperf-$(CONFIG_PERF_REGS) += perf_regs.o
 libperf-$(CONFIG_ZLIB) += zlib.o
 libperf-$(CONFIG_LZMA) += lzma.o
 
diff --git a/tools/perf/util/perf_regs.c b/tools/perf/util/perf_regs.c
index 885e8ac83997..6b8eb13e14e4 100644
--- a/tools/perf/util/perf_regs.c
+++ b/tools/perf/util/perf_regs.c
@@ -6,6 +6,7 @@ const struct sample_reg __weak sample_reg_masks[] = {
SMPL_REG_END
 };
 
+#ifdef HAVE_PERF_REGS_SUPPORT
 int perf_reg_value(u64 *valp, struct regs_dump *regs, int id)
 {
int i, idx = 0;
@@ -29,3 +30,4 @@ out:
*valp = regs->cache_regs[id];
return 0;
 }
+#endif
diff --git a/tools/perf/util/perf_regs.h b/tools/perf/util/perf_regs.h
index 2984dcc54d67..679d6e493962 100644
--- a/tools/perf/util/perf_regs.h
+++ b/tools/perf/util/perf_regs.h
@@ -2,6 +2,7 @@
 #define __PERF_REGS_H
 
 #include 
+#include 
 
 struct regs_dump;
 
-- 
2.1.0

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v9 1/4] perf,kvm/{x86,s390}: Remove dependency on uapi/kvm_perf.h

[David Ahern]

On 10/6/15 8:25 PM, Hemant Kumar wrote:

@@ -358,7 +357,12 @@ static bool handle_end_event(struct perf_kvm_stat *kvm,
time_diff = sample->time - time_begin;

if (kvm->duration && time_diff > kvm->duration) {
-   char decode[DECODE_STR_LEN];
+   char *decode = zalloc(decode_str_len);


decode can still be a stack variable even with variable length.


+
+   if (!decode) {
+   pr_err("Not enough memory\n");
+   return false;
+   }

kvm->events_ops->decode_key(kvm, >key, decode);
if (!skip_event(decode)) {
@@ -366,6 +370,7 @@ static bool handle_end_event(struct perf_kvm_stat *kvm,
 sample->time, sample->pid, 
vcpu_record->vcpu_id,
 decode, time_diff/1000);
}
+   free(decode);
}

return update_kvm_event(event, vcpu, time_diff);
@@ -386,7 +391,8 @@ struct vcpu_event_record *per_vcpu_record(struct thread 
*thread,


-8<-


@@ -575,7 +581,7 @@ static void show_timeofday(void)

  static void print_result(struct perf_kvm_stat *kvm)
  {
-   char decode[DECODE_STR_LEN];
+   char *decode;


and a stack variable here too.

David
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[GIT PULL 0/1] perf/urgent fix

[Arnaldo Carvalho de Melo]

From: Arnaldo Carvalho de Melo 

Hi Ingo,

Please consider pulling,

- Arnaldo

The following changes since commit 097f70b3c4d84ffccca15195bdfde3a37c0a7c0f:

  Merge branch 'upstream' of 
git://git.linux-mips.org/pub/scm/ralf/upstream-linus (2015-09-27 18:22:34 -0400)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git 
tags/perf-urgent-for-mingo

for you to fetch changes up to 9fb4765451f22c5e782c1590747717550bff34b2:

  perf tools: Fix build break on powerpc due to sample_reg_masks (2015-10-07 
10:20:08 -0300)


perf/urgent fix:

- Fix build break on (at least) powerpc due to sample_reg_masks, not being
  available for linking (Sukadev Bhattiprolu)

Signed-off-by: Arnaldo Carvalho de Melo 


Sukadev Bhattiprolu (1):
  perf tools: Fix build break on powerpc due to sample_reg_masks

 tools/perf/util/Build   | 2 +-
 tools/perf/util/perf_regs.c | 2 ++
 tools/perf/util/perf_regs.h | 1 +
 3 files changed, 4 insertions(+), 1 deletion(-)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Time to remove platforms/cell?

[Geoff Levand]

On Mon, 2015-10-05 at 12:27 +0200, Marc Dietrich wrote:
> Am Sonntag, 4. Oktober 2015, 12:27:19 schrieb Geoff Levand:
> > I just tested the ps3-queue branch (v4.3-rc4 based) of my ps3-linux
> > git
> > repo and it works OK.
> > 
> > Do you see any output on the display, maybe some penguins at least
> 
> 
> I tried with ps3-queue and still no luck. Petitboot just says
> "Booting kernel 
> ..." thats all - no output.
> 
> FW is 3.15 of course
> Petitboot says (white-09.09.01-15.56)
> compiled kernel with gcc 4.4.2 (fedora 13)
> git clean -fdx; make ps3_defconfig; make vmlinux modules; make
> modules_install
> strip --strip-unneeded vmlinux

I think I can reproduce your problem, but didn't have time to look into
it.  I'll try to find time over the weekend.

If you want to try some things yourself, one is to exit to the
petitboot shell and try a manual kexec from there to see if there are
any messages that might explain what's going wrong.  Another is to use
git bisect to try to locate the kernel commit that introduced the
problem.  Let me know anything you find if you try.

-Geoff
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev