Em Wed, 27 Jan 2021 11:19:36 +0100
Greg Kroah-Hartman [off-list ref] escreveu:

quoted

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:

quoted

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

quoted

On Tue, Jan 26, 2021 at 06:11:24PM +0000, Mark Brown wrote:  

quoted

On Tue, Jan 26, 2021 at 07:02:39PM +0100, Greg Kroah-Hartman wrote:  

quoted

On Tue, Jan 26, 2021 at 05:57:52PM +0000, Mark Brown wrote:  

quoted

quoted

Is there a branch we can pull from?  

quoted

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.
  

quoted

quoted

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