* [PATCH 5/5] arm: dts: aspeed: Add power9 CFAM dtsi and use it on OpenPower P9 machines
From: Benjamin Herrenschmidt @ 2018-07-24 4:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180724042406.15374-1-benh@kernel.crashing.org>
This provides proper chip IDs but also adds the various sub-devices
necessary for the future OCC driver among other. All the added nodes
comply with the existing upstream FSI bindings.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/arm/boot/dts/aspeed-bmc-opp-lanyang.dts | 1 +
arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts | 2 +
.../boot/dts/aspeed-bmc-opp-witherspoon.dts | 2 +
arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts | 2 +
arch/arm/boot/dts/ibm-power9-cfam.dtsi | 104 ++++++++++++++++++
arch/arm/boot/dts/ibm-power9-dual.dtsi | 58 ++++++++++
6 files changed, 169 insertions(+)
create mode 100644 arch/arm/boot/dts/ibm-power9-cfam.dtsi
create mode 100644 arch/arm/boot/dts/ibm-power9-dual.dtsi
diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-lanyang.dts b/arch/arm/boot/dts/aspeed-bmc-opp-lanyang.dts
index d598b6391362..e744d6532cbb 100644
--- a/arch/arm/boot/dts/aspeed-bmc-opp-lanyang.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-opp-lanyang.dts
@@ -323,3 +323,4 @@
status = "okay";
};
+#include "ibm-power9-dual.dtsi"
diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts b/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
index 852f264b9569..ead2a84f16bd 100644
--- a/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
@@ -282,3 +282,5 @@
&ibt {
status = "okay";
};
+
+#include "ibm-power9-dual.dtsi"
diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts b/arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts
index 656036106001..33ea336f0c17 100644
--- a/arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts
@@ -583,3 +583,5 @@
&ibt {
status = "okay";
};
+
+#include "ibm-power9-dual.dtsi"
diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts b/arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts
index 2c5aa90a546d..05df11cacb21 100644
--- a/arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts
@@ -435,3 +435,5 @@
&ibt {
status = "okay";
};
+
+#include "ibm-power9-dual.dtsi"
diff --git a/arch/arm/boot/dts/ibm-power9-cfam.dtsi b/arch/arm/boot/dts/ibm-power9-cfam.dtsi
new file mode 100644
index 000000000000..5bda517f93cc
--- /dev/null
+++ b/arch/arm/boot/dts/ibm-power9-cfam.dtsi
@@ -0,0 +1,104 @@
+// SPDX-License-Identifier: GPL-2.0+
+// Copyright 2018 IBM Corp
+
+#define __MAKE_LABEL(p,i) p##i
+#define _MAKE_LABEL(p,i) __MAKE_LABEL(p,i)
+#define HUB_LABEL _MAKE_LABEL(fsi_hub,CFAM_CHIP_ID)
+#define I2C_LABEL(n) _MAKE_LABEL(_MAKE_LABEL(cfam,CFAM_CHIP_ID),_i2c##n)
+
+#address-cells = <1>;
+#size-cells = <1>;
+chip-id = <CFAM_CHIP_ID>;
+
+scom at 1000 {
+ compatible = "ibm,fsi2pib";
+ reg = <0x1000 0x400>;
+};
+
+i2c at 1800 {
+ compatible = "ibm,fsi-i2c-master";
+ reg = <0x1800 0x400>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ I2C_LABEL(0): i2c-bus at 0 {
+ reg = <0>;
+ };
+
+ I2C_LABEL(1): i2c-bus at 1 {
+ reg = <1>;
+ };
+
+ I2C_LABEL(2): i2c-bus at 2 {
+ reg = <2>;
+ };
+
+ I2C_LABEL(3): i2c-bus at 3 {
+ reg = <3>;
+ };
+
+ I2C_LABEL(4): i2c-bus at 4 {
+ reg = <4>;
+ };
+
+ I2C_LABEL(5): i2c-bus at 5 {
+ reg = <5>;
+ };
+
+ I2C_LABEL(6): i2c-bus at 6 {
+ reg = <6>;
+ };
+
+ I2C_LABEL(7): i2c-bus at 7 {
+ reg = <7>;
+ };
+
+ I2C_LABEL(8): i2c-bus at 8 {
+ reg = <8>;
+ };
+
+ I2C_LABEL(9): i2c-bus at 9 {
+ reg = <9>;
+ };
+
+ I2C_LABEL(10): i2c-bus at 10 {
+ reg = <10>;
+ };
+
+ I2C_LABEL(11): i2c-bus at 11 {
+ reg = <11>;
+ };
+
+ I2C_LABEL(12): i2c-bus at 12 {
+ reg = <12>;
+ };
+
+ I2C_LABEL(13): i2c-bus at 13 {
+ reg = <13>;
+ };
+
+ I2C_LABEL(14): i2c-bus at 14 {
+ reg = <14>;
+ };
+};
+
+sbefifo at 2400 {
+ compatible = "ibm,p9-sbefifo";
+ reg = <0x2400 0x400>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+};
+
+HUB_LABEL: hub at 3400 {
+ compatible = "fsi-master-hub";
+ reg = <0x3400 0x400>;
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ no-scan-on-init;
+};
+
+#undef __MAKE_LABEL
+#undef _MAKE_LABEL
+#undef HUB_LABEL
+#undef I2C_LABEL
diff --git a/arch/arm/boot/dts/ibm-power9-dual.dtsi b/arch/arm/boot/dts/ibm-power9-dual.dtsi
new file mode 100644
index 000000000000..f6a82ad43ff8
--- /dev/null
+++ b/arch/arm/boot/dts/ibm-power9-dual.dtsi
@@ -0,0 +1,58 @@
+// SPDX-License-Identifier: GPL-2.0+
+// Copyright 2018 IBM Corp
+
+/* Instantiate chip 0 */
+#define CFAM_CHIP_ID 0
+&fsi {
+ cfam at 0,0 {
+ reg = <0 0>;
+ #include "ibm-power9-cfam.dtsi"
+ };
+};
+#undef CFAM_CHIP_ID
+
+/* Instantiate chip 1 */
+#define CFAM_CHIP_ID 1
+&fsi_hub0 {
+ cfam at 1,0 {
+ reg = <1 0>;
+ #include "ibm-power9-cfam.dtsi"
+ };
+};
+#undef CFAM_CHIP_ID
+
+/ {
+ aliases {
+ i2c100 = &cfam0_i2c0;
+ i2c101 = &cfam0_i2c1;
+ i2c102 = &cfam0_i2c2;
+ i2c103 = &cfam0_i2c3;
+ i2c104 = &cfam0_i2c4;
+ i2c105 = &cfam0_i2c5;
+ i2c106 = &cfam0_i2c6;
+ i2c107 = &cfam0_i2c7;
+ i2c108 = &cfam0_i2c8;
+ i2c109 = &cfam0_i2c9;
+ i2c110 = &cfam0_i2c10;
+ i2c111 = &cfam0_i2c11;
+ i2c112 = &cfam0_i2c12;
+ i2c113 = &cfam0_i2c13;
+ i2c114 = &cfam0_i2c14;
+ i2c200 = &cfam1_i2c0;
+ i2c201 = &cfam1_i2c1;
+ i2c202 = &cfam1_i2c2;
+ i2c203 = &cfam1_i2c3;
+ i2c204 = &cfam1_i2c4;
+ i2c205 = &cfam1_i2c5;
+ i2c206 = &cfam1_i2c6;
+ i2c207 = &cfam1_i2c7;
+ i2c208 = &cfam1_i2c8;
+ i2c209 = &cfam1_i2c9;
+ i2c210 = &cfam1_i2c10;
+ i2c211 = &cfam1_i2c11;
+ i2c212 = &cfam1_i2c12;
+ i2c213 = &cfam1_i2c13;
+ i2c214 = &cfam1_i2c14;
+ };
+};
+
--
2.17.1
^ permalink raw reply related
* [PATCH 5/5] arm: dts: aspeed: Add power9 CFAM dtsi and use it on OpenPower P9 machines
From: Benjamin Herrenschmidt @ 2018-07-24 4:24 UTC (permalink / raw)
To: linux-aspeed
In-Reply-To: <20180724042406.15374-1-benh@kernel.crashing.org>
This provides proper chip IDs but also adds the various sub-devices
necessary for the future OCC driver among other. All the added nodes
comply with the existing upstream FSI bindings.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/arm/boot/dts/aspeed-bmc-opp-lanyang.dts | 1 +
arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts | 2 +
.../boot/dts/aspeed-bmc-opp-witherspoon.dts | 2 +
arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts | 2 +
arch/arm/boot/dts/ibm-power9-cfam.dtsi | 104 ++++++++++++++++++
arch/arm/boot/dts/ibm-power9-dual.dtsi | 58 ++++++++++
6 files changed, 169 insertions(+)
create mode 100644 arch/arm/boot/dts/ibm-power9-cfam.dtsi
create mode 100644 arch/arm/boot/dts/ibm-power9-dual.dtsi
diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-lanyang.dts b/arch/arm/boot/dts/aspeed-bmc-opp-lanyang.dts
index d598b6391362..e744d6532cbb 100644
--- a/arch/arm/boot/dts/aspeed-bmc-opp-lanyang.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-opp-lanyang.dts
@@ -323,3 +323,4 @@
status = "okay";
};
+#include "ibm-power9-dual.dtsi"
diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts b/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
index 852f264b9569..ead2a84f16bd 100644
--- a/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
@@ -282,3 +282,5 @@
&ibt {
status = "okay";
};
+
+#include "ibm-power9-dual.dtsi"
diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts b/arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts
index 656036106001..33ea336f0c17 100644
--- a/arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts
@@ -583,3 +583,5 @@
&ibt {
status = "okay";
};
+
+#include "ibm-power9-dual.dtsi"
diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts b/arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts
index 2c5aa90a546d..05df11cacb21 100644
--- a/arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-opp-zaius.dts
@@ -435,3 +435,5 @@
&ibt {
status = "okay";
};
+
+#include "ibm-power9-dual.dtsi"
diff --git a/arch/arm/boot/dts/ibm-power9-cfam.dtsi b/arch/arm/boot/dts/ibm-power9-cfam.dtsi
new file mode 100644
index 000000000000..5bda517f93cc
--- /dev/null
+++ b/arch/arm/boot/dts/ibm-power9-cfam.dtsi
@@ -0,0 +1,104 @@
+// SPDX-License-Identifier: GPL-2.0+
+// Copyright 2018 IBM Corp
+
+#define __MAKE_LABEL(p,i) p##i
+#define _MAKE_LABEL(p,i) __MAKE_LABEL(p,i)
+#define HUB_LABEL _MAKE_LABEL(fsi_hub,CFAM_CHIP_ID)
+#define I2C_LABEL(n) _MAKE_LABEL(_MAKE_LABEL(cfam,CFAM_CHIP_ID),_i2c##n)
+
+#address-cells = <1>;
+#size-cells = <1>;
+chip-id = <CFAM_CHIP_ID>;
+
+scom at 1000 {
+ compatible = "ibm,fsi2pib";
+ reg = <0x1000 0x400>;
+};
+
+i2c at 1800 {
+ compatible = "ibm,fsi-i2c-master";
+ reg = <0x1800 0x400>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ I2C_LABEL(0): i2c-bus at 0 {
+ reg = <0>;
+ };
+
+ I2C_LABEL(1): i2c-bus at 1 {
+ reg = <1>;
+ };
+
+ I2C_LABEL(2): i2c-bus at 2 {
+ reg = <2>;
+ };
+
+ I2C_LABEL(3): i2c-bus at 3 {
+ reg = <3>;
+ };
+
+ I2C_LABEL(4): i2c-bus at 4 {
+ reg = <4>;
+ };
+
+ I2C_LABEL(5): i2c-bus at 5 {
+ reg = <5>;
+ };
+
+ I2C_LABEL(6): i2c-bus at 6 {
+ reg = <6>;
+ };
+
+ I2C_LABEL(7): i2c-bus at 7 {
+ reg = <7>;
+ };
+
+ I2C_LABEL(8): i2c-bus at 8 {
+ reg = <8>;
+ };
+
+ I2C_LABEL(9): i2c-bus at 9 {
+ reg = <9>;
+ };
+
+ I2C_LABEL(10): i2c-bus at 10 {
+ reg = <10>;
+ };
+
+ I2C_LABEL(11): i2c-bus at 11 {
+ reg = <11>;
+ };
+
+ I2C_LABEL(12): i2c-bus at 12 {
+ reg = <12>;
+ };
+
+ I2C_LABEL(13): i2c-bus at 13 {
+ reg = <13>;
+ };
+
+ I2C_LABEL(14): i2c-bus at 14 {
+ reg = <14>;
+ };
+};
+
+sbefifo at 2400 {
+ compatible = "ibm,p9-sbefifo";
+ reg = <0x2400 0x400>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+};
+
+HUB_LABEL: hub at 3400 {
+ compatible = "fsi-master-hub";
+ reg = <0x3400 0x400>;
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ no-scan-on-init;
+};
+
+#undef __MAKE_LABEL
+#undef _MAKE_LABEL
+#undef HUB_LABEL
+#undef I2C_LABEL
diff --git a/arch/arm/boot/dts/ibm-power9-dual.dtsi b/arch/arm/boot/dts/ibm-power9-dual.dtsi
new file mode 100644
index 000000000000..f6a82ad43ff8
--- /dev/null
+++ b/arch/arm/boot/dts/ibm-power9-dual.dtsi
@@ -0,0 +1,58 @@
+// SPDX-License-Identifier: GPL-2.0+
+// Copyright 2018 IBM Corp
+
+/* Instantiate chip 0 */
+#define CFAM_CHIP_ID 0
+&fsi {
+ cfam at 0,0 {
+ reg = <0 0>;
+ #include "ibm-power9-cfam.dtsi"
+ };
+};
+#undef CFAM_CHIP_ID
+
+/* Instantiate chip 1 */
+#define CFAM_CHIP_ID 1
+&fsi_hub0 {
+ cfam at 1,0 {
+ reg = <1 0>;
+ #include "ibm-power9-cfam.dtsi"
+ };
+};
+#undef CFAM_CHIP_ID
+
+/ {
+ aliases {
+ i2c100 = &cfam0_i2c0;
+ i2c101 = &cfam0_i2c1;
+ i2c102 = &cfam0_i2c2;
+ i2c103 = &cfam0_i2c3;
+ i2c104 = &cfam0_i2c4;
+ i2c105 = &cfam0_i2c5;
+ i2c106 = &cfam0_i2c6;
+ i2c107 = &cfam0_i2c7;
+ i2c108 = &cfam0_i2c8;
+ i2c109 = &cfam0_i2c9;
+ i2c110 = &cfam0_i2c10;
+ i2c111 = &cfam0_i2c11;
+ i2c112 = &cfam0_i2c12;
+ i2c113 = &cfam0_i2c13;
+ i2c114 = &cfam0_i2c14;
+ i2c200 = &cfam1_i2c0;
+ i2c201 = &cfam1_i2c1;
+ i2c202 = &cfam1_i2c2;
+ i2c203 = &cfam1_i2c3;
+ i2c204 = &cfam1_i2c4;
+ i2c205 = &cfam1_i2c5;
+ i2c206 = &cfam1_i2c6;
+ i2c207 = &cfam1_i2c7;
+ i2c208 = &cfam1_i2c8;
+ i2c209 = &cfam1_i2c9;
+ i2c210 = &cfam1_i2c10;
+ i2c211 = &cfam1_i2c11;
+ i2c212 = &cfam1_i2c12;
+ i2c213 = &cfam1_i2c13;
+ i2c214 = &cfam1_i2c14;
+ };
+};
+
--
2.17.1
^ permalink raw reply related
* [PATCH 4/5] arm: dts: Add power8 CFAM dtsi and use it on palmetto
From: Benjamin Herrenschmidt @ 2018-07-24 4:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180724042406.15374-1-benh@kernel.crashing.org>
So we get proper chip-id
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts | 10 ++++++
arch/arm/boot/dts/ibm-power8-cfam.dtsi | 31 +++++++++++++++++++
2 files changed, 41 insertions(+)
create mode 100644 arch/arm/boot/dts/ibm-power8-cfam.dtsi
diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts b/arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts
index e6cfdf3c1a67..e264d817978c 100644
--- a/arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts
@@ -331,3 +331,13 @@
line-name = "BMC_TPM_INT_N";
};
};
+
+/* Instantiate chip 0 */
+#define CFAM_CHIP_ID 0
+&fsi {
+ cfam at 0,0 {
+ reg = <0 0>;
+ #include "ibm-power8-cfam.dtsi"
+ };
+};
+#undef CFAM_CHIP_ID
diff --git a/arch/arm/boot/dts/ibm-power8-cfam.dtsi b/arch/arm/boot/dts/ibm-power8-cfam.dtsi
new file mode 100644
index 000000000000..a07e9509d9bd
--- /dev/null
+++ b/arch/arm/boot/dts/ibm-power8-cfam.dtsi
@@ -0,0 +1,31 @@
+// SPDX-License-Identifier: GPL-2.0+
+// Copyright 2018 IBM Corp
+
+#define __MAKE_LABEL(p,i) p##i
+#define _MAKE_LABEL(p,i) __MAKE_LABEL(p,i)
+#define HUB_LABEL _MAKE_LABEL(fsi_hub,CFAM_CHIP_ID)
+#define OCC_LABEL _MAKE_LABEL(fsi_occ,CFAM_CHIP_ID)
+#define I2C_LABEL(n) _MAKE_LABEL(_MAKE_LABEL(cfam,CFAM_CHIP_ID),_i2c##n)
+
+#address-cells = <1>;
+#size-cells = <1>;
+chip-id = <CFAM_CHIP_ID>;
+
+scom at 1000 {
+ compatible = "ibm,fsi2pib";
+ reg = <0x1000 0x400>;
+};
+
+HUB_LABEL: hub at 3400 {
+ compatible = "ibm,fsi-master-hub";
+ reg = <0x3400 0x400>;
+ #address-cells = <2>;
+ #size-cells = <0>;
+ no-scan-on-init;
+};
+
+#undef __MAKE_LABEL
+#undef _MAKE_LABEL
+#undef HUB_LABEL
+#undef OCC_LABEL
+#undef I2C_LABEL
--
2.17.1
^ permalink raw reply related
* [PATCH 4/5] arm: dts: Add power8 CFAM dtsi and use it on palmetto
From: Benjamin Herrenschmidt @ 2018-07-24 4:24 UTC (permalink / raw)
To: linux-aspeed
In-Reply-To: <20180724042406.15374-1-benh@kernel.crashing.org>
So we get proper chip-id
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts | 10 ++++++
arch/arm/boot/dts/ibm-power8-cfam.dtsi | 31 +++++++++++++++++++
2 files changed, 41 insertions(+)
create mode 100644 arch/arm/boot/dts/ibm-power8-cfam.dtsi
diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts b/arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts
index e6cfdf3c1a67..e264d817978c 100644
--- a/arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts
@@ -331,3 +331,13 @@
line-name = "BMC_TPM_INT_N";
};
};
+
+/* Instantiate chip 0 */
+#define CFAM_CHIP_ID 0
+&fsi {
+ cfam at 0,0 {
+ reg = <0 0>;
+ #include "ibm-power8-cfam.dtsi"
+ };
+};
+#undef CFAM_CHIP_ID
diff --git a/arch/arm/boot/dts/ibm-power8-cfam.dtsi b/arch/arm/boot/dts/ibm-power8-cfam.dtsi
new file mode 100644
index 000000000000..a07e9509d9bd
--- /dev/null
+++ b/arch/arm/boot/dts/ibm-power8-cfam.dtsi
@@ -0,0 +1,31 @@
+// SPDX-License-Identifier: GPL-2.0+
+// Copyright 2018 IBM Corp
+
+#define __MAKE_LABEL(p,i) p##i
+#define _MAKE_LABEL(p,i) __MAKE_LABEL(p,i)
+#define HUB_LABEL _MAKE_LABEL(fsi_hub,CFAM_CHIP_ID)
+#define OCC_LABEL _MAKE_LABEL(fsi_occ,CFAM_CHIP_ID)
+#define I2C_LABEL(n) _MAKE_LABEL(_MAKE_LABEL(cfam,CFAM_CHIP_ID),_i2c##n)
+
+#address-cells = <1>;
+#size-cells = <1>;
+chip-id = <CFAM_CHIP_ID>;
+
+scom at 1000 {
+ compatible = "ibm,fsi2pib";
+ reg = <0x1000 0x400>;
+};
+
+HUB_LABEL: hub at 3400 {
+ compatible = "ibm,fsi-master-hub";
+ reg = <0x3400 0x400>;
+ #address-cells = <2>;
+ #size-cells = <0>;
+ no-scan-on-init;
+};
+
+#undef __MAKE_LABEL
+#undef _MAKE_LABEL
+#undef HUB_LABEL
+#undef OCC_LABEL
+#undef I2C_LABEL
--
2.17.1
^ permalink raw reply related
* [PATCH 3/5] arm: dts: OpenPower Palmetto system can use coprocessor for FSI
From: Benjamin Herrenschmidt @ 2018-07-24 4:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180724042406.15374-1-benh@kernel.crashing.org>
This switches away from userspace bitbanging to kernel FSI
using the coprocessor.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts | 28 ++++++++++++++-----
1 file changed, 21 insertions(+), 7 deletions(-)
diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts b/arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts
index c7084a819dc6..e6cfdf3c1a67 100644
--- a/arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts
@@ -26,6 +26,11 @@
no-map;
reg = <0x5f000000 0x01000000>; /* 16M */
};
+
+ coldfire_memory: codefire_memory at 5ee00000 {
+ reg = <0x5ee00000 0x00200000>;
+ no-map;
+ };
};
leds {
@@ -44,6 +49,22 @@
};
};
+ fsi: gpio-fsi {
+ compatible = "aspeed,ast2400-cf-fsi-master", "fsi-master";
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ memory-region = <&coldfire_memory>;
+ aspeed,sram = <&sram>;
+ aspeed,cvic = <&cvic>;
+
+ clock-gpios = <&gpio ASPEED_GPIO(A, 4) GPIO_ACTIVE_HIGH>;
+ data-gpios = <&gpio ASPEED_GPIO(A, 5) GPIO_ACTIVE_HIGH>;
+ mux-gpios = <&gpio ASPEED_GPIO(A, 6) GPIO_ACTIVE_HIGH>;
+ enable-gpios = <&gpio ASPEED_GPIO(D, 0) GPIO_ACTIVE_HIGH>;
+ trans-gpios = <&gpio ASPEED_GPIO(H, 6) GPIO_ACTIVE_HIGH>;
+ };
+
gpio-keys {
compatible = "gpio-keys";
@@ -303,13 +324,6 @@
line-name = "SYS_PWROK_BMC";
};
- pin_gpio_h6 {
- gpio-hog;
- gpios = <ASPEED_GPIO(H, 6) GPIO_ACTIVE_HIGH>;
- output-high;
- line-name = "SCM1_FSI0_DATA_EN";
- };
-
pin_gpio_h7 {
gpio-hog;
gpios = <ASPEED_GPIO(H, 7) GPIO_ACTIVE_HIGH>;
--
2.17.1
^ permalink raw reply related
* [PATCH 3/5] arm: dts: OpenPower Palmetto system can use coprocessor for FSI
From: Benjamin Herrenschmidt @ 2018-07-24 4:24 UTC (permalink / raw)
To: linux-aspeed
In-Reply-To: <20180724042406.15374-1-benh@kernel.crashing.org>
This switches away from userspace bitbanging to kernel FSI
using the coprocessor.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts | 28 ++++++++++++++-----
1 file changed, 21 insertions(+), 7 deletions(-)
diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts b/arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts
index c7084a819dc6..e6cfdf3c1a67 100644
--- a/arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts
@@ -26,6 +26,11 @@
no-map;
reg = <0x5f000000 0x01000000>; /* 16M */
};
+
+ coldfire_memory: codefire_memory at 5ee00000 {
+ reg = <0x5ee00000 0x00200000>;
+ no-map;
+ };
};
leds {
@@ -44,6 +49,22 @@
};
};
+ fsi: gpio-fsi {
+ compatible = "aspeed,ast2400-cf-fsi-master", "fsi-master";
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ memory-region = <&coldfire_memory>;
+ aspeed,sram = <&sram>;
+ aspeed,cvic = <&cvic>;
+
+ clock-gpios = <&gpio ASPEED_GPIO(A, 4) GPIO_ACTIVE_HIGH>;
+ data-gpios = <&gpio ASPEED_GPIO(A, 5) GPIO_ACTIVE_HIGH>;
+ mux-gpios = <&gpio ASPEED_GPIO(A, 6) GPIO_ACTIVE_HIGH>;
+ enable-gpios = <&gpio ASPEED_GPIO(D, 0) GPIO_ACTIVE_HIGH>;
+ trans-gpios = <&gpio ASPEED_GPIO(H, 6) GPIO_ACTIVE_HIGH>;
+ };
+
gpio-keys {
compatible = "gpio-keys";
@@ -303,13 +324,6 @@
line-name = "SYS_PWROK_BMC";
};
- pin_gpio_h6 {
- gpio-hog;
- gpios = <ASPEED_GPIO(H, 6) GPIO_ACTIVE_HIGH>;
- output-high;
- line-name = "SCM1_FSI0_DATA_EN";
- };
-
pin_gpio_h7 {
gpio-hog;
gpios = <ASPEED_GPIO(H, 7) GPIO_ACTIVE_HIGH>;
--
2.17.1
^ permalink raw reply related
* [PATCH 2/5] arm: dts: OpenPower Romulus system can use coprocessor for FSI
From: Benjamin Herrenschmidt @ 2018-07-24 4:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180724042406.15374-1-benh@kernel.crashing.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts b/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
index 0b9b37d4d6ef..852f264b9569 100644
--- a/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
@@ -30,6 +30,11 @@
no-map;
reg = <0x98000000 0x04000000>; /* 64M */
};
+
+ coldfire_memory: codefire_memory at 9ef00000 {
+ reg = <0x9ef00000 0x00100000>;
+ no-map;
+ };
};
leds {
@@ -49,10 +54,13 @@
};
fsi: gpio-fsi {
- compatible = "fsi-master-gpio", "fsi-master";
+ compatible = "aspeed,ast2500-cf-fsi-master", "fsi-master";
#address-cells = <2>;
#size-cells = <0>;
- no-gpio-delays;
+
+ memory-region = <&coldfire_memory>;
+ aspeed,sram = <&sram>;
+ aspeed,cvic = <&cvic>;
clock-gpios = <&gpio ASPEED_GPIO(AA, 0) GPIO_ACTIVE_HIGH>;
data-gpios = <&gpio ASPEED_GPIO(AA, 2) GPIO_ACTIVE_HIGH>;
--
2.17.1
^ permalink raw reply related
* [PATCH 2/5] arm: dts: OpenPower Romulus system can use coprocessor for FSI
From: Benjamin Herrenschmidt @ 2018-07-24 4:24 UTC (permalink / raw)
To: linux-aspeed
In-Reply-To: <20180724042406.15374-1-benh@kernel.crashing.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts b/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
index 0b9b37d4d6ef..852f264b9569 100644
--- a/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
@@ -30,6 +30,11 @@
no-map;
reg = <0x98000000 0x04000000>; /* 64M */
};
+
+ coldfire_memory: codefire_memory at 9ef00000 {
+ reg = <0x9ef00000 0x00100000>;
+ no-map;
+ };
};
leds {
@@ -49,10 +54,13 @@
};
fsi: gpio-fsi {
- compatible = "fsi-master-gpio", "fsi-master";
+ compatible = "aspeed,ast2500-cf-fsi-master", "fsi-master";
#address-cells = <2>;
#size-cells = <0>;
- no-gpio-delays;
+
+ memory-region = <&coldfire_memory>;
+ aspeed,sram = <&sram>;
+ aspeed,cvic = <&cvic>;
clock-gpios = <&gpio ASPEED_GPIO(AA, 0) GPIO_ACTIVE_HIGH>;
data-gpios = <&gpio ASPEED_GPIO(AA, 2) GPIO_ACTIVE_HIGH>;
--
2.17.1
^ permalink raw reply related
* [PATCH 1/5] arm: dts: aspeed: Add coprocessor interrupt controller
From: Benjamin Herrenschmidt @ 2018-07-24 4:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180724042406.15374-1-benh@kernel.crashing.org>
Add the missing node for the CVIC (the coprocessor interrupt
controller) and add a label to the SRAM node so it can be
referenced from the board device-tree file.
OpenBMC-Staging-Count: 1
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Joel Stanley <joel@jms.id.au>
---
arch/arm/boot/dts/aspeed-g4.dtsi | 8 +++++++-
arch/arm/boot/dts/aspeed-g5.dtsi | 9 ++++++++-
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/aspeed-g4.dtsi b/arch/arm/boot/dts/aspeed-g4.dtsi
index 75df1573380e..b1a19f99a4c9 100644
--- a/arch/arm/boot/dts/aspeed-g4.dtsi
+++ b/arch/arm/boot/dts/aspeed-g4.dtsi
@@ -92,6 +92,12 @@
reg = <0x1e6c0080 0x80>;
};
+ cvic: copro-interrupt-controller at 1e6c2000 {
+ compatible = "aspeed,ast2400-cvic", "aspeed-cvic";
+ valid-sources = <0x7fffffff>;
+ reg = <0x1e6c2000 0x80>;
+ };
+
mac0: ethernet at 1e660000 {
compatible = "aspeed,ast2400-mac", "faraday,ftgmac100";
reg = <0x1e660000 0x180>;
@@ -161,7 +167,7 @@
status = "disabled";
};
- sram at 1e720000 {
+ sram: sram at 1e720000 {
compatible = "mmio-sram";
reg = <0x1e720000 0x8000>; // 32K
};
diff --git a/arch/arm/boot/dts/aspeed-g5.dtsi b/arch/arm/boot/dts/aspeed-g5.dtsi
index 17f2714d18a7..21141ca1bfa4 100644
--- a/arch/arm/boot/dts/aspeed-g5.dtsi
+++ b/arch/arm/boot/dts/aspeed-g5.dtsi
@@ -127,6 +127,13 @@
reg = <0x1e6c0080 0x80>;
};
+ cvic: copro-interrupt-controller at 1e6c2000 {
+ compatible = "aspeed,ast2500-cvic", "aspeed-cvic";
+ valid-sources = <0xffffffff>;
+ copro-sw-interrupts = <1>;
+ reg = <0x1e6c2000 0x80>;
+ };
+
mac0: ethernet at 1e660000 {
compatible = "aspeed,ast2500-mac", "faraday,ftgmac100";
reg = <0x1e660000 0x180>;
@@ -211,7 +218,7 @@
status = "disabled";
};
- sram at 1e720000 {
+ sram: sram at 1e720000 {
compatible = "mmio-sram";
reg = <0x1e720000 0x9000>; // 36K
};
--
2.17.1
^ permalink raw reply related
* [PATCH 1/5] arm: dts: aspeed: Add coprocessor interrupt controller
From: Benjamin Herrenschmidt @ 2018-07-24 4:24 UTC (permalink / raw)
To: linux-aspeed
In-Reply-To: <20180724042406.15374-1-benh@kernel.crashing.org>
Add the missing node for the CVIC (the coprocessor interrupt
controller) and add a label to the SRAM node so it can be
referenced from the board device-tree file.
OpenBMC-Staging-Count: 1
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Joel Stanley <joel@jms.id.au>
---
arch/arm/boot/dts/aspeed-g4.dtsi | 8 +++++++-
arch/arm/boot/dts/aspeed-g5.dtsi | 9 ++++++++-
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/aspeed-g4.dtsi b/arch/arm/boot/dts/aspeed-g4.dtsi
index 75df1573380e..b1a19f99a4c9 100644
--- a/arch/arm/boot/dts/aspeed-g4.dtsi
+++ b/arch/arm/boot/dts/aspeed-g4.dtsi
@@ -92,6 +92,12 @@
reg = <0x1e6c0080 0x80>;
};
+ cvic: copro-interrupt-controller at 1e6c2000 {
+ compatible = "aspeed,ast2400-cvic", "aspeed-cvic";
+ valid-sources = <0x7fffffff>;
+ reg = <0x1e6c2000 0x80>;
+ };
+
mac0: ethernet at 1e660000 {
compatible = "aspeed,ast2400-mac", "faraday,ftgmac100";
reg = <0x1e660000 0x180>;
@@ -161,7 +167,7 @@
status = "disabled";
};
- sram at 1e720000 {
+ sram: sram at 1e720000 {
compatible = "mmio-sram";
reg = <0x1e720000 0x8000>; // 32K
};
diff --git a/arch/arm/boot/dts/aspeed-g5.dtsi b/arch/arm/boot/dts/aspeed-g5.dtsi
index 17f2714d18a7..21141ca1bfa4 100644
--- a/arch/arm/boot/dts/aspeed-g5.dtsi
+++ b/arch/arm/boot/dts/aspeed-g5.dtsi
@@ -127,6 +127,13 @@
reg = <0x1e6c0080 0x80>;
};
+ cvic: copro-interrupt-controller at 1e6c2000 {
+ compatible = "aspeed,ast2500-cvic", "aspeed-cvic";
+ valid-sources = <0xffffffff>;
+ copro-sw-interrupts = <1>;
+ reg = <0x1e6c2000 0x80>;
+ };
+
mac0: ethernet at 1e660000 {
compatible = "aspeed,ast2500-mac", "faraday,ftgmac100";
reg = <0x1e660000 0x180>;
@@ -211,7 +218,7 @@
status = "disabled";
};
- sram at 1e720000 {
+ sram: sram at 1e720000 {
compatible = "mmio-sram";
reg = <0x1e720000 0x9000>; // 36K
};
--
2.17.1
^ permalink raw reply related
* [PATCH 0/5] arm: dts: aspeed DTS updates for OpenPower
From: Benjamin Herrenschmidt @ 2018-07-24 4:24 UTC (permalink / raw)
To: linux-arm-kernel
These are DTS updates for Aspeed SoCs used on OpenPower systems.
They should comply with existing bindings either upstream, in
linux-next or about to be pulled into linux-next, and that have
been acked by Rob.
- Add the "cvic" node for the coprocessor interrupt controller
to the Aspeed G4 and G5 SoC .dtsi files.
- Switch OpenPower Romulus and Palmetto systems from using the
Linux bitbang GPIO FSI master to using the new ColdFire coprocessor
based one which is much faster (driver about to hit linux-next)
- Add a basic definition of the POWER8 and POWER9 processors
as seen on an FSI bus by the BMC. Not every device in there is
exposed yet. More devices will be added as their drivers and
bindings get finalized.
^ permalink raw reply
* [PATCH 0/5] arm: dts: aspeed DTS updates for OpenPower
From: Benjamin Herrenschmidt @ 2018-07-24 4:24 UTC (permalink / raw)
To: linux-aspeed
These are DTS updates for Aspeed SoCs used on OpenPower systems.
They should comply with existing bindings either upstream, in
linux-next or about to be pulled into linux-next, and that have
been acked by Rob.
- Add the "cvic" node for the coprocessor interrupt controller
to the Aspeed G4 and G5 SoC .dtsi files.
- Switch OpenPower Romulus and Palmetto systems from using the
Linux bitbang GPIO FSI master to using the new ColdFire coprocessor
based one which is much faster (driver about to hit linux-next)
- Add a basic definition of the POWER8 and POWER9 processors
as seen on an FSI bus by the BMC. Not every device in there is
exposed yet. More devices will be added as their drivers and
bindings get finalized.
^ permalink raw reply
* Re: [PATCH v4 net-next 2/3] rds: Enable RDS IPv6 support
From: Ka-Cheong Poon @ 2018-07-24 3:18 UTC (permalink / raw)
To: David Miller; +Cc: netdev, santosh.shilimkar, rds-devel, sowmini.varadhan
In-Reply-To: <20180723.111545.2052989865778508499.davem@davemloft.net>
On 07/24/2018 02:15 AM, David Miller wrote:
> From: Ka-Cheong Poon <ka-cheong.poon@oracle.com>
> Date: Mon, 23 Jul 2018 07:16:11 -0700
>
>> @@ -163,15 +165,29 @@ int rds_tcp_accept_one(struct socket *sock)
>>
>> inet = inet_sk(new_sock->sk);
>>
>> + my_addr = &new_sock->sk->sk_v6_rcv_saddr;
>> + peer_addr = &new_sock->sk->sk_v6_daddr,
>> rdsdebug("accepted tcp %pI6c:%u -> %pI6c:%u\n",
>
> Note that comma, instead of a semicolon, at the end of the peer_addr
> assignment.
>
> This doesn't even compile.
Strange, the compiler did not complain. Will check why's
that.
Thanks.
--
K. Poon
ka-cheong.poon@oracle.com
^ permalink raw reply
* Re: [PATCH v1 0/3] [RFC] Speeding up checkout (and merge, rebase, etc)
From: Jeff King @ 2018-07-24 4:20 UTC (permalink / raw)
To: Ben Peart; +Cc: Duy Nguyen, Ben Peart, Git Mailing List, Junio C Hamano
In-Reply-To: <6ff6fbdc-d9cf-019f-317c-7fdba31105c6@gmail.com>
On Mon, Jul 23, 2018 at 04:51:38PM -0400, Ben Peart wrote:
> > Hmm.. this means cache-tree is fully valid, unless you have changes in
> > index. We're quite aggressive in repairing cache-tree since aecf567cbf
> > (cache-tree: create/update cache-tree on checkout - 2014-07-05). If we
> > have very good cache-tree records and still spend 33s on
> > traverse_trees, maybe there's something else.
>
> I'm not at all familiar with the cache-tree and couldn't find any
> documentation on it other than index-format.txt which says "it helps speed
> up tree object generation for a new commit." In this particular case, no
> new commit is being created so I don't know that the cache-tree would help.
It's basically an index extension that mirrors the tree structure within
the index, telling you the sha1 of the three that _would_ be generated
from any particular path. So any time you're walking a tree alongside
the index, in theory you should be able to say "the cache-tree for this
subset of the index matches the tree" and skip over a bunch of entries.
At least that's my view of it. unpack_trees() has always been a
terrifying beast that I've avoided looking too closely at.
> After a quick look at the code, the only place I can find that tries to use
> cache_tree_matches_traversal() is in unpack_callback() and that only happens
> if n == 1 and in the "git checkout" case, n == 2. Am I missing something?
Looks like it's trying to special-case "diff-index --cached". Which
kind-of makes sense. In the non-cached case, we're thinking not only
about the relationship between the index and the tree, but also whether
the on-disk files are up to date.
And that would be the same for checkout. We want to know not only
whether there are changes to make to the index, but also whether the
on-disk files need to be updated from the index.
But I assume in your case that we've just refreshed the index quickly
using fsmonitor. So I think in the long run what you want is:
1. fsmonitor tells us which index entries are not clean
2. based on the unclean list, we invalidate cache-tree entries for
those paths
3. if we have a valid cache-tree entry, we should be able to skip
digging into that tree; if not, then we walk the index and tree as
normal, adding/deleting index entries and updating (or complaining
about) modified on-disk files
I think the "n" adds an extra layer of complexity. n==2 means we're
doing a "2-way" merge. Moving from tree X to tree Y, and dealing with
the index as we go. Naively I _think_ we'd be OK to just extend the rule
to "if both subtrees match each other _and_ match the valid cache-tree,
then we can skip".
Again, I'm a little out of my area of expertise here, but cargo-culting
like this:
diff --git a/sha1-file.c b/sha1-file.c
index de4839e634..c105af70ce 100644
--- a/sha1-file.c
+++ b/sha1-file.c
@@ -1375,6 +1375,7 @@ static void *read_object(const unsigned char *sha1, enum object_type *type,
if (oid_object_info_extended(the_repository, &oid, &oi, 0) < 0)
return NULL;
+ trace_printf("reading %s %s", type_name(*type), sha1_to_hex(sha1));
return content;
}
diff --git a/unpack-trees.c b/unpack-trees.c
index 66741130ae..cfdad4133d 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -1075,6 +1075,23 @@ static int unpack_callback(int n, unsigned long mask, unsigned long dirmask, str
o->cache_bottom += matches;
return mask;
}
+ } else if (n == 2 && S_ISDIR(names->mode) &&
+ names[0].mode == names[1].mode &&
+ !strcmp(names[0].path, names[1].path) &&
+ !oidcmp(names[0].oid, names[1].oid)
+ /* && somehow account for modified on-disk files */) {
+ int matches;
+
+ /*
+ * we know that the two trees have the same oid, so we
+ * only need to look at one of them
+ */
+ matches = cache_tree_matches_traversal(o->src_index->cache_tree,
+ names, info);
+ if (matches) {
+ o->cache_bottom += matches;
+ return mask;
+ }
}
if (traverse_trees_recursive(n, dirmask, mask & ~dirmask,
seems to avoid the tree reads when running "GIT_TRACE=1 git checkout".
It also totally empties the index. ;) So clearly we have to do a bit
more there. Probably rather than just bumping o->cache_bottom forward,
we'd need to actually move those entries into the new index. Or maybe
it's something else entirely (I did say cargo-culting, right?).
-Peff
^ permalink raw reply related
* [GIT PULL] FSI updates round 3 for 4.19
From: Benjamin Herrenschmidt @ 2018-07-24 4:13 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: linux-kernel@vger.kernel.org, openbmc, Joel Stanley
Hi Greg !
This adds support for offloading the FSI low level bitbanging to the
ColdFire coprocessor of the Aspeed SoCs. All the pre-requisites have
already been merged, this is the final piece in the puzzle.
This branch also pull gpio/ib-aspeed which is a topic branch already
in gpio/for-next (and thus in next) whic contains pre-requisites.
Finally, there's also a bug fix to the sbefifo driver for some
inconsistent use of a mutex in the error handling code.
Note: The oddball "origin" commit of that pull request comes from
the fact that Linus Walleij gpio/ib-aspeed tree is ahead of mine,
so pulling his branch pulled a bunch of already upstream other things
in. As such, i had to base this pull request off a local merge. This
shouldn't affect you at all, and allows the diffstat below to be
correct.
The bindings updates have been acked by Rob and the corresponding
device-tree updates will be merged by Joel via the ARM SoC tree.
Thanks !
Ben.
The following changes since commit d5e748ff2b996d83489ac76c072e8b99f9ecef13:
Merge remote-tracking branch 'gpio/ib-aspeed' into upstream-ready (2018-07-23 15:21:39 +1000)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/linux-fsi.git tags/fsi-updates-2018-07-24
for you to fetch changes up to 0a213777d1dd879092225a7aa847b6e9b3a1c267:
fsi: Add support for device-tree provided chip IDs (2018-07-23 16:27:32 +1000)
----------------------------------------------------------------
Benjamin Herrenschmidt (6):
devres: Add devm_of_iomap()
dt-bindings: fsi: Document binding for the fsi-master-ast-cf "device"
fsi: master-ast-cf: Add new FSI master using Aspeed ColdFire
fsi: sbefifo: Fix inconsistent use of ffdc mutex
dt-bindings: fsi: Add optional chip-id to CFAMs
fsi: Add support for device-tree provided chip IDs
Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt | 36 +++++++
Documentation/devicetree/bindings/fsi/fsi.txt | 5 +
drivers/fsi/Kconfig | 9 ++
drivers/fsi/Makefile | 1 +
drivers/fsi/cf-fsi-fw.h | 157 ++++++++++++++++++++++++++++
drivers/fsi/fsi-core.c | 24 +++++
drivers/fsi/fsi-master-ast-cf.c | 1438 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
drivers/fsi/fsi-sbefifo.c | 13 ++-
include/linux/device.h | 4 +
include/trace/events/fsi_master_ast_cf.h | 150 ++++++++++++++++++++++++++
lib/devres.c | 36 +++++++
11 files changed, 1869 insertions(+), 4 deletions(-)
create mode 100644 Documentation/devicetree/bindings/fsi/fsi-master-ast-cf.txt
create mode 100644 drivers/fsi/cf-fsi-fw.h
create mode 100644 drivers/fsi/fsi-master-ast-cf.c
create mode 100644 include/trace/events/fsi_master_ast_cf.h
^ permalink raw reply
* [PATCH v2] bcache: set max writeback rate when I/O request is idle
From: Coly Li @ 2018-07-24 4:03 UTC (permalink / raw)
To: colyli, linux-bcache; +Cc: linux-block, stable, Michael Lyle, Stefan Priebe
Commit b1092c9af9ed ("bcache: allow quick writeback when backing idle")
allows the writeback rate to be faster if there is no I/O request on a
bcache device. It works well if there is only one bcache device attached
to the cache set. If there are many bcache devices attached to a cache
set, it may introduce performance regression because multiple faster
writeback threads of the idle bcache devices will compete the btree level
locks with the bcache device who have I/O requests coming.
This patch fixes the above issue by only permitting fast writebac when
all bcache devices attached on the cache set are idle. And if one of the
bcache devices has new I/O request coming, minimized all writeback
throughput immediately and let PI controller __update_writeback_rate()
to decide the upcoming writeback rate for each bcache device.
Also when all bcache devices are idle, limited wrieback rate to a small
number is wast of thoughput, especially when backing devices are slower
non-rotation devices (e.g. SATA SSD). This patch sets a max writeback
rate for each backing device if the whole cache set is idle. A faster
writeback rate in idle time means new I/Os may have more available space
for dirty data, and people may observe a better write performance then.
Please note bcache may change its cache mode in run time, and this patch
still works if the cache mode is switched from writeback mode and there
is still dirty data on cache.
Fixes: Commit b1092c9af9ed ("bcache: allow quick writeback when backing idle")
Cc: stable@vger.kernel.org #4.16+
Signed-off-by: Coly Li <colyli@suse.de>
Tested-by: Kai Krakow <kai@kaishome.de>
Cc: Michael Lyle <mlyle@lyle.org>
Cc: Stefan Priebe <s.priebe@profihost.ag>
---
Channgelog:
v2, Fix a deadlock reported by Stefan Priebe.
v1, Initial version.
drivers/md/bcache/bcache.h | 11 ++--
drivers/md/bcache/request.c | 51 ++++++++++++++-
drivers/md/bcache/super.c | 1 +
drivers/md/bcache/sysfs.c | 14 +++--
drivers/md/bcache/util.c | 2 +-
drivers/md/bcache/util.h | 2 +-
drivers/md/bcache/writeback.c | 115 ++++++++++++++++++++++++++--------
7 files changed, 155 insertions(+), 41 deletions(-)
diff --git a/drivers/md/bcache/bcache.h b/drivers/md/bcache/bcache.h
index d6bf294f3907..469ab1a955e0 100644
--- a/drivers/md/bcache/bcache.h
+++ b/drivers/md/bcache/bcache.h
@@ -328,13 +328,6 @@ struct cached_dev {
*/
atomic_t has_dirty;
- /*
- * Set to zero by things that touch the backing volume-- except
- * writeback. Incremented by writeback. Used to determine when to
- * accelerate idle writeback.
- */
- atomic_t backing_idle;
-
struct bch_ratelimit writeback_rate;
struct delayed_work writeback_rate_update;
@@ -514,6 +507,8 @@ struct cache_set {
struct cache_accounting accounting;
unsigned long flags;
+ atomic_t idle_counter;
+ atomic_t at_max_writeback_rate;
struct cache_sb sb;
@@ -523,6 +518,8 @@ struct cache_set {
struct bcache_device **devices;
unsigned devices_max_used;
+ /* See set_at_max_writeback_rate() for how it is used */
+ unsigned previous_dirty_dc_nr;
struct list_head cached_devs;
uint64_t cached_dev_sectors;
struct closure caching;
diff --git a/drivers/md/bcache/request.c b/drivers/md/bcache/request.c
index ae67f5fa8047..1af3d96abfa5 100644
--- a/drivers/md/bcache/request.c
+++ b/drivers/md/bcache/request.c
@@ -1104,6 +1104,43 @@ static void detached_dev_do_request(struct bcache_device *d, struct bio *bio)
/* Cached devices - read & write stuff */
+static void quit_max_writeback_rate(struct cache_set *c,
+ struct cached_dev *this_dc)
+{
+ int i;
+ struct bcache_device *d;
+ struct cached_dev *dc;
+
+ /*
+ * If bch_register_lock is acquired by other attach/detach operations,
+ * waiting here will increase I/O request latency for seconds or more.
+ * To avoid such situation, only writeback rate of current cached device
+ * is set to 1, and __update_write_back() will decide writeback rate
+ * of other cached devices (remember c->idle_counter is 0 now).
+ */
+ if (mutex_trylock(&bch_register_lock)){
+ for (i = 0; i < c->devices_max_used; i++) {
+ if (!c->devices[i])
+ continue;
+
+ if (UUID_FLASH_ONLY(&c->uuids[i]))
+ continue;
+
+ d = c->devices[i];
+ dc = container_of(d, struct cached_dev, disk);
+ /*
+ * set writeback rate to default minimum value,
+ * then let update_writeback_rate() to decide the
+ * upcoming rate.
+ */
+ atomic64_set(&dc->writeback_rate.rate, 1);
+ }
+
+ mutex_unlock(&bch_register_lock);
+ } else
+ atomic64_set(&this_dc->writeback_rate.rate, 1);
+}
+
static blk_qc_t cached_dev_make_request(struct request_queue *q,
struct bio *bio)
{
@@ -1119,7 +1156,19 @@ static blk_qc_t cached_dev_make_request(struct request_queue *q,
return BLK_QC_T_NONE;
}
- atomic_set(&dc->backing_idle, 0);
+ if (d->c) {
+ atomic_set(&d->c->idle_counter, 0);
+ /*
+ * If at_max_writeback_rate of cache set is true and new I/O
+ * comes, quit max writeback rate of all cached devices
+ * attached to this cache set, and set at_max_writeback_rate
+ * to false.
+ */
+ if (unlikely(atomic_read(&d->c->at_max_writeback_rate) == 1)) {
+ atomic_set(&d->c->at_max_writeback_rate, 0);
+ quit_max_writeback_rate(d->c, dc);
+ }
+ }
generic_start_io_acct(q, rw, bio_sectors(bio), &d->disk->part0);
bio_set_dev(bio, dc->bdev);
diff --git a/drivers/md/bcache/super.c b/drivers/md/bcache/super.c
index fa4058e43202..fa532d9f9353 100644
--- a/drivers/md/bcache/super.c
+++ b/drivers/md/bcache/super.c
@@ -1687,6 +1687,7 @@ struct cache_set *bch_cache_set_alloc(struct cache_sb *sb)
c->block_bits = ilog2(sb->block_size);
c->nr_uuids = bucket_bytes(c) / sizeof(struct uuid_entry);
c->devices_max_used = 0;
+ c->previous_dirty_dc_nr = 0;
c->btree_pages = bucket_pages(c);
if (c->btree_pages > BTREE_MAX_PAGES)
c->btree_pages = max_t(int, c->btree_pages / 4,
diff --git a/drivers/md/bcache/sysfs.c b/drivers/md/bcache/sysfs.c
index 225b15aa0340..d719021bff81 100644
--- a/drivers/md/bcache/sysfs.c
+++ b/drivers/md/bcache/sysfs.c
@@ -170,7 +170,8 @@ SHOW(__bch_cached_dev)
var_printf(writeback_running, "%i");
var_print(writeback_delay);
var_print(writeback_percent);
- sysfs_hprint(writeback_rate, dc->writeback_rate.rate << 9);
+ sysfs_hprint(writeback_rate,
+ atomic64_read(&dc->writeback_rate.rate) << 9);
sysfs_hprint(io_errors, atomic_read(&dc->io_errors));
sysfs_printf(io_error_limit, "%i", dc->error_limit);
sysfs_printf(io_disable, "%i", dc->io_disable);
@@ -188,7 +189,8 @@ SHOW(__bch_cached_dev)
char change[20];
s64 next_io;
- bch_hprint(rate, dc->writeback_rate.rate << 9);
+ bch_hprint(rate,
+ atomic64_read(&dc->writeback_rate.rate) << 9);
bch_hprint(dirty, bcache_dev_sectors_dirty(&dc->disk) << 9);
bch_hprint(target, dc->writeback_rate_target << 9);
bch_hprint(proportional,dc->writeback_rate_proportional << 9);
@@ -255,8 +257,12 @@ STORE(__cached_dev)
sysfs_strtoul_clamp(writeback_percent, dc->writeback_percent, 0, 40);
- sysfs_strtoul_clamp(writeback_rate,
- dc->writeback_rate.rate, 1, INT_MAX);
+ if (attr == &sysfs_writeback_rate) {
+ int v;
+
+ sysfs_strtoul_clamp(writeback_rate, v, 1, INT_MAX);
+ atomic64_set(&dc->writeback_rate.rate, v);
+ }
sysfs_strtoul_clamp(writeback_rate_update_seconds,
dc->writeback_rate_update_seconds,
diff --git a/drivers/md/bcache/util.c b/drivers/md/bcache/util.c
index fc479b026d6d..84f90c3d996d 100644
--- a/drivers/md/bcache/util.c
+++ b/drivers/md/bcache/util.c
@@ -200,7 +200,7 @@ uint64_t bch_next_delay(struct bch_ratelimit *d, uint64_t done)
{
uint64_t now = local_clock();
- d->next += div_u64(done * NSEC_PER_SEC, d->rate);
+ d->next += div_u64(done * NSEC_PER_SEC, atomic64_read(&d->rate));
/* Bound the time. Don't let us fall further than 2 seconds behind
* (this prevents unnecessary backlog that would make it impossible
diff --git a/drivers/md/bcache/util.h b/drivers/md/bcache/util.h
index cced87f8eb27..7e17f32ab563 100644
--- a/drivers/md/bcache/util.h
+++ b/drivers/md/bcache/util.h
@@ -442,7 +442,7 @@ struct bch_ratelimit {
* Rate at which we want to do work, in units per second
* The units here correspond to the units passed to bch_next_delay()
*/
- uint32_t rate;
+ atomic64_t rate;
};
static inline void bch_ratelimit_reset(struct bch_ratelimit *d)
diff --git a/drivers/md/bcache/writeback.c b/drivers/md/bcache/writeback.c
index ad45ebe1a74b..11ffadc3cf8f 100644
--- a/drivers/md/bcache/writeback.c
+++ b/drivers/md/bcache/writeback.c
@@ -49,6 +49,80 @@ static uint64_t __calc_target_rate(struct cached_dev *dc)
return (cache_dirty_target * bdev_share) >> WRITEBACK_SHARE_SHIFT;
}
+static bool set_at_max_writeback_rate(struct cache_set *c,
+ struct cached_dev *dc)
+{
+ int i, dirty_dc_nr = 0;
+ struct bcache_device *d;
+
+ /*
+ * bch_register_lock is acquired in cached_dev_detach_finish() before
+ * calling cancel_writeback_rate_update_dwork() to stop the delayed
+ * kworker writeback_rate_update (where the context we are for now).
+ * Therefore call mutex_lock() here may introduce deadlock when shut
+ * down the bcache device.
+ * c->previous_dirty_dc_nr is used to record previous calculated
+ * dirty_dc_nr when mutex_trylock() last time succeeded. Then if
+ * mutex_trylock() failed here, use c->previous_dirty_dc_nr as dirty
+ * cached device number. Of cause it might be inaccurate, but a few more
+ * or less loop before setting c->at_max_writeback_rate is much better
+ * then a deadlock here.
+ */
+ if (mutex_trylock(&bch_register_lock)) {
+ for (i = 0; i < c->devices_max_used; i++) {
+ if (!c->devices[i])
+ continue;
+ if (UUID_FLASH_ONLY(&c->uuids[i]))
+ continue;
+ d = c->devices[i];
+ dc = container_of(d, struct cached_dev, disk);
+ if (atomic_read(&dc->has_dirty))
+ dirty_dc_nr++;
+ }
+ c->previous_dirty_dc_nr = dirty_dc_nr;
+
+ mutex_unlock(&bch_register_lock);
+ } else
+ dirty_dc_nr = c->previous_dirty_dc_nr;
+
+ /*
+ * Idle_counter is increased everytime when update_writeback_rate()
+ * is rescheduled in. If all backing devices attached to the same
+ * cache set has same dc->writeback_rate_update_seconds value, it
+ * is about 10 rounds of update_writeback_rate() is called on each
+ * backing device, then the code will fall through at set 1 to
+ * c->at_max_writeback_rate, and a max wrteback rate to each
+ * dc->writeback_rate.rate. This is not very accurate but works well
+ * to make sure the whole cache set has no new I/O coming before
+ * writeback rate is set to a max number.
+ */
+ if (atomic_inc_return(&c->idle_counter) < dirty_dc_nr * 10)
+ return false;
+
+ if (atomic_read(&c->at_max_writeback_rate) != 1)
+ atomic_set(&c->at_max_writeback_rate, 1);
+
+
+ atomic64_set(&dc->writeback_rate.rate, INT_MAX);
+
+ /* keep writeback_rate_target as existing value */
+ dc->writeback_rate_proportional = 0;
+ dc->writeback_rate_integral_scaled = 0;
+ dc->writeback_rate_change = 0;
+
+ /*
+ * Check c->idle_counter and c->at_max_writeback_rate agagain in case
+ * new I/O arrives during before set_at_max_writeback_rate() returns.
+ * Then the writeback rate is set to 1, and its new value should be
+ * decided via __update_writeback_rate().
+ */
+ if (atomic_read(&c->idle_counter) < dirty_dc_nr * 10 ||
+ !atomic_read(&c->at_max_writeback_rate))
+ return false;
+
+ return true;
+}
+
static void __update_writeback_rate(struct cached_dev *dc)
{
/*
@@ -104,8 +178,9 @@ static void __update_writeback_rate(struct cached_dev *dc)
dc->writeback_rate_proportional = proportional_scaled;
dc->writeback_rate_integral_scaled = integral_scaled;
- dc->writeback_rate_change = new_rate - dc->writeback_rate.rate;
- dc->writeback_rate.rate = new_rate;
+ dc->writeback_rate_change = new_rate -
+ atomic64_read(&dc->writeback_rate.rate);
+ atomic64_set(&dc->writeback_rate.rate, new_rate);
dc->writeback_rate_target = target;
}
@@ -138,9 +213,16 @@ static void update_writeback_rate(struct work_struct *work)
down_read(&dc->writeback_lock);
- if (atomic_read(&dc->has_dirty) &&
- dc->writeback_percent)
- __update_writeback_rate(dc);
+ if (atomic_read(&dc->has_dirty) && dc->writeback_percent) {
+ /*
+ * If the whole cache set is idle, set_at_max_writeback_rate()
+ * will set writeback rate to a max number. Then it is
+ * unncessary to update writeback rate for an idle cache set
+ * in maximum writeback rate number(s).
+ */
+ if (!set_at_max_writeback_rate(c, dc))
+ __update_writeback_rate(dc);
+ }
up_read(&dc->writeback_lock);
@@ -422,27 +504,6 @@ static void read_dirty(struct cached_dev *dc)
delay = writeback_delay(dc, size);
- /* If the control system would wait for at least half a
- * second, and there's been no reqs hitting the backing disk
- * for awhile: use an alternate mode where we have at most
- * one contiguous set of writebacks in flight at a time. If
- * someone wants to do IO it will be quick, as it will only
- * have to contend with one operation in flight, and we'll
- * be round-tripping data to the backing disk as quickly as
- * it can accept it.
- */
- if (delay >= HZ / 2) {
- /* 3 means at least 1.5 seconds, up to 7.5 if we
- * have slowed way down.
- */
- if (atomic_inc_return(&dc->backing_idle) >= 3) {
- /* Wait for current I/Os to finish */
- closure_sync(&cl);
- /* And immediately launch a new set. */
- delay = 0;
- }
- }
-
while (!kthread_should_stop() &&
!test_bit(CACHE_SET_IO_DISABLE, &dc->disk.c->flags) &&
delay) {
@@ -715,7 +776,7 @@ void bch_cached_dev_writeback_init(struct cached_dev *dc)
dc->writeback_running = true;
dc->writeback_percent = 10;
dc->writeback_delay = 30;
- dc->writeback_rate.rate = 1024;
+ atomic64_set(&dc->writeback_rate.rate, 1024);
dc->writeback_rate_minimum = 8;
dc->writeback_rate_update_seconds = WRITEBACK_RATE_UPDATE_SECS_DEFAULT;
--
2.17.1
^ permalink raw reply related
* [PATCH] drm/amdgpu: move the amdgpu_fbdev_set_suspend() further up
From: Shirish S @ 2018-07-24 4:02 UTC (permalink / raw)
To: alexander.deucher-5C7GfCeVMHo, christian.koenig-5C7GfCeVMHo,
michel-otUistvHUpPR7s880joybQ
Cc: amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, Shirish S
This patch moves amdgpu_fbdev_set_suspend() to the beginning
of suspend sequence.
This is to ensure fbcon does not to write to the VRAM
after GPU is powerd down.
Signed-off-by: Shirish S <shirish.s@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 7a1bec1..745f760 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -2702,6 +2702,9 @@ int amdgpu_device_suspend(struct drm_device *dev, bool suspend, bool fbcon)
drm_kms_helper_poll_disable(dev);
+ if (fbcon)
+ amdgpu_fbdev_set_suspend(adev, 1);
+
if (!amdgpu_device_has_dc_support(adev)) {
/* turn off display hw */
drm_modeset_lock_all(dev);
@@ -2767,9 +2770,6 @@ int amdgpu_device_suspend(struct drm_device *dev, bool suspend, bool fbcon)
DRM_ERROR("amdgpu asic reset failed\n");
}
- if (fbcon)
- amdgpu_fbdev_set_suspend(adev, 1);
-
return 0;
}
--
2.7.4
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply related
* Re: [PATCH 2/4] phy: socionext: add USB3 PHY driver for UniPhier SoC
From: Kishon Vijay Abraham I @ 2018-07-24 4:01 UTC (permalink / raw)
To: Kunihiko Hayashi
Cc: Rob Herring, Mark Rutland, Masahiro Yamada, linux-arm-kernel,
linux-kernel, devicetree, Masami Hiramatsu, Jassi Brar
In-Reply-To: <20180717202757.858B.4A936039@socionext.com>
Hi,
On Tuesday 17 July 2018 04:57 PM, Kunihiko Hayashi wrote:
> Hi Kishon,
>
> On Fri, 13 Jul 2018 12:45:06 +0530 <kishon@ti.com> wrote:
>
>> Hi,
>>
>> On Wednesday 11 July 2018 05:35 PM, Kunihiko Hayashi wrote:
>>> On Mon, 9 Jul 2018 20:23:19 +0900 <hayashi.kunihiko@socionext.com> wrote:
>>>
>>>> Hi Kishon,
>>>> Thank you for your comments.
>>>>
>>>> On Mon, 9 Jul 2018 10:49:50 +0530 <kishon@ti.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> On Friday 29 June 2018 02:08 PM, Kunihiko Hayashi wrote:
>>>>>> Add a driver for PHY interface built into USB3 controller
>>>>>> implemented in UniPhier SoCs.
>>>>>> This driver supports High-Speed PHY and Super-Speed PHY.
>>>>>>
>>>>>> Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
>>>>>> Signed-off-by: Motoya Tanigawa <tanigawa.motoya@socionext.com>
>>>>>> Signed-off-by: Masami Hiramatsu <masami.hiramatsu@linaro.org>
>>>>>> ---
>>>>>> drivers/phy/Kconfig | 1 +
>>>>>> drivers/phy/Makefile | 1 +
>>>>>> drivers/phy/socionext/Kconfig | 12 +
>>>>>> drivers/phy/socionext/Makefile | 6 +
>>>>>> drivers/phy/socionext/phy-uniphier-usb3hs.c | 422 ++++++++++++++++++++++++++++
>>>>>> drivers/phy/socionext/phy-uniphier-usb3ss.c | 369 ++++++++++++++++++++++++
>>>>>> 6 files changed, 811 insertions(+)
>>>>>> create mode 100644 drivers/phy/socionext/Kconfig
>>>>>> create mode 100644 drivers/phy/socionext/Makefile
>>>>>> create mode 100644 drivers/phy/socionext/phy-uniphier-usb3hs.c
>>>>>> create mode 100644 drivers/phy/socionext/phy-uniphier-usb3ss.c
>>>>
>>>> (snip...)
>>>>
>>>>>> --- /dev/null
>>>>>> +++ b/drivers/phy/socionext/phy-uniphier-usb3hs.c
>>>>>> @@ -0,0 +1,422 @@
>>>>>> +// SPDX-License-Identifier: GPL-2.0
>>>>>> +/*
>>>>>> + * phy-uniphier-usb3hs.c - HS-PHY driver for Socionext UniPhier USB3 controller
>>>>>> + * Copyright 2015-2018 Socionext Inc.
>>>>>> + * Author:
>>>>>> + * Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
>>>>>> + * Contributors:
>>>>>> + * Motoya Tanigawa <tanigawa.motoya@socionext.com>
>>>>>> + * Masami Hiramatsu <masami.hiramatsu@linaro.org>
>>>>>> + */
>>>>>> +
>>>>>> +#include <linux/bitfield.h>
>>>>>> +#include <linux/bitops.h>
>>>>>> +#include <linux/clk.h>
>>>>>> +#include <linux/io.h>
>>>>>> +#include <linux/mfd/syscon.h>
>>>>>> +#include <linux/module.h>
>>>>>> +#include <linux/nvmem-consumer.h>
>>>>>> +#include <linux/of.h>
>>>>>> +#include <linux/of_platform.h>
>>>>>> +#include <linux/phy/phy.h>
>>>>>> +#include <linux/platform_device.h>
>>>>>> +#include <linux/reset.h>
>>>>>> +#include <linux/slab.h>
>>>>>> +
>>>>>> +#define HSPHY_CFG0 0x0
>>>>>> +#define HSPHY_CFG0_HS_I_MASK GENMASK(31, 28)
>>>>>> +#define HSPHY_CFG0_HSDISC_MASK GENMASK(27, 26)
>>>>>> +#define HSPHY_CFG0_SWING_MASK GENMASK(17, 16)
>>>>>> +#define HSPHY_CFG0_SEL_T_MASK GENMASK(15, 12)
>>>>>> +#define HSPHY_CFG0_RTERM_MASK GENMASK(7, 6)
>>>>>> +#define HSPHY_CFG0_TRIMMASK (HSPHY_CFG0_HS_I_MASK \
>>>>>> + | HSPHY_CFG0_SEL_T_MASK \
>>>>>> + | HSPHY_CFG0_RTERM_MASK)
>>>>>> +
>>>>>> +#define HSPHY_CFG1 0x4
>>>>>> +#define HSPHY_CFG1_DAT_EN BIT(29)
>>>>>> +#define HSPHY_CFG1_ADR_EN BIT(28)
>>>>>> +#define HSPHY_CFG1_ADR_MASK GENMASK(27, 16)
>>>>>> +#define HSPHY_CFG1_DAT_MASK GENMASK(23, 16)
>>>>>> +
>>>>>> +#define MAX_CLKS 3
>>>>>> +#define MAX_RSTS 2
>>>>>> +#define MAX_PHY_PARAMS 1
>>>>>> +
>>>>>> +struct uniphier_u3hsphy_param {
>>>>>> + u32 addr;
>>>>>> + u32 mask;
>>>>>> + u32 val;
>>>>>> +};
>>>>>
>>>>> I'd like to avoid configure the PHY this way, since it's impossible to know
>>>>> which register is being configured.
>>>>
>>>
>>> This way might be misunderstood.
>>> These HS-PHY and SS-PHY have "internal" registers, which are not memory-mapped.
>>>
>>> And to access these internal registers, we need to specify the number
>>> corresponding to the register.
>>>
>>> The "addr" in "uniphier_u3hsphy_param" is just the number of the register.
>>> The "mask" shows a bitfield of the register, that means one of PHY parameters.
>>> The "value" shows a parameter value to set to the bitfield.
>>
>> What does each of these bitfields represent? Which PHY parameter does it
>> configure. Are they really PHY parameters or they also configure clocks/mux
>> etc? I would like the configurations to be more descriptive so that we get to
>> know at least what's getting configured here.
>
> These bitfields represent phy parameters only, not include clocks/mux etc.
> We can express the register (bitfield) name with macros.
>
> However, only recommended values are noted for the bitfields in the specsheet,
> because there are the trimmed values that aren't set as power-on values,
> and we should use the values for stable operation.
Calibration values are fine but at least the registers and bitfields has to be
described using names.
Thanks
Kishon
^ permalink raw reply
* Re: [PATCH 2/4] phy: socionext: add USB3 PHY driver for UniPhier SoC
From: Kishon Vijay Abraham I @ 2018-07-24 4:01 UTC (permalink / raw)
To: Kunihiko Hayashi
Cc: Mark Rutland, devicetree, Masami Hiramatsu, Jassi Brar,
linux-kernel, Masahiro Yamada, Rob Herring, linux-arm-kernel
In-Reply-To: <20180717202757.858B.4A936039@socionext.com>
Hi,
On Tuesday 17 July 2018 04:57 PM, Kunihiko Hayashi wrote:
> Hi Kishon,
>
> On Fri, 13 Jul 2018 12:45:06 +0530 <kishon@ti.com> wrote:
>
>> Hi,
>>
>> On Wednesday 11 July 2018 05:35 PM, Kunihiko Hayashi wrote:
>>> On Mon, 9 Jul 2018 20:23:19 +0900 <hayashi.kunihiko@socionext.com> wrote:
>>>
>>>> Hi Kishon,
>>>> Thank you for your comments.
>>>>
>>>> On Mon, 9 Jul 2018 10:49:50 +0530 <kishon@ti.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> On Friday 29 June 2018 02:08 PM, Kunihiko Hayashi wrote:
>>>>>> Add a driver for PHY interface built into USB3 controller
>>>>>> implemented in UniPhier SoCs.
>>>>>> This driver supports High-Speed PHY and Super-Speed PHY.
>>>>>>
>>>>>> Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
>>>>>> Signed-off-by: Motoya Tanigawa <tanigawa.motoya@socionext.com>
>>>>>> Signed-off-by: Masami Hiramatsu <masami.hiramatsu@linaro.org>
>>>>>> ---
>>>>>> drivers/phy/Kconfig | 1 +
>>>>>> drivers/phy/Makefile | 1 +
>>>>>> drivers/phy/socionext/Kconfig | 12 +
>>>>>> drivers/phy/socionext/Makefile | 6 +
>>>>>> drivers/phy/socionext/phy-uniphier-usb3hs.c | 422 ++++++++++++++++++++++++++++
>>>>>> drivers/phy/socionext/phy-uniphier-usb3ss.c | 369 ++++++++++++++++++++++++
>>>>>> 6 files changed, 811 insertions(+)
>>>>>> create mode 100644 drivers/phy/socionext/Kconfig
>>>>>> create mode 100644 drivers/phy/socionext/Makefile
>>>>>> create mode 100644 drivers/phy/socionext/phy-uniphier-usb3hs.c
>>>>>> create mode 100644 drivers/phy/socionext/phy-uniphier-usb3ss.c
>>>>
>>>> (snip...)
>>>>
>>>>>> --- /dev/null
>>>>>> +++ b/drivers/phy/socionext/phy-uniphier-usb3hs.c
>>>>>> @@ -0,0 +1,422 @@
>>>>>> +// SPDX-License-Identifier: GPL-2.0
>>>>>> +/*
>>>>>> + * phy-uniphier-usb3hs.c - HS-PHY driver for Socionext UniPhier USB3 controller
>>>>>> + * Copyright 2015-2018 Socionext Inc.
>>>>>> + * Author:
>>>>>> + * Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
>>>>>> + * Contributors:
>>>>>> + * Motoya Tanigawa <tanigawa.motoya@socionext.com>
>>>>>> + * Masami Hiramatsu <masami.hiramatsu@linaro.org>
>>>>>> + */
>>>>>> +
>>>>>> +#include <linux/bitfield.h>
>>>>>> +#include <linux/bitops.h>
>>>>>> +#include <linux/clk.h>
>>>>>> +#include <linux/io.h>
>>>>>> +#include <linux/mfd/syscon.h>
>>>>>> +#include <linux/module.h>
>>>>>> +#include <linux/nvmem-consumer.h>
>>>>>> +#include <linux/of.h>
>>>>>> +#include <linux/of_platform.h>
>>>>>> +#include <linux/phy/phy.h>
>>>>>> +#include <linux/platform_device.h>
>>>>>> +#include <linux/reset.h>
>>>>>> +#include <linux/slab.h>
>>>>>> +
>>>>>> +#define HSPHY_CFG0 0x0
>>>>>> +#define HSPHY_CFG0_HS_I_MASK GENMASK(31, 28)
>>>>>> +#define HSPHY_CFG0_HSDISC_MASK GENMASK(27, 26)
>>>>>> +#define HSPHY_CFG0_SWING_MASK GENMASK(17, 16)
>>>>>> +#define HSPHY_CFG0_SEL_T_MASK GENMASK(15, 12)
>>>>>> +#define HSPHY_CFG0_RTERM_MASK GENMASK(7, 6)
>>>>>> +#define HSPHY_CFG0_TRIMMASK (HSPHY_CFG0_HS_I_MASK \
>>>>>> + | HSPHY_CFG0_SEL_T_MASK \
>>>>>> + | HSPHY_CFG0_RTERM_MASK)
>>>>>> +
>>>>>> +#define HSPHY_CFG1 0x4
>>>>>> +#define HSPHY_CFG1_DAT_EN BIT(29)
>>>>>> +#define HSPHY_CFG1_ADR_EN BIT(28)
>>>>>> +#define HSPHY_CFG1_ADR_MASK GENMASK(27, 16)
>>>>>> +#define HSPHY_CFG1_DAT_MASK GENMASK(23, 16)
>>>>>> +
>>>>>> +#define MAX_CLKS 3
>>>>>> +#define MAX_RSTS 2
>>>>>> +#define MAX_PHY_PARAMS 1
>>>>>> +
>>>>>> +struct uniphier_u3hsphy_param {
>>>>>> + u32 addr;
>>>>>> + u32 mask;
>>>>>> + u32 val;
>>>>>> +};
>>>>>
>>>>> I'd like to avoid configure the PHY this way, since it's impossible to know
>>>>> which register is being configured.
>>>>
>>>
>>> This way might be misunderstood.
>>> These HS-PHY and SS-PHY have "internal" registers, which are not memory-mapped.
>>>
>>> And to access these internal registers, we need to specify the number
>>> corresponding to the register.
>>>
>>> The "addr" in "uniphier_u3hsphy_param" is just the number of the register.
>>> The "mask" shows a bitfield of the register, that means one of PHY parameters.
>>> The "value" shows a parameter value to set to the bitfield.
>>
>> What does each of these bitfields represent? Which PHY parameter does it
>> configure. Are they really PHY parameters or they also configure clocks/mux
>> etc? I would like the configurations to be more descriptive so that we get to
>> know at least what's getting configured here.
>
> These bitfields represent phy parameters only, not include clocks/mux etc.
> We can express the register (bitfield) name with macros.
>
> However, only recommended values are noted for the bitfields in the specsheet,
> because there are the trimmed values that aren't set as power-on values,
> and we should use the values for stable operation.
Calibration values are fine but at least the registers and bitfields has to be
described using names.
Thanks
Kishon
^ permalink raw reply
* [PATCH 2/4] phy: socionext: add USB3 PHY driver for UniPhier SoC
From: Kishon Vijay Abraham I @ 2018-07-24 4:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180717202757.858B.4A936039@socionext.com>
Hi,
On Tuesday 17 July 2018 04:57 PM, Kunihiko Hayashi wrote:
> Hi Kishon,
>
> On Fri, 13 Jul 2018 12:45:06 +0530 <kishon@ti.com> wrote:
>
>> Hi,
>>
>> On Wednesday 11 July 2018 05:35 PM, Kunihiko Hayashi wrote:
>>> On Mon, 9 Jul 2018 20:23:19 +0900 <hayashi.kunihiko@socionext.com> wrote:
>>>
>>>> Hi Kishon,
>>>> Thank you for your comments.
>>>>
>>>> On Mon, 9 Jul 2018 10:49:50 +0530 <kishon@ti.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> On Friday 29 June 2018 02:08 PM, Kunihiko Hayashi wrote:
>>>>>> Add a driver for PHY interface built into USB3 controller
>>>>>> implemented in UniPhier SoCs.
>>>>>> This driver supports High-Speed PHY and Super-Speed PHY.
>>>>>>
>>>>>> Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
>>>>>> Signed-off-by: Motoya Tanigawa <tanigawa.motoya@socionext.com>
>>>>>> Signed-off-by: Masami Hiramatsu <masami.hiramatsu@linaro.org>
>>>>>> ---
>>>>>> drivers/phy/Kconfig | 1 +
>>>>>> drivers/phy/Makefile | 1 +
>>>>>> drivers/phy/socionext/Kconfig | 12 +
>>>>>> drivers/phy/socionext/Makefile | 6 +
>>>>>> drivers/phy/socionext/phy-uniphier-usb3hs.c | 422 ++++++++++++++++++++++++++++
>>>>>> drivers/phy/socionext/phy-uniphier-usb3ss.c | 369 ++++++++++++++++++++++++
>>>>>> 6 files changed, 811 insertions(+)
>>>>>> create mode 100644 drivers/phy/socionext/Kconfig
>>>>>> create mode 100644 drivers/phy/socionext/Makefile
>>>>>> create mode 100644 drivers/phy/socionext/phy-uniphier-usb3hs.c
>>>>>> create mode 100644 drivers/phy/socionext/phy-uniphier-usb3ss.c
>>>>
>>>> (snip...)
>>>>
>>>>>> --- /dev/null
>>>>>> +++ b/drivers/phy/socionext/phy-uniphier-usb3hs.c
>>>>>> @@ -0,0 +1,422 @@
>>>>>> +// SPDX-License-Identifier: GPL-2.0
>>>>>> +/*
>>>>>> + * phy-uniphier-usb3hs.c - HS-PHY driver for Socionext UniPhier USB3 controller
>>>>>> + * Copyright 2015-2018 Socionext Inc.
>>>>>> + * Author:
>>>>>> + * Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
>>>>>> + * Contributors:
>>>>>> + * Motoya Tanigawa <tanigawa.motoya@socionext.com>
>>>>>> + * Masami Hiramatsu <masami.hiramatsu@linaro.org>
>>>>>> + */
>>>>>> +
>>>>>> +#include <linux/bitfield.h>
>>>>>> +#include <linux/bitops.h>
>>>>>> +#include <linux/clk.h>
>>>>>> +#include <linux/io.h>
>>>>>> +#include <linux/mfd/syscon.h>
>>>>>> +#include <linux/module.h>
>>>>>> +#include <linux/nvmem-consumer.h>
>>>>>> +#include <linux/of.h>
>>>>>> +#include <linux/of_platform.h>
>>>>>> +#include <linux/phy/phy.h>
>>>>>> +#include <linux/platform_device.h>
>>>>>> +#include <linux/reset.h>
>>>>>> +#include <linux/slab.h>
>>>>>> +
>>>>>> +#define HSPHY_CFG0 0x0
>>>>>> +#define HSPHY_CFG0_HS_I_MASK GENMASK(31, 28)
>>>>>> +#define HSPHY_CFG0_HSDISC_MASK GENMASK(27, 26)
>>>>>> +#define HSPHY_CFG0_SWING_MASK GENMASK(17, 16)
>>>>>> +#define HSPHY_CFG0_SEL_T_MASK GENMASK(15, 12)
>>>>>> +#define HSPHY_CFG0_RTERM_MASK GENMASK(7, 6)
>>>>>> +#define HSPHY_CFG0_TRIMMASK (HSPHY_CFG0_HS_I_MASK \
>>>>>> + | HSPHY_CFG0_SEL_T_MASK \
>>>>>> + | HSPHY_CFG0_RTERM_MASK)
>>>>>> +
>>>>>> +#define HSPHY_CFG1 0x4
>>>>>> +#define HSPHY_CFG1_DAT_EN BIT(29)
>>>>>> +#define HSPHY_CFG1_ADR_EN BIT(28)
>>>>>> +#define HSPHY_CFG1_ADR_MASK GENMASK(27, 16)
>>>>>> +#define HSPHY_CFG1_DAT_MASK GENMASK(23, 16)
>>>>>> +
>>>>>> +#define MAX_CLKS 3
>>>>>> +#define MAX_RSTS 2
>>>>>> +#define MAX_PHY_PARAMS 1
>>>>>> +
>>>>>> +struct uniphier_u3hsphy_param {
>>>>>> + u32 addr;
>>>>>> + u32 mask;
>>>>>> + u32 val;
>>>>>> +};
>>>>>
>>>>> I'd like to avoid configure the PHY this way, since it's impossible to know
>>>>> which register is being configured.
>>>>
>>>
>>> This way might be misunderstood.
>>> These HS-PHY and SS-PHY have "internal" registers, which are not memory-mapped.
>>>
>>> And to access these internal registers, we need to specify the number
>>> corresponding to the register.
>>>
>>> The "addr" in "uniphier_u3hsphy_param" is just the number of the register.
>>> The "mask" shows a bitfield of the register, that means one of PHY parameters.
>>> The "value" shows a parameter value to set to the bitfield.
>>
>> What does each of these bitfields represent? Which PHY parameter does it
>> configure. Are they really PHY parameters or they also configure clocks/mux
>> etc? I would like the configurations to be more descriptive so that we get to
>> know at least what's getting configured here.
>
> These bitfields represent phy parameters only, not include clocks/mux etc.
> We can express the register (bitfield) name with macros.
>
> However, only recommended values are noted for the bitfields in the specsheet,
> because there are the trimmed values that aren't set as power-on values,
> and we should use the values for stable operation.
Calibration values are fine but at least the registers and bitfields has to be
described using names.
Thanks
Kishon
^ permalink raw reply
* [lustre-devel] New tag 2.11.53
From: Oleg Drokin @ 2018-07-24 4:00 UTC (permalink / raw)
To: lustre-devel
I just tagged a new tag 2.11.53 in Lustre master tree.
Here?s the changelog:
Alex Zhuravlev (3):
LU-7236 ptlrpc: idle connections can disconnect
LU-10048 osd: async truncate
LU-11097 utils: add libuuid for llverdev
Alexander Boyko (4):
LU-6399 lnet: socket cleanup
LU-10945 ldlm: fix l_last_activity usage
LU-11117 ptlrpc: don't zero request handle
LU-10893 tests: allow to disable dm-flakey layer
Amir Shehata (1):
LU-11064 lnd: determine gaps correctly
Andreas Dilger (5):
LU-10264 misc: fix possible array overflow
LU-10921 utils: improve lfs setstripe error message
LU-10855 ptlrpc: remove obsolete OBD RPC opcodes
LU-10855 ptlrpc: assign specific values to MGS opcodes
LU-10855 ptlrpc: remove obsolete LLOG_ORIGIN_* RPCs
Andrew Perepechko (1):
LU-10964 build: armv7 client build fixes
Andriy Skulysh (2):
LU-11004 ptlrpc: Serialize procfs access to scp_hist_reqs using mutex
LU-11098 ptlrpc: ASSERTION(!list_empty(imp->imp_replay_cursor))
Arshad Hussain (2):
LU-7943 mdd: Move assignment after LASSERT()
LU-10370 ofd: truncate does not update blocks count on client
Bob Glossman (3):
LU-10897 kernel: kernel upgrade RHEL7.5 [3.10.0-862.2.3.el7]
LU-11043 kernel: kernel update RHEL7.5 [3.10.0-862.3.2.el7]
LU-11065 kernel: kernel update [SLES12 SP3 4.4.132-94.33]
Bruno Faccini (3):
LU-10680 mdd: create gc thread when no current transaction
LU-10527 obdclass: don't recycle loghandle upon ENOSPC
LU-10734 tests: ensure current GC interval is over
Chris Horn (1):
LU-11044 osd-ldiskfs: ext4_dir_operations uses iterate_shared
Chuck Fossen (1):
LU-10963 gnilnd: stats variables overflow assert
Dmitry Eremin (1):
LU-4423 ptlrpc: use delayed_work in sec_gc
Emoly Liu (6):
LU-10907 tests: improve nodemap_test_setup()
LU-10979 test: correct the version code check in sanity-sec.sh
LU-10980 test: correct the version code check in sanityn.sh
LU-10972 test: get client uuid correctly
LU-10906 checksum: enable/disable checksum correctly
LU-11099 doc: include "-N" option to lfs_setstripe.1
Fan Yong (6):
LU-11024 osd-zfs: properly detect ZFS dnode accounting
LU-10419 lfsck: signal master engine when stop
LU-9764 lfsck: reset LFSCK trace file if fail to load it
LU-9751 snapshot: set PATH for remote zfs commands
LU-10120 lsnapshot: handle dash in fsname
LU-11079 llite: control concurrent statahead instances
Giuseppe Di Natale (1):
LU-6160 osd-zfs: Fix refcount_add call
Gregoire Pichon (1):
LU-739 utils: remove references to lustre 1.4 upgrade flag
Hongchao Zhang (1):
LU-7816 quota: add default quota setting support
James Nunez (5):
LU-11010 tests: remove calls to return after skip()
LU-8972 tests: remove conf-sanity test from ALWAYS_EXCEPT
LU-10971 tests: use changelog routines in lustre-rsync-test
LU-11058 tests: stop running sanity test 77k
LU-11161 tests: stop running sanity test 160g
James Simmons (9):
LU-9325 obdclass: handle strings correctly in lmd_find_delimiter
LU-9325 libcfs: handle complex strings in cfs_str2num_check
LU-10886 build: fix WARNING: modpost: missing MODULE_LICENSE()
LU-10997 build: add files to .gitignore
LU-8066 llite: Preparation to move /proc/fs/lustre/llite to sysfs
LU-8066 llite: replace ll_process_config with class_modify_config
LU-9325 llog: replace simple_strtol with kstrtol
LU-8066 osc: fix idle_timeout handling
LU-8066 llite: replace ll_process_config with class_modify_config
Joe Grund (1):
LU-11026 lustre-dkms should require patch or quilt
John L. Hammond (14):
LU-10699 hsm: add local object storage to MDTs
LU-10855 llog: remove llog_cancel()
LU-10978 utils: preserve lustre_rsync state
LU-10989 utils: correct lustre_rsync changelog clear logic
LU-10855 llog: remove obsolete llog handlers
LU-11014 mdt: intent handling simplification
LU-11054 lnet: remove non-error error message
LU-11069 llite: correct file position after appending writes
LU-11051 obd: remove obd_{get,put}ref()
LU-11014 mdt: remove enum mdt_it_code
LU-11045 test: use provided directory in racer/racer.sh
LU-11052 obd: remove OBD ops based stats
LU-11074 mdc: set correct body eadatasize for getxattr()
LU-11157 obd: keep dirty_max_pages a round number of MB
Lai Siyao (2):
LU-4684 mdt: improve directory stripe lock
LU-4684 xattr: add list support for remote object
Li Dongyang (1):
LU-10560 osd: bio_integrity_enabled was removed
Li Xi (2):
LU-10472 osd-ldiskfs: add T10PI support for BIO
LU-10472 osc: add T10PI support for RPC checksum
Mikhail Pershin (5):
LU-10808 lod: align wrong DoM stripe values with defaults
LU-10808 lod: remove DoM component if DoM is disabled
LU-10175 ptlrpc: add LOCK_CONVERT connection flag
LU-10175 ldlm: handle lock converts in cancel handler
LU-11003 ldlm: don't add canceling lock back to LRU
Minh Diep (1):
LU-11034 build: update changelog for Ubuntu 18.04
Nathaniel Clark (4):
LU-10843 mgs: allow snapshot after MGS remount
LU-10898 tests: enable conf-sanity 32a/32d
LU-11019 build: Update ZFS/SPL to 0.7.9
LU-11066 systemd: Add IB dependencies to lnet.service
NeilBrown (5):
LU-9859 libcfs: rearrange placement of CPU partition management code.
LU-4423 libcfs: disable preempt while sampling processor id.
LU-8130 ldlm: store name directly in namespace.
LU-4423 obd: backport of lu_object changes upstream
LU-4423 ldlm: use delayed_work for ldlm_pools_recalc
Oleg Drokin (5):
LU-10938 ptlrpc: Add WBC connect flag
LU-11015 lov: Move lov_tgts_kobj init to lov_setup
Revert "LU-8066 llite: replace ll_process_config with class_modify_config"
LU-10990 osc: increase default max_dirty_mb to 2G
New tag 2.11.53
Parinay Kondekar (1):
LU-6511 osd-ldiskfs: Fix all irregular indentation for osd_iam.c
Patrick Farrell (1):
LU-10648 ldlm: Reduce debug to console during eviction
Quentin Bouget (2):
LU-9474 tests: remove unneeded hsm_set_param for raolu tests
LU-10796 tests: standardize changelog testing in sanity-hsm
Saurabh Tandan (1):
LU-10977 test: add version check to sanity test_60ab
Sebastien Buisson (2):
LU-9727 tests: exercise new changelog fields and records
LU-11049 ssk: correctly handle null byte by lgss_sk
Vladimir Saveliev (2):
LU-11131 target: keep reply data bit set on failover
LU-11132 compile: fix LC_BI_BDEV for old kernels
Wang Shilong (3):
LU-11017 quota: ignore quota for CAP_SYS_RESOURCE properly
LU-11086 test: reset quota setting properly
LU-10986 lfs: make lfs project tolerant errors
Yang Sheng (2):
LU-9230 ldlm: speed up preparation for list of lock cancel
LU-11003 ldlm: fix for l_lru usage
^ permalink raw reply
* Re: WARNING in port_delete
From: DaeRyong Jeong @ 2018-07-24 3:59 UTC (permalink / raw)
To: perex, tiwai, Colin King
Cc: alsa-devel, LKML, Byoungyoung Lee, Kyungtae Kim, bammanag,
syzkaller
In-Reply-To: <20180724033608.GA17607@dragonet>
I just realized that the crash has been spotted by Syzkaller a few days before.
(https://syzkaller.appspot.com/bug?id=3490860a465e6b39227c6906f0ef2d40ad4d5bb1)
I'm CC'ing Syzkaller's mailing list.
Best regards,
DaeRyong Jeong
On Tue, Jul 24, 2018 at 12:36 PM, Dae R. Jeong <threeearcat@gmail.com> wrote:
> Reporting the crash: WARNING in port_delete
>
> This crash has been found in v4.18-rc3 using RaceFuzzer (a modified
> version of Syzkaller), which we descrbie more at the end of this
> report. Our analysis shows that the race occurs when invoking two close
> syscalls concurrently.
>
>
> The executed program is as follows:
> r0 = open("/dev/snd/seq", 0x0, 0x0)
> ioctl(r0, SNDRV_SEQ_IOCTL_CREATE_PORT, {{0x80}, "706f72943000000000000000000000000000000000000000000000000000000000233f770800000000000000000000000000000000000000001000", 0xffffffffffffffff, 0xfffffffffffffbff})
> r1 = openat(AT_FDCWD, "/dev/sequencer2", 0x8402, 0x0)
> close(r0)
> close(r1)
>
> and two threads executed the program as follows:
> Thread0 Thread1
> open("/dev/snd/seq")
> ioctl(r0, SNDRV_SEQ_IOCTL_CREATE_PORT)
> openat("/dev/sequencer2")
> close(r0) close(r1)
>
> (Note that two close() syscalls were exeuted after openat() syscall, and
> two close() syscalls were executed concurrently.)
>
>
> Crash log:
> ==================================================================
> WARNING: CPU: 1 PID: 32519 at /home/daeryong/workspace/race-fuzzer/kernels_repo/kernel_v4.18-rc3/sound/core/seq/seq_ports.c:275 port_delete+0xde/0xf0 sound/core/seq/seq_ports.c:275
> Kernel panic - not syncing: panic_on_warn set ...
>
> CPU: 1 PID: 32519 Comm: syz-executor0 Not tainted 4.18.0-rc3 #1
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x16e/0x22c lib/dump_stack.c:113
> panic+0x1a8/0x3a7 kernel/panic.c:184
> __warn+0x191/0x1a0 kernel/panic.c:536
> report_bug+0x132/0x1b0 lib/bug.c:186
> fixup_bug.part.10+0x28/0x50 arch/x86/kernel/traps.c:178
> fixup_bug arch/x86/kernel/traps.c:247 [inline]
> do_error_trap+0x284/0x2c0 arch/x86/kernel/traps.c:296
> do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:316
> invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:992
> RIP: 0010:port_delete+0xde/0xf0 sound/core/seq/seq_ports.c:275
> Code: 00 00 e8 b5 68 d2 fd 8b 83 58 01 00 00 85 c0 75 1d e8 86 5c ae fd 48 89 df e8 3e 52 d2 fd 31 c0 5b 41 5c 5d c3 e8 72 5c ae fd <0f> 0b eb c8 e8 69 5c ae fd 0f 0b eb da 0f 1f 44 00 00 55 48 89 e5
> RSP: 0018:ffff8801d635f900 EFLAGS: 00010216
> RAX: 0000000000040000 RBX: ffff8801da196900 RCX: ffffffff839b86ee
> RDX: 0000000000005e94 RSI: ffffc90002640000 RDI: ffff8801da196978
> RBP: ffff8801d635f910 R08: 0000000000000098 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff839ba820
> R13: ffff8801da196950 R14: ffff8801ed5bc080 R15: ffff8801da196958
> snd_seq_delete_port+0x2b0/0x2d0 sound/core/seq/seq_ports.c:303
> snd_seq_ioctl_delete_port+0x5b/0xa0 sound/core/seq/seq_clientmgr.c:1325
> snd_seq_kernel_client_ctl+0xd4/0xf0 sound/core/seq/seq_clientmgr.c:2361
> snd_seq_event_port_detach+0xcb/0x120 sound/core/seq/seq_ports.c:705
> delete_port+0x3a/0x70 sound/core/seq/oss/seq_oss_init.c:354
> snd_seq_oss_release+0x7c/0x90 sound/core/seq/oss/seq_oss_init.c:433
> odev_release+0x40/0x60 sound/core/seq/oss/seq_oss.c:153
> __fput+0x234/0x470 fs/file_table.c:209
> ____fput+0x15/0x20 fs/file_table.c:243
> task_work_run+0x15a/0x1c0 kernel/task_work.c:113
> tracehook_notify_resume include/linux/tracehook.h:192 [inline]
> exit_to_usermode_loop+0x2a3/0x2b0 arch/x86/entry/common.c:166
> prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline]
> syscall_return_slowpath arch/x86/entry/common.c:268 [inline]
> do_syscall_64+0x485/0x4b0 arch/x86/entry/common.c:293
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x456469
> Code: 1d ba fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 eb b9 fb ff c3 66 2e 0f 1f 84 00 00 00 00
> RSP: 002b:00007fe9a8936b28 EFLAGS: 00000246 ORIG_RAX: 0000000000000003
> RAX: 0000000000000000 RBX: 000000000072bfa0 RCX: 0000000000456469
> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000014
> RBP: 0000000000000054 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 00007fe9a89376d4
> R13: 00000000ffffffff R14: 00000000006f5880 R15: 0000000000000000
> Dumping ftrace buffer:
> (ftrace buffer empty)
> Kernel Offset: disabled
> Rebooting in 86400 seconds..
>
>
> = About RaceFuzzer
>
> RaceFuzzer is a customized version of Syzkaller, specifically tailored
> to find race condition bugs in the Linux kernel. While we leverage
> many different technique, the notable feature of RaceFuzzer is in
> leveraging a custom hypervisor (QEMU/KVM) to interleave the
> scheduling. In particular, we modified the hypervisor to intentionally
> stall a per-core execution, which is similar to supporting per-core
> breakpoint functionality. This allows RaceFuzzer to force the kernel
> to deterministically trigger racy condition (which may rarely happen
> in practice due to randomness in scheduling).
>
> RaceFuzzer's C repro always pinpoints two racy syscalls. Since C
> repro's scheduling synchronization should be performed at the user
> space, its reproducibility is limited (reproduction may take from 1
> second to 10 minutes (or even more), depending on a bug). This is
> because, while RaceFuzzer precisely interleaves the scheduling at the
> kernel's instruction level when finding this bug, C repro cannot fully
> utilize such a feature. Please disregard all code related to
> "should_hypercall" in the C repro, as this is only for our debugging
> purposes using our own hypervisor.
^ permalink raw reply
* Re: WARNING in port_delete
From: DaeRyong Jeong @ 2018-07-24 3:59 UTC (permalink / raw)
To: perex, tiwai, Colin King
Cc: bammanag, alsa-devel, Kyungtae Kim, LKML, syzkaller,
Byoungyoung Lee
In-Reply-To: <20180724033608.GA17607@dragonet>
I just realized that the crash has been spotted by Syzkaller a few days before.
(https://syzkaller.appspot.com/bug?id=3490860a465e6b39227c6906f0ef2d40ad4d5bb1)
I'm CC'ing Syzkaller's mailing list.
Best regards,
DaeRyong Jeong
On Tue, Jul 24, 2018 at 12:36 PM, Dae R. Jeong <threeearcat@gmail.com> wrote:
> Reporting the crash: WARNING in port_delete
>
> This crash has been found in v4.18-rc3 using RaceFuzzer (a modified
> version of Syzkaller), which we descrbie more at the end of this
> report. Our analysis shows that the race occurs when invoking two close
> syscalls concurrently.
>
>
> The executed program is as follows:
> r0 = open("/dev/snd/seq", 0x0, 0x0)
> ioctl(r0, SNDRV_SEQ_IOCTL_CREATE_PORT, {{0x80}, "706f72943000000000000000000000000000000000000000000000000000000000233f770800000000000000000000000000000000000000001000", 0xffffffffffffffff, 0xfffffffffffffbff})
> r1 = openat(AT_FDCWD, "/dev/sequencer2", 0x8402, 0x0)
> close(r0)
> close(r1)
>
> and two threads executed the program as follows:
> Thread0 Thread1
> open("/dev/snd/seq")
> ioctl(r0, SNDRV_SEQ_IOCTL_CREATE_PORT)
> openat("/dev/sequencer2")
> close(r0) close(r1)
>
> (Note that two close() syscalls were exeuted after openat() syscall, and
> two close() syscalls were executed concurrently.)
>
>
> Crash log:
> ==================================================================
> WARNING: CPU: 1 PID: 32519 at /home/daeryong/workspace/race-fuzzer/kernels_repo/kernel_v4.18-rc3/sound/core/seq/seq_ports.c:275 port_delete+0xde/0xf0 sound/core/seq/seq_ports.c:275
> Kernel panic - not syncing: panic_on_warn set ...
>
> CPU: 1 PID: 32519 Comm: syz-executor0 Not tainted 4.18.0-rc3 #1
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x16e/0x22c lib/dump_stack.c:113
> panic+0x1a8/0x3a7 kernel/panic.c:184
> __warn+0x191/0x1a0 kernel/panic.c:536
> report_bug+0x132/0x1b0 lib/bug.c:186
> fixup_bug.part.10+0x28/0x50 arch/x86/kernel/traps.c:178
> fixup_bug arch/x86/kernel/traps.c:247 [inline]
> do_error_trap+0x284/0x2c0 arch/x86/kernel/traps.c:296
> do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:316
> invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:992
> RIP: 0010:port_delete+0xde/0xf0 sound/core/seq/seq_ports.c:275
> Code: 00 00 e8 b5 68 d2 fd 8b 83 58 01 00 00 85 c0 75 1d e8 86 5c ae fd 48 89 df e8 3e 52 d2 fd 31 c0 5b 41 5c 5d c3 e8 72 5c ae fd <0f> 0b eb c8 e8 69 5c ae fd 0f 0b eb da 0f 1f 44 00 00 55 48 89 e5
> RSP: 0018:ffff8801d635f900 EFLAGS: 00010216
> RAX: 0000000000040000 RBX: ffff8801da196900 RCX: ffffffff839b86ee
> RDX: 0000000000005e94 RSI: ffffc90002640000 RDI: ffff8801da196978
> RBP: ffff8801d635f910 R08: 0000000000000098 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff839ba820
> R13: ffff8801da196950 R14: ffff8801ed5bc080 R15: ffff8801da196958
> snd_seq_delete_port+0x2b0/0x2d0 sound/core/seq/seq_ports.c:303
> snd_seq_ioctl_delete_port+0x5b/0xa0 sound/core/seq/seq_clientmgr.c:1325
> snd_seq_kernel_client_ctl+0xd4/0xf0 sound/core/seq/seq_clientmgr.c:2361
> snd_seq_event_port_detach+0xcb/0x120 sound/core/seq/seq_ports.c:705
> delete_port+0x3a/0x70 sound/core/seq/oss/seq_oss_init.c:354
> snd_seq_oss_release+0x7c/0x90 sound/core/seq/oss/seq_oss_init.c:433
> odev_release+0x40/0x60 sound/core/seq/oss/seq_oss.c:153
> __fput+0x234/0x470 fs/file_table.c:209
> ____fput+0x15/0x20 fs/file_table.c:243
> task_work_run+0x15a/0x1c0 kernel/task_work.c:113
> tracehook_notify_resume include/linux/tracehook.h:192 [inline]
> exit_to_usermode_loop+0x2a3/0x2b0 arch/x86/entry/common.c:166
> prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline]
> syscall_return_slowpath arch/x86/entry/common.c:268 [inline]
> do_syscall_64+0x485/0x4b0 arch/x86/entry/common.c:293
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x456469
> Code: 1d ba fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 eb b9 fb ff c3 66 2e 0f 1f 84 00 00 00 00
> RSP: 002b:00007fe9a8936b28 EFLAGS: 00000246 ORIG_RAX: 0000000000000003
> RAX: 0000000000000000 RBX: 000000000072bfa0 RCX: 0000000000456469
> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000014
> RBP: 0000000000000054 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 00007fe9a89376d4
> R13: 00000000ffffffff R14: 00000000006f5880 R15: 0000000000000000
> Dumping ftrace buffer:
> (ftrace buffer empty)
> Kernel Offset: disabled
> Rebooting in 86400 seconds..
>
>
> = About RaceFuzzer
>
> RaceFuzzer is a customized version of Syzkaller, specifically tailored
> to find race condition bugs in the Linux kernel. While we leverage
> many different technique, the notable feature of RaceFuzzer is in
> leveraging a custom hypervisor (QEMU/KVM) to interleave the
> scheduling. In particular, we modified the hypervisor to intentionally
> stall a per-core execution, which is similar to supporting per-core
> breakpoint functionality. This allows RaceFuzzer to force the kernel
> to deterministically trigger racy condition (which may rarely happen
> in practice due to randomness in scheduling).
>
> RaceFuzzer's C repro always pinpoints two racy syscalls. Since C
> repro's scheduling synchronization should be performed at the user
> space, its reproducibility is limited (reproduction may take from 1
> second to 10 minutes (or even more), depending on a bug). This is
> because, while RaceFuzzer precisely interleaves the scheduling at the
> kernel's instruction level when finding this bug, C repro cannot fully
> utilize such a feature. Please disregard all code related to
> "should_hypercall" in the C repro, as this is only for our debugging
> purposes using our own hypervisor.
^ permalink raw reply
* Re: [PATCH] 9p: validate PDU length
From: Dominique Martinet @ 2018-07-24 3:57 UTC (permalink / raw)
To: Tomas Bortoli
Cc: ericvh, rminnich, lucho, davem, v9fs-developer, netdev,
linux-kernel, syzkaller
In-Reply-To: <20180723154404.2406-1-tomasbortoli@gmail.com>
Tomas Bortoli wrote on Mon, Jul 23, 2018:
> This commit adds length check for the PDU size.
> The size contained in the header has to match the actual size,
> except for TCP (trans_fd.c) where actual length is not known ahead
> and the header's length will be checked only against the validity
> range.
>
> Signed-off-by: Tomas Bortoli <tomasbortoli@gmail.com>
> Reported-by: syzbot+65c6b72f284a39d416b4@syzkaller.appspotmail.com
Ok, I've run some more in-depth testing this time and all appear in
order.
Like I said last time, I cannot test the xen transport - if someone can
point me to how to set it up or run some tests semi-regularily it'd be
great.
Meanwhile, code looks good and appears to work, so I'll take this
patch unless someone yells
> ---
> net/9p/client.c | 25 ++++++++++++++++---------
> net/9p/trans_fd.c | 5 ++++-
> net/9p/trans_rdma.c | 1 +
> net/9p/trans_virtio.c | 4 +++-
> 4 files changed, 24 insertions(+), 11 deletions(-)
>
> diff --git a/net/9p/client.c b/net/9p/client.c
> index 18c5271910dc..92240ccf476b 100644
> --- a/net/9p/client.c
> +++ b/net/9p/client.c
> @@ -477,20 +477,11 @@ p9_parse_header(struct p9_fcall *pdu, int32_t *size, int8_t *type, int16_t *tag,
> int err;
>
> pdu->offset = 0;
> - if (pdu->size == 0)
> - pdu->size = 7;
>
> err = p9pdu_readf(pdu, 0, "dbw", &r_size, &r_type, &r_tag);
> if (err)
> goto rewind_and_exit;
>
> - pdu->size = r_size;
> - pdu->id = r_type;
> - pdu->tag = r_tag;
> -
> - p9_debug(P9_DEBUG_9P, "<<< size=%d type: %d tag: %d\n",
> - pdu->size, pdu->id, pdu->tag);
> -
> if (type)
> *type = r_type;
> if (tag)
> @@ -498,6 +489,16 @@ p9_parse_header(struct p9_fcall *pdu, int32_t *size, int8_t *type, int16_t *tag,
> if (size)
> *size = r_size;
>
> + if (pdu->size != r_size || r_size < 7) {
> + err = -EINVAL;
> + goto rewind_and_exit;
> + }
> +
> + pdu->id = r_type;
> + pdu->tag = r_tag;
> +
> + p9_debug(P9_DEBUG_9P, "<<< size=%d type: %d tag: %d\n",
> + pdu->size, pdu->id, pdu->tag);
>
> rewind_and_exit:
> if (rewind)
> @@ -524,6 +525,12 @@ static int p9_check_errors(struct p9_client *c, struct p9_req_t *req)
> int ecode;
>
> err = p9_parse_header(req->rc, NULL, &type, NULL, 0);
> + if (req->rc->size >= c->msize) {
> + p9_debug(P9_DEBUG_ERROR,
> + "requested packet size too big: %d\n",
> + req->rc->size);
> + return -EIO;
Indentation here looks wrong, I took the liberty of deindenting that
return in my tree.
> + }
> /*
> * dump the response from server
> * This should be after check errors which poplulate pdu_fcall.
> diff --git a/net/9p/trans_fd.c b/net/9p/trans_fd.c
> index 588bf88c3305..65533c437b7f 100644
> --- a/net/9p/trans_fd.c
> +++ b/net/9p/trans_fd.c
> @@ -324,7 +324,9 @@ static void p9_read_work(struct work_struct *work)
> if ((!m->req) && (m->rc.offset == m->rc.capacity)) {
> p9_debug(P9_DEBUG_TRANS, "got new header\n");
>
> - err = p9_parse_header(&m->rc, NULL, NULL, NULL, 0);
> + /* Header size */
> + m->rc.size = 7;
> + err = p9_parse_header(&m->rc, &m->rc.size, NULL, NULL, 0);
> if (err) {
> p9_debug(P9_DEBUG_ERROR,
> "error parsing header: %d\n", err);
> @@ -369,6 +371,7 @@ static void p9_read_work(struct work_struct *work)
> */
> if ((m->req) && (m->rc.offset == m->rc.capacity)) {
> p9_debug(P9_DEBUG_TRANS, "got new packet\n");
> + m->req->rc->size = m->rc.offset;
> spin_lock(&m->client->lock);
> if (m->req->status != REQ_STATUS_ERROR)
> status = REQ_STATUS_RCVD;
> diff --git a/net/9p/trans_rdma.c b/net/9p/trans_rdma.c
> index 3d414acb7015..2649b2ebf961 100644
> --- a/net/9p/trans_rdma.c
> +++ b/net/9p/trans_rdma.c
> @@ -320,6 +320,7 @@ recv_done(struct ib_cq *cq, struct ib_wc *wc)
> if (wc->status != IB_WC_SUCCESS)
> goto err_out;
>
> + c->rc->size = wc->byte_len;
> err = p9_parse_header(c->rc, NULL, NULL, &tag, 1);
> if (err)
> goto err_out;
> diff --git a/net/9p/trans_virtio.c b/net/9p/trans_virtio.c
> index 05006cbb3361..fc6dc9ca86a4 100644
> --- a/net/9p/trans_virtio.c
> +++ b/net/9p/trans_virtio.c
> @@ -159,8 +159,10 @@ static void req_done(struct virtqueue *vq)
> spin_unlock_irqrestore(&chan->lock, flags);
> /* Wakeup if anyone waiting for VirtIO ring space. */
> wake_up(chan->vc_wq);
> - if (len)
> + if (len) {
> + req->rc->size = len;
> p9_client_cb(chan->client, req, REQ_STATUS_RCVD);
> + }
> }
> }
>
--
Dominique Martinet
^ permalink raw reply
* Re: [Qemu-devel] [PATCH qemu v2] vfio/spapr: Allow backing bigger guest IOMMU pages with smaller physical pages
From: Alexey Kardashevskiy @ 2018-07-24 3:56 UTC (permalink / raw)
To: David Gibson; +Cc: qemu-devel, qemu-ppc, Alex Williamson
In-Reply-To: <20180723031142.GA6830@umbus.fritz.box>
[-- Attachment #1: Type: text/plain, Size: 5377 bytes --]
On 23/07/2018 13:11, David Gibson wrote:
> On Wed, Jun 20, 2018 at 07:10:12PM +1000, Alexey Kardashevskiy wrote:
>> At the moment the PPC64/pseries guest only supports 4K/64K/16M IOMMU
>> pages and POWER8 CPU supports the exact same set of page size so
>> so far things worked fine.
>>
>> However POWER9 supports different set of sizes - 4K/64K/2M/1G and
>> the last two - 2M and 1G - are not even allowed in the paravirt interface
>> (RTAS DDW) so we always end up using 64K IOMMU pages, although we could
>> back guest's 16MB IOMMU pages with 2MB pages on the host.
>>
>> This stores the supported host IOMMU page sizes in VFIOContainer and uses
>> this later when creating a new DMA window. This uses the system page size
>> (64k normally, 2M/16M/1G if hugepages used) as the upper limit of
>> the IOMMU pagesize.
>>
>> This changes the type of @pagesize to uint64_t as this is what
>> memory_region_iommu_get_min_page_size() returns and clz64() takes.
>>
>> There should be no behavioral changes on platforms other than pseries.
>> The guest will keep using the IOMMU page size selected by the PHB pagesize
>> property as this only changes the underlying hardware TCE table
>> granularity.
>>
>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>> ---
>> Changes:
>> v2:
>> * fixed biggest but smaller page size calculation
>> * limit IOMMU pagesize to the system pagesize
>
> Sorry, this fell of my radar for a bit.
>
> I've now applied it to ppc-for-3.1.
Alex might object that as it does not have his "rb" ;)
>
>> ---
>> include/hw/vfio/vfio-common.h | 1 +
>> hw/vfio/common.c | 3 +++
>> hw/vfio/spapr.c | 21 ++++++++++++++++++++-
>> 3 files changed, 24 insertions(+), 1 deletion(-)
>>
>> diff --git a/include/hw/vfio/vfio-common.h b/include/hw/vfio/vfio-common.h
>> index a903692..c20524d 100644
>> --- a/include/hw/vfio/vfio-common.h
>> +++ b/include/hw/vfio/vfio-common.h
>> @@ -73,6 +73,7 @@ typedef struct VFIOContainer {
>> unsigned iommu_type;
>> int error;
>> bool initialized;
>> + unsigned long pgsizes;
>> /*
>> * This assumes the host IOMMU can support only a single
>> * contiguous IOVA window. We may need to generalize that in
>> diff --git a/hw/vfio/common.c b/hw/vfio/common.c
>> index fb396cf..40f0356 100644
>> --- a/hw/vfio/common.c
>> +++ b/hw/vfio/common.c
>> @@ -1108,6 +1108,7 @@ static int vfio_connect_container(VFIOGroup *group, AddressSpace *as,
>> info.iova_pgsizes = 4096;
>> }
>> vfio_host_win_add(container, 0, (hwaddr)-1, info.iova_pgsizes);
>> + container->pgsizes = info.iova_pgsizes;
>> } else if (ioctl(fd, VFIO_CHECK_EXTENSION, VFIO_SPAPR_TCE_IOMMU) ||
>> ioctl(fd, VFIO_CHECK_EXTENSION, VFIO_SPAPR_TCE_v2_IOMMU)) {
>> struct vfio_iommu_spapr_tce_info info;
>> @@ -1172,6 +1173,7 @@ static int vfio_connect_container(VFIOGroup *group, AddressSpace *as,
>> }
>>
>> if (v2) {
>> + container->pgsizes = info.ddw.pgsizes;
>> /*
>> * There is a default window in just created container.
>> * To make region_add/del simpler, we better remove this
>> @@ -1186,6 +1188,7 @@ static int vfio_connect_container(VFIOGroup *group, AddressSpace *as,
>> }
>> } else {
>> /* The default table uses 4K pages */
>> + container->pgsizes = 0x1000;
>> vfio_host_win_add(container, info.dma32_window_start,
>> info.dma32_window_start +
>> info.dma32_window_size - 1,
>> diff --git a/hw/vfio/spapr.c b/hw/vfio/spapr.c
>> index 259397c..becf71a 100644
>> --- a/hw/vfio/spapr.c
>> +++ b/hw/vfio/spapr.c
>> @@ -15,6 +15,7 @@
>>
>> #include "hw/vfio/vfio-common.h"
>> #include "hw/hw.h"
>> +#include "exec/ram_addr.h"
>> #include "qemu/error-report.h"
>> #include "trace.h"
>>
>> @@ -144,9 +145,27 @@ int vfio_spapr_create_window(VFIOContainer *container,
>> {
>> int ret;
>> IOMMUMemoryRegion *iommu_mr = IOMMU_MEMORY_REGION(section->mr);
>> - unsigned pagesize = memory_region_iommu_get_min_page_size(iommu_mr);
>> + uint64_t pagesize = memory_region_iommu_get_min_page_size(iommu_mr);
>> unsigned entries, pages;
>> struct vfio_iommu_spapr_tce_create create = { .argsz = sizeof(create) };
>> + long systempagesize = qemu_getrampagesize();
>> +
>> + /*
>> + * The host might not support the guest supported IOMMU page size,
>> + * so we will use smaller physical IOMMU pages to back them.
>> + */
>> + if (pagesize > systempagesize) {
>> + pagesize = systempagesize;
>> + }
>> + pagesize = 1ULL << (63 - clz64(container->pgsizes &
>> + (pagesize | (pagesize - 1))));
>> + if (!pagesize) {
>> + error_report("Host doesn't support page size 0x%"PRIx64
>> + ", the supported mask is 0x%lx",
>> + memory_region_iommu_get_min_page_size(iommu_mr),
>> + container->pgsizes);
>> + return -EINVAL;
>> + }
>>
>> /*
>> * FIXME: For VFIO iommu types which have KVM acceleration to
>
--
Alexey
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.