[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



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[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


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Mark Brown]

[-- Attachment #1.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 #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Mark Brown]

[-- Attachment #1.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 #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Mark Brown]

[-- Attachment #1.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 #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Mark Brown]

[-- Attachment #1.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 #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel