* [PATCH 12/12] ARM: dts: imx6ul-14x14-evk: Move regulators out of simple-bus
From: Fabio Estevam @ 2017-12-01 19:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512156285-18451-1-git-send-email-festevam@gmail.com>
From: Fabio Estevam <fabio.estevam@nxp.com>
It is not recommended to place regulator nodes inside simple-bus, so
move them out in order to fix the following build warnings with W=1:
arch/arm/boot/dts/imx6ul-14x14-evk.dtb: Warning (simple_bus_reg): Node /regulators/sd1_regulator missing or empty reg/ranges property
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
---
arch/arm/boot/dts/imx6ul-14x14-evk.dts | 19 +++++++------------
1 file changed, 7 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/imx6ul-14x14-evk.dts b/arch/arm/boot/dts/imx6ul-14x14-evk.dts
index e5d3ef8..18fdb08 100644
--- a/arch/arm/boot/dts/imx6ul-14x14-evk.dts
+++ b/arch/arm/boot/dts/imx6ul-14x14-evk.dts
@@ -30,19 +30,14 @@
status = "okay";
};
- regulators {
- compatible = "simple-bus";
- #address-cells = <1>;
- #size-cells = <0>;
- reg_sd1_vmmc: sd1_regulator {
- compatible = "regulator-fixed";
- regulator-name = "VSD_3V3";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- gpio = <&gpio1 9 GPIO_ACTIVE_HIGH>;
- enable-active-high;
- };
+ reg_sd1_vmmc: regulator-sd1-vmmc {
+ compatible = "regulator-fixed";
+ regulator-name = "VSD_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ gpio = <&gpio1 9 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
};
sound {
--
2.7.4
^ permalink raw reply related
* [PATCH 11/12] ARM: dts: imx6qdl-nitrogen6_max: Remove unneeded unit address
From: Fabio Estevam @ 2017-12-01 19:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512156285-18451-1-git-send-email-festevam@gmail.com>
From: Fabio Estevam <fabio.estevam@nxp.com>
Remove the unneeded unit address for the i2cmux nodes in order to fix
the following build warnings with W=1:
arch/arm/boot/dts/imx6q-nitrogen6_max.dtb: Warning (unit_address_vs_reg): Node /i2cmux at 2 has a unit name, but no reg property
arch/arm/boot/dts/imx6q-nitrogen6_max.dtb: Warning (unit_address_vs_reg): Node /i2cmux at 3 has a unit name, but no reg property
Cc: Gary Bisson <gary.bisson@boundarydevices.com>
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
---
arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi b/arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi
index 3a77f0f..3cdffed 100644
--- a/arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi
@@ -172,7 +172,7 @@
};
};
- i2cmux at 2 {
+ i2cmux2 {
compatible = "i2c-mux-gpio";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_i2c2mux>;
@@ -196,7 +196,7 @@
};
};
- i2cmux at 3 {
+ i2cmux3 {
compatible = "i2c-mux-gpio";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_i2c3mux>;
--
2.7.4
^ permalink raw reply related
* [PATCH 10/12] ARM: dts: imx6q-h100: Remove unneeded unit address
From: Fabio Estevam @ 2017-12-01 19:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512156285-18451-1-git-send-email-festevam@gmail.com>
From: Fabio Estevam <fabio.estevam@nxp.com>
Remove the unneeded unit address for the port nodes in order to fix
the following build warnings with W=1:
arch/arm/boot/dts/imx6q-h100.dtb: Warning (unit_address_vs_reg): Node /soc/aips-bus at 2100000/i2c at 21a0000/tc358743 at f/port at 0 has a unit name, but no reg property
arch/arm/boot/dts/imx6q-h100.dtb: Warning (unit_address_vs_reg): Node /soc/aips-bus at 2100000/mipi at 21dc000/port at 0 has a unit name, but no reg property
Cc: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
---
arch/arm/boot/dts/imx6q-h100.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/imx6q-h100.dts b/arch/arm/boot/dts/imx6q-h100.dts
index 743c11f..cc1ce46 100644
--- a/arch/arm/boot/dts/imx6q-h100.dts
+++ b/arch/arm/boot/dts/imx6q-h100.dts
@@ -205,7 +205,7 @@
reset-gpios = <&gpio6 15 GPIO_ACTIVE_LOW>;
/* IRQ has a wrong pull resistor which renders it useless */
- port at 0 {
+ port {
tc358743_out: endpoint {
remote-endpoint = <&mipi_csi2_in>;
data-lanes = <1 2 3 4>;
@@ -348,7 +348,7 @@
&mipi_csi {
status = "okay";
- port at 0 {
+ port {
mipi_csi2_in: endpoint {
remote-endpoint = <&tc358743_out>;
data-lanes = <1 2 3 4>;
--
2.7.4
^ permalink raw reply related
* [PATCH 09/12] ARM: dts: imx6qdl-colibri: Remove unneeded reg property
From: Fabio Estevam @ 2017-12-01 19:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512156285-18451-1-git-send-email-festevam@gmail.com>
From: Fabio Estevam <fabio.estevam@nxp.com>
As described in
Documentation/devicetree/bindings/input/touchscreen/stmpe.txt
there is no 'reg' property under stmpe_touchscreen, so remove it
to fix the following build warning with W=1:
arch/arm/boot/dts/imx6dl-colibri-eval-v3.dtb: Warning (unit_address_vs_reg): Node /soc/aips-bus at 2100000/i2c at 21a4000/stmpe811 at 41/stmpe_touchscreen has a reg or ranges property, but no unit name
Cc: Sanchayan Maity <maitysanchayan@gmail.com>
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
---
arch/arm/boot/dts/imx6qdl-colibri.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx6qdl-colibri.dtsi b/arch/arm/boot/dts/imx6qdl-colibri.dtsi
index fc66bbf..e4eb300 100644
--- a/arch/arm/boot/dts/imx6qdl-colibri.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-colibri.dtsi
@@ -274,7 +274,6 @@
stmpe_touchscreen {
compatible = "st,stmpe-ts";
- reg = <0>;
/* 3.25 MHz ADC clock speed */
st,adc-freq = <1>;
/* 8 sample average control */
--
2.7.4
^ permalink raw reply related
* [PATCH 08/12] ARM: dts: imx6qdl-apalis: Remove unneeded reg property
From: Fabio Estevam @ 2017-12-01 19:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512156285-18451-1-git-send-email-festevam@gmail.com>
From: Fabio Estevam <fabio.estevam@nxp.com>
As described in
Documentation/devicetree/bindings/input/touchscreen/stmpe.txt
there is no 'reg' property under stmpe_touchscreen, so remove it
to fix the following build warning with W=1:
arch/arm/boot/dts/imx6q-apalis-eval.dtb: Warning (unit_address_vs_reg): Node /soc/aips-bus at 2100000/i2c at 21a4000/stmpe811 at 41/stmpe_touchscreen has a reg or ranges property, but no unit name
Cc: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
---
arch/arm/boot/dts/imx6qdl-apalis.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx6qdl-apalis.dtsi b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
index e80fdca..4e776e0 100644
--- a/arch/arm/boot/dts/imx6qdl-apalis.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
@@ -338,7 +338,6 @@
stmpe_touchscreen {
compatible = "st,stmpe-ts";
- reg = <0>;
/* 3.25 MHz ADC clock speed */
st,adc-freq = <1>;
/* 8 sample average control */
--
2.7.4
^ permalink raw reply related
* [PATCH 07/12] ARM: dts: imx6qdl-aristainetos: Move display node out of 'soc'
From: Fabio Estevam @ 2017-12-01 19:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512156285-18451-1-git-send-email-festevam@gmail.com>
From: Fabio Estevam <fabio.estevam@nxp.com>
Move disp0 node from soc node to root node.
disp0 node does not have any register properties and thus
shouldn't be placed on the bus.
This fixes the following build warnings with W=1:
arch/arm/boot/dts/imx6dl-aristainetos_4.dtb: Warning (simple_bus_reg): Node /soc/disp0 missing or empty reg/ranges property
Cc: Heiko Schocher <hs@denx.de>
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
---
arch/arm/boot/dts/imx6dl-aristainetos_4.dts | 50 ++++++++++++++---------------
arch/arm/boot/dts/imx6dl-aristainetos_7.dts | 48 +++++++++++++--------------
2 files changed, 47 insertions(+), 51 deletions(-)
diff --git a/arch/arm/boot/dts/imx6dl-aristainetos_4.dts b/arch/arm/boot/dts/imx6dl-aristainetos_4.dts
index cc418ce..3c9f4af 100644
--- a/arch/arm/boot/dts/imx6dl-aristainetos_4.dts
+++ b/arch/arm/boot/dts/imx6dl-aristainetos_4.dts
@@ -31,35 +31,33 @@
reg = <0x10000000 0x40000000>;
};
- soc {
- display0: disp0 {
- compatible = "fsl,imx-parallel-display";
- interface-pix-fmt = "rgb24";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_ipu_disp>;
- status = "okay";
+ display0: disp0 {
+ compatible = "fsl,imx-parallel-display";
+ interface-pix-fmt = "rgb24";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ipu_disp>;
+ status = "okay";
- display-timings {
- 480x800p60 {
- native-mode;
- clock-frequency = <30000000>;
- hactive = <480>;
- vactive = <800>;
- hfront-porch = <59>;
- hback-porch = <10>;
- hsync-len = <10>;
- vback-porch = <15>;
- vfront-porch = <15>;
- vsync-len = <15>;
- hsync-active = <1>;
- vsync-active = <1>;
- };
+ display-timings {
+ 480x800p60 {
+ native-mode;
+ clock-frequency = <30000000>;
+ hactive = <480>;
+ vactive = <800>;
+ hfront-porch = <59>;
+ hback-porch = <10>;
+ hsync-len = <10>;
+ vback-porch = <15>;
+ vfront-porch = <15>;
+ vsync-len = <15>;
+ hsync-active = <1>;
+ vsync-active = <1>;
};
+ };
- port {
- display0_in: endpoint {
- remote-endpoint = <&ipu1_di0_disp0>;
- };
+ port {
+ display0_in: endpoint {
+ remote-endpoint = <&ipu1_di0_disp0>;
};
};
};
diff --git a/arch/arm/boot/dts/imx6dl-aristainetos_7.dts b/arch/arm/boot/dts/imx6dl-aristainetos_7.dts
index 126ff96..96cd835 100644
--- a/arch/arm/boot/dts/imx6dl-aristainetos_7.dts
+++ b/arch/arm/boot/dts/imx6dl-aristainetos_7.dts
@@ -20,34 +20,32 @@
reg = <0x10000000 0x40000000>;
};
- soc {
- display0: disp0 {
- compatible = "fsl,imx-parallel-display";
- interface-pix-fmt = "rgb24";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_ipu_disp>;
- status = "okay";
+ display0: disp0 {
+ compatible = "fsl,imx-parallel-display";
+ interface-pix-fmt = "rgb24";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ipu_disp>;
+ status = "okay";
- display-timings {
- 800x480p60 {
- native-mode;
- clock-frequency = <33246000>;
- hactive = <800>;
- vactive = <480>;
- hfront-porch = <88>;
- hback-porch = <88>;
- hsync-len = <80>;
- vback-porch = <10>;
- vfront-porch = <10>;
- vsync-len = <25>;
- vsync-active = <1>;
- };
+ display-timings {
+ 800x480p60 {
+ native-mode;
+ clock-frequency = <33246000>;
+ hactive = <800>;
+ vactive = <480>;
+ hfront-porch = <88>;
+ hback-porch = <88>;
+ hsync-len = <80>;
+ vback-porch = <10>;
+ vfront-porch = <10>;
+ vsync-len = <25>;
+ vsync-active = <1>;
};
+ };
- port {
- display0_in: endpoint {
- remote-endpoint = <&ipu1_di0_disp0>;
- };
+ port {
+ display0_in: endpoint {
+ remote-endpoint = <&ipu1_di0_disp0>;
};
};
};
--
2.7.4
^ permalink raw reply related
* [PATCH 06/12] ARM: dts: imx6qdl-aristainetos: Move regulators out of simple-bus
From: Fabio Estevam @ 2017-12-01 19:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512156285-18451-1-git-send-email-festevam@gmail.com>
From: Fabio Estevam <fabio.estevam@nxp.com>
It is not recommended to place regulator nodes inside simple-bus, so
move them out in order to fix the following build warnings with W=1:
arch/arm/boot/dts/imx6dl-aristainetos_4.dtb: Warning (unit_address_vs_reg): Node /memory has a reg or ranges property, but no unit name
arch/arm/boot/dts/imx6dl-aristainetos_4.dtb: Warning (unit_address_vs_reg): Node /regulators/regulator at 0 has a unit name, but no reg property
arch/arm/boot/dts/imx6dl-aristainetos_4.dtb: Warning (unit_address_vs_reg): Node /regulators/regulator at 1 has a unit name, but no reg property
arch/arm/boot/dts/imx6dl-aristainetos_4.dtb: Warning (unit_address_vs_reg): Node /regulators/regulator at 2 has a unit name, but no reg property
arch/arm/boot/dts/imx6dl-aristainetos_4.dtb: Warning (unit_address_vs_reg): Node /regulators/regulator at 3 has a unit name, but no reg property
Cc: Heiko Schocher <hs@denx.de>
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
---
arch/arm/boot/dts/imx6qdl-aristainetos.dtsi | 73 +++++++++++++-------------
arch/arm/boot/dts/imx6qdl-aristainetos2.dtsi | 76 +++++++++++++---------------
2 files changed, 70 insertions(+), 79 deletions(-)
diff --git a/arch/arm/boot/dts/imx6qdl-aristainetos.dtsi b/arch/arm/boot/dts/imx6qdl-aristainetos.dtsi
index 7d64075..ee4d0f8 100644
--- a/arch/arm/boot/dts/imx6qdl-aristainetos.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-aristainetos.dtsi
@@ -12,48 +12,43 @@
#include <dt-bindings/gpio/gpio.h>
/ {
- regulators {
- compatible = "simple-bus";
- #address-cells = <1>;
- #size-cells = <0>;
-
- reg_2p5v: regulator at 0 {
- compatible = "regulator-fixed";
- regulator-name = "2P5V";
- regulator-min-microvolt = <2500000>;
- regulator-max-microvolt = <2500000>;
- regulator-always-on;
- };
- reg_3p3v: regulator at 1 {
- compatible = "regulator-fixed";
- regulator-name = "3P3V";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- regulator-always-on;
- };
+ reg_2p5v: regulator-2p5v {
+ compatible = "regulator-fixed";
+ regulator-name = "2P5V";
+ regulator-min-microvolt = <2500000>;
+ regulator-max-microvolt = <2500000>;
+ regulator-always-on;
+ };
- reg_usbh1_vbus: regulator at 2 {
- compatible = "regulator-fixed";
- enable-active-high;
- gpio = <&gpio3 31 GPIO_ACTIVE_HIGH>;
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_aristainetos_usbh1_vbus>;
- regulator-name = "usb_h1_vbus";
- regulator-min-microvolt = <5000000>;
- regulator-max-microvolt = <5000000>;
- };
+ reg_3p3v: regulator-3p3v {
+ compatible = "regulator-fixed";
+ regulator-name = "3P3V";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
- reg_usbotg_vbus: regulator at 3 {
- compatible = "regulator-fixed";
- enable-active-high;
- gpio = <&gpio4 15 GPIO_ACTIVE_HIGH>;
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_aristainetos_usbotg_vbus>;
- regulator-name = "usb_otg_vbus";
- regulator-min-microvolt = <5000000>;
- regulator-max-microvolt = <5000000>;
- };
+ reg_usbh1_vbus: regulator-usbh1-vbus {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = <&gpio3 31 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_aristainetos_usbh1_vbus>;
+ regulator-name = "usb_h1_vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ };
+
+ reg_usbotg_vbus: regulator-usbotg-vbus {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = <&gpio4 15 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_aristainetos_usbotg_vbus>;
+ regulator-name = "usb_otg_vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
};
};
diff --git a/arch/arm/boot/dts/imx6qdl-aristainetos2.dtsi b/arch/arm/boot/dts/imx6qdl-aristainetos2.dtsi
index 1b18728..3767508 100644
--- a/arch/arm/boot/dts/imx6qdl-aristainetos2.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-aristainetos2.dtsi
@@ -52,46 +52,42 @@
enable-gpios = <&gpio6 31 GPIO_ACTIVE_HIGH>;
};
- regulators {
- compatible = "simple-bus";
-
- reg_2p5v: 2p5v {
- compatible = "regulator-fixed";
- regulator-name = "2P5V";
- regulator-min-microvolt = <2500000>;
- regulator-max-microvolt = <2500000>;
- regulator-always-on;
- };
-
- reg_3p3v: 3p3v {
- compatible = "regulator-fixed";
- regulator-name = "3P3V";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- regulator-always-on;
- };
-
- reg_usbh1_vbus: usb-h1-vbus {
- compatible = "regulator-fixed";
- enable-active-high;
- gpio = <&gpio1 0 GPIO_ACTIVE_HIGH>;
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_aristainetos2_usbh1_vbus>;
- regulator-name = "usb_h1_vbus";
- regulator-min-microvolt = <5000000>;
- regulator-max-microvolt = <5000000>;
- };
-
- reg_usbotg_vbus: usb-otg-vbus {
- compatible = "regulator-fixed";
- enable-active-high;
- gpio = <&gpio4 15 GPIO_ACTIVE_HIGH>;
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_aristainetos2_usbotg_vbus>;
- regulator-name = "usb_otg_vbus";
- regulator-min-microvolt = <5000000>;
- regulator-max-microvolt = <5000000>;
- };
+ reg_2p5v: regulator-2p5v {
+ compatible = "regulator-fixed";
+ regulator-name = "2P5V";
+ regulator-min-microvolt = <2500000>;
+ regulator-max-microvolt = <2500000>;
+ regulator-always-on;
+ };
+
+ reg_3p3v: regulator-3p3v {
+ compatible = "regulator-fixed";
+ regulator-name = "3P3V";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ reg_usbh1_vbus: regulator-usbh1-vbus {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = <&gpio1 0 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_aristainetos2_usbh1_vbus>;
+ regulator-name = "usb_h1_vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ };
+
+ reg_usbotg_vbus: regulator-usbotg-vbus {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = <&gpio4 15 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_aristainetos2_usbotg_vbus>;
+ regulator-name = "usb_otg_vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
};
};
--
2.7.4
^ permalink raw reply related
* [PATCH 05/12] ARM: dts: imx6qdl-apf6dev: Move regulators out of simple-bus
From: Fabio Estevam @ 2017-12-01 19:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512156285-18451-1-git-send-email-festevam@gmail.com>
From: Fabio Estevam <fabio.estevam@nxp.com>
It is not recommended to place regulator nodes inside simple-bus, so
move them out in order to fix the following build warnings with W=1:
arch/arm/boot/dts/imx6dl-apf6dev.dtb: Warning (simple_bus_reg): Node /regulators/3p3v missing or empty reg/ranges property
arch/arm/boot/dts/imx6dl-apf6dev.dtb: Warning (simple_bus_reg): Node /regulators/usb-h1-vbus missing or empty reg/ranges property
arch/arm/boot/dts/imx6dl-apf6dev.dtb: Warning (simple_bus_reg): Node /regulators/usb-otg-vbus missing or empty reg/ranges property
Cc: S?bastien Szymanski <sebastien.szymanski@armadeus.com>
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
---
arch/arm/boot/dts/imx6qdl-apf6dev.dtsi | 44 ++++++++++++++++------------------
1 file changed, 20 insertions(+), 24 deletions(-)
diff --git a/arch/arm/boot/dts/imx6qdl-apf6dev.dtsi b/arch/arm/boot/dts/imx6qdl-apf6dev.dtsi
index 829a479..a61dd1a 100644
--- a/arch/arm/boot/dts/imx6qdl-apf6dev.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-apf6dev.dtsi
@@ -111,32 +111,28 @@
};
};
- regulators {
- compatible = "simple-bus";
-
- reg_3p3v: 3p3v {
- compatible = "regulator-fixed";
- regulator-name = "3P3V";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- regulator-always-on;
- };
+ reg_3p3v: regulator-3p3v {
+ compatible = "regulator-fixed";
+ regulator-name = "3P3V";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
- reg_usbh1_vbus: usb-h1-vbus {
- compatible = "regulator-fixed";
- regulator-name = "usb_h1_vbus";
- regulator-min-microvolt = <5000000>;
- regulator-max-microvolt = <5000000>;
- regulator-always-on;
- };
+ reg_usbh1_vbus: regulator-usb-h1-vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "usb_h1_vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-always-on;
+ };
- reg_usb_otg_vbus: usb-otg-vbus {
- compatible = "regulator-fixed";
- regulator-name = "usb_otg_vbus";
- regulator-min-microvolt = <5000000>;
- regulator-max-microvolt = <5000000>;
- regulator-always-on;
- };
+ reg_usb_otg_vbus: regulator-usb-otg-vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "usb_otg_vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-always-on;
};
sound {
--
2.7.4
^ permalink raw reply related
* [PATCH 04/12] ARM: dts: imx53-tx53-x03x: Move display node out of 'soc'
From: Fabio Estevam @ 2017-12-01 19:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512156285-18451-1-git-send-email-festevam@gmail.com>
From: Fabio Estevam <fabio.estevam@nxp.com>
Move disp0 node from soc node to root node.
disp0 node does not have any register properties and thus
shouldn't be placed on the bus.
This fixes the following build warnings with W=1:
arch/arm/boot/dts/imx53-tx53-x03x.dtb: Warning (simple_bus_reg): Node /soc/disp0 missing or empty reg/ranges property
Cc: Lothar Wa?mann <LW@KARO-electronics.de>
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
---
arch/arm/boot/dts/imx53-tx53-x03x.dts | 232 +++++++++++++++++-----------------
1 file changed, 115 insertions(+), 117 deletions(-)
diff --git a/arch/arm/boot/dts/imx53-tx53-x03x.dts b/arch/arm/boot/dts/imx53-tx53-x03x.dts
index 7eb53e4..fe15c95 100644
--- a/arch/arm/boot/dts/imx53-tx53-x03x.dts
+++ b/arch/arm/boot/dts/imx53-tx53-x03x.dts
@@ -53,132 +53,130 @@
display = &display;
};
- soc {
- display: disp0 {
- compatible = "fsl,imx-parallel-display";
- interface-pix-fmt = "rgb24";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_rgb24_vga1>;
- status = "okay";
+ display: disp0 {
+ compatible = "fsl,imx-parallel-display";
+ interface-pix-fmt = "rgb24";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_rgb24_vga1>;
+ status = "okay";
- port {
- display0_in: endpoint {
- remote-endpoint = <&ipu_di0_disp0>;
- };
+ port {
+ display0_in: endpoint {
+ remote-endpoint = <&ipu_di0_disp0>;
};
+ };
- display-timings {
- VGA {
- clock-frequency = <25200000>;
- hactive = <640>;
- vactive = <480>;
- hback-porch = <48>;
- hsync-len = <96>;
- hfront-porch = <16>;
- vback-porch = <31>;
- vsync-len = <2>;
- vfront-porch = <12>;
- hsync-active = <0>;
- vsync-active = <0>;
- de-active = <1>;
- pixelclk-active = <0>;
- };
+ display-timings {
+ VGA {
+ clock-frequency = <25200000>;
+ hactive = <640>;
+ vactive = <480>;
+ hback-porch = <48>;
+ hsync-len = <96>;
+ hfront-porch = <16>;
+ vback-porch = <31>;
+ vsync-len = <2>;
+ vfront-porch = <12>;
+ hsync-active = <0>;
+ vsync-active = <0>;
+ de-active = <1>;
+ pixelclk-active = <0>;
+ };
- ETV570 {
- clock-frequency = <25200000>;
- hactive = <640>;
- vactive = <480>;
- hback-porch = <114>;
- hsync-len = <30>;
- hfront-porch = <16>;
- vback-porch = <32>;
- vsync-len = <3>;
- vfront-porch = <10>;
- hsync-active = <0>;
- vsync-active = <0>;
- de-active = <1>;
- pixelclk-active = <0>;
- };
+ ETV570 {
+ clock-frequency = <25200000>;
+ hactive = <640>;
+ vactive = <480>;
+ hback-porch = <114>;
+ hsync-len = <30>;
+ hfront-porch = <16>;
+ vback-porch = <32>;
+ vsync-len = <3>;
+ vfront-porch = <10>;
+ hsync-active = <0>;
+ vsync-active = <0>;
+ de-active = <1>;
+ pixelclk-active = <0>;
+ };
- ET0350 {
- clock-frequency = <6413760>;
- hactive = <320>;
- vactive = <240>;
- hback-porch = <34>;
- hsync-len = <34>;
- hfront-porch = <20>;
- vback-porch = <15>;
- vsync-len = <3>;
- vfront-porch = <4>;
- hsync-active = <0>;
- vsync-active = <0>;
- de-active = <1>;
- pixelclk-active = <0>;
- };
+ ET0350 {
+ clock-frequency = <6413760>;
+ hactive = <320>;
+ vactive = <240>;
+ hback-porch = <34>;
+ hsync-len = <34>;
+ hfront-porch = <20>;
+ vback-porch = <15>;
+ vsync-len = <3>;
+ vfront-porch = <4>;
+ hsync-active = <0>;
+ vsync-active = <0>;
+ de-active = <1>;
+ pixelclk-active = <0>;
+ };
- ET0430 {
- clock-frequency = <9009000>;
- hactive = <480>;
- vactive = <272>;
- hback-porch = <2>;
- hsync-len = <41>;
- hfront-porch = <2>;
- vback-porch = <2>;
- vsync-len = <10>;
- vfront-porch = <2>;
- hsync-active = <0>;
- vsync-active = <0>;
- de-active = <1>;
- pixelclk-active = <1>;
- };
+ ET0430 {
+ clock-frequency = <9009000>;
+ hactive = <480>;
+ vactive = <272>;
+ hback-porch = <2>;
+ hsync-len = <41>;
+ hfront-porch = <2>;
+ vback-porch = <2>;
+ vsync-len = <10>;
+ vfront-porch = <2>;
+ hsync-active = <0>;
+ vsync-active = <0>;
+ de-active = <1>;
+ pixelclk-active = <1>;
+ };
- ET0500 {
- clock-frequency = <33264000>;
- hactive = <800>;
- vactive = <480>;
- hback-porch = <88>;
- hsync-len = <128>;
- hfront-porch = <40>;
- vback-porch = <33>;
- vsync-len = <2>;
- vfront-porch = <10>;
- hsync-active = <0>;
- vsync-active = <0>;
- de-active = <1>;
- pixelclk-active = <0>;
- };
+ ET0500 {
+ clock-frequency = <33264000>;
+ hactive = <800>;
+ vactive = <480>;
+ hback-porch = <88>;
+ hsync-len = <128>;
+ hfront-porch = <40>;
+ vback-porch = <33>;
+ vsync-len = <2>;
+ vfront-porch = <10>;
+ hsync-active = <0>;
+ vsync-active = <0>;
+ de-active = <1>;
+ pixelclk-active = <0>;
+ };
- ET0700 { /* same as ET0500 */
- clock-frequency = <33264000>;
- hactive = <800>;
- vactive = <480>;
- hback-porch = <88>;
- hsync-len = <128>;
- hfront-porch = <40>;
- vback-porch = <33>;
- vsync-len = <2>;
- vfront-porch = <10>;
- hsync-active = <0>;
- vsync-active = <0>;
- de-active = <1>;
- pixelclk-active = <0>;
- };
+ ET0700 { /* same as ET0500 */
+ clock-frequency = <33264000>;
+ hactive = <800>;
+ vactive = <480>;
+ hback-porch = <88>;
+ hsync-len = <128>;
+ hfront-porch = <40>;
+ vback-porch = <33>;
+ vsync-len = <2>;
+ vfront-porch = <10>;
+ hsync-active = <0>;
+ vsync-active = <0>;
+ de-active = <1>;
+ pixelclk-active = <0>;
+ };
- ETQ570 {
- clock-frequency = <6596040>;
- hactive = <320>;
- vactive = <240>;
- hback-porch = <38>;
- hsync-len = <30>;
- hfront-porch = <30>;
- vback-porch = <16>;
- vsync-len = <3>;
- vfront-porch = <4>;
- hsync-active = <0>;
- vsync-active = <0>;
- de-active = <1>;
- pixelclk-active = <0>;
- };
+ ETQ570 {
+ clock-frequency = <6596040>;
+ hactive = <320>;
+ vactive = <240>;
+ hback-porch = <38>;
+ hsync-len = <30>;
+ hfront-porch = <30>;
+ vback-porch = <16>;
+ vsync-len = <3>;
+ vfront-porch = <4>;
+ hsync-active = <0>;
+ vsync-active = <0>;
+ de-active = <1>;
+ pixelclk-active = <0>;
};
};
};
--
2.7.4
^ permalink raw reply related
* [PATCH 03/12] ARM: dts: imx53-m53: Remove unneeded reg property
From: Fabio Estevam @ 2017-12-01 19:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512156285-18451-1-git-send-email-festevam@gmail.com>
From: Fabio Estevam <fabio.estevam@nxp.com>
As described in
Documentation/devicetree/bindings/input/touchscreen/stmpe.txt
there is no 'reg' property under stmpe_touchscreen, so remove it
to fix the following build warning with W=1:
arch/arm/boot/dts/imx53-m53evk.dtb: Warning (unit_address_vs_reg): Node /soc/aips at 60000000/i2c at 63fc4000/stmpe610 at 41/stmpe_touchscreen has a reg or ranges property, but no unit name
Cc: Marek Vasut <marex@denx.de>
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
---
arch/arm/boot/dts/imx53-m53.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx53-m53.dtsi b/arch/arm/boot/dts/imx53-m53.dtsi
index ec390aa5..7ce69c6 100644
--- a/arch/arm/boot/dts/imx53-m53.dtsi
+++ b/arch/arm/boot/dts/imx53-m53.dtsi
@@ -64,7 +64,6 @@
stmpe_touchscreen {
compatible = "st,stmpe-ts";
- reg = <0>;
st,sample-time = <4>;
st,mod-12b = <1>;
st,ref-sel = <0>;
--
2.7.4
^ permalink raw reply related
* [PATCH 02/12] ARM: dts: imx51-zii-rdu1: Add the unit addresses in sysled
From: Fabio Estevam @ 2017-12-01 19:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512156285-18451-1-git-send-email-festevam@gmail.com>
From: Fabio Estevam <fabio.estevam@nxp.com>
As described at Documentation/devicetree/bindings/mfd/mc13xxx.txt the
reg property is mandatory, so add the corresponding unit address in
order to fix the following build warnings with W=1:
arch/arm/boot/dts/imx51-zii-rdu1.dtb: Warning (unit_address_vs_reg): Node /memory has a reg or ranges property, but no unit name
arch/arm/boot/dts/imx51-zii-rdu1.dtb: Warning (unit_address_vs_reg): Node /soc/aips at 70000000/spba at 70000000/ecspi at 70010000/pmic at 0/leds/sysled0 has a reg or ranges property, but no unit name
arch/arm/boot/dts/imx51-zii-rdu1.dtb: Warning (unit_address_vs_reg): Node /soc/aips at 70000000/spba at 70000000/ecspi at 70010000/pmic at 0/leds/sysled1 has a reg or ranges property, but no unit name
Cc: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
---
arch/arm/boot/dts/imx51-zii-rdu1.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/imx51-zii-rdu1.dts b/arch/arm/boot/dts/imx51-zii-rdu1.dts
index f9fdb7c..70fdcdd 100644
--- a/arch/arm/boot/dts/imx51-zii-rdu1.dts
+++ b/arch/arm/boot/dts/imx51-zii-rdu1.dts
@@ -428,13 +428,13 @@
#size-cells = <0>;
led-control = <0x0 0x0 0x3f83f8 0x0>;
- sysled0 {
+ sysled0 at 3 {
reg = <3>;
label = "system:green:status";
linux,default-trigger = "default-on";
};
- sysled1 {
+ sysled1 at 4 {
reg = <4>;
label = "system:green:act";
linux,default-trigger = "heartbeat";
--
2.7.4
^ permalink raw reply related
* [PATCH 01/12] ARM: dts: imx51-ts4800: Fix syscon and touschscreen nodes
From: Fabio Estevam @ 2017-12-01 19:24 UTC (permalink / raw)
To: linux-arm-kernel
From: Fabio Estevam <fabio.estevam@nxp.com>
The syscon node has an incorrect notation for its unit address and the
wdt node has an unneeded unit address.
Fix them so that the following build warnings with W=1 are gone:
arch/arm/boot/dts/imx51-ts4800.dtb: Warning (unit_address_vs_reg): Node /memory has a reg or ranges property, but no unit name
arch/arm/boot/dts/imx51-ts4800.dtb: Warning (unit_address_vs_reg): Node /soc/aips at 80000000/weim at 83fda000/fpga at 0/syscon at b0010000/wdt at e has a unit name, but no reg property
arch/arm/boot/dts/imx51-ts4800.dtb: Warning (unit_address_vs_reg): Node /soc/aips at 80000000/weim at 83fda000/fpga at 0/touchscreen has a reg or ranges property, but no unit name
arch/arm/boot/dts/imx51-ts4800.dtb: Warning (simple_bus_reg): Node /soc/aips at 80000000/weim at 83fda000/fpga at 0/syscon at b0010000 simple-bus unit address format error, expected "10000"
arch/arm/boot/dts/imx51-ts4800.dtb: Warning (simple_bus_reg): Node /soc/aips at 80000000/weim at 83fda000/fpga at 0/touchscreen simple-bus unit address format error, expected "12000"
Cc: Damien Riegel <damien.riegel@savoirfairelinux.com>
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
---
arch/arm/boot/dts/imx51-ts4800.dts | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/imx51-ts4800.dts b/arch/arm/boot/dts/imx51-ts4800.dts
index 564233e..f59b02b 100644
--- a/arch/arm/boot/dts/imx51-ts4800.dts
+++ b/arch/arm/boot/dts/imx51-ts4800.dts
@@ -149,18 +149,18 @@
#size-cells = <1>;
ranges = <0 0 0 0x1d000>;
- syscon: syscon at b0010000 {
+ syscon: syscon at 10000 {
compatible = "syscon", "simple-mfd";
reg = <0x10000 0x3d>;
reg-io-width = <2>;
- wdt at e {
+ wdt {
compatible = "technologic,ts4800-wdt";
syscon = <&syscon 0xe>;
};
};
- touchscreen {
+ touchscreen at 12000 {
compatible = "technologic,ts4800-ts";
reg = <0x12000 0x1000>;
syscon = <&syscon 0x10 6>;
--
2.7.4
^ permalink raw reply related
* [PATCH RT] arm*: disable NEON in kernel mode
From: Ard Biesheuvel @ 2017-12-01 19:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171201182410.GU22781@e103592.cambridge.arm.com>
On 1 December 2017 at 18:24, Dave Martin <Dave.Martin@arm.com> wrote:
> On Fri, Dec 01, 2017 at 06:08:28PM +0000, Russell King - ARM Linux wrote:
>> On Fri, Dec 01, 2017 at 05:58:45PM +0000, Dave Martin wrote:
>> > +1, at least for arm64. I don't see a really compelling reason for
>> > holding kernel-mode NEON around memory management now that we have a
>> > strict save-once-restore-lazily model.
>> >
>> > This may not work so well for arm though -- I haven't looked at that
>> > code for a while.
>> >
>> >
>> > If there is memory manamement in any core loop, you already lost
>> > the performance battle, and an extra
>> > kernel_neon_end()+kernel_neon_begin() may not be that catastrophic.
>>
>> Remember that we don't permit context switches while kernel neon is
>> in use on ARM - if there's any possibility of scheduling to occur,
>> the get_cpu() in kernel_neon_begin() should trigger a schedule-while-
>> atomic warning.
>
> Agreed, and an arm64 the same is true. (Actually softirq is disabled
> too, for tortuous reasons involving SVE.)
>
> On 2017-12-01 11:43:32 [+0100], To linux-rt-users at vger.kernel.org wrote:
>> NEON in kernel mode is used by the crypto algorithms and raid6 code.
>> While the raid6 code looks okay, the crypto algorithms do not: NEON
>> is enabled on first invocation and may allocate/free/map memory before
>> the NEON mode is disabled again.
>> This needs to be changed until it can be enabled.
>> On ARM NEON in kernel mode can be simply disabled. on ARM64 it needs to
>> stay on due to possible EFI callbacks so here I disable each algorithm.
>
> [...]
>
>> diff --git a/arch/arm64/crypto/Kconfig b/arch/arm64/crypto/Kconfig
>> index 70c517aa4501..2a5f05b5a19a 100644
>> --- a/arch/arm64/crypto/Kconfig
>> +++ b/arch/arm64/crypto/Kconfig
>> @@ -19,19 +19,19 @@ config CRYPTO_SHA512_ARM64
>>
>> config CRYPTO_SHA1_ARM64_CE
>> tristate "SHA-1 digest algorithm (ARMv8 Crypto Extensions)"
>> - depends on KERNEL_MODE_NEON
>> + depends on KERNEL_MODE_NEON && !PREEMPT_RT_BASE
>> select CRYPTO_HASH
>> select CRYPTO_SHA1
>
> Sebastian, can you piont to where sha1 (say) hits this issue?
> I wonder whether this is really a sign that some refactoring is needed.
>
I don't think the SHA code is affected. It is primarily the block
ciphers, where the scatterwalk API offers some guarantees to the API
client (the NEON crypto driver) that data is presented in suitable
blocks. This may involve copying data from the scatterlist to a temp
buffer if any of the chunks are not blocksize aligned.
^ permalink raw reply
* [alsa-devel] [PATCH v5 13/13] ASoC: stm32: add DFSDM DAI support
From: kbuild test robot @ 2017-12-01 19:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1511881557-28596-14-git-send-email-arnaud.pouliquen@st.com>
Hi Arnaud,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on iio/togreg]
[also build test WARNING on v4.15-rc1 next-20171201]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Arnaud-Pouliquen/Add-STM32-DFSDM-support/20171201-215409
base: https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git togreg
config: tile-allyesconfig (attached as .config)
compiler: tilegx-linux-gcc (GCC) 4.6.2
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=tile
All warnings (new ones prefixed by >>):
sound/soc/stm/stm32_adfsdm.c: In function 'stm32_afsdm_pcm_cb':
>> sound/soc/stm/stm32_adfsdm.c:173:2: warning: format '%d' expects argument of type 'int', but argument 7 has type 'size_t' [-Wformat]
vim +173 sound/soc/stm/stm32_adfsdm.c
161
162 static int stm32_afsdm_pcm_cb(const void *data, size_t size, void *private)
163 {
164 struct stm32_adfsdm_priv *priv = private;
165 struct snd_soc_pcm_runtime *rtd = priv->substream->private_data;
166 u8 *pcm_buff = priv->pcm_buff;
167 u8 *src_buff = (u8 *)data;
168 unsigned int buff_size = snd_pcm_lib_buffer_bytes(priv->substream);
169 unsigned int period_size = snd_pcm_lib_period_bytes(priv->substream);
170 unsigned int old_pos = priv->pos;
171 unsigned int cur_size = size;
172
> 173 dev_dbg(rtd->dev, "%s: buff_add :%p, pos = %d, size = %d\n",
174 __func__, &pcm_buff[priv->pos], priv->pos, size);
175
176 if ((priv->pos + size) > buff_size) {
177 memcpy(&pcm_buff[priv->pos], src_buff, buff_size - priv->pos);
178 cur_size -= buff_size - priv->pos;
179 priv->pos = 0;
180 }
181
182 memcpy(&pcm_buff[priv->pos], &src_buff[size - cur_size], cur_size);
183 priv->pos = (priv->pos + cur_size) % buff_size;
184
185 if (cur_size != size || (old_pos && (old_pos % period_size < size)))
186 snd_pcm_period_elapsed(priv->substream);
187
188 return 0;
189 }
190
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 50547 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171202/a7485b14/attachment-0001.gz>
^ permalink raw reply
* [PATCH 1/1] phy: Add 2.5G SGMII interface mode
From: Andrew Lunn @ 2017-12-01 19:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AM3PR04MB449A2C7FDF78431360961E48C390@AM3PR04MB449.eurprd04.prod.outlook.com>
> So do we need to introduce a new interface type
> PHY_INTERFACE_MODE_2500SGMII or is there a way to deal with 2.5G
> SGMII ?
And just adding to what Florian said, you don't just add a new define
like this, you also need to add a user of it. Posting your MAC and PHY
driver making use of this symbol will make it a lot clearer why it is
needed and how it should be used.
Andrew
^ permalink raw reply
* [PATCH 1/1] phy: Add 2.5G SGMII interface mode
From: Florian Fainelli @ 2017-12-01 18:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AM3PR04MB449A2C7FDF78431360961E48C390@AM3PR04MB449.eurprd04.prod.outlook.com>
On 12/01/2017 10:40 AM, Bhaskar Upadhaya wrote:
>
>> -----Original Message-----
>> From: Russell King - ARM Linux [mailto:linux at armlinux.org.uk]
>> Sent: Friday, December 01, 2017 12:23 AM
>> To: Andrew Lunn <andrew@lunn.ch>
>> Cc: Bhaskar Upadhaya <bhaskar.upadhaya@nxp.com>; netdev at vger.kernel.org;
>> davem at davemloft.net; linux-arm-kernel at lists.infradead.org
>> Subject: Re: [PATCH 1/1] phy: Add 2.5G SGMII interface mode
>>
>> On Thu, Nov 30, 2017 at 07:26:21PM +0100, Andrew Lunn wrote:
>>> On Thu, Nov 30, 2017 at 06:15:20PM +0000, Russell King - ARM Linux wrote:
>>>> On Thu, Nov 30, 2017 at 06:41:27PM +0100, Andrew Lunn wrote:
>>>>> SGMII supports passing auto-negotiation results from the PHY to
>>>>> the MAC. 1000BASE-X does not.
>>>>>
>>>>> SGMII supports the PHY running at 10, 100, and 1000 Mbps. But to
>>>>> support this, the MAC needs to replicate the bits 100, or 10 times
>>>>> when the PHY is running in 10 or 100Mbps mode.
>>>>>
>>>>> So with your 2.5G SGMII, you need to replicate the bits 250, 25,
>>>>> or
>>>>> 2.5 times if they PHY is running at lower speeds. This last one is
>>>>> interesting.
>>>>
>>>> That's not what I've read so far - but I don't know about the PHY in
>>>> this exact case because the docs are only available under NDA (which
>>>> makes it incredibly difficult to have this discussion.)
>>>>
>>>> However, from what I can ascertain from a Xilinx document, 2.5G is
>>>> 1G SGMII clocked 2.5x faster. When in 2.5G mode, the other modes
>>>> are unavailable.
>>>
>>> Hi Russell
>>>
>>> Thanks for looking into the details.
>>>
>>> So you need the PHY driver to see what it has negotiated, and when it
>>> calls the adjust_link callback, the MAC needs look at the
>>> phydev->interface and set the MAC to 2.5G SGMII or SGMII.
>>
>> Yes, it /looks/ that way from what I've read so far. I'd like to do a more
>> comprehensive look around at what various manufacturers are doing before
>> saying that definitively. Even better would be to find a specification for 2.5G
>> SGMII!
>>
>>> Same as the Marvell 10G PHY driver flips between
>>> PHY_INTERFACE_MODE_10GKR and PHY_INTERFACE_MODE_SGMII depending
>> on
>>> what it has negotiated.
>>
>> Having played extensively with the Marvell 88x3310 and thoroughly inspected its
>> registers and analysed its behaviour, I'd be hessitant to compare other PHYs with
>> it. The 3310 PHY seems to be multiple PHY blocks (from two vendors) in a single
>> package, and it dynamically switches in the appropriate hardware blocks
>> according to the negotiated link modes.
>>
>> However, given that 1G SGMII is clocked at a different rate from 2.5G SGMII,
>> both ends would need to be configured the same.
>>
>> For example, both mvneta and mvpp2.2 support 2.5G modes merely by
>> reconfiguring the comphy block, and all that does is increase the serdes clock.
>> That's used for 2500BASE-X (which I have had working locally through a devmem2
>> pokes on Clearfog and the older Marvell pp2x driver on Macchiatobin) but it's
>> more difficult to find 2.5G copper SFP modules to test with - which would
>> presumably talk 2.5G SGMII.
>
> So do we need to introduce a new interface type PHY_INTERFACE_MODE_2500SGMII or is there a way to deal with 2.5G SGMII ?
Well, because you are proposing this change, we were sort of hoping you
could explain the rationale, and point us to the 2.5 SGMII standard
document so we can understand what this is about....
--
Florian
^ permalink raw reply
* [PATCH 1/1] phy: Add 2.5G SGMII interface mode
From: Bhaskar Upadhaya @ 2017-12-01 18:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171130185300.GG10595@n2100.armlinux.org.uk>
>-----Original Message-----
>From: Russell King - ARM Linux [mailto:linux at armlinux.org.uk]
>Sent: Friday, December 01, 2017 12:23 AM
>To: Andrew Lunn <andrew@lunn.ch>
>Cc: Bhaskar Upadhaya <bhaskar.upadhaya@nxp.com>; netdev at vger.kernel.org;
>davem at davemloft.net; linux-arm-kernel at lists.infradead.org
>Subject: Re: [PATCH 1/1] phy: Add 2.5G SGMII interface mode
>
>On Thu, Nov 30, 2017 at 07:26:21PM +0100, Andrew Lunn wrote:
>> On Thu, Nov 30, 2017 at 06:15:20PM +0000, Russell King - ARM Linux wrote:
>> > On Thu, Nov 30, 2017 at 06:41:27PM +0100, Andrew Lunn wrote:
>> > > SGMII supports passing auto-negotiation results from the PHY to
>> > > the MAC. 1000BASE-X does not.
>> > >
>> > > SGMII supports the PHY running at 10, 100, and 1000 Mbps. But to
>> > > support this, the MAC needs to replicate the bits 100, or 10 times
>> > > when the PHY is running in 10 or 100Mbps mode.
>> > >
>> > > So with your 2.5G SGMII, you need to replicate the bits 250, 25,
>> > > or
>> > > 2.5 times if they PHY is running at lower speeds. This last one is
>> > > interesting.
>> >
>> > That's not what I've read so far - but I don't know about the PHY in
>> > this exact case because the docs are only available under NDA (which
>> > makes it incredibly difficult to have this discussion.)
>> >
>> > However, from what I can ascertain from a Xilinx document, 2.5G is
>> > 1G SGMII clocked 2.5x faster. When in 2.5G mode, the other modes
>> > are unavailable.
>>
>> Hi Russell
>>
>> Thanks for looking into the details.
>>
>> So you need the PHY driver to see what it has negotiated, and when it
>> calls the adjust_link callback, the MAC needs look at the
>> phydev->interface and set the MAC to 2.5G SGMII or SGMII.
>
>Yes, it /looks/ that way from what I've read so far. I'd like to do a more
>comprehensive look around at what various manufacturers are doing before
>saying that definitively. Even better would be to find a specification for 2.5G
>SGMII!
>
>> Same as the Marvell 10G PHY driver flips between
>> PHY_INTERFACE_MODE_10GKR and PHY_INTERFACE_MODE_SGMII depending
>on
>> what it has negotiated.
>
>Having played extensively with the Marvell 88x3310 and thoroughly inspected its
>registers and analysed its behaviour, I'd be hessitant to compare other PHYs with
>it. The 3310 PHY seems to be multiple PHY blocks (from two vendors) in a single
>package, and it dynamically switches in the appropriate hardware blocks
>according to the negotiated link modes.
>
>However, given that 1G SGMII is clocked at a different rate from 2.5G SGMII,
>both ends would need to be configured the same.
>
>For example, both mvneta and mvpp2.2 support 2.5G modes merely by
>reconfiguring the comphy block, and all that does is increase the serdes clock.
>That's used for 2500BASE-X (which I have had working locally through a devmem2
>pokes on Clearfog and the older Marvell pp2x driver on Macchiatobin) but it's
>more difficult to find 2.5G copper SFP modules to test with - which would
>presumably talk 2.5G SGMII.
So do we need to introduce a new interface type PHY_INTERFACE_MODE_2500SGMII or is there a way to deal with 2.5G SGMII ?
>
>--
>RMK's Patch system:
>https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ar
>mlinux.org.uk%2Fdeveloper%2Fpatches%2F&data=02%7C01%7Cbhaskar.upadha
>ya%40nxp.com%7C6ed1aa95e2844f1f316008d538239cf6%7C686ea1d3bc2b4c6f
>a92cd99c5c301635%7C0%7C0%7C636476647969399947&sdata=z35Urdlslv7Cdq
>hmj6JUd48QyXrwjzrldIoFP9TEA6E%3D&reserved=0
>FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
>According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH RT] arm*: disable NEON in kernel mode
From: Dave Martin @ 2017-12-01 18:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171201180828.GN10595@n2100.armlinux.org.uk>
On Fri, Dec 01, 2017 at 06:08:28PM +0000, Russell King - ARM Linux wrote:
> On Fri, Dec 01, 2017 at 05:58:45PM +0000, Dave Martin wrote:
> > +1, at least for arm64. I don't see a really compelling reason for
> > holding kernel-mode NEON around memory management now that we have a
> > strict save-once-restore-lazily model.
> >
> > This may not work so well for arm though -- I haven't looked at that
> > code for a while.
> >
> >
> > If there is memory manamement in any core loop, you already lost
> > the performance battle, and an extra
> > kernel_neon_end()+kernel_neon_begin() may not be that catastrophic.
>
> Remember that we don't permit context switches while kernel neon is
> in use on ARM - if there's any possibility of scheduling to occur,
> the get_cpu() in kernel_neon_begin() should trigger a schedule-while-
> atomic warning.
Agreed, and an arm64 the same is true. (Actually softirq is disabled
too, for tortuous reasons involving SVE.)
On 2017-12-01 11:43:32 [+0100], To linux-rt-users at vger.kernel.org wrote:
> NEON in kernel mode is used by the crypto algorithms and raid6 code.
> While the raid6 code looks okay, the crypto algorithms do not: NEON
> is enabled on first invocation and may allocate/free/map memory before
> the NEON mode is disabled again.
> This needs to be changed until it can be enabled.
> On ARM NEON in kernel mode can be simply disabled. on ARM64 it needs to
> stay on due to possible EFI callbacks so here I disable each algorithm.
[...]
> diff --git a/arch/arm64/crypto/Kconfig b/arch/arm64/crypto/Kconfig
> index 70c517aa4501..2a5f05b5a19a 100644
> --- a/arch/arm64/crypto/Kconfig
> +++ b/arch/arm64/crypto/Kconfig
> @@ -19,19 +19,19 @@ config CRYPTO_SHA512_ARM64
>
> config CRYPTO_SHA1_ARM64_CE
> tristate "SHA-1 digest algorithm (ARMv8 Crypto Extensions)"
> - depends on KERNEL_MODE_NEON
> + depends on KERNEL_MODE_NEON && !PREEMPT_RT_BASE
> select CRYPTO_HASH
> select CRYPTO_SHA1
Sebastian, can you piont to where sha1 (say) hits this issue?
I wonder whether this is really a sign that some refactoring is needed.
Cheers
---Dave
^ permalink raw reply
* [GIT PULL] arm64: fixes for -rc2
From: Will Deacon @ 2017-12-01 18:23 UTC (permalink / raw)
To: linux-arm-kernel
Hi Linus,
Please pull the following arm64 fixes for 4.15-rc2. The critical one here
is a fix for fpsimd register corruption across signals which was introduced
by the SVE support code (the register files overlap), but the others are
worth having as well.
Summary in the tag.
Cheers,
Will
--->8
The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git tags/arm64-fixes
for you to fetch changes up to 3a33c7605750fb6a87613044d16b1455e482414d:
arm64: context: Fix comments and remove pointless smp_wmb() (2017-12-01 13:05:08 +0000)
----------------------------------------------------------------
arm64 fixes:
- Fix FP register corruption when SVE is not available or in use
- Fix out-of-tree module build failure when CONFIG_ARM64_MODULE_PLTS=y
- Missing 'const' generating errors with LTO builds
- Remove unsupported events from Cortex-A73 PMU description
- Removal of stale and incorrect comments
----------------------------------------------------------------
Ard Biesheuvel (2):
arm64: module-plts: factor out PLT generation code for ftrace
arm64: ftrace: emit ftrace-mod.o contents through code
Dave Martin (1):
arm64: fpsimd: Fix failure to restore FPSIMD state after signals
Jinbum Park (1):
arm64: pgd: Mark pgd_cache as __ro_after_init
Mark Rutland (1):
arm64: mm: cleanup stale AIVIVT references
Will Deacon (1):
arm64: context: Fix comments and remove pointless smp_wmb()
Xu YiPing (1):
arm64: perf: remove unsupported events for Cortex-A73
Yury Norov (1):
arm64: cpu_ops: Add missing 'const' qualifiers
arch/arm64/Makefile | 3 ---
arch/arm64/include/asm/cacheflush.h | 2 +-
arch/arm64/include/asm/module.h | 46 +++++++++++++++++++++++++++++++++-
arch/arm64/kernel/Makefile | 3 ---
arch/arm64/kernel/cpu_ops.c | 6 ++---
arch/arm64/kernel/fpsimd.c | 6 ++---
arch/arm64/kernel/ftrace-mod.S | 18 -------------
arch/arm64/kernel/ftrace.c | 14 ++++++-----
arch/arm64/kernel/module-plts.c | 50 +++++++++++--------------------------
arch/arm64/kernel/module.lds | 1 +
arch/arm64/kernel/perf_event.c | 6 -----
arch/arm64/mm/context.c | 28 ++++++++++++---------
arch/arm64/mm/pgd.c | 2 +-
13 files changed, 92 insertions(+), 93 deletions(-)
delete mode 100644 arch/arm64/kernel/ftrace-mod.S
^ permalink raw reply
* [PATCH v2 00/18] arm64: Unmap the kernel whilst running in userspace (KAISER)
From: Will Deacon @ 2017-12-01 18:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f86ac529-d763-9f90-1ced-b8a28f545582@linux.intel.com>
On Fri, Dec 01, 2017 at 10:02:43AM -0800, Dave Hansen wrote:
> On 12/01/2017 09:58 AM, Mark Rutland wrote:
> > On Fri, Dec 01, 2017 at 05:50:26PM +0000, Will Deacon wrote:
> >> On Fri, Dec 01, 2017 at 02:04:06PM +0000, Mark Rutland wrote:
> >>> On Thu, Nov 30, 2017 at 04:39:28PM +0000, Will Deacon wrote:
> >> Thanks for going through this. Do you have any ideas about what we could
> >> rename the command-line option to? I'll get us started:
> >>
> >> - kaiser=
> >> - hidekernel=
> >> - unmapkernel=
> >> - hardenkaslr=
> >> - swuan=
> > Off all of these, I think "unmapkernel" is the clear winner, since it
> > says what it does in the tin (even if it misses the when).
> >
> > I'll have a think over the weekend.
>
> On the x86 side we've been leaning toward renaming kaiser to something
> like "user pagetable isolation", so the boot parameter is something like
> "noupti".
>
> But I think the consensus is definitely to get rid of "kaiser".
Ok, good. I'm happy to follow your lead on the name if it's likely to be
resolved in the next week or so.
Will
^ permalink raw reply
* [PATCH 13/37] KVM: arm64: Introduce VHE-specific kvm_vcpu_run
From: Christoffer Dall @ 2017-12-01 18:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171107152529.taszxq37f35yw3ga@kamzik.brq.redhat.com>
On Tue, Nov 07, 2017 at 04:25:29PM +0100, Andrew Jones wrote:
> On Thu, Oct 12, 2017 at 12:41:17PM +0200, Christoffer Dall wrote:
> > So far this is just a copy of the legacy non-VHE switch function, where
> > we only change the existing calls to has_vhe() in both the original and
> > new functions.
> >
> > Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> > ---
> > arch/arm/include/asm/kvm_asm.h | 4 +++
> > arch/arm64/include/asm/kvm_asm.h | 2 ++
> > arch/arm64/kvm/hyp/switch.c | 57 ++++++++++++++++++++++++++++++++++++++++
> > virt/kvm/arm/arm.c | 5 +++-
> > 4 files changed, 67 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/include/asm/kvm_asm.h b/arch/arm/include/asm/kvm_asm.h
> > index 36dd296..1a7bc5f 100644
> > --- a/arch/arm/include/asm/kvm_asm.h
> > +++ b/arch/arm/include/asm/kvm_asm.h
> > @@ -70,8 +70,12 @@ extern void __kvm_tlb_flush_local_vmid(struct kvm_vcpu *vcpu);
> >
> > extern void __kvm_timer_set_cntvoff(u32 cntvoff_low, u32 cntvoff_high);
> >
> > +/* no VHE on 32-bit :( */
> > +static inline int kvm_vcpu_run(struct kvm_vcpu *vcpu) { return 0; }
> > +
> > extern int __kvm_vcpu_run(struct kvm_vcpu *vcpu);
> >
> > +
>
> stray new blank line
>
> > extern void __init_stage2_translation(void);
> >
> > extern u64 __vgic_v3_get_ich_vtr_el2(void);
> > diff --git a/arch/arm64/include/asm/kvm_asm.h b/arch/arm64/include/asm/kvm_asm.h
> > index 7e48a39..2eb5b23 100644
> > --- a/arch/arm64/include/asm/kvm_asm.h
> > +++ b/arch/arm64/include/asm/kvm_asm.h
> > @@ -57,6 +57,8 @@ extern void __kvm_tlb_flush_local_vmid(struct kvm_vcpu *vcpu);
> >
> > extern void __kvm_timer_set_cntvoff(u32 cntvoff_low, u32 cntvoff_high);
> >
> > +extern int kvm_vcpu_run(struct kvm_vcpu *vcpu);
> > +
> > extern int __kvm_vcpu_run(struct kvm_vcpu *vcpu);
> >
> > extern u64 __vgic_v3_get_ich_vtr_el2(void);
> > diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
> > index ed30af5..8a0f38f 100644
> > --- a/arch/arm64/kvm/hyp/switch.c
> > +++ b/arch/arm64/kvm/hyp/switch.c
> > @@ -319,6 +319,63 @@ static bool __hyp_text fixup_guest_exit(struct kvm_vcpu *vcpu, u64 *exit_code)
> > return false;
> > }
> >
> > +/* Switch to the guest for VHE systems running in EL2 */
> > +int kvm_vcpu_run(struct kvm_vcpu *vcpu)
> > +{
> > + struct kvm_cpu_context *host_ctxt;
> > + struct kvm_cpu_context *guest_ctxt;
> > + u64 exit_code;
> > +
> > + vcpu = kern_hyp_va(vcpu);
> > +
> > + host_ctxt = kern_hyp_va(vcpu->arch.host_cpu_context);
> > + host_ctxt->__hyp_running_vcpu = vcpu;
> > + guest_ctxt = &vcpu->arch.ctxt;
> > +
> > + __sysreg_save_host_state(host_ctxt);
> > +
> > + __activate_traps(vcpu);
> > + __activate_vm(vcpu);
> > +
> > + __vgic_restore_state(vcpu);
> > + __timer_enable_traps(vcpu);
> > +
> > + /*
> > + * We must restore the 32-bit state before the sysregs, thanks
> > + * to erratum #852523 (Cortex-A57) or #853709 (Cortex-A72).
> > + */
> > + __sysreg32_restore_state(vcpu);
> > + __sysreg_restore_guest_state(guest_ctxt);
> > + __debug_switch_to_guest(vcpu);
> > +
> > + /* Jump in the fire! */
> > +again:
> > + exit_code = __guest_enter(vcpu, host_ctxt);
> > + /* And we're baaack! */
> > +
> > + if (fixup_guest_exit(vcpu, &exit_code))
> > + goto again;
> > +
> > + __sysreg_save_guest_state(guest_ctxt);
> > + __sysreg32_save_state(vcpu);
> > + __timer_disable_traps(vcpu);
> > + __vgic_save_state(vcpu);
> > +
> > + __deactivate_traps(vcpu);
> > + __deactivate_vm(vcpu);
> > +
> > + __sysreg_restore_host_state(host_ctxt);
> > +
> > + /*
> > + * This must come after restoring the host sysregs, since a non-VHE
> > + * system may enable SPE here and make use of the TTBRs.
> > + */
> > + __debug_switch_to_host(vcpu);
> > +
> > + return exit_code;
> > +}
> > +
> > +/* Switch to the guest for legacy non-VHE systems */
> > int __hyp_text __kvm_vcpu_run(struct kvm_vcpu *vcpu)
> > {
> > struct kvm_cpu_context *host_ctxt;
> > diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
> > index cf121b2..b11647a 100644
> > --- a/virt/kvm/arm/arm.c
> > +++ b/virt/kvm/arm/arm.c
> > @@ -706,7 +706,10 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run *run)
> > trace_kvm_entry(*vcpu_pc(vcpu));
> > guest_enter_irqoff();
> >
> > - ret = kvm_call_hyp(__kvm_vcpu_run, vcpu);
> > + if (has_vhe())
> > + ret = kvm_vcpu_run(vcpu);
> > + else
> > + ret = kvm_call_hyp(__kvm_vcpu_run, vcpu);
>
> So kvm_vcpu_run() is going to be VHE only, but the only way for people
> stepping through the code to know that is by seeing this callsite or by
> reading the comment above it. Everywhere else we make it much more clear
> with the _vhe and _nvhe suffixes. I wonder if we should keep that pattern
> by adding
>
> static int kvm_vcpu_run(struct kvm_vcpu *vcpu)
> {
> if (has_vhe())
> ret = kvm_vcpu_run_vhe(vcpu);
> else
> ret = kvm_call_hyp(__kvm_vcpu_run_nvhe, vcpu);
> }
>
> to virt/kvm/arm/arm.c and then calling that from here.
>
> I'm afraid the __ prefix is too ambiguous in the kernel to interpret
> __foo() as the hyp mode non-VHE version of foo(), the hyp mode VHE
> version.
>
Sure.
Thanks,
-Christoffer
^ permalink raw reply
* [PATCH RT] arm*: disable NEON in kernel mode
From: Russell King - ARM Linux @ 2017-12-01 18:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171201175844.GT22781@e103592.cambridge.arm.com>
On Fri, Dec 01, 2017 at 05:58:45PM +0000, Dave Martin wrote:
> +1, at least for arm64. I don't see a really compelling reason for
> holding kernel-mode NEON around memory management now that we have a
> strict save-once-restore-lazily model.
>
> This may not work so well for arm though -- I haven't looked at that
> code for a while.
>
>
> If there is memory manamement in any core loop, you already lost
> the performance battle, and an extra
> kernel_neon_end()+kernel_neon_begin() may not be that catastrophic.
Remember that we don't permit context switches while kernel neon is
in use on ARM - if there's any possibility of scheduling to occur,
the get_cpu() in kernel_neon_begin() should trigger a schedule-while-
atomic warning.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH v5 3/8] KVM: arm/arm64: Don't cache the timer IRQ level
From: Andre Przywara @ 2017-12-01 18:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171120191649.17290-4-christoffer.dall@linaro.org>
Hi,
On 20/11/17 19:16, Christoffer Dall wrote:
> The timer was modeled after a strict idea of modelling an interrupt line
> level in software, meaning that only transitions in the level needed to
> be reported to the VGIC. This works well for the timer, because the
> arch timer code is in complete control of the device and can track the
> transitions of the line.
>
> However, as we are about to support using the HW bit in the VGIC not
> just for the timer, but also for VFIO which cannot track transitions of
> the interrupt line, we have to decide on an interface for level
> triggered mapped interrupts to the GIC, which both the timer and VFIO
> can use.
>
> VFIO only sees an asserting transition of the physical interrupt line,
> and tells the VGIC when that happens. That means that part of the
> interrupt flow is offloaded to the hardware.
>
> To use the same interface for VFIO devices and the timer, we therefore
> have to change the timer (we cannot change VFIO because it doesn't know
> the details of the device it is assigning to a VM).
>
> Luckily, changing the timer is simple, we just need to stop 'caching'
> the line level, but instead let the VGIC know the state of the timer
> every time there is a potential change in the line level, and when the
> line level should be asserted from the timer ISR. The VGIC can ignore
> extra notifications using its validate mechanism.
Indeed vgic_validate_injection() should take care of that change.
> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Cheers,
Andre.
> ---
> virt/kvm/arm/arch_timer.c | 20 +++++++++++++-------
> 1 file changed, 13 insertions(+), 7 deletions(-)
>
> diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
> index 190c99ed1b73..5f8ad8e3f3ff 100644
> --- a/virt/kvm/arm/arch_timer.c
> +++ b/virt/kvm/arm/arch_timer.c
> @@ -99,11 +99,9 @@ static irqreturn_t kvm_arch_timer_handler(int irq, void *dev_id)
> }
> vtimer = vcpu_vtimer(vcpu);
>
> - if (!vtimer->irq.level) {
> - vtimer->cnt_ctl = read_sysreg_el0(cntv_ctl);
> - if (kvm_timer_irq_can_fire(vtimer))
> - kvm_timer_update_irq(vcpu, true, vtimer);
> - }
> + vtimer->cnt_ctl = read_sysreg_el0(cntv_ctl);
> + if (kvm_timer_irq_can_fire(vtimer))
> + kvm_timer_update_irq(vcpu, true, vtimer);
>
> if (unlikely(!irqchip_in_kernel(vcpu->kvm)))
> kvm_vtimer_update_mask_user(vcpu);
> @@ -324,12 +322,20 @@ static void kvm_timer_update_state(struct kvm_vcpu *vcpu)
> struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
> struct arch_timer_context *vtimer = vcpu_vtimer(vcpu);
> struct arch_timer_context *ptimer = vcpu_ptimer(vcpu);
> + bool level;
>
> if (unlikely(!timer->enabled))
> return;
>
> - if (kvm_timer_should_fire(vtimer) != vtimer->irq.level)
> - kvm_timer_update_irq(vcpu, !vtimer->irq.level, vtimer);
> + /*
> + * The vtimer virtual interrupt is a 'mapped' interrupt, meaning part
> + * of its lifecycle is offloaded to the hardware, and we therefore may
> + * not have lowered the irq.level value before having to signal a new
> + * interrupt, but have to signal an interrupt every time the level is
> + * asserted.
> + */
> + level = kvm_timer_should_fire(vtimer);
> + kvm_timer_update_irq(vcpu, level, vtimer);
>
> if (kvm_timer_should_fire(ptimer) != ptimer->irq.level)
> kvm_timer_update_irq(vcpu, !ptimer->irq.level, ptimer);
>
^ permalink raw reply
* [PATCH v5 2/8] KVM: arm/arm64: Factor out functionality to get vgic mmio requester_vcpu
From: Andre Przywara @ 2017-12-01 18:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171120191649.17290-3-christoffer.dall@linaro.org>
Hi,
On 20/11/17 19:16, Christoffer Dall wrote:
> We are about to distinguish between userspace accesses and mmio traps
> for a number of the mmio handlers. When the requester vcpu is NULL, it
> mens we are handling a userspace acccess.
>
> Factor out the functionality to get the request vcpu into its own
> function, mostly so we have a common place to document the semantics of
> the return value.
>
> Also take the chance to move the functionality outside of holding a
> spinlock and instead explicitly disable and enable preemption. This
> supports PREEMPT_RT kernels as well.
>
> Acked-by: Marc Zyngier <marc.zyngier@arm.com>
> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> ---
> virt/kvm/arm/vgic/vgic-mmio.c | 43 +++++++++++++++++++++++++++----------------
> 1 file changed, 27 insertions(+), 16 deletions(-)
>
> diff --git a/virt/kvm/arm/vgic/vgic-mmio.c b/virt/kvm/arm/vgic/vgic-mmio.c
> index deb51ee16a3d..6113cf850f47 100644
> --- a/virt/kvm/arm/vgic/vgic-mmio.c
> +++ b/virt/kvm/arm/vgic/vgic-mmio.c
> @@ -122,6 +122,26 @@ unsigned long vgic_mmio_read_pending(struct kvm_vcpu *vcpu,
> return value;
> }
>
> +/*
> + * This function will return the VCPU that performed the MMIO access and
> + * trapped from twithin the VM, and will return NULL if this is a userspace
> + * access.
> + *
> + * We can disable preemption locally around accessing the per-CPU variable
> + * because even if the current thread is migrated to another CPU, reading the
> + * per-CPU value later will give us the same value as we update the per-CPU
> + * variable in the preempt notifier handlers.
This comment left me scratching my head a bit. Maybe you could change it
to point out that ... it's safe to *enable* preemption after the call
again, because of said reasons? Because disabling preemption before
accessing a per-CPU variable is not really an issue.
Apart from that it's fine.
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Cheers,
Andre.
> + */
> +static struct kvm_vcpu *vgic_get_mmio_requester_vcpu(void)
> +{
> + struct kvm_vcpu *vcpu;
> +
> + preempt_disable();
> + vcpu = kvm_arm_get_running_vcpu();
> + preempt_enable();
> + return vcpu;
> +}
> +
> void vgic_mmio_write_spending(struct kvm_vcpu *vcpu,
> gpa_t addr, unsigned int len,
> unsigned long val)
> @@ -184,24 +204,10 @@ unsigned long vgic_mmio_read_active(struct kvm_vcpu *vcpu,
> static void vgic_mmio_change_active(struct kvm_vcpu *vcpu, struct vgic_irq *irq,
> bool new_active_state)
> {
> - struct kvm_vcpu *requester_vcpu;
> unsigned long flags;
> - spin_lock_irqsave(&irq->irq_lock, flags);
> + struct kvm_vcpu *requester_vcpu = vgic_get_mmio_requester_vcpu();
>
> - /*
> - * The vcpu parameter here can mean multiple things depending on how
> - * this function is called; when handling a trap from the kernel it
> - * depends on the GIC version, and these functions are also called as
> - * part of save/restore from userspace.
> - *
> - * Therefore, we have to figure out the requester in a reliable way.
> - *
> - * When accessing VGIC state from user space, the requester_vcpu is
> - * NULL, which is fine, because we guarantee that no VCPUs are running
> - * when accessing VGIC state from user space so irq->vcpu->cpu is
> - * always -1.
> - */
> - requester_vcpu = kvm_arm_get_running_vcpu();
> + spin_lock_irqsave(&irq->irq_lock, flags);
>
> /*
> * If this virtual IRQ was written into a list register, we
> @@ -213,6 +219,11 @@ static void vgic_mmio_change_active(struct kvm_vcpu *vcpu, struct vgic_irq *irq,
> * vgic_change_active_prepare) and still has to sync back this IRQ,
> * so we release and re-acquire the spin_lock to let the other thread
> * sync back the IRQ.
> + *
> + * When accessing VGIC state from user space, requester_vcpu is
> + * NULL, which is fine, because we guarantee that no VCPUs are running
> + * when accessing VGIC state from user space so irq->vcpu->cpu is
> + * always -1.
> */
> while (irq->vcpu && /* IRQ may have state in an LR somewhere */
> irq->vcpu != requester_vcpu && /* Current thread is not the VCPU thread */
>
^ permalink raw reply
* [PATCH v5 1/8] KVM: arm/arm64: Remove redundant preemptible checks
From: Andre Przywara @ 2017-12-01 18:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171120191649.17290-2-christoffer.dall@linaro.org>
Hi,
On 20/11/17 19:16, Christoffer Dall wrote:
> The __this_cpu_read() and __this_cpu_write() functions already implement
> checks for the required preemption levels when using
> CONFIG_DEBUG_PREEMPT which gives you nice error messages and such.
> Therefore there is no need to explicitly check this using a BUG_ON() in
> the code (which we don't do for other uses of per cpu variables either).
>
> Acked-by: Marc Zyngier <marc.zyngier@arm.com>
> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
> ---
> virt/kvm/arm/arm.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
> index c13d74c083fe..28548aeaf164 100644
> --- a/virt/kvm/arm/arm.c
> +++ b/virt/kvm/arm/arm.c
> @@ -71,7 +71,6 @@ static DEFINE_PER_CPU(unsigned char, kvm_arm_hardware_enabled);
>
> static void kvm_arm_set_running_vcpu(struct kvm_vcpu *vcpu)
> {
> - BUG_ON(preemptible());
> __this_cpu_write(kvm_arm_running_vcpu, vcpu);
> }
>
> @@ -81,7 +80,6 @@ static void kvm_arm_set_running_vcpu(struct kvm_vcpu *vcpu)
> */
> struct kvm_vcpu *kvm_arm_get_running_vcpu(void)
> {
> - BUG_ON(preemptible());
> return __this_cpu_read(kvm_arm_running_vcpu);
> }
>
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox