[PATCH v5 00/21] Move Hisilicon 6421v600 SPMI driver set out of staging

[PATCH v5 00/21] Move Hisilicon 6421v600 SPMI driver set out of staging

[Mauro Carvalho Chehab]

Hi Mark/Lee,

This patch series finish addressing support for Hikey 970
SPMI controller, PMIC and regulators.

This version was generated with -M, in order to make easier
to merge upstream.  Also, rebased on the top of v5.10,
without any dependencies from the other patch series
I'm submitting for this board.

Yet,  patch 18 to 20 modifies drivers/staging/hikey9xx/Kconfig
and drivers/staging/hikey9xx/Makefile. So, trivial conflicts
will rise if they're applied via different trees, as they all
remove some lines from such files. 

Regards,
Mauro

v5:
- rebased to not depend on USB PHY patchset;
- removed an USB-specific DT binding;
- changed the subject of one of the patches;
- no driver nor DT contents were changed.

v4:
- use regmap for mfd and spmi drivers;
- a few minor cleanups at the mfd driver.

v3:
- fixed a bug with eco-mode at get_optimum_mode;
- changed the sleep logic when enabling/disabling a power line;
- additional cleanups, as requested by Mark.

v2:

- this driver's probe routine is very similar to the one at the non-SPMI
  variant of Hisilicon 6421;
- The register/voltage data were moved from DT into the driver itself;
- It doesn't have anymore any static data;
- All debug messages got removed;
- Addressed a few be32 warnings from sparse.

Mauro Carvalho Chehab (21):
  staging: hikey9xx: hisilicon,hisi-spmi-controller.yaml fix bindings
  staging: hikey9xx: hisilicon,hi6421-spmi-pmic.yaml: simplify props
  staging: hikey9xx: hisi-spmi-controller: clean sparse warnings
  staging: hikey9xx: hi6421v600-regulator: do some cleanups
  staging: hikey9xx: hi6421v600-regulator: move LDO config from DT
  staging: hikey9xx: hi6421v600-regulator: cleanup debug msgs
  staging: hikey9xx: hi6421v600-regulator: get rid of an static data
  staging: hikey9xx: hi6421v600-regulator: do some cleanups
  staging: hikey9xx: hi6421v600-regulator: update copyright
  staging: hikey9xx: hi6421v600-regulator: fix delay logic
  staging: hikey9xx: hi6421v600-regulator: cleanup comments
  staging: hikey9xx: hi6421v600-regulator: fix get_optimum_mode
  staging: hikey9xx: hisilicon,hi6421-spmi-pmic.yaml: cleanup a warning
  staging: hikey9xx: spmi driver: convert to regmap
  staging: hikey9xx: hi6421-spmi-pmic: update copyright
  staging: hikey9xx: hi6421-spmi-pmic: simplify includes
  staging: hikey9xx: hi6421v600-regulator: use some regmap helpers
  spmi: hisi-spmi-controller: move driver from staging
  mfd: hi6421-spmi-pmic: move driver from staging
  regulator: hi6421v600-regulator: move it from staging
  dts: hisilicon: add support for the PMIC found on Hikey 970

 .../mfd/hisilicon,hi6421-spmi-pmic.yaml       | 135 +++++
 .../spmi}/hisilicon,hisi-spmi-controller.yaml |  19 +-
 MAINTAINERS                                   |  15 +-
 .../boot/dts/hisilicon/hi3670-hikey970.dts    |  22 +-
 .../boot/dts/hisilicon/hikey970-pmic.dtsi     |  87 ++++
 drivers/mfd/Kconfig                           |  15 +
 drivers/mfd/Makefile                          |   1 +
 .../hikey9xx => mfd}/hi6421-spmi-pmic.c       | 147 ++----
 drivers/regulator/Kconfig                     |   8 +
 drivers/regulator/Makefile                    |   1 +
 drivers/regulator/hi6421v600-regulator.c      | 299 +++++++++++
 drivers/spmi/Kconfig                          |   9 +
 drivers/spmi/Makefile                         |   1 +
 .../hikey9xx => spmi}/hisi-spmi-controller.c  |   4 +-
 drivers/staging/Kconfig                       |   2 -
 drivers/staging/Makefile                      |   1 -
 drivers/staging/hikey9xx/Kconfig              |  37 --
 drivers/staging/hikey9xx/Makefile             |   4 -
 .../staging/hikey9xx/hi6421v600-regulator.c   | 478 ------------------
 .../hikey9xx/hisilicon,hi6421-spmi-pmic.yaml  | 159 ------
 include/linux/mfd/hi6421-spmi-pmic.h          |   8 +-
 21 files changed, 634 insertions(+), 818 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mfd/hisilicon,hi6421-spmi-pmic.yaml
 rename {drivers/staging/hikey9xx => Documentation/devicetree/bindings/spmi}/hisilicon,hisi-spmi-controller.yaml (84%)
 create mode 100644 arch/arm64/boot/dts/hisilicon/hikey970-pmic.dtsi
 rename drivers/{staging/hikey9xx => mfd}/hi6421-spmi-pmic.c (65%)
 create mode 100644 drivers/regulator/hi6421v600-regulator.c
 rename drivers/{staging/hikey9xx => spmi}/hisi-spmi-controller.c (99%)
 delete mode 100644 drivers/staging/hikey9xx/hi6421v600-regulator.c
 delete mode 100644 drivers/staging/hikey9xx/hisilicon,hi6421-spmi-pmic.yaml

-- 
2.29.2

[PATCH v5 18/21] spmi: hisi-spmi-controller: move driver from staging

[Mauro Carvalho Chehab]

The Hisilicon 6421v600 SPMI driver is ready for mainstream.

So, move it from staging.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 .../spmi}/hisilicon,hisi-spmi-controller.yaml         |  0
 MAINTAINERS                                           |  7 +++++++
 drivers/spmi/Kconfig                                  |  9 +++++++++
 drivers/spmi/Makefile                                 |  1 +
 .../{staging/hikey9xx => spmi}/hisi-spmi-controller.c |  0
 drivers/staging/hikey9xx/Kconfig                      | 11 -----------
 drivers/staging/hikey9xx/Makefile                     |  1 -
 7 files changed, 17 insertions(+), 12 deletions(-)
 rename {drivers/staging/hikey9xx => Documentation/devicetree/bindings/spmi}/hisilicon,hisi-spmi-controller.yaml (100%)
 rename drivers/{staging/hikey9xx => spmi}/hisi-spmi-controller.c (100%)

diff --git a/drivers/staging/hikey9xx/hisilicon,hisi-spmi-controller.yaml b/Documentation/devicetree/bindings/spmi/hisilicon,hisi-spmi-controller.yaml
similarity index 100%
rename from drivers/staging/hikey9xx/hisilicon,hisi-spmi-controller.yaml
rename to Documentation/devicetree/bindings/spmi/hisilicon,hisi-spmi-controller.yaml
diff --git a/MAINTAINERS b/MAINTAINERS
index 281de213ef47..056777397c68 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7999,6 +7999,13 @@ F:	drivers/crypto/hisilicon/sec2/sec_crypto.c
 F:	drivers/crypto/hisilicon/sec2/sec_crypto.h
 F:	drivers/crypto/hisilicon/sec2/sec_main.c
 
+HISILICON SPMI CONTROLLER DRIVER FOR HIKEY 970
+M:	Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+L:	linux-kernel@vger.kernel.org
+S:	Maintained
+F:	Documentation/devicetree/bindings/spmi/hisilicon,hisi-spmi-controller.yaml
+F:	drivers/spmi/hisi-spmi-controller.c
+
 HISILICON STAGING DRIVERS FOR HIKEY 960/970
 M:	Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
 L:	devel@driverdev.osuosl.org
diff --git a/drivers/spmi/Kconfig b/drivers/spmi/Kconfig
index a53bad541f1a..2874b6c26028 100644
--- a/drivers/spmi/Kconfig
+++ b/drivers/spmi/Kconfig
@@ -11,6 +11,15 @@ menuconfig SPMI
 
 if SPMI
 
+config SPMI_HISI3670
+	tristate "Hisilicon 3670 SPMI Controller"
+	select IRQ_DOMAIN_HIERARCHY
+	depends on HAS_IOMEM
+	help
+	  If you say yes to this option, support will be included for the
+	  built-in SPMI PMIC Arbiter interface on Hisilicon 3670
+	  processors.
+
 config SPMI_MSM_PMIC_ARB
 	tristate "Qualcomm MSM SPMI Controller (PMIC Arbiter)"
 	select IRQ_DOMAIN_HIERARCHY
diff --git a/drivers/spmi/Makefile b/drivers/spmi/Makefile
index 55a94cadeffe..6e092e6f290c 100644
--- a/drivers/spmi/Makefile
+++ b/drivers/spmi/Makefile
@@ -4,4 +4,5 @@
 #
 obj-$(CONFIG_SPMI)	+= spmi.o
 
+obj-$(CONFIG_SPMI_HISI3670)	+= hisi-spmi-controller.o
 obj-$(CONFIG_SPMI_MSM_PMIC_ARB)	+= spmi-pmic-arb.o
diff --git a/drivers/staging/hikey9xx/hisi-spmi-controller.c b/drivers/spmi/hisi-spmi-controller.c
similarity index 100%
rename from drivers/staging/hikey9xx/hisi-spmi-controller.c
rename to drivers/spmi/hisi-spmi-controller.c
diff --git a/drivers/staging/hikey9xx/Kconfig b/drivers/staging/hikey9xx/Kconfig
index b29f5d5df134..6dc9f9307510 100644
--- a/drivers/staging/hikey9xx/Kconfig
+++ b/drivers/staging/hikey9xx/Kconfig
@@ -11,17 +11,6 @@ config PHY_HI3670_USB
 
 	  To compile this driver as a module, choose M here.
 
-# to be placed at drivers/spmi
-config SPMI_HISI3670
-	tristate "Hisilicon 3670 SPMI Controller"
-	select IRQ_DOMAIN_HIERARCHY
-	depends on HAS_IOMEM
-	depends on SPMI
-	help
-	  If you say yes to this option, support will be included for the
-	  built-in SPMI PMIC Arbiter interface on Hisilicon 3670
-	  processors.
-
 # to be placed at drivers/mfd
 config MFD_HI6421_SPMI
 	tristate "HiSilicon Hi6421v600 SPMI PMU/Codec IC"
diff --git a/drivers/staging/hikey9xx/Makefile b/drivers/staging/hikey9xx/Makefile
index 1924fadac952..64b419cf7bca 100644
--- a/drivers/staging/hikey9xx/Makefile
+++ b/drivers/staging/hikey9xx/Makefile
@@ -2,6 +2,5 @@
 
 obj-$(CONFIG_PHY_HI3670_USB)		+= phy-hi3670-usb3.o
 
-obj-$(CONFIG_SPMI_HISI3670)		+= hisi-spmi-controller.o
 obj-$(CONFIG_MFD_HI6421_SPMI)		+= hi6421-spmi-pmic.o
 obj-$(CONFIG_REGULATOR_HI6421V600)	+= hi6421v600-regulator.o
-- 
2.29.2

[PATCH v5 19/21] mfd: hi6421-spmi-pmic: move driver from staging

[Mauro Carvalho Chehab]

This driver is ready for mainstream. So, move it out of staging.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 .../mfd}/hisilicon,hi6421-spmi-pmic.yaml         |  0
 MAINTAINERS                                      |  7 +++++++
 drivers/mfd/Kconfig                              | 15 +++++++++++++++
 drivers/mfd/Makefile                             |  1 +
 .../{staging/hikey9xx => mfd}/hi6421-spmi-pmic.c |  0
 drivers/staging/hikey9xx/Kconfig                 | 16 ----------------
 drivers/staging/hikey9xx/Makefile                |  1 -
 7 files changed, 23 insertions(+), 17 deletions(-)
 rename {drivers/staging/hikey9xx => Documentation/devicetree/bindings/mfd}/hisilicon,hi6421-spmi-pmic.yaml (100%)
 rename drivers/{staging/hikey9xx => mfd}/hi6421-spmi-pmic.c (100%)

diff --git a/drivers/staging/hikey9xx/hisilicon,hi6421-spmi-pmic.yaml b/Documentation/devicetree/bindings/mfd/hisilicon,hi6421-spmi-pmic.yaml
similarity index 100%
rename from drivers/staging/hikey9xx/hisilicon,hi6421-spmi-pmic.yaml
rename to Documentation/devicetree/bindings/mfd/hisilicon,hi6421-spmi-pmic.yaml
diff --git a/MAINTAINERS b/MAINTAINERS
index 056777397c68..120f14620f56 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8006,6 +8006,13 @@ S:	Maintained
 F:	Documentation/devicetree/bindings/spmi/hisilicon,hisi-spmi-controller.yaml
 F:	drivers/spmi/hisi-spmi-controller.c
 
+HISILICON SPMI PMIC DRIVER FOR HIKEY 6421v600
+M:	Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+L:	linux-kernel@vger.kernel.org
+S:	Maintained
+F:	Documentation/devicetree/bindings/mfd/hisilicon,hi6421-spmi-pmic.yaml
+F:	drivers/mfd/hi6421-spmi-pmic.c
+
 HISILICON STAGING DRIVERS FOR HIKEY 960/970
 M:	Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
 L:	devel@driverdev.osuosl.org
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 8b99a13669bf..c04c2f6be1d9 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -509,6 +509,21 @@ config MFD_HI6421_PMIC
 	  menus in order to enable them.
 	  We communicate with the Hi6421 via memory-mapped I/O.
 
+config MFD_HI6421_SPMI
+	tristate "HiSilicon Hi6421v600 SPMI PMU/Codec IC"
+	depends on OF
+	depends on SPMI
+	select MFD_CORE
+	help
+	  Add support for HiSilicon Hi6421v600 SPMI PMIC. Hi6421 includes
+	  multi-functions, such as regulators, RTC, codec, Coulomb counter,
+	  etc.
+
+	  This driver includes core APIs _only_. You have to select
+	  individual components like voltage regulators under corresponding
+	  menus in order to enable them.
+	  We communicate with the Hi6421v600 via a SPMI bus.
+
 config MFD_HI655X_PMIC
 	tristate "HiSilicon Hi655X series PMU/Codec IC"
 	depends on ARCH_HISI || COMPILE_TEST
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 1780019d2474..7744993c42bc 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -233,6 +233,7 @@ obj-$(CONFIG_MFD_IPAQ_MICRO)	+= ipaq-micro.o
 obj-$(CONFIG_MFD_IQS62X)	+= iqs62x.o
 obj-$(CONFIG_MFD_MENF21BMC)	+= menf21bmc.o
 obj-$(CONFIG_MFD_HI6421_PMIC)	+= hi6421-pmic-core.o
+obj-$(CONFIG_MFD_HI6421_SPMI)	+= hi6421-spmi-pmic.o
 obj-$(CONFIG_MFD_HI655X_PMIC)   += hi655x-pmic.o
 obj-$(CONFIG_MFD_DLN2)		+= dln2.o
 obj-$(CONFIG_MFD_RT5033)	+= rt5033.o
diff --git a/drivers/staging/hikey9xx/hi6421-spmi-pmic.c b/drivers/mfd/hi6421-spmi-pmic.c
similarity index 100%
rename from drivers/staging/hikey9xx/hi6421-spmi-pmic.c
rename to drivers/mfd/hi6421-spmi-pmic.c
diff --git a/drivers/staging/hikey9xx/Kconfig b/drivers/staging/hikey9xx/Kconfig
index 6dc9f9307510..76337be330f8 100644
--- a/drivers/staging/hikey9xx/Kconfig
+++ b/drivers/staging/hikey9xx/Kconfig
@@ -11,22 +11,6 @@ config PHY_HI3670_USB
 
 	  To compile this driver as a module, choose M here.
 
-# to be placed at drivers/mfd
-config MFD_HI6421_SPMI
-	tristate "HiSilicon Hi6421v600 SPMI PMU/Codec IC"
-	depends on OF
-	depends on SPMI
-	select MFD_CORE
-	help
-	  Add support for HiSilicon Hi6421v600 SPMI PMIC. Hi6421 includes
-	  multi-functions, such as regulators, RTC, codec, Coulomb counter,
-	  etc.
-
-	  This driver includes core APIs _only_. You have to select
-	  individual components like voltage regulators under corresponding
-	  menus in order to enable them.
-	  We communicate with the Hi6421v600 via a SPMI bus.
-
 # to be placed at drivers/regulator
 config REGULATOR_HI6421V600
 	tristate "HiSilicon Hi6421v600 PMIC voltage regulator support"
diff --git a/drivers/staging/hikey9xx/Makefile b/drivers/staging/hikey9xx/Makefile
index 64b419cf7bca..d26af65baf8b 100644
--- a/drivers/staging/hikey9xx/Makefile
+++ b/drivers/staging/hikey9xx/Makefile
@@ -2,5 +2,4 @@
 
 obj-$(CONFIG_PHY_HI3670_USB)		+= phy-hi3670-usb3.o
 
-obj-$(CONFIG_MFD_HI6421_SPMI)		+= hi6421-spmi-pmic.o
 obj-$(CONFIG_REGULATOR_HI6421V600)	+= hi6421v600-regulator.o
-- 
2.29.2

[PATCH v5 21/21] dts: hisilicon: add support for the PMIC found on Hikey 970

[Mauro Carvalho Chehab]

Add a device tree for the HiSilicon 6421v600 SPMI PMIC, used
on HiKey970 board.

As we now have support for it, change the fixed regulators
used by the SD I/O to use the proper LDO supplies.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
 .../boot/dts/hisilicon/hi3670-hikey970.dts    | 22 +----
 .../boot/dts/hisilicon/hikey970-pmic.dtsi     | 87 +++++++++++++++++++
 2 files changed, 90 insertions(+), 19 deletions(-)
 create mode 100644 arch/arm64/boot/dts/hisilicon/hikey970-pmic.dtsi

diff --git a/arch/arm64/boot/dts/hisilicon/hi3670-hikey970.dts b/arch/arm64/boot/dts/hisilicon/hi3670-hikey970.dts
index 7f9f9886c349..5e6d7b329771 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3670-hikey970.dts
+++ b/arch/arm64/boot/dts/hisilicon/hi3670-hikey970.dts
@@ -12,6 +12,7 @@
 
 #include "hi3670.dtsi"
 #include "hikey970-pinctrl.dtsi"
+#include "hikey970-pmic.dtsi"
 
 / {
 	model = "HiKey970";
@@ -39,23 +40,6 @@ memory@0 {
 		reg = <0x0 0x0 0x0 0x0>;
 	};
 
-	sd_1v8: regulator-1v8 {
-		compatible = "regulator-fixed";
-		regulator-name = "fixed-1.8V";
-		regulator-min-microvolt = <1800000>;
-		regulator-max-microvolt = <1800000>;
-		regulator-always-on;
-	};
-
-	sd_3v3: regulator-3v3 {
-		compatible = "regulator-fixed";
-		regulator-name = "fixed-3.3V";
-		regulator-min-microvolt = <3300000>;
-		regulator-max-microvolt = <3300000>;
-		regulator-boot-on;
-		regulator-always-on;
-	};
-
 	wlan_en: wlan-en-1-8v {
 		compatible = "regulator-fixed";
 		regulator-name = "wlan-en-regulator";
@@ -402,8 +386,8 @@ &dwmmc1 {
 	pinctrl-0 = <&sd_pmx_func
 		     &sd_clk_cfg_func
 		     &sd_cfg_func>;
-	vmmc-supply = <&sd_3v3>;
-	vqmmc-supply = <&sd_1v8>;
+	vmmc-supply = <&ldo16>;
+	vqmmc-supply = <&ldo9>;
 	status = "okay";
 };
 
diff --git a/arch/arm64/boot/dts/hisilicon/hikey970-pmic.dtsi b/arch/arm64/boot/dts/hisilicon/hikey970-pmic.dtsi
new file mode 100644
index 000000000000..8cf45b962fea
--- /dev/null
+++ b/arch/arm64/boot/dts/hisilicon/hikey970-pmic.dtsi
@@ -0,0 +1,87 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * dts file for Hi6421v600 SPMI PMIC used at the HiKey970 Development Board
+ *
+ * Copyright (C) 2020, Huawei Tech. Co., Ltd.
+ */
+
+#include <dt-bindings/spmi/spmi.h>
+
+/ {
+	spmi: spmi@fff24000 {
+		compatible = "hisilicon,kirin970-spmi-controller";
+		#address-cells = <2>;
+		#size-cells = <0>;
+		status = "okay";
+		reg = <0x0 0xfff24000 0x0 0x1000>;
+		spmi-channel = <2>;
+
+		pmic: pmic@0 {
+			compatible = "hisilicon,hi6421-spmi";
+			reg = <0 SPMI_USID>;
+
+			#interrupt-cells = <2>;
+			interrupt-controller;
+			gpios = <&gpio28 0 0>;
+
+			regulators {
+				#address-cells = <1>;
+				#size-cells = <0>;
+
+				ldo3: LDO3 {
+					regulator-name = "ldo3";
+					regulator-min-microvolt = <1500000>;
+					regulator-max-microvolt = <2000000>;
+					regulator-boot-on;
+				};
+
+				ldo4: LDO4 { /* 40 PIN */
+					regulator-name = "ldo4";
+					regulator-min-microvolt = <1725000>;
+					regulator-max-microvolt = <1900000>;
+					regulator-boot-on;
+				};
+
+				ldo9: LDO9 { /* SDCARD I/O */
+					regulator-name = "ldo9";
+					regulator-min-microvolt = <1750000>;
+					regulator-max-microvolt = <3300000>;
+					regulator-boot-on;
+				};
+
+				ldo15: LDO15 { /* UFS */
+					regulator-name = "ldo15";
+					regulator-min-microvolt = <1800000>;
+					regulator-max-microvolt = <3000000>;
+					regulator-always-on;
+				};
+
+				ldo16: LDO16 { /* SD */
+					regulator-name = "ldo16";
+					regulator-min-microvolt = <1800000>;
+					regulator-max-microvolt = <3000000>;
+					regulator-boot-on;
+				};
+
+				ldo17: LDO17 {
+					regulator-name = "ldo17";
+					regulator-min-microvolt = <2500000>;
+					regulator-max-microvolt = <3300000>;
+				};
+
+				ldo33: LDO33 { /* PEX8606 */
+					regulator-name = "ldo33";
+					regulator-min-microvolt = <2500000>;
+					regulator-max-microvolt = <3300000>;
+					regulator-boot-on;
+				};
+
+				ldo34: LDO34 { /* GPS AUX IN VDD */
+					regulator-name = "ldo34";
+					regulator-min-microvolt = <2600000>;
+					regulator-max-microvolt = <3300000>;
+				};
+			};
+		};
+	};
+};
-- 
2.29.2

Re: [PATCH v5 00/21] Move Hisilicon 6421v600 SPMI driver set out of staging

[Greg Kroah-Hartman]

On Thu, Jan 21, 2021 at 08:18:02AM +0100, Mauro Carvalho Chehab wrote:
> Hi Mark/Lee,
> 
> This patch series finish addressing support for Hikey 970
> SPMI controller, PMIC and regulators.
> 
> This version was generated with -M, in order to make easier
> to merge upstream.  Also, rebased on the top of v5.10,
> without any dependencies from the other patch series
> I'm submitting for this board.
> 
> Yet,  patch 18 to 20 modifies drivers/staging/hikey9xx/Kconfig
> and drivers/staging/hikey9xx/Makefile. So, trivial conflicts
> will rise if they're applied via different trees, as they all
> remove some lines from such files. 

I've applied the first 13 patches, except for patch 3, as that did not
apply, to my tree, thanks.

greg k-h

Re: [PATCH v5 00/21] Move Hisilicon 6421v600 SPMI driver set out of staging

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 208 bytes --]

On Tue, Jan 26, 2021 at 06:54:57PM +0100, Greg Kroah-Hartman wrote:

> I've applied the first 13 patches, except for patch 3, as that did not
> apply, to my tree, thanks.

Is there a branch we can pull from?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v5 00/21] Move Hisilicon 6421v600 SPMI driver set out of staging

[Greg Kroah-Hartman]

On Tue, Jan 26, 2021 at 05:57:52PM +0000, Mark Brown wrote:
> On Tue, Jan 26, 2021 at 06:54:57PM +0100, Greg Kroah-Hartman wrote:
> 
> > I've applied the first 13 patches, except for patch 3, as that did not
> > apply, to my tree, thanks.
> 
> Is there a branch we can pull from?

Once 0-day passes, you can pull from my staging-testing branch from
staging.git on git.kernel.org if you want.  Give it 24 hours to pass
before it hits that location.

Do you need a tag to pull from?

thanks,

greg k-h

Re: [PATCH v5 00/21] Move Hisilicon 6421v600 SPMI driver set out of staging

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 422 bytes --]

On Tue, Jan 26, 2021 at 07:02:39PM +0100, Greg Kroah-Hartman wrote:
> On Tue, Jan 26, 2021 at 05:57:52PM +0000, Mark Brown wrote:

> > Is there a branch we can pull from?

> Once 0-day passes, you can pull from my staging-testing branch from
> staging.git on git.kernel.org if you want.  Give it 24 hours to pass
> before it hits that location.

Thanks.

> Do you need a tag to pull from?

It'd be nice but not essential.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v5 00/21] Move Hisilicon 6421v600 SPMI driver set out of staging

[Greg Kroah-Hartman]

On Tue, Jan 26, 2021 at 06:11:24PM +0000, Mark Brown wrote:
> On Tue, Jan 26, 2021 at 07:02:39PM +0100, Greg Kroah-Hartman wrote:
> > On Tue, Jan 26, 2021 at 05:57:52PM +0000, Mark Brown wrote:
> 
> > > Is there a branch we can pull from?
> 
> > Once 0-day passes, you can pull from my staging-testing branch from
> > staging.git on git.kernel.org if you want.  Give it 24 hours to pass
> > before it hits that location.
> 
> Thanks.

Should be out there now if you want to pull.

> > Do you need a tag to pull from?
> 
> It'd be nice but not essential.

Why do you want/need this?  Having these changes in your tree is good,
but what about other coding style cleanups that I will end up applying
over time before the 5.12-rc1 merge window opens?  Are you wanting to
take the moved driver in your tree, or something else?

Traditionally moving drivers out of staging can be done 2 ways:
	- all happens in the staging tree, I take an ack from the
	  subsystem maintainer that this is ok to do.
	- A new driver enters the "real" subsystem tree, and then I
	  delete the driver in the staging tree.  This doesn't preserve
	  history as well (not at all), but can be easier for trees that
	  move quickly (like networking.)

Which ever works for you is fine with me, but relying on the code to
stay "not touched" in my tree after you pull it almost never happens due
to the number of drive-by coding style cleanups that end up in the
staging tree every week.

thanks,

greg k-h

Re: [PATCH v5 00/21] Move Hisilicon 6421v600 SPMI driver set out of staging

[Lee Jones]

On Wed, 27 Jan 2021, Greg Kroah-Hartman wrote:

> On Tue, Jan 26, 2021 at 06:11:24PM +0000, Mark Brown wrote:
> > On Tue, Jan 26, 2021 at 07:02:39PM +0100, Greg Kroah-Hartman wrote:
> > > On Tue, Jan 26, 2021 at 05:57:52PM +0000, Mark Brown wrote:
> > 
> > > > Is there a branch we can pull from?
> > 
> > > Once 0-day passes, you can pull from my staging-testing branch from
> > > staging.git on git.kernel.org if you want.  Give it 24 hours to pass
> > > before it hits that location.
> > 
> > Thanks.
> 
> Should be out there now if you want to pull.
> 
> > > Do you need a tag to pull from?
> > 
> > It'd be nice but not essential.
> 
> Why do you want/need this?  Having these changes in your tree is good,
> but what about other coding style cleanups that I will end up applying
> over time before the 5.12-rc1 merge window opens?  Are you wanting to
> take the moved driver in your tree, or something else?
> 
> Traditionally moving drivers out of staging can be done 2 ways:
> 	- all happens in the staging tree, I take an ack from the
> 	  subsystem maintainer that this is ok to do.
> 	- A new driver enters the "real" subsystem tree, and then I
> 	  delete the driver in the staging tree.  This doesn't preserve
> 	  history as well (not at all), but can be easier for trees that
> 	  move quickly (like networking.)
> 
> Which ever works for you is fine with me, but relying on the code to
> stay "not touched" in my tree after you pull it almost never happens due
> to the number of drive-by coding style cleanups that end up in the
> staging tree every week.

I would have expected the whole set to be merged as a set into a
single tree, placed on an immutable branch and a pull-request to be
sent out for the other maintainers to pull from (if they so wished).

This would ensure development could continue on any/all of the
affected drivers/files.

If it's not too late, I'd be more than happy to facilitate.

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

Re: [PATCH v5 00/21] Move Hisilicon 6421v600 SPMI driver set out of staging

[Greg Kroah-Hartman]

On Wed, Jan 27, 2021 at 10:08:16AM +0000, Lee Jones wrote:
> On Wed, 27 Jan 2021, Greg Kroah-Hartman wrote:
> 
> > On Tue, Jan 26, 2021 at 06:11:24PM +0000, Mark Brown wrote:
> > > On Tue, Jan 26, 2021 at 07:02:39PM +0100, Greg Kroah-Hartman wrote:
> > > > On Tue, Jan 26, 2021 at 05:57:52PM +0000, Mark Brown wrote:
> > > 
> > > > > Is there a branch we can pull from?
> > > 
> > > > Once 0-day passes, you can pull from my staging-testing branch from
> > > > staging.git on git.kernel.org if you want.  Give it 24 hours to pass
> > > > before it hits that location.
> > > 
> > > Thanks.
> > 
> > Should be out there now if you want to pull.
> > 
> > > > Do you need a tag to pull from?
> > > 
> > > It'd be nice but not essential.
> > 
> > Why do you want/need this?  Having these changes in your tree is good,
> > but what about other coding style cleanups that I will end up applying
> > over time before the 5.12-rc1 merge window opens?  Are you wanting to
> > take the moved driver in your tree, or something else?
> > 
> > Traditionally moving drivers out of staging can be done 2 ways:
> > 	- all happens in the staging tree, I take an ack from the
> > 	  subsystem maintainer that this is ok to do.
> > 	- A new driver enters the "real" subsystem tree, and then I
> > 	  delete the driver in the staging tree.  This doesn't preserve
> > 	  history as well (not at all), but can be easier for trees that
> > 	  move quickly (like networking.)
> > 
> > Which ever works for you is fine with me, but relying on the code to
> > stay "not touched" in my tree after you pull it almost never happens due
> > to the number of drive-by coding style cleanups that end up in the
> > staging tree every week.
> 
> I would have expected the whole set to be merged as a set into a
> single tree, placed on an immutable branch and a pull-request to be
> sent out for the other maintainers to pull from (if they so wished).
> 
> This would ensure development could continue on any/all of the
> affected drivers/files.
> 
> If it's not too late, I'd be more than happy to facilitate.

Given these patches are already in my public tree, that might be a bit
harder, why the huge work for this?  Worst case, I just keep all of the
patches that do not actually move the code in my tree, and then things
can move after 5.12-rc1.

thanks,

greg k-h

Re: [PATCH v5 19/21] mfd: hi6421-spmi-pmic: move driver from staging

[Lee Jones]

On Thu, 21 Jan 2021, Mauro Carvalho Chehab wrote:

> This driver is ready for mainstream. So, move it out of staging.
> 
> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> ---
>  .../mfd}/hisilicon,hi6421-spmi-pmic.yaml         |  0
>  MAINTAINERS                                      |  7 +++++++
>  drivers/mfd/Kconfig                              | 15 +++++++++++++++
>  drivers/mfd/Makefile                             |  1 +
>  .../{staging/hikey9xx => mfd}/hi6421-spmi-pmic.c |  0
>  drivers/staging/hikey9xx/Kconfig                 | 16 ----------------
>  drivers/staging/hikey9xx/Makefile                |  1 -
>  7 files changed, 23 insertions(+), 17 deletions(-)
>  rename {drivers/staging/hikey9xx => Documentation/devicetree/bindings/mfd}/hisilicon,hi6421-spmi-pmic.yaml (100%)
>  rename drivers/{staging/hikey9xx => mfd}/hi6421-spmi-pmic.c (100%)

Replied to an earlier submission where I was able to reply in-line.

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

Re: [PATCH v5 00/21] Move Hisilicon 6421v600 SPMI driver set out of staging

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1512 bytes --]

On Wed, Jan 27, 2021 at 09:57:40AM +0100, Greg Kroah-Hartman wrote:
> On Tue, Jan 26, 2021 at 06:11:24PM +0000, Mark Brown wrote:

> > > Do you need a tag to pull from?

> > It'd be nice but not essential.

> Why do you want/need this?  Having these changes in your tree is good,
> but what about other coding style cleanups that I will end up applying
> over time before the 5.12-rc1 merge window opens?  Are you wanting to
> take the moved driver in your tree, or something else?

I want to apply the regulator driver so I stop being sent this patch
series which will help keep my backlog more manageable.

> Traditionally moving drivers out of staging can be done 2 ways:
> 	- all happens in the staging tree, I take an ack from the
> 	  subsystem maintainer that this is ok to do.
> 	- A new driver enters the "real" subsystem tree, and then I
> 	  delete the driver in the staging tree.  This doesn't preserve
> 	  history as well (not at all), but can be easier for trees that
> 	  move quickly (like networking.)

The whole reason the driver is in the staging tree is that Mauro has a
requirement to do things in a way that preserves history and so won't
send any non-incremental patches.

> Which ever works for you is fine with me, but relying on the code to
> stay "not touched" in my tree after you pull it almost never happens due
> to the number of drive-by coding style cleanups that end up in the
> staging tree every week.

I'm sure someone can work out the conflicts if they're going to happen.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v5 00/21] Move Hisilicon 6421v600 SPMI driver set out of staging

[Greg Kroah-Hartman]

On Wed, Jan 27, 2021 at 12:04:26PM +0000, Mark Brown wrote:
> On Wed, Jan 27, 2021 at 09:57:40AM +0100, Greg Kroah-Hartman wrote:
> > On Tue, Jan 26, 2021 at 06:11:24PM +0000, Mark Brown wrote:
> 
> > > > Do you need a tag to pull from?
> 
> > > It'd be nice but not essential.
> 
> > Why do you want/need this?  Having these changes in your tree is good,
> > but what about other coding style cleanups that I will end up applying
> > over time before the 5.12-rc1 merge window opens?  Are you wanting to
> > take the moved driver in your tree, or something else?
> 
> I want to apply the regulator driver so I stop being sent this patch
> series which will help keep my backlog more manageable.
> 
> > Traditionally moving drivers out of staging can be done 2 ways:
> > 	- all happens in the staging tree, I take an ack from the
> > 	  subsystem maintainer that this is ok to do.
> > 	- A new driver enters the "real" subsystem tree, and then I
> > 	  delete the driver in the staging tree.  This doesn't preserve
> > 	  history as well (not at all), but can be easier for trees that
> > 	  move quickly (like networking.)
> 
> The whole reason the driver is in the staging tree is that Mauro has a
> requirement to do things in a way that preserves history and so won't
> send any non-incremental patches.

Ok, should we wait until after 5.12-rc1 is out then?

thanks,

greg k-h

Re: [PATCH v5 00/21] Move Hisilicon 6421v600 SPMI driver set out of staging

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 536 bytes --]

On Wed, Jan 27, 2021 at 02:32:35PM +0100, Greg Kroah-Hartman wrote:
> On Wed, Jan 27, 2021 at 12:04:26PM +0000, Mark Brown wrote:

> > The whole reason the driver is in the staging tree is that Mauro has a
> > requirement to do things in a way that preserves history and so won't
> > send any non-incremental patches.

> Ok, should we wait until after 5.12-rc1 is out then?

Ah, turns out I actually need up to patch 14 anyway which updates the
MFD bits so may as well leave things for now and work out what to do
once that's reviewed.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v5 00/21] Move Hisilicon 6421v600 SPMI driver set out of staging

[Mauro Carvalho Chehab]

Em Wed, 27 Jan 2021 11:19:36 +0100
Greg Kroah-Hartman <gregkh@linuxfoundation.org> escreveu:

> > This patch series finish addressing support for Hikey 970
> > SPMI controller, PMIC and regulators.
> > 
> > This version was generated with -M, in order to make easier
> > to merge upstream.  Also, rebased on the top of v5.10,
> > without any dependencies from the other patch series
> > I'm submitting for this board.
> > 
> > Yet,  patch 18 to 20 modifies drivers/staging/hikey9xx/Kconfig
> > and drivers/staging/hikey9xx/Makefile. So, trivial conflicts
> > will rise if they're applied via different trees, as they all
> > remove some lines from such files.   
> 
> I've applied the first 13 patches, except for patch 3, as that did not
> apply, to my tree, thanks.

Ok. I'll rebase the remaining patches on the top of staging-testing branch.

> On Wed, Jan 27, 2021 at 10:08:16AM +0000, Lee Jones wrote:
> > On Wed, 27 Jan 2021, Greg Kroah-Hartman wrote:
> >   
> > > On Tue, Jan 26, 2021 at 06:11:24PM +0000, Mark Brown wrote:  
> > > > On Tue, Jan 26, 2021 at 07:02:39PM +0100, Greg Kroah-Hartman wrote:  
> > > > > On Tue, Jan 26, 2021 at 05:57:52PM +0000, Mark Brown wrote:  
> > > >   
> > > > > > Is there a branch we can pull from?  
> > > >   
> > > > > Once 0-day passes, you can pull from my staging-testing branch from
> > > > > staging.git on git.kernel.org if you want.  Give it 24 hours to pass
> > > > > before it hits that location.  
> > > > 
> > > > Thanks.  
> > > 
> > > Should be out there now if you want to pull.
> > >   
> > > > > Do you need a tag to pull from?  
> > > > 
> > > > It'd be nice but not essential.  
> > > 
> > > Why do you want/need this?  Having these changes in your tree is good,
> > > but what about other coding style cleanups that I will end up applying
> > > over time before the 5.12-rc1 merge window opens?  Are you wanting to
> > > take the moved driver in your tree, or something else?
> > > 
> > > Traditionally moving drivers out of staging can be done 2 ways:
> > > 	- all happens in the staging tree, I take an ack from the
> > > 	  subsystem maintainer that this is ok to do.
> > > 	- A new driver enters the "real" subsystem tree, and then I
> > > 	  delete the driver in the staging tree.  This doesn't preserve
> > > 	  history as well (not at all), but can be easier for trees that
> > > 	  move quickly (like networking.)
> > > 
> > > Which ever works for you is fine with me, but relying on the code to
> > > stay "not touched" in my tree after you pull it almost never happens due
> > > to the number of drive-by coding style cleanups that end up in the
> > > staging tree every week.  
> > 
> > I would have expected the whole set to be merged as a set into a
> > single tree, placed on an immutable branch and a pull-request to be
> > sent out for the other maintainers to pull from (if they so wished).
> > 
> > This would ensure development could continue on any/all of the
> > affected drivers/files.
> > 
> > If it's not too late, I'd be more than happy to facilitate.  
> 
> Given these patches are already in my public tree, that might be a bit
> harder, why the huge work for this?  Worst case, I just keep all of the
> patches that do not actually move the code in my tree, and then things
> can move after 5.12-rc1.

Whatever works best for Lee/Mark.

From my side, I can re-submit the move patches and the DTS ones to
be applied after 5.12-rc1, if this would be the preferred way.

Thanks,
Mauro