[PATCH] powerpc: Reword the returning from prom_init message
We get way too many bug reports that say the kernel is hung in
prom_init, which stems from the fact that the last piece of output
people see is returning from prom_init.
The kernel is almost never hung in prom_init(), it's just that it's
crashed somewhere after prom_init() but prior to the console coming up.
The existing message should give a clue to that, ie. returning from
indicates that prom_init() has finished, but it doesn't seem to work.
Let's try something different.
This prints:
Calling quiesce...
Shutting down Open Firmware, booting Linux via __start() ...
Which hopefully makes it clear that prom_init() is not the problem, and
although __start() probably isn't either, it's at least the right place
to begin looking.
Signed-off-by: Michael Ellerman m...@ellerman.id.au
---
arch/powerpc/kernel/prom_init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index 1a85d8f96739..bd3e0d8ac8fd 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -2910,7 +2910,7 @@ unsigned long __init prom_init(unsigned long r3, unsigned
long r4,
/* Don't print anything after quiesce under OPAL, it crashes OFW */
if (of_platform != PLATFORM_OPAL) {
- prom_printf(returning from prom_init\n);
+ prom_printf(Shutting down Open Firmware, booting Linux via
__start() ...\n);
prom_debug(-dt_header_start=0x%x\n, hdr);
}
--
2.1.0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 1/2] powerpc: Add 64bit optimised memcmp
From: Joakim Tjernlund
On Mon, 2015-01-12 at 11:55 +1100, Anton Blanchard wrote:
Hi David,
The unrolled loop (deleted) looks excessive.
On a modern cpu with multiple execution units you can usually
manage to get the loop overhead to execute in parallel to the
actual 'work'.
So I suspect that a much simpler 'word at a time' loop will be almost as
fast - especially in the
case where the code isn't
already in the cache and the compare is relatively short.
I'm always keen to keep things as simple as possible, but your loop is over
50% slower. Once the
loop hits a steady state you are going to run into front end issues with
instruction fetch on POWER8.
Interesting, I'm not an expert on ppc scheduling, but on my old x86 Athon 700
(I think
it was that one) a similar loop ran as fast as 'rep movsw'.
Out of curiosity, does preincrement make any difference(or can gcc do that
for you nowadays)?
It will only change register pressure slightly, and might allow any execution
delays be filled - but that is very processor dependant.
Actually you probably want to do 'a += 2' somewhere to reduce the instruction
count.
Similarly the end condition needs to compare one of the pointers.
Elsewhere (not ppc) I've used (++p)[-1] instead of *p++ to move the increment
before the load to get better scheduling.
a1 = *a;
b1 = *b;
while {
a2 = *++a;
b2 = *++b;
if (a1 != a2)
That should have been a1 != b1
break;
a1 = *++a;
b1 = *++b;
} while (a2 != a1);
and a2 != b2
David
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC 02/11] i2c: add quirk checks to core
Hi Wolfram,
On Fri, Jan 09, 2015 at 06:21:32PM +0100, Wolfram Sang wrote:
Let the core do the checks if HW quirks prevent a transfer. Saves code
from drivers and adds consistency.
Signed-off-by: Wolfram Sang w...@the-dreams.de
---
drivers/i2c/i2c-core.c | 53
++
1 file changed, 53 insertions(+)
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 39d25a8cb1ad..7b10a19abf5b 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -2063,6 +2063,56 @@ module_exit(i2c_exit);
*
*/
+/* Check if val is exceeding the quirk IFF quirk is non 0 */
+#define i2c_quirk_exceeded(val, quirk) ((quirk) ((val) (quirk)))
+
+static int i2c_quirk_error(struct i2c_adapter *adap, struct i2c_msg *msg,
char *err_msg)
+{
+ dev_err(adap-dev, quirk: %s (addr 0x%04x, size %u)\n, err_msg,
msg-addr, msg-len);
+ return -EOPNOTSUPP;
+}
+
+static int i2c_check_for_quirks(struct i2c_adapter *adap, struct i2c_msg
*msgs, int num)
+{
+ struct i2c_adapter_quirks *q = adap-quirks;
+ u16 max_read = q-max_read_len, max_write = q-max_write_len;
+ int max_num = q-max_num_msgs, i;
+
+ if (q-flags I2C_ADAPTER_QUIRK_COMB_WRITE_THEN_READ)
+ max_num = 2;
+
+ if (i2c_quirk_exceeded(num, max_num))
+ return i2c_quirk_error(adap, msgs[0], too many messages);
+
+ if (num == 2 q-flags I2C_ADAPTER_QUIRK_COMB_WRITE_FIRST) {
+ if (msgs[0].flags I2C_M_RD)
+ return i2c_quirk_error(adap, msgs[0], invalid first
write msg);
+
+ max_write = q-max_comb_write_len;
+ }
+
+ if (num == 2 q-flags I2C_ADAPTER_QUIRK_COMB_READ_SECOND) {
+ if (!(msgs[1].flags I2C_M_RD) || msgs[0].addr != msgs[1].addr)
+ return i2c_quirk_error(adap, msgs[1], invalid second
read msg);
+
+ max_read = q-max_comb_read_len;
+ }
+
+ for (i = 0; i num; i++) {
+ u16 len = msgs[i].len;
+
+ if (msgs[i].flags I2C_M_RD) {
+ if (i2c_quirk_exceeded(len, max_read))
+ return i2c_quirk_error(adap, msgs[i], msg too
long);
+ } else {
+ if (i2c_quirk_exceeded(len, max_write))
+ return i2c_quirk_error(adap, msgs[i], msg too
long);
+ }
+ }
+
I am not sure it will perfectly fit at91 quirks.
The hardware can handle two messages by using the internal address
feature. The internal address size is from one byte to three bytes. Then
the length of the first message is limited to three but we don't have
this constraint for the second one. If we have 'write then read' no problem
but if we have two write messages, the second one will cause a quirk
exceeded error.
Regards
Ludovic
+ return 0;
+}
+
/**
* __i2c_transfer - unlocked flavor of i2c_transfer
* @adap: Handle to I2C bus
@@ -2080,6 +2130,9 @@ int __i2c_transfer(struct i2c_adapter *adap, struct
i2c_msg *msgs, int num)
unsigned long orig_jiffies;
int ret, try;
+ if (adap-quirks i2c_check_for_quirks(adap, msgs, num))
+ return -EOPNOTSUPP;
+
/* i2c_trace_msg gets enabled when tracepoint i2c_transfer gets
* enabled. This is an efficient way of keeping the for-loop from
* being executed when not needed.
--
2.1.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC 02/11] i2c: add quirk checks to core
I am not sure it will perfectly fit at91 quirks. I think it does. The hardware can handle two messages by using the internal address feature. The internal address size is from one byte to three bytes. Then the length of the first message is limited to three but we don't have this constraint for the second one. If we have 'write then read' no problem but if we have two write messages, the second one will cause a quirk exceeded error. Yeah, for this reason I seperated I2C_ADAPTER_QUIRK_COMB_WRITE_FIRST out. The first message is checked against max_comb_write_len which is set to 3 for your driver. The second is checked agains max_write_len which is unset in your driver and thus can be of any length. That should work, no? signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/dts: Update platform PLL node
From: Igal Liberman igal.liber...@freescale.com
Signed-off-by: Igal Liberman igal.liber...@freescale.com
Change-Id: I92d020651237041d3767aa35e9345439714f9831
---
arch/powerpc/boot/dts/fsl/qoriq-clockgen2.dtsi |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-clockgen2.dtsi
b/arch/powerpc/boot/dts/fsl/qoriq-clockgen2.dtsi
index 48e0b6e..7e1f074 100644
--- a/arch/powerpc/boot/dts/fsl/qoriq-clockgen2.dtsi
+++ b/arch/powerpc/boot/dts/fsl/qoriq-clockgen2.dtsi
@@ -49,14 +49,16 @@ global-utilities@e1000 {
reg = 0x800 0x4;
compatible = fsl,qoriq-core-pll-2.0;
clocks = sysclk;
- clock-output-names = pll0, pll0-div2, pll0-div4;
+ clock-output-names = pll0, pll0-div2, pll0-div3,
+ pll0-div4;
};
pll1: pll1@820 {
#clock-cells = 1;
reg = 0x820 0x4;
compatible = fsl,qoriq-core-pll-2.0;
clocks = sysclk;
- clock-output-names = pll1, pll1-div2, pll1-div4;
+ clock-output-names = pll1, pll1-div2, pll1-div3,
+ pll1-div4;
};
platform_pll: platform-pll@c00 {
#clock-cells = 1;
--
1.7.9.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v7 0/4] Add support for parametrized events
Em Thu, Jan 08, 2015 at 10:54:34AM +0100, Jiri Olsa escreveu: for the patchset: Acked-by: Jiri Olsa jo...@kernel.org Applied to perf/core Thanks, - Arnaldo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC 02/11] i2c: add quirk checks to core
2015-01-09 18:21 GMT+01:00 Wolfram Sang w...@the-dreams.de:
Let the core do the checks if HW quirks prevent a transfer. Saves code
from drivers and adds consistency.
Signed-off-by: Wolfram Sang w...@the-dreams.de
---
drivers/i2c/i2c-core.c | 53
++
1 file changed, 53 insertions(+)
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 39d25a8cb1ad..7b10a19abf5b 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -2063,6 +2063,56 @@ module_exit(i2c_exit);
*
*/
+/* Check if val is exceeding the quirk IFF quirk is non 0 */
+#define i2c_quirk_exceeded(val, quirk) ((quirk) ((val) (quirk)))
+
+static int i2c_quirk_error(struct i2c_adapter *adap, struct i2c_msg *msg,
char *err_msg)
+{
+ dev_err(adap-dev, quirk: %s (addr 0x%04x, size %u)\n, err_msg,
msg-addr, msg-len);
+ return -EOPNOTSUPP;
+}
+
+static int i2c_check_for_quirks(struct i2c_adapter *adap, struct i2c_msg
*msgs, int num)
+{
+ struct i2c_adapter_quirks *q = adap-quirks;
+ u16 max_read = q-max_read_len, max_write = q-max_write_len;
+ int max_num = q-max_num_msgs, i;
+
+ if (q-flags I2C_ADAPTER_QUIRK_COMB_WRITE_THEN_READ)
+ max_num = 2;
+
+ if (i2c_quirk_exceeded(num, max_num))
+ return i2c_quirk_error(adap, msgs[0], too many messages);
+
+ if (num == 2 q-flags I2C_ADAPTER_QUIRK_COMB_WRITE_FIRST) {
+ if (msgs[0].flags I2C_M_RD)
+ return i2c_quirk_error(adap, msgs[0], invalid first
write msg);
+
+ max_write = q-max_comb_write_len;
+ }
+
+ if (num == 2 q-flags I2C_ADAPTER_QUIRK_COMB_READ_SECOND) {
+ if (!(msgs[1].flags I2C_M_RD) || msgs[0].addr !=
msgs[1].addr)
+ return i2c_quirk_error(adap, msgs[1], invalid
second read msg);
+
+ max_read = q-max_comb_read_len;
+ }
+
+ for (i = 0; i num; i++) {
+ u16 len = msgs[i].len;
+
+ if (msgs[i].flags I2C_M_RD) {
+ if (i2c_quirk_exceeded(len, max_read))
+ return i2c_quirk_error(adap, msgs[i], msg
too long);
+ } else {
+ if (i2c_quirk_exceeded(len, max_write))
+ return i2c_quirk_error(adap, msgs[i], msg
too long);
+ }
What about being more verbose in the error message, specifying if it
was a read or a write message that failed?
+ }
+
+ return 0;
+}
+
/**
* __i2c_transfer - unlocked flavor of i2c_transfer
* @adap: Handle to I2C bus
@@ -2080,6 +2130,9 @@ int __i2c_transfer(struct i2c_adapter *adap, struct
i2c_msg *msgs, int num)
unsigned long orig_jiffies;
int ret, try;
+ if (adap-quirks i2c_check_for_quirks(adap, msgs, num))
+ return -EOPNOTSUPP;
+
/* i2c_trace_msg gets enabled when tracepoint i2c_transfer gets
* enabled. This is an efficient way of keeping the for-loop from
* being executed when not needed.
--
2.1.3
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
motzblog.wordpress.com
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/dts: Unify B4 mux nodes
From: Igal Liberman igal.liber...@freescale.com
Signed-off-by: Igal Liberman igal.liber...@freescale.com
Change-Id: Ic5f28f7b492b708f00a5ff74dda723ce5e1da0ba
---
arch/powerpc/boot/dts/fsl/b4420si-post.dtsi | 15 ++-
arch/powerpc/boot/dts/fsl/b4860si-post.dtsi | 15 ++-
arch/powerpc/boot/dts/fsl/b4si-post.dtsi| 12
3 files changed, 16 insertions(+), 26 deletions(-)
diff --git a/arch/powerpc/boot/dts/fsl/b4420si-post.dtsi
b/arch/powerpc/boot/dts/fsl/b4420si-post.dtsi
index 86161ae..1ea8602 100644
--- a/arch/powerpc/boot/dts/fsl/b4420si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/b4420si-post.dtsi
@@ -80,20 +80,9 @@
compatible = fsl,b4420-device-config,
fsl,qoriq-device-config-2.0;
};
-/include/ qoriq-clockgen2.dtsi
global-utilities@e1000 {
- compatible = fsl,b4420-clockgen, fsl,qoriq-clockgen-2.0;
-
- mux0: mux0@0 {
- #clock-cells = 0;
- reg = 0x0 0x4;
- compatible = fsl,qoriq-core-mux-2.0;
- clocks = pll0 0, pll0 1, pll0 2,
- pll1 0, pll1 1, pll1 2;
- clock-names = pll0, pll0-div2, pll0-div4,
- pll1, pll1-div2, pll1-div4;
- clock-output-names = cmux0;
- };
+ compatible = fsl,b4420-clockgen, fsl,b4-clockgen,
+ fsl,qoriq-clockgen-2.0;
};
rcpm: global-utilities@e2000 {
diff --git a/arch/powerpc/boot/dts/fsl/b4860si-post.dtsi
b/arch/powerpc/boot/dts/fsl/b4860si-post.dtsi
index 65100b9..d0a5cde 100644
--- a/arch/powerpc/boot/dts/fsl/b4860si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/b4860si-post.dtsi
@@ -124,20 +124,9 @@
compatible = fsl,b4860-device-config,
fsl,qoriq-device-config-2.0;
};
-/include/ qoriq-clockgen2.dtsi
global-utilities@e1000 {
- compatible = fsl,b4860-clockgen, fsl,qoriq-clockgen-2.0;
-
- mux0: mux0@0 {
- #clock-cells = 0;
- reg = 0x0 0x4;
- compatible = fsl,qoriq-core-mux-2.0;
- clocks = pll0 0, pll0 1, pll0 2,
- pll1 0, pll1 1, pll1 2;
- clock-names = pll0, pll0-div2, pll0-div4,
- pll1, pll1-div2, pll1-div4;
- clock-output-names = cmux0;
- };
+ compatible = fsl,b4860-clockgen, fsl,b4-clockgen,
+ fsl,qoriq-clockgen-2.0;
};
rcpm: global-utilities@e2000 {
diff --git a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
index 1a54ba7..e4e69b0 100644
--- a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
@@ -214,9 +214,21 @@
fsl,liodn-bits = 12;
};
+/include/ qoriq-clockgen2.dtsi
clockgen: global-utilities@e1000 {
compatible = fsl,b4-clockgen, fsl,qoriq-clockgen-2.0;
reg = 0xe1000 0x1000;
+
+ mux0: mux0@0 {
+ #clock-cells = 0;
+ reg = 0x0 0x4;
+ compatible = fsl,qoriq-core-mux-2.0;
+ clocks = pll0 0, pll0 1, pll0 2,
+ pll1 0, pll1 1, pll1 2;
+ clock-names = pll0, pll0-div2, pll0-div4,
+ pll1, pll1-div2, pll1-div4;
+ clock-output-names = cmux0;
+ };
};
rcpm: global-utilities@e2000 {
--
1.7.9.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC 02/11] i2c: add quirk checks to core
On Fri, Jan 09, 2015 at 06:21:32PM +0100, Wolfram Sang wrote:
+static int i2c_quirk_error(struct i2c_adapter *adap, struct i2c_msg *msg,
char *err_msg)
+{
+ dev_err(adap-dev, quirk: %s (addr 0x%04x, size %u)\n, err_msg,
msg-addr, msg-len);
+ return -EOPNOTSUPP;
+}
So, what happens if I open an I2C adapter, find a message which causes
i2c_quirk_error() to be called, and then spin repeatedly calling that...
Shouldn't there be some rate limiting to this?
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: Tree for Jan 12 (build failures: m68k, ppc)
On Mon, Jan 12, 2015 at 5:24 PM, Guenter Roeck li...@roeck-us.net wrote:
On Mon, Jan 12, 2015 at 06:03:22PM +1100, Stephen Rothwell wrote:
Hi all,
Changes since 20150109:
The usb-gadget-fixes tree gained a conflict against the usb.current tree.
The net-next tree gained a build failure for which I reverted a commit.
The pinctrl tree gained a build failure so I used the version from
next-20150109.
The akpm tree lost a few patches that turned up elsewhere.
Non-merge commits (relative to Linus' tree): 2202
2272 files changed, 69868 insertions(+), 38441 deletions(-)
Build failures, seen since next-20150109:
m68k:allmodconfig
powerpc:ppc6xx_defconfig
Due to:
ERROR: __get_user_bad [drivers/gpu/drm/drm.ko] undefined!
make[1]: *** [__modpost] Error 1
Caused by commit d34f20d6e2f (drm: Atomic modeset ioctl).
Yeah, it needs a get_user() that supports 64-bit data.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/fsl: Add empty ranges to etsec2 dts files
With an earlier change (746c9e9f - Fix PowerPC address parsing hack), ethernet
has broken on Freescale boards such as the P1022. All ranges used by the
ethernet controllers are also covered by sub-devices that properly
declared the used ranges. The error shown is:
fsl-gianfar: probe of soc@ffe0:ethernet@b failed with error -12
Signed-off-by: Martin Hicks m...@bork.org
---
arch/powerpc/boot/dts/fsl/pq3-etsec2-0.dtsi |1 +
arch/powerpc/boot/dts/fsl/pq3-etsec2-1.dtsi |1 +
arch/powerpc/boot/dts/fsl/pq3-etsec2-2.dtsi |1 +
3 files changed, 3 insertions(+)
diff --git a/arch/powerpc/boot/dts/fsl/pq3-etsec2-0.dtsi
b/arch/powerpc/boot/dts/fsl/pq3-etsec2-0.dtsi
index 1382fec..d1a6c48 100644
--- a/arch/powerpc/boot/dts/fsl/pq3-etsec2-0.dtsi
+++ b/arch/powerpc/boot/dts/fsl/pq3-etsec2-0.dtsi
@@ -43,6 +43,7 @@ mdio@24000 {
ethernet@b {
#address-cells = 1;
#size-cells = 1;
+ ranges = ;
device_type = network;
model = eTSEC;
compatible = fsl,etsec2;
diff --git a/arch/powerpc/boot/dts/fsl/pq3-etsec2-1.dtsi
b/arch/powerpc/boot/dts/fsl/pq3-etsec2-1.dtsi
index 221cd2e..0447d38 100644
--- a/arch/powerpc/boot/dts/fsl/pq3-etsec2-1.dtsi
+++ b/arch/powerpc/boot/dts/fsl/pq3-etsec2-1.dtsi
@@ -43,6 +43,7 @@ mdio@25000 {
ethernet@b1000 {
#address-cells = 1;
#size-cells = 1;
+ ranges = ;
device_type = network;
model = eTSEC;
compatible = fsl,etsec2;
diff --git a/arch/powerpc/boot/dts/fsl/pq3-etsec2-2.dtsi
b/arch/powerpc/boot/dts/fsl/pq3-etsec2-2.dtsi
index 61456c3..d2b7255 100644
--- a/arch/powerpc/boot/dts/fsl/pq3-etsec2-2.dtsi
+++ b/arch/powerpc/boot/dts/fsl/pq3-etsec2-2.dtsi
@@ -42,6 +42,7 @@ mdio@26000 {
ethernet@b2000 {
#address-cells = 1;
#size-cells = 1;
+ ranges = ;
device_type = network;
model = eTSEC;
compatible = fsl,etsec2;
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: Tree for Jan 12 (build failures: m68k, ppc)
On Mon, Jan 12, 2015 at 06:03:22PM +1100, Stephen Rothwell wrote: Hi all, Changes since 20150109: The usb-gadget-fixes tree gained a conflict against the usb.current tree. The net-next tree gained a build failure for which I reverted a commit. The pinctrl tree gained a build failure so I used the version from next-20150109. The akpm tree lost a few patches that turned up elsewhere. Non-merge commits (relative to Linus' tree): 2202 2272 files changed, 69868 insertions(+), 38441 deletions(-) Build failures, seen since next-20150109: m68k:allmodconfig powerpc:ppc6xx_defconfig Due to: ERROR: __get_user_bad [drivers/gpu/drm/drm.ko] undefined! make[1]: *** [__modpost] Error 1 Caused by commit d34f20d6e2f (drm: Atomic modeset ioctl). Bisect results: # bad: [39b673bba50275b516543d32ef78767a524b9f26] Add linux-next specific files for 20150109 # good: [b1940cd21c0f4abdce101253e860feff547291b0] Linux 3.19-rc3 git bisect start 'HEAD' 'v3.19-rc3' # good: [d01312ff089667b0b996228ca165d4a9c124b28f] Merge remote-tracking branch 'net-next/master' git bisect good d01312ff089667b0b996228ca165d4a9c124b28f # bad: [b90b3ee4f96067f9eb2edf9e61c9f6356b796232] Merge remote-tracking branch 'device-mapper/for-next' git bisect bad b90b3ee4f96067f9eb2edf9e61c9f6356b796232 # bad: [d4a32441dd063fd10f41826a69dea2b3f410501a] Merge remote-tracking branch 'drm-intel/for-linux-next' git bisect bad d4a32441dd063fd10f41826a69dea2b3f410501a # good: [d01203fd1b8c822adbadb0f0e417a7d344456150] Merge remote-tracking branch 'crypto/master' git bisect good d01203fd1b8c822adbadb0f0e417a7d344456150 # good: [2be57922d46fdec4360ced2eb108832c5a90bc0e] drm/i915: Fix CRC support for DP port D on CHV git bisect good 2be57922d46fdec4360ced2eb108832c5a90bc0e # bad: [4baddea51fe5d73a4f2226e9febc6da21e11bac0] Merge remote-tracking branch 'drm/drm-next' git bisect bad 4baddea51fe5d73a4f2226e9febc6da21e11bac0 # good: [72a3697097b8dc92f5b8362598f5730a9986eb83] Merge branch 'topic/core-stuff' into topic/atomic-core git bisect good 72a3697097b8dc92f5b8362598f5730a9986eb83 # bad: [a97df1ccd3c30f16385696964767adf854878021] drm/atomic: Hide drm.ko internal interfaces git bisect bad a97df1ccd3c30f16385696964767adf854878021 # good: [88a48e297b3a3bac6022c03babfb038f1a886cea] drm: add atomic properties git bisect good 88a48e297b3a3bac6022c03babfb038f1a886cea # good: [6b4959f43a04e12d39c5700607727f2cbcfeac31] drm/atomic: atomic plane properties git bisect good 6b4959f43a04e12d39c5700607727f2cbcfeac31 # bad: [d34f20d6e2f21bd3531b969dc40913181a8ae31a] drm: Atomic modeset ioctl git bisect bad d34f20d6e2f21bd3531b969dc40913181a8ae31a # good: [ae16c597b61ae4613b13a0c3fac302e8d8827ac7] drm/atomic: atomic connector properties git bisect good ae16c597b61ae4613b13a0c3fac302e8d8827ac7 # first bad commit: [d34f20d6e2f21bd3531b969dc40913181a8ae31a] drm: Atomic modeset ioctl ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 09/10] PCI, powerpc: clip firmware assigned resource under parent bridge's
Some bios put range that is not fully coverred by root bus resources.
Try to clip them and update them in pci bridge bars.
We'd like to fix other arches instead of just x86.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491
Reported-by: Marek Kordik kordikma...@gmail.com
Fixes: 5b28541552ef (PCI: Restrict 64-bit prefetchable bridge windows to
64-bit resources)
Signed-off-by: Yinghai Lu ying...@kernel.org
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Paul Mackerras pau...@samba.org
Cc: Michael Ellerman m...@ellerman.id.au
Cc: Gavin Shan gws...@linux.vnet.ibm.com
Cc: Anton Blanchard an...@samba.org
Cc: Sebastian Ott seb...@linux.vnet.ibm.com
Cc: Wei Yang weiy...@linux.vnet.ibm.com
Cc: Andrew Murray amur...@embedded-bits.co.uk
Cc: linuxppc-dev@lists.ozlabs.org
---
arch/powerpc/kernel/pci-common.c | 43 +++-
1 file changed, 42 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index 37d512d..6909546 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -1148,6 +1148,7 @@ static void pcibios_allocate_bus_resources(struct pci_bus
*bus)
struct pci_bus *b;
int i;
struct resource *res, *pr;
+ bool changed = false;
pr_debug(PCI: Allocating bus resources for %04x:%02x...\n,
pci_domain_nr(bus), bus-number);
@@ -1184,6 +1185,8 @@ static void pcibios_allocate_bus_resources(struct pci_bus
*bus)
pr, (pr pr-name) ? pr-name : nil);
if (pr !(pr-flags IORESOURCE_UNSET)) {
+ struct pci_dev *dev = bus-self;
+
if (request_resource(pr, res) == 0)
continue;
/*
@@ -1193,6 +1196,16 @@ static void pcibios_allocate_bus_resources(struct
pci_bus *bus)
*/
if (reparent_resources(pr, res) == 0)
continue;
+
+ if (dev i = PCI_BRIDGE_RESOURCES
+ i PCI_NUM_RESOURCES
+ (dev-class 8) == PCI_CLASS_BRIDGE_PCI
+ pci_bus_clip_resource(dev, res)) {
+ changed = true;
+ if (pci_claim_resource(dev, i) = 0)
+ continue;
+ }
+
}
pr_warning(PCI: Cannot allocate resource region
%d of PCI bridge %d, will remap\n, i, bus-number);
@@ -1208,6 +1221,9 @@ static void pcibios_allocate_bus_resources(struct pci_bus
*bus)
res-flags = 0;
}
+ if (changed)
+ pci_setup_bridge(bus);
+
list_for_each_entry(b, bus-children, node)
pcibios_allocate_bus_resources(b);
}
@@ -1225,6 +1241,13 @@ static inline void alloc_resource(struct pci_dev *dev,
int idx)
pr = pci_find_parent_resource(dev, r);
if (!pr || (pr-flags IORESOURCE_UNSET) ||
request_resource(pr, r) 0) {
+ /* try again with clip */
+ if (idx != PCI_ROM_RESOURCE pci_bus_clip_resource(dev, r)) {
+ pci_update_resource(dev, idx);
+ if (pci_claim_resource(dev, idx) = 0)
+ return;
+ }
+
printk(KERN_WARNING PCI: Cannot allocate resource region %d
of device %s, will remap\n, idx, pci_name(dev));
if (pr)
@@ -1386,6 +1409,7 @@ void pcibios_claim_one_bus(struct pci_bus *bus)
struct pci_bus *child_bus;
list_for_each_entry(dev, bus-devices, bus_list) {
+ bool changed = false;
int i;
for (i = 0; i PCI_NUM_RESOURCES; i++) {
@@ -1401,8 +1425,25 @@ void pcibios_claim_one_bus(struct pci_bus *bus)
(unsigned long long)r-end,
(unsigned int)r-flags);
- pci_claim_resource(dev, i);
+ if (pci_claim_resource(dev, i) = 0)
+ continue;
+
+ if (dev-subordinate
+ i = PCI_BRIDGE_RESOURCES
+ i PCI_NUM_RESOURCES
+ (dev-class 8) == PCI_CLASS_BRIDGE_PCI
+ pci_bus_clip_resource(dev, r)) {
+ changed = true;
+ pci_claim_resource(dev, i);
+ } else if (i PCI_BRIDGE_RESOURCES
+ i != PCI_ROM_RESOURCE
+ pci_bus_clip_resource(dev, r)) {
+ pci_update_resource(dev, i);
+ pci_claim_resource(dev, i);
+ }
Re: [PATCH] powerpc/fsl: Add empty ranges to etsec2 dts files
On Mon, 2015-01-12 at 10:27 -0500, Martin Hicks wrote:
With an earlier change (746c9e9f - Fix PowerPC address parsing hack), ethernet
has broken on Freescale boards such as the P1022. All ranges used by the
ethernet controllers are also covered by sub-devices that properly
declared the used ranges. The error shown is:
fsl-gianfar: probe of soc@ffe0:ethernet@b failed with error -12
Signed-off-by: Martin Hicks m...@bork.org
---
arch/powerpc/boot/dts/fsl/pq3-etsec2-0.dtsi |1 +
arch/powerpc/boot/dts/fsl/pq3-etsec2-1.dtsi |1 +
arch/powerpc/boot/dts/fsl/pq3-etsec2-2.dtsi |1 +
3 files changed, 3 insertions(+)
http://patchwork.ozlabs.org/patch/422446/
diff --git a/arch/powerpc/boot/dts/fsl/pq3-etsec2-0.dtsi
b/arch/powerpc/boot/dts/fsl/pq3-etsec2-0.dtsi
index 1382fec..d1a6c48 100644
--- a/arch/powerpc/boot/dts/fsl/pq3-etsec2-0.dtsi
+++ b/arch/powerpc/boot/dts/fsl/pq3-etsec2-0.dtsi
@@ -43,6 +43,7 @@ mdio@24000 {
ethernet@b {
#address-cells = 1;
#size-cells = 1;
+ ranges = ;
The = is usually omitted for empty properties.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/6] powerpc/ps3: Add ps3_mm_set_repository_highmem
Add the new routine ps3_mm_set_repository_highmem() that saves highmem info to
the ps3 repository. Also, move the existing ps3_mm_get_repository_highmem()
routine up in the source file.
This inplementation of ps3_mm_set_repository_highmem() assumes the repository
will have a single highmem region entry (at index 0).
Signed-off-by: Geoff Levand ge...@infradead.org
---
arch/powerpc/platforms/ps3/mm.c | 68 +++--
1 file changed, 38 insertions(+), 30 deletions(-)
diff --git a/arch/powerpc/platforms/ps3/mm.c b/arch/powerpc/platforms/ps3/mm.c
index 0c9f643..04c1b93 100644
--- a/arch/powerpc/platforms/ps3/mm.c
+++ b/arch/powerpc/platforms/ps3/mm.c
@@ -223,6 +223,44 @@ void ps3_mm_vas_destroy(void)
}
}
+static int ps3_mm_get_repository_highmem(struct mem_region *r)
+{
+ int result;
+
+ /* Assume a single highmem region. */
+
+ result = ps3_repository_read_highmem_info(0, r-base, r-size);
+
+ if (result)
+ goto zero_region;
+
+ if (!r-base || !r-size) {
+ result = -1;
+ goto zero_region;
+ }
+
+ r-offset = r-base - map.rm.size;
+
+ DBG(%s:%d: Found high region in repository: %llxh %llxh\n,
+ __func__, __LINE__, r-base, r-size);
+
+ return 0;
+
+zero_region:
+ DBG(%s:%d: No high region in repository.\n, __func__, __LINE__);
+
+ r-size = r-base = r-offset = 0;
+ return result;
+}
+
+static int ps3_mm_set_repository_highmem(const struct mem_region *r)
+{
+ /* Assume a single highmem region. */
+
+ return r ? ps3_repository_write_highmem_info(0, r-base, r-size) :
+ ps3_repository_write_highmem_info(0, 0, 0);
+}
+
/**
* ps3_mm_region_create - create a memory region in the vas
* @r: pointer to a struct mem_region to accept initialized values
@@ -293,36 +331,6 @@ static void ps3_mm_region_destroy(struct mem_region *r)
}
}
-static int ps3_mm_get_repository_highmem(struct mem_region *r)
-{
- int result;
-
- /* Assume a single highmem region. */
-
- result = ps3_repository_read_highmem_info(0, r-base, r-size);
-
- if (result)
- goto zero_region;
-
- if (!r-base || !r-size) {
- result = -1;
- goto zero_region;
- }
-
- r-offset = r-base - map.rm.size;
-
- DBG(%s:%d: Found high region in repository: %llxh %llxh\n,
- __func__, __LINE__, r-base, r-size);
-
- return 0;
-
-zero_region:
- DBG(%s:%d: No high region in repository.\n, __func__, __LINE__);
-
- r-size = r-base = r-offset = 0;
- return result;
-}
-
/**/
/* dma routines
*/
/**/
--
1.9.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 6/6] powerpc/ps3: Update ps3_defconfig
Refresh ps3_defconfig and add CONFIG_PS3_REPOSITORY_WRITE=y. Signed-off-by: Geoff Levand ge...@infradead.org --- arch/powerpc/configs/ps3_defconfig | 17 ++--- 1 file changed, 6 insertions(+), 11 deletions(-) diff --git a/arch/powerpc/configs/ps3_defconfig b/arch/powerpc/configs/ps3_defconfig index 2e637c8..9836c1b 100644 --- a/arch/powerpc/configs/ps3_defconfig +++ b/arch/powerpc/configs/ps3_defconfig @@ -22,6 +22,8 @@ CONFIG_MODULE_UNLOAD=y # CONFIG_PPC_PSERIES is not set # CONFIG_PPC_PMAC is not set CONFIG_PPC_PS3=y +CONFIG_PS3_ADVANCED=y +CONFIG_PS3_REPOSITORY_WRITE=y CONFIG_PS3_DISK=y CONFIG_PS3_ROM=y CONFIG_PS3_FLASH=y @@ -64,11 +66,9 @@ CONFIG_BT_HCIBTUSB=m CONFIG_CFG80211=m CONFIG_CFG80211_WEXT=y CONFIG_MAC80211=m -CONFIG_MAC80211_RC_PID=y # CONFIG_MAC80211_RC_MINSTREL is not set CONFIG_UEVENT_HELPER_PATH=/sbin/hotplug # CONFIG_FIRMWARE_IN_KERNEL is not set -CONFIG_PROC_DEVICETREE=y CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=65535 @@ -76,7 +76,6 @@ CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y CONFIG_BLK_DEV_SR=y CONFIG_CHR_DEV_SG=m -CONFIG_SCSI_MULTI_LUN=y # CONFIG_SCSI_LOWLEVEL is not set CONFIG_MD=y CONFIG_BLK_DEV_DM=m @@ -107,7 +106,6 @@ CONFIG_INPUT_EVDEV=m # CONFIG_LEGACY_PTYS is not set # CONFIG_HW_RANDOM is not set # CONFIG_HWMON is not set -CONFIG_VIDEO_OUTPUT_CONTROL=m CONFIG_FB=y CONFIG_FB_PS3=y # CONFIG_VGA_CONSOLE is not set @@ -130,8 +128,6 @@ CONFIG_HID_TWINHAN=m CONFIG_HID_LOGITECH=m CONFIG_HID_LOGITECH_DJ=m CONFIG_HID_MICROSOFT=m -CONFIG_HID_PS3REMOTE=m -CONFIG_HID_SONY=m CONFIG_HID_SUNPLUS=m CONFIG_HID_SMARTJOYPLUS=m CONFIG_USB_HIDDEV=y @@ -169,18 +165,17 @@ CONFIG_NLS_CODEPAGE_437=y CONFIG_NLS_ISO8859_1=y CONFIG_CRC_CCITT=m CONFIG_CRC_T10DIF=y -CONFIG_MAGIC_SYSRQ=y +CONFIG_DEBUG_INFO=y CONFIG_DEBUG_FS=y +CONFIG_MAGIC_SYSRQ=y +CONFIG_DEBUG_MEMORY_INIT=y +CONFIG_DEBUG_STACKOVERFLOW=y CONFIG_DETECT_HUNG_TASK=y CONFIG_PROVE_LOCKING=y CONFIG_DEBUG_LOCKDEP=y -CONFIG_DEBUG_INFO=y -CONFIG_DEBUG_MEMORY_INIT=y CONFIG_DEBUG_LIST=y CONFIG_RCU_CPU_STALL_TIMEOUT=60 # CONFIG_FTRACE is not set -CONFIG_DEBUG_STACKOVERFLOW=y -CONFIG_CRYPTO_CCM=m CONFIG_CRYPTO_GCM=m CONFIG_CRYPTO_PCBC=m CONFIG_CRYPTO_MICHAEL_MIC=m -- 1.9.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2] MAINTAINERS: ibmvfc driver maintainer change
Change maintainer of ibmvfc driver to Tyrel Datwyler. Signed-off-by: Tyrel Datwyler tyr...@linux.vnet.ibm.com Cc: Nathan Fontenot nf...@linux.vnet.ibm.com Cc: Brian King brk...@linux.vnet.ibm.com --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index a646b94..f0d7593 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4761,7 +4761,7 @@ F:drivers/scsi/ibmvscsi/ibmvscsi* F: drivers/scsi/ibmvscsi/viosrp.h IBM Power Virtual FC Device Drivers -M: Brian King brk...@linux.vnet.ibm.com +M: Tyrel Datwyler tyr...@linux.vnet.ibm.com L: linux-s...@vger.kernel.org S: Supported F: drivers/scsi/ibmvscsi/ibmvfc* -- 1.7.12.2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 0/6] *** SUBJECT HERE ***
Hi Ben, Here is a short series of updates for PS3, none are critical. Please queue. These are based on v3.18. I can rebase to something else if you like. The first three patches are to have the kernel write the PS3 highmem info to the LV1 hypervisor registry so that the info will be available to second stage OS's loaded by petitboot/kexec. FreeBSD and some Linux derivatives use this feature. The next two patches fix some warnings emitted by sparse. The final patch refreshes ps3_defconfig and enables the highmem info write feature (CONFIG_PS3_REPOSITORY_WRITE=y) introduced in the first three patches. -Geoff The following changes since commit b2776bf7149bddd1f4161f14f79520f17fc1d71d: Linux 3.18 (2014-12-07 14:21:05 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/geoff/ps3-linux.git for-powerpc for you to fetch changes up to c9fc20b63c625d8d5c136f1e72d9930a6b0070df: powerpc/ps3: Update ps3_defconfig (2014-12-23 14:56:29 -0800) Geoff Levand (6): powerpc/ps3: Add empty repository highmem routines powerpc/ps3: Add ps3_mm_set_repository_highmem powerpc/ps3: Write highmem info to repository powerpc/ps3: Fix vuart sparse warnings powerpc/ps3: Fix sys-manager-core sparse warnings powerpc/ps3: Update ps3_defconfig arch/powerpc/configs/ps3_defconfig| 17 +++- arch/powerpc/platforms/ps3/mm.c | 77 --- arch/powerpc/platforms/ps3/platform.h | 13 ++ drivers/ps3/ps3-vuart.c | 5 --- drivers/ps3/sys-manager-core.c| 6 +-- drivers/ps3/vuart.h | 16 6 files changed, 83 insertions(+), 51 deletions(-) -- 1.9.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3/6] powerpc/ps3: Write highmem info to repository
Add calls to the ps3_mm_set_repository_highmem() routine when the ps3
r1 highmem region is either created or destroyed.
Signed-off-by: Geoff Levand ge...@infradead.org
---
arch/powerpc/platforms/ps3/mm.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/ps3/mm.c b/arch/powerpc/platforms/ps3/mm.c
index 04c1b93..b0f3466 100644
--- a/arch/powerpc/platforms/ps3/mm.c
+++ b/arch/powerpc/platforms/ps3/mm.c
@@ -329,6 +329,7 @@ static void ps3_mm_region_destroy(struct mem_region *r)
r-size = r-base = r-offset = 0;
map.total = map.rm.size;
}
+ ps3_mm_set_repository_highmem(NULL);
}
/**/
@@ -1218,8 +1219,12 @@ void __init ps3_mm_init(void)
/* Check if we got the highmem region from an earlier boot step */
- if (ps3_mm_get_repository_highmem(map.r1))
- ps3_mm_region_create(map.r1, map.total - map.rm.size);
+ if (ps3_mm_get_repository_highmem(map.r1)) {
+ result = ps3_mm_region_create(map.r1, map.total - map.rm.size);
+
+ if (!result)
+ ps3_mm_set_repository_highmem(map.r1);
+ }
/* correct map.total for the real total amount of memory we use */
map.total = map.rm.size + map.r1.size;
--
1.9.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/6] powerpc/ps3: Write highmem info to repository
On Tue, 2015-01-13 at 01:00 +, Geoff Levand wrote: Add calls to the ps3_mm_set_repository_highmem() routine when the ps3 r1 highmem region is either created or destroyed. What does this actually do? ie. from a user perspective. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/5] powerpc/powernv: Introduce pnv_pci_poll()
On Fri, Jan 09, 2015 at 10:43:04AM -0700, Bjorn Helgaas wrote:
On Thu, Dec 04, 2014 at 04:54:46PM +1100, Gavin Shan wrote:
We might not get some PCI slot information (e.g. power status)
immediately by OPAL API. Instead, opal_pci_poll() need to be called
for the required information.
The patch introduces pnv_pci_poll(), which bases on original
ioda_eeh_poll(), to cover the above case
Signed-off-by: Gavin Shan gws...@linux.vnet.ibm.com
Hi Gavin,
This patch doesn't apply cleanly on v3.19-rc1. Can you refresh this
series, please?
Bjorn, the patchset depends on PowerPC specific changes as follows. The
PowerPC specfic changes should go first before you can apply this patchset
cleanly. Also, all patches depend on the firwmare changes, which is waiting
for Ben's comments. So I guess it's not urgent to merge it for now.
PowerPC specific patchs:
https://patchwork.ozlabs.org/patch/417638/
https://patchwork.ozlabs.org/patch/417637/
https://patchwork.ozlabs.org/patch/417636/
Thanks,
Gavin
Bjorn
---
arch/powerpc/platforms/powernv/eeh-ioda.c | 28 ++--
arch/powerpc/platforms/powernv/pci.c | 19 +++
arch/powerpc/platforms/powernv/pci.h | 1 +
3 files changed, 22 insertions(+), 26 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/eeh-ioda.c
b/arch/powerpc/platforms/powernv/eeh-ioda.c
index cf38781..21fa033 100644
--- a/arch/powerpc/platforms/powernv/eeh-ioda.c
+++ b/arch/powerpc/platforms/powernv/eeh-ioda.c
@@ -490,24 +490,6 @@ static int ioda_eeh_get_state(struct eeh_pe *pe)
return ioda_eeh_get_pe_state(pe);
}
-static s64 ioda_eeh_poll(uint64_t id)
-{
-s64 rc = OPAL_HARDWARE;
-
-while (1) {
-rc = opal_pci_poll(id, NULL);
-if (rc = 0)
-break;
-
-if (system_state SYSTEM_RUNNING)
-udelay(1000 * rc);
-else
-msleep(rc);
-}
-
-return rc;
-}
-
int ioda_eeh_phb_reset(struct pci_controller *hose, int option)
{
struct pnv_phb *phb = hose-private_data;
@@ -536,10 +518,7 @@ int ioda_eeh_phb_reset(struct pci_controller *hose, int
option)
/* Issue reset and poll until it's completed */
rc = opal_pci_reset(phb-opal_id, scope, OPAL_ASSERT_RESET);
-if (rc 0)
-rc = ioda_eeh_poll(phb-opal_id);
-
-return (rc == OPAL_SUCCESS) ? 0 : -EIO;
+return pnv_pci_poll(phb-opal_id, rc, NULL);
}
static int __ioda_eeh_bridge_reset(struct pci_dev *dev, int option)
@@ -630,10 +609,7 @@ static int ioda_eeh_bridge_reset(struct pci_dev *dev,
int option)
phb = hose-private_data;
id |= (dev-bus-number 24) | (dev-devfn 16) | phb-opal_id;
rc = opal_pci_reset(id, scope, OPAL_ASSERT_RESET);
-if (rc 0)
-ioda_eeh_poll(id);
-
-return (rc == OPAL_SUCCESS) ? 0 : -EIO;
+return pnv_pci_poll(id, rc, NULL);
}
static int pnv_pci_dev_reset_type(struct pci_dev *pdev, void *data)
diff --git a/arch/powerpc/platforms/powernv/pci.c
b/arch/powerpc/platforms/powernv/pci.c
index 4b20f2c..6dc8ea9 100644
--- a/arch/powerpc/platforms/powernv/pci.c
+++ b/arch/powerpc/platforms/powernv/pci.c
@@ -45,6 +45,25 @@
#define cfg_dbg(fmt...) do { } while(0)
//#define cfg_dbg(fmt...) printk(fmt)
+int pnv_pci_poll(uint64_t id, int64_t rval, uint8_t *pval)
+{
+while (rval 0) {
+rval = opal_pci_poll(id, pval);
+if (rval == OPAL_SUCCESS pval)
+rval = opal_pci_poll(id, pval);
+
+if (rval = 0)
+break;
+
+if (system_state SYSTEM_RUNNING)
+udelay(1000 * rval);
+else
+msleep(rval);
+}
+
+return rval ? -EIO : 0;
+}
+
#ifdef CONFIG_PCI_MSI
static int pnv_setup_msi_irqs(struct pci_dev *pdev, int nvec, int type)
{
diff --git a/arch/powerpc/platforms/powernv/pci.h
b/arch/powerpc/platforms/powernv/pci.h
index 6c02ff8..396fe02 100644
--- a/arch/powerpc/platforms/powernv/pci.h
+++ b/arch/powerpc/platforms/powernv/pci.h
@@ -217,6 +217,7 @@ extern struct pci_ops pnv_pci_ops;
extern struct pnv_eeh_ops ioda_eeh_ops;
#endif
+int pnv_pci_poll(uint64_t id, int64_t rval, uint8_t *pval);
void pnv_pci_dump_phb_diag_data(struct pci_controller *hose,
unsigned char *log_buff);
int pnv_pci_cfg_read(struct device_node *dn,
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-pci in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 5/6] powerpc/ps3: Fix sys-manager-core sparse warnings
Fixes warnings like these:
drivers/ps3/sys-manager-core.c: error: symbol 'ps3_sys_manager_power_off'
redeclared with different type
Signed-off-by: Geoff Levand ge...@infradead.org
---
drivers/ps3/sys-manager-core.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/ps3/sys-manager-core.c b/drivers/ps3/sys-manager-core.c
index 0e41737..c429ffc 100644
--- a/drivers/ps3/sys-manager-core.c
+++ b/drivers/ps3/sys-manager-core.c
@@ -47,7 +47,7 @@ void ps3_sys_manager_register_ops(const struct
ps3_sys_manager_ops *ops)
}
EXPORT_SYMBOL_GPL(ps3_sys_manager_register_ops);
-void ps3_sys_manager_power_off(void)
+void __noreturn ps3_sys_manager_power_off(void)
{
if (ps3_sys_manager_ops.power_off)
ps3_sys_manager_ops.power_off(ps3_sys_manager_ops.dev);
@@ -55,7 +55,7 @@ void ps3_sys_manager_power_off(void)
ps3_sys_manager_halt();
}
-void ps3_sys_manager_restart(void)
+void __noreturn ps3_sys_manager_restart(void)
{
if (ps3_sys_manager_ops.restart)
ps3_sys_manager_ops.restart(ps3_sys_manager_ops.dev);
@@ -63,7 +63,7 @@ void ps3_sys_manager_restart(void)
ps3_sys_manager_halt();
}
-void ps3_sys_manager_halt(void)
+void __noreturn ps3_sys_manager_halt(void)
{
pr_emerg(System Halted, OK to turn off power\n);
local_irq_disable();
--
1.9.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 4/6] powerpc/ps3: Fix vuart sparse warnings
Fix sparse warnings like these:
drivers/ps3/ps3-vuart.c: warning: symbol 'ps3_vuart_disable_interrupt_tx' was
not declared. Should it be static?
Signed-off-by: Geoff Levand ge...@infradead.org
---
drivers/ps3/ps3-vuart.c | 5 -
drivers/ps3/vuart.h | 16
2 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/drivers/ps3/ps3-vuart.c b/drivers/ps3/ps3-vuart.c
index bc1e513..d6db822 100644
--- a/drivers/ps3/ps3-vuart.c
+++ b/drivers/ps3/ps3-vuart.c
@@ -151,11 +151,6 @@ static void __maybe_unused _dump_port_params(unsigned int
port_number,
#endif
}
-struct vuart_triggers {
- unsigned long rx;
- unsigned long tx;
-};
-
int ps3_vuart_get_triggers(struct ps3_system_bus_device *dev,
struct vuart_triggers *trig)
{
diff --git a/drivers/ps3/vuart.h b/drivers/ps3/vuart.h
index eb7f6d9..23358b7 100644
--- a/drivers/ps3/vuart.h
+++ b/drivers/ps3/vuart.h
@@ -82,4 +82,20 @@ void ps3_vuart_cancel_async(struct ps3_system_bus_device
*dev);
void ps3_vuart_clear_rx_bytes(struct ps3_system_bus_device *dev,
unsigned int bytes);
+struct vuart_triggers {
+ unsigned long rx;
+ unsigned long tx;
+};
+
+int ps3_vuart_get_triggers(struct ps3_system_bus_device *dev,
+ struct vuart_triggers *trig);
+int ps3_vuart_set_triggers(struct ps3_system_bus_device *dev, unsigned int tx,
+ unsigned int rx);
+int ps3_vuart_enable_interrupt_tx(struct ps3_system_bus_device *dev);
+int ps3_vuart_disable_interrupt_tx(struct ps3_system_bus_device *dev);
+int ps3_vuart_enable_interrupt_rx(struct ps3_system_bus_device *dev);
+int ps3_vuart_disable_interrupt_rx(struct ps3_system_bus_device *dev);
+int ps3_vuart_enable_interrupt_disconnect(struct ps3_system_bus_device *dev);
+int ps3_vuart_disable_interrupt_disconnect(struct ps3_system_bus_device *dev);
+
#endif
--
1.9.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Reword the returning from prom_init message
On Mon, 2015-01-12 at 11:27 -0600, Paul Clarke wrote: On 01/12/2015 03:48 AM, Michael Ellerman wrote: We get way too many bug reports that say the kernel is hung in prom_init, which stems from the fact that the last piece of output people see is returning from prom_init. The kernel is almost never hung in prom_init(), it's just that it's crashed somewhere after prom_init() but prior to the console coming up. The existing message should give a clue to that, ie. returning from indicates that prom_init() has finished, but it doesn't seem to work. Let's try something different. This prints: Calling quiesce... Shutting down Open Firmware, booting Linux via __start() ... Which hopefully makes it clear that prom_init() is not the problem, and although __start() probably isn't either, it's at least the right place to begin looking. I'm very much in favor of anything that increases usability or decreases confusion. I worry about confusion caused by any phrase that begins Shutting down.. Even if accurate, I wonder if something more positive that indicates that, at least at this point, things are continuing to proceed along would be preferred. True. Perhaps something like Transferring control from Open Firmware to kernel (via __start) Yeah, that's not quite accurate either :) Linux already has control, but up until that point it is running alongside OF and using its services. After prom_init() returns we take over the machine entirely. Maybe Leaving Open Firmware, booting Linux ... Or just Booting Linux (Do we know for certain that what is about to be invoked is Linux per-se, or can it be something else that has a __start?) Yes it's Linux. Although we treat prom_init() as a separate thing, it's just linked into the regular kernel binary. So the transfer here is really just a function call. But it signifies a switch from code that runs alongside Open Firmware (prom_init()), to code that doesn't (the rest of the kernel). We have talked about actually linking them separately but we've never bothered, it wouldn't buy us much. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/6] powerpc/ps3: Add empty repository highmem routines
To avoid the need for preprocessor conditionals in C source files add a set of
empty inline repository highmem write routines to platform.h that are used when
CONFIG_PS3_REPOSITORY_WRITE is not defined.
Signed-off-by: Geoff Levand ge...@infradead.org
---
arch/powerpc/platforms/ps3/platform.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/powerpc/platforms/ps3/platform.h
b/arch/powerpc/platforms/ps3/platform.h
index d71329a..1809cfc 100644
--- a/arch/powerpc/platforms/ps3/platform.h
+++ b/arch/powerpc/platforms/ps3/platform.h
@@ -196,6 +196,7 @@ int ps3_repository_read_highmem_size(unsigned int
region_index,
int ps3_repository_read_highmem_info(unsigned int region_index,
u64 *highmem_base, u64 *highmem_size);
+#if defined (CONFIG_PS3_REPOSITORY_WRITE)
int ps3_repository_write_highmem_region_count(unsigned int region_count);
int ps3_repository_write_highmem_base(unsigned int region_index,
u64 highmem_base);
@@ -204,6 +205,18 @@ int ps3_repository_write_highmem_size(unsigned int
region_index,
int ps3_repository_write_highmem_info(unsigned int region_index,
u64 highmem_base, u64 highmem_size);
int ps3_repository_delete_highmem_info(unsigned int region_index);
+#else
+static inline int ps3_repository_write_highmem_region_count(
+ unsigned int region_count) {return 0;}
+static inline int ps3_repository_write_highmem_base(unsigned int region_index,
+ u64 highmem_base) {return 0;}
+static inline int ps3_repository_write_highmem_size(unsigned int region_index,
+ u64 highmem_size) {return 0;}
+static inline int ps3_repository_write_highmem_info(unsigned int region_index,
+ u64 highmem_base, u64 highmem_size) {return 0;}
+static inline int ps3_repository_delete_highmem_info(unsigned int region_index)
+ {return 0;}
+#endif
/* repository pme info */
--
1.9.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] KVM: PPC: BOOK3S: HV: Add helpers for lock/unlock hpte
Hi,
Any update on this patch. We could drop patch 3. Any feedback on 1 and 2
?.
-aneesh
Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com writes:
This patch adds helper routine for lock and unlock hpte and use
the same for rest of the code. We don't change any locking rules in this
patch. In the next patch we switch some of the unlock usage to use
the api with barrier and also document the usage without barriers.
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/kvm_book3s_64.h | 14 ++
arch/powerpc/kvm/book3s_64_mmu_hv.c | 25 ++---
arch/powerpc/kvm/book3s_hv_rm_mmu.c | 27 ++-
3 files changed, 34 insertions(+), 32 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_book3s_64.h
b/arch/powerpc/include/asm/kvm_book3s_64.h
index 0aa817933e6a..ec9fb6085843 100644
--- a/arch/powerpc/include/asm/kvm_book3s_64.h
+++ b/arch/powerpc/include/asm/kvm_book3s_64.h
@@ -86,6 +86,20 @@ static inline long try_lock_hpte(__be64 *hpte, unsigned
long bits)
return old == 0;
}
+static inline void unlock_hpte(__be64 *hpte, unsigned long hpte_v)
+{
+ hpte_v = ~HPTE_V_HVLOCK;
+ asm volatile(PPC_RELEASE_BARRIER : : : memory);
+ hpte[0] = cpu_to_be64(hpte_v);
+}
+
+/* Without barrier */
+static inline void __unlock_hpte(__be64 *hpte, unsigned long hpte_v)
+{
+ hpte_v = ~HPTE_V_HVLOCK;
+ hpte[0] = cpu_to_be64(hpte_v);
+}
+
static inline int __hpte_actual_psize(unsigned int lp, int psize)
{
int i, shift;
diff --git a/arch/powerpc/kvm/book3s_64_mmu_hv.c
b/arch/powerpc/kvm/book3s_64_mmu_hv.c
index cebb86bc4a37..5ea4b2b6a157 100644
--- a/arch/powerpc/kvm/book3s_64_mmu_hv.c
+++ b/arch/powerpc/kvm/book3s_64_mmu_hv.c
@@ -475,9 +475,7 @@ static int kvmppc_mmu_book3s_64_hv_xlate(struct kvm_vcpu
*vcpu, gva_t eaddr,
v = be64_to_cpu(hptep[0]) ~HPTE_V_HVLOCK;
gr = kvm-arch.revmap[index].guest_rpte;
- /* Unlock the HPTE */
- asm volatile(lwsync : : : memory);
- hptep[0] = cpu_to_be64(v);
+ unlock_hpte(hptep, v);
preempt_enable();
gpte-eaddr = eaddr;
@@ -606,8 +604,7 @@ int kvmppc_book3s_hv_page_fault(struct kvm_run *run,
struct kvm_vcpu *vcpu,
hpte[0] = be64_to_cpu(hptep[0]) ~HPTE_V_HVLOCK;
hpte[1] = be64_to_cpu(hptep[1]);
hpte[2] = r = rev-guest_rpte;
- asm volatile(lwsync : : : memory);
- hptep[0] = cpu_to_be64(hpte[0]);
+ unlock_hpte(hptep, hpte[0]);
preempt_enable();
if (hpte[0] != vcpu-arch.pgfault_hpte[0] ||
@@ -758,7 +755,7 @@ int kvmppc_book3s_hv_page_fault(struct kvm_run *run,
struct kvm_vcpu *vcpu,
hptep[1] = cpu_to_be64(r);
eieio();
- hptep[0] = cpu_to_be64(hpte[0]);
+ __unlock_hpte(hptep, hpte[0]);
asm volatile(ptesync : : : memory);
preempt_enable();
if (page hpte_is_writable(r))
@@ -777,7 +774,7 @@ int kvmppc_book3s_hv_page_fault(struct kvm_run *run,
struct kvm_vcpu *vcpu,
return ret;
out_unlock:
- hptep[0] = ~cpu_to_be64(HPTE_V_HVLOCK);
+ __unlock_hpte(hptep, be64_to_cpu(hptep[0]));
preempt_enable();
goto out_put;
}
@@ -907,7 +904,7 @@ static int kvm_unmap_rmapp(struct kvm *kvm, unsigned long
*rmapp,
}
}
unlock_rmap(rmapp);
- hptep[0] = ~cpu_to_be64(HPTE_V_HVLOCK);
+ __unlock_hpte(hptep, be64_to_cpu(hptep[0]));
}
return 0;
}
@@ -995,7 +992,7 @@ static int kvm_age_rmapp(struct kvm *kvm, unsigned long
*rmapp,
}
ret = 1;
}
- hptep[0] = ~cpu_to_be64(HPTE_V_HVLOCK);
+ __unlock_hpte(hptep, be64_to_cpu(hptep[0]));
} while ((i = j) != head);
unlock_rmap(rmapp);
@@ -1118,8 +1115,7 @@ static int kvm_test_clear_dirty_npages(struct kvm *kvm,
unsigned long *rmapp)
/* Now check and modify the HPTE */
if (!(hptep[0] cpu_to_be64(HPTE_V_VALID))) {
- /* unlock and continue */
- hptep[0] = ~cpu_to_be64(HPTE_V_HVLOCK);
+ __unlock_hpte(hptep, be64_to_cpu(hptep[0]));
continue;
}
/* need to make it temporarily absent so C is stable */
@@ -1139,9 +1135,9 @@ static int kvm_test_clear_dirty_npages(struct kvm *kvm,
unsigned long *rmapp)
npages_dirty = n;
eieio();
}
- v = ~(HPTE_V_ABSENT | HPTE_V_HVLOCK);
+ v = ~HPTE_V_ABSENT;
v |= HPTE_V_VALID;
- hptep[0] = cpu_to_be64(v);
+ __unlock_hpte(hptep, v);
} while ((i = j) != head);
unlock_rmap(rmapp);
@@ -1379,8 +1375,7 @@ static long record_hpte(unsigned long flags, __be64
*hptp,
Re: linux-next: Tree for Jan 12 (build failures: m68k, ppc)
On Mon, Jan 12, 2015 at 05:27:08PM +0100, Geert Uytterhoeven wrote: On Mon, Jan 12, 2015 at 5:24 PM, Guenter Roeck li...@roeck-us.net wrote: On Mon, Jan 12, 2015 at 06:03:22PM +1100, Stephen Rothwell wrote: Hi all, Changes since 20150109: The usb-gadget-fixes tree gained a conflict against the usb.current tree. The net-next tree gained a build failure for which I reverted a commit. The pinctrl tree gained a build failure so I used the version from next-20150109. The akpm tree lost a few patches that turned up elsewhere. Non-merge commits (relative to Linus' tree): 2202 2272 files changed, 69868 insertions(+), 38441 deletions(-) Build failures, seen since next-20150109: m68k:allmodconfig powerpc:ppc6xx_defconfig Due to: ERROR: __get_user_bad [drivers/gpu/drm/drm.ko] undefined! make[1]: *** [__modpost] Error 1 Caused by commit d34f20d6e2f (drm: Atomic modeset ioctl). Yeah, it needs a get_user() that supports 64-bit data. Hi Geert, I assume you mean m68k, where 64 bit support for get_user has been disabled. The problem on powerpc is different though: __get_user_nocheck() and __get_user_check() use unsigned long __gu_val; followed by __get_user_size(__gu_val, __gu_addr, (size), __gu_err); __get_user_size() fails in if (size sizeof(x)) (x) = __get_user_bad(); Presumably unsigned long is 32 bit on 32 bit powerpc, not 64 bit. Overall, the explicit 64-bit use of get_user() seems to be quite unusual. Thanks, Guenter ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Reword the returning from prom_init message
On 01/12/2015 03:48 AM, Michael Ellerman wrote: We get way too many bug reports that say the kernel is hung in prom_init, which stems from the fact that the last piece of output people see is returning from prom_init. The kernel is almost never hung in prom_init(), it's just that it's crashed somewhere after prom_init() but prior to the console coming up. The existing message should give a clue to that, ie. returning from indicates that prom_init() has finished, but it doesn't seem to work. Let's try something different. This prints: Calling quiesce... Shutting down Open Firmware, booting Linux via __start() ... Which hopefully makes it clear that prom_init() is not the problem, and although __start() probably isn't either, it's at least the right place to begin looking. I'm very much in favor of anything that increases usability or decreases confusion. I worry about confusion caused by any phrase that begins Shutting down.. Even if accurate, I wonder if something more positive that indicates that, at least at this point, things are continuing to proceed along would be preferred. Perhaps something like Transferring control from Open Firmware to kernel (via __start) (Do we know for certain that what is about to be invoked is Linux per-se, or can it be something else that has a __start?) PC ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3.16.y-ckt 175/216] powerpc/powernv: Switch off MMU before entering nap/sleep/rvwinkle mode
3.16.7-ckt4 -stable review patch. If anyone has any objections, please let me know. -- From: Paul Mackerras pau...@samba.org commit 8117ac6a6c2fa0f847ff6a21a1f32c8d2c8501d0 upstream. Currently, when going idle, we set the flag indicating that we are in nap mode (paca-kvm_hstate.hwthread_state) and then execute the nap (or sleep or rvwinkle) instruction, all with the MMU on. This is bad for two reasons: (a) the architecture specifies that those instructions must be executed with the MMU off, and in fact with only the SF, HV, ME and possibly RI bits set, and (b) this introduces a race, because as soon as we set the flag, another thread can switch the MMU to a guest context. If the race is lost, this thread will typically start looping on relocation-on ISIs at 0xc...4400. This fixes it by setting the MSR as required by the architecture before setting the flag or executing the nap/sleep/rvwinkle instruction. [ shre...@linux.vnet.ibm.com: Edited to handle LE ] Signed-off-by: Paul Mackerras pau...@samba.org Signed-off-by: Shreyas B. Prabhu shre...@linux.vnet.ibm.com Cc: Benjamin Herrenschmidt b...@kernel.crashing.org Cc: Michael Ellerman m...@ellerman.id.au Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by: Michael Ellerman m...@ellerman.id.au Signed-off-by: Luis Henriques luis.henriq...@canonical.com --- arch/powerpc/include/asm/reg.h| 2 ++ arch/powerpc/kernel/idle_power7.S | 18 +- 2 files changed, 19 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h index bffd89d27301..e73cdadab785 100644 --- a/arch/powerpc/include/asm/reg.h +++ b/arch/powerpc/include/asm/reg.h @@ -118,8 +118,10 @@ #define __MSR (MSR_ME | MSR_RI | MSR_IR | MSR_DR | MSR_ISF |MSR_HV) #ifdef __BIG_ENDIAN__ #define MSR_ __MSR +#define MSR_IDLE (MSR_ME | MSR_SF | MSR_HV) #else #define MSR_ (__MSR | MSR_LE) +#define MSR_IDLE (MSR_ME | MSR_SF | MSR_HV | MSR_LE) #endif #define MSR_KERNEL (MSR_ | MSR_64BIT) #define MSR_USER32 (MSR_ | MSR_PR | MSR_EE) diff --git a/arch/powerpc/kernel/idle_power7.S b/arch/powerpc/kernel/idle_power7.S index 5cf3d367190d..a29f5b0f9d3e 100644 --- a/arch/powerpc/kernel/idle_power7.S +++ b/arch/powerpc/kernel/idle_power7.S @@ -101,7 +101,23 @@ _GLOBAL(power7_powersave_common) std r9,_MSR(r1) std r1,PACAR1(r13) -_GLOBAL(power7_enter_nap_mode) + /* +* Go to real mode to do the nap, as required by the architecture. +* Also, we need to be in real mode before setting hwthread_state, +* because as soon as we do that, another thread can switch +* the MMU context to the guest. +*/ + LOAD_REG_IMMEDIATE(r5, MSR_IDLE) + li r6, MSR_RI + andcr6, r9, r6 + LOAD_REG_ADDR(r7, power7_enter_nap_mode) + mtmsrd r6, 1 /* clear RI before setting SRR0/1 */ + mtspr SPRN_SRR0, r7 + mtspr SPRN_SRR1, r5 + rfid + + .globl power7_enter_nap_mode +power7_enter_nap_mode: #ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE /* Tell KVM we're napping */ li r4,KVM_HWTHREAD_IN_NAP -- 2.1.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
