[PATCH 00/15] Initial MSM8953 & Fairphone 3 support

[PATCH 00/15] Initial MSM8953 & Fairphone 3 support

[Luca Weiss]

This series adds initial support for MSM8953 (and SDM632 which is based
on MSM8953) and the Fairphone 3 smartphone.

Only relatively basic functionality is supported like storage, volume
keys and USB.

There is currently close-to-mainline support for other components for
this SoC including GPU, WiFi and audio, this series adds only basic
support so that the other components can start getting upstreamed
easier.

Luca Weiss (10):
  dt-bindings: phy: qcom,qusb2: Document msm8953 compatible
  phy: qcom-qusb2: Add compatible for MSM8953
  dt-bindings: mfd: qcom,tcsr: Document msm8953 compatible
  mfd: qcom-spmi-pmic: Add pm8953 compatible
  dt-bindings: mmc: sdhci-msm: Add msm8953 compatible
  dt-bindings: thermal: tsens: Add msm8953 compatible
  dt-bindings: usb: qcom,dwc3: Add msm8953 compatible
  dt-bindings: pinctrl: qcom: msm8953: allow gpio-reserved-ranges
  dt-bindings: arm: qcom: Document sdm632 and fairphone,fp3 board
  arm64: dts: qcom: sdm632: Add device tree for Fairphone 3

Vladimir Lypak (5):
  rpmsg: smd: Drop unnecessary condition for channel creation
  arm64: dts: qcom: Add MSM8953 device tree
  arm64: dts: qcom: Add PM8953 PMIC
  arm64: dts: qcom: Add SDM632 device tree
  arm64: dts: qcom: Add MSM8953+PM8953 device tree

 .../devicetree/bindings/arm/qcom.yaml         |    6 +
 .../bindings/mfd/qcom,spmi-pmic.txt           |    1 +
 .../devicetree/bindings/mfd/qcom,tcsr.txt     |    1 +
 .../devicetree/bindings/mmc/sdhci-msm.txt     |    1 +
 .../bindings/phy/qcom,qusb2-phy.yaml          |    1 +
 .../pinctrl/qcom,msm8953-pinctrl.yaml         |    2 +
 .../bindings/thermal/qcom-tsens.yaml          |    1 +
 .../devicetree/bindings/usb/qcom,dwc3.yaml    |    1 +
 arch/arm64/boot/dts/qcom/Makefile             |    1 +
 arch/arm64/boot/dts/qcom/msm8953-pm8953.dtsi  |   50 +
 arch/arm64/boot/dts/qcom/msm8953.dtsi         | 1337 +++++++++++++++++
 arch/arm64/boot/dts/qcom/pm8953.dtsi          |   90 ++
 .../boot/dts/qcom/sdm632-fairphone-fp3.dts    |  189 +++
 arch/arm64/boot/dts/qcom/sdm632.dtsi          |  125 ++
 drivers/phy/qualcomm/phy-qcom-qusb2.c         |    3 +
 drivers/rpmsg/qcom_smd.c                      |    8 +-
 16 files changed, 1810 insertions(+), 7 deletions(-)
 create mode 100644 arch/arm64/boot/dts/qcom/msm8953-pm8953.dtsi
 create mode 100644 arch/arm64/boot/dts/qcom/msm8953.dtsi
 create mode 100644 arch/arm64/boot/dts/qcom/pm8953.dtsi
 create mode 100644 arch/arm64/boot/dts/qcom/sdm632-fairphone-fp3.dts
 create mode 100644 arch/arm64/boot/dts/qcom/sdm632.dtsi

-- 
2.34.1

[PATCH 01/15] dt-bindings: phy: qcom,qusb2: Document msm8953 compatible

[Luca Weiss]

Document the compatible string used for the qusb2 phy in msm8953.

Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
Acked-by: Konrad Dybcio <konrad.dybcio@somainline.org>
---
 Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml
index aa2e409a1a09..f28eb4902038 100644
--- a/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml
@@ -19,6 +19,7 @@ properties:
       - items:
           - enum:
               - qcom,ipq8074-qusb2-phy
+              - qcom,msm8953-qusb2-phy
               - qcom,msm8996-qusb2-phy
               - qcom,msm8998-qusb2-phy
               - qcom,qcm2290-qusb2-phy
-- 
2.34.1

[PATCH 02/15] phy: qcom-qusb2: Add compatible for MSM8953

[Luca Weiss]

Add compatible for MSM8953 QUSB2 device which reuses MSM8996
configuration.

Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
Acked-by: Konrad Dybcio <konrad.dybcio@somainline.org>
---
 drivers/phy/qualcomm/phy-qcom-qusb2.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/phy/qualcomm/phy-qcom-qusb2.c b/drivers/phy/qualcomm/phy-qcom-qusb2.c
index 032d02bf50c5..7529a7e6e5df 100644
--- a/drivers/phy/qualcomm/phy-qcom-qusb2.c
+++ b/drivers/phy/qualcomm/phy-qcom-qusb2.c
@@ -911,6 +911,9 @@ static const struct of_device_id qusb2_phy_of_match_table[] = {
 	}, {
 		.compatible	= "qcom,ipq8074-qusb2-phy",
 		.data		= &msm8996_phy_cfg,
+	}, {
+		.compatible	= "qcom,msm8953-qusb2-phy",
+		.data		= &msm8996_phy_cfg,
 	}, {
 		.compatible	= "qcom,msm8996-qusb2-phy",
 		.data		= &msm8996_phy_cfg,
-- 
2.34.1

[PATCH 03/15] dt-bindings: mfd: qcom,tcsr: Document msm8953 compatible

[Luca Weiss]

Document the compatible for tcsr found in msm8953.

Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
Acked-by: Konrad Dybcio <konrad.dybcio@somainline.org>
---
 Documentation/devicetree/bindings/mfd/qcom,tcsr.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/mfd/qcom,tcsr.txt b/Documentation/devicetree/bindings/mfd/qcom,tcsr.txt
index c5f4f0ddfcc3..add61bcc3c74 100644
--- a/Documentation/devicetree/bindings/mfd/qcom,tcsr.txt
+++ b/Documentation/devicetree/bindings/mfd/qcom,tcsr.txt
@@ -10,6 +10,7 @@ Required properties:
 		"qcom,tcsr-ipq8064", "syscon" for IPQ8064
 		"qcom,tcsr-apq8064", "syscon" for APQ8064
 		"qcom,tcsr-msm8660", "syscon" for MSM8660
+		"qcom,tcsr-msm8953", "syscon" for MSM8953
 		"qcom,tcsr-msm8960", "syscon" for MSM8960
 		"qcom,tcsr-msm8974", "syscon" for MSM8974
 		"qcom,tcsr-apq8084", "syscon" for APQ8084
-- 
2.34.1

[PATCH 04/15] mfd: qcom-spmi-pmic: Add pm8953 compatible

[Luca Weiss]

Document the compatible for pm8953 as found in msm8953.

Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
Acked-by: Konrad Dybcio <konrad.dybcio@somainline.org>
---
 Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt
index 7a27c500ff63..a461ec2f758f 100644
--- a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt
+++ b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt
@@ -35,6 +35,7 @@ Required properties:
                    "qcom,pm8916",
                    "qcom,pm8941",
                    "qcom,pm8950",
+                   "qcom,pm8953",
                    "qcom,pm8994",
                    "qcom,pm8998",
                    "qcom,pma8084",
-- 
2.34.1

[PATCH 05/15] dt-bindings: mmc: sdhci-msm: Add msm8953 compatible

[Luca Weiss]

Add msm8953 SoC specific compatible strings for qcom-sdhci controller.

Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
Acked-by: Konrad Dybcio <konrad.dybcio@somainline.org>
---
 Documentation/devicetree/bindings/mmc/sdhci-msm.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
index 50841e2843fc..a62eaade5d97 100644
--- a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
+++ b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
@@ -14,6 +14,7 @@ Required properties:
 	full compatible strings with SoC and version:
 		"qcom,apq8084-sdhci", "qcom,sdhci-msm-v4"
 		"qcom,msm8226-sdhci", "qcom,sdhci-msm-v4"
+		"qcom,msm8953-sdhci", "qcom,sdhci-msm-v4"
 		"qcom,msm8974-sdhci", "qcom,sdhci-msm-v4"
 		"qcom,msm8916-sdhci", "qcom,sdhci-msm-v4"
 		"qcom,msm8992-sdhci", "qcom,sdhci-msm-v4"
-- 
2.34.1

[PATCH 06/15] dt-bindings: thermal: tsens: Add msm8953 compatible

[Luca Weiss]

Document the compatible string for tsens found in msm8953.

Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
Acked-by: Konrad Dybcio <konrad.dybcio@somainline.org>
---
 Documentation/devicetree/bindings/thermal/qcom-tsens.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml
index d3b9e9b600a2..b6406bcc683f 100644
--- a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml
+++ b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml
@@ -43,6 +43,7 @@ properties:
       - description: v2 of TSENS
         items:
           - enum:
+              - qcom,msm8953-tsens
               - qcom,msm8996-tsens
               - qcom,msm8998-tsens
               - qcom,sc7180-tsens
-- 
2.34.1

[PATCH 07/15] dt-bindings: usb: qcom,dwc3: Add msm8953 compatible

[Luca Weiss]

Document the compatible string for the DWC3 controller in msm8953.

Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
Acked-by: Konrad Dybcio <konrad.dybcio@somainline.org>
---
 Documentation/devicetree/bindings/usb/qcom,dwc3.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
index 2bdaba023c01..d6a71711a182 100644
--- a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
+++ b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
@@ -14,6 +14,7 @@ properties:
     items:
       - enum:
           - qcom,ipq6018-dwc3
+          - qcom,msm8953-dwc3
           - qcom,msm8996-dwc3
           - qcom,msm8998-dwc3
           - qcom,sc7180-dwc3
-- 
2.34.1

[PATCH 08/15] dt-bindings: pinctrl: qcom: msm8953: allow gpio-reserved-ranges

[Luca Weiss]

Allow the gpio-reserved-ranges property to be used in dts.

Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
Acked-by: Konrad Dybcio <konrad.dybcio@somainline.org>
---
 .../devicetree/bindings/pinctrl/qcom,msm8953-pinctrl.yaml       | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8953-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,msm8953-pinctrl.yaml
index abe9f4c9b1e3..11a215bba64b 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,msm8953-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8953-pinctrl.yaml
@@ -34,6 +34,8 @@ properties:
 
   gpio-controller: true
 
+  gpio-reserved-ranges: true
+
   '#gpio-cells':
     description: Specifying the pin number and flags, as defined in
       include/dt-bindings/gpio/gpio.h
-- 
2.34.1

[PATCH 09/15] rpmsg: smd: Drop unnecessary condition for channel creation

[Luca Weiss]

From: Vladimir Lypak <vladimir.lypak@gmail.com>

RPM Firmware on variety of newer SoCs such as MSM8917 (also likely
MSM8937, MSM8940, MSM8952), MSM8953 and on some MSM8916 devices) doesn't
initiate opening of the SMD channel if it was previously opened by
bootloader. This doesn't allow probing of smd-rpm driver on such devices
because there is a check that requires RPM this behaviour.

Signed-off-by: Vladimir Lypak <vladimir.lypak@gmail.com>
Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org>
---
 drivers/rpmsg/qcom_smd.c | 8 +-------
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/drivers/rpmsg/qcom_smd.c b/drivers/rpmsg/qcom_smd.c
index 8da1b5cb31b3..6a01ef932b01 100644
--- a/drivers/rpmsg/qcom_smd.c
+++ b/drivers/rpmsg/qcom_smd.c
@@ -1280,19 +1280,13 @@ static void qcom_channel_state_worker(struct work_struct *work)
 	unsigned long flags;
 
 	/*
-	 * Register a device for any closed channel where the remote processor
-	 * is showing interest in opening the channel.
+	 * Register a device for any closed channel.
 	 */
 	spin_lock_irqsave(&edge->channels_lock, flags);
 	list_for_each_entry(channel, &edge->channels, list) {
 		if (channel->state != SMD_CHANNEL_CLOSED)
 			continue;
 
-		remote_state = GET_RX_CHANNEL_INFO(channel, state);
-		if (remote_state != SMD_CHANNEL_OPENING &&
-		    remote_state != SMD_CHANNEL_OPENED)
-			continue;
-
 		if (channel->registered)
 			continue;
 
-- 
2.34.1

[PATCH 10/15] arm64: dts: qcom: Add MSM8953 device tree

[Luca Weiss]

From: Vladimir Lypak <vladimir.lypak@gmail.com>

Add a base DT for MSM8953 SoC.

Co-developed-by: Luca Weiss <luca@z3ntu.xyz>
Signed-off-by: Vladimir Lypak <vladimir.lypak@gmail.com>
Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
---
 arch/arm64/boot/dts/qcom/msm8953.dtsi | 1337 +++++++++++++++++++++++++
 1 file changed, 1337 insertions(+)
 create mode 100644 arch/arm64/boot/dts/qcom/msm8953.dtsi

diff --git a/arch/arm64/boot/dts/qcom/msm8953.dtsi b/arch/arm64/boot/dts/qcom/msm8953.dtsi
new file mode 100644
index 000000000000..59918b527750
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/msm8953.dtsi
@@ -0,0 +1,1337 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/* Copyright (c) 2022, The Linux Foundation. All rights reserved. */
+
+#include <dt-bindings/clock/qcom,gcc-msm8953.h>
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/power/qcom-rpmpd.h>
+#include <dt-bindings/thermal/thermal.h>
+
+/ {
+	interrupt-parent = <&intc>;
+
+	#address-cells = <2>;
+	#size-cells = <2>;
+
+	aliases {
+		i2c1 = &i2c_1;
+		i2c2 = &i2c_2;
+		i2c3 = &i2c_3;
+		i2c4 = &i2c_4;
+		i2c5 = &i2c_5;
+		i2c6 = &i2c_6;
+		i2c7 = &i2c_7;
+		i2c8 = &i2c_8;
+	};
+
+	chosen { };
+
+	clocks {
+		sleep_clk: sleep-clk {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-frequency = <32768>;
+		};
+
+		xo_board: xo-board {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-frequency = <19200000>;
+			clock-output-names = "xo";
+		};
+	};
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		CPU0: cpu@0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a53";
+			reg = <0x0>;
+			enable-method = "psci";
+			capacity-dmips-mhz = <1024>;
+			next-level-cache = <&L2_0>;
+			#cooling-cells = <2>;
+
+			l1-icache {
+				compatible = "cache";
+			};
+			l1-dcache {
+				compatible = "cache";
+			};
+		};
+
+		CPU1: cpu@1 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a53";
+			reg = <0x1>;
+			enable-method = "psci";
+			capacity-dmips-mhz = <1024>;
+			next-level-cache = <&L2_0>;
+			#cooling-cells = <2>;
+
+			l1-icache {
+				compatible = "cache";
+			};
+			l1-dcache {
+				compatible = "cache";
+			};
+		};
+
+		CPU2: cpu@2 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a53";
+			reg = <0x2>;
+			enable-method = "psci";
+			capacity-dmips-mhz = <1024>;
+			next-level-cache = <&L2_0>;
+			#cooling-cells = <2>;
+
+			l1-icache {
+				compatible = "cache";
+			};
+			l1-dcache {
+				compatible = "cache";
+			};
+		};
+
+		CPU3: cpu@3 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a53";
+			reg = <0x3>;
+			enable-method = "psci";
+			capacity-dmips-mhz = <1024>;
+			next-level-cache = <&L2_0>;
+			#cooling-cells = <2>;
+
+			l1-icache {
+				compatible = "cache";
+			};
+			l1-dcache {
+				compatible = "cache";
+			};
+		};
+
+		CPU4: cpu@100 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a53";
+			reg = <0x100>;
+			enable-method = "psci";
+			capacity-dmips-mhz = <1024>;
+			next-level-cache = <&L2_1>;
+			#cooling-cells = <2>;
+
+			l1-icache {
+				compatible = "cache";
+			};
+			l1-dcache {
+				compatible = "cache";
+			};
+		};
+
+		CPU5: cpu@101 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a53";
+			reg = <0x101>;
+			enable-method = "psci";
+			capacity-dmips-mhz = <1024>;
+			next-level-cache = <&L2_1>;
+			#cooling-cells = <2>;
+
+			l1-icache {
+				compatible = "cache";
+			};
+			l1-dcache {
+				compatible = "cache";
+			};
+		};
+
+		CPU6: cpu@102 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a53";
+			reg = <0x102>;
+			enable-method = "psci";
+			capacity-dmips-mhz = <1024>;
+			next-level-cache = <&L2_1>;
+			#cooling-cells = <2>;
+
+			l1-icache {
+				compatible = "cache";
+			};
+			l1-dcache {
+				compatible = "cache";
+			};
+		};
+
+		CPU7: cpu@103 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a53";
+			reg = <0x103>;
+			enable-method = "psci";
+			capacity-dmips-mhz = <1024>;
+			next-level-cache = <&L2_1>;
+			#cooling-cells = <2>;
+
+			l1-icache {
+				compatible = "cache";
+			};
+			l1-dcache {
+				compatible = "cache";
+			};
+		};
+
+		cpu-map {
+			cluster0 {
+				core0 {
+					cpu = <&CPU0>;
+				};
+				core1 {
+					cpu = <&CPU1>;
+				};
+				core2 {
+					cpu = <&CPU2>;
+				};
+				core3 {
+					cpu = <&CPU3>;
+				};
+			};
+
+			cluster1 {
+				core0 {
+					cpu = <&CPU4>;
+				};
+				core1 {
+					cpu = <&CPU5>;
+				};
+				core2 {
+					cpu = <&CPU6>;
+				};
+				core3 {
+					cpu = <&CPU7>;
+				};
+			};
+		};
+
+		L2_0: l2-cache_0 {
+			compatible = "cache";
+			cache-level = <2>;
+		};
+
+		L2_1: l2-cache_1 {
+			compatible = "cache";
+			cache-level = <2>;
+		};
+	};
+
+	firmware {
+		scm: scm {
+			compatible = "qcom,scm-msm8953";
+			clocks = <&gcc GCC_CRYPTO_CLK>,
+				 <&gcc GCC_CRYPTO_AXI_CLK>,
+				 <&gcc GCC_CRYPTO_AHB_CLK>;
+			clock-names = "core", "bus", "iface";
+			#reset-cells = <1>;
+		};
+	};
+
+	memory {
+		device_type = "memory";
+		/* We expect the bootloader to fill in the reg */
+		reg = <0 0 0 0>;
+	};
+
+	pmu {
+		compatible = "arm,cortex-a53-pmu";
+		interrupts = <GIC_PPI 7 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_HIGH)>;
+	};
+
+	psci {
+		compatible = "arm,psci-1.0";
+		method = "smc";
+	};
+
+	reserved-memory {
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+
+		zap_shader_region: memory@81800000 {
+			compatible = "shared-dma-pool";
+			reg = <0x0 0x81800000 0x0 0x2000>;
+			no-map;
+		};
+
+		memory@85b00000 {
+			reg = <0x0 0x85b00000 0x0 0x800000>;
+			no-map;
+		};
+
+		smem_mem: memory@86300000 {
+			compatible = "qcom,smem";
+			reg = <0x0 0x86300000 0x0 0x100000>;
+			qcom,rpm-msg-ram = <&rpm_msg_ram>;
+			hwlocks = <&tcsr_mutex 3>;
+			no-map;
+		};
+
+		memory@86400000 {
+			reg = <0x0 0x86400000 0x0 0x400000>;
+			no-map;
+		};
+
+		mpss_mem: memory@86c00000 {
+			reg = <0x0 0x86c00000 0x0 0x6a00000>;
+			no-map;
+		};
+
+		adsp_fw_mem: memory@8d600000 {
+			reg = <0x0 0x8d600000 0x0 0x1100000>;
+			no-map;
+		};
+
+		wcnss_fw_mem: memory@8e700000 {
+			reg = <0x0 0x8e700000 0x0 0x700000>;
+			no-map;
+		};
+
+		memory@90000000 {
+			reg = <0 0x90000000 0 0x1000>;
+			no-map;
+		};
+
+		memory@90001000 {
+			reg = <0x0 0x90001000 0x0 0x13ff000>;
+			no-map;
+		};
+
+		venus_mem: memory@90400000 {
+			reg = <0x0 0x91400000 0x0 0x700000>;
+			no-map;
+		};
+
+		mba_mem: memory@92000000 {
+			reg = <0x0 0x92000000 0x0 0x100000>;
+			no-map;
+		};
+
+		memory@f2d00000 {
+			compatible = "qcom,rmtfs-mem";
+			reg = <0x0 0xf2d00000 0x0 0x180000>;
+			no-map;
+
+			qcom,client-id = <1>;
+		};
+	};
+
+	smd {
+		compatible = "qcom,smd";
+
+		rpm {
+			interrupts = <GIC_SPI 168 IRQ_TYPE_EDGE_RISING>;
+			qcom,ipc = <&apcs 8 0>;
+			qcom,smd-edge = <15>;
+
+			rpm_requests: rpm_requests {
+				compatible = "qcom,rpm-msm8953";
+				qcom,smd-channels = "rpm_requests";
+
+				rpmcc: rpmcc {
+					compatible = "qcom,rpmcc-msm8953";
+					clocks = <&xo_board>;
+					clock-names = "xo";
+					#clock-cells = <1>;
+				};
+
+				rpmpd: power-controller {
+					compatible = "qcom,msm8953-rpmpd";
+					#power-domain-cells = <1>;
+					operating-points-v2 = <&rpmpd_opp_table>;
+
+					clocks = <&xo_board>;
+					clock-names = "ref";
+
+					rpmpd_opp_table: opp-table {
+						compatible = "operating-points-v2";
+
+						rpmpd_opp_ret: opp1 {
+							opp-level = <RPM_SMD_LEVEL_RETENTION>;
+						};
+
+						rpmpd_opp_ret_plus: opp2 {
+							opp-level = <RPM_SMD_LEVEL_RETENTION_PLUS>;
+						};
+
+						rpmpd_opp_min_svs: opp3 {
+							opp-level = <RPM_SMD_LEVEL_MIN_SVS>;
+						};
+
+						rpmpd_opp_low_svs: opp4 {
+							opp-level = <RPM_SMD_LEVEL_LOW_SVS>;
+						};
+
+						rpmpd_opp_svs: opp5 {
+							opp-level = <RPM_SMD_LEVEL_SVS>;
+						};
+
+						rpmpd_opp_svs_plus: opp6 {
+							opp-level = <RPM_SMD_LEVEL_SVS_PLUS>;
+						};
+
+						rpmpd_opp_nom: opp7 {
+							opp-level = <RPM_SMD_LEVEL_NOM>;
+						};
+
+						rpmpd_opp_nom_plus: opp8 {
+							opp-level = <RPM_SMD_LEVEL_NOM_PLUS>;
+						};
+
+						rpmpd_opp_turbo: opp9 {
+							opp-level = <RPM_SMD_LEVEL_TURBO>;
+						};
+					};
+				};
+			};
+		};
+	};
+
+	smsm {
+		compatible = "qcom,smsm";
+
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		qcom,ipc-1 = <&apcs 8 13>;
+		qcom,ipc-3 = <&apcs 8 19>;
+
+		apps_smsm: apps@0 {
+			reg = <0>;
+
+			#qcom,smem-state-cells = <1>;
+		};
+	};
+
+	soc: soc@0 {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges = <0 0 0 0xffffffff>;
+		compatible = "simple-bus";
+
+		rpm_msg_ram: sram@60000 {
+			compatible = "qcom,rpm-msg-ram";
+			reg = <0x60000 0x8000>;
+		};
+
+		hsusb_phy: phy@79000 {
+			compatible = "qcom,msm8953-qusb2-phy";
+			reg = <0x79000 0x180>;
+			#phy-cells = <0>;
+
+			clocks = <&gcc GCC_USB_PHY_CFG_AHB_CLK>,
+				 <&gcc GCC_QUSB_REF_CLK>;
+			clock-names = "cfg_ahb", "ref";
+
+			qcom,tcsr-syscon = <&tcsr_phy_clk_scheme_sel>;
+
+			resets = <&gcc GCC_QUSB2_PHY_BCR>;
+
+			status = "disabled";
+		};
+
+		rng@e3000 {
+			compatible = "qcom,prng";
+			reg = <0x000e3000 0x1000>;
+			clocks = <&gcc GCC_PRNG_AHB_CLK>;
+			clock-names = "core";
+		};
+
+		tsens0: thermal-sensor@4a9000 {
+			compatible = "qcom,msm8953-tsens", "qcom,tsens-v2";
+			reg = <0x4a9000 0x1000>, /* TM */
+			      <0x4a8000 0x1000>; /* SROT */
+			#qcom,sensors = <16>;
+			interrupts = <GIC_SPI 184 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 314 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "uplow", "critical";
+			#thermal-sensor-cells = <1>;
+		};
+
+		restart@4ab000 {
+			compatible = "qcom,pshold";
+			reg = <0x4ab000 0x4>;
+		};
+
+		tlmm: pinctrl@1000000 {
+			compatible = "qcom,msm8953-pinctrl";
+			reg = <0x1000000 0x300000>;
+			interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
+			gpio-controller;
+			gpio-ranges = <&tlmm 0 0 155>;
+			#gpio-cells = <2>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+
+			uart_console_active: uart-console-active-pins {
+				pins = "gpio4", "gpio5";
+				function = "blsp_uart2";
+				drive-strength = <2>;
+				bias-disable;
+			};
+
+			uart_console_sleep: uart-console-sleep-pins {
+				pins = "gpio4", "gpio5";
+				function = "blsp_uart2";
+				drive-strength = <2>;
+				bias-pull-down;
+			};
+
+			sdc1_clk_on: sdc1-clk-on-pins {
+				pins = "sdc1_clk";
+				bias-disable;
+				drive-strength = <16>;
+			};
+
+			sdc1_clk_off: sdc1-clk-off-pins {
+				pins = "sdc1_clk";
+				bias-disable;
+				drive-strength = <2>;
+			};
+
+			sdc1_cmd_on: sdc1-cmd-on-pins {
+				pins = "sdc1_cmd";
+				bias-disable;
+				drive-strength = <10>;
+			};
+
+			sdc1_cmd_off: sdc1-cmd-off-pins {
+				pins = "sdc1_cmd";
+				bias-disable;
+				drive-strength = <2>;
+			};
+
+			sdc1_data_on: sdc1-data-on-pins {
+				pins = "sdc1_data";
+				bias-pull-up;
+				drive-strength = <10>;
+			};
+
+			sdc1_data_off: sdc1-data-off-pins {
+				pins = "sdc1_data";
+				bias-pull-up;
+				drive-strength = <2>;
+			};
+
+			sdc1_rclk_on: sdc1-rclk-on-pins {
+				pins = "sdc1_rclk";
+				bias-pull-down;
+			};
+
+			sdc1_rclk_off: sdc1-rclk-off-pins {
+				pins = "sdc1_rclk";
+				bias-pull-down;
+			};
+
+			sdc2_clk_on: sdc2-clk-on-pins {
+				pins = "sdc2_clk";
+				drive-strength = <16>;
+				bias-disable;
+			};
+
+			sdc2_clk_off: sdc2-clk-off-pins {
+				pins = "sdc2_clk";
+				bias-disable;
+				drive-strength = <2>;
+			};
+
+			sdc2_cmd_on: sdc2-cmd-on-pins {
+				pins = "sdc2_cmd";
+				bias-pull-up;
+				drive-strength = <10>;
+			};
+
+			sdc2_cmd_off: sdc2-cmd-off-pins {
+				pins = "sdc2_cmd";
+				bias-pull-up;
+				drive-strength = <2>;
+			};
+
+			sdc2_data_on: sdc2-data-on-pins {
+				pins = "sdc2_data";
+				bias-pull-up;
+				drive-strength = <10>;
+			};
+
+			sdc2_data_off: sdc2-data-off-pins {
+				pins = "sdc2_data";
+				bias-pull-up;
+				drive-strength = <2>;
+			};
+
+			sdc2_cd_on: cd-on-pins {
+				pins = "gpio133";
+				function = "gpio";
+				drive-strength = <2>;
+				bias-pull-up;
+			};
+
+			sdc2_cd_off: cd-off-pins {
+				pins = "gpio133";
+				function = "gpio";
+				drive-strength = <2>;
+				bias-disable;
+			};
+
+			gpio_key_default: gpio-key-default-pins {
+				pins = "gpio85";
+				function = "gpio";
+				drive-strength = <2>;
+				bias-pull-up;
+			};
+
+			i2c_1_default: i2c-1-default-pins {
+				pins = "gpio2", "gpio3";
+				function = "blsp_i2c1";
+				drive-strength = <2>;
+				bias-disable;
+			};
+
+			i2c_1_sleep: i2c-1-sleep-pins {
+				pins = "gpio2", "gpio3";
+				function = "gpio";
+				drive-strength = <2>;
+				bias-disable;
+			};
+
+			i2c_2_default: i2c-2-default-pins {
+				pins = "gpio6", "gpio7";
+				function = "blsp_i2c2";
+				drive-strength = <2>;
+				bias-disable;
+			};
+
+			i2c_2_sleep: i2c-2-sleep-pins {
+				pins = "gpio6", "gpio7";
+				function = "gpio";
+				drive-strength = <2>;
+				bias-disable;
+			};
+
+			i2c_3_default: i2c-3-default-pins {
+				pins = "gpio10", "gpio11";
+				function = "blsp_i2c3";
+				drive-strength = <2>;
+				bias-disable;
+			};
+
+			i2c_3_sleep: i2c-3-sleep-pins {
+				pins = "gpio10", "gpio11";
+				function = "gpio";
+				drive-strength = <2>;
+				bias-disable;
+			};
+
+			i2c_4_default: i2c-4-default-pins {
+				pins = "gpio14", "gpio15";
+				function = "blsp_i2c4";
+				drive-strength = <2>;
+				bias-disable;
+			};
+
+			i2c_4_sleep: i2c-4-sleep-pins {
+				pins = "gpio14", "gpio15";
+				function = "gpio";
+				drive-strength = <2>;
+				bias-disable;
+			};
+
+			i2c_5_default: i2c-5-default-pins {
+				pins = "gpio18", "gpio19";
+				function = "blsp_i2c5";
+				drive-strength = <2>;
+				bias-disable;
+			};
+
+			i2c_5_sleep: i2c-5-sleep-pins {
+				pins = "gpio18", "gpio19";
+				function = "gpio";
+				drive-strength = <2>;
+				bias-disable;
+			};
+
+			i2c_6_default: i2c-6-default-pins {
+				pins = "gpio22", "gpio23";
+				function = "blsp_i2c6";
+				drive-strength = <2>;
+				bias-disable;
+			};
+
+			i2c_6_sleep: i2c-6-sleep-pins {
+				pins = "gpio22", "gpio23";
+				function = "gpio";
+				drive-strength = <2>;
+				bias-disable;
+			};
+
+			i2c_7_default: i2c-7-default-pins {
+				pins = "gpio135", "gpio136";
+				function = "blsp_i2c7";
+				drive-strength = <2>;
+				bias-disable;
+			};
+
+			i2c_7_sleep: i2c-7-sleep-pins {
+				pins = "gpio135", "gpio136";
+				function = "gpio";
+				drive-strength = <2>;
+				bias-disable;
+			};
+
+			i2c_8_default: i2c-8-default-pins {
+				pins = "gpio98", "gpio99";
+				function = "blsp_i2c8";
+				drive-strength = <2>;
+				bias-disable;
+			};
+
+			i2c_8_sleep: i2c-8-sleep-pins {
+				pins = "gpio98", "gpio99";
+				function = "gpio";
+				drive-strength = <2>;
+				bias-disable;
+			};
+		};
+
+		gcc: clock-controller@1800000 {
+			compatible = "qcom,gcc-msm8953";
+			reg = <0x1800000 0x80000>;
+			#clock-cells = <1>;
+			#reset-cells = <1>;
+			#power-domain-cells = <1>;
+			clocks = <&xo_board>,
+				 <&sleep_clk>,
+				 <0>,
+				 <0>,
+				 <0>,
+				 <0>;
+			clock-names = "xo",
+				      "sleep",
+				      "dsi0pll",
+				      "dsi0pllbyte",
+				      "dsi1pll",
+				      "dsi1pllbyte";
+		};
+
+		tcsr_mutex: hwlock@1905000 {
+			compatible = "qcom,tcsr-mutex";
+			reg = <0x1905000 0x20000>;
+			#hwlock-cells = <1>;
+		};
+
+		tcsr: syscon@1937000 {
+			compatible = "qcom,tcsr-msm8953", "syscon";
+			reg = <0x1937000 0x30000>;
+		};
+
+		tcsr_phy_clk_scheme_sel: syscon@193f044 {
+			compatible = "syscon";
+			reg = <0x193f044 0x4>;
+		};
+
+		spmi_bus: spmi@200f000 {
+			compatible = "qcom,spmi-pmic-arb";
+			reg = <0x200f000 0x1000>,
+			      <0x2400000 0x800000>,
+			      <0x2c00000 0x800000>,
+			      <0x3800000 0x200000>,
+			      <0x200a000 0x2100>;
+			reg-names = "core", "chnls", "obsrvr", "intr", "cnfg";
+			interrupt-names = "periph_irq";
+			interrupts = <GIC_SPI 190 IRQ_TYPE_LEVEL_HIGH>;
+			qcom,ee = <0>;
+			qcom,channel = <0>;
+			interrupt-controller;
+
+			#interrupt-cells = <4>;
+			#address-cells = <2>;
+			#size-cells = <0>;
+		};
+
+		usb3: usb@70f8800 {
+			compatible = "qcom,msm8953-dwc3", "qcom,dwc3";
+			reg = <0x70f8800 0x400>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges;
+
+			interrupts = <GIC_SPI 136 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 220 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "hs_phy_irq", "ss_phy_irq";
+
+			clocks = <&gcc GCC_USB_PHY_CFG_AHB_CLK>,
+				 <&gcc GCC_USB30_MASTER_CLK>,
+				 <&gcc GCC_PCNOC_USB3_AXI_CLK>,
+				 <&gcc GCC_USB30_MOCK_UTMI_CLK>,
+				 <&gcc GCC_USB30_SLEEP_CLK>;
+			clock-names = "cfg_noc", "core", "iface",
+				      "mock_utmi", "sleep";
+
+			assigned-clocks = <&gcc GCC_USB30_MOCK_UTMI_CLK>,
+					  <&gcc GCC_USB30_MASTER_CLK>;
+			assigned-clock-rates = <19200000>, <133330000>;
+
+			power-domains = <&gcc USB30_GDSC>;
+
+			qcom,select-utmi-as-pipe-clk;
+
+			status = "disabled";
+
+			usb3_dwc3: usb@7000000 {
+				compatible = "snps,dwc3";
+				reg = <0x07000000 0xcc00>;
+				interrupts = <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH>;
+				phys = <&hsusb_phy>;
+				phy-names = "usb2-phy";
+
+				snps,usb2-gadget-lpm-disable;
+				snps,dis-u1-entry-quirk;
+				snps,dis-u2-entry-quirk;
+				snps,is-utmi-l1-suspend;
+				snps,hird-threshold = /bits/ 8 <0x00>;
+
+				maximum-speed = "high-speed";
+				phy_mode = "utmi";
+			};
+		};
+
+		sdhc_1: sdhci@7824900 {
+			compatible = "qcom,msm8953-sdhci", "qcom,sdhci-msm-v4";
+
+			reg = <0x7824900 0x500>, <0x7824000 0x800>;
+			reg-names = "hc_mem", "core_mem";
+
+			interrupts = <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 138 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "hc_irq", "pwr_irq";
+
+			clocks = <&gcc GCC_SDCC1_AHB_CLK>,
+				 <&gcc GCC_SDCC1_APPS_CLK>,
+				 <&xo_board>;
+			clock-names = "iface", "core", "xo";
+
+			power-domains = <&rpmpd MSM8953_VDDCX>;
+			operating-points-v2 = <&sdhc1_opp_table>;
+
+			pinctrl-names = "default", "sleep";
+			pinctrl-0 = <&sdc1_clk_on &sdc1_cmd_on &sdc1_data_on &sdc1_rclk_on>;
+			pinctrl-1 = <&sdc1_clk_off &sdc1_cmd_off &sdc1_data_off &sdc1_rclk_off>;
+
+			mmc-hs400-1_8v;
+			mmc-hs200-1_8v;
+			mmc-ddr-1_8v;
+			bus-width = <8>;
+			non-removable;
+
+			status = "disabled";
+
+			sdhc1_opp_table: opp-table-sdhc1 {
+				compatible = "operating-points-v2";
+
+				opp-25000000 {
+					opp-hz = /bits/ 64 <25000000>;
+					required-opps = <&rpmpd_opp_low_svs>;
+				};
+
+				opp-50000000 {
+					opp-hz = /bits/ 64 <50000000>;
+					required-opps = <&rpmpd_opp_svs>;
+				};
+
+				opp-100000000 {
+					opp-hz = /bits/ 64 <100000000>;
+					required-opps = <&rpmpd_opp_svs>;
+				};
+
+				opp-192000000 {
+					opp-hz = /bits/ 64 <192000000>;
+					required-opps = <&rpmpd_opp_nom>;
+				};
+
+				opp-384000000 {
+					opp-hz = /bits/ 64 <384000000>;
+					required-opps = <&rpmpd_opp_nom>;
+				};
+			};
+		};
+
+		sdhc_2: sdhci@7864900 {
+			compatible = "qcom,msm8953-sdhci", "qcom,sdhci-msm-v4";
+
+			reg = <0x7864900 0x500>, <0x7864000 0x800>;
+			reg-names = "hc_mem", "core_mem";
+
+			interrupts = <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>,
+				     <GIC_SPI 221 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "hc_irq", "pwr_irq";
+
+			clocks = <&gcc GCC_SDCC2_AHB_CLK>,
+				 <&gcc GCC_SDCC2_APPS_CLK>,
+				 <&xo_board>;
+			clock-names = "iface", "core", "xo";
+
+			power-domains = <&rpmpd MSM8953_VDDCX>;
+			operating-points-v2 = <&sdhc2_opp_table>;
+
+			pinctrl-names = "default", "sleep";
+			pinctrl-0 = <&sdc2_clk_on &sdc2_cmd_on &sdc2_data_on>;
+			pinctrl-1 = <&sdc2_clk_off &sdc2_cmd_off &sdc2_data_off>;
+
+			bus-width = <4>;
+
+			status = "disabled";
+
+			sdhc2_opp_table: opp-table-sdhc2 {
+				compatible = "operating-points-v2";
+
+				opp-25000000 {
+					opp-hz = /bits/ 64 <25000000>;
+					required-opps = <&rpmpd_opp_low_svs>;
+				};
+
+				opp-50000000 {
+					opp-hz = /bits/ 64 <50000000>;
+					required-opps = <&rpmpd_opp_svs>;
+				};
+
+				opp-100000000 {
+					opp-hz = /bits/ 64 <100000000>;
+					required-opps = <&rpmpd_opp_svs>;
+				};
+
+				opp-177770000 {
+					opp-hz = /bits/ 64 <177770000>;
+					required-opps = <&rpmpd_opp_nom>;
+				};
+
+				opp-200000000 {
+					opp-hz = /bits/ 64 <200000000>;
+					required-opps = <&rpmpd_opp_nom>;
+				};
+			};
+		};
+
+		uart_0: serial@78af000 {
+			compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm";
+			reg = <0x78af000 0x200>;
+			interrupts = <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&gcc GCC_BLSP1_UART1_APPS_CLK>,
+				 <&gcc GCC_BLSP1_AHB_CLK>;
+			clock-names = "core", "iface";
+
+			status = "disabled";
+		};
+
+		i2c_1: i2c@78b5000 {
+			compatible = "qcom,i2c-qup-v2.2.1";
+			reg = <0x78b5000 0x600>;
+			interrupts = <GIC_SPI 95 IRQ_TYPE_LEVEL_HIGH>;
+			clock-names = "iface", "core";
+			clocks = <&gcc GCC_BLSP1_AHB_CLK>,
+				 <&gcc GCC_BLSP1_QUP1_I2C_APPS_CLK>;
+
+			pinctrl-names = "default", "sleep";
+			pinctrl-0 = <&i2c_1_default>;
+			pinctrl-1 = <&i2c_1_sleep>;
+
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			status = "disabled";
+		};
+
+		i2c_2: i2c@78b6000 {
+			compatible = "qcom,i2c-qup-v2.2.1";
+			reg = <0x78b6000 0x600>;
+			interrupts = <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>;
+			clock-names = "iface", "core";
+			clocks = <&gcc GCC_BLSP1_AHB_CLK>,
+				 <&gcc GCC_BLSP1_QUP2_I2C_APPS_CLK>;
+
+			pinctrl-names = "default", "sleep";
+			pinctrl-0 = <&i2c_2_default>;
+			pinctrl-1 = <&i2c_2_sleep>;
+
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			status = "disabled";
+		};
+
+		i2c_3: i2c@78b7000 {
+			compatible = "qcom,i2c-qup-v2.2.1";
+			reg = <0x78b7000 0x600>;
+			interrupts = <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>;
+			clock-names = "iface", "core";
+			clocks = <&gcc GCC_BLSP1_AHB_CLK>,
+				 <&gcc GCC_BLSP1_QUP3_I2C_APPS_CLK>;
+			pinctrl-names = "default", "sleep";
+			pinctrl-0 = <&i2c_3_default>;
+			pinctrl-1 = <&i2c_3_sleep>;
+
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			status = "disabled";
+		};
+
+		i2c_4: i2c@78b8000 {
+			compatible = "qcom,i2c-qup-v2.2.1";
+			reg = <0x78b8000 0x600>;
+			interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>;
+			clock-names = "iface", "core";
+			clocks = <&gcc GCC_BLSP1_AHB_CLK>,
+				 <&gcc GCC_BLSP1_QUP4_I2C_APPS_CLK>;
+			pinctrl-names = "default", "sleep";
+			pinctrl-0 = <&i2c_4_default>;
+			pinctrl-1 = <&i2c_4_sleep>;
+
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			status = "disabled";
+		};
+
+		i2c_5: i2c@7af5000 {
+			compatible = "qcom,i2c-qup-v2.2.1";
+			reg = <0x7af5000 0x600>;
+			interrupts = <GIC_SPI 299 IRQ_TYPE_LEVEL_HIGH>;
+			clock-names = "iface", "core";
+			clocks = <&gcc GCC_BLSP2_AHB_CLK>,
+				 <&gcc GCC_BLSP2_QUP1_I2C_APPS_CLK>;
+			pinctrl-names = "default", "sleep";
+			pinctrl-0 = <&i2c_5_default>;
+			pinctrl-1 = <&i2c_5_sleep>;
+
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			status = "disabled";
+		};
+
+		i2c_6: i2c@7af6000 {
+			compatible = "qcom,i2c-qup-v2.2.1";
+			reg = <0x7af6000 0x600>;
+			interrupts = <GIC_SPI 300 IRQ_TYPE_LEVEL_HIGH>;
+			clock-names = "iface", "core";
+			clocks = <&gcc GCC_BLSP2_AHB_CLK>,
+				 <&gcc GCC_BLSP2_QUP2_I2C_APPS_CLK>;
+			pinctrl-names = "default", "sleep";
+			pinctrl-0 = <&i2c_6_default>;
+			pinctrl-1 = <&i2c_6_sleep>;
+
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			status = "disabled";
+		};
+
+		i2c_7: i2c@7af7000 {
+			compatible = "qcom,i2c-qup-v2.2.1";
+			reg = <0x7af7000 0x600>;
+			interrupts = <GIC_SPI 301 IRQ_TYPE_LEVEL_HIGH>;
+			clock-names = "iface", "core";
+			clocks = <&gcc GCC_BLSP2_AHB_CLK>,
+				 <&gcc GCC_BLSP2_QUP3_I2C_APPS_CLK>;
+			pinctrl-names = "default", "sleep";
+			pinctrl-0 = <&i2c_7_default>;
+			pinctrl-1 = <&i2c_7_sleep>;
+
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			status = "disabled";
+		};
+
+		i2c_8: i2c@7af8000 {
+			compatible = "qcom,i2c-qup-v2.2.1";
+			reg = <0x7af8000 0x600>;
+			interrupts = <GIC_SPI 302 IRQ_TYPE_LEVEL_HIGH>;
+			clock-names = "iface", "core";
+			clocks = <&gcc GCC_BLSP2_AHB_CLK>,
+				 <&gcc GCC_BLSP2_QUP4_I2C_APPS_CLK>;
+			pinctrl-names = "default", "sleep";
+			pinctrl-0 = <&i2c_8_default>;
+			pinctrl-1 = <&i2c_8_sleep>;
+
+			#address-cells = <1>;
+			#size-cells = <0>;
+
+			status = "disabled";
+		};
+
+		intc: interrupt-controller@b000000 {
+			compatible = "qcom,msm-qgic2";
+			interrupt-controller;
+			#interrupt-cells = <3>;
+			reg = <0x0b000000 0x1000>, <0x0b002000 0x1000>;
+		};
+
+		apcs: mailbox@b011000 {
+			compatible = "qcom,msm8953-apcs-kpss-global", "syscon";
+			reg = <0xb011000 0x1000>;
+			#mbox-cells = <1>;
+		};
+
+		timer@b120000 {
+			compatible = "arm,armv7-timer-mem";
+			reg = <0xb120000 0x1000>;
+			#address-cells = <0x01>;
+			#size-cells = <0x01>;
+			ranges;
+
+			frame@b121000 {
+				frame-number = <0>;
+				interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>,
+					     <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
+				reg = <0xb121000 0x1000>,
+				      <0xb122000 0x1000>;
+			};
+
+			frame@b123000 {
+				frame-number = <1>;
+				interrupts = <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>;
+				reg = <0xb123000 0x1000>;
+				status = "disabled";
+			};
+
+			frame@b124000 {
+				frame-number = <2>;
+				interrupts = <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>;
+				reg = <0xb124000 0x1000>;
+				status = "disabled";
+			};
+
+			frame@b125000 {
+				frame-number = <3>;
+				interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>;
+				reg = <0xb125000 0x1000>;
+				status = "disabled";
+			};
+
+			frame@b126000 {
+				frame-number = <4>;
+				interrupts = <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>;
+				reg = <0xb126000 0x1000>;
+				status = "disabled";
+			};
+
+			frame@b127000 {
+				frame-number = <5>;
+				interrupts = <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>;
+				reg = <0xb127000 0x1000>;
+				status = "disabled";
+			};
+
+			frame@b128000 {
+				frame-number = <6>;
+				interrupts = <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>;
+				reg = <0xb128000 0x1000>;
+				status = "disabled";
+			};
+		};
+	};
+
+	thermal-zones {
+		cpu0-thermal {
+			polling-delay-passive = <250>;
+			polling-delay = <1000>;
+			thermal-sensors = <&tsens0 9>;
+			trips {
+				cpu0_alert: trip-point0 {
+					temperature = <80000>;
+					hysteresis = <2000>;
+					type = "passive";
+				};
+				cpu0_crit: crit {
+					temperature = <100000>;
+					hysteresis = <2000>;
+					type = "critical";
+				};
+			};
+			cooling-maps {
+				map0 {
+					trip = <&cpu0_alert>;
+					cooling-device = <&CPU0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+				};
+			};
+		};
+		cpu1-thermal {
+			polling-delay-passive = <250>;
+			polling-delay = <1000>;
+			thermal-sensors = <&tsens0 10>;
+			trips {
+				cpu1_alert: trip-point0 {
+					temperature = <80000>;
+					hysteresis = <2000>;
+					type = "passive";
+				};
+				cpu1_crit: crit {
+					temperature = <100000>;
+					hysteresis = <2000>;
+					type = "critical";
+				};
+			};
+			cooling-maps {
+				map0 {
+					trip = <&cpu1_alert>;
+					cooling-device = <&CPU1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+				};
+			};
+		};
+		cpu2-thermal {
+			polling-delay-passive = <250>;
+			polling-delay = <1000>;
+			thermal-sensors = <&tsens0 11>;
+			trips {
+				cpu2_alert: trip-point0 {
+					temperature = <80000>;
+					hysteresis = <2000>;
+					type = "passive";
+				};
+				cpu2_crit: crit {
+					temperature = <100000>;
+					hysteresis = <2000>;
+					type = "critical";
+				};
+			};
+			cooling-maps {
+				map0 {
+					trip = <&cpu2_alert>;
+					cooling-device = <&CPU2 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+				};
+			};
+		};
+		cpu3-thermal {
+			polling-delay-passive = <250>;
+			polling-delay = <1000>;
+			thermal-sensors = <&tsens0 12>;
+			trips {
+				cpu3_alert: trip-point0 {
+					temperature = <80000>;
+					hysteresis = <2000>;
+					type = "passive";
+				};
+				cpu3_crit: crit {
+					temperature = <100000>;
+					hysteresis = <2000>;
+					type = "critical";
+				};
+			};
+			cooling-maps {
+				map0 {
+					trip = <&cpu3_alert>;
+					cooling-device = <&CPU3 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+				};
+			};
+		};
+		cpu4-thermal {
+			polling-delay-passive = <250>;
+			polling-delay = <1000>;
+			thermal-sensors = <&tsens0 4>;
+			trips {
+				cpu4_alert: trip-point0 {
+					temperature = <80000>;
+					hysteresis = <2000>;
+					type = "passive";
+				};
+				cpu4_crit: crit {
+					temperature = <100000>;
+					hysteresis = <2000>;
+					type = "critical";
+				};
+			};
+			cooling-maps {
+				map0 {
+					trip = <&cpu4_alert>;
+					cooling-device = <&CPU4 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+				};
+			};
+		};
+		cpu5-thermal {
+			polling-delay-passive = <250>;
+			polling-delay = <1000>;
+			thermal-sensors = <&tsens0 5>;
+			trips {
+				cpu5_alert: trip-point0 {
+					temperature = <80000>;
+					hysteresis = <2000>;
+					type = "passive";
+				};
+				cpu5_crit: crit {
+					temperature = <100000>;
+					hysteresis = <2000>;
+					type = "critical";
+				};
+			};
+			cooling-maps {
+				map0 {
+					trip = <&cpu5_alert>;
+					cooling-device = <&CPU5 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+				};
+			};
+		};
+		cpu6-thermal {
+			polling-delay-passive = <250>;
+			polling-delay = <1000>;
+			thermal-sensors = <&tsens0 6>;
+			trips {
+				cpu6_alert: trip-point0 {
+					temperature = <80000>;
+					hysteresis = <2000>;
+					type = "passive";
+				};
+				cpu6_crit: crit {
+					temperature = <100000>;
+					hysteresis = <2000>;
+					type = "critical";
+				};
+			};
+			cooling-maps {
+				map0 {
+					trip = <&cpu6_alert>;
+					cooling-device = <&CPU6 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+				};
+			};
+		};
+		cpu7-thermal {
+			polling-delay-passive = <250>;
+			polling-delay = <1000>;
+			thermal-sensors = <&tsens0 7>;
+			trips {
+				cpu7_alert: trip-point0 {
+					temperature = <80000>;
+					hysteresis = <2000>;
+					type = "passive";
+				};
+				cpu7_crit: crit {
+					temperature = <100000>;
+					hysteresis = <2000>;
+					type = "critical";
+				};
+			};
+			cooling-maps {
+				map0 {
+					trip = <&cpu7_alert>;
+					cooling-device = <&CPU7 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+				};
+			};
+		};
+	};
+
+	timer {
+		compatible = "arm,armv8-timer";
+		interrupts = <GIC_PPI 2 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>,
+			     <GIC_PPI 3 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>,
+			     <GIC_PPI 4 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>,
+			     <GIC_PPI 1 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>;
+	};
+};
-- 
2.34.1

[PATCH 11/15] arm64: dts: qcom: Add PM8953 PMIC

[Luca Weiss]

From: Vladimir Lypak <vladimir.lypak@gmail.com>

Add a base DT for PM8953 PMIC, commonly used with MSM8953.

Signed-off-by: Vladimir Lypak <vladimir.lypak@gmail.com>
Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org>
---
 arch/arm64/boot/dts/qcom/pm8953.dtsi | 90 ++++++++++++++++++++++++++++
 1 file changed, 90 insertions(+)
 create mode 100644 arch/arm64/boot/dts/qcom/pm8953.dtsi

diff --git a/arch/arm64/boot/dts/qcom/pm8953.dtsi b/arch/arm64/boot/dts/qcom/pm8953.dtsi
new file mode 100644
index 000000000000..102555b3f313
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/pm8953.dtsi
@@ -0,0 +1,90 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/* Copyright (c) 2022, The Linux Foundation. All rights reserved. */
+
+#include <dt-bindings/iio/qcom,spmi-vadc.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/input/linux-event-codes.h>
+#include <dt-bindings/spmi/spmi.h>
+
+&spmi_bus {
+	pmic@0 {
+		compatible = "qcom,pm8953", "qcom,spmi-pmic";
+		reg = <0 SPMI_USID>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		rtc@6000 {
+			compatible = "qcom,pm8941-rtc";
+			reg = <0x6000>, <0x6100>;
+			reg-names = "rtc", "alarm";
+			interrupts = <0x0 0x61 0x1 IRQ_TYPE_EDGE_RISING>;
+		};
+
+		pm8953_pon: pon@800 {
+			compatible = "qcom,pm8916-pon";
+			reg = <0x800>;
+			mode-bootloader = <0x2>;
+			mode-recovery = <0x1>;
+
+			pwrkey {
+				compatible = "qcom,pm8941-pwrkey";
+				interrupts = <0x00 0x08 0 IRQ_TYPE_EDGE_BOTH>;
+				debounce = <15625>;
+				bias-pull-up;
+				linux,code = <KEY_POWER>;
+			};
+
+			pm8953_resin: resin {
+				compatible = "qcom,pm8941-resin";
+				interrupts = <0x00 0x08 1 IRQ_TYPE_EDGE_BOTH>;
+				debounce = <15625>;
+				bias-pull-up;
+				status = "disabled";
+			};
+		};
+
+		temp-alarm@2400 {
+			compatible = "qcom,spmi-temp-alarm";
+			reg = <0x2400>;
+			interrupts = <0x0 0x24 0x0 IRQ_TYPE_EDGE_RISING>;
+			io-channels = <&pm8953_vadc 0x08>;
+			io-channel-names = "thermal";
+			#thermal-sensor-cells = <0x00>;
+		};
+
+		pm8953_vadc: vadc@3100 {
+			compatible = "qcom,spmi-vadc";
+			reg = <0x3100>;
+			interrupts = <0x00 0x31 0x00 0x01>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			#io-channel-cells = <1>;
+
+			die_temp@8 {
+				reg = <VADC_DIE_TEMP>;
+			};
+			ref_625mv@9 {
+				reg = <VADC_REF_625MV>;
+			};
+			ref_1250v@a {
+				reg = <VADC_REF_1250MV>;
+			};
+			ref_buf_625mv@c {
+				reg = <VADC_SPARE1>;
+			};
+			ref_gnd@e {
+				reg = <VADC_GND_REF>;
+			};
+			ref_vdd@f {
+				reg = <VADC_VDD_VADC>;
+			};
+		};
+	};
+
+	pmic@1 {
+		compatible = "qcom,pm8953", "qcom,spmi-pmic";
+		reg = <1 SPMI_USID>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+	};
+};
-- 
2.34.1

[PATCH 12/15] arm64: dts: qcom: Add SDM632 device tree

[Luca Weiss]

From: Vladimir Lypak <vladimir.lypak@gmail.com>

Snapdragon 632 is based on msm8953, add the devicee tree for that.

Signed-off-by: Vladimir Lypak <vladimir.lypak@gmail.com>
Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
---
 arch/arm64/boot/dts/qcom/sdm632.dtsi | 125 +++++++++++++++++++++++++++
 1 file changed, 125 insertions(+)
 create mode 100644 arch/arm64/boot/dts/qcom/sdm632.dtsi

diff --git a/arch/arm64/boot/dts/qcom/sdm632.dtsi b/arch/arm64/boot/dts/qcom/sdm632.dtsi
new file mode 100644
index 000000000000..b80ba8a5ef3f
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/sdm632.dtsi
@@ -0,0 +1,125 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/* Copyright (c) 2022, The Linux Foundation. All rights reserved. */
+
+#include "msm8953.dtsi"
+
+/ {
+	thermal-zones {
+		/delete-node/cpu0-thermal;
+		/delete-node/cpu1-thermal;
+		/delete-node/cpu2-thermal;
+		/delete-node/cpu3-thermal;
+		/delete-node/cpu4-thermal;
+		/delete-node/cpu5-thermal;
+		/delete-node/cpu6-thermal;
+		/delete-node/cpu7-thermal;
+		cpu4-thermal {
+			polling-delay-passive = <250>;
+			polling-delay = <1000>;
+			thermal-sensors = <&tsens0 5>;
+			trips {
+				cpu4_alert: trip-point0 {
+					temperature = <80000>;
+					hysteresis = <2000>;
+					type = "passive";
+				};
+				cpu4_crit: crit {
+					temperature = <100000>;
+					hysteresis = <2000>;
+					type = "critical";
+				};
+			};
+			cooling-maps {
+				map0 {
+					trip = <&cpu4_alert>;
+					cooling-device = <&CPU4 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+				};
+			};
+		};
+		cpu5-thermal {
+			polling-delay-passive = <250>;
+			polling-delay = <1000>;
+			thermal-sensors = <&tsens0 6>;
+			trips {
+				cpu5_alert: trip-point0 {
+					temperature = <80000>;
+					hysteresis = <2000>;
+					type = "passive";
+				};
+				cpu5_crit: crit {
+					temperature = <100000>;
+					hysteresis = <2000>;
+					type = "critical";
+				};
+			};
+			cooling-maps {
+				map0 {
+					trip = <&cpu5_alert>;
+					cooling-device = <&CPU5 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+				};
+			};
+		};
+		cpu6-thermal {
+			polling-delay-passive = <250>;
+			polling-delay = <1000>;
+			thermal-sensors = <&tsens0 7>;
+			trips {
+				cpu6_alert: trip-point0 {
+					temperature = <80000>;
+					hysteresis = <2000>;
+					type = "passive";
+				};
+				cpu6_crit: crit {
+					temperature = <100000>;
+					hysteresis = <2000>;
+					type = "critical";
+				};
+			};
+			cooling-maps {
+				map0 {
+					trip = <&cpu6_alert>;
+					cooling-device = <&CPU6 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+				};
+			};
+		};
+		cpu7-thermal {
+			polling-delay-passive = <250>;
+			polling-delay = <1000>;
+			thermal-sensors = <&tsens0 8>;
+			trips {
+				cpu7_alert: trip-point0 {
+					temperature = <80000>;
+					hysteresis = <2000>;
+					type = "passive";
+				};
+				cpu7_crit: crit {
+					temperature = <100000>;
+					hysteresis = <2000>;
+					type = "critical";
+				};
+			};
+			cooling-maps {
+				map0 {
+					trip = <&cpu7_alert>;
+					cooling-device = <&CPU7 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+				};
+			};
+		};
+	};
+};
+
+&CPU4 {
+	capacity-dmips-mhz = <1980>;
+};
+
+&CPU5 {
+	capacity-dmips-mhz = <1980>;
+};
+
+&CPU6 {
+	capacity-dmips-mhz = <1980>;
+};
+
+&CPU7 {
+	capacity-dmips-mhz = <1980>;
+};
-- 
2.34.1

[PATCH 13/15] arm64: dts: qcom: Add MSM8953+PM8953 device tree

[Luca Weiss]

From: Vladimir Lypak <vladimir.lypak@gmail.com>

The combination MSM8953 + PM8953 is commonly used, so add a
device tree where common power supplies etc. can be configured.

Signed-off-by: Vladimir Lypak <vladimir.lypak@gmail.com>
Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org>
---
 arch/arm64/boot/dts/qcom/msm8953-pm8953.dtsi | 50 ++++++++++++++++++++
 1 file changed, 50 insertions(+)
 create mode 100644 arch/arm64/boot/dts/qcom/msm8953-pm8953.dtsi

diff --git a/arch/arm64/boot/dts/qcom/msm8953-pm8953.dtsi b/arch/arm64/boot/dts/qcom/msm8953-pm8953.dtsi
new file mode 100644
index 000000000000..b5f20fc9488e
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/msm8953-pm8953.dtsi
@@ -0,0 +1,50 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/* Copyright (c) 2022, The Linux Foundation. All rights reserved. */
+
+#include "msm8953.dtsi"
+#include "pm8953.dtsi"
+
+&hsusb_phy {
+	vdd-supply = <&pm8953_l3>;
+	vdda-pll-supply = <&pm8953_l7>;
+	vdda-phy-dpdm-supply = <&pm8953_l13>;
+};
+
+&sdhc_1 {
+	vmmc-supply = <&pm8953_l8>;
+	vqmmc-supply = <&pm8953_l5>;
+};
+
+&sdhc_2 {
+	vmmc-supply = <&pm8953_l11>;
+	vqmmc-supply = <&pm8953_l12>;
+};
+
+&rpm_requests {
+	smd_rpm_regulators: pm8953-regulators {
+		compatible = "qcom,rpm-pm8953-regulators";
+
+		pm8953_s1: s1 {};
+		pm8953_s3: s3 {};
+		pm8953_s4: s4 {};
+
+		pm8953_l1: l1 {};
+		pm8953_l2: l2 {};
+		pm8953_l3: l3 {};
+		pm8953_l5: l5 {};
+		pm8953_l6: l6 {};
+		pm8953_l7: l7 {};
+		pm8953_l8: l8 {};
+		pm8953_l9: l9 {};
+		pm8953_l10: l10 {};
+		pm8953_l11: l11 {};
+		pm8953_l12: l12 {};
+		pm8953_l13: l13 {};
+		pm8953_l15: l15 {};
+		pm8953_l16: l16 {};
+		pm8953_l17: l17 {};
+		pm8953_l19: l19 {};
+		pm8953_l22: l22 {};
+		pm8953_l23: l23 {};
+	};
+};
-- 
2.34.1

[PATCH 14/15] dt-bindings: arm: qcom: Document sdm632 and fairphone,fp3 board

[Luca Weiss]

Add binding documentation for Fairphone 3 smartphone which is based on
Snapdragon 632 (sm632).

Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
---
 Documentation/devicetree/bindings/arm/qcom.yaml | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
index c8808e0f9e64..d3755bc8c28f 100644
--- a/Documentation/devicetree/bindings/arm/qcom.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom.yaml
@@ -42,6 +42,7 @@ description: |
         sc7180
         sc7280
         sdm630
+        sdm632
         sdm660
         sdm845
         sdx55
@@ -207,6 +208,11 @@ properties:
               - google,senor
           - const: qcom,sc7280
 
+      - items:
+          - enum:
+              - fairphone,fp3
+          - const: qcom,sdm632
+
       - items:
           - enum:
               - xiaomi,lavender
-- 
2.34.1

[PATCH 15/15] arm64: dts: qcom: sdm632: Add device tree for Fairphone 3

[Luca Weiss]

Add device tree for the Fairphone 3 smartphone which is based on
Snapdragon 632 (sdm632).

Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
---
 arch/arm64/boot/dts/qcom/Makefile             |   1 +
 .../boot/dts/qcom/sdm632-fairphone-fp3.dts    | 189 ++++++++++++++++++
 2 files changed, 190 insertions(+)
 create mode 100644 arch/arm64/boot/dts/qcom/sdm632-fairphone-fp3.dts

diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index 6b816eb33309..f67973aacd82 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -82,6 +82,7 @@ dtb-$(CONFIG_ARCH_QCOM)	+= sdm630-sony-xperia-ganges-kirin.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= sdm630-sony-xperia-nile-discovery.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= sdm630-sony-xperia-nile-pioneer.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= sdm630-sony-xperia-nile-voyager.dtb
+dtb-$(CONFIG_ARCH_QCOM)	+= sdm632-fairphone-fp3.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= sdm636-sony-xperia-ganges-mermaid.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= sdm660-xiaomi-lavender.dtb
 dtb-$(CONFIG_ARCH_QCOM)	+= sdm845-cheza-r1.dtb
diff --git a/arch/arm64/boot/dts/qcom/sdm632-fairphone-fp3.dts b/arch/arm64/boot/dts/qcom/sdm632-fairphone-fp3.dts
new file mode 100644
index 000000000000..34f4900c8b28
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/sdm632-fairphone-fp3.dts
@@ -0,0 +1,189 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) 2022, Luca Weiss <luca@z3ntu.xyz>
+ */
+/dts-v1/;
+
+#include "msm8953-pm8953.dtsi"
+#include "sdm632.dtsi"
+
+/ {
+	model = "Fairphone 3";
+	compatible = "fairphone,fp3", "qcom,sdm632";
+	chassis-type = "handset";
+	qcom,msm-id = <349 0>;
+	qcom,board-id = <8 0x10000>;
+
+	aliases {
+		mmc0 = &sdhc_1;
+		mmc1 = &sdhc_2;
+		serial0 = &uart_0;
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
+	gpio-keys {
+		compatible = "gpio-keys";
+
+		volume-up {
+			label = "volume_up";
+			linux,code = <KEY_VOLUMEUP>;
+			gpios = <&tlmm 85 GPIO_ACTIVE_LOW>;
+		};
+	};
+
+	vph_pwr: vph-pwr-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vph_pwr";
+		regulator-always-on;
+		regulator-boot-on;
+	};
+};
+
+&hsusb_phy {
+	status = "okay";
+};
+
+&pm8953_resin {
+	status = "okay";
+	linux,code = <KEY_VOLUMEDOWN>;
+};
+
+&sdhc_1 {
+	status = "okay";
+};
+
+&sdhc_2 {
+	status = "okay";
+	cd-gpios = <&tlmm 133 GPIO_ACTIVE_LOW>;
+};
+
+&smd_rpm_regulators {
+	vdd_l1-supply = <&pm8953_s3>;
+	vdd_l2_l3-supply = <&pm8953_s3>;
+	vdd_l4_l5_l6_l7_l16_l19-supply = <&pm8953_s4>;
+	vdd_l8_l11_l12_l13_l14_l15-supply = <&vph_pwr>;
+	vdd_l9_l10_l17_l18_l22-supply = <&vph_pwr>;
+
+	s3 {
+		regulator-min-microvolt = <984000>;
+		regulator-max-microvolt = <1240000>;
+	};
+
+	s4 {
+		regulator-min-microvolt = <1036000>;
+		regulator-max-microvolt = <2040000>;
+	};
+
+	s5 {
+		regulator-min-microvolt = <1036000>;
+		regulator-max-microvolt = <2040000>;
+	};
+
+	l1 {
+		regulator-min-microvolt = <975000>;
+		regulator-max-microvolt = <1050000>;
+	};
+
+	l2 {
+		regulator-min-microvolt = <975000>;
+		regulator-max-microvolt = <1175000>;
+	};
+
+	l3 {
+		regulator-min-microvolt = <925000>;
+		regulator-max-microvolt = <925000>;
+	};
+
+	l5 {
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+	};
+
+	l6 {
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+	};
+
+	l7 {
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1900000>;
+	};
+
+	l8 {
+		regulator-min-microvolt = <2900000>;
+		regulator-max-microvolt = <2900000>;
+	};
+
+	l9 {
+		regulator-min-microvolt = <3000000>;
+		regulator-max-microvolt = <3300000>;
+	};
+
+	l10 {
+		regulator-min-microvolt = <2800000>;
+		regulator-max-microvolt = <3000000>;
+	};
+
+	l11 {
+		regulator-min-microvolt = <2950000>;
+		regulator-max-microvolt = <2950000>;
+	};
+
+	l12 {
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <2950000>;
+	};
+
+	l13 {
+		regulator-min-microvolt = <3125000>;
+		regulator-max-microvolt = <3125000>;
+	};
+
+	l16 {
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+	};
+
+	l17 {
+		regulator-min-microvolt = <2850000>;
+		regulator-max-microvolt = <2850000>;
+	};
+
+	l19 {
+		regulator-min-microvolt = <1200000>;
+		regulator-max-microvolt = <1350000>;
+	};
+
+	l22 {
+		regulator-min-microvolt = <2800000>;
+		regulator-max-microvolt = <2800000>;
+	};
+
+	l23 {
+		regulator-min-microvolt = <975000>;
+		regulator-max-microvolt = <1225000>;
+	};
+};
+
+&tlmm {
+	/*
+	 * 0-3: unused but protected by TZ
+	 * 135-138: fingerprint reader (SPI)
+	 */
+	gpio-reserved-ranges = <0 4>, <135 4>;
+};
+
+&uart_0 {
+	status = "okay";
+};
+
+&usb3 {
+	status = "okay";
+};
+
+&usb3_dwc3 {
+	dr_mode = "peripheral";
+};
-- 
2.34.1

Re: [PATCH 09/15] rpmsg: smd: Drop unnecessary condition for channel creation

[Stephan Gerhold]

Hi,

+Cc Srinivas

On Wed, Jan 12, 2022 at 08:40:58PM +0100, Luca Weiss wrote:
> From: Vladimir Lypak <vladimir.lypak@gmail.com>
> 
> RPM Firmware on variety of newer SoCs such as MSM8917 (also likely
> MSM8937, MSM8940, MSM8952), MSM8953 and on some MSM8916 devices) doesn't
> initiate opening of the SMD channel if it was previously opened by
> bootloader. This doesn't allow probing of smd-rpm driver on such devices
> because there is a check that requires RPM this behaviour.
> 
> Signed-off-by: Vladimir Lypak <vladimir.lypak@gmail.com>
> Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org>

This is effectively a "Revert "Revert "rpmsg: smd: Create device for all
channels""":

https://lore.kernel.org/linux-arm-msm/20171212235857.10432-3-bjorn.andersson@linaro.org/
https://lore.kernel.org/linux-arm-msm/20180315181244.8859-1-bjorn.andersson@linaro.org/

Won't this cause the same regression reported by Srinivas again?

Thanks,
Stephan

> ---
>  drivers/rpmsg/qcom_smd.c | 8 +-------
>  1 file changed, 1 insertion(+), 7 deletions(-)
> 
> diff --git a/drivers/rpmsg/qcom_smd.c b/drivers/rpmsg/qcom_smd.c
> index 8da1b5cb31b3..6a01ef932b01 100644
> --- a/drivers/rpmsg/qcom_smd.c
> +++ b/drivers/rpmsg/qcom_smd.c
> @@ -1280,19 +1280,13 @@ static void qcom_channel_state_worker(struct work_struct *work)
>  	unsigned long flags;
>  
>  	/*
> -	 * Register a device for any closed channel where the remote processor
> -	 * is showing interest in opening the channel.
> +	 * Register a device for any closed channel.
>  	 */
>  	spin_lock_irqsave(&edge->channels_lock, flags);
>  	list_for_each_entry(channel, &edge->channels, list) {
>  		if (channel->state != SMD_CHANNEL_CLOSED)
>  			continue;
>  
> -		remote_state = GET_RX_CHANNEL_INFO(channel, state);
> -		if (remote_state != SMD_CHANNEL_OPENING &&
> -		    remote_state != SMD_CHANNEL_OPENED)
> -			continue;
> -
>  		if (channel->registered)
>  			continue;
>  
> -- 
> 2.34.1
> 

Re: [PATCH 09/15] rpmsg: smd: Drop unnecessary condition for channel creation

[Luca Weiss]

Hi Stephan,

On Mittwoch, 12. Jänner 2022 22:39:53 CET Stephan Gerhold wrote:
> Hi,
> 
> +Cc Srinivas
> 
> On Wed, Jan 12, 2022 at 08:40:58PM +0100, Luca Weiss wrote:
> > From: Vladimir Lypak <vladimir.lypak@gmail.com>
> > 
> > RPM Firmware on variety of newer SoCs such as MSM8917 (also likely
> > MSM8937, MSM8940, MSM8952), MSM8953 and on some MSM8916 devices) doesn't
> > initiate opening of the SMD channel if it was previously opened by
> > bootloader. This doesn't allow probing of smd-rpm driver on such devices
> > because there is a check that requires RPM this behaviour.
> > 
> > Signed-off-by: Vladimir Lypak <vladimir.lypak@gmail.com>
> > Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
> > Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org>
> 
> This is effectively a "Revert "Revert "rpmsg: smd: Create device for all
> channels""":
> 
> https://lore.kernel.org/linux-arm-msm/20171212235857.10432-3-bjorn.andersson
> @linaro.org/
> https://lore.kernel.org/linux-arm-msm/20180315181244.8859-1-bjorn.andersson
> @linaro.org/
> 
> Won't this cause the same regression reported by Srinivas again?
> 

Do you have any suggestion on another way to solve this? Without this commit 
the regulators just won't probe at all, I haven't looked very deep into it 
though given this patch solves it.

I guess worst case it'll become a devicetree property to enable this quirk?

Regards
Luca

> Thanks,
> Stephan
> 
> > ---
> > 
> >  drivers/rpmsg/qcom_smd.c | 8 +-------
> >  1 file changed, 1 insertion(+), 7 deletions(-)
> > 
> > diff --git a/drivers/rpmsg/qcom_smd.c b/drivers/rpmsg/qcom_smd.c
> > index 8da1b5cb31b3..6a01ef932b01 100644
> > --- a/drivers/rpmsg/qcom_smd.c
> > +++ b/drivers/rpmsg/qcom_smd.c
> > @@ -1280,19 +1280,13 @@ static void qcom_channel_state_worker(struct
> > work_struct *work)> 
> >  	unsigned long flags;
> >  	
> >  	/*
> > 
> > -	 * Register a device for any closed channel where the remote 
processor
> > -	 * is showing interest in opening the channel.
> > +	 * Register a device for any closed channel.
> > 
> >  	 */
> >  	
> >  	spin_lock_irqsave(&edge->channels_lock, flags);
> >  	list_for_each_entry(channel, &edge->channels, list) {
> >  	
> >  		if (channel->state != SMD_CHANNEL_CLOSED)
> >  		
> >  			continue;
> > 
> > -		remote_state = GET_RX_CHANNEL_INFO(channel, state);
> > -		if (remote_state != SMD_CHANNEL_OPENING &&
> > -		    remote_state != SMD_CHANNEL_OPENED)
> > -			continue;
> > -
> > 
> >  		if (channel->registered)
> >  		
> >  			continue;

Re: [PATCH 09/15] rpmsg: smd: Drop unnecessary condition for channel creation

[Stephan Gerhold]

On Sun, Jan 16, 2022 at 05:08:29PM +0100, Luca Weiss wrote:
> On Mittwoch, 12. Jänner 2022 22:39:53 CET Stephan Gerhold wrote:
> > On Wed, Jan 12, 2022 at 08:40:58PM +0100, Luca Weiss wrote:
> > > From: Vladimir Lypak <vladimir.lypak@gmail.com>
> > > 
> > > RPM Firmware on variety of newer SoCs such as MSM8917 (also likely
> > > MSM8937, MSM8940, MSM8952), MSM8953 and on some MSM8916 devices) doesn't
> > > initiate opening of the SMD channel if it was previously opened by
> > > bootloader. This doesn't allow probing of smd-rpm driver on such devices
> > > because there is a check that requires RPM this behaviour.
> > > 
> > > Signed-off-by: Vladimir Lypak <vladimir.lypak@gmail.com>
> > > Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
> > > Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org>
> > 
> > This is effectively a "Revert "Revert "rpmsg: smd: Create device for all
> > channels""":
> > 
> > https://lore.kernel.org/linux-arm-msm/20171212235857.10432-3-bjorn.andersson
> > @linaro.org/
> > https://lore.kernel.org/linux-arm-msm/20180315181244.8859-1-bjorn.andersson
> > @linaro.org/
> > 
> > Won't this cause the same regression reported by Srinivas again?
> > 
> 
> Do you have any suggestion on another way to solve this? Without this commit 
> the regulators just won't probe at all, I haven't looked very deep into it 
> though given this patch solves it.
> 
> I guess worst case it'll become a devicetree property to enable this quirk?
> 

My spontaneous suggestion would be to skip the check only for the
"rpm_requests" channel, e.g. something like

	if (remote_state != SMD_CHANNEL_OPENING &&
	    remote_state != SMD_CHANNEL_OPENED &&
	    strcmp(channel->name, "rpm_requests")
		continue;

This will avoid changing the behavior for anything but the RPM channel.
I don't think anything else is affected by the same problem (since the
bootloader or earlier firmware should not make use of any other channel).
Also, we definitely *always* want to open the channel to the RPM because
otherwise almost everything breaks.

Many solutions are possible though so at the end it is mostly up to
Bjorn to decide I think. :)

Thanks,
Stephan

Re: [PATCH 06/15] dt-bindings: thermal: tsens: Add msm8953 compatible

[Amit Kucheria]

On Thu, Jan 13, 2022 at 1:12 AM Luca Weiss <luca@z3ntu.xyz> wrote:
>
> Document the compatible string for tsens found in msm8953.
>
> Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
> Acked-by: Konrad Dybcio <konrad.dybcio@somainline.org>

Acked-by: Amit Kucheria <amitk@kernel.org>

> ---
>  Documentation/devicetree/bindings/thermal/qcom-tsens.yaml | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml
> index d3b9e9b600a2..b6406bcc683f 100644
> --- a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml
> +++ b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml
> @@ -43,6 +43,7 @@ properties:
>        - description: v2 of TSENS
>          items:
>            - enum:
> +              - qcom,msm8953-tsens
>                - qcom,msm8996-tsens
>                - qcom,msm8998-tsens
>                - qcom,sc7180-tsens
> --
> 2.34.1
>

Re: [PATCH 05/15] dt-bindings: mmc: sdhci-msm: Add msm8953 compatible

[Ulf Hansson]

On Wed, 12 Jan 2022 at 20:42, Luca Weiss <luca@z3ntu.xyz> wrote:
>
> Add msm8953 SoC specific compatible strings for qcom-sdhci controller.
>
> Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
> Acked-by: Konrad Dybcio <konrad.dybcio@somainline.org>

Applied for next, thanks!

Kind regards
Uffe


> ---
>  Documentation/devicetree/bindings/mmc/sdhci-msm.txt | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
> index 50841e2843fc..a62eaade5d97 100644
> --- a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
> +++ b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
> @@ -14,6 +14,7 @@ Required properties:
>         full compatible strings with SoC and version:
>                 "qcom,apq8084-sdhci", "qcom,sdhci-msm-v4"
>                 "qcom,msm8226-sdhci", "qcom,sdhci-msm-v4"
> +               "qcom,msm8953-sdhci", "qcom,sdhci-msm-v4"
>                 "qcom,msm8974-sdhci", "qcom,sdhci-msm-v4"
>                 "qcom,msm8916-sdhci", "qcom,sdhci-msm-v4"
>                 "qcom,msm8992-sdhci", "qcom,sdhci-msm-v4"
> --
> 2.34.1
>

Re: [PATCH 01/15] dt-bindings: phy: qcom,qusb2: Document msm8953 compatible

[Vinod Koul]

On 12-01-22, 20:40, Luca Weiss wrote:
> Document the compatible string used for the qusb2 phy in msm8953.

Applied, thanks

-- 
~Vinod

Re: [PATCH 02/15] phy: qcom-qusb2: Add compatible for MSM8953

[Vinod Koul]

On 12-01-22, 20:40, Luca Weiss wrote:
> Add compatible for MSM8953 QUSB2 device which reuses MSM8996
> configuration.

Applied, thanks

-- 
~Vinod

Re: [PATCH 09/15] rpmsg: smd: Drop unnecessary condition for channel creation

[Bjorn Andersson]

On Sun 16 Jan 10:30 CST 2022, Stephan Gerhold wrote:

> On Sun, Jan 16, 2022 at 05:08:29PM +0100, Luca Weiss wrote:
> > On Mittwoch, 12. Jänner 2022 22:39:53 CET Stephan Gerhold wrote:
> > > On Wed, Jan 12, 2022 at 08:40:58PM +0100, Luca Weiss wrote:
> > > > From: Vladimir Lypak <vladimir.lypak@gmail.com>
> > > > 
> > > > RPM Firmware on variety of newer SoCs such as MSM8917 (also likely
> > > > MSM8937, MSM8940, MSM8952), MSM8953 and on some MSM8916 devices) doesn't
> > > > initiate opening of the SMD channel if it was previously opened by
> > > > bootloader. This doesn't allow probing of smd-rpm driver on such devices
> > > > because there is a check that requires RPM this behaviour.
> > > > 
> > > > Signed-off-by: Vladimir Lypak <vladimir.lypak@gmail.com>
> > > > Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
> > > > Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org>
> > > 
> > > This is effectively a "Revert "Revert "rpmsg: smd: Create device for all
> > > channels""":
> > > 
> > > https://lore.kernel.org/linux-arm-msm/20171212235857.10432-3-bjorn.andersson
> > > @linaro.org/
> > > https://lore.kernel.org/linux-arm-msm/20180315181244.8859-1-bjorn.andersson
> > > @linaro.org/
> > > 
> > > Won't this cause the same regression reported by Srinivas again?
> > > 
> > 
> > Do you have any suggestion on another way to solve this? Without this commit 
> > the regulators just won't probe at all, I haven't looked very deep into it 
> > though given this patch solves it.
> > 
> > I guess worst case it'll become a devicetree property to enable this quirk?
> > 
> 
> My spontaneous suggestion would be to skip the check only for the
> "rpm_requests" channel, e.g. something like
> 
> 	if (remote_state != SMD_CHANNEL_OPENING &&
> 	    remote_state != SMD_CHANNEL_OPENED &&
> 	    strcmp(channel->name, "rpm_requests")
> 		continue;
> 
> This will avoid changing the behavior for anything but the RPM channel.
> I don't think anything else is affected by the same problem (since the
> bootloader or earlier firmware should not make use of any other channel).
> Also, we definitely *always* want to open the channel to the RPM because
> otherwise almost everything breaks.
> 

Last time this came up I asked if someone could test if the RPM is stuck
in the state machine trying to close the channel and as such we could
kick it by making sure that we "ack" the closing of the channel and
hence it would come back up again.

But I don't remember seeing any outcome of this.

> Many solutions are possible though so at the end it is mostly up to
> Bjorn to decide I think. :)
> 

I would prefer to get an answer to above question, but if that doesn't
work (or look like crap) I'm willing to take your suggestion of skipping
the continue for the rpm_requests channel. Obviously with a comment
above describing why we're carrying that special case.

Regards,
Bjorn

Re: [PATCH 09/15] rpmsg: smd: Drop unnecessary condition for channel creation

[Bjorn Andersson]

On Wed 12 Jan 13:40 CST 2022, Luca Weiss wrote:

> From: Vladimir Lypak <vladimir.lypak@gmail.com>
> 
> RPM Firmware on variety of newer SoCs such as MSM8917 (also likely
> MSM8937, MSM8940, MSM8952), MSM8953 and on some MSM8916 devices) doesn't
> initiate opening of the SMD channel if it was previously opened by
> bootloader. This doesn't allow probing of smd-rpm driver on such devices
> because there is a check that requires RPM this behaviour.
> 
> Signed-off-by: Vladimir Lypak <vladimir.lypak@gmail.com>
> Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org>
> ---
>  drivers/rpmsg/qcom_smd.c | 8 +-------
>  1 file changed, 1 insertion(+), 7 deletions(-)
> 
> diff --git a/drivers/rpmsg/qcom_smd.c b/drivers/rpmsg/qcom_smd.c
> index 8da1b5cb31b3..6a01ef932b01 100644
> --- a/drivers/rpmsg/qcom_smd.c
> +++ b/drivers/rpmsg/qcom_smd.c
> @@ -1280,19 +1280,13 @@ static void qcom_channel_state_worker(struct work_struct *work)
>  	unsigned long flags;
>  
>  	/*
> -	 * Register a device for any closed channel where the remote processor
> -	 * is showing interest in opening the channel.
> +	 * Register a device for any closed channel.
>  	 */
>  	spin_lock_irqsave(&edge->channels_lock, flags);
>  	list_for_each_entry(channel, &edge->channels, list) {
>  		if (channel->state != SMD_CHANNEL_CLOSED)
>  			continue;
>  
> -		remote_state = GET_RX_CHANNEL_INFO(channel, state);
> -		if (remote_state != SMD_CHANNEL_OPENING &&
> -		    remote_state != SMD_CHANNEL_OPENED)
> -			continue;

The second time you boot the modem (e.g. after a firmware crash), we
will find a whole bunch of channels here and attempt to open them in
order, but the modem will refuse to open most of them until the IPCRTR
channel has been opened and we have done the rmtfs dance - at which time
we have timed out opening a bunch of channels and things are in a broken
state.

As such, this has been proven to not work :(

Regards,
Bjorn

> -
>  		if (channel->registered)
>  			continue;
>  
> -- 
> 2.34.1
> 

Re: [PATCH 13/15] arm64: dts: qcom: Add MSM8953+PM8953 device tree

[Bjorn Andersson]

On Wed 12 Jan 13:41 CST 2022, Luca Weiss wrote:

> From: Vladimir Lypak <vladimir.lypak@gmail.com>
> 
> The combination MSM8953 + PM8953 is commonly used, so add a
> device tree where common power supplies etc. can be configured.
> 
> Signed-off-by: Vladimir Lypak <vladimir.lypak@gmail.com>
> Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org>

I would prefer if we stick with the current scheme and just push this
into the device dts (or possibly some vendor-common dtsi if that's
applicable).

Simply just to follow what we do on other platforms.


PS. I see some patches has been applied, but as you resubmit this
series please split it per maintainer to make it obvious to each
maintainer that they should pick their part(s).

Thanks,
Bjorn

> ---
>  arch/arm64/boot/dts/qcom/msm8953-pm8953.dtsi | 50 ++++++++++++++++++++
>  1 file changed, 50 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/qcom/msm8953-pm8953.dtsi
> 
> diff --git a/arch/arm64/boot/dts/qcom/msm8953-pm8953.dtsi b/arch/arm64/boot/dts/qcom/msm8953-pm8953.dtsi
> new file mode 100644
> index 000000000000..b5f20fc9488e
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/msm8953-pm8953.dtsi
> @@ -0,0 +1,50 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/* Copyright (c) 2022, The Linux Foundation. All rights reserved. */
> +
> +#include "msm8953.dtsi"
> +#include "pm8953.dtsi"
> +
> +&hsusb_phy {
> +	vdd-supply = <&pm8953_l3>;
> +	vdda-pll-supply = <&pm8953_l7>;
> +	vdda-phy-dpdm-supply = <&pm8953_l13>;
> +};
> +
> +&sdhc_1 {
> +	vmmc-supply = <&pm8953_l8>;
> +	vqmmc-supply = <&pm8953_l5>;
> +};
> +
> +&sdhc_2 {
> +	vmmc-supply = <&pm8953_l11>;
> +	vqmmc-supply = <&pm8953_l12>;
> +};
> +
> +&rpm_requests {
> +	smd_rpm_regulators: pm8953-regulators {
> +		compatible = "qcom,rpm-pm8953-regulators";
> +
> +		pm8953_s1: s1 {};
> +		pm8953_s3: s3 {};
> +		pm8953_s4: s4 {};
> +
> +		pm8953_l1: l1 {};
> +		pm8953_l2: l2 {};
> +		pm8953_l3: l3 {};
> +		pm8953_l5: l5 {};
> +		pm8953_l6: l6 {};
> +		pm8953_l7: l7 {};
> +		pm8953_l8: l8 {};
> +		pm8953_l9: l9 {};
> +		pm8953_l10: l10 {};
> +		pm8953_l11: l11 {};
> +		pm8953_l12: l12 {};
> +		pm8953_l13: l13 {};
> +		pm8953_l15: l15 {};
> +		pm8953_l16: l16 {};
> +		pm8953_l17: l17 {};
> +		pm8953_l19: l19 {};
> +		pm8953_l22: l22 {};
> +		pm8953_l23: l23 {};
> +	};
> +};
> -- 
> 2.34.1
> 

Re: [PATCH 09/15] rpmsg: smd: Drop unnecessary condition for channel creation

[Luca Weiss]

Hi Bjorn,

On Montag, 31. Jänner 2022 23:32:42 CET Bjorn Andersson wrote:
> On Sun 16 Jan 10:30 CST 2022, Stephan Gerhold wrote:
> > On Sun, Jan 16, 2022 at 05:08:29PM +0100, Luca Weiss wrote:
> > > On Mittwoch, 12. Jänner 2022 22:39:53 CET Stephan Gerhold wrote:
> > > > On Wed, Jan 12, 2022 at 08:40:58PM +0100, Luca Weiss wrote:
> > > > > From: Vladimir Lypak <vladimir.lypak@gmail.com>
> > > > > 
> > > > > RPM Firmware on variety of newer SoCs such as MSM8917 (also likely
> > > > > MSM8937, MSM8940, MSM8952), MSM8953 and on some MSM8916 devices)
> > > > > doesn't
> > > > > initiate opening of the SMD channel if it was previously opened by
> > > > > bootloader. This doesn't allow probing of smd-rpm driver on such
> > > > > devices
> > > > > because there is a check that requires RPM this behaviour.
> > > > > 
> > > > > Signed-off-by: Vladimir Lypak <vladimir.lypak@gmail.com>
> > > > > Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
> > > > > Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org>
> > > > 
> > > > This is effectively a "Revert "Revert "rpmsg: smd: Create device for
> > > > all
> > > > channels""":
> > > > 
> > > > https://lore.kernel.org/linux-arm-msm/20171212235857.10432-3-bjorn.and
> > > > ersson @linaro.org/
> > > > https://lore.kernel.org/linux-arm-msm/20180315181244.8859-1-bjorn.ande
> > > > rsson
> > > > @linaro.org/
> > > > 
> > > > Won't this cause the same regression reported by Srinivas again?
> > > 
> > > Do you have any suggestion on another way to solve this? Without this
> > > commit the regulators just won't probe at all, I haven't looked very
> > > deep into it though given this patch solves it.
> > > 
> > > I guess worst case it'll become a devicetree property to enable this
> > > quirk?
> > 
> > My spontaneous suggestion would be to skip the check only for the
> > "rpm_requests" channel, e.g. something like
> > 
> > 	if (remote_state != SMD_CHANNEL_OPENING &&
> > 	
> > 	    remote_state != SMD_CHANNEL_OPENED &&
> > 	    strcmp(channel->name, "rpm_requests")
> > 		
> > 		continue;
> > 
> > This will avoid changing the behavior for anything but the RPM channel.
> > I don't think anything else is affected by the same problem (since the
> > bootloader or earlier firmware should not make use of any other channel).
> > Also, we definitely *always* want to open the channel to the RPM because
> > otherwise almost everything breaks.
> 
> Last time this came up I asked if someone could test if the RPM is stuck
> in the state machine trying to close the channel and as such we could
> kick it by making sure that we "ack" the closing of the channel and
> hence it would come back up again.
> 
> But I don't remember seeing any outcome of this.

Do you have a link to this or should I go digging in the archives?

Regards
Luca

> 
> > Many solutions are possible though so at the end it is mostly up to
> > Bjorn to decide I think. :)
> 
> I would prefer to get an answer to above question, but if that doesn't
> work (or look like crap) I'm willing to take your suggestion of skipping
> the continue for the rpm_requests channel. Obviously with a comment
> above describing why we're carrying that special case.
> 
> Regards,
> Bjorn

Re: [PATCH 11/15] arm64: dts: qcom: Add PM8953 PMIC

[rayyan]

On 2022-01-12 19:41, Luca Weiss wrote:
> From: Vladimir Lypak <vladimir.lypak@gmail.com>
> 
> Add a base DT for PM8953 PMIC, commonly used with MSM8953.
> 
> Signed-off-by: Vladimir Lypak <vladimir.lypak@gmail.com>
> Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org>
> ---
>  arch/arm64/boot/dts/qcom/pm8953.dtsi | 90 ++++++++++++++++++++++++++++
>  1 file changed, 90 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/qcom/pm8953.dtsi
> 
> diff --git a/arch/arm64/boot/dts/qcom/pm8953.dtsi
> b/arch/arm64/boot/dts/qcom/pm8953.dtsi
> new file mode 100644
> index 000000000000..102555b3f313
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/pm8953.dtsi
> @@ -0,0 +1,90 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/* Copyright (c) 2022, The Linux Foundation. All rights reserved. */
> +
> +#include <dt-bindings/iio/qcom,spmi-vadc.h>
> +#include <dt-bindings/interrupt-controller/irq.h>
> +#include <dt-bindings/input/linux-event-codes.h>
> +#include <dt-bindings/spmi/spmi.h>
> +
> +&spmi_bus {
> +	pmic@0 {
> +		compatible = "qcom,pm8953", "qcom,spmi-pmic";
> +		reg = <0 SPMI_USID>;
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		rtc@6000 {
> +			compatible = "qcom,pm8941-rtc";
> +			reg = <0x6000>, <0x6100>;
> +			reg-names = "rtc", "alarm";
> +			interrupts = <0x0 0x61 0x1 IRQ_TYPE_EDGE_RISING>;
> +		};
> +
> +		pm8953_pon: pon@800 {
> +			compatible = "qcom,pm8916-pon";
> +			reg = <0x800>;
> +			mode-bootloader = <0x2>;
> +			mode-recovery = <0x1>;
> +
> +			pwrkey {
> +				compatible = "qcom,pm8941-pwrkey";
> +				interrupts = <0x00 0x08 0 IRQ_TYPE_EDGE_BOTH>;
> +				debounce = <15625>;
> +				bias-pull-up;
> +				linux,code = <KEY_POWER>;
> +			};
> +
> +			pm8953_resin: resin {
> +				compatible = "qcom,pm8941-resin";
> +				interrupts = <0x00 0x08 1 IRQ_TYPE_EDGE_BOTH>;
> +				debounce = <15625>;
> +				bias-pull-up;
> +				status = "disabled";
> +			};
> +		};
> +
> +		temp-alarm@2400 {
> +			compatible = "qcom,spmi-temp-alarm";
> +			reg = <0x2400>;
> +			interrupts = <0x0 0x24 0x0 IRQ_TYPE_EDGE_RISING>;
> +			io-channels = <&pm8953_vadc 0x08>;
> +			io-channel-names = "thermal";
> +			#thermal-sensor-cells = <0x00>;
> +		};
> +
> +		pm8953_vadc: vadc@3100 {
> +			compatible = "qcom,spmi-vadc";
> +			reg = <0x3100>;
> +			interrupts = <0x00 0x31 0x00 0x01>;
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			#io-channel-cells = <1>;
> +
> +			die_temp@8 {
> +				reg = <VADC_DIE_TEMP>;
> +			};
> +			ref_625mv@9 {
> +				reg = <VADC_REF_625MV>;
> +			};
> +			ref_1250v@a {
> +				reg = <VADC_REF_1250MV>;
> +			};
> +			ref_buf_625mv@c {
> +				reg = <VADC_SPARE1>;
> +			};
> +			ref_gnd@e {
> +				reg = <VADC_GND_REF>;
> +			};
> +			ref_vdd@f {
> +				reg = <VADC_VDD_VADC>;
> +			};

Could you use the generic names for each VADC channel as recommended in 
qcom,spmi-vadc.yaml?

> +		};
> +	};
> +
> +	pmic@1 {
> +		compatible = "qcom,pm8953", "qcom,spmi-pmic";
> +		reg = <1 SPMI_USID>;
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +	};
> +};

Re: [PATCH 03/15] dt-bindings: mfd: qcom,tcsr: Document msm8953 compatible

[Rob Herring]

On Wed, 12 Jan 2022 20:40:52 +0100, Luca Weiss wrote:
> Document the compatible for tcsr found in msm8953.
> 
> Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
> Acked-by: Konrad Dybcio <konrad.dybcio@somainline.org>
> ---
>  Documentation/devicetree/bindings/mfd/qcom,tcsr.txt | 1 +
>  1 file changed, 1 insertion(+)
> 

Acked-by: Rob Herring <robh@kernel.org>

Re: [PATCH 04/15] mfd: qcom-spmi-pmic: Add pm8953 compatible

[Rob Herring]

On Wed, 12 Jan 2022 20:40:53 +0100, Luca Weiss wrote:
> Document the compatible for pm8953 as found in msm8953.
> 
> Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
> Acked-by: Konrad Dybcio <konrad.dybcio@somainline.org>
> ---
>  Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt | 1 +
>  1 file changed, 1 insertion(+)
> 

Acked-by: Rob Herring <robh@kernel.org>

Re: [PATCH 06/15] dt-bindings: thermal: tsens: Add msm8953 compatible

[Rob Herring]

On Wed, 12 Jan 2022 20:40:55 +0100, Luca Weiss wrote:
> Document the compatible string for tsens found in msm8953.
> 
> Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
> Acked-by: Konrad Dybcio <konrad.dybcio@somainline.org>
> ---
>  Documentation/devicetree/bindings/thermal/qcom-tsens.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 

Acked-by: Rob Herring <robh@kernel.org>

Re: [PATCH 07/15] dt-bindings: usb: qcom,dwc3: Add msm8953 compatible

[Rob Herring]

On Wed, 12 Jan 2022 20:40:56 +0100, Luca Weiss wrote:
> Document the compatible string for the DWC3 controller in msm8953.
> 
> Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
> Acked-by: Konrad Dybcio <konrad.dybcio@somainline.org>
> ---
>  Documentation/devicetree/bindings/usb/qcom,dwc3.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 

Acked-by: Rob Herring <robh@kernel.org>

Re: [PATCH 08/15] dt-bindings: pinctrl: qcom: msm8953: allow gpio-reserved-ranges

[Rob Herring]

On Wed, 12 Jan 2022 20:40:57 +0100, Luca Weiss wrote:
> Allow the gpio-reserved-ranges property to be used in dts.
> 
> Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
> Acked-by: Konrad Dybcio <konrad.dybcio@somainline.org>
> ---
>  .../devicetree/bindings/pinctrl/qcom,msm8953-pinctrl.yaml       | 2 ++
>  1 file changed, 2 insertions(+)
> 

Acked-by: Rob Herring <robh@kernel.org>

Re: [PATCH 14/15] dt-bindings: arm: qcom: Document sdm632 and fairphone,fp3 board

[Rob Herring]

On Wed, 12 Jan 2022 20:41:03 +0100, Luca Weiss wrote:
> Add binding documentation for Fairphone 3 smartphone which is based on
> Snapdragon 632 (sm632).
> 
> Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
> ---
>  Documentation/devicetree/bindings/arm/qcom.yaml | 6 ++++++
>  1 file changed, 6 insertions(+)
> 

Acked-by: Rob Herring <robh@kernel.org>

Re: [PATCH 11/15] arm64: dts: qcom: Add PM8953 PMIC

[Rayyan Ansari]

On 2022-01-12 19:41, Luca Weiss wrote:
> From: Vladimir Lypak <vladimir.lypak@gmail.com>
> 
> Add a base DT for PM8953 PMIC, commonly used with MSM8953.
> 
> Signed-off-by: Vladimir Lypak <vladimir.lypak@gmail.com>
> Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org>
> ---
>  arch/arm64/boot/dts/qcom/pm8953.dtsi | 90 ++++++++++++++++++++++++++++
>  1 file changed, 90 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/qcom/pm8953.dtsi
> 
> diff --git a/arch/arm64/boot/dts/qcom/pm8953.dtsi
> b/arch/arm64/boot/dts/qcom/pm8953.dtsi
> new file mode 100644
> index 000000000000..102555b3f313
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/pm8953.dtsi
> @@ -0,0 +1,90 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/* Copyright (c) 2022, The Linux Foundation. All rights reserved. */
> +
> +#include <dt-bindings/iio/qcom,spmi-vadc.h>
> +#include <dt-bindings/interrupt-controller/irq.h>
> +#include <dt-bindings/input/linux-event-codes.h>
> +#include <dt-bindings/spmi/spmi.h>
> +
> +&spmi_bus {
> +	pmic@0 {
> +		compatible = "qcom,pm8953", "qcom,spmi-pmic";
> +		reg = <0 SPMI_USID>;
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		rtc@6000 {
> +			compatible = "qcom,pm8941-rtc";
> +			reg = <0x6000>, <0x6100>;
> +			reg-names = "rtc", "alarm";
> +			interrupts = <0x0 0x61 0x1 IRQ_TYPE_EDGE_RISING>;
> +		};

Could you sort the nodes by order? The rtc@6000 node should be after 
vadc@3100.

> +
> +		pm8953_pon: pon@800 {
> +			compatible = "qcom,pm8916-pon";
> +			reg = <0x800>;
> +			mode-bootloader = <0x2>;
> +			mode-recovery = <0x1>;
> +
> +			pwrkey {
> +				compatible = "qcom,pm8941-pwrkey";
> +				interrupts = <0x00 0x08 0 IRQ_TYPE_EDGE_BOTH>;
> +				debounce = <15625>;
> +				bias-pull-up;
> +				linux,code = <KEY_POWER>;
> +			};
> +
> +			pm8953_resin: resin {
> +				compatible = "qcom,pm8941-resin";
> +				interrupts = <0x00 0x08 1 IRQ_TYPE_EDGE_BOTH>;
> +				debounce = <15625>;
> +				bias-pull-up;
> +				status = "disabled";
> +			};
> +		};
> +
> +		temp-alarm@2400 {
> +			compatible = "qcom,spmi-temp-alarm";
> +			reg = <0x2400>;
> +			interrupts = <0x0 0x24 0x0 IRQ_TYPE_EDGE_RISING>;
> +			io-channels = <&pm8953_vadc 0x08>;

Could you use VADC_DIE_TEMP here instead of 0x08 like in 
qcom-spmi-temp-alarm.txt?

> +			io-channel-names = "thermal";
> +			#thermal-sensor-cells = <0x00>;

This should be "#thermal-sensor-cells = <0>;" as recommended by docs.

> +		};
> +
> +		pm8953_vadc: vadc@3100 {
> +			compatible = "qcom,spmi-vadc";
> +			reg = <0x3100>;
> +			interrupts = <0x00 0x31 0x00 0x01>;
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +			#io-channel-cells = <1>;
> +
> +			die_temp@8 {
> +				reg = <VADC_DIE_TEMP>;
> +			};
> +			ref_625mv@9 {
> +				reg = <VADC_REF_625MV>;
> +			};
> +			ref_1250v@a {
> +				reg = <VADC_REF_1250MV>;
> +			};
> +			ref_buf_625mv@c {
> +				reg = <VADC_SPARE1>;
> +			};
> +			ref_gnd@e {
> +				reg = <VADC_GND_REF>;
> +			};
> +			ref_vdd@f {
> +				reg = <VADC_VDD_VADC>;
> +			};

Could you use the generic names for each VADC channel as recommended in 
qcom,spmi-vadc.yaml?

> +		};
> +	};
> +
> +	pmic@1 {
> +		compatible = "qcom,pm8953", "qcom,spmi-pmic";
> +		reg = <1 SPMI_USID>;
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +	};
> +};

With this sorted, add my Reviewed-by.

Reviewed-by: Rayyan Ansari <rayyan@ansari.sh>

Re: [PATCH 08/15] dt-bindings: pinctrl: qcom: msm8953: allow gpio-reserved-ranges

[Linus Walleij]

On Wed, Jan 12, 2022 at 8:42 PM Luca Weiss <luca@z3ntu.xyz> wrote:

> Allow the gpio-reserved-ranges property to be used in dts.
>
> Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
> Acked-by: Konrad Dybcio <konrad.dybcio@somainline.org>

This patch applied to the pinctrl tree.

Yours,
Linus Walleij

Re: [PATCH 13/15] arm64: dts: qcom: Add MSM8953+PM8953 device tree

[Luca Weiss]

Hi Bjorn,

On Montag, 31. Jänner 2022 23:39:06 CET Bjorn Andersson wrote:
> On Wed 12 Jan 13:41 CST 2022, Luca Weiss wrote:
> > From: Vladimir Lypak <vladimir.lypak@gmail.com>
> > 
> > The combination MSM8953 + PM8953 is commonly used, so add a
> > device tree where common power supplies etc. can be configured.
> > 
> > Signed-off-by: Vladimir Lypak <vladimir.lypak@gmail.com>
> > Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
> > Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org>
> 
> I would prefer if we stick with the current scheme and just push this
> into the device dts (or possibly some vendor-common dtsi if that's
> applicable).
> 
> Simply just to follow what we do on other platforms.

Sure, will do in v2.

> 
> 
> PS. I see some patches has been applied, but as you resubmit this
> series please split it per maintainer to make it obvious to each
> maintainer that they should pick their part(s).

What do you mean by this? Send one series per maintainer? Or something else? 

Currently when making the patches I don't really "care" about who maintains 
what, my git send-email setup picks the relevant people for CC.

Sometimes there's also multiple maintainers/trees listed for one file, not sure 
what to do there... 

Regards
Luca

> 
> Thanks,
> Bjorn
> 
> > ---
> > 
> >  arch/arm64/boot/dts/qcom/msm8953-pm8953.dtsi | 50 ++++++++++++++++++++
> >  1 file changed, 50 insertions(+)
> >  create mode 100644 arch/arm64/boot/dts/qcom/msm8953-pm8953.dtsi
> > 
> > diff --git a/arch/arm64/boot/dts/qcom/msm8953-pm8953.dtsi
> > b/arch/arm64/boot/dts/qcom/msm8953-pm8953.dtsi new file mode 100644
> > index 000000000000..b5f20fc9488e
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/qcom/msm8953-pm8953.dtsi
> > @@ -0,0 +1,50 @@
> > +// SPDX-License-Identifier: BSD-3-Clause
> > +/* Copyright (c) 2022, The Linux Foundation. All rights reserved. */
> > +
> > +#include "msm8953.dtsi"
> > +#include "pm8953.dtsi"
> > +
> > +&hsusb_phy {
> > +	vdd-supply = <&pm8953_l3>;
> > +	vdda-pll-supply = <&pm8953_l7>;
> > +	vdda-phy-dpdm-supply = <&pm8953_l13>;
> > +};
> > +
> > +&sdhc_1 {
> > +	vmmc-supply = <&pm8953_l8>;
> > +	vqmmc-supply = <&pm8953_l5>;
> > +};
> > +
> > +&sdhc_2 {
> > +	vmmc-supply = <&pm8953_l11>;
> > +	vqmmc-supply = <&pm8953_l12>;
> > +};
> > +
> > +&rpm_requests {
> > +	smd_rpm_regulators: pm8953-regulators {
> > +		compatible = "qcom,rpm-pm8953-regulators";
> > +
> > +		pm8953_s1: s1 {};
> > +		pm8953_s3: s3 {};
> > +		pm8953_s4: s4 {};
> > +
> > +		pm8953_l1: l1 {};
> > +		pm8953_l2: l2 {};
> > +		pm8953_l3: l3 {};
> > +		pm8953_l5: l5 {};
> > +		pm8953_l6: l6 {};
> > +		pm8953_l7: l7 {};
> > +		pm8953_l8: l8 {};
> > +		pm8953_l9: l9 {};
> > +		pm8953_l10: l10 {};
> > +		pm8953_l11: l11 {};
> > +		pm8953_l12: l12 {};
> > +		pm8953_l13: l13 {};
> > +		pm8953_l15: l15 {};
> > +		pm8953_l16: l16 {};
> > +		pm8953_l17: l17 {};
> > +		pm8953_l19: l19 {};
> > +		pm8953_l22: l22 {};
> > +		pm8953_l23: l23 {};
> > +	};
> > +};

Re: [PATCH 09/15] rpmsg: smd: Drop unnecessary condition for channel creation

[Luca Weiss]

Hi Bjorn,

On Sonntag, 6. Februar 2022 21:17:22 CET Luca Weiss wrote:
> Hi Bjorn,
> 
> On Montag, 31. Jänner 2022 23:32:42 CET Bjorn Andersson wrote:
> > On Sun 16 Jan 10:30 CST 2022, Stephan Gerhold wrote:
> > > On Sun, Jan 16, 2022 at 05:08:29PM +0100, Luca Weiss wrote:
> > > > On Mittwoch, 12. Jänner 2022 22:39:53 CET Stephan Gerhold wrote:
> > > > > On Wed, Jan 12, 2022 at 08:40:58PM +0100, Luca Weiss wrote:
> > > > > > From: Vladimir Lypak <vladimir.lypak@gmail.com>
> > > > > > 
> > > > > > RPM Firmware on variety of newer SoCs such as MSM8917 (also likely
> > > > > > MSM8937, MSM8940, MSM8952), MSM8953 and on some MSM8916 devices)
> > > > > > doesn't
> > > > > > initiate opening of the SMD channel if it was previously opened by
> > > > > > bootloader. This doesn't allow probing of smd-rpm driver on such
> > > > > > devices
> > > > > > because there is a check that requires RPM this behaviour.
> > > > > > 
> > > > > > Signed-off-by: Vladimir Lypak <vladimir.lypak@gmail.com>
> > > > > > Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
> > > > > > Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org>
> > > > > 
> > > > > This is effectively a "Revert "Revert "rpmsg: smd: Create device for
> > > > > all
> > > > > channels""":
> > > > > 
> > > > > https://lore.kernel.org/linux-arm-msm/20171212235857.10432-3-bjorn.a
> > > > > nd
> > > > > ersson @linaro.org/
> > > > > https://lore.kernel.org/linux-arm-msm/20180315181244.8859-1-bjorn.an
> > > > > de
> > > > > rsson
> > > > > @linaro.org/
> > > > > 
> > > > > Won't this cause the same regression reported by Srinivas again?
> > > > 
> > > > Do you have any suggestion on another way to solve this? Without this
> > > > commit the regulators just won't probe at all, I haven't looked very
> > > > deep into it though given this patch solves it.
> > > > 
> > > > I guess worst case it'll become a devicetree property to enable this
> > > > quirk?
> > > 
> > > My spontaneous suggestion would be to skip the check only for the
> > > "rpm_requests" channel, e.g. something like
> > > 
> > > 	if (remote_state != SMD_CHANNEL_OPENING &&
> > > 	
> > > 	    remote_state != SMD_CHANNEL_OPENED &&
> > > 	    strcmp(channel->name, "rpm_requests")
> > > 		
> > > 		continue;
> > > 
> > > This will avoid changing the behavior for anything but the RPM channel.
> > > I don't think anything else is affected by the same problem (since the
> > > bootloader or earlier firmware should not make use of any other
> > > channel).
> > > Also, we definitely *always* want to open the channel to the RPM because
> > > otherwise almost everything breaks.
> > 
> > Last time this came up I asked if someone could test if the RPM is stuck
> > in the state machine trying to close the channel and as such we could
> > kick it by making sure that we "ack" the closing of the channel and
> > hence it would come back up again.
> > 
> > But I don't remember seeing any outcome of this.
> 
> Do you have a link to this or should I go digging in the archives?

Replying to myself, I went searching but couldn't find anything. If you have 
some PoC code I'd be happy to try but as I'm not familiar with rpm/smd at all 
I'd have to read myself into it first.

If Stephans suggestion with the strcmp(channel->name, "rpm_requests") is ok 
then I'd test this and use that in v2. I'd personally rather not spend too 
much time on this issue right now as it's blocking msm8953 completely (no 
regulators = no nothing),

Regards
Luca

> 
> Regards
> Luca
> 
> > > Many solutions are possible though so at the end it is mostly up to
> > > Bjorn to decide I think. :)
> > 
> > I would prefer to get an answer to above question, but if that doesn't
> > work (or look like crap) I'm willing to take your suggestion of skipping
> > the continue for the rpm_requests channel. Obviously with a comment
> > above describing why we're carrying that special case.
> > 
> > Regards,
> > Bjorn

Re: [PATCH 13/15] arm64: dts: qcom: Add MSM8953+PM8953 device tree

[Bjorn Andersson]

On Sun 13 Feb 12:25 PST 2022, Luca Weiss wrote:

> Hi Bjorn,
> 
> On Montag, 31. Jänner 2022 23:39:06 CET Bjorn Andersson wrote:
> > On Wed 12 Jan 13:41 CST 2022, Luca Weiss wrote:
> > > From: Vladimir Lypak <vladimir.lypak@gmail.com>
> > > 
> > > The combination MSM8953 + PM8953 is commonly used, so add a
> > > device tree where common power supplies etc. can be configured.
> > > 
> > > Signed-off-by: Vladimir Lypak <vladimir.lypak@gmail.com>
> > > Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
> > > Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org>
> > 
> > I would prefer if we stick with the current scheme and just push this
> > into the device dts (or possibly some vendor-common dtsi if that's
> > applicable).
> > 
> > Simply just to follow what we do on other platforms.
> 
> Sure, will do in v2.
> 
> > 
> > 
> > PS. I see some patches has been applied, but as you resubmit this
> > series please split it per maintainer to make it obvious to each
> > maintainer that they should pick their part(s).
> 
> What do you mean by this? Send one series per maintainer? Or something else? 
> 

Yes, that's what I'm suggesting.

> Currently when making the patches I don't really "care" about who maintains 
> what, my git send-email setup picks the relevant people for CC.
> 

You technically don't have to care, but as it's not always obvious to a
maintainer if he/she can take the patches destined for their subsystem
it's easy that things ends up sitting on the list for longer than
necessary.

So you're making yourself a favour of splitting things that aren't
dependent as you send it out.

> Sometimes there's also multiple maintainers/trees listed for one file, not sure 
> what to do there... 
> 

Your current approach works, above is just a suggestion of how to make
it easier for the maintainers, which will help you to get your patches
land faster.

Regards,
Bjorn

> Regards
> Luca
> 
> > 
> > Thanks,
> > Bjorn
> > 
> > > ---
> > > 
> > >  arch/arm64/boot/dts/qcom/msm8953-pm8953.dtsi | 50 ++++++++++++++++++++
> > >  1 file changed, 50 insertions(+)
> > >  create mode 100644 arch/arm64/boot/dts/qcom/msm8953-pm8953.dtsi
> > > 
> > > diff --git a/arch/arm64/boot/dts/qcom/msm8953-pm8953.dtsi
> > > b/arch/arm64/boot/dts/qcom/msm8953-pm8953.dtsi new file mode 100644
> > > index 000000000000..b5f20fc9488e
> > > --- /dev/null
> > > +++ b/arch/arm64/boot/dts/qcom/msm8953-pm8953.dtsi
> > > @@ -0,0 +1,50 @@
> > > +// SPDX-License-Identifier: BSD-3-Clause
> > > +/* Copyright (c) 2022, The Linux Foundation. All rights reserved. */
> > > +
> > > +#include "msm8953.dtsi"
> > > +#include "pm8953.dtsi"
> > > +
> > > +&hsusb_phy {
> > > +	vdd-supply = <&pm8953_l3>;
> > > +	vdda-pll-supply = <&pm8953_l7>;
> > > +	vdda-phy-dpdm-supply = <&pm8953_l13>;
> > > +};
> > > +
> > > +&sdhc_1 {
> > > +	vmmc-supply = <&pm8953_l8>;
> > > +	vqmmc-supply = <&pm8953_l5>;
> > > +};
> > > +
> > > +&sdhc_2 {
> > > +	vmmc-supply = <&pm8953_l11>;
> > > +	vqmmc-supply = <&pm8953_l12>;
> > > +};
> > > +
> > > +&rpm_requests {
> > > +	smd_rpm_regulators: pm8953-regulators {
> > > +		compatible = "qcom,rpm-pm8953-regulators";
> > > +
> > > +		pm8953_s1: s1 {};
> > > +		pm8953_s3: s3 {};
> > > +		pm8953_s4: s4 {};
> > > +
> > > +		pm8953_l1: l1 {};
> > > +		pm8953_l2: l2 {};
> > > +		pm8953_l3: l3 {};
> > > +		pm8953_l5: l5 {};
> > > +		pm8953_l6: l6 {};
> > > +		pm8953_l7: l7 {};
> > > +		pm8953_l8: l8 {};
> > > +		pm8953_l9: l9 {};
> > > +		pm8953_l10: l10 {};
> > > +		pm8953_l11: l11 {};
> > > +		pm8953_l12: l12 {};
> > > +		pm8953_l13: l13 {};
> > > +		pm8953_l15: l15 {};
> > > +		pm8953_l16: l16 {};
> > > +		pm8953_l17: l17 {};
> > > +		pm8953_l19: l19 {};
> > > +		pm8953_l22: l22 {};
> > > +		pm8953_l23: l23 {};
> > > +	};
> > > +};
> 
> 
> 
> 

Re: [PATCH 03/15] dt-bindings: mfd: qcom,tcsr: Document msm8953 compatible

[Lee Jones]

On Wed, 12 Jan 2022, Luca Weiss wrote:

> Document the compatible for tcsr found in msm8953.
> 
> Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
> Acked-by: Konrad Dybcio <konrad.dybcio@somainline.org>
> ---
>  Documentation/devicetree/bindings/mfd/qcom,tcsr.txt | 1 +
>  1 file changed, 1 insertion(+)

Doesn't seem to apply.

Could you please rebase.

> diff --git a/Documentation/devicetree/bindings/mfd/qcom,tcsr.txt b/Documentation/devicetree/bindings/mfd/qcom,tcsr.txt
> index c5f4f0ddfcc3..add61bcc3c74 100644
> --- a/Documentation/devicetree/bindings/mfd/qcom,tcsr.txt
> +++ b/Documentation/devicetree/bindings/mfd/qcom,tcsr.txt
> @@ -10,6 +10,7 @@ Required properties:
>  		"qcom,tcsr-ipq8064", "syscon" for IPQ8064
>  		"qcom,tcsr-apq8064", "syscon" for APQ8064
>  		"qcom,tcsr-msm8660", "syscon" for MSM8660
> +		"qcom,tcsr-msm8953", "syscon" for MSM8953
>  		"qcom,tcsr-msm8960", "syscon" for MSM8960
>  		"qcom,tcsr-msm8974", "syscon" for MSM8974
>  		"qcom,tcsr-apq8084", "syscon" for APQ8084

-- 
Lee Jones [李琼斯]
Principal Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH 04/15] mfd: qcom-spmi-pmic: Add pm8953 compatible

[Lee Jones]

On Wed, 12 Jan 2022, Luca Weiss wrote:

> Document the compatible for pm8953 as found in msm8953.
> 
> Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
> Acked-by: Konrad Dybcio <konrad.dybcio@somainline.org>
> ---
>  Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt | 1 +
>  1 file changed, 1 insertion(+)

Applied, thanks.

-- 
Lee Jones [李琼斯]
Principal Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH 09/15] rpmsg: smd: Drop unnecessary condition for channel creation

[Bjorn Andersson]

On Sun 13 Feb 14:51 CST 2022, Luca Weiss wrote:

> Hi Bjorn,
> 
> On Sonntag, 6. Februar 2022 21:17:22 CET Luca Weiss wrote:
> > Hi Bjorn,
> > 
> > On Montag, 31. Jänner 2022 23:32:42 CET Bjorn Andersson wrote:
> > > On Sun 16 Jan 10:30 CST 2022, Stephan Gerhold wrote:
> > > > On Sun, Jan 16, 2022 at 05:08:29PM +0100, Luca Weiss wrote:
> > > > > On Mittwoch, 12. Jänner 2022 22:39:53 CET Stephan Gerhold wrote:
> > > > > > On Wed, Jan 12, 2022 at 08:40:58PM +0100, Luca Weiss wrote:
> > > > > > > From: Vladimir Lypak <vladimir.lypak@gmail.com>
> > > > > > > 
> > > > > > > RPM Firmware on variety of newer SoCs such as MSM8917 (also likely
> > > > > > > MSM8937, MSM8940, MSM8952), MSM8953 and on some MSM8916 devices)
> > > > > > > doesn't
> > > > > > > initiate opening of the SMD channel if it was previously opened by
> > > > > > > bootloader. This doesn't allow probing of smd-rpm driver on such
> > > > > > > devices
> > > > > > > because there is a check that requires RPM this behaviour.
> > > > > > > 
> > > > > > > Signed-off-by: Vladimir Lypak <vladimir.lypak@gmail.com>
> > > > > > > Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
> > > > > > > Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org>
> > > > > > 
> > > > > > This is effectively a "Revert "Revert "rpmsg: smd: Create device for
> > > > > > all
> > > > > > channels""":
> > > > > > 
> > > > > > https://lore.kernel.org/linux-arm-msm/20171212235857.10432-3-bjorn.a
> > > > > > nd
> > > > > > ersson @linaro.org/
> > > > > > https://lore.kernel.org/linux-arm-msm/20180315181244.8859-1-bjorn.an
> > > > > > de
> > > > > > rsson
> > > > > > @linaro.org/
> > > > > > 
> > > > > > Won't this cause the same regression reported by Srinivas again?
> > > > > 
> > > > > Do you have any suggestion on another way to solve this? Without this
> > > > > commit the regulators just won't probe at all, I haven't looked very
> > > > > deep into it though given this patch solves it.
> > > > > 
> > > > > I guess worst case it'll become a devicetree property to enable this
> > > > > quirk?
> > > > 
> > > > My spontaneous suggestion would be to skip the check only for the
> > > > "rpm_requests" channel, e.g. something like
> > > > 
> > > > 	if (remote_state != SMD_CHANNEL_OPENING &&
> > > > 	
> > > > 	    remote_state != SMD_CHANNEL_OPENED &&
> > > > 	    strcmp(channel->name, "rpm_requests")
> > > > 		
> > > > 		continue;
> > > > 
> > > > This will avoid changing the behavior for anything but the RPM channel.
> > > > I don't think anything else is affected by the same problem (since the
> > > > bootloader or earlier firmware should not make use of any other
> > > > channel).
> > > > Also, we definitely *always* want to open the channel to the RPM because
> > > > otherwise almost everything breaks.
> > > 
> > > Last time this came up I asked if someone could test if the RPM is stuck
> > > in the state machine trying to close the channel and as such we could
> > > kick it by making sure that we "ack" the closing of the channel and
> > > hence it would come back up again.
> > > 
> > > But I don't remember seeing any outcome of this.
> > 
> > Do you have a link to this or should I go digging in the archives?
> 
> Replying to myself, I went searching but couldn't find anything. If you have 
> some PoC code I'd be happy to try but as I'm not familiar with rpm/smd at all 
> I'd have to read myself into it first.
> 

A quick search didn't turn anything up on my side either.

And while I had suggestions of what could be tried, I don't have any
devices myself that manifest this problem, so I haven't been able to
debug it.

> If Stephans suggestion with the strcmp(channel->name, "rpm_requests") is ok 
> then I'd test this and use that in v2. I'd personally rather not spend too 
> much time on this issue right now as it's blocking msm8953 completely (no 
> regulators = no nothing),
> 

It's been a long time since this problem was initially reported, so I
rather see us land the strcmp() hack to unblock you and others. Then
someone who knows SMD can take a proper look at this.

Regards,
Bjorn

> Regards
> Luca
> 
> > 
> > Regards
> > Luca
> > 
> > > > Many solutions are possible though so at the end it is mostly up to
> > > > Bjorn to decide I think. :)
> > > 
> > > I would prefer to get an answer to above question, but if that doesn't
> > > work (or look like crap) I'm willing to take your suggestion of skipping
> > > the continue for the rpm_requests channel. Obviously with a comment
> > > above describing why we're carrying that special case.
> > > 
> > > Regards,
> > > Bjorn
> 
> 
> 
> 

Re: [PATCH 12/15] arm64: dts: qcom: Add SDM632 device tree

[Bjorn Andersson]

On Wed 12 Jan 13:41 CST 2022, Luca Weiss wrote:

> From: Vladimir Lypak <vladimir.lypak@gmail.com>
> 
> Snapdragon 632 is based on msm8953, add the devicee tree for that.
> 

The commit message is a little bit thin on details about the change.

> Signed-off-by: Vladimir Lypak <vladimir.lypak@gmail.com>
> Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
> ---
>  arch/arm64/boot/dts/qcom/sdm632.dtsi | 125 +++++++++++++++++++++++++++
>  1 file changed, 125 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/qcom/sdm632.dtsi
> 
> diff --git a/arch/arm64/boot/dts/qcom/sdm632.dtsi b/arch/arm64/boot/dts/qcom/sdm632.dtsi
> new file mode 100644
> index 000000000000..b80ba8a5ef3f
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/sdm632.dtsi
> @@ -0,0 +1,125 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/* Copyright (c) 2022, The Linux Foundation. All rights reserved. */
> +
> +#include "msm8953.dtsi"
> +
> +/ {
> +	thermal-zones {
> +		/delete-node/cpu0-thermal;

Below you replace cpu[4-7]-thermal. What about cpu[0-3]-thermal? And I
would prefer the answer to be documented in the commit message.

Regards,
Bjorn

> +		/delete-node/cpu1-thermal;
> +		/delete-node/cpu2-thermal;
> +		/delete-node/cpu3-thermal;
> +		/delete-node/cpu4-thermal;
> +		/delete-node/cpu5-thermal;
> +		/delete-node/cpu6-thermal;
> +		/delete-node/cpu7-thermal;
> +		cpu4-thermal {
> +			polling-delay-passive = <250>;
> +			polling-delay = <1000>;
> +			thermal-sensors = <&tsens0 5>;
> +			trips {
> +				cpu4_alert: trip-point0 {
> +					temperature = <80000>;
> +					hysteresis = <2000>;
> +					type = "passive";
> +				};
> +				cpu4_crit: crit {
> +					temperature = <100000>;
> +					hysteresis = <2000>;
> +					type = "critical";
> +				};
> +			};
> +			cooling-maps {
> +				map0 {
> +					trip = <&cpu4_alert>;
> +					cooling-device = <&CPU4 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> +				};
> +			};
> +		};
> +		cpu5-thermal {
> +			polling-delay-passive = <250>;
> +			polling-delay = <1000>;
> +			thermal-sensors = <&tsens0 6>;
> +			trips {
> +				cpu5_alert: trip-point0 {
> +					temperature = <80000>;
> +					hysteresis = <2000>;
> +					type = "passive";
> +				};
> +				cpu5_crit: crit {
> +					temperature = <100000>;
> +					hysteresis = <2000>;
> +					type = "critical";
> +				};
> +			};
> +			cooling-maps {
> +				map0 {
> +					trip = <&cpu5_alert>;
> +					cooling-device = <&CPU5 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> +				};
> +			};
> +		};
> +		cpu6-thermal {
> +			polling-delay-passive = <250>;
> +			polling-delay = <1000>;
> +			thermal-sensors = <&tsens0 7>;
> +			trips {
> +				cpu6_alert: trip-point0 {
> +					temperature = <80000>;
> +					hysteresis = <2000>;
> +					type = "passive";
> +				};
> +				cpu6_crit: crit {
> +					temperature = <100000>;
> +					hysteresis = <2000>;
> +					type = "critical";
> +				};
> +			};
> +			cooling-maps {
> +				map0 {
> +					trip = <&cpu6_alert>;
> +					cooling-device = <&CPU6 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> +				};
> +			};
> +		};
> +		cpu7-thermal {
> +			polling-delay-passive = <250>;
> +			polling-delay = <1000>;
> +			thermal-sensors = <&tsens0 8>;
> +			trips {
> +				cpu7_alert: trip-point0 {
> +					temperature = <80000>;
> +					hysteresis = <2000>;
> +					type = "passive";
> +				};
> +				cpu7_crit: crit {
> +					temperature = <100000>;
> +					hysteresis = <2000>;
> +					type = "critical";
> +				};
> +			};
> +			cooling-maps {
> +				map0 {
> +					trip = <&cpu7_alert>;
> +					cooling-device = <&CPU7 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> +				};
> +			};
> +		};
> +	};
> +};
> +
> +&CPU4 {
> +	capacity-dmips-mhz = <1980>;
> +};
> +
> +&CPU5 {
> +	capacity-dmips-mhz = <1980>;
> +};
> +
> +&CPU6 {
> +	capacity-dmips-mhz = <1980>;
> +};
> +
> +&CPU7 {
> +	capacity-dmips-mhz = <1980>;
> +};
> -- 
> 2.34.1
> 

Re: [PATCH 10/15] arm64: dts: qcom: Add MSM8953 device tree

[Bjorn Andersson]

On Wed 12 Jan 13:40 CST 2022, Luca Weiss wrote:

> From: Vladimir Lypak <vladimir.lypak@gmail.com>
> 
> Add a base DT for MSM8953 SoC.
> 
> Co-developed-by: Luca Weiss <luca@z3ntu.xyz>
> Signed-off-by: Vladimir Lypak <vladimir.lypak@gmail.com>
> Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
> ---
>  arch/arm64/boot/dts/qcom/msm8953.dtsi | 1337 +++++++++++++++++++++++++
>  1 file changed, 1337 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/qcom/msm8953.dtsi
> 
> diff --git a/arch/arm64/boot/dts/qcom/msm8953.dtsi b/arch/arm64/boot/dts/qcom/msm8953.dtsi
> new file mode 100644
> index 000000000000..59918b527750
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/msm8953.dtsi
> @@ -0,0 +1,1337 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/* Copyright (c) 2022, The Linux Foundation. All rights reserved. */
> +
> +#include <dt-bindings/clock/qcom,gcc-msm8953.h>
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include <dt-bindings/power/qcom-rpmpd.h>
> +#include <dt-bindings/thermal/thermal.h>
> +
> +/ {
> +	interrupt-parent = <&intc>;
> +
> +	#address-cells = <2>;
> +	#size-cells = <2>;

Why do you have address/size-cells of 2, and then limit them to 1 in
/soc?

> +
> +	aliases {
> +		i2c1 = &i2c_1;
> +		i2c2 = &i2c_2;
> +		i2c3 = &i2c_3;
> +		i2c4 = &i2c_4;
> +		i2c5 = &i2c_5;
> +		i2c6 = &i2c_6;
> +		i2c7 = &i2c_7;
> +		i2c8 = &i2c_8;

It was expressed a while back that you should specify alias only for the
things that you have enabled in your .dts.

> +	};
[..]
> +		tcsr_mutex: hwlock@1905000 {
> +			compatible = "qcom,tcsr-mutex";
> +			reg = <0x1905000 0x20000>;
> +			#hwlock-cells = <1>;
> +		};
> +
> +		tcsr: syscon@1937000 {
> +			compatible = "qcom,tcsr-msm8953", "syscon";
> +			reg = <0x1937000 0x30000>;
> +		};
> +
> +		tcsr_phy_clk_scheme_sel: syscon@193f044 {

I don't fancy exposing a single word from the middle of &tcsr using a
syscon. The tcsr node should express the TCSR region and if we need to
reference bits of information within that we should do that in some
structured way.

Wouldn't nvmem be a good candidate for this?

> +			compatible = "syscon";
> +			reg = <0x193f044 0x4>;
> +		};
> +

Regards,
Bjorn

Re: [PATCH 10/15] arm64: dts: qcom: Add MSM8953 device tree

[Luca Weiss]

Hi Bjorn,

On Dienstag, 15. Februar 2022 17:40:20 CET Bjorn Andersson wrote:
> On Wed 12 Jan 13:40 CST 2022, Luca Weiss wrote:
> > From: Vladimir Lypak <vladimir.lypak@gmail.com>
> > 
> > Add a base DT for MSM8953 SoC.
> > 
> > Co-developed-by: Luca Weiss <luca@z3ntu.xyz>
> > Signed-off-by: Vladimir Lypak <vladimir.lypak@gmail.com>
> > Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
> > ---
> > 
> >  arch/arm64/boot/dts/qcom/msm8953.dtsi | 1337 +++++++++++++++++++++++++
> >  1 file changed, 1337 insertions(+)
> >  create mode 100644 arch/arm64/boot/dts/qcom/msm8953.dtsi
> > 
> > diff --git a/arch/arm64/boot/dts/qcom/msm8953.dtsi
> > b/arch/arm64/boot/dts/qcom/msm8953.dtsi new file mode 100644
> > index 000000000000..59918b527750
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/qcom/msm8953.dtsi
> > @@ -0,0 +1,1337 @@
> > +// SPDX-License-Identifier: BSD-3-Clause
> > +/* Copyright (c) 2022, The Linux Foundation. All rights reserved. */
> > +
> > +#include <dt-bindings/clock/qcom,gcc-msm8953.h>
> > +#include <dt-bindings/gpio/gpio.h>
> > +#include <dt-bindings/interrupt-controller/arm-gic.h>
> > +#include <dt-bindings/power/qcom-rpmpd.h>
> > +#include <dt-bindings/thermal/thermal.h>
> > +
> > +/ {
> > +	interrupt-parent = <&intc>;
> > +
> > +	#address-cells = <2>;
> > +	#size-cells = <2>;
> 
> Why do you have address/size-cells of 2, and then limit them to 1 in
> /soc?

Quite a few arm64 qcom dtsi files use #address-cells & #size-cells = <1> which 
also makes reg properties quite more readable - and we don't need the 64 bits 
on 8953.

> 
> > +
> > +	aliases {
> > +		i2c1 = &i2c_1;
> > +		i2c2 = &i2c_2;
> > +		i2c3 = &i2c_3;
> > +		i2c4 = &i2c_4;
> > +		i2c5 = &i2c_5;
> > +		i2c6 = &i2c_6;
> > +		i2c7 = &i2c_7;
> > +		i2c8 = &i2c_8;
> 
> It was expressed a while back that you should specify alias only for the
> things that you have enabled in your .dts.

Sure, I'll remove it.

> 
> > +	};
> 
> [..]
> 
> > +		tcsr_mutex: hwlock@1905000 {
> > +			compatible = "qcom,tcsr-mutex";
> > +			reg = <0x1905000 0x20000>;
> > +			#hwlock-cells = <1>;
> > +		};
> > +
> > +		tcsr: syscon@1937000 {
> > +			compatible = "qcom,tcsr-msm8953", "syscon";
> > +			reg = <0x1937000 0x30000>;
> > +		};
> > +
> > +		tcsr_phy_clk_scheme_sel: syscon@193f044 {
> 
> I don't fancy exposing a single word from the middle of &tcsr using a
> syscon. The tcsr node should express the TCSR region and if we need to
> reference bits of information within that we should do that in some
> structured way.
> 
> Wouldn't nvmem be a good candidate for this?

The qusb2 bindings expect the reference like this as far as I can tell, 

qphy->tcsr = syscon_regmap_lookup_by_phandle(dev->of_node,
                                           "qcom,tcsr-syscon");

So I don't think we can change this without changing the driver as well?

Regards
Luca

> 
> > +			compatible = "syscon";
> > +			reg = <0x193f044 0x4>;
> > +		};
> > +
> 
> Regards,
> Bjorn