* Re: [PATCH] MDIO: FSL_PQ_MDIO: Fix bug on incorrect offset of tbipa register
From: Oded Gabbay @ 2013-06-12 13:09 UTC (permalink / raw)
To: Timur Tabi
Cc: stef.van.os, bigeasy, Dongsheng.Wang, paulus, netdev,
linuxppc-dev, davem, linux-kernel, B38951
In-Reply-To: <51B871CB.1090808@tabi.org>
Oded Gabbay wrote:
>> Note: This patch may break MDIO functionallity of some old
>> Freescale's SoC
>> until Freescale will fix their device tree files. Basically, every
>> device tree
>> which contains an mdio device that is compatible to "fsl,gianfar-tbi"
>> should be
>> examined.
>
> On 06/12/2013 04:04 PM, Timur Tabi wrote:
> I haven't had a chance to review the patch in detail, but I can tell
> you that breaking compatibility with older device trees is
> unacceptable. You need to add some code, even if it's an ugly hack,
> to support those trees.
>
I generally agree with this statement except that without this patch,
almost ALL of Freescale's SoC that uses "fsl,gianfar-tbi" are broken,
including the older ones. At least this patch fixes some of the device
trees. Because I'm not working at Freescale, I have a very limited
access to a few SoC which I could test this patch on. I think it is
Freescale's responsibility to release a complementary patch to fix the
rest of the SoC device trees.
Oded
^ permalink raw reply
* [PATCH] MDIO: FSL_PQ_MDIO: Fix bug on incorrect offset of tbipa register
From: Oded Gabbay @ 2013-06-12 12:47 UTC (permalink / raw)
To: benh, paulus, leoli, galak, B38951, Dongsheng.Wang, bigeasy,
stef.van.os, timur, davem, ogabbay
Cc: netdev, linuxppc-dev, linux-kernel
This patch fixes a bug in the fsl_pq_mdio.c module and in relevant device-tree
files regarding the correct offset of the tbipa register in the eTSEC
controller in some of Freescale's PQ3 and QorIQ SoC.
The bug happens when the mdio in the device tree is configured to be compatible
to "fsl,gianfar-tbi". Because the mdio device in the device tree points to
addresses 25520, 26520 or 27520 (depends on the controller ID), the variable
priv->map at function fsl_pq_mdio_probe, points to that address. However,
later in the function there is a write to register tbipa that is actually
located at 25030, 26030 or 27030. Because the correct address is not io mapped,
the contents are written to a different register in the controller.
The fix sets the address of the mdio device to start at 25000, 26000 or 27000
and changes the mii_offset field to 0x520 in the relevant entry
(fsl,gianfar-tbi) of the fsl_pq_mdio_match array.
Note: This patch may break MDIO functionallity of some old Freescale's SoC
until Freescale will fix their device tree files. Basically, every device tree
which contains an mdio device that is compatible to "fsl,gianfar-tbi" should be
examined.
Signed-off-by: Oded Gabbay <ogabbay@advaoptical.com>
---
arch/powerpc/boot/dts/fsl/pq3-etsec1-1.dtsi | 4 ++--
arch/powerpc/boot/dts/fsl/pq3-etsec1-2.dtsi | 4 ++--
arch/powerpc/boot/dts/fsl/pq3-etsec1-3.dtsi | 4 ++--
arch/powerpc/boot/dts/ge_imp3a.dts | 4 ++--
arch/powerpc/boot/dts/mpc8536ds.dtsi | 4 ++--
arch/powerpc/boot/dts/mpc8544ds.dtsi | 2 +-
arch/powerpc/boot/dts/mpc8548cds.dtsi | 6 +++---
arch/powerpc/boot/dts/mpc8568mds.dts | 2 +-
arch/powerpc/boot/dts/mpc8572ds.dtsi | 6 +++---
arch/powerpc/boot/dts/mpc8572ds_camp_core0.dts | 4 ++--
arch/powerpc/boot/dts/mpc8572ds_camp_core1.dts | 2 +-
arch/powerpc/boot/dts/p2020ds.dtsi | 4 ++--
arch/powerpc/boot/dts/p2020rdb-pc.dtsi | 4 ++--
arch/powerpc/boot/dts/p2020rdb.dts | 4 ++--
arch/powerpc/boot/dts/ppa8548.dts | 6 +++---
drivers/net/ethernet/freescale/fsl_pq_mdio.c | 2 +-
16 files changed, 31 insertions(+), 31 deletions(-)
diff --git a/arch/powerpc/boot/dts/fsl/pq3-etsec1-1.dtsi b/arch/powerpc/boot/dts/fsl/pq3-etsec1-1.dtsi
index 96693b4..d38bf63 100644
--- a/arch/powerpc/boot/dts/fsl/pq3-etsec1-1.dtsi
+++ b/arch/powerpc/boot/dts/fsl/pq3-etsec1-1.dtsi
@@ -46,9 +46,9 @@ ethernet@25000 {
interrupts = <35 2 0 0 36 2 0 0 40 2 0 0>;
};
-mdio@25520 {
+mdio@25000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,gianfar-tbi";
- reg = <0x25520 0x20>;
+ reg = <0x25000 0x1000>;
};
diff --git a/arch/powerpc/boot/dts/fsl/pq3-etsec1-2.dtsi b/arch/powerpc/boot/dts/fsl/pq3-etsec1-2.dtsi
index 6b3fab1..6290b49 100644
--- a/arch/powerpc/boot/dts/fsl/pq3-etsec1-2.dtsi
+++ b/arch/powerpc/boot/dts/fsl/pq3-etsec1-2.dtsi
@@ -46,9 +46,9 @@ ethernet@26000 {
interrupts = <31 2 0 0 32 2 0 0 33 2 0 0>;
};
-mdio@26520 {
+mdio@26000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,gianfar-tbi";
- reg = <0x26520 0x20>;
+ reg = <0x26000 0x1000>;
};
diff --git a/arch/powerpc/boot/dts/fsl/pq3-etsec1-3.dtsi b/arch/powerpc/boot/dts/fsl/pq3-etsec1-3.dtsi
index 0da592d..5296811 100644
--- a/arch/powerpc/boot/dts/fsl/pq3-etsec1-3.dtsi
+++ b/arch/powerpc/boot/dts/fsl/pq3-etsec1-3.dtsi
@@ -46,9 +46,9 @@ ethernet@27000 {
interrupts = <37 2 0 0 38 2 0 0 39 2 0 0>;
};
-mdio@27520 {
+mdio@27000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,gianfar-tbi";
- reg = <0x27520 0x20>;
+ reg = <0x27000 0x1000>;
};
diff --git a/arch/powerpc/boot/dts/ge_imp3a.dts b/arch/powerpc/boot/dts/ge_imp3a.dts
index fefae41..49d9b4e 100644
--- a/arch/powerpc/boot/dts/ge_imp3a.dts
+++ b/arch/powerpc/boot/dts/ge_imp3a.dts
@@ -174,14 +174,14 @@
};
};
- mdio@25520 {
+ mdio@25000 {
tbi1: tbi-phy@11 {
reg = <0x11>;
device_type = "tbi-phy";
};
};
- mdio@26520 {
+ mdio@26000 {
status = "disabled";
};
diff --git a/arch/powerpc/boot/dts/mpc8536ds.dtsi b/arch/powerpc/boot/dts/mpc8536ds.dtsi
index 7c3dde8..c4df5a1 100644
--- a/arch/powerpc/boot/dts/mpc8536ds.dtsi
+++ b/arch/powerpc/boot/dts/mpc8536ds.dtsi
@@ -227,11 +227,11 @@
phy-connection-type = "rgmii-id";
};
- mdio@26520 {
+ mdio@26000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,gianfar-tbi";
- reg = <0x26520 0x20>;
+ reg = <0x26000 0x1000>;
tbi1: tbi-phy@11 {
reg = <0x11>;
diff --git a/arch/powerpc/boot/dts/mpc8544ds.dtsi b/arch/powerpc/boot/dts/mpc8544ds.dtsi
index b219d03..ba051b2 100644
--- a/arch/powerpc/boot/dts/mpc8544ds.dtsi
+++ b/arch/powerpc/boot/dts/mpc8544ds.dtsi
@@ -111,7 +111,7 @@
phy-connection-type = "rgmii-id";
};
- mdio@26520 {
+ mdio@26000 {
tbi1: tbi-phy@11 {
reg = <0x11>;
device_type = "tbi-phy";
diff --git a/arch/powerpc/boot/dts/mpc8548cds.dtsi b/arch/powerpc/boot/dts/mpc8548cds.dtsi
index c61f525..85da565 100644
--- a/arch/powerpc/boot/dts/mpc8548cds.dtsi
+++ b/arch/powerpc/boot/dts/mpc8548cds.dtsi
@@ -137,7 +137,7 @@
phy-handle = <&phy1>;
};
- mdio@25520 {
+ mdio@25000 {
tbi1: tbi-phy@11 {
reg = <0x11>;
device_type = "tbi-phy";
@@ -149,7 +149,7 @@
phy-handle = <&phy2>;
};
- mdio@26520 {
+ mdio@26000 {
tbi2: tbi-phy@11 {
reg = <0x11>;
device_type = "tbi-phy";
@@ -161,7 +161,7 @@
phy-handle = <&phy3>;
};
- mdio@27520 {
+ mdio@27000 {
tbi3: tbi-phy@11 {
reg = <0x11>;
device_type = "tbi-phy";
diff --git a/arch/powerpc/boot/dts/mpc8568mds.dts b/arch/powerpc/boot/dts/mpc8568mds.dts
index 09598bb..30cd8b8 100644
--- a/arch/powerpc/boot/dts/mpc8568mds.dts
+++ b/arch/powerpc/boot/dts/mpc8568mds.dts
@@ -120,7 +120,7 @@
sleep = <&pmc 0x00000040>;
};
- mdio@25520 {
+ mdio@25000 {
tbi1: tbi-phy@11 {
reg = <0x11>;
device_type = "tbi-phy";
diff --git a/arch/powerpc/boot/dts/mpc8572ds.dtsi b/arch/powerpc/boot/dts/mpc8572ds.dtsi
index 357490b..c82a800 100644
--- a/arch/powerpc/boot/dts/mpc8572ds.dtsi
+++ b/arch/powerpc/boot/dts/mpc8572ds.dtsi
@@ -208,7 +208,7 @@
};
- mdio@25520 {
+ mdio@25000 {
tbi1: tbi-phy@11 {
reg = <0x11>;
device_type = "tbi-phy";
@@ -221,7 +221,7 @@
phy-connection-type = "rgmii-id";
};
- mdio@26520 {
+ mdio@26000 {
tbi2: tbi-phy@11 {
reg = <0x11>;
device_type = "tbi-phy";
@@ -234,7 +234,7 @@
phy-connection-type = "rgmii-id";
};
- mdio@27520 {
+ mdio@27000 {
tbi3: tbi-phy@11 {
reg = <0x11>;
device_type = "tbi-phy";
diff --git a/arch/powerpc/boot/dts/mpc8572ds_camp_core0.dts b/arch/powerpc/boot/dts/mpc8572ds_camp_core0.dts
index ef9ef56..5dae410 100644
--- a/arch/powerpc/boot/dts/mpc8572ds_camp_core0.dts
+++ b/arch/powerpc/boot/dts/mpc8572ds_camp_core0.dts
@@ -47,13 +47,13 @@
ethernet@26000 {
status = "disabled";
};
- mdio@26520 {
+ mdio@26000 {
status = "disabled";
};
ethernet@27000 {
status = "disabled";
};
- mdio@27520 {
+ mdio@27000 {
status = "disabled";
};
pic@40000 {
diff --git a/arch/powerpc/boot/dts/mpc8572ds_camp_core1.dts b/arch/powerpc/boot/dts/mpc8572ds_camp_core1.dts
index 24564ee..706e782 100644
--- a/arch/powerpc/boot/dts/mpc8572ds_camp_core1.dts
+++ b/arch/powerpc/boot/dts/mpc8572ds_camp_core1.dts
@@ -73,7 +73,7 @@
ethernet@25000 {
status = "disabled";
};
- mdio@25520 {
+ mdio@25000 {
status = "disabled";
};
crypto@30000 {
diff --git a/arch/powerpc/boot/dts/p2020ds.dtsi b/arch/powerpc/boot/dts/p2020ds.dtsi
index e699cf9..1e9001c 100644
--- a/arch/powerpc/boot/dts/p2020ds.dtsi
+++ b/arch/powerpc/boot/dts/p2020ds.dtsi
@@ -167,14 +167,14 @@
};
- mdio@25520 {
+ mdio@25000 {
tbi1: tbi-phy@11 {
reg = <0x11>;
device_type = "tbi-phy";
};
};
- mdio@26520 {
+ mdio@26000 {
tbi2: tbi-phy@11 {
reg = <0x11>;
device_type = "tbi-phy";
diff --git a/arch/powerpc/boot/dts/p2020rdb-pc.dtsi b/arch/powerpc/boot/dts/p2020rdb-pc.dtsi
index c21d1c7..994cb4c 100644
--- a/arch/powerpc/boot/dts/p2020rdb-pc.dtsi
+++ b/arch/powerpc/boot/dts/p2020rdb-pc.dtsi
@@ -203,14 +203,14 @@
};
};
- mdio@25520 {
+ mdio@25000 {
tbi0: tbi-phy@11 {
reg = <0x11>;
device_type = "tbi-phy";
};
};
- mdio@26520 {
+ mdio@26000 {
status = "disabled";
};
diff --git a/arch/powerpc/boot/dts/p2020rdb.dts b/arch/powerpc/boot/dts/p2020rdb.dts
index 4d52bce..b6f50e1 100644
--- a/arch/powerpc/boot/dts/p2020rdb.dts
+++ b/arch/powerpc/boot/dts/p2020rdb.dts
@@ -215,14 +215,14 @@
};
};
- mdio@25520 {
+ mdio@25000 {
tbi0: tbi-phy@11 {
reg = <0x11>;
device_type = "tbi-phy";
};
};
- mdio@26520 {
+ mdio@26000 {
status = "disabled";
};
diff --git a/arch/powerpc/boot/dts/ppa8548.dts b/arch/powerpc/boot/dts/ppa8548.dts
index f97ecee..2117927 100644
--- a/arch/powerpc/boot/dts/ppa8548.dts
+++ b/arch/powerpc/boot/dts/ppa8548.dts
@@ -128,7 +128,7 @@
phy-handle = <&phy0>;
};
- mdio@25520 {
+ mdio@25000 {
tbi1: tbi-phy@11 {
reg = <0x11>;
device_type = "tbi-phy";
@@ -140,7 +140,7 @@
phy-handle = <&phy1>;
};
- mdio@26520 {
+ mdio@26000 {
tbi2: tbi-phy@11 {
reg = <0x11>;
device_type = "tbi-phy";
@@ -151,7 +151,7 @@
status = "disabled";
};
- mdio@27520 {
+ mdio@27000 {
tbi3: tbi-phy@11 {
reg = <0x11>;
device_type = "tbi-phy";
diff --git a/drivers/net/ethernet/freescale/fsl_pq_mdio.c b/drivers/net/ethernet/freescale/fsl_pq_mdio.c
index c93a056..4228c4e 100644
--- a/drivers/net/ethernet/freescale/fsl_pq_mdio.c
+++ b/drivers/net/ethernet/freescale/fsl_pq_mdio.c
@@ -288,7 +288,7 @@ static struct of_device_id fsl_pq_mdio_match[] = {
{
.compatible = "fsl,gianfar-tbi",
.data = &(struct fsl_pq_mdio_data) {
- .mii_offset = 0,
+ .mii_offset = 0x520,
.get_tbipa = get_gfar_tbipa,
},
},
--
1.8.3.1
^ permalink raw reply related
* Re: [v3][KVM][PATCH 1/1] kvm:ppc: control doorbell exception with CONFIG_PPC_DOORBELL
From: Alexander Graf @ 2013-06-12 13:18 UTC (permalink / raw)
To: Tiejun Chen; +Cc: scottwood, linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <1368410445-4969-1-git-send-email-tiejun.chen@windriver.com>
On 13.05.2013, at 04:00, Tiejun Chen wrote:
> We can only use CONFIG_PPC_DOORBELL to control whether
> the doorbell exception should be enabled.
>
> Signed-off-by: Tiejun Chen <tiejun.chen@windriver.com>
Thanks, applied to kvm-ppc-queue with a slightly changed patch description:
KVM: PPC: Guard doorbell exception with CONFIG_PPC_DOORBELL
Availablity of the doorbell_exception function is guarded by
CONFIG_PPC_DOORBELL. Use the same define to guard our caller
of it.
Signed-off-by: Tiejun Chen <tiejun.chen@windriver.com>
[agraf: improve patch description]
Signed-off-by: Alexander Graf <agraf@suse.de>
^ permalink raw reply
* Re: [PATCH] MDIO: FSL_PQ_MDIO: Fix bug on incorrect offset of tbipa register
From: Sebastian Andrzej Siewior @ 2013-06-12 15:08 UTC (permalink / raw)
To: Oded Gabbay
Cc: stef.van.os, timur, Dongsheng.Wang, paulus, netdev, linuxppc-dev,
davem, linux-kernel, B38951
In-Reply-To: <1371041258-15298-1-git-send-email-ogabbay@advaoptical.com>
On 06/12/2013 02:47 PM, Oded Gabbay wrote:
> This patch fixes a bug in the fsl_pq_mdio.c module and in relevant device-tree
> files regarding the correct offset of the tbipa register in the eTSEC
> controller in some of Freescale's PQ3 and QorIQ SoC.
> The bug happens when the mdio in the device tree is configured to be compatible
> to "fsl,gianfar-tbi". Because the mdio device in the device tree points to
> addresses 25520, 26520 or 27520 (depends on the controller ID), the variable
> priv->map at function fsl_pq_mdio_probe, points to that address. However,
> later in the function there is a write to register tbipa that is actually
> located at 25030, 26030 or 27030. Because the correct address is not io mapped,
> the contents are written to a different register in the controller.
> The fix sets the address of the mdio device to start at 25000, 26000 or 27000
> and changes the mii_offset field to 0x520 in the relevant entry
> (fsl,gianfar-tbi) of the fsl_pq_mdio_match array.
>
> Note: This patch may break MDIO functionallity of some old Freescale's SoC
> until Freescale will fix their device tree files. Basically, every device tree
> which contains an mdio device that is compatible to "fsl,gianfar-tbi" should be
> examined.
Not as is.
Please add a check for the original address. If it has 0x520 at the end
print a warning and fix it up. Please add to the patch description
which register is modified instead if this patch is not applied.
Depending on how critical this it might has to go stable.
Sebastian
^ permalink raw reply
* [PATCH REPOST] dtc: ensure #line directives don't consume data from the next line
From: Stephen Warren @ 2013-06-12 16:18 UTC (permalink / raw)
To: Grant Likely, Rob Herring
Cc: Michal Marek, jdl, Stephen Warren, Ian Campbell, linux-kbuild,
devicetree-discuss, linux-kernel, linuxppc-dev
From: Stephen Warren <swarren@nvidia.com>
Previously, the #line parsing regex ended with ({WS}+[0-9]+)?. The {WS}
could match line-break characters. If the #line directive did not contain
the optional flags field at the end, this could cause any integer data on
the next line to be consumed as part of the #line directive parsing. This
could cause syntax errors (i.e. #line parsing consuming the leading 0
from a hex literal 0x1234, leaving x1234 to be parsed as cell data,
which is a syntax error), or invalid compilation results (i.e. simply
consuming literal 1234 as part of the #line processing, thus removing it
from the cell data).
Fix this by replacing {WS} with [ \t] so that it can't match line-breaks.
Convert all instances of {WS}, even though the other instances should be
irrelevant for any well-formed #line directive. This is done for
consistency and ultimate safety.
This is a port of upstream dtc commit a1ee6f0 (with same subject) to the
kernel's copy of dtc.
Reported-by: Ian Campbell <Ian.Campbell@citrix.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Ian Campbell <ian.campbell@citrix.com>
---
Grant, I believe this should be applied for v3.10.
scripts/dtc/dtc-lexer.l | 2 +-
scripts/dtc/dtc-lexer.lex.c_shipped | 232 ++++++++++++++++++------------------
2 files changed, 117 insertions(+), 117 deletions(-)
diff --git a/scripts/dtc/dtc-lexer.l b/scripts/dtc/dtc-lexer.l
index 254d5af..3b41bfc 100644
--- a/scripts/dtc/dtc-lexer.l
+++ b/scripts/dtc/dtc-lexer.l
@@ -71,7 +71,7 @@ static int pop_input_file(void);
push_input_file(name);
}
-<*>^"#"(line)?{WS}+[0-9]+{WS}+{STRING}({WS}+[0-9]+)? {
+<*>^"#"(line)?[ \t]+[0-9]+[ \t]+{STRING}([ \t]+[0-9]+)? {
char *line, *tmp, *fn;
/* skip text before line # */
line = yytext;
diff --git a/scripts/dtc/dtc-lexer.lex.c_shipped b/scripts/dtc/dtc-lexer.lex.c_shipped
index a6c5fcd..2d30f41 100644
--- a/scripts/dtc/dtc-lexer.lex.c_shipped
+++ b/scripts/dtc/dtc-lexer.lex.c_shipped
@@ -405,19 +405,19 @@ static yyconst flex_int16_t yy_accept[161] =
static yyconst flex_int32_t yy_ec[256] =
{ 0,
1, 1, 1, 1, 1, 1, 1, 1, 2, 3,
- 2, 2, 2, 1, 1, 1, 1, 1, 1, 1,
+ 4, 4, 4, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
- 1, 2, 4, 5, 6, 1, 1, 7, 8, 1,
- 1, 9, 10, 10, 11, 10, 12, 13, 14, 15,
- 15, 15, 15, 15, 15, 15, 15, 16, 1, 17,
- 18, 19, 10, 10, 20, 20, 20, 20, 20, 20,
- 21, 21, 21, 21, 21, 22, 21, 21, 21, 21,
- 21, 21, 21, 21, 23, 21, 21, 24, 21, 21,
- 1, 25, 26, 1, 21, 1, 20, 27, 28, 29,
-
- 30, 20, 21, 21, 31, 21, 21, 32, 33, 34,
- 35, 36, 21, 37, 38, 39, 40, 41, 21, 24,
- 42, 21, 43, 44, 45, 1, 1, 1, 1, 1,
+ 1, 2, 5, 6, 7, 1, 1, 8, 9, 1,
+ 1, 10, 11, 11, 12, 11, 13, 14, 15, 16,
+ 16, 16, 16, 16, 16, 16, 16, 17, 1, 18,
+ 19, 20, 11, 11, 21, 21, 21, 21, 21, 21,
+ 22, 22, 22, 22, 22, 23, 22, 22, 22, 22,
+ 22, 22, 22, 22, 24, 22, 22, 25, 22, 22,
+ 1, 26, 27, 1, 22, 1, 21, 28, 29, 30,
+
+ 31, 21, 22, 22, 32, 22, 22, 33, 34, 35,
+ 36, 37, 22, 38, 39, 40, 41, 42, 22, 25,
+ 43, 22, 44, 45, 46, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
@@ -434,36 +434,36 @@ static yyconst flex_int32_t yy_ec[256] =
1, 1, 1, 1, 1
} ;
-static yyconst flex_int32_t yy_meta[46] =
+static yyconst flex_int32_t yy_meta[47] =
{ 0,
- 1, 1, 1, 1, 1, 2, 3, 1, 2, 2,
- 2, 4, 5, 5, 5, 6, 1, 1, 1, 7,
- 8, 8, 8, 8, 1, 1, 7, 7, 7, 7,
- 8, 8, 8, 8, 8, 8, 8, 8, 8, 8,
- 8, 8, 3, 1, 1
+ 1, 1, 1, 1, 1, 1, 2, 3, 1, 2,
+ 2, 2, 4, 5, 5, 5, 6, 1, 1, 1,
+ 7, 8, 8, 8, 8, 1, 1, 7, 7, 7,
+ 7, 8, 8, 8, 8, 8, 8, 8, 8, 8,
+ 8, 8, 8, 3, 1, 1
} ;
static yyconst flex_int16_t yy_base[175] =
{ 0,
- 0, 388, 381, 40, 41, 386, 71, 385, 34, 44,
- 390, 395, 60, 62, 371, 112, 111, 111, 111, 104,
- 370, 106, 371, 342, 124, 119, 0, 144, 395, 0,
- 123, 0, 159, 153, 165, 167, 395, 130, 395, 382,
- 395, 0, 372, 122, 395, 157, 374, 379, 350, 21,
- 346, 349, 395, 395, 395, 395, 395, 362, 395, 395,
- 181, 346, 342, 395, 359, 0, 191, 343, 190, 351,
- 350, 0, 0, 0, 173, 362, 177, 367, 357, 329,
- 335, 328, 337, 331, 206, 329, 334, 327, 395, 338,
- 170, 314, 346, 345, 318, 325, 343, 158, 316, 212,
-
- 322, 319, 320, 395, 340, 336, 308, 305, 314, 304,
- 295, 138, 208, 220, 395, 292, 305, 265, 264, 254,
- 201, 222, 285, 275, 273, 270, 236, 235, 225, 115,
- 395, 395, 252, 216, 216, 217, 214, 230, 209, 220,
- 213, 239, 211, 217, 216, 209, 229, 395, 240, 225,
- 206, 169, 395, 395, 116, 106, 99, 54, 395, 395,
- 254, 260, 268, 272, 276, 282, 289, 293, 301, 309,
- 313, 319, 327, 335
+ 0, 385, 378, 40, 41, 383, 72, 382, 34, 44,
+ 388, 393, 61, 117, 368, 116, 115, 115, 115, 48,
+ 367, 107, 368, 339, 127, 120, 0, 147, 393, 0,
+ 127, 0, 133, 156, 168, 153, 393, 125, 393, 380,
+ 393, 0, 369, 127, 393, 160, 371, 377, 347, 21,
+ 343, 346, 393, 393, 393, 393, 393, 359, 393, 393,
+ 183, 343, 339, 393, 356, 0, 183, 340, 187, 348,
+ 347, 0, 0, 0, 178, 359, 195, 365, 354, 326,
+ 332, 325, 334, 328, 204, 326, 331, 324, 393, 335,
+ 150, 311, 343, 342, 315, 322, 340, 179, 313, 207,
+
+ 319, 316, 317, 393, 337, 333, 305, 302, 311, 301,
+ 310, 190, 338, 337, 393, 307, 322, 301, 305, 277,
+ 208, 311, 307, 278, 271, 270, 248, 246, 213, 130,
+ 393, 393, 263, 235, 207, 221, 218, 229, 213, 213,
+ 206, 234, 218, 210, 208, 193, 219, 393, 223, 204,
+ 176, 157, 393, 393, 120, 106, 97, 119, 393, 393,
+ 245, 251, 259, 263, 267, 273, 280, 284, 292, 300,
+ 304, 310, 318, 326
} ;
static yyconst flex_int16_t yy_def[175] =
@@ -489,108 +489,108 @@ static yyconst flex_int16_t yy_def[175] =
160, 160, 160, 160
} ;
-static yyconst flex_int16_t yy_nxt[441] =
+static yyconst flex_int16_t yy_nxt[440] =
{ 0,
- 12, 13, 14, 15, 16, 12, 17, 18, 12, 12,
- 12, 19, 12, 12, 12, 12, 20, 21, 22, 23,
- 23, 23, 23, 23, 12, 12, 23, 23, 23, 23,
+ 12, 13, 14, 13, 15, 16, 12, 17, 18, 12,
+ 12, 12, 19, 12, 12, 12, 12, 20, 21, 22,
+ 23, 23, 23, 23, 23, 12, 12, 23, 23, 23,
23, 23, 23, 23, 23, 23, 23, 23, 23, 23,
- 23, 23, 12, 24, 12, 25, 34, 35, 35, 25,
- 81, 26, 26, 27, 27, 27, 34, 35, 35, 82,
- 28, 36, 36, 36, 36, 159, 29, 28, 28, 28,
- 28, 12, 13, 14, 15, 16, 30, 17, 18, 30,
- 30, 30, 26, 30, 30, 30, 12, 20, 21, 22,
- 31, 31, 31, 31, 31, 32, 12, 31, 31, 31,
+ 23, 23, 23, 12, 24, 12, 25, 34, 35, 35,
+ 25, 81, 26, 26, 27, 27, 27, 34, 35, 35,
+ 82, 28, 36, 36, 36, 53, 54, 29, 28, 28,
+ 28, 28, 12, 13, 14, 13, 15, 16, 30, 17,
+ 18, 30, 30, 30, 26, 30, 30, 30, 12, 20,
+ 21, 22, 31, 31, 31, 31, 31, 32, 12, 31,
31, 31, 31, 31, 31, 31, 31, 31, 31, 31,
- 31, 31, 31, 12, 24, 12, 39, 41, 45, 47,
- 53, 54, 48, 56, 57, 61, 61, 47, 66, 45,
- 48, 66, 66, 66, 39, 46, 40, 49, 59, 50,
- 158, 51, 122, 52, 157, 49, 46, 50, 136, 63,
- 137, 52, 156, 43, 40, 62, 65, 65, 65, 59,
- 61, 61, 123, 65, 75, 69, 69, 69, 36, 36,
- 65, 65, 65, 65, 70, 71, 72, 69, 69, 69,
- 45, 46, 61, 61, 109, 77, 70, 71, 93, 110,
- 68, 70, 71, 85, 85, 85, 66, 46, 155, 66,
-
- 66, 66, 69, 69, 69, 122, 59, 100, 100, 61,
- 61, 70, 71, 100, 100, 148, 112, 154, 85, 85,
- 85, 61, 61, 129, 129, 123, 129, 129, 135, 135,
- 135, 142, 142, 148, 143, 149, 153, 135, 135, 135,
- 142, 142, 160, 143, 152, 151, 150, 146, 145, 144,
- 141, 140, 139, 149, 38, 38, 38, 38, 38, 38,
- 38, 38, 42, 138, 134, 133, 42, 42, 44, 44,
- 44, 44, 44, 44, 44, 44, 58, 58, 58, 58,
- 64, 132, 64, 66, 131, 130, 66, 160, 66, 66,
- 67, 128, 127, 67, 67, 67, 67, 73, 126, 73,
-
- 73, 76, 76, 76, 76, 76, 76, 76, 76, 78,
- 78, 78, 78, 78, 78, 78, 78, 91, 125, 91,
- 92, 124, 92, 92, 120, 92, 92, 121, 121, 121,
- 121, 121, 121, 121, 121, 147, 147, 147, 147, 147,
- 147, 147, 147, 119, 118, 117, 116, 115, 47, 114,
- 110, 113, 111, 108, 107, 106, 48, 105, 104, 89,
- 103, 102, 101, 99, 98, 97, 96, 95, 94, 79,
- 77, 90, 89, 88, 59, 87, 86, 59, 84, 83,
- 80, 79, 77, 74, 160, 60, 59, 55, 37, 160,
- 33, 25, 26, 25, 11, 160, 160, 160, 160, 160,
+ 31, 31, 31, 31, 31, 12, 24, 12, 36, 36,
+ 36, 39, 41, 45, 47, 56, 57, 48, 61, 47,
+ 39, 159, 48, 66, 61, 45, 66, 66, 66, 158,
+ 46, 40, 49, 59, 50, 157, 51, 49, 52, 50,
+ 40, 63, 46, 52, 36, 36, 36, 156, 43, 62,
+ 65, 65, 65, 59, 136, 68, 137, 65, 75, 69,
+ 69, 69, 70, 71, 65, 65, 65, 65, 70, 71,
+ 72, 69, 69, 69, 61, 46, 45, 155, 154, 66,
+ 70, 71, 66, 66, 66, 122, 85, 85, 85, 59,
+
+ 69, 69, 69, 46, 77, 100, 109, 93, 100, 70,
+ 71, 110, 112, 122, 129, 123, 153, 85, 85, 85,
+ 135, 135, 135, 148, 148, 160, 135, 135, 135, 152,
+ 142, 142, 142, 123, 143, 142, 142, 142, 151, 143,
+ 150, 146, 145, 149, 149, 38, 38, 38, 38, 38,
+ 38, 38, 38, 42, 144, 141, 140, 42, 42, 44,
+ 44, 44, 44, 44, 44, 44, 44, 58, 58, 58,
+ 58, 64, 139, 64, 66, 138, 134, 66, 133, 66,
+ 66, 67, 132, 131, 67, 67, 67, 67, 73, 130,
+ 73, 73, 76, 76, 76, 76, 76, 76, 76, 76,
+
+ 78, 78, 78, 78, 78, 78, 78, 78, 91, 160,
+ 91, 92, 129, 92, 92, 128, 92, 92, 121, 121,
+ 121, 121, 121, 121, 121, 121, 147, 147, 147, 147,
+ 147, 147, 147, 147, 127, 126, 125, 124, 61, 61,
+ 120, 119, 118, 117, 116, 115, 47, 114, 110, 113,
+ 111, 108, 107, 106, 48, 105, 104, 89, 103, 102,
+ 101, 99, 98, 97, 96, 95, 94, 79, 77, 90,
+ 89, 88, 59, 87, 86, 59, 84, 83, 80, 79,
+ 77, 74, 160, 60, 59, 55, 37, 160, 33, 25,
+ 26, 25, 11, 160, 160, 160, 160, 160, 160, 160,
160, 160, 160, 160, 160, 160, 160, 160, 160, 160,
160, 160, 160, 160, 160, 160, 160, 160, 160, 160,
160, 160, 160, 160, 160, 160, 160, 160, 160, 160,
- 160, 160, 160, 160, 160, 160, 160, 160, 160, 160
+ 160, 160, 160, 160, 160, 160, 160, 160, 160
} ;
-static yyconst flex_int16_t yy_chk[441] =
+static yyconst flex_int16_t yy_chk[440] =
{ 0,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
- 1, 1, 1, 1, 1, 4, 9, 9, 9, 10,
- 50, 4, 5, 5, 5, 5, 10, 10, 10, 50,
- 5, 13, 13, 14, 14, 158, 5, 5, 5, 5,
- 5, 7, 7, 7, 7, 7, 7, 7, 7, 7,
+ 1, 1, 1, 1, 1, 1, 4, 9, 9, 9,
+ 10, 50, 4, 5, 5, 5, 5, 10, 10, 10,
+ 50, 5, 13, 13, 13, 20, 20, 5, 5, 5,
+ 5, 5, 7, 7, 7, 7, 7, 7, 7, 7,
7, 7, 7, 7, 7, 7, 7, 7, 7, 7,
7, 7, 7, 7, 7, 7, 7, 7, 7, 7,
7, 7, 7, 7, 7, 7, 7, 7, 7, 7,
- 7, 7, 7, 7, 7, 7, 16, 17, 18, 19,
- 20, 20, 19, 22, 22, 25, 25, 26, 31, 44,
- 26, 31, 31, 31, 38, 18, 16, 19, 31, 19,
- 157, 19, 112, 19, 156, 26, 44, 26, 130, 26,
- 130, 26, 155, 17, 38, 25, 28, 28, 28, 28,
- 33, 33, 112, 28, 46, 34, 34, 34, 36, 36,
- 28, 28, 28, 28, 34, 34, 34, 35, 35, 35,
- 75, 46, 61, 61, 98, 77, 35, 35, 77, 98,
- 33, 91, 91, 61, 61, 61, 67, 75, 152, 67,
-
- 67, 67, 69, 69, 69, 121, 67, 85, 85, 113,
- 113, 69, 69, 100, 100, 143, 100, 151, 85, 85,
- 85, 114, 114, 122, 122, 121, 129, 129, 135, 135,
- 135, 138, 138, 147, 138, 143, 150, 129, 129, 129,
- 142, 142, 149, 142, 146, 145, 144, 141, 140, 139,
- 137, 136, 134, 147, 161, 161, 161, 161, 161, 161,
- 161, 161, 162, 133, 128, 127, 162, 162, 163, 163,
- 163, 163, 163, 163, 163, 163, 164, 164, 164, 164,
- 165, 126, 165, 166, 125, 124, 166, 123, 166, 166,
- 167, 120, 119, 167, 167, 167, 167, 168, 118, 168,
-
- 168, 169, 169, 169, 169, 169, 169, 169, 169, 170,
- 170, 170, 170, 170, 170, 170, 170, 171, 117, 171,
- 172, 116, 172, 172, 111, 172, 172, 173, 173, 173,
- 173, 173, 173, 173, 173, 174, 174, 174, 174, 174,
- 174, 174, 174, 110, 109, 108, 107, 106, 105, 103,
- 102, 101, 99, 97, 96, 95, 94, 93, 92, 90,
- 88, 87, 86, 84, 83, 82, 81, 80, 79, 78,
- 76, 71, 70, 68, 65, 63, 62, 58, 52, 51,
- 49, 48, 47, 43, 40, 24, 23, 21, 15, 11,
- 8, 6, 3, 2, 160, 160, 160, 160, 160, 160,
+ 7, 7, 7, 7, 7, 7, 7, 7, 14, 14,
+ 14, 16, 17, 18, 19, 22, 22, 19, 25, 26,
+ 38, 158, 26, 31, 33, 44, 31, 31, 31, 157,
+ 18, 16, 19, 31, 19, 156, 19, 26, 19, 26,
+ 38, 26, 44, 26, 36, 36, 36, 155, 17, 25,
+ 28, 28, 28, 28, 130, 33, 130, 28, 46, 34,
+ 34, 34, 91, 91, 28, 28, 28, 28, 34, 34,
+ 34, 35, 35, 35, 61, 46, 75, 152, 151, 67,
+ 35, 35, 67, 67, 67, 112, 61, 61, 61, 67,
+
+ 69, 69, 69, 75, 77, 85, 98, 77, 100, 69,
+ 69, 98, 100, 121, 129, 112, 150, 85, 85, 85,
+ 135, 135, 135, 143, 147, 149, 129, 129, 129, 146,
+ 138, 138, 138, 121, 138, 142, 142, 142, 145, 142,
+ 144, 141, 140, 143, 147, 161, 161, 161, 161, 161,
+ 161, 161, 161, 162, 139, 137, 136, 162, 162, 163,
+ 163, 163, 163, 163, 163, 163, 163, 164, 164, 164,
+ 164, 165, 134, 165, 166, 133, 128, 166, 127, 166,
+ 166, 167, 126, 125, 167, 167, 167, 167, 168, 124,
+ 168, 168, 169, 169, 169, 169, 169, 169, 169, 169,
+
+ 170, 170, 170, 170, 170, 170, 170, 170, 171, 123,
+ 171, 172, 122, 172, 172, 120, 172, 172, 173, 173,
+ 173, 173, 173, 173, 173, 173, 174, 174, 174, 174,
+ 174, 174, 174, 174, 119, 118, 117, 116, 114, 113,
+ 111, 110, 109, 108, 107, 106, 105, 103, 102, 101,
+ 99, 97, 96, 95, 94, 93, 92, 90, 88, 87,
+ 86, 84, 83, 82, 81, 80, 79, 78, 76, 71,
+ 70, 68, 65, 63, 62, 58, 52, 51, 49, 48,
+ 47, 43, 40, 24, 23, 21, 15, 11, 8, 6,
+ 3, 2, 160, 160, 160, 160, 160, 160, 160, 160,
160, 160, 160, 160, 160, 160, 160, 160, 160, 160,
160, 160, 160, 160, 160, 160, 160, 160, 160, 160,
160, 160, 160, 160, 160, 160, 160, 160, 160, 160,
- 160, 160, 160, 160, 160, 160, 160, 160, 160, 160
+ 160, 160, 160, 160, 160, 160, 160, 160, 160
} ;
static yy_state_type yy_last_accepting_state;
--
1.8.1.5
^ permalink raw reply related
* Re: [PATCH] MDIO: FSL_PQ_MDIO: Fix bug on incorrect offset of tbipa register
From: Scott Wood @ 2013-06-12 18:31 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: stef.van.os, Oded Gabbay, netdev, Dongsheng.Wang, timur, paulus,
linuxppc-dev, davem, linux-kernel, B38951
In-Reply-To: <51B88EED.6090709@linutronix.de>
On 06/12/2013 10:08:29 AM, Sebastian Andrzej Siewior wrote:
> On 06/12/2013 02:47 PM, Oded Gabbay wrote:
> > This patch fixes a bug in the fsl_pq_mdio.c module and in relevant =20
> device-tree
> > files regarding the correct offset of the tbipa register in the =20
> eTSEC
> > controller in some of Freescale's PQ3 and QorIQ SoC.
> > The bug happens when the mdio in the device tree is configured to =20
> be compatible
> > to "fsl,gianfar-tbi". Because the mdio device in the device tree =20
> points to
> > addresses 25520, 26520 or 27520 (depends on the controller ID), the =20
> variable
> > priv->map at function fsl_pq_mdio_probe, points to that address. =20
> However,
> > later in the function there is a write to register tbipa that is =20
> actually
> > located at 25030, 26030 or 27030. Because the correct address is =20
> not io mapped,
> > the contents are written to a different register in the controller.
> > The fix sets the address of the mdio device to start at 25000, =20
> 26000 or 27000
> > and changes the mii_offset field to 0x520 in the relevant entry
> > (fsl,gianfar-tbi) of the fsl_pq_mdio_match array.
> >
> > Note: This patch may break MDIO functionallity of some old =20
> Freescale's SoC
> > until Freescale will fix their device tree files. Basically, every =20
> device tree
> > which contains an mdio device that is compatible to =20
> "fsl,gianfar-tbi" should be
> > examined.
>=20
> Not as is.
> Please add a check for the original address. If it has 0x520 at the =20
> end
> print a warning and fix it up. Please add to the patch description
> which register is modified instead if this patch is not applied.
> Depending on how critical this it might has to go stable.
I'm not sure it's stable material if this is something that has never =20
worked...
The device tree binding will also need to be fixed to note the =20
difference in "reg" between "fsl,gianfar-mdio" and "fsl-gianfar-tbi" -- =20
and should give an example of the latter.
-Scott=
^ permalink raw reply
* Re: [PATCH] powerpc: Fix bad pmd error with book3E config
From: Scott Wood @ 2013-06-12 20:33 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: linuxppc-dev
In-Reply-To: <1371033004-15864-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
On Wed, Jun 12, 2013 at 04:00:04PM +0530, Aneesh Kumar K.V wrote:
> From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
>
> Book3E uses the hugepd at PMD level and don't encode pte directly
> at the pmd level. So it will find the lower bits of pmd set
> and the pmd_bad check throws error. Infact the current code
> will never take the free_hugepd_range call at all because it will
> clear the pmd if it find a hugepd pointer.
>
> Reported-by: Scott Wood <scottwood@freescale.com>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
> ---
> arch/powerpc/mm/hugetlbpage.c | 29 ++++++++++++++++++-----------
> 1 file changed, 18 insertions(+), 11 deletions(-)
Thanks; this fixes the error for me.
-Scott
^ permalink raw reply
* Re: [BUG] PCI related panic on powerpc based board with 3.10-rcX
From: Scott Wood @ 2013-06-12 21:50 UTC (permalink / raw)
To: Rojhalat Ibrahim; +Cc: linuxppc-dev, linux-kernel, Michael Guntsche
In-Reply-To: <34279395.MbRViMjbAR@pcimr>
On 06/12/2013 03:19:30 AM, Rojhalat Ibrahim wrote:
> On Tuesday 11 June 2013 12:28:59 Scott Wood wrote:
> > Yes, I figured it was non-PCIe because the code change that you said
> > helped was on the non-PCIe branch of the if/else. Generally it's =20
> good
> > to explicitly mention the chip you're using, though.
> >
> > fsl_setup_indirect_pci should be renamed to fsl_setup_indirect_pcie.
> > Your patch above should be applied, and fsl_setup_indirect_pcie =20
> should
> > be moved into the booke/86xx ifdef to avoid an unused function =20
> warning.
> >
> > -Scott
>=20
> How about this patch? It uses setup_indirect_pci for the PCI case in
> mpc83xx_add_bridge. Additionally it adds a check in =20
> fsl_setup_indirect_pci
> to only use the modified read function in case of PCIe.
If we're adding the check to fsl_setup_indirect_pci, there's no need to =20
change the 83xx call back to setup_indirect_pci. I see that 85xx is =20
also callirng fsl_setup_indirect_pci for both; it'd be good to be =20
consistent.
In any case, can you send a proper patch with a signoff and commit =20
message?
-Scott=
^ permalink raw reply
* Re: [PATCH 1/2] powerpc: add Book E support to 64-bit hibernation
From: Scott Wood @ 2013-06-12 22:03 UTC (permalink / raw)
To: Wang Dongsheng; +Cc: anton, Wang Dongsheng, johannes, linuxppc-dev
In-Reply-To: <1370774260-31072-1-git-send-email-dongsheng.wang@freescale.com>
On 06/09/2013 05:37:39 AM, Wang Dongsheng wrote:
> /* these macros rely on the save area being
> * pointed to by r11 */
> +
> +#define SAVE_SPR(register) \
> + mfspr r0,SPRN_##register ;\
> + std r0,SL_##register(r11)
> +#define RESTORE_SPR(register) \
> + ld r0,SL_##register(r11) ;\
> + mtspr SPRN_##register,r0
> +#define RESTORE_SPRG(n) \
> + ld r0,SL_SPRG##n(r11) ;\
> + mtsprg n,r0
> #define SAVE_SPECIAL(special) \
> mf##special r0 ;\
> std r0, SL_##special(r11)
Is there a particular SPR that you're trying to save, for which =20
SAVE_SPECIAL doesn't work?
> +#else
> + /* Save SPRGs */
> + RESTORE_SPRG(0)
> + RESTORE_SPRG(1)
> + RESTORE_SPRG(2)
> + RESTORE_SPRG(3)
> + RESTORE_SPRG(4)
> + RESTORE_SPRG(5)
> + RESTORE_SPRG(6)
> + RESTORE_SPRG(7)
Why do we need this on book3e and not on book3s?
> +
> + RESTORE_SPECIAL(MSR)
> +
> + /* Restore TCR and clear any pending bits in TSR. */
> + RESTORE_SPR(TCR)
> + lis r0, (TSR_ENW | TSR_WIS | TSR_DIS | TSR_FIS)@h
> + mtspr SPRN_TSR,r0
Please be internally consistent with whitespace after commas, even if =20
the rest of the file is already inconsistent. :-P
> +
> + /* Kick decrementer */
> + li r0,1
> + mtdec r0
Why doesn't book3s need to kick the decrementer?
-Scott=
^ permalink raw reply
* [PATCH] powerpc/perf: Freeze PMC5/6 if we're not using them on Power8
From: Michael Ellerman @ 2013-06-13 1:16 UTC (permalink / raw)
To: linuxppc-dev
On Power8 we can freeze PMC5 and 6 if we're not using them. Normally they
run all the time.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/include/asm/reg.h | 1 +
arch/powerpc/perf/power8-pmu.c | 4 ++++
2 files changed, 5 insertions(+)
diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
index 4a9e408..362142b 100644
--- a/arch/powerpc/include/asm/reg.h
+++ b/arch/powerpc/include/asm/reg.h
@@ -626,6 +626,7 @@
#define MMCR0_TRIGGER 0x00002000UL /* TRIGGER enable */
#define MMCR0_PMAO 0x00000080UL /* performance monitor alert has occurred, set to 0 after handling exception */
#define MMCR0_SHRFC 0x00000040UL /* SHRre freeze conditions between threads */
+#define MMCR0_FC56 0x00000010UL /* freeze counters 5 and 6 */
#define MMCR0_FCTI 0x00000008UL /* freeze counters in tags inactive mode */
#define MMCR0_FCTA 0x00000004UL /* freeze counters in tags active mode */
#define MMCR0_FCWAIT 0x00000002UL /* freeze counter in WAIT state */
diff --git a/arch/powerpc/perf/power8-pmu.c b/arch/powerpc/perf/power8-pmu.c
index f7d1c4f..e791c68 100644
--- a/arch/powerpc/perf/power8-pmu.c
+++ b/arch/powerpc/perf/power8-pmu.c
@@ -378,6 +378,10 @@ static int power8_compute_mmcr(u64 event[], int n_ev,
if (pmc_inuse & 0x7c)
mmcr[0] |= MMCR0_PMCjCE;
+ /* If we're not using PMC 5 or 6, freeze them */
+ if (!(pmc_inuse & 0x60))
+ mmcr[0] |= MMCR0_FC56;
+
mmcr[1] = mmcr1;
mmcr[2] = mmcra;
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH 21/27] powerpc/eeh: Process interrupts caused by EEH
From: Gavin Shan @ 2013-06-13 4:14 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Gavin Shan
In-Reply-To: <1370938435.8250.116.camel@pasglop>
On Tue, Jun 11, 2013 at 06:13:55PM +1000, Benjamin Herrenschmidt wrote:
>On Wed, 2013-06-05 at 15:34 +0800, Gavin Shan wrote:
>
>> diff --git a/arch/powerpc/include/asm/eeh.h b/arch/powerpc/include/asm/eeh.h
>> index d1fd5d4..68ac408 100644
>> --- a/arch/powerpc/include/asm/eeh.h
>> +++ b/arch/powerpc/include/asm/eeh.h
>> @@ -209,6 +209,12 @@ void eeh_add_device_tree_late(struct pci_bus *);
>> void eeh_add_sysfs_files(struct pci_bus *);
>> void eeh_remove_bus_device(struct pci_dev *, int);
>>
>> +#ifdef CONFIG_PPC_POWERNV
>> +void pci_err_release(void);
>> +#else
>> +static inline void pci_err_release(void) { }
>> +#endif
>
>That business of the EEH core calling back into the powernv code
>directly is gross. We don't do that...
>
>See below for a discussion...
>
>.../...
>
Thanks for the review and comments, Ben.
>> +static void pci_err_take(void)
>> +{
>> + down(&pci_err_seq_sem);
>> +}
>> +
>> +/**
>> + * pci_err_release - Enable error report for sending events
>> + *
>> + * We're hanlding the EEH event one by one. Each time, there only has
>> + * one EEH event caused by error IRQ. The function is called to enable
>> + * error report in order to send more EEH events.
>> + */
>> +void pci_err_release(void)
>> +{
>> + up(&pci_err_seq_sem);
>> +}
>
>So it's generally bad to keep a semaphore held like that for a long
>time, taken in one corner of the kernel and released in another.
>
>I think you need to do something else. I'm not 100% certain what but
>that doesn't seem right to me.
>
>Also you have two problems I see here:
>
> - A given error will come potentially as both an interrupt and
>a return of ffff's from MMIO. You don't know which one will get it first
>and you end up going through two fairly different code path maybe. IE.
>What happens if interrupts are off for a while on the CPU that is
>targetted by the PHB interrupt and you "detect" a PHB fence as a result
>of an MMIO on another CPU ? Will the normal EEH process clear the fence
>and your interrupt completely miss logging any of those fancy messages
>you added to this file ?
>
Yes, we don't know which one (interrupt and 0xff's from MMIO/PCI-CFG)
comes in first. And no, the normal EEH process will call eeh_ops::get_log()
to collect the log and we won't lose the log.
> - You create another kthread ... we already have one in eeh_event.c,
>why another ?
>
What I thought is to prevent EEH core calling opal_pci_next_error() since
the EEH core is the shared part by multiple platforms. That's to say,
I expected opal_pci_next_error() to be part of powernv platform, and we
need some mechanism to inject EEH event to EEH core so that it can handle
them in sequence. That's why I created a new kthread.
>I think you need to rethink that part. My idea is that the EEH
>interrupts coming from the OPAL notifier would cause you to queue up
>EEH events just like the current ones.
>
>IE. Everything (including get_next_error) should be done by the one EEH
>thread. This also avoids the needs for those extra semaphores.
>
>One option is to create an event without a PE pointer at all. When
>eeh_event_handler() gets that, it would iterate a new hook,
>eeh_ops->next_error() which returns the PE.
>
>That way you can do your printing for fences etc... and return the
>top-level PE for anything PHB-wide. You may also want to add a flag
>maybe to return non-recoverable events and essentially make EEH just
>remove the offending devices from the system instead of panic'ing (panic
>is never a good idea, for all I know, the dead PHB or dead IOC wasn't
>critical to the system operating normally and you may have killed my
>ability to even recover the logs by panic'ing).
>
>Think a bit about it. I know the RTAS model is fairly different than our
>model here, but I like the idea that on powernv, even if we detect an
>MMIO freeze, we don't directly tell the EEH core to process *that* PE
>but instead do the whole next_error thing as well. If the freeze was the
>result of a fence, there's no point trying to process that specific PE.
>
>Something like a fence would thus look like that:
>
> - [ Case 1 -> fence interrupt -> queue eeh_event with no PE ]
> [ Case 2 -> MMIO freeze detected -> queue eeh event with no PE ]
>
> - eeh_event_handler() sees no PE, loops around eeh_ops->get_next_error,
>since we are single threaded in the EEH thread, it's ok for the IODA
>backend to "cache" the current error data so that subsequent calls into
>the backend know what we are doing.
>
> - get_next_error sees the fence, returns the top-level PE and starts
>the reset (don't wait)
>
> - eeh_event_handler() calls the drivers for all devices on that PE
>(including children) to notify them something's wrong (TODO: Add passing
>by the upper level that this is a fatal error and don't attempt to
>recover).
>
> - It then calls wait_state() which knows it's waiting on a fence, and
>do the appropriate waiting etc...
>
> - Back to normal process...
>
>Don't you think that might be cleaner ? Or do you see a gaping hole in
>my description ?
>
It would incur lots of "unnecessary" EEH events. Normally, we send one
EEH event and we have specific PE (either corresponding to PHB or real
PE) for the event. Before the event is queued to the event queue, the
corresponding PE will be marked as "isolated". If the PE has been put
into "isolated" state, and we won't create another event if detecting
the PE got frozen again.
I think we can remove those pci_err_release/pci_err_take() by:
- Export function to control "confirm_error_lock" (defined in eeh.c).
For example, eeh_serialize_lock/unlock().
- While detecting fenced PHB or frozen PE through interrupt or MMIO
access, calling eeh_serialize_lock() and won't create EEH event if
the PHB or PE has been marked "isolated". Otherwise, we will create
an EEH event and queue it for further processing.
>> +static void pci_err_hub_diag_common(struct OpalIoP7IOCErrorData *data)
>> +{
>> + /* GEM */
>> + pr_info(" GEM XFIR: %016llx\n", data->gemXfir);
>> + pr_info(" GEM RFIR: %016llx\n", data->gemRfir);
>> + pr_info(" GEM RIRQFIR: %016llx\n", data->gemRirqfir);
>> + pr_info(" GEM Mask: %016llx\n", data->gemMask);
>> + pr_info(" GEM RWOF: %016llx\n", data->gemRwof);
>> +
>> + /* LEM */
>> + pr_info(" LEM FIR: %016llx\n", data->lemFir);
>> + pr_info(" LEM Error Mask: %016llx\n", data->lemErrMask);
>> + pr_info(" LEM Action 0: %016llx\n", data->lemAction0);
>> + pr_info(" LEM Action 1: %016llx\n", data->lemAction1);
>> + pr_info(" LEM WOF: %016llx\n", data->lemWof);
>> +}
>
>That's stuff is P7IOC specific. Make sure you make it clear in the
>function name and that you check the diag data "type". IE. Use a new
>diag_data2 function that returns a type. We can obsolete the old one.
>
Ok. Will update in next revision.
>> +static void pci_err_hub_diag_data(struct pci_controller *hose)
>> +{
>> + struct pnv_phb *phb = hose->private_data;
>> + struct OpalIoP7IOCErrorData *data;
>> + long ret;
>> +
>> + data = (struct OpalIoP7IOCErrorData *)pci_err_diag;
>> + ret = opal_pci_get_hub_diag_data(phb->hub_id, data, PAGE_SIZE);
>> + if (ret != OPAL_SUCCESS) {
>> + pr_warning("%s: Failed to get HUB#%llx diag-data, ret=%ld\n",
>> + __func__, phb->hub_id, ret);
>> + return;
>> + }
>> +
>> + /* Check the error type */
>> + if (data->type <= OPAL_P7IOC_DIAG_TYPE_NONE ||
>> + data->type >= OPAL_P7IOC_DIAG_TYPE_LAST) {
>> + pr_warning("%s: Invalid type of HUB#%llx diag-data (%d)\n",
>> + __func__, phb->hub_id, data->type);
>> + return;
>> + }
>> +
>> + switch (data->type) {
>> + case OPAL_P7IOC_DIAG_TYPE_RGC:
>> + pr_info("P7IOC diag-data for RGC\n\n");
>> + pci_err_hub_diag_common(data);
>> + pr_info(" RGC Status: %016llx\n", data->rgc.rgcStatus);
>> + pr_info(" RGC LDCP: %016llx\n", data->rgc.rgcLdcp);
>> + break;
>> + case OPAL_P7IOC_DIAG_TYPE_BI:
>> + pr_info("P7IOC diag-data for BI %s\n\n",
>> + data->bi.biDownbound ? "Downbound" : "Upbound");
>> + pci_err_hub_diag_common(data);
>> + pr_info(" BI LDCP 0: %016llx\n", data->bi.biLdcp0);
>> + pr_info(" BI LDCP 1: %016llx\n", data->bi.biLdcp1);
>> + pr_info(" BI LDCP 2: %016llx\n", data->bi.biLdcp2);
>> + pr_info(" BI Fence Status: %016llx\n", data->bi.biFenceStatus);
>> + break;
>> + case OPAL_P7IOC_DIAG_TYPE_CI:
>> + pr_info("P7IOC diag-data for CI Port %d\\nn",
>> + data->ci.ciPort);
>> + pci_err_hub_diag_common(data);
>> + pr_info(" CI Port Status: %016llx\n", data->ci.ciPortStatus);
>> + pr_info(" CI Port LDCP: %016llx\n", data->ci.ciPortLdcp);
>> + break;
>> + case OPAL_P7IOC_DIAG_TYPE_MISC:
>> + pr_info("P7IOC diag-data for MISC\n\n");
>> + pci_err_hub_diag_common(data);
>> + break;
>> + case OPAL_P7IOC_DIAG_TYPE_I2C:
>> + pr_info("P7IOC diag-data for I2C\n\n");
>> + pci_err_hub_diag_common(data);
>> + break;
>> + }
>> +}
>> +
>> +static void pci_err_phb_diag_data(struct pci_controller *hose)
>> +{
>> + struct pnv_phb *phb = hose->private_data;
>> + struct OpalIoP7IOCPhbErrorData *data;
>> + int i;
>> + long ret;
>> +
>> + data = (struct OpalIoP7IOCPhbErrorData *)pci_err_diag;
>> + ret = opal_pci_get_phb_diag_data2(phb->opal_id, data, PAGE_SIZE);
>> + if (ret != OPAL_SUCCESS) {
>> + pr_warning("%s: Failed to get diag-data for PHB#%x, ret=%ld\n",
>> + __func__, hose->global_number, ret);
>> + return;
>> + }
>> +
>> + pr_info("PHB#%x Diag-data\n\n", hose->global_number);
>> + pr_info(" brdgCtl: %08x\n", data->brdgCtl);
>> +
>> + pr_info(" portStatusReg: %08x\n", data->portStatusReg);
>> + pr_info(" rootCmplxStatus: %08x\n", data->rootCmplxStatus);
>> + pr_info(" busAgentStatus: %08x\n", data->busAgentStatus);
>> +
>> + pr_info(" deviceStatus: %08x\n", data->deviceStatus);
>> + pr_info(" slotStatus: %08x\n", data->slotStatus);
>> + pr_info(" linkStatus: %08x\n", data->linkStatus);
>> + pr_info(" devCmdStatus: %08x\n", data->devCmdStatus);
>> + pr_info(" devSecStatus: %08x\n", data->devSecStatus);
>> +
>> + pr_info(" rootErrorStatus: %08x\n", data->rootErrorStatus);
>> + pr_info(" uncorrErrorStatus: %08x\n", data->uncorrErrorStatus);
>> + pr_info(" corrErrorStatus: %08x\n", data->corrErrorStatus);
>> + pr_info(" tlpHdr1: %08x\n", data->tlpHdr1);
>> + pr_info(" tlpHdr2: %08x\n", data->tlpHdr2);
>> + pr_info(" tlpHdr3: %08x\n", data->tlpHdr3);
>> + pr_info(" tlpHdr4: %08x\n", data->tlpHdr4);
>> + pr_info(" sourceId: %08x\n", data->sourceId);
>> +
>> + pr_info(" errorClass: %016llx\n", data->errorClass);
>> + pr_info(" correlator: %016llx\n", data->correlator);
>> + pr_info(" p7iocPlssr: %016llx\n", data->p7iocPlssr);
>> + pr_info(" p7iocCsr: %016llx\n", data->p7iocCsr);
>> + pr_info(" lemFir: %016llx\n", data->lemFir);
>> + pr_info(" lemErrorMask: %016llx\n", data->lemErrorMask);
>> + pr_info(" lemWOF: %016llx\n", data->lemWOF);
>> + pr_info(" phbErrorStatus: %016llx\n", data->phbErrorStatus);
>> + pr_info(" phbFirstErrorStatus: %016llx\n", data->phbFirstErrorStatus);
>> + pr_info(" phbErrorLog0: %016llx\n", data->phbErrorLog0);
>> + pr_info(" phbErrorLog1: %016llx\n", data->phbErrorLog1);
>> + pr_info(" mmioErrorStatus: %016llx\n", data->mmioErrorStatus);
>> + pr_info(" mmioFirstErrorStatus: %016llx\n", data->mmioFirstErrorStatus);
>> + pr_info(" mmioErrorLog0: %016llx\n", data->mmioErrorLog0);
>> + pr_info(" mmioErrorLog1: %016llx\n", data->mmioErrorLog1);
>> + pr_info(" dma0ErrorStatus: %016llx\n", data->dma0ErrorStatus);
>> + pr_info(" dma0FirstErrorStatus: %016llx\n", data->dma0FirstErrorStatus);
>> + pr_info(" dma0ErrorLog0: %016llx\n", data->dma0ErrorLog0);
>> + pr_info(" dma0ErrorLog1: %016llx\n", data->dma0ErrorLog1);
>> + pr_info(" dma1ErrorStatus: %016llx\n", data->dma1ErrorStatus);
>> + pr_info(" dma1FirstErrorStatus: %016llx\n", data->dma1FirstErrorStatus);
>> + pr_info(" dma1ErrorLog0: %016llx\n", data->dma1ErrorLog0);
>> + pr_info(" dma1ErrorLog1: %016llx\n", data->dma1ErrorLog1);
>> +
>> + for (i = 0; i < OPAL_P7IOC_NUM_PEST_REGS; i++) {
>> + if ((data->pestA[i] >> 63) == 0 &&
>> + (data->pestB[i] >> 63) == 0)
>> + continue;
>> +
>> + pr_info(" PE[%3d] PESTA: %016llx\n", i, data->pestA[i]);
>> + pr_info(" PESTB: %016llx\n", data->pestB[i]);
>> + }
>> +}
>> +
>> +/*
>> + * Process PCI errors from IOC, PHB, or PE. Here's the list
>> + * of expected error types and their severities, as well as
>> + * the corresponding action.
>> + *
>> + * Type Severity Action
>> + * OPAL_EEH_ERROR_IOC OPAL_EEH_SEV_IOC_DEAD panic
>> + * OPAL_EEH_ERROR_IOC OPAL_EEH_SEV_INF diag_data
>> + * OPAL_EEH_ERROR_PHB OPAL_EEH_SEV_PHB_DEAD panic
>> + * OPAL_EEH_ERROR_PHB OPAL_EEH_SEV_PHB_FENCED eeh
>> + * OPAL_EEH_ERROR_PHB OPAL_EEH_SEV_INF diag_data
>> + * OPAL_EEH_ERROR_PE OPAL_EEH_SEV_PE_ER eeh
>> + */
>> +static void pci_err_process(struct pci_controller *hose,
>> + u16 err_type, u16 severity, u16 pe_no)
>> +{
>> + PCI_ERR_DBG("PCI_ERR: Process error (%d, %d, %d) on PHB#%x\n",
>> + err_type, severity, pe_no, hose->global_number);
>> +
>> + switch (err_type) {
>> + case OPAL_EEH_IOC_ERROR:
>> + if (severity == OPAL_EEH_SEV_IOC_DEAD)
>> + panic("Dead IOC of PHB#%x", hose->global_number);
>> + else if (severity == OPAL_EEH_SEV_INF) {
>> + pci_err_hub_diag_data(hose);
>> + pci_err_release();
>> + }
>> +
>> + break;
>> + case OPAL_EEH_PHB_ERROR:
>> + if (severity == OPAL_EEH_SEV_PHB_DEAD)
>> + panic("Dead PHB#%x", hose->global_number);
>> + else if (severity == OPAL_EEH_SEV_PHB_FENCED)
>> + pci_err_check_phb(hose);
>> + else if (severity == OPAL_EEH_SEV_INF) {
>> + pci_err_phb_diag_data(hose);
>> + pci_err_release();
>> + }
>> +
>> + break;
>> + case OPAL_EEH_PE_ERROR:
>> + pci_err_check_pe(hose, pe_no);
>> + break;
>> + }
>> +}
>> +
>> +static int pci_err_handler(void *dummy)
>> +{
>> + struct pnv_phb *phb;
>> + struct pci_controller *hose, *tmp;
>> + u64 frozen_pe_no;
>> + u16 err_type, severity;
>> + long ret;
>> +
>> + while (!kthread_should_stop()) {
>> + down(&pci_err_int_sem);
>> + PCI_ERR_DBG("PCI_ERR: Get PCI error semaphore\n");
>> +
>> + list_for_each_entry_safe(hose, tmp, &hose_list, list_node) {
>> + phb = hose->private_data;
>> +restart:
>> + pci_err_take();
>> + ret = opal_pci_next_error(phb->opal_id,
>> + &frozen_pe_no, &err_type, &severity);
>> +
>> + /* If OPAL API returns error, we needn't proceed */
>> + if (ret != OPAL_SUCCESS) {
>> + PCI_ERR_DBG("PCI_ERR: Invalid return value on "
>> + "PHB#%x (0x%lx) from opal_pci_next_error",
>> + hose->global_number, ret);
>> + pci_err_release();
>> + continue;
>> + }
>> +
>> + /* If the PHB doesn't have error, stop processing */
>> + if (err_type == OPAL_EEH_NO_ERROR ||
>> + severity == OPAL_EEH_SEV_NO_ERROR) {
>> + PCI_ERR_DBG("PCI_ERR: No error found on PHB#%x\n",
>> + hose->global_number);
>> + pci_err_release();
>> + continue;
>> + }
>> +
>> + /*
>> + * Process the error until there're no pending
>> + * errors on the specific PHB.
>> + */
>> + pci_err_process(hose, err_type, severity, frozen_pe_no);
>> + goto restart;
>> + }
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +/*
>> + * pci_err_init - Initialize PCI error handling component
>> + *
>> + * It should be done before OPAL interrupts got registered because
>> + * that depends on this.
>> + */
>> +static int __init pci_err_init(void)
>> +{
>> + int ret = 0;
>> +
>> + if (!firmware_has_feature(FW_FEATURE_OPALv3)) {
>> + pr_err("%s: FW_FEATURE_OPALv3 required!\n",
>> + __func__);
>> + return -EINVAL;
>> + }
>> +
>> + pci_err_diag = (char *)__get_free_page(GFP_KERNEL|__GFP_ZERO);
>> + if (!pci_err_diag) {
>> + pr_err("%s: Failed to alloc memory for diag data\n",
>> + __func__);
>> + return -ENOMEM;
>> + }
>> +
>> + /* Initialize semaphore */
>> + sema_init(&pci_err_int_sem, 0);
>> + sema_init(&pci_err_seq_sem, 1);
>> +
>> + /* Start kthread */
>> + pci_err_thread = kthread_run(pci_err_handler, NULL, "PCI_ERR");
>> + if (IS_ERR(pci_err_thread)) {
>> + ret = PTR_ERR(pci_err_thread);
>> + pr_err("%s: Failed to start kthread, ret=%d\n",
>> + __func__, ret);
>> + }
>> +
>> + free_page((unsigned long)pci_err_diag);
>> + return ret;
>> +}
>> +
>> +arch_initcall(pci_err_init);
>> diff --git a/arch/powerpc/platforms/pseries/eeh_event.c b/arch/powerpc/platforms/pseries/eeh_event.c
>> index 1f86b80..e4c636e 100644
>> --- a/arch/powerpc/platforms/pseries/eeh_event.c
>> +++ b/arch/powerpc/platforms/pseries/eeh_event.c
>> @@ -84,6 +84,14 @@ static int eeh_event_handler(void * dummy)
>> eeh_handle_event(pe);
>> eeh_pe_state_clear(pe, EEH_PE_RECOVERING);
>>
>> + /*
>> + * If it's the event caused by error reporting IRQ,
>> + * we need release the module so that precedent events
>> + * could be fired.
>> + */
>> + if (event->flag & EEH_EVENT_INT)
>> + pci_err_release();
>> +
>> kfree(event);
>> mutex_unlock(&eeh_event_mutex);
>>
Thanks,
Gavin
^ permalink raw reply
* Re: [PATCH 15/27] powerpc/eeh: I/O chip EEH state retrieval
From: Gavin Shan @ 2013-06-13 4:26 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Gavin Shan
In-Reply-To: <1371010765.8250.173.camel@pasglop>
On Wed, Jun 12, 2013 at 02:19:25PM +1000, Benjamin Herrenschmidt wrote:
>On Wed, 2013-06-12 at 11:32 +0800, Gavin Shan wrote:
>
>> >Same comments about "state" which is really "delay" and is probably
>> >not necessary at all ...
>> >
>>
>> We need the "delay" in future to support PowerKVM guest. If the
>> specified PE is being reset, we rely on the delay to hold the
>> powerkvm guest for a while until the PE reset is done.
>
>Do we ? Can't we just rely on "temp unavailble" result and wait 1s when
>that happens (then try again) ?
>
>IE, A delay associated with a state doesn't make that much sense
>semantically speaking. With a state *transition* maybe but this isn't
>what this function is about...
>
Sorry, Ben. I should have clarified more clearly: Basically, the EEH
core is going to be shared by: powernv, pseries on top of powernv or
phyp. While running pseries on top of phyp, we're getting PE state
through RTAS call "ibm,read-slot-reset-state2" and desired delay returned
from f/w for temporary unavailable PE. In the future, the function
ioda_eeh_get_state() will be called directly to emulate the RTAS call
for guest running on top of PowerNV.
So the answer is we can do it by makeing the assumption that f/w won't
return valid delay and we're going to use default value (1 second) for
guest on powernv or phyp, or we keep the delay here.
Thanks,
Gavin
^ permalink raw reply
* Re: [PATCH 15/27] powerpc/eeh: I/O chip EEH state retrieval
From: Benjamin Herrenschmidt @ 2013-06-13 4:42 UTC (permalink / raw)
To: Gavin Shan; +Cc: linuxppc-dev
In-Reply-To: <20130613042615.GA4045@shangw.(null)>
On Thu, 2013-06-13 at 12:26 +0800, Gavin Shan wrote:
> So the answer is we can do it by makeing the assumption that f/w won't
> return valid delay and we're going to use default value (1 second) for
> guest on powernv or phyp, or we keep the delay here.
Ok, at the very least then change the name to "unavailable_delay" or
something explicit like that then :-)
BTW. I've already applied patches 1 and 2 to my tree, you don't have to
resend those. They'll show up today or tomorrow when I push my next
branch out.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc/perf: Freeze PMC5/6 if we're not using them on Power8
From: Anshuman Khandual @ 2013-06-13 6:39 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
In-Reply-To: <1371086200-16778-1-git-send-email-michael@ellerman.id.au>
On 06/13/2013 06:46 AM, Michael Ellerman wrote:
> On Power8 we can freeze PMC5 and 6 if we're not using them. Normally they
> run all the time.
>
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
> ---
> arch/powerpc/include/asm/reg.h | 1 +
> arch/powerpc/perf/power8-pmu.c | 4 ++++
> 2 files changed, 5 insertions(+)
>
> diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
> index 4a9e408..362142b 100644
> --- a/arch/powerpc/include/asm/reg.h
> +++ b/arch/powerpc/include/asm/reg.h
> @@ -626,6 +626,7 @@
> #define MMCR0_TRIGGER 0x00002000UL /* TRIGGER enable */
> #define MMCR0_PMAO 0x00000080UL /* performance monitor alert has occurred, set to 0 after handling exception */
> #define MMCR0_SHRFC 0x00000040UL /* SHRre freeze conditions between threads */
> +#define MMCR0_FC56 0x00000010UL /* freeze counters 5 and 6 */
> #define MMCR0_FCTI 0x00000008UL /* freeze counters in tags inactive mode */
> #define MMCR0_FCTA 0x00000004UL /* freeze counters in tags active mode */
> #define MMCR0_FCWAIT 0x00000002UL /* freeze counter in WAIT state */
> diff --git a/arch/powerpc/perf/power8-pmu.c b/arch/powerpc/perf/power8-pmu.c
> index f7d1c4f..e791c68 100644
> --- a/arch/powerpc/perf/power8-pmu.c
> +++ b/arch/powerpc/perf/power8-pmu.c
> @@ -378,6 +378,10 @@ static int power8_compute_mmcr(u64 event[], int n_ev,
> if (pmc_inuse & 0x7c)
> mmcr[0] |= MMCR0_PMCjCE;
>
> + /* If we're not using PMC 5 or 6, freeze them */
> + if (!(pmc_inuse & 0x60))
> + mmcr[0] |= MMCR0_FC56;
> +
> mmcr[1] = mmcr1;
> mmcr[2] = mmcra;
>
Hey Michael,
This looks good. But we need to undo this changes when we terminate the perf session.
That way user would be able to continue reading PMC5 and PMC6 through /sys interface
as before (which may not be ideal). Adding the following changes along with this patch
would keep the status quo as it is.
diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index 29c6482..141756a 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -881,6 +881,12 @@ static void power_pmu_disable(struct pmu *pmu)
}
/*
+ * Undo PMC5/PMC6 freeze if already applied
+ */
+ if (mfspr(SPRN_MMCR0) & MMCR0_FC56)
+ mtspr(SPRN_MMCR0, mfspr(SPRN_MMCR0) & ~PMCR0_FC56)
+
+ /*
* Set the 'freeze counters' bit.
* The barrier is to make sure the mtspr has been
* executed and the PMU has frozen the events
Regards
Anshuman
^ permalink raw reply related
* Re: [PATCH] MDIO: FSL_PQ_MDIO: Fix bug on incorrect offset of tbipa register
From: Oded Gabbay @ 2013-06-13 6:44 UTC (permalink / raw)
To: Scott Wood, Sebastian Andrzej Siewior
Cc: stef.van.os, netdev, timur, Dongsheng.Wang, paulus, linuxppc-dev,
davem, linux-kernel, B38951
In-Reply-To: <1371061871.18413.44@snotra>
On 06/12/2013 09:31 PM, Scott Wood wrote:
> On 06/12/2013 10:08:29 AM, Sebastian Andrzej Siewior wrote:
>> On 06/12/2013 02:47 PM, Oded Gabbay wrote:
>> > This patch fixes a bug in the fsl_pq_mdio.c module and in relevant
>> device-tree
>> > files regarding the correct offset of the tbipa register in the eTSEC
>> > controller in some of Freescale's PQ3 and QorIQ SoC.
>> > The bug happens when the mdio in the device tree is configured to
>> be compatible
>> > to "fsl,gianfar-tbi". Because the mdio device in the device tree
>> points to
>> > addresses 25520, 26520 or 27520 (depends on the controller ID), the
>> variable
>> > priv->map at function fsl_pq_mdio_probe, points to that address.
>> However,
>> > later in the function there is a write to register tbipa that is
>> actually
>> > located at 25030, 26030 or 27030. Because the correct address is
>> not io mapped,
>> > the contents are written to a different register in the controller.
>> > The fix sets the address of the mdio device to start at 25000,
>> 26000 or 27000
>> > and changes the mii_offset field to 0x520 in the relevant entry
>> > (fsl,gianfar-tbi) of the fsl_pq_mdio_match array.
>> >
>> > Note: This patch may break MDIO functionallity of some old
>> Freescale's SoC
>> > until Freescale will fix their device tree files. Basically, every
>> device tree
>> > which contains an mdio device that is compatible to
>> "fsl,gianfar-tbi" should be
>> > examined.
>>
>> Not as is.
>> Please add a check for the original address. If it has 0x520 at the end
>> print a warning and fix it up. Please add to the patch description
>> which register is modified instead if this patch is not applied.
>> Depending on how critical this it might has to go stable.
>
> I'm not sure it's stable material if this is something that has never
> worked...
>
> The device tree binding will also need to be fixed to note the
> difference in "reg" between "fsl,gianfar-mdio" and "fsl-gianfar-tbi"
> -- and should give an example of the latter.
>
> -Scott
I read the 2 comments and I'm not sure what should be the best way to
move ahead.
I would like to describe what is the impact of not accepting this patch:
When you connect any eTSEC, except the first one, using SGMII, you must
configure the TBIPA register because
the MII management configuration uses the TBIPA address as part of the
SGMII initialization sequence,
as described in the P2020 Reference manual.
So, if that register is not initialized, the sequence is broken the and
eTSEC is not functioning (can not send/receive
packets).
I still think the best way to fix it is what I did:
1. Point the priv->map to the start of the whole registers range of the
eTSEC
2. Set mii_offset to 0x520 in the "gianfar-tbi" entry of the
"fsl_pq_mdio_match" array.
3. Fix all the usages of the "gianfar-tbi" in the device tree files -
change the starting address and reg range
I think this is the best way because it is stated in "fsl_pq_mdio_probe"
function that:
/*
* Some device tree nodes represent only the MII registers, and
* others represent the MAC and MII registers. The 'mii_offset' field
* contains the offset of the MII registers inside the mapped register
* space.
*/
and that's why we have priv->map and priv->regs. So my fix goes
according to the current design of the driver.
-Oded
^ permalink raw reply
* Re: [BUG] PCI related panic on powerpc based board with 3.10-rcX
From: Rojhalat Ibrahim @ 2013-06-13 7:21 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, linux-kernel, Michael Guntsche
In-Reply-To: <1371073826.18413.52@snotra>
On Wednesday 12 June 2013 16:50:26 Scott Wood wrote:
> On 06/12/2013 03:19:30 AM, Rojhalat Ibrahim wrote:
> > On Tuesday 11 June 2013 12:28:59 Scott Wood wrote:
> > > Yes, I figured it was non-PCIe because the code change that you said
> > > helped was on the non-PCIe branch of the if/else. Generally it's
> >
> > good
> >
> > > to explicitly mention the chip you're using, though.
> > >
> > > fsl_setup_indirect_pci should be renamed to fsl_setup_indirect_pcie.
> > > Your patch above should be applied, and fsl_setup_indirect_pcie
> >
> > should
> >
> > > be moved into the booke/86xx ifdef to avoid an unused function
> >
> > warning.
> >
> > > -Scott
> >
> > How about this patch? It uses setup_indirect_pci for the PCI case in
> > mpc83xx_add_bridge. Additionally it adds a check in
> > fsl_setup_indirect_pci
> > to only use the modified read function in case of PCIe.
>
> If we're adding the check to fsl_setup_indirect_pci, there's no need to
> change the 83xx call back to setup_indirect_pci. I see that 85xx is
> also callirng fsl_setup_indirect_pci for both; it'd be good to be
> consistent.
>
> In any case, can you send a proper patch with a signoff and commit
> message?
>
> -Scott
Where is it called for 85xx? As far as I can tell fsl_setup_indirect_pci is
called exactly once in fsl_add_bridge and nowhere else (after applying the
proposed patch).
For 83xx the decision between PCI and PCIe has already been made at
the point where the setup function is called. So IMO it doesn't make sense
to call fsl_setup_indirect_pci and do the check again. Moreover PCIe on 83xx
uses a completely different set of functions.
I'll send the proper patch in a separate mail.
Rojhalat
^ permalink raw reply
* [PATCH] powerpc/pci: Fix setup of Freescale PCI / PCIe controllers
From: Rojhalat Ibrahim @ 2013-06-13 7:53 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, linux-kernel, Michael Guntsche
Commit 50d8f87d2b3 (powerpc/fsl-pci Make PCIe hotplug work with Freescale
PCIe controllers) does not handle non-PCIe controllers properly, which causes
a panic during boot for certain configurations.
This patch fixes the issue for 83xx devices by calling the proper setup function.
For booke/86xx devices a check is added to differentiate between PCI and PCIe
controllers.
Reported-by: Michael Guntsche <mike@it-loops.com>
Cc: Scott Wood <scottwood@freescale.com>
Signed-off-by: Rojhalat Ibrahim <imr@rtschenk.de>
---
arch/powerpc/sysdev/fsl_pci.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 028ac1f..45670df 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -97,22 +97,23 @@ static int fsl_indirect_read_config(struct pci_bus *bus, unsigned int devfn,
return indirect_read_config(bus, devfn, offset, len, val);
}
-static struct pci_ops fsl_indirect_pci_ops =
+static struct pci_ops fsl_indirect_pcie_ops =
{
.read = fsl_indirect_read_config,
.write = indirect_write_config,
};
+#if defined(CONFIG_FSL_SOC_BOOKE) || defined(CONFIG_PPC_86xx)
+
static void __init fsl_setup_indirect_pci(struct pci_controller* hose,
resource_size_t cfg_addr,
resource_size_t cfg_data, u32 flags)
{
setup_indirect_pci(hose, cfg_addr, cfg_data, flags);
- hose->ops = &fsl_indirect_pci_ops;
+ if (early_find_capability(hose, 0, 0, PCI_CAP_ID_EXP)) /* PCIe */
+ hose->ops = &fsl_indirect_pcie_ops;
}
-#if defined(CONFIG_FSL_SOC_BOOKE) || defined(CONFIG_PPC_86xx)
-
#define MAX_PHYS_ADDR_BITS 40
static u64 pci64_dma_offset = 1ull << MAX_PHYS_ADDR_BITS;
@@ -814,8 +815,8 @@ int __init mpc83xx_add_bridge(struct device_node *dev)
if (ret)
goto err0;
} else {
- fsl_setup_indirect_pci(hose, rsrc_cfg.start,
- rsrc_cfg.start + 4, 0);
+ setup_indirect_pci(hose, rsrc_cfg.start,
+ rsrc_cfg.start + 4, 0);
}
printk(KERN_INFO "Found FSL PCI host bridge at 0x%016llx. "
--
1.8.1.5
^ permalink raw reply related
* Re: [RFC PATCH powerpc] Set cpu sibling mask before online cpu
From: Li Zhong @ 2013-06-13 9:42 UTC (permalink / raw)
To: Srivatsa S. Bhat; +Cc: Paul Mackerras, PowerPC email list, Nikunj A Dadhania
In-Reply-To: <51B6E0F4.6040008@linux.vnet.ibm.com>
On Tue, 2013-06-11 at 14:03 +0530, Srivatsa S. Bhat wrote:
> On 06/11/2013 12:30 PM, Benjamin Herrenschmidt wrote:
> > On Thu, 2013-05-16 at 18:20 +0800, Li Zhong wrote:
> >> It seems following race is possible:
> >>
> >
> > .../...
> >
> >> vdso_getcpu_init();
> >> #endif
> >> - notify_cpu_starting(cpu);
> >> - set_cpu_online(cpu, true);
> >> /* Update sibling maps */
> >> base = cpu_first_thread_sibling(cpu);
> >> for (i = 0; i < threads_per_core; i++) {
> >> - if (cpu_is_offline(base + i))
> >> + if (cpu_is_offline(base + i) && (cpu != base + i))
> >> continue;
> >> cpumask_set_cpu(cpu, cpu_sibling_mask(base + i));
> >> cpumask_set_cpu(base + i, cpu_sibling_mask(cpu));
> >> @@ -667,6 +665,10 @@ __cpuinit void start_secondary(void *unused)
> >> }
> >> of_node_put(l2_cache);
> >>
> >> + smp_wmb();
> >> + notify_cpu_starting(cpu);
> >> + set_cpu_online(cpu, true);
> >> +
> >
> > So we could have an online CPU with an empty sibling mask. Now we can
> > have a sibling that isn't online ... Is that ok ?
>
> I think it is OK. We do the same thing on x86 as well - we set up the
> sibling links before calling notify_cpu_starting() and setting the cpu
> in the cpu_online_mask. In fact, there is even a comment explicitly
> noting that order:
>
> arch/x86/kernel/smpboot.c:
> 220 /*
> 221 * This must be done before setting cpu_online_mask
> 222 * or calling notify_cpu_starting.
> 223 */
> 224 set_cpu_sibling_map(raw_smp_processor_id());
> 225 wmb();
> 226
> 227 notify_cpu_starting(cpuid);
> 228
> 229 /*
> 230 * Allow the master to continue.
> 231 */
> 232 cpumask_set_cpu(cpuid, cpu_callin_mask);
>
>
> So I agree with Li Zhong's solution.
>
> [Arch-specific CPU hotplug code consolidation efforts such as [1] would
> have weeded out such nasty bugs.. I guess we should revive that patchset
> sometime soon.]
>
Thank you both for the review and comments.
Good to know that it matches that of x86, and there is a patchset
consolidating the code. With the patches in [1], it seems we only need
the line to include the "to be onlined cpu" in this patch.
Thanks, Zhong
> Regards,
> Srivatsa S. Bhat
>
> [1]. https://lwn.net/Articles/500185/
>
^ permalink raw reply
* RE: [PATCH 1/2] powerpc: add Book E support to 64-bit hibernation
From: Wang Dongsheng-B40534 @ 2013-06-13 9:55 UTC (permalink / raw)
To: Wood Scott-B07421
Cc: johannes@sipsolutions.net, anton@enomsg.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1371074628.18413.53@snotra>
> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Thursday, June 13, 2013 6:04 AM
> To: Wang Dongsheng-B40534
> Cc: benh@kernel.crashing.org; johannes@sipsolutions.net; anton@enomsg.org=
;
> galak@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org; Wang Dongsheng-
> B40534
> Subject: Re: [PATCH 1/2] powerpc: add Book E support to 64-bit
> hibernation
>=20
> On 06/09/2013 05:37:39 AM, Wang Dongsheng wrote:
> > /* these macros rely on the save area being
> > * pointed to by r11 */
> > +
> > +#define SAVE_SPR(register) \
> > + mfspr r0,SPRN_##register ;\
> > + std r0,SL_##register(r11)
> > +#define RESTORE_SPR(register) \
> > + ld r0,SL_##register(r11) ;\
> > + mtspr SPRN_##register,r0
> > +#define RESTORE_SPRG(n) \
> > + ld r0,SL_SPRG##n(r11) ;\
> > + mtsprg n,r0
> > #define SAVE_SPECIAL(special) \
> > mf##special r0 ;\
> > std r0, SL_##special(r11)
>=20
> Is there a particular SPR that you're trying to save, for which
> SAVE_SPECIAL doesn't work?
>=20
Yes, like pid, tcr.
> > +#else
> > + /* Save SPRGs */
> > + RESTORE_SPRG(0)
> > + RESTORE_SPRG(1)
> > + RESTORE_SPRG(2)
> > + RESTORE_SPRG(3)
> > + RESTORE_SPRG(4)
> > + RESTORE_SPRG(5)
> > + RESTORE_SPRG(6)
> > + RESTORE_SPRG(7)
>=20
> Why do we need this on book3e and not on book3s?
>=20
Book3e: SPRG1 used save paca, SPRG2 be defined SPRN_SPRG_TLB_EXFRAME,...
I think those register should be save, even now some SPRG register not be u=
se.
Book3s: Sorry, I not clear why book3s not do this. I think Anton or Ben cou=
ld know the reason.
> > +
> > + RESTORE_SPECIAL(MSR)
> > +
> > + /* Restore TCR and clear any pending bits in TSR. */
> > + RESTORE_SPR(TCR)
> > + lis r0, (TSR_ENW | TSR_WIS | TSR_DIS | TSR_FIS)@h
> > + mtspr SPRN_TSR,r0
>=20
> Please be internally consistent with whitespace after commas, even if the
> rest of the file is already inconsistent. :-P
>=20
Thanks.
> > +
> > + /* Kick decrementer */
> > + li r0,1
> > + mtdec r0
>=20
> Why doesn't book3s need to kick the decrementer?
>=20
Sorry, I not clear why book3s not do this. I think Anton or Ben could know =
the reason.
> -Scott
^ permalink raw reply
* [PATCH] powerpc: Fix stack overflow crash in resume_kernel when ftracing
From: Michael Ellerman @ 2013-06-13 11:04 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Anton Blanchard, rostedt
It's possible for us to crash when running with ftrace enabled, eg:
Bad kernel stack pointer bffffd12 at c00000000000a454
cpu 0x3: Vector: 300 (Data Access) at [c00000000ffe3d40]
pc: c00000000000a454: resume_kernel+0x34/0x60
lr: c00000000000335c: performance_monitor_common+0x15c/0x180
sp: bffffd12
msr: 8000000000001032
dar: bffffd12
dsisr: 42000000
If we look at current's stack (paca->__current->stack) we see it is
equal to c0000002ecab0000. Our stack is 16K, and comparing to
paca->kstack (c0000002ecab3e30) we can see that we have overflowed our
kernel stack. This leads to us writing over our struct thread_info, and
in this case we have corrupted thread_info->flags and set
_TIF_EMULATE_STACK_STORE.
Dumping the stack we see:
3:mon> t c0000002ecab0000
[c0000002ecab0000] c00000000002131c .performance_monitor_exception+0x5c/0x70
[c0000002ecab0080] c00000000000335c performance_monitor_common+0x15c/0x180
--- Exception: f01 (Performance Monitor) at c0000000000fb2ec .trace_hardirqs_off+0x1c/0x30
[c0000002ecab0370] c00000000016fdb0 .trace_graph_entry+0xb0/0x280 (unreliable)
[c0000002ecab0410] c00000000003d038 .prepare_ftrace_return+0x98/0x130
[c0000002ecab04b0] c00000000000a920 .ftrace_graph_caller+0x14/0x28
[c0000002ecab0520] c0000000000d6b58 .idle_cpu+0x18/0x90
[c0000002ecab05a0] c00000000000a934 .return_to_handler+0x0/0x34
[c0000002ecab0620] c00000000001e660 .timer_interrupt+0x160/0x300
[c0000002ecab06d0] c0000000000025dc decrementer_common+0x15c/0x180
--- Exception: 901 (Decrementer) at c0000000000104d4 .arch_local_irq_restore+0x74/0xa0
[c0000002ecab09c0] c0000000000fe044 .trace_hardirqs_on+0x14/0x30 (unreliable)
[c0000002ecab0fb0] c00000000016fe3c .trace_graph_entry+0x13c/0x280
[c0000002ecab1050] c00000000003d038 .prepare_ftrace_return+0x98/0x130
[c0000002ecab10f0] c00000000000a920 .ftrace_graph_caller+0x14/0x28
[c0000002ecab1160] c0000000000161f0 .__ppc64_runlatch_on+0x10/0x40
[c0000002ecab11d0] c00000000000a934 .return_to_handler+0x0/0x34
--- Exception: 901 (Decrementer) at c0000000000104d4 .arch_local_irq_restore+0x74/0xa0
... and so on
__ppc64_runlatch_on() is called from RUNLATCH_ON in the exception entry
path. At that point the irq state is not consistent, ie. interrupts are
hard disabled (by the exception entry), but the paca soft-enabled flag
may be out of sync.
This leads to the local_irq_restore() in trace_graph_entry() actually
enabling interrupts, which we do not want. Because we have not yet
reprogrammed the decrementer we immediately take another decrementer
exception, and recurse.
The fix is twofold. Firstly make sure we call DISABLE_INTS before
calling RUNLATCH_ON. The badly named DISABLE_INTS actually reconciles
the irq state in the paca with the hardware, making it safe again to
call local_irq_save/restore().
Although that should be sufficient to fix the bug, we also mark the
runlatch routines as notrace. They are called very early in the
exception entry and we are asking for trouble tracing them. They are
also fairly uninteresting and tracing them just adds unnecessary
overhead.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/include/asm/exception-64s.h | 2 +-
arch/powerpc/kernel/process.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/exception-64s.h b/arch/powerpc/include/asm/exception-64s.h
index 8e5fae8..46793b5 100644
--- a/arch/powerpc/include/asm/exception-64s.h
+++ b/arch/powerpc/include/asm/exception-64s.h
@@ -513,7 +513,7 @@ label##_common: \
*/
#define STD_EXCEPTION_COMMON_ASYNC(trap, label, hdlr) \
EXCEPTION_COMMON(trap, label, hdlr, ret_from_except_lite, \
- FINISH_NAP;RUNLATCH_ON;DISABLE_INTS)
+ FINISH_NAP;DISABLE_INTS;RUNLATCH_ON)
/*
* When the idle code in power4_idle puts the CPU into NAP mode,
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index b0f3e3f..076d124 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -1369,7 +1369,7 @@ void show_stack(struct task_struct *tsk, unsigned long *stack)
#ifdef CONFIG_PPC64
/* Called with hard IRQs off */
-void __ppc64_runlatch_on(void)
+void notrace __ppc64_runlatch_on(void)
{
struct thread_info *ti = current_thread_info();
unsigned long ctrl;
@@ -1382,7 +1382,7 @@ void __ppc64_runlatch_on(void)
}
/* Called with hard IRQs off */
-void __ppc64_runlatch_off(void)
+void notrace __ppc64_runlatch_off(void)
{
struct thread_info *ti = current_thread_info();
unsigned long ctrl;
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH] powerpc/sysfs: disable hotplug for the boot cpu
From: Zhao Chenhui @ 2013-06-13 11:25 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1371007522.8250.169.camel@pasglop>
On Wed, Jun 12, 2013 at 01:25:22PM +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2013-06-03 at 18:43 +0800, Zhao Chenhui wrote:
> > On Sat, Jun 01, 2013 at 07:49:44AM +1000, Benjamin Herrenschmidt wrote:
> > > On Tue, 2013-05-28 at 15:59 +0800, Zhao Chenhui wrote:
> > > > Some features depend on the boot cpu, for instance, hibernate/suspend.
> > > > So disable hotplug for the boot cpu.
> > >
> > > Don't we have code to "move" the boot CPU around when that happens ?
> > >
> > > Ben.
> > >
> >
> > Currently, the code in generic_cpu_disable() likes this:
> >
> > if (cpu == boot_cpuid)
> > return -EBUSY;
>
> But the code in pseries/hotplug-cpu.c doesn't, we just "move" the boot
> CPU around when that happens. Any reason we can't do that generically ?
>
> Cheers,
> Ben.
>
Some multicore SoCs firstly boot up the cpu0 after warm reset.
In some suspend/resume cases, SoC will do a warm reset when resuming.
In order to ensure that the suspending and resuming is running
on a same cpu, cpu0 should be the last cpu to suspend. Here, cpu0 is
the boot_cpuid.
-Chenhui
> > If the dying cpu is the boot cpu, it will return -EBUSY. In the subsequent error handling,
> > cpu_notify_nofail(CPU_DOWN_FAILED) in _cpu_down() will be called. Unfortunately, some
> > cpu notifier callbacks handled CPU_DOWN_PREPARE, but not CPU_DOWN_FAILED, such as sched_cpu_inactive().
> > So it will cause issues.
> >
> > If we set the hotpluggable for the boot cpu, we can prevent user applications from disabling the boot cpu.
> >
> > -Chenhui
> >
^ permalink raw reply
* Re: [PATCH] powerpc: Fix stack overflow crash in resume_kernel when ftracing
From: Steven Rostedt @ 2013-06-13 12:45 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Anton Blanchard
In-Reply-To: <1371121496-16095-1-git-send-email-michael@ellerman.id.au>
On Thu, 2013-06-13 at 21:04 +1000, Michael Ellerman wrote:
> Although that should be sufficient to fix the bug, we also mark the
> runlatch routines as notrace. They are called very early in the
> exception entry and we are asking for trouble tracing them. They are
> also fairly uninteresting and tracing them just adds unnecessary
> overhead.
Note, I usually lean towards tracing everything that can be traced, and
only adding notrace to things that will actually cause a crash. If you
don't like them to be traced, you can always do:
echo '*__ppc64_runlatch_*'
> /sys/kernel/debug/tracing/set_ftrace_notrace
and that will keep them from being traced. You can also add it to the
kernel command line with: ftrace_notrace=*__ppc64_runlatch_* which will
also disable them on boot up.
Also trace-cmd has:
trace-cmd record -p function_graph -n '*__ppc64_runlatch_*'
that will do the same thing.
Hmm, I should add a way to disable things that are usually considered
noise. Perhaps add something like:
FTRACE_DEFAULT_OFF(__ppc64_runlatch_on);
That adds the function to a different section that places it into
another file that keeps it from being traced, but can be enabled when
you want it to.
-- Steve
^ permalink raw reply
* Re: [PATCH] powerpc: Fix stack overflow crash in resume_kernel when ftracing
From: Michael Ellerman @ 2013-06-13 14:31 UTC (permalink / raw)
To: Steven Rostedt; +Cc: linuxppc-dev, Anton Blanchard
In-Reply-To: <1371127506.9844.275.camel@gandalf.local.home>
On Thu, 2013-06-13 at 08:45 -0400, Steven Rostedt wrote:
> On Thu, 2013-06-13 at 21:04 +1000, Michael Ellerman wrote:
>
> > Although that should be sufficient to fix the bug, we also mark the
> > runlatch routines as notrace. They are called very early in the
> > exception entry and we are asking for trouble tracing them. They are
> > also fairly uninteresting and tracing them just adds unnecessary
> > overhead.
>
> Note, I usually lean towards tracing everything that can be traced, and
> only adding notrace to things that will actually cause a crash. If you
> don't like them to be traced, you can always do:
Yeah fair enough. In this case I think we don't want to trace it.
Although it doesn't cause a crash right now (at least after part 1 of
this patch), it's being called at a time when things are fragile, and
it's possible we could get bitten again some other way if the
surrounding code changes.
> echo '*__ppc64_runlatch_*'
> > /sys/kernel/debug/tracing/set_ftrace_notrace
>
> and that will keep them from being traced. You can also add it to the
> kernel command line with: ftrace_notrace=*__ppc64_runlatch_* which will
> also disable them on boot up.
>
> Also trace-cmd has:
>
> trace-cmd record -p function_graph -n '*__ppc64_runlatch_*'
>
> that will do the same thing.
>
> Hmm, I should add a way to disable things that are usually considered
> noise. Perhaps add something like:
>
>
> FTRACE_DEFAULT_OFF(__ppc64_runlatch_on);
>
> That adds the function to a different section that places it into
> another file that keeps it from being traced, but can be enabled when
> you want it to.
Yeah that would be cool.
Personally I'm just using shell scripts that poke the files in sysfs,
and I'm often running on different boxes, so the more that just works
without extra config by me the better.
cheers
^ permalink raw reply
* Re: [PATCH] powerpc: Fix stack overflow crash in resume_kernel when ftracing
From: Steven Rostedt @ 2013-06-13 14:46 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Anton Blanchard
In-Reply-To: <1371133862.23094.15.camel@concordia>
On Fri, 2013-06-14 at 00:31 +1000, Michael Ellerman wrote:
> On Thu, 2013-06-13 at 08:45 -0400, Steven Rostedt wrote:
> > On Thu, 2013-06-13 at 21:04 +1000, Michael Ellerman wrote:
> >
> > > Although that should be sufficient to fix the bug, we also mark the
> > > runlatch routines as notrace. They are called very early in the
> > > exception entry and we are asking for trouble tracing them. They are
> > > also fairly uninteresting and tracing them just adds unnecessary
> > > overhead.
> >
> > Note, I usually lean towards tracing everything that can be traced, and
> > only adding notrace to things that will actually cause a crash. If you
> > don't like them to be traced, you can always do:
>
> Yeah fair enough. In this case I think we don't want to trace it.
> Although it doesn't cause a crash right now (at least after part 1 of
> this patch), it's being called at a time when things are fragile, and
> it's possible we could get bitten again some other way if the
> surrounding code changes.
>
I wont push to trace it, as if it is fragile code, then it's best not to
risk it. Tracing is always a second class citizen in the kernel ;-)
>
> > echo '*__ppc64_runlatch_*'
> > > /sys/kernel/debug/tracing/set_ftrace_notrace
> >
> > and that will keep them from being traced. You can also add it to the
> > kernel command line with: ftrace_notrace=*__ppc64_runlatch_* which will
> > also disable them on boot up.
> >
> > Also trace-cmd has:
> >
> > trace-cmd record -p function_graph -n '*__ppc64_runlatch_*'
> >
> > that will do the same thing.
> >
> > Hmm, I should add a way to disable things that are usually considered
> > noise. Perhaps add something like:
> >
> >
> > FTRACE_DEFAULT_OFF(__ppc64_runlatch_on);
> >
> > That adds the function to a different section that places it into
> > another file that keeps it from being traced, but can be enabled when
> > you want it to.
>
> Yeah that would be cool.
>
> Personally I'm just using shell scripts that poke the files in sysfs,
> and I'm often running on different boxes, so the more that just works
> without extra config by me the better.
Agreed, which is why I hope to get something like this in. Perhaps I'll
aim for 3.12. Then we can look at all the functions with "notrace" and
see which can be converted.
Thanks,
-- Steve
^ permalink raw reply
* Re: [PATCH 15/27] powerpc/eeh: I/O chip EEH state retrieval
From: Gavin Shan @ 2013-06-13 5:50 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Gavin Shan
In-Reply-To: <1371098537.5555.0.camel@pasglop>
On Thu, Jun 13, 2013 at 02:42:17PM +1000, Benjamin Herrenschmidt wrote:
>On Thu, 2013-06-13 at 12:26 +0800, Gavin Shan wrote:
>> So the answer is we can do it by makeing the assumption that f/w won't
>> return valid delay and we're going to use default value (1 second) for
>> guest on powernv or phyp, or we keep the delay here.
>
>Ok, at the very least then change the name to "unavailable_delay" or
>something explicit like that then :-)
>
Ok.
>BTW. I've already applied patches 1 and 2 to my tree, you don't have to
>resend those. They'll show up today or tomorrow when I push my next
>branch out.
>
Ok. Thanks, Ben.
Thanks,
Gavin
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox