Linux ARM-MSM sub-architecture
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: devel@driverdev.osuosl.org, devicetree@vger.kernel.org,
	Mayulong <mayulong1@huawei.com>,
	Mauro Carvalho Chehab <mchehab+huawei@kernel.org>,
	linux-arm-msm@vger.kernel.org, YueHaibing <yuehaibing@huawei.com>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Wei Xu <xuwei5@hisilicon.com>,
	linux-kernel@vger.kernel.org, Stephen Boyd <sboyd@kernel.org>,
	Rob Herring <robh+dt@kernel.org>,
	linux-arm-kernel@lists.infradead.org,
	Colin Ian King <colin.king@canonical.com>,
	Lee Jones <lee.jones@linaro.org>,
	Dan Carpenter <dan.carpenter@oracle.com>
Subject: Re: [PATCH v5 00/21] Move Hisilicon 6421v600 SPMI driver set out of staging
Date: Wed, 27 Jan 2021 12:04:26 +0000	[thread overview]
Message-ID: <20210127120426.GB4387@sirena.org.uk> (raw)
In-Reply-To: <YBErBByYD8lNIWAX@kroah.com>

[-- 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 --]

  parent reply	other threads:[~2021-01-27 12:08 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-21  7:18 [PATCH v5 00/21] Move Hisilicon 6421v600 SPMI driver set out of staging Mauro Carvalho Chehab
2021-01-21  7:18 ` [PATCH v5 18/21] spmi: hisi-spmi-controller: move driver from staging Mauro Carvalho Chehab
2021-01-26 17:54 ` [PATCH v5 00/21] Move Hisilicon 6421v600 SPMI driver set out of staging Greg Kroah-Hartman
2021-01-26 17:57   ` Mark Brown
2021-01-26 18:02     ` Greg Kroah-Hartman
2021-01-26 18:11       ` Mark Brown
2021-01-27  8:57         ` Greg Kroah-Hartman
2021-01-27 10:08           ` Lee Jones
2021-01-27 10:19             ` Greg Kroah-Hartman
2021-01-27 17:41               ` Mauro Carvalho Chehab
2021-01-27 12:04           ` Mark Brown [this message]
2021-01-27 13:32             ` Greg Kroah-Hartman
2021-01-27 17:27               ` Mark Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210127120426.GB4387@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=colin.king@canonical.com \
    --cc=dan.carpenter@oracle.com \
    --cc=devel@driverdev.osuosl.org \
    --cc=devicetree@vger.kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=lee.jones@linaro.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mayulong1@huawei.com \
    --cc=mchehab+huawei@kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=sboyd@kernel.org \
    --cc=xuwei5@hisilicon.com \
    --cc=yuehaibing@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox