| Message ID | cover.1611212783.git.mchehab+huawei@kernel.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | Move Hisilicon 6421v600 SPMI driver set out of staging | expand |
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
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?
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
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.
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
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.
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
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.
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
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.
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
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