<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://permalink.gmane.org/gmane.linux.ports.ppc64.devel">
    <title>gmane.linux.ports.ppc64.devel</title>
    <link>http://permalink.gmane.org/gmane.linux.ports.ppc64.devel</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/82233"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/82229"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/82226"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/82225"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/82221"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/82220"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/82212"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/82211"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/82210"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/82209"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/82208"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/82203"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/82202"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/82200"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/82199"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/82188"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/82173"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/82165"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/82164"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/82159"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/82233">
    <title>Re: ppc/sata-fsl: orphan config value: CONFIG_MPC8315_DS</title>
    <link>http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/82233</link>
    <description>&lt;pre&gt;

My impression is that the simplest fix is Adrian's patch, which simply
keys off CONFIG_MPC831x_RDB.  It's not very satisfying, but I'll take
"working" vs. "rare lockups at boot".

If there is some other defining characteristic of boards that require
this patch, then a simple KConfig snippit with a description would be
even better.  Without any KConfig support for this variable, I lost it
even after using an oldconfig from my vendor.

(Or, if it was preserved, I might have removed it when trying to
optimize the kernel for support for our hardware, and I had no way of
knowing that the MPC8315_DS had any impact on my system at all...)

If it's actually a CPU/SOC-level problem, then an ideal situation
would conditionalize the fix by examining CPU version or stepping.
That would allow us to get rid of the config variable entirely.


Possibly.  :)

I only saw the problem (failure to SATA handshake at 3Gbps?) very
rarely, maybe one in 100 warm boot cycles.

I've added the patch to my current project, and have not&lt;/pre&gt;</description>
    <dc:creator>Anthony Foiani</dc:creator>
    <dc:date>2012-05-26T06:53:20</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/82229">
    <title>Re: pread() and pwrite() system calls</title>
    <link>http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/82229</link>
    <description>&lt;pre&gt;
Huh? Won't fly, r0 is used for the system call number!

On the other hand, I believed PPC had no problems passing
up to 8 32 bit arguments in registers (r3 to r10), but
I may be confusing with the standard ABI for function calls.

Hmm, a quick look at kernel/entry_32.s shows that it should 
be able to use at least r3 to r8, which should be sufficient.

I think that it is an uClibc problem.

Gabriel
&lt;/pre&gt;</description>
    <dc:creator>Gabriel Paubert</dc:creator>
    <dc:date>2012-05-25T16:45:51</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/82226">
    <title>pread() and pwrite() system calls</title>
    <link>http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/82226</link>
    <description>&lt;pre&gt;We have a system with linux 2.6.32 and the somewhat archaic
uClibc 0.9.27 (but I'm not sure the current version is
any better, and I think there are binary compatibility
if we update).

I've just discovered that pread() is 'implemented'
by using 3 lseek() system calls and read().
(the same is true for the 64bit versions).

I thought that pread() was supposed to be atomic
(so usable concurrently by multiple threads) which
means that this implementation is completely broken.

I've not looked to see what glibc does.

I can see that part of the problem is the alignment
of the 64bit value on the argument list of syscall()
(when the register save area is cast to a sycall
argument structure).
But it also looks as though the uClibc syscall()
stub can only pass 5 arguments in registers, and
pread() (with an aligned 64bit offset) requires 6.

The ucLibc source seems to be predicated by __NR_pread,
but if that were defined it would try to call
__syscall_pread() and I can't find that anywhere.

A special pread/pwrite as&lt;/pre&gt;</description>
    <dc:creator>David Laight</dc:creator>
    <dc:date>2012-05-25T13:29:06</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/82225">
    <title>Re: module loading issue/flaw in busy memory situation?</title>
    <link>http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/82225</link>
    <description>&lt;pre&gt;Hi,

The basic question is, has the GPR r11 a dedicated function (to point to the previous stack frame)
or is it still a volatile GPR, according to EABI definition ?
In the case of a dedicated function was assigned, the trampoline code generation in

     arch/powerpc/kernel/module_32.c

must be corrected. I'd suggest to use r12 instead of r11, in this case.

Best Regards
Steffen
&lt;/pre&gt;</description>
    <dc:creator>Steffen Rumler</dc:creator>
    <dc:date>2012-05-25T07:56:07</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/82221">
    <title>Re: Oops with Radeon/Uninorth on Maple</title>
    <link>http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/82221</link>
    <description>&lt;pre&gt;
Machine Check probably means that there's a HW configuration issue,
possibly something missing in the initialization of the AGP hardware to
make it actually work.

Cheers,
Ben.

&lt;/pre&gt;</description>
    <dc:creator>Benjamin Herrenschmidt</dc:creator>
    <dc:date>2012-05-25T00:59:55</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/82220">
    <title>module loading issue/flaw in busy memory situation?</title>
    <link>http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/82220</link>
    <description>&lt;pre&gt;Hi,

let's assume a module gets loaded into an already busy system, and the ".init.text" section with the __init function gets loaded into one memory region, and the normal ".text" section gets loaded into a totally different memory region.
Now assume that both regions are &amp;gt;32MB apart in addressing, so that a call from the __init .init.text function to any function in .text requires a trampoline as set up by the do_plt_call() function in arch/kernel/module*.c
So far so good for user code.

Now assume that the __init function is not trivial and will require register save/restore functions in prologue/epilogue with such calls generated by gcc, e.g., the __init function calls _rest32gpr_28_x() in the epilogue. This restore functions however is in the .text section due to the static link of the normal libs.

Now we have the __init function calling the trampoline, which is destroying r11. The trampoline is then jumping to the register restore function which relies on r11 still being intact, which it now isn't any&lt;/pre&gt;</description>
    <dc:creator>Wrobel Heinz-R39252</dc:creator>
    <dc:date>2012-05-24T20:05:19</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/82212">
    <title>[PATCH 2/2] powerpc/85xx: Add P1024rdb board support</title>
    <link>http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/82212</link>
    <description>&lt;pre&gt;From: Tang Yuantian &amp;lt;Yuantian.Tang&amp;lt; at &amp;gt;freescale.com&amp;gt;

The p1024rdb has the similar feature as the p1020rdb. Therefore, p1024rdb use
the same platform file as the p1/p2 rdb board.
Overview of P2020RDB platform
- DDR3 1G
- NOR flash 16M
- 3 Ethernet interfaces
- NAND Flash 32M
- SPI EEPROM 16M
- SD/MMC
- 2 USB ports
- 4 TDM ports

Signed-off-by: Jin Qing &amp;lt;b24347&amp;lt; at &amp;gt;freescale.com&amp;gt;
Signed-off-by: Li Yang &amp;lt;leoli&amp;lt; at &amp;gt;freescale.com&amp;gt;
Signed-off-by: Tang Yuantian &amp;lt;Yuantian.Tang&amp;lt; at &amp;gt;freescale.com&amp;gt;
---
 arch/powerpc/platforms/85xx/mpc85xx_rdb.c |   22 ++++++++++++++++++++++
 1 files changed, 22 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
index 313fce4..1910fdc 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -169,6 +169,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; machine_device_initcall(p1020_rdb_pc, mpc85xx_common_publish_devices);
 machine_device_initcall(p1020_utm_pc, mpc85xx_common_publish_devices);
 machine_device_ini&lt;/pre&gt;</description>
    <dc:creator>b29983&lt; at &gt;freescale.com</dc:creator>
    <dc:date>2012-05-24T09:08:28</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/82211">
    <title>[PATCH 1/2] powerpc/85xx: Add P1024rdb dts support</title>
    <link>http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/82211</link>
    <description>&lt;pre&gt;From: Tang Yuantian &amp;lt;Yuantian.Tang&amp;lt; at &amp;gt;freescale.com&amp;gt;

Signed-off-by: Jin Qing &amp;lt;b24347&amp;lt; at &amp;gt;freescale.com&amp;gt;
Signed-off-by: Li Yang &amp;lt;leoli&amp;lt; at &amp;gt;freescale.com&amp;gt;
Signed-off-by: Tang Yuantian &amp;lt;Yuantian.Tang&amp;lt; at &amp;gt;freescale.com&amp;gt;
---
 arch/powerpc/boot/dts/p1024rdb.dtsi    |  228 ++++++++++++++++++++++++++++++++
 arch/powerpc/boot/dts/p1024rdb_32b.dts |   87 ++++++++++++
 arch/powerpc/boot/dts/p1024rdb_36b.dts |   87 ++++++++++++
 3 files changed, 402 insertions(+), 0 deletions(-)
 create mode 100644 arch/powerpc/boot/dts/p1024rdb.dtsi
 create mode 100644 arch/powerpc/boot/dts/p1024rdb_32b.dts
 create mode 100644 arch/powerpc/boot/dts/p1024rdb_36b.dts

diff --git a/arch/powerpc/boot/dts/p1024rdb.dtsi b/arch/powerpc/boot/dts/p1024rdb.dtsi
new file mode 100644
index 0000000..b05dcb4
--- /dev/null
+++ b/arch/powerpc/boot/dts/p1024rdb.dtsi
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -0,0 +1,228 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt;
+/*
+ * P1024 RDB Device Tree Source stub (no addresses or top-level ranges)
+ *
+ * Copyright 2012 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary form&lt;/pre&gt;</description>
    <dc:creator>b29983&lt; at &gt;freescale.com</dc:creator>
    <dc:date>2012-05-24T09:08:27</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/82210">
    <title>Oops with Radeon/Uninorth on Maple</title>
    <link>http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/82210</link>
    <description>&lt;pre&gt;Hello, colleagues,

I'm trying to enable an AGP slot (again) on my Maple board (dual 
PPC970FX board, with CPC925 (U3H) north bridge).

  For now I'm stuck with a problem: I use radeon card, drm-radeon driver 
with KMS.

If I force drm-radeon to think about a card as about PCI card (by 
commenting corresponding lines in drm_radeon_kms.c), everything works, I 
get framebuffer, working X11, etc. If I enable agpgart-uninorth driver
and RADEON_IS_AGP flag in drm driver, I get an Oops early during the 
bootstrap. Relevant part of the log (I can send full dmesg of normal 
bootstrap or this oops on request, if that would help).

[    2.820647] Linux agpgart interface v0.103
[    2.824909] agpgart-uninorth 0000:f0:0b.0: Apple U3H chipset
[    2.830668] agpgart-uninorth 0000:f0:0b.0: Found device u3, rev 35
[    2.843611] agpgart-uninorth 0000:f0:0b.0: configuring for size idx: 64
[    2.850638] agpgart-uninorth 0000:f0:0b.0: AGP aperture is 256M &amp;lt; at &amp;gt; 0x0
[    2.857646] [drm] Initialized drm 1.1.0 20060810
[    2.862567&lt;/pre&gt;</description>
    <dc:creator>Dmitry Eremin-Solenikov</dc:creator>
    <dc:date>2012-05-24T06:18:55</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/82209">
    <title>[PATCH] [ppc] Do not reserve cpu spin-table for crash kernel</title>
    <link>http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/82209</link>
    <description>&lt;pre&gt;As of now, the kexec reserves the spin-table for all the CPUs
on an SMP machine. The spin-table is pointed to by the 
cpu-release-addr property in the device-tree. Reserving the
spin-table in the crash kernel will cause a BUG(), if the table
lies outside the memory reserved for the crashkernel.

Disable reserving the spin-table regions and use maxcpus=1 to 
use only the crashing CPU to boot the crash kernel.

Signed-off-by: Suzuki K. Poulose &amp;lt;suzuki&amp;lt; at &amp;gt;in.ibm.com&amp;gt;
---

 kexec/arch/ppc/crashdump-powerpc.c |   19 +++++++++++++------
 kexec/arch/ppc/fixup_dtb.c         |    4 ++++
 2 files changed, 17 insertions(+), 6 deletions(-)

diff --git a/kexec/arch/ppc/crashdump-powerpc.c b/kexec/arch/ppc/crashdump-powerpc.c
index 1bef69b..4c8c75d 100644
--- a/kexec/arch/ppc/crashdump-powerpc.c
+++ b/kexec/arch/ppc/crashdump-powerpc.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -262,10 +262,19 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static void ulltoa(unsigned long long i, char *str)
 }
 }
 
+/* Append str to cmdline */
+static void add_cmdline(char *cmdline, char *str)
+{
+int cmdlen = strlen(cmdl&lt;/pre&gt;</description>
    <dc:creator>Suzuki K. Poulose</dc:creator>
    <dc:date>2012-05-24T06:09:45</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/82208">
    <title>[PATCH v3 2/2] microblaze/PCI: move DMA &amp; IRQ init to device_add() notification path</title>
    <link>http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/82208</link>
    <description>&lt;pre&gt;From: Hiroo Matsumoto &amp;lt;matsumoto.hiroo&amp;lt; at &amp;gt;jp.fujitsu.com&amp;gt;

Microblaze initialized DMA and IRQ information in the pci_scan_child_bus()
-&amp;gt; pcibios_fixup_bus() path.  Some hotplug drivers use that path, but
others don't, e.g., pciehp, so sometimes hot-added devices are only
partly initialized.

This patch moves that initialization from pcibios_fixup_bus() to a new
pci_bus_notify() called in the pci_bus_add_device() -&amp;gt; device_add() path.
That means the initialization happens the same way for all PCI devices,
whether they are present at boot or hot-added later.

[bhelgaas: changelog, notifier name, inline registration]
Signed-off-by: Hiroo MATSUMOTO &amp;lt;matsumoto.hiroo&amp;lt; at &amp;gt;jp.fujitsu.com&amp;gt;
Signed-off-by: Bjorn Helgaas &amp;lt;bhelgaas&amp;lt; at &amp;gt;google.com&amp;gt;
---
 arch/microblaze/include/asm/pci.h |    1 -
 arch/microblaze/pci/pci-common.c  |   62 ++++++++++++++++++++-----------------
 2 files changed, 34 insertions(+), 29 deletions(-)

diff --git a/arch/microblaze/include/asm/pci.h b/arch/microblaze/include/asm/pci.h
index a0da88b..2aa97fd 10&lt;/pre&gt;</description>
    <dc:creator>Bjorn Helgaas</dc:creator>
    <dc:date>2012-05-23T22:37:05</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/82203">
    <title>[PATCH] powerpc/p1010rdb: add EEPROMs to device tree</title>
    <link>http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/82203</link>
    <description>&lt;pre&gt;Add EEPROM to the P1010RDB device tree.
The 24c01 acts as a memory SPD so it shouldn't be overwritten without
care.
The 24c256 is a general purpose memory.

Signed-off-by: Gustavo Zacarias &amp;lt;gustavo&amp;lt; at &amp;gt;zacarias.com.ar&amp;gt;
---
 arch/powerpc/boot/dts/p1010rdb.dtsi |   12 ++++++++++++
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/boot/dts/p1010rdb.dtsi b/arch/powerpc/boot/dts/p1010rdb.dtsi
index 4977614..ec7c27a 100644
--- a/arch/powerpc/boot/dts/p1010rdb.dtsi
+++ b/arch/powerpc/boot/dts/p1010rdb.dtsi
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -126,12 +126,24 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt;
 
 &amp;amp;board_soc {
 i2c&amp;lt; at &amp;gt;3000 {
+eeprom&amp;lt; at &amp;gt;50 {
+compatible = "st,24c256";
+reg = &amp;lt;0x50&amp;gt;;
+};
+
 rtc&amp;lt; at &amp;gt;68 {
 compatible = "pericom,pt7c4338";
 reg = &amp;lt;0x68&amp;gt;;
 };
 };
 
+i2c&amp;lt; at &amp;gt;3100 {
+eeprom&amp;lt; at &amp;gt;52 {
+compatible = "atmel,24c01";
+reg = &amp;lt;0x52&amp;gt;;
+};
+};
+
 spi&amp;lt; at &amp;gt;7000 {
 flash&amp;lt; at &amp;gt;0 {
 #address-cells = &amp;lt;1&amp;gt;;
&lt;/pre&gt;</description>
    <dc:creator>Gustavo Zacarias</dc:creator>
    <dc:date>2012-05-23T14:35:18</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/82202">
    <title>[PATCH] powerpc: tracing: Avoid tracepoint duplication with DECLARE_EVENT_CLASS</title>
    <link>http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/82202</link>
    <description>&lt;pre&gt;
irq_entry, irq_exit, timer_interrupt_entry and timer_interrupt_exit
all do the same thing so use DECLARE_EVENT_CLASS to avoid duplicating
everything 4 times.

This saves quite a lot of space in both instruction text and data:

   text    data     bss     dec     hex filename
   9265   19622      16   28903    70e7 arch/powerpc/kernel/irq.o
   6817   19019      16   25852    64fc arch/powerpc/kernel/irq.o

Signed-off-by: Anton Blanchard &amp;lt;anton&amp;lt; at &amp;gt;samba.org&amp;gt;
---

Index: linux-build/arch/powerpc/include/asm/trace.h
===================================================================
--- linux-build.orig/arch/powerpc/include/asm/trace.h2012-05-23 13:30:51.235534219 +1000
+++ linux-build/arch/powerpc/include/asm/trace.h2012-05-23 14:10:44.406639628 +1000
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -8,7 +8,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt;
 
 struct pt_regs;
 
-TRACE_EVENT(irq_entry,
+DECLARE_EVENT_CLASS(ppc64_interrupt_class,
 
 TP_PROTO(struct pt_regs *regs),
 
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -25,55 +25,32 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; TRACE_EVENT(irq_entry,
 TP_printk("pt_regs=%p", __entry-&amp;gt;regs)
 );
 
-TRACE_EVENT(irq_exit,
+DEFINE_&lt;/pre&gt;</description>
    <dc:creator>Anton Blanchard</dc:creator>
    <dc:date>2012-05-23T04:47:48</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/82200">
    <title>[PATCH] powerpc: Enable jump label support</title>
    <link>http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/82200</link>
    <description>&lt;pre&gt;
When looking through some instruction traces I noticed our tracepoint
checks were inline. It turns out we don't have CONFIG_JUMP_LABEL
enabled.

By enabling CONFIG_JUMP_LABEL we replace a load/compare/branch with
a nop at every tracepoint call. For example in do_IRQ:

CONFIG_JUMP_LABEL disabled:
        stdx 3,11,9
        lwz 0,8(29)
        cmpwi 7,0,0
        bne- 7,.L124
        bl .irq_enter

CONFIG_JUMP_LABEL enabled:
        stdx 3,11,9     
        nop
        bl .irq_enter  

Signed-off-by: Anton Blanchard &amp;lt;anton&amp;lt; at &amp;gt;samba.org&amp;gt;
---

Index: linux-build/arch/powerpc/configs/ppc64_defconfig
===================================================================
--- linux-build.orig/arch/powerpc/configs/ppc64_defconfig2012-04-05 13:47:45.691857096 +1000
+++ linux-build/arch/powerpc/configs/ppc64_defconfig2012-05-23 13:14:04.254270594 +1000
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -16,6 +16,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; CONFIG_BLK_DEV_INITRD=y
 CONFIG_PROFILING=y
 CONFIG_OPROFILE=y
 CONFIG_KPROBES=y
+CONFIG_JUMP_LABEL=y
 CONFIG_MODULES=y
 CONFIG_MODULE_UNLOAD=y
 CONFIG_M&lt;/pre&gt;</description>
    <dc:creator>Anton Blanchard</dc:creator>
    <dc:date>2012-05-23T03:58:41</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/82199">
    <title>powerc tree maintainership status</title>
    <link>http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/82199</link>
    <description>&lt;pre&gt;Hi Folks !

I'm going to be getting some surgery next week. In the good case, I
should be officially back to work 2 weeks later, but I might end
up being unavailable for longer.

So while I'm away, Michael Ellerman and Paul Mackerras are going to take
care of the powerpc tree. I'll make sure Paul and I sign Michael's PGP
key before I leave.

Cheers,
Ben.
&lt;/pre&gt;</description>
    <dc:creator>Benjamin Herrenschmidt</dc:creator>
    <dc:date>2012-05-23T03:43:27</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/82188">
    <title>Handling spin table in kdump</title>
    <link>http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/82188</link>
    <description>&lt;pre&gt;Hi

I came across the following issue while testing Kdump on an SMP 
board(Currituck) running a non-SMP kernel. Even though the kernel is UP,
the device-tree has the nodes for second CPU and the related details.


The kexec tool adds the spin table area as a reserved section in the 
device tree for the dump capture kernel. This value is read from the 
'cpu-release-addr'.

But now, if the spin table is not located within the 'Reserved region' 
for the crash kernel, the dump capture kernel would fail to boot, 
hitting a BUG in mm/bootmem.c as in [1].

This is because we try to reserve a region which is not available to the 
kernel.

So I am wondering how is this handled really on an SMP board (Fsl_bookE).

There are two possible solutions :
1) Do not reserve the regions for the spin-table, as we will use
only the crashing CPU in the second kernel(maxcpus=1).


2) Add the spin-table region to the available memory regions passed
to the kernel by kexec-tools.

I have tested (1) and it works fine for me. Yet to te&lt;/pre&gt;</description>
    <dc:creator>Suzuki K. Poulose</dc:creator>
    <dc:date>2012-05-22T12:42:10</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/82173">
    <title>powerpc -next rebase WARNING</title>
    <link>http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/82173</link>
    <description>&lt;pre&gt;Folks, bad news ... my fault.

I accidentally forgot a --signoff on a git am command last week, meaning
that a pair of patches are in -next and not signed off by me.

For various (legal) reasons that cannot go into Linus tree as-is, so I
have to rebase the tree to fix it.

Sorry about that ...

Cheers,
Ben.
&lt;/pre&gt;</description>
    <dc:creator>Benjamin Herrenschmidt</dc:creator>
    <dc:date>2012-05-22T01:51:13</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/82165">
    <title>RE: ppc/sata-fsl: orphan config value: CONFIG_MPC8315_DS</title>
    <link>http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/82165</link>
    <description>&lt;pre&gt;


Thanks for bringing it up again.  Looks like we do have a problem here.

Btw, did it help with your problem by enabling it?

Leo
&lt;/pre&gt;</description>
    <dc:creator>Li Yang-R58472</dc:creator>
    <dc:date>2012-05-21T06:31:48</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/82164">
    <title>Re: [PATCH] cpuidle: (POWER) Replace pseries_notify_cpuidle_add call with a elegant notifier to fix lockdep problem in start_secondary</title>
    <link>http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/82164</link>
    <description>&lt;pre&gt;Hi Ben,

On 05/21/2012 06:17 AM, Benjamin Herrenschmidt wrote:


  In the current design disable and enable device are called
  when the cpu comes online. This is to make sure that we clean up and
  re-register again. All the counters are reset.

  Not calling cpu disable when cpu goes offline currently, would only
  retain the counters right now.

  But I could add a offline check and disable the device there, if that
  results in cleaner design.  I will test and send across the patch with
  couple more pseries-idle fixes soon.

  Thanks for your review comments !

&lt;/pre&gt;</description>
    <dc:creator>Deepthi Dharwar</dc:creator>
    <dc:date>2012-05-21T04:55:07</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/82159">
    <title>Re: [PATCH] cpuidle: (POWER) Replace pseries_notify_cpuidle_add call with a elegant notifier to fix lockdep problem in start_secondary</title>
    <link>http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/82159</link>
    <description>&lt;pre&gt;
Any reason why you don't do cpuidle_disable_device() when the
CPU is going offline and cpuidle_enable_device() when it's coming
back ?

I'm applying the patch for now since it fixes a real problem but
if the above makes sense, please send a followup fix.

Cheers,
Ben.

&lt;/pre&gt;</description>
    <dc:creator>Benjamin Herrenschmidt</dc:creator>
    <dc:date>2012-05-21T00:47:01</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/82151">
    <title>[PATCH EDAC v26 02/66] edac: move dimm properties to struct dimm_info</title>
    <link>http://permalink.gmane.org/gmane.linux.ports.ppc64.devel/82151</link>
    <description>&lt;pre&gt;On systems based on chip select rows, all channels need to use memories
with the same properties, otherwise the memories on channels A and B
won't be recognized.

However, such assumption is not true for all types of memory
controllers.

Controllers for FB-DIMM's don't have such requirements.

Also, modern Intel controllers seem to be capable of handling such
differences.

So, we need to get rid of storing the DIMM information into a per-csrow
data, storing it, instead at the right place.

The first step is to move grain, mtype, dtype and edac_mode to the
per-dimm struct.

Reviewed-by: Aristeu Rozanski &amp;lt;arozansk&amp;lt; at &amp;gt;redhat.com&amp;gt;
Reviewed-by: Borislav Petkov &amp;lt;borislav.petkov&amp;lt; at &amp;gt;amd.com&amp;gt;
Acked-by: Chris Metcalf &amp;lt;cmetcalf&amp;lt; at &amp;gt;tilera.com&amp;gt;
Cc: Doug Thompson &amp;lt;norsk5&amp;lt; at &amp;gt;yahoo.com&amp;gt;
Cc: Borislav Petkov &amp;lt;borislav.petkov&amp;lt; at &amp;gt;amd.com&amp;gt;
Cc: Mark Gross &amp;lt;mark.gross&amp;lt; at &amp;gt;intel.com&amp;gt;
Cc: Jason Uhlenkott &amp;lt;juhlenko&amp;lt; at &amp;gt;akamai.com&amp;gt;
Cc: Tim Small &amp;lt;tim&amp;lt; at &amp;gt;buttersideup.com&amp;gt;
Cc: Ranganathan Desikan &amp;lt;ravi&amp;lt; at &amp;gt;jetztechnologies.com&amp;gt;
Cc: "Arvind R." &amp;lt;arvino55&amp;lt; at &amp;gt;gmail.com&amp;gt;
C&lt;/pre&gt;</description>
    <dc:creator>Mauro Carvalho Chehab</dc:creator>
    <dc:date>2012-05-18T16:31:49</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.linux.ports.ppc64.devel">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.linux.ports.ppc64.devel</link>
  </textinput>
</rdf:RDF>

