2021-09-11 23:30:49

by Luca Weiss

[permalink] [raw]
Subject: [PATCH 0/8] Initial LG G Watch R support

Add support for more msm8226 hardware and the LG G Watch R smartwatch which
is based on apq8026.

Luca Weiss (8):
pinctrl: qcom: msm8226: fill in more functions
dt-bindings: mmc: sdhci-msm: Add compatible string for msm8226
dt-bindings: firmware: scm: Add compatible for msm8226
ARM: dts: qcom: msm8226: Add more SoC bits
ARM: dts: qcom: Add pm8226 PMIC
dt-bindings: vendor-prefixes: add LG Electronics
dt-bindings: arm: qcom: Document APQ8026 SoC binding
ARM: dts: qcom: Add support for LG G Watch R

.../devicetree/bindings/arm/qcom.yaml | 6 +
.../devicetree/bindings/firmware/qcom,scm.txt | 1 +
.../devicetree/bindings/mmc/sdhci-msm.txt | 1 +
.../devicetree/bindings/vendor-prefixes.yaml | 2 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/qcom-apq8026-lge-lenok.dts | 237 ++++++++++++++++
arch/arm/boot/dts/qcom-msm8226.dtsi | 263 +++++++++++++++++-
arch/arm/boot/dts/qcom-pm8226.dtsi | 27 ++
drivers/pinctrl/qcom/pinctrl-msm8226.c | 74 +++--
9 files changed, 582 insertions(+), 30 deletions(-)
create mode 100644 arch/arm/boot/dts/qcom-apq8026-lge-lenok.dts
create mode 100644 arch/arm/boot/dts/qcom-pm8226.dtsi

--
2.33.0


2021-09-11 23:30:49

by Luca Weiss

[permalink] [raw]
Subject: [PATCH 4/8] ARM: dts: qcom: msm8226: Add more SoC bits

Add nodes for sdhc, uart4, i2c, scm, smem, rpm-requests including
dependencies.

Signed-off-by: Luca Weiss <[email protected]>
---
arch/arm/boot/dts/qcom-msm8226.dtsi | 263 +++++++++++++++++++++++++++-
1 file changed, 255 insertions(+), 8 deletions(-)

diff --git a/arch/arm/boot/dts/qcom-msm8226.dtsi b/arch/arm/boot/dts/qcom-msm8226.dtsi
index 2de69d56870d..72efd565c6ae 100644
--- a/arch/arm/boot/dts/qcom-msm8226.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8226.dtsi
@@ -7,6 +7,7 @@

#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/clock/qcom,gcc-msm8974.h>
+#include <dt-bindings/gpio/gpio.h>

/ {
#address-cells = <1>;
@@ -20,6 +21,20 @@ memory@0 {
reg = <0x0 0x0>;
};

+ clocks {
+ xo_board: xo_board {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <19200000>;
+ };
+
+ sleep_clk: sleep_clk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <32768>;
+ };
+ };
+
soc: soc {
compatible = "simple-bus";
#address-cells = <1>;
@@ -34,6 +49,136 @@ intc: interrupt-controller@f9000000 {
#interrupt-cells = <3>;
};

+ apcs: syscon@f9011000 {
+ compatible = "syscon";
+ reg = <0xf9011000 0x1000>;
+ };
+
+ sdhc_1: sdhci@f9824900 {
+ compatible = "qcom,msm8226-sdhci", "qcom,sdhci-msm-v4";
+ reg = <0xf9824900 0x11c>, <0xf9824000 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_APPS_CLK>,
+ <&gcc GCC_SDCC1_AHB_CLK>,
+ <&xo_board>;
+ clock-names = "core", "iface", "xo";
+ status = "disabled";
+ };
+
+ sdhc_2: sdhci@f98a4900 {
+ compatible = "qcom,msm8226-sdhci", "qcom,sdhci-msm-v4";
+ reg = <0xf98a4900 0x11c>, <0xf98a4000 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_APPS_CLK>,
+ <&gcc GCC_SDCC2_AHB_CLK>,
+ <&xo_board>;
+ clock-names = "core", "iface", "xo";
+ status = "disabled";
+ };
+
+ sdhc_3: sdhci@f9864900 {
+ compatible = "qcom,msm8226-sdhci", "qcom,sdhci-msm-v4";
+ reg = <0xf9864900 0x11c>, <0xf9864000 0x800>;
+ reg-names = "hc_mem", "core_mem";
+ interrupts = <GIC_SPI 127 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 224 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "hc_irq", "pwr_irq";
+ clocks = <&gcc GCC_SDCC3_APPS_CLK>,
+ <&gcc GCC_SDCC3_AHB_CLK>,
+ <&xo_board>;
+ clock-names = "core", "iface", "xo";
+ status = "disabled";
+ };
+
+ blsp1_uart3: serial@f991f000 {
+ compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm";
+ reg = <0xf991f000 0x1000>;
+ interrupts = <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&gcc GCC_BLSP1_UART3_APPS_CLK>, <&gcc GCC_BLSP1_AHB_CLK>;
+ clock-names = "core", "iface";
+ status = "disabled";
+ };
+
+ blsp1_uart4: serial@f9920000 {
+ compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm";
+ reg = <0xf9920000 0x1000>;
+ interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&gcc GCC_BLSP1_UART4_APPS_CLK>, <&gcc GCC_BLSP1_AHB_CLK>;
+ clock-names = "core", "iface";
+ status = "disabled";
+ };
+
+ blsp1_i2c1: i2c@f9923000 {
+ status = "disabled";
+ compatible = "qcom,i2c-qup-v2.1.1";
+ reg = <0xf9923000 0x1000>;
+ interrupts = <GIC_SPI 95 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&gcc GCC_BLSP1_QUP1_I2C_APPS_CLK>, <&gcc GCC_BLSP1_AHB_CLK>;
+ clock-names = "core", "iface";
+ pinctrl-names = "default";
+ pinctrl-0 = <&blsp1_i2c1_pins>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ blsp1_i2c2: i2c@f9924000 {
+ status = "disabled";
+ compatible = "qcom,i2c-qup-v2.1.1";
+ reg = <0xf9924000 0x1000>;
+ interrupts = <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&gcc GCC_BLSP1_QUP2_I2C_APPS_CLK>, <&gcc GCC_BLSP1_AHB_CLK>;
+ clock-names = "core", "iface";
+ pinctrl-names = "default";
+ pinctrl-0 = <&blsp1_i2c2_pins>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ blsp1_i2c3: i2c@f9925000 {
+ status = "disabled";
+ compatible = "qcom,i2c-qup-v2.1.1";
+ reg = <0xf9925000 0x1000>;
+ interrupts = <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&gcc GCC_BLSP1_QUP3_I2C_APPS_CLK>, <&gcc GCC_BLSP1_AHB_CLK>;
+ clock-names = "core", "iface";
+ pinctrl-names = "default";
+ pinctrl-0 = <&blsp1_i2c3_pins>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ blsp1_i2c4: i2c@f9926000 {
+ status = "disabled";
+ compatible = "qcom,i2c-qup-v2.1.1";
+ reg = <0xf9926000 0x1000>;
+ interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&gcc GCC_BLSP1_QUP4_I2C_APPS_CLK>, <&gcc GCC_BLSP1_AHB_CLK>;
+ clock-names = "core", "iface";
+ pinctrl-names = "default";
+ pinctrl-0 = <&blsp1_i2c4_pins>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ blsp1_i2c5: i2c@f9927000 {
+ status = "disabled";
+ compatible = "qcom,i2c-qup-v2.1.1";
+ reg = <0xf9927000 0x1000>;
+ interrupts = <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&gcc GCC_BLSP1_QUP5_I2C_APPS_CLK>, <&gcc GCC_BLSP1_AHB_CLK>;
+ clock-names = "core", "iface";
+ pinctrl-names = "default";
+ pinctrl-0 = <&blsp1_i2c5_pins>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
gcc: clock-controller@fc400000 {
compatible = "qcom,gcc-msm8226";
reg = <0xfc400000 0x4000>;
@@ -51,15 +196,41 @@ tlmm: pinctrl@fd510000 {
interrupt-controller;
#interrupt-cells = <2>;
interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
- };

- blsp1_uart3: serial@f991f000 {
- compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm";
- reg = <0xf991f000 0x1000>;
- interrupts = <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&gcc GCC_BLSP1_UART3_APPS_CLK>, <&gcc GCC_BLSP1_AHB_CLK>;
- clock-names = "core", "iface";
- status = "disabled";
+ blsp1_i2c1_pins: blsp1-i2c1 {
+ pins = "gpio2", "gpio3";
+ function = "blsp_i2c1";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ blsp1_i2c2_pins: blsp1-i2c2 {
+ pins = "gpio6", "gpio7";
+ function = "blsp_i2c2";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ blsp1_i2c3_pins: blsp1-i2c3 {
+ pins = "gpio10", "gpio11";
+ function = "blsp_i2c3";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ blsp1_i2c4_pins: blsp1-i2c4 {
+ pins = "gpio14", "gpio15";
+ function = "blsp_i2c4";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ blsp1_i2c5_pins: blsp1-i2c5 {
+ pins = "gpio18", "gpio19";
+ function = "blsp_i2c5";
+ drive-strength = <2>;
+ bias-disable;
+ };
};

restart@fc4ab000 {
@@ -67,6 +238,22 @@ restart@fc4ab000 {
reg = <0xfc4ab000 0x4>;
};

+ spmi_bus: spmi@fc4cf000 {
+ compatible = "qcom,spmi-pmic-arb";
+ reg-names = "core", "intr", "cnfg";
+ reg = <0xfc4cf000 0x1000>,
+ <0xfc4cb000 0x1000>,
+ <0xfc4ca000 0x1000>;
+ interrupt-names = "periph_irq";
+ interrupts = <GIC_SPI 190 IRQ_TYPE_LEVEL_HIGH>;
+ qcom,ee = <0>;
+ qcom,channel = <0>;
+ #address-cells = <2>;
+ #size-cells = <0>;
+ interrupt-controller;
+ #interrupt-cells = <4>;
+ };
+
rng@f9bff000 {
compatible = "qcom,prng";
reg = <0xf9bff000 0x200>;
@@ -131,6 +318,66 @@ frame@f9028000 {
status = "disabled";
};
};
+
+ rpm_msg_ram: memory@fc428000 {
+ compatible = "qcom,rpm-msg-ram";
+ reg = <0xfc428000 0x4000>;
+ };
+
+ tcsr_mutex_block: syscon@fd484000 {
+ compatible = "syscon";
+ reg = <0xfd484000 0x2000>;
+ };
+ };
+
+ firmware {
+ scm {
+ compatible = "qcom,scm-msm8226", "qcom,scm";
+ clocks = <&gcc GCC_CE1_CLK>, <&gcc GCC_CE1_AXI_CLK>, <&gcc GCC_CE1_AHB_CLK>;
+ clock-names = "core", "bus", "iface";
+ };
+ };
+
+ tcsr_mutex: hwlock {
+ compatible = "qcom,tcsr-mutex";
+ syscon = <&tcsr_mutex_block 0 0x80>;
+
+ #hwlock-cells = <1>;
+ };
+
+ reserved-memory {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ smem_region: smem@3000000 {
+ reg = <0x3000000 0x100000>;
+ no-map;
+ };
+ };
+
+ 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-msm8226";
+ qcom,smd-channels = "rpm_requests";
+ };
+ };
+ };
+
+ smem {
+ compatible = "qcom,smem";
+
+ memory-region = <&smem_region>;
+ qcom,rpm-msg-ram = <&rpm_msg_ram>;
+
+ hwlocks = <&tcsr_mutex 3>;
};

timer {
--
2.33.0

2021-09-11 23:31:00

by Luca Weiss

[permalink] [raw]
Subject: [PATCH 5/8] ARM: dts: qcom: Add pm8226 PMIC

The pm8226 is used with Qualcomm platforms, like msm8226.

Signed-off-by: Luca Weiss <[email protected]>
---
arch/arm/boot/dts/qcom-pm8226.dtsi | 27 +++++++++++++++++++++++++++
1 file changed, 27 insertions(+)
create mode 100644 arch/arm/boot/dts/qcom-pm8226.dtsi

diff --git a/arch/arm/boot/dts/qcom-pm8226.dtsi b/arch/arm/boot/dts/qcom-pm8226.dtsi
new file mode 100644
index 000000000000..dddb5150dfd7
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-pm8226.dtsi
@@ -0,0 +1,27 @@
+// SPDX-License-Identifier: BSD-3-Clause
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/spmi/spmi.h>
+
+&spmi_bus {
+ pm8226_0: pm8226@0 {
+ compatible = "qcom,pm8226", "qcom,spmi-pmic";
+ reg = <0x0 SPMI_USID>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pwrkey@800 {
+ compatible = "qcom,pm8941-pwrkey";
+ reg = <0x800>;
+ interrupts = <0x0 0x8 0 IRQ_TYPE_EDGE_BOTH>;
+ debounce = <15625>;
+ bias-pull-up;
+ };
+ };
+
+ pm8226_1: pm8226@1 {
+ compatible = "qcom,pm8226", "qcom,spmi-pmic";
+ reg = <0x1 SPMI_USID>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+};
--
2.33.0

2021-09-11 23:31:42

by Luca Weiss

[permalink] [raw]
Subject: [PATCH 7/8] dt-bindings: arm: qcom: Document APQ8026 SoC binding

Document the APQ8026 (based on MSM8226) SoC device-tree binding and the
LG G Watch R.

Signed-off-by: Luca Weiss <[email protected]>
---
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 880ddafc634e..da44688133af 100644
--- a/Documentation/devicetree/bindings/arm/qcom.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom.yaml
@@ -25,6 +25,7 @@ description: |
The 'SoC' element must be one of the following strings:

apq8016
+ apq8026
apq8074
apq8084
apq8096
@@ -92,6 +93,11 @@ properties:
- qcom,apq8016-sbc
- const: qcom,apq8016

+ - items:
+ - enum:
+ - lge,lenok
+ - const: qcom,apq8026
+
- items:
- enum:
- qcom,apq8064-cm-qs600
--
2.33.0

2021-09-11 23:33:23

by Luca Weiss

[permalink] [raw]
Subject: [PATCH 6/8] dt-bindings: vendor-prefixes: add LG Electronics

LG Electronics is a part of the LG Corporation and produces, amongst
other things, consumer electronics such as phones and smartwatches.

Signed-off-by: Luca Weiss <[email protected]>
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index a867f7102c35..b99af98bf5de 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -635,6 +635,8 @@ patternProperties:
description: Lenovo Group Ltd.
"^lg,.*":
description: LG Corporation
+ "^lge,.*":
+ description: LG Electronics Inc.
"^lgphilips,.*":
description: LG Display
"^libretech,.*":
--
2.33.0

2021-09-11 23:33:42

by Luca Weiss

[permalink] [raw]
Subject: [PATCH 8/8] ARM: dts: qcom: Add support for LG G Watch R

Add a device tree for the LG G Watch R smartwatch, manufactured by LG
Electronics and based on the msm8226 platform (apq8026).

Currently UART, internal storage, power button and touchscreen are
supported.

Signed-off-by: Luca Weiss <[email protected]>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/qcom-apq8026-lge-lenok.dts | 237 +++++++++++++++++++
2 files changed, 238 insertions(+)
create mode 100644 arch/arm/boot/dts/qcom-apq8026-lge-lenok.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 7e0934180724..8cb859728bd9 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -939,6 +939,7 @@ dtb-$(CONFIG_ARCH_OXNAS) += \
ox810se-wd-mbwe.dtb \
ox820-cloudengines-pogoplug-series-3.dtb
dtb-$(CONFIG_ARCH_QCOM) += \
+ qcom-apq8026-lge-lenok.dtb \
qcom-apq8060-dragonboard.dtb \
qcom-apq8064-cm-qs600.dtb \
qcom-apq8064-ifc6410.dtb \
diff --git a/arch/arm/boot/dts/qcom-apq8026-lge-lenok.dts b/arch/arm/boot/dts/qcom-apq8026-lge-lenok.dts
new file mode 100644
index 000000000000..02c8dfb0988a
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-apq8026-lge-lenok.dts
@@ -0,0 +1,237 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) 2021, Luca Weiss <[email protected]>
+ */
+
+/dts-v1/;
+
+#include "qcom-msm8226.dtsi"
+#include "qcom-pm8226.dtsi"
+
+/ {
+ model = "LG G Watch R";
+ compatible = "lge,lenok", "qcom,apq8026";
+ qcom,board-id = <132 0x0a>;
+ qcom,msm-id = <199 0x20000>;
+
+ aliases {
+ serial0 = &blsp1_uart3;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+};
+
+&blsp1_i2c5 {
+ status = "okay";
+ clock-frequency = <384000>;
+
+ touchscreen@20 {
+ compatible = "syna,rmi4-i2c";
+ reg = <0x20>;
+
+ interrupts-extended = <&tlmm 17 IRQ_TYPE_EDGE_FALLING>;
+ vdd-supply = <&pm8226_l15>;
+ vio-supply = <&pm8226_l22>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&touch_pins>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ rmi4-f01@1 {
+ reg = <0x1>;
+ syna,nosleep-mode = <1>;
+ };
+
+ rmi4-f12@12 {
+ reg = <0x12>;
+ syna,sensor-type = <1>;
+ };
+ };
+};
+
+&blsp1_uart3 {
+ status = "okay";
+};
+
+&sdhc_1 {
+ status = "okay";
+
+ vmmc-supply = <&pm8226_l17>;
+ vqmmc-supply = <&pm8226_l6>;
+
+ bus-width = <8>;
+ non-removable;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdhc1_pin_a>;
+};
+
+&rpm_requests {
+ pm8226-regulators {
+ compatible = "qcom,rpm-pm8226-regulators";
+
+ pm8226_s1: s1 {
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <1275000>;
+ };
+ pm8226_s3: s3 {
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1350000>;
+ };
+ pm8226_s4: s4 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <2200000>;
+ };
+ pm8226_s5: s5 {
+ regulator-min-microvolt = <1150000>;
+ regulator-max-microvolt = <1150000>;
+ };
+
+ pm8226_l1: l1 {
+ regulator-min-microvolt = <1225000>;
+ regulator-max-microvolt = <1225000>;
+ };
+ pm8226_l2: l2 {
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ };
+ pm8226_l3: l3 {
+ regulator-min-microvolt = <750000>;
+ regulator-max-microvolt = <1337500>;
+ };
+ pm8226_l4: l4 {
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ };
+ pm8226_l5: l5 {
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ };
+ pm8226_l6: l6 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+ pm8226_l7: l7 {
+ regulator-min-microvolt = <1850000>;
+ regulator-max-microvolt = <1850000>;
+ };
+ pm8226_l8: l8 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+ pm8226_l9: l9 {
+ regulator-min-microvolt = <2050000>;
+ regulator-max-microvolt = <2050000>;
+ };
+ pm8226_l10: l10 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+ pm8226_l12: l12 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+ pm8226_l14: l14 {
+ regulator-min-microvolt = <2750000>;
+ regulator-max-microvolt = <2750000>;
+ };
+ pm8226_l15: l15 {
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+ pm8226_l16: l16 {
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3350000>;
+ };
+ pm8226_l17: l17 {
+ regulator-min-microvolt = <2950000>;
+ regulator-max-microvolt = <2950000>;
+ };
+ pm8226_l18: l18 {
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3300000>;
+ };
+ pm8226_l19: l19 {
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ };
+ pm8226_l20: l20 {
+ regulator-min-microvolt = <3075000>;
+ regulator-max-microvolt = <3075000>;
+ };
+ pm8226_l21: l21 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <2950000>;
+ };
+ pm8226_l22: l22 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+ pm8226_l23: l23 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <2950000>;
+ };
+ pm8226_l24: l24 {
+ regulator-min-microvolt = <1300000>;
+ regulator-max-microvolt = <1350000>;
+ };
+ pm8226_l25: l25 {
+ regulator-min-microvolt = <1775000>;
+ regulator-max-microvolt = <2125000>;
+ };
+ pm8226_l26: l26 {
+ regulator-min-microvolt = <1225000>;
+ regulator-max-microvolt = <1225000>;
+ };
+ pm8226_l27: l27 {
+ regulator-min-microvolt = <2050000>;
+ regulator-max-microvolt = <2050000>;
+ };
+ pm8226_l28: l28 {
+ regulator-min-microvolt = <2700000>;
+ regulator-max-microvolt = <3000000>;
+ };
+
+ pm8226_lvs1: lvs1 {};
+ };
+};
+
+&tlmm {
+ sdhc1_pin_a: sdhc1-pin-active {
+ clk {
+ pins = "sdc1_clk";
+ drive-strength = <10>;
+ bias-disable;
+ };
+
+ cmd-data {
+ pins = "sdc1_cmd", "sdc1_data";
+ drive-strength = <10>;
+ bias-pull-up;
+ };
+ };
+
+ touch_pins: touch {
+ irq {
+ pins = "gpio17";
+ function = "gpio";
+
+ drive-strength = <8>;
+ bias-pull-down;
+ input-enable;
+ };
+
+ reset {
+ pins = "gpio16";
+ function = "gpio";
+
+ drive-strength = <8>;
+ bias-disable;
+ output-high;
+ };
+ };
+};
--
2.33.0

2021-09-13 08:51:10

by Krzysztof Kozlowski

[permalink] [raw]
Subject: Re: [PATCH 6/8] dt-bindings: vendor-prefixes: add LG Electronics

On 12/09/2021 01:27, Luca Weiss wrote:
> LG Electronics is a part of the LG Corporation and produces, amongst
> other things, consumer electronics such as phones and smartwatches.

Hi,

Thanks for the patches.

I think "lge" it's the same prefix as "lg". There is no sense in having
multiple vendor prefixes just because company splits inside business
units or subsidiaries. The same as with other conglomerates, e.g.
Samsung - if we wanted to be specific, there will be 4-5 Samsung
vendors... Not mentioning that company organisation is not always
disclosed and can change.

We already have lg for several components, also made by LG Electronics.
What about these?

There is only one device with "lge", added back in 2016 without adding
vendor prefix. I would propose to fix that one, instead of keeping
duplicated "lg".

Best regards,
Krzysztof

2021-09-14 00:57:04

by Luca Weiss

[permalink] [raw]
Subject: Re: [PATCH 6/8] dt-bindings: vendor-prefixes: add LG Electronics

Hi Krzysztof,

On Montag, 13. September 2021 10:49:43 CEST Krzysztof Kozlowski wrote:
> On 12/09/2021 01:27, Luca Weiss wrote:
> > LG Electronics is a part of the LG Corporation and produces, amongst
> > other things, consumer electronics such as phones and smartwatches.
>
> Hi,
>
> Thanks for the patches.
>
> I think "lge" it's the same prefix as "lg". There is no sense in having
> multiple vendor prefixes just because company splits inside business
> units or subsidiaries. The same as with other conglomerates, e.g.
> Samsung - if we wanted to be specific, there will be 4-5 Samsung
> vendors... Not mentioning that company organisation is not always
> disclosed and can change.
>

I was mostly following qcom-msm8974-lge-nexus5-hammerhead as it's the other LG
device tree I am aware of so I've picked lge instead of lg. Also worth noting
that Google uses "LGE" in the Android device tree[1] or in the model name in
the LG G Watch R kernel sources ("LGE APQ 8026v2 LENOK rev-1.0").

I don't have a strong opinion either way so I'm fine with either.

If we decide to go with "lg" do we want to change the Nexus 5 devicetree
(hammerhead) also, that one has the lge name in at least compatible and
filename (I don't know how much of a breaking change that would be considered
as).

> We already have lg for several components, also made by LG Electronics.
> What about these?
>
> There is only one device with "lge", added back in 2016 without adding
> vendor prefix. I would propose to fix that one, instead of keeping
> duplicated "lg".
>
> Best regards,
> Krzysztof

Regards
Luca

[1] https://android.googlesource.com/device/lge/hammerhead/



2021-09-14 07:26:08

by Krzysztof Kozlowski

[permalink] [raw]
Subject: Re: [PATCH 6/8] dt-bindings: vendor-prefixes: add LG Electronics

On 13/09/2021 21:14, Luca Weiss wrote:
> Hi Krzysztof,
>
> On Montag, 13. September 2021 10:49:43 CEST Krzysztof Kozlowski wrote:
>> On 12/09/2021 01:27, Luca Weiss wrote:
>>> LG Electronics is a part of the LG Corporation and produces, amongst
>>> other things, consumer electronics such as phones and smartwatches.
>>
>> Hi,
>>
>> Thanks for the patches.
>>
>> I think "lge" it's the same prefix as "lg". There is no sense in having
>> multiple vendor prefixes just because company splits inside business
>> units or subsidiaries. The same as with other conglomerates, e.g.
>> Samsung - if we wanted to be specific, there will be 4-5 Samsung
>> vendors... Not mentioning that company organisation is not always
>> disclosed and can change.
>>
>
> I was mostly following qcom-msm8974-lge-nexus5-hammerhead as it's the other LG
> device tree I am aware of so I've picked lge instead of lg. Also worth noting
> that Google uses "LGE" in the Android device tree[1] or in the model name in
> the LG G Watch R kernel sources ("LGE APQ 8026v2 LENOK rev-1.0")

[1] Does not point to kernel tree. Downstream user could be a good
argument to switch to lge, but then I would expect correcting other "lg"
devices which are in fact made by LGE.

>
> I don't have a strong opinion either way so I'm fine with either.
>
> If we decide to go with "lg" do we want to change the Nexus 5 devicetree
> (hammerhead) also, that one has the lge name in at least compatible and
> filename (I don't know how much of a breaking change that would be considered
> as).

We would have to add a new one and mark the old compatible as deprecated.

>
>> We already have lg for several components, also made by LG Electronics.
>> What about these?
>>
>> There is only one device with "lge", added back in 2016 without adding
>> vendor prefix. I would propose to fix that one, instead of keeping
>> duplicated "lg".
>>
>> Best regards,
>> Krzysztof
>
> Regards
> Luca
>
> [1] https://android.googlesource.com/device/lge/hammerhead/
>
>
>


Best regards,
Krzysztof

2021-09-21 03:39:45

by Rob Herring (Arm)

[permalink] [raw]
Subject: Re: [PATCH 7/8] dt-bindings: arm: qcom: Document APQ8026 SoC binding

On Sun, Sep 12, 2021 at 01:27:01AM +0200, Luca Weiss wrote:
> Document the APQ8026 (based on MSM8226) SoC device-tree binding and the
> LG G Watch R.

Looks like this was applied, but lg vs. lge needs to be sorted first.
IMO, we should fix the one instance of 'lge'.

>
> Signed-off-by: Luca Weiss <[email protected]>
> ---
> 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 880ddafc634e..da44688133af 100644
> --- a/Documentation/devicetree/bindings/arm/qcom.yaml
> +++ b/Documentation/devicetree/bindings/arm/qcom.yaml
> @@ -25,6 +25,7 @@ description: |
> The 'SoC' element must be one of the following strings:
>
> apq8016
> + apq8026
> apq8074
> apq8084
> apq8096
> @@ -92,6 +93,11 @@ properties:
> - qcom,apq8016-sbc
> - const: qcom,apq8016
>
> + - items:
> + - enum:
> + - lge,lenok
> + - const: qcom,apq8026
> +
> - items:
> - enum:
> - qcom,apq8064-cm-qs600
> --
> 2.33.0
>
>

2022-01-27 07:28:02

by Petr Vorel

[permalink] [raw]
Subject: Re: [PATCH 6/8] dt-bindings: vendor-prefixes: add LG Electronics

Hi all,

> > Hi Krzysztof,

> > On Montag, 13. September 2021 10:49:43 CEST Krzysztof Kozlowski wrote:
> >> On 12/09/2021 01:27, Luca Weiss wrote:
> >>> LG Electronics is a part of the LG Corporation and produces, amongst
> >>> other things, consumer electronics such as phones and smartwatches.

> >> Hi,

> >> Thanks for the patches.

> >> I think "lge" it's the same prefix as "lg". There is no sense in having
> >> multiple vendor prefixes just because company splits inside business
> >> units or subsidiaries. The same as with other conglomerates, e.g.
> >> Samsung - if we wanted to be specific, there will be 4-5 Samsung
> >> vendors... Not mentioning that company organisation is not always
> >> disclosed and can change.


> > I was mostly following qcom-msm8974-lge-nexus5-hammerhead as it's the other LG
> > device tree I am aware of so I've picked lge instead of lg. Also worth noting
> > that Google uses "LGE" in the Android device tree[1] or in the model name in
> > the LG G Watch R kernel sources ("LGE APQ 8026v2 LENOK rev-1.0")

> [1] Does not point to kernel tree. Downstream user could be a good
> argument to switch to lge, but then I would expect correcting other "lg"
> devices which are in fact made by LGE.


> > I don't have a strong opinion either way so I'm fine with either.

> > If we decide to go with "lg" do we want to change the Nexus 5 devicetree
> > (hammerhead) also, that one has the lge name in at least compatible and
> > filename (I don't know how much of a breaking change that would be considered
> > as).

> We would have to add a new one and mark the old compatible as deprecated.

Have we sorted this lg- vs. lge- ?

There are both:
arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
vs
arch/arm/boot/dts/qcom-apq8026-lg-lenok.dts

+ patch flying for msm8992-lg-bullhead-rev-101.dtb
original:
https://lore.kernel.org/linux-arm-msm/[email protected]/
rebased by me:
https://lore.kernel.org/linux-arm-msm/[email protected]/

Kind regards,
Petr

> >> We already have lg for several components, also made by LG Electronics.
> >> What about these?

> >> There is only one device with "lge", added back in 2016 without adding
> >> vendor prefix. I would propose to fix that one, instead of keeping
> >> duplicated "lg".

> >> Best regards,
> >> Krzysztof

> > Regards
> > Luca

> > [1] https://android.googlesource.com/device/lge/hammerhead/





> Best regards,
> Krzysztof

2022-01-27 14:06:05

by Krzysztof Kozlowski

[permalink] [raw]
Subject: Re: [PATCH 6/8] dt-bindings: vendor-prefixes: add LG Electronics

On 27/01/2022 01:20, Petr Vorel wrote:
> Hi all,
>
>>> Hi Krzysztof,
>
>>> On Montag, 13. September 2021 10:49:43 CEST Krzysztof Kozlowski wrote:
>>>> On 12/09/2021 01:27, Luca Weiss wrote:
>>>>> LG Electronics is a part of the LG Corporation and produces, amongst
>>>>> other things, consumer electronics such as phones and smartwatches.
>
>>>> Hi,
>
>>>> Thanks for the patches.
>
>>>> I think "lge" it's the same prefix as "lg". There is no sense in having
>>>> multiple vendor prefixes just because company splits inside business
>>>> units or subsidiaries. The same as with other conglomerates, e.g.
>>>> Samsung - if we wanted to be specific, there will be 4-5 Samsung
>>>> vendors... Not mentioning that company organisation is not always
>>>> disclosed and can change.
>
>
>>> I was mostly following qcom-msm8974-lge-nexus5-hammerhead as it's the other LG
>>> device tree I am aware of so I've picked lge instead of lg. Also worth noting
>>> that Google uses "LGE" in the Android device tree[1] or in the model name in
>>> the LG G Watch R kernel sources ("LGE APQ 8026v2 LENOK rev-1.0")
>
>> [1] Does not point to kernel tree. Downstream user could be a good
>> argument to switch to lge, but then I would expect correcting other "lg"
>> devices which are in fact made by LGE.
>
>
>>> I don't have a strong opinion either way so I'm fine with either.
>
>>> If we decide to go with "lg" do we want to change the Nexus 5 devicetree
>>> (hammerhead) also, that one has the lge name in at least compatible and
>>> filename (I don't know how much of a breaking change that would be considered
>>> as).
>
>> We would have to add a new one and mark the old compatible as deprecated.
>
> Have we sorted this lg- vs. lge- ?
>
> There are both:
> arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
> vs
> arch/arm/boot/dts/qcom-apq8026-lg-lenok.dts
>

Probably renaming/unifying/correcting prefix in existing compatibles is
not worth the effort. This would make a mess and affect other DTS users.

Most of existing usages of "lg" prefix are panels which are coming from
another subsidiary of LG - LG Display. We all use there "lg" prefix, not
"lgd".
Plus mention before Bullhead mobile phone which is coming from LG
Electronics.

If we use generalized "lg" prefix for one subsidiary (LG Display), then
let's do the same for another subsidiary - LG Electronics. Plus entire
branding of LG Electronics products is LG: the website, the logo,
advertisements. Everywhere except legal footer.

I vote for using "lg" for both subsidiaries: LG Display and LG Electronics.


Best regards,
Krzysztof

2022-01-28 17:22:31

by Luca Weiss

[permalink] [raw]
Subject: Re: [PATCH 6/8] dt-bindings: vendor-prefixes: add LG Electronics

Hi all,

On Donnerstag, 27. J?nner 2022 08:45:33 CET Krzysztof Kozlowski wrote:
> On 27/01/2022 01:20, Petr Vorel wrote:
> > Hi all,
> >
> >>> Hi Krzysztof,
> >>>
> >>> On Montag, 13. September 2021 10:49:43 CEST Krzysztof Kozlowski wrote:
> >>>> On 12/09/2021 01:27, Luca Weiss wrote:
> >>>>> LG Electronics is a part of the LG Corporation and produces, amongst
> >>>>> other things, consumer electronics such as phones and smartwatches.
> >>>>
> >>>> Hi,
> >>>>
> >>>> Thanks for the patches.
> >>>>
> >>>> I think "lge" it's the same prefix as "lg". There is no sense in having
> >>>> multiple vendor prefixes just because company splits inside business
> >>>> units or subsidiaries. The same as with other conglomerates, e.g.
> >>>> Samsung - if we wanted to be specific, there will be 4-5 Samsung
> >>>> vendors... Not mentioning that company organisation is not always
> >>>> disclosed and can change.
> >>>
> >>> I was mostly following qcom-msm8974-lge-nexus5-hammerhead as it's the
> >>> other LG device tree I am aware of so I've picked lge instead of lg.
> >>> Also worth noting that Google uses "LGE" in the Android device tree[1]
> >>> or in the model name in the LG G Watch R kernel sources ("LGE APQ
> >>> 8026v2 LENOK rev-1.0")
> >>
> >> [1] Does not point to kernel tree. Downstream user could be a good
> >> argument to switch to lge, but then I would expect correcting other "lg"
> >> devices which are in fact made by LGE.
> >>
> >>> I don't have a strong opinion either way so I'm fine with either.
> >>>
> >>> If we decide to go with "lg" do we want to change the Nexus 5 devicetree
> >>> (hammerhead) also, that one has the lge name in at least compatible and
> >>> filename (I don't know how much of a breaking change that would be
> >>> considered as).
> >>
> >> We would have to add a new one and mark the old compatible as deprecated.
> >
> > Have we sorted this lg- vs. lge- ?
> >
> > There are both:
> > arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
> > vs
> > arch/arm/boot/dts/qcom-apq8026-lg-lenok.dts
>
> Probably renaming/unifying/correcting prefix in existing compatibles is
> not worth the effort. This would make a mess and affect other DTS users.

If wanted I can send a patch renaming the Nexus 5 to just LG, this would
adjust both compatible in the file (which shouldn't really affect anything) and
the filename (which probably will affect various scripts and whatnot used by
existing users of the dtb).
Is this something that can be done in mainline or should we rather just let it
be? I'm not sure what the policies there are.

Regards
Luca

> Most of existing usages of "lg" prefix are panels which are coming from
> another subsidiary of LG - LG Display. We all use there "lg" prefix, not
> "lgd".
> Plus mention before Bullhead mobile phone which is coming from LG
> Electronics.
>
> If we use generalized "lg" prefix for one subsidiary (LG Display), then
> let's do the same for another subsidiary - LG Electronics. Plus entire
> branding of LG Electronics products is LG: the website, the logo,
> advertisements. Everywhere except legal footer.
>
> I vote for using "lg" for both subsidiaries: LG Display and LG Electronics.
>
>
> Best regards,
> Krzysztof




2022-01-30 21:25:22

by Krzysztof Kozlowski

[permalink] [raw]
Subject: Re: [PATCH 6/8] dt-bindings: vendor-prefixes: add LG Electronics

On 27/01/2022 21:51, Luca Weiss wrote:
> Hi all,
>
> On Donnerstag, 27. Jänner 2022 08:45:33 CET Krzysztof Kozlowski wrote:
>> On 27/01/2022 01:20, Petr Vorel wrote:
>>> Hi all,
>>>
>>>>> Hi Krzysztof,
>>>>>
>>>>> On Montag, 13. September 2021 10:49:43 CEST Krzysztof Kozlowski wrote:
>>>>>> On 12/09/2021 01:27, Luca Weiss wrote:
>>>>>>> LG Electronics is a part of the LG Corporation and produces, amongst
>>>>>>> other things, consumer electronics such as phones and smartwatches.
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Thanks for the patches.
>>>>>>
>>>>>> I think "lge" it's the same prefix as "lg". There is no sense in having
>>>>>> multiple vendor prefixes just because company splits inside business
>>>>>> units or subsidiaries. The same as with other conglomerates, e.g.
>>>>>> Samsung - if we wanted to be specific, there will be 4-5 Samsung
>>>>>> vendors... Not mentioning that company organisation is not always
>>>>>> disclosed and can change.
>>>>>
>>>>> I was mostly following qcom-msm8974-lge-nexus5-hammerhead as it's the
>>>>> other LG device tree I am aware of so I've picked lge instead of lg.
>>>>> Also worth noting that Google uses "LGE" in the Android device tree[1]
>>>>> or in the model name in the LG G Watch R kernel sources ("LGE APQ
>>>>> 8026v2 LENOK rev-1.0")
>>>>
>>>> [1] Does not point to kernel tree. Downstream user could be a good
>>>> argument to switch to lge, but then I would expect correcting other "lg"
>>>> devices which are in fact made by LGE.
>>>>
>>>>> I don't have a strong opinion either way so I'm fine with either.
>>>>>
>>>>> If we decide to go with "lg" do we want to change the Nexus 5 devicetree
>>>>> (hammerhead) also, that one has the lge name in at least compatible and
>>>>> filename (I don't know how much of a breaking change that would be
>>>>> considered as).
>>>>
>>>> We would have to add a new one and mark the old compatible as deprecated.
>>>
>>> Have we sorted this lg- vs. lge- ?
>>>
>>> There are both:
>>> arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
>>> vs
>>> arch/arm/boot/dts/qcom-apq8026-lg-lenok.dts
>>
>> Probably renaming/unifying/correcting prefix in existing compatibles is
>> not worth the effort. This would make a mess and affect other DTS users.
>
> If wanted I can send a patch renaming the Nexus 5 to just LG, this would
> adjust both compatible in the file (which shouldn't really affect anything) and
> the filename (which probably will affect various scripts and whatnot used by
> existing users of the dtb).
> Is this something that can be done in mainline or should we rather just let it
> be? I'm not sure what the policies there are.

The "lge" compatible is already in the bindings, so it should not be
changed without valid reason. Imagine there is an user-space code
parsing compatibles to adjust some power-management settings to
different models. It would be broken now.

What could be done is to mark it as deprecated and a add new one:
compatible = "lg,hammerhead", "lge,hammerhead", "qcom,msm8974";
This should be safe for user-space and allow transition to common "lg".


Best regards,
Krzysztof

2022-02-01 01:30:46

by Luca Weiss

[permalink] [raw]
Subject: Re: [PATCH 6/8] dt-bindings: vendor-prefixes: add LG Electronics

Hi Krzysztof,

On Freitag, 28. J?nner 2022 10:57:15 CET Krzysztof Kozlowski wrote:
> On 27/01/2022 21:51, Luca Weiss wrote:
> > Hi all,
> >
> > On Donnerstag, 27. J?nner 2022 08:45:33 CET Krzysztof Kozlowski wrote:
> >> On 27/01/2022 01:20, Petr Vorel wrote:
> >>> Hi all,
> >>>
> >>>>> Hi Krzysztof,
> >>>>>
> >>>>> On Montag, 13. September 2021 10:49:43 CEST Krzysztof Kozlowski wrote:
> >>>>>> On 12/09/2021 01:27, Luca Weiss wrote:
> >>>>>>> LG Electronics is a part of the LG Corporation and produces, amongst
> >>>>>>> other things, consumer electronics such as phones and smartwatches.
> >>>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> Thanks for the patches.
> >>>>>>
> >>>>>> I think "lge" it's the same prefix as "lg". There is no sense in
> >>>>>> having
> >>>>>> multiple vendor prefixes just because company splits inside business
> >>>>>> units or subsidiaries. The same as with other conglomerates, e.g.
> >>>>>> Samsung - if we wanted to be specific, there will be 4-5 Samsung
> >>>>>> vendors... Not mentioning that company organisation is not always
> >>>>>> disclosed and can change.
> >>>>>
> >>>>> I was mostly following qcom-msm8974-lge-nexus5-hammerhead as it's the
> >>>>> other LG device tree I am aware of so I've picked lge instead of lg.
> >>>>> Also worth noting that Google uses "LGE" in the Android device tree[1]
> >>>>> or in the model name in the LG G Watch R kernel sources ("LGE APQ
> >>>>> 8026v2 LENOK rev-1.0")
> >>>>
> >>>> [1] Does not point to kernel tree. Downstream user could be a good
> >>>> argument to switch to lge, but then I would expect correcting other
> >>>> "lg"
> >>>> devices which are in fact made by LGE.
> >>>>
> >>>>> I don't have a strong opinion either way so I'm fine with either.
> >>>>>
> >>>>> If we decide to go with "lg" do we want to change the Nexus 5
> >>>>> devicetree
> >>>>> (hammerhead) also, that one has the lge name in at least compatible
> >>>>> and
> >>>>> filename (I don't know how much of a breaking change that would be
> >>>>> considered as).
> >>>>
> >>>> We would have to add a new one and mark the old compatible as
> >>>> deprecated.
> >>>
> >>> Have we sorted this lg- vs. lge- ?
> >>>
> >>> There are both:
> >>> arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
> >>> vs
> >>> arch/arm/boot/dts/qcom-apq8026-lg-lenok.dts
> >>
> >> Probably renaming/unifying/correcting prefix in existing compatibles is
> >> not worth the effort. This would make a mess and affect other DTS users.
> >
> > If wanted I can send a patch renaming the Nexus 5 to just LG, this would
> > adjust both compatible in the file (which shouldn't really affect
> > anything) and the filename (which probably will affect various scripts
> > and whatnot used by existing users of the dtb).
> > Is this something that can be done in mainline or should we rather just
> > let it be? I'm not sure what the policies there are.
>
> The "lge" compatible is already in the bindings, so it should not be
> changed without valid reason. Imagine there is an user-space code
> parsing compatibles to adjust some power-management settings to
> different models. It would be broken now.
>
> What could be done is to mark it as deprecated and a add new one:
> compatible = "lg,hammerhead", "lge,hammerhead", "qcom,msm8974";
> This should be safe for user-space and allow transition to common "lg".

What can or should be done about the filename then?
For compatible in the file it's now clear from my side.

Regards
Luca

>
> Best regards,
> Krzysztof




2022-02-01 01:41:23

by Krzysztof Kozlowski

[permalink] [raw]
Subject: Re: [PATCH 6/8] dt-bindings: vendor-prefixes: add LG Electronics

On 29/01/2022 10:45, Luca Weiss wrote:
> Hi Krzysztof,
>
>>>>>
>>>>> Have we sorted this lg- vs. lge- ?
>>>>>
>>>>> There are both:
>>>>> arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
>>>>> vs
>>>>> arch/arm/boot/dts/qcom-apq8026-lg-lenok.dts
>>>>
>>>> Probably renaming/unifying/correcting prefix in existing compatibles is
>>>> not worth the effort. This would make a mess and affect other DTS users.
>>>
>>> If wanted I can send a patch renaming the Nexus 5 to just LG, this would
>>> adjust both compatible in the file (which shouldn't really affect
>>> anything) and the filename (which probably will affect various scripts
>>> and whatnot used by existing users of the dtb).
>>> Is this something that can be done in mainline or should we rather just
>>> let it be? I'm not sure what the policies there are.
>>
>> The "lge" compatible is already in the bindings, so it should not be
>> changed without valid reason. Imagine there is an user-space code
>> parsing compatibles to adjust some power-management settings to
>> different models. It would be broken now.
>>
>> What could be done is to mark it as deprecated and a add new one:
>> compatible = "lg,hammerhead", "lge,hammerhead", "qcom,msm8974";
>> This should be safe for user-space and allow transition to common "lg".
>
> What can or should be done about the filename then?

I don't have an opinion on the filename. It does not matter to me. :)
You can change it to "lg" or keep "lge". I don't see much benefits of
changing it but I don't mind keeping it consistent.

Best regards,
Krzysztof