[GIT PULL] Immutable branch between LEDs, MFD and REGULATOR

[GIT PULL] Immutable branch between LEDs, MFD and REGULATOR

[Jacek Anaszewski]

The following changes since commit a188339ca5a396acc588e5851ed7e19f66b0ebd9:

  Linux 5.2-rc1 (2019-05-19 15:47:09 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds.git tags/ti-lmu-led-drivers

for you to fetch changes up to 13f5750a60b923d8f3f0e23902f2ece46dd733d7:

  leds: lm36274: Introduce the TI LM36274 LED driver (2019-05-21 20:34:19 +0200)

----------------------------------------------------------------
TI LMU LED support rework and introduction of two new drivers
with DT bindings:

- leds-lm3697 (entails additions to lm363x-regulator.c)
- leds-lm36274
----------------------------------------------------------------
Dan Murphy (12):
      dt-bindings: mfd: LMU: Add the ramp up/down property
      dt-bindings: mfd: LMU: Add ti,brightness-resolution
      leds: TI LMU: Add common code for TI LMU devices
      dt-bindings: ti-lmu: Modify dt bindings for the LM3697
      mfd: ti-lmu: Remove support for LM3697
      leds: lm3697: Introduce the lm3697 driver
      regulator: lm363x: Make the gpio register enable flexible
      dt-bindings: mfd: Add lm36274 bindings to ti-lmu
      mfd: ti-lmu: Add LM36274 support to the ti-lmu
      regulator: lm363x: Add support for LM36274
      dt-bindings: leds: Add LED bindings for the LM36274
      leds: lm36274: Introduce the TI LM36274 LED driver

 .../devicetree/bindings/leds/leds-lm36274.txt      |  82 +++++
 .../devicetree/bindings/leds/leds-lm3697.txt       |  73 ++++
 Documentation/devicetree/bindings/mfd/ti-lmu.txt   |  88 +++--
 drivers/leds/Kconfig                               |  23 ++
 drivers/leds/Makefile                              |   3 +
 drivers/leds/leds-lm36274.c                        | 174 +++++++++
 drivers/leds/leds-lm3697.c                         | 395 +++++++++++++++++++++
 drivers/leds/leds-ti-lmu-common.c                  | 156 ++++++++
 drivers/mfd/Kconfig                                |   5 +-
 drivers/mfd/ti-lmu.c                               |  23 +-
 drivers/regulator/Kconfig                          |   2 +-
 drivers/regulator/lm363x-regulator.c               |  56 ++-
 include/linux/leds-ti-lmu-common.h                 |  47 +++
 include/linux/mfd/ti-lmu-register.h                |  63 ++--
 include/linux/mfd/ti-lmu.h                         |   5 +-
 15 files changed, 1112 insertions(+), 83 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/leds/leds-lm36274.txt
 create mode 100644 Documentation/devicetree/bindings/leds/leds-lm3697.txt
 create mode 100644 drivers/leds/leds-lm36274.c
 create mode 100644 drivers/leds/leds-lm3697.c
 create mode 100644 drivers/leds/leds-ti-lmu-common.c
 create mode 100644 include/linux/leds-ti-lmu-common.h

Re: [GIT PULL] Immutable branch between LEDs, MFD and REGULATOR

[Mark Brown]

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

On Tue, May 21, 2019 at 10:30:38PM +0200, Jacek Anaszewski wrote:

>       regulator: lm363x: Make the gpio register enable flexible
>       regulator: lm363x: Add support for LM36274

Why have these been applied, I haven't reviewed them?  As far as I can
tell they were sent before the merge window so I'd expect a resend at
this point...

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

Re: [GIT PULL] Immutable branch between LEDs, MFD and REGULATOR

[Dan Murphy]

Mark

On 5/21/19 4:15 PM, Mark Brown wrote:
> On Tue, May 21, 2019 at 10:30:38PM +0200, Jacek Anaszewski wrote:
> 
>>       regulator: lm363x: Make the gpio register enable flexible
>>       regulator: lm363x: Add support for LM36274
> 
> Why have these been applied, I haven't reviewed them?  As far as I can
> tell they were sent before the merge window so I'd expect a resend at
> this point...
> 

You and Liam were cc'd on April 10,2019 for v2 of this patch set.  So I am not sure why the review was missed.

My apologies for not cc'ing you on v4 but there were no change since that time.
I cannot find v3 of this patchset.

The initial patches were sent on April 5, 2019

Dan

Re: [GIT PULL] Immutable branch between LEDs, MFD and REGULATOR

[Mark Brown]

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

On Tue, May 21, 2019 at 07:48:18PM -0500, Dan Murphy wrote:
> On 5/21/19 4:15 PM, Mark Brown wrote:
> > On Tue, May 21, 2019 at 10:30:38PM +0200, Jacek Anaszewski wrote:

> >>       regulator: lm363x: Make the gpio register enable flexible
> >>       regulator: lm363x: Add support for LM36274

> > Why have these been applied, I haven't reviewed them?  As far as I can
> > tell they were sent before the merge window so I'd expect a resend at
> > this point...

> You and Liam were cc'd on April 10,2019 for v2 of this patch set.  So I am not sure why the review was missed.

> My apologies for not cc'ing you on v4 but there were no change since that time.

Perhaps I was busy, perhaps I saw that the series had other problems and
needed a rework as it was so I just waited for the resend in case they
had knock on effects on the regulator patches.

> I cannot find v3 of this patchset.

> The initial patches were sent on April 5, 2019

And not CCed to maintainers...  AFAICT I got at most one copy of this
ages ago that needed revisions.

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

Re: [GIT PULL] Immutable branch between LEDs, MFD and REGULATOR

[Jacek Anaszewski]

On 5/21/19 11:15 PM, Mark Brown wrote:
> On Tue, May 21, 2019 at 10:30:38PM +0200, Jacek Anaszewski wrote:
> 
>>        regulator: lm363x: Make the gpio register enable flexible
>>        regulator: lm363x: Add support for LM36274
> 
> Why have these been applied, I haven't reviewed them?  As far as I can
> tell they were sent before the merge window so I'd expect a resend at
> this point...

The patch set have been floating around for some time and besides
the v2 you were cc'ed by Dan, I also poked you a week ago for v4 [1].
Don't be surprised that I assumed you simply don't care.

Still, we're awaiting your comments

[0] https://lkml.org/lkml/2019/4/10/547
[1] https://lkml.org/lkml/2019/5/14/717

-- 
Best regards,
Jacek Anaszewski

Re: [GIT PULL] Immutable branch between LEDs, MFD and REGULATOR

[Mark Brown]

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

On Wed, May 22, 2019 at 08:27:32PM +0200, Jacek Anaszewski wrote:
> On 5/21/19 11:15 PM, Mark Brown wrote:
> > On Tue, May 21, 2019 at 10:30:38PM +0200, Jacek Anaszewski wrote:

> > >        regulator: lm363x: Make the gpio register enable flexible
> > >        regulator: lm363x: Add support for LM36274

> > Why have these been applied, I haven't reviewed them?  As far as I can
> > tell they were sent before the merge window so I'd expect a resend at
> > this point...

> The patch set have been floating around for some time and besides

Most of that time as far as I can tell they weren't being posted to
subsystem maintainers, you can't expect people to be aware of patches
that they are not being sent and single postings get missed or dropped
for all sorts of reasons.

> the v2 you were cc'ed by Dan, I also poked you a week ago for v4 [1].

That post from a week ago was you copying me into a thread I wasn't CCed
on saying I should have been sent the patches.  My expectation would
therefore be that someone would send me the patches, I'm obviously going
to prioritize patches that actually get sent to me over ones where I
have to go searching to try to turn up copies.

> Don't be surprised that I assumed you simply don't care.

You have unreasonable expectations here.  At the very least I would have
expected something along the lines of "hey, you don't seem to have
looked at these" before you just applied things, and ideally ensuring
that the patches had actually been sent to everyone with a reasonable
lead time so there was a good chance that review could happen.

> Still, we're awaiting your comments

If someone sends me the patches...

> [0] https://lkml.org/lkml/2019/4/10/547
> [1] https://lkml.org/lkml/2019/5/14/717

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

Re: [GIT PULL] Immutable branch between LEDs, MFD and REGULATOR

[Jacek Anaszewski]

On 5/22/19 9:02 PM, Mark Brown wrote:
> On Wed, May 22, 2019 at 08:27:32PM +0200, Jacek Anaszewski wrote:
>> On 5/21/19 11:15 PM, Mark Brown wrote:
>>> On Tue, May 21, 2019 at 10:30:38PM +0200, Jacek Anaszewski wrote:
> 
>>>>         regulator: lm363x: Make the gpio register enable flexible
>>>>         regulator: lm363x: Add support for LM36274
> 
>>> Why have these been applied, I haven't reviewed them?  As far as I can
>>> tell they were sent before the merge window so I'd expect a resend at
>>> this point...
> 
>> The patch set have been floating around for some time and besides
> 
> Most of that time as far as I can tell they weren't being posted to
> subsystem maintainers, you can't expect people to be aware of patches
> that they are not being sent and single postings get missed or dropped
> for all sorts of reasons.
> 
>> the v2 you were cc'ed by Dan, I also poked you a week ago for v4 [1].
> 
> That post from a week ago was you copying me into a thread I wasn't CCed
> on saying I should have been sent the patches.  My expectation would
> therefore be that someone would send me the patches, I'm obviously going
> to prioritize patches that actually get sent to me over ones where I
> have to go searching to try to turn up copies.

I admit I should have CC'ed you the exact patches and not only
the cover letter.

>> Don't be surprised that I assumed you simply don't care.
> 
> You have unreasonable expectations here.  At the very least I would have
> expected something along the lines of "hey, you don't seem to have
> looked at these" before you just applied things, and ideally ensuring
> that the patches had actually been sent to everyone with a reasonable
> lead time so there was a good chance that review could happen.

In fact you were notified only of v2 of the patch set AFAICS.
There is indeed a chance it might have gone unnoticed through
your mailbox (or classified otherwise).

I need to be more wary in such cases in the future.

>> Still, we're awaiting your comments
> 
> If someone sends me the patches...
> 
>> [0] https://lkml.org/lkml/2019/4/10/547
>> [1] https://lkml.org/lkml/2019/5/14/717

-- 
Best regards,
Jacek Anaszewski

Re: [GIT PULL] Immutable branch between LEDs, MFD and REGULATOR

[Lee Jones]

On Tue, 21 May 2019, Jacek Anaszewski wrote:

> The following changes since commit a188339ca5a396acc588e5851ed7e19f66b0ebd9:
> 
>   Linux 5.2-rc1 (2019-05-19 15:47:09 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds.git tags/ti-lmu-led-drivers
> 
> for you to fetch changes up to 13f5750a60b923d8f3f0e23902f2ece46dd733d7:
> 
>   leds: lm36274: Introduce the TI LM36274 LED driver (2019-05-21 20:34:19 +0200)
> 
> ----------------------------------------------------------------
> TI LMU LED support rework and introduction of two new drivers
> with DT bindings:
> 
> - leds-lm3697 (entails additions to lm363x-regulator.c)
> - leds-lm36274
> ----------------------------------------------------------------
> Dan Murphy (12):

>       dt-bindings: mfd: LMU: Add the ramp up/down property
>       dt-bindings: mfd: LMU: Add ti,brightness-resolution
>       mfd: ti-lmu: Remove support for LM3697
>       mfd: ti-lmu: Add LM36274 support to the ti-lmu

These patches were Acked "for my own reference", which means I'd
at least expect a discussion on how/where they would be applied.

It's fine for them to go in via the LED tree in this instance and I do
thank you for sending a PR.  Next time can we at least agree on the
route-in though please?

>       leds: TI LMU: Add common code for TI LMU devices
>       dt-bindings: ti-lmu: Modify dt bindings for the LM3697
>       leds: lm3697: Introduce the lm3697 driver
>       regulator: lm363x: Make the gpio register enable flexible
>       dt-bindings: mfd: Add lm36274 bindings to ti-lmu
>       regulator: lm363x: Add support for LM36274
>       dt-bindings: leds: Add LED bindings for the LM36274
>       leds: lm36274: Introduce the TI LM36274 LED driver
> 
>  .../devicetree/bindings/leds/leds-lm36274.txt      |  82 +++++
>  .../devicetree/bindings/leds/leds-lm3697.txt       |  73 ++++
>  Documentation/devicetree/bindings/mfd/ti-lmu.txt   |  88 +++--
>  drivers/leds/Kconfig                               |  23 ++
>  drivers/leds/Makefile                              |   3 +
>  drivers/leds/leds-lm36274.c                        | 174 +++++++++
>  drivers/leds/leds-lm3697.c                         | 395 +++++++++++++++++++++
>  drivers/leds/leds-ti-lmu-common.c                  | 156 ++++++++
>  drivers/mfd/Kconfig                                |   5 +-
>  drivers/mfd/ti-lmu.c                               |  23 +-
>  drivers/regulator/Kconfig                          |   2 +-
>  drivers/regulator/lm363x-regulator.c               |  56 ++-
>  include/linux/leds-ti-lmu-common.h                 |  47 +++
>  include/linux/mfd/ti-lmu-register.h                |  63 ++--
>  include/linux/mfd/ti-lmu.h                         |   5 +-
>  15 files changed, 1112 insertions(+), 83 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/leds/leds-lm36274.txt
>  create mode 100644 Documentation/devicetree/bindings/leds/leds-lm3697.txt
>  create mode 100644 drivers/leds/leds-lm36274.c
>  create mode 100644 drivers/leds/leds-lm3697.c
>  create mode 100644 drivers/leds/leds-ti-lmu-common.c
>  create mode 100644 include/linux/leds-ti-lmu-common.h

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

Re: [GIT PULL] Immutable branch between LEDs, MFD and REGULATOR

[Jacek Anaszewski]

On 5/22/19 7:42 AM, Lee Jones wrote:
> On Tue, 21 May 2019, Jacek Anaszewski wrote:
> 
>> The following changes since commit a188339ca5a396acc588e5851ed7e19f66b0ebd9:
>>
>>    Linux 5.2-rc1 (2019-05-19 15:47:09 -0700)
>>
>> are available in the git repository at:
>>
>>    git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds.git tags/ti-lmu-led-drivers
>>
>> for you to fetch changes up to 13f5750a60b923d8f3f0e23902f2ece46dd733d7:
>>
>>    leds: lm36274: Introduce the TI LM36274 LED driver (2019-05-21 20:34:19 +0200)
>>
>> ----------------------------------------------------------------
>> TI LMU LED support rework and introduction of two new drivers
>> with DT bindings:
>>
>> - leds-lm3697 (entails additions to lm363x-regulator.c)
>> - leds-lm36274
>> ----------------------------------------------------------------
>> Dan Murphy (12):
> 
>>        dt-bindings: mfd: LMU: Add the ramp up/down property
>>        dt-bindings: mfd: LMU: Add ti,brightness-resolution
>>        mfd: ti-lmu: Remove support for LM3697
>>        mfd: ti-lmu: Add LM36274 support to the ti-lmu
> 
> These patches were Acked "for my own reference", which means I'd
> at least expect a discussion on how/where they would be applied.
> 
> It's fine for them to go in via the LED tree in this instance and I do
> thank you for sending a PR.  Next time can we at least agree on the
> route-in though please?

Usually ack from the colliding subsystem maintainer means he
acknowledges the patch and gives silent approval for merging
it via the other tree.

This is the usual workflow e.g. in case of massive reworks
of commonly shared kernel APIs.

Your Acked-for-MFD-by tag is not documented anywhere and I've just
found out about its exact meaning :-) Note also that it percolated
to the mainline git history probably because people mistakenly assumed
it was some new convention (despite that checkpatch.pl complains about
it). So far there are 12 occurrences thereof in git. I must admit that
I once unduly made my contribution to that mess.

Of course, now being taught about the exact meaning of the tag,
I will proceed accordingly.

Regarding this one - please hold on for a while with pulling
the stuff, since we may have some updates from REGULATOR maintainers
(hopefully Acked-by).

-- 
Best regards,
Jacek Anaszewski

Re: [GIT PULL] Immutable branch between LEDs, MFD and REGULATOR

[Lee Jones]

On Wed, 22 May 2019, Jacek Anaszewski wrote:

> On 5/22/19 7:42 AM, Lee Jones wrote:
> > On Tue, 21 May 2019, Jacek Anaszewski wrote:
> > 
> > > The following changes since commit a188339ca5a396acc588e5851ed7e19f66b0ebd9:
> > > 
> > >    Linux 5.2-rc1 (2019-05-19 15:47:09 -0700)
> > > 
> > > are available in the git repository at:
> > > 
> > >    git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds.git tags/ti-lmu-led-drivers
> > > 
> > > for you to fetch changes up to 13f5750a60b923d8f3f0e23902f2ece46dd733d7:
> > > 
> > >    leds: lm36274: Introduce the TI LM36274 LED driver (2019-05-21 20:34:19 +0200)
> > > 
> > > ----------------------------------------------------------------
> > > TI LMU LED support rework and introduction of two new drivers
> > > with DT bindings:
> > > 
> > > - leds-lm3697 (entails additions to lm363x-regulator.c)
> > > - leds-lm36274
> > > ----------------------------------------------------------------
> > > Dan Murphy (12):
> > 
> > >        dt-bindings: mfd: LMU: Add the ramp up/down property
> > >        dt-bindings: mfd: LMU: Add ti,brightness-resolution
> > >        mfd: ti-lmu: Remove support for LM3697
> > >        mfd: ti-lmu: Add LM36274 support to the ti-lmu
> > 
> > These patches were Acked "for my own reference", which means I'd
> > at least expect a discussion on how/where they would be applied.
> > 
> > It's fine for them to go in via the LED tree in this instance and I do
> > thank you for sending a PR.  Next time can we at least agree on the
> > route-in though please?
> 
> Usually ack from the colliding subsystem maintainer means he
> acknowledges the patch and gives silent approval for merging
> it via the other tree.

Usually the type of Ack you mention takes this form:

  Acked-by: Lee Jones <lee.jones@linaro.org>

However, the one I provided looks like this:

  For my own reference:
    Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>

Which clearly says "for my own reference" and not to be taken as an
indication that it's okay for the patch(es) to go in via another
tree.

> This is the usual workflow e.g. in case of massive reworks
> of commonly shared kernel APIs.
> 
> Your Acked-for-MFD-by tag is not documented anywhere and I've just
> found out about its exact meaning :-) Note also that it percolated
> to the mainline git history probably because people mistakenly assumed
> it was some new convention (despite that checkpatch.pl complains about
> it). So far there are 12 occurrences thereof in git. I must admit that
> I once unduly made my contribution to that mess.

Being MFD maintainer presents an uncommon and awkward scenario.  MFD
is special in that it means we have to work more cross-subsystem than
most (any?).  The default for MFD related patch-sets which traverse
multiple subsystem is for them to go in via MFD with Acks from all the
other maintainers.  I'm always happy to discuss different merge
strategies, but using the MFD repo is the norm.

The Acked-*-by you see above came as a result of a conversation
between myself and Maintainers I work with the most.  It was seen as
the most succinct way of saying that the patch has been reviewed,
whilst providing the least amount of confusion w.r.t. whether it's
okay to be applied to another tree or not.  The "for my own reference"
should be clear enough that I provide that tag for my own purposes,
rather than an okay for others to merge it.

> Of course, now being taught about the exact meaning of the tag,
> I will proceed accordingly.

I'd appreciate that, thank you.

> Regarding this one - please hold on for a while with pulling
> the stuff, since we may have some updates from REGULATOR maintainers
> (hopefully Acked-by).

I haven't pulled this yet, but please bear in mind ...

Once an immutable branch is created, it should never, ever change.  I
think this is the second pull-request I've had from you [0] and the
second one you've wanted to retract.  That should not happen!

This is precisely why I usually find it better for patches to go in
via the MFD tree.

[0] [GIT PULL] LM3532 backlight support improvements and relocation

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

Re: [GIT PULL] Immutable branch between LEDs, MFD and REGULATOR

[Jacek Anaszewski]

On 5/23/19 10:31 AM, Lee Jones wrote:
> On Wed, 22 May 2019, Jacek Anaszewski wrote:
> 
>> On 5/22/19 7:42 AM, Lee Jones wrote:
>>> On Tue, 21 May 2019, Jacek Anaszewski wrote:
>>>
>>>> The following changes since commit a188339ca5a396acc588e5851ed7e19f66b0ebd9:
>>>>
>>>>     Linux 5.2-rc1 (2019-05-19 15:47:09 -0700)
>>>>
>>>> are available in the git repository at:
>>>>
>>>>     git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds.git tags/ti-lmu-led-drivers
>>>>
>>>> for you to fetch changes up to 13f5750a60b923d8f3f0e23902f2ece46dd733d7:
>>>>
>>>>     leds: lm36274: Introduce the TI LM36274 LED driver (2019-05-21 20:34:19 +0200)
>>>>
>>>> ----------------------------------------------------------------
>>>> TI LMU LED support rework and introduction of two new drivers
>>>> with DT bindings:
>>>>
>>>> - leds-lm3697 (entails additions to lm363x-regulator.c)
>>>> - leds-lm36274
>>>> ----------------------------------------------------------------
>>>> Dan Murphy (12):
>>>
>>>>         dt-bindings: mfd: LMU: Add the ramp up/down property
>>>>         dt-bindings: mfd: LMU: Add ti,brightness-resolution
>>>>         mfd: ti-lmu: Remove support for LM3697
>>>>         mfd: ti-lmu: Add LM36274 support to the ti-lmu
>>>
>>> These patches were Acked "for my own reference", which means I'd
>>> at least expect a discussion on how/where they would be applied.
>>>
>>> It's fine for them to go in via the LED tree in this instance and I do
>>> thank you for sending a PR.  Next time can we at least agree on the
>>> route-in though please?
>>
>> Usually ack from the colliding subsystem maintainer means he
>> acknowledges the patch and gives silent approval for merging
>> it via the other tree.
> 
> Usually the type of Ack you mention takes this form:
> 
>    Acked-by: Lee Jones <lee.jones@linaro.org>
> 
> However, the one I provided looks like this:
> 
>    For my own reference:
>      Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> 
> Which clearly says "for my own reference" and not to be taken as an
> indication that it's okay for the patch(es) to go in via another
> tree.
> 
>> This is the usual workflow e.g. in case of massive reworks
>> of commonly shared kernel APIs.
>>
>> Your Acked-for-MFD-by tag is not documented anywhere and I've just
>> found out about its exact meaning :-) Note also that it percolated
>> to the mainline git history probably because people mistakenly assumed
>> it was some new convention (despite that checkpatch.pl complains about
>> it). So far there are 12 occurrences thereof in git. I must admit that
>> I once unduly made my contribution to that mess.
> 
> Being MFD maintainer presents an uncommon and awkward scenario.  MFD
> is special in that it means we have to work more cross-subsystem than
> most (any?).  The default for MFD related patch-sets which traverse
> multiple subsystem is for them to go in via MFD with Acks from all the
> other maintainers.  I'm always happy to discuss different merge
> strategies, but using the MFD repo is the norm.
> 
> The Acked-*-by you see above came as a result of a conversation
> between myself and Maintainers I work with the most.  It was seen as
> the most succinct way of saying that the patch has been reviewed,
> whilst providing the least amount of confusion w.r.t. whether it's
> okay to be applied to another tree or not.  The "for my own reference"
> should be clear enough that I provide that tag for my own purposes,
> rather than an okay for others to merge it.
> 
>> Of course, now being taught about the exact meaning of the tag,
>> I will proceed accordingly.
> 
> I'd appreciate that, thank you.
> 
>> Regarding this one - please hold on for a while with pulling
>> the stuff, since we may have some updates from REGULATOR maintainers
>> (hopefully Acked-by).
> 
> I haven't pulled this yet, but please bear in mind ...
> 
> Once an immutable branch is created, it should never, ever change.  I
> think this is the second pull-request I've had from you [0] and the
> second one you've wanted to retract.  That should not happen!

This is life - it is always possible that some problems will be
detected in linux-next later in the cycle, either by bots or by other
people.

Some time ago I referred to Linus' message from 2017 discouraging
maintainers from cross-merging their trees, which you didn't find
applicable to existing MFD workflow.

Recently Linus put stress on that again [0].

At the occasion of the situation we have currently, I'd like to clarify
if cross-merges between MFD and other subsystems deserve special
treatment.

So please, if you find it reasonable to proceed with these immutable
branches workflow, I would first prefer to see Linus' approval for that.

> This is precisely why I usually find it better for patches to go in
> via the MFD tree.
> 
> [0] [GIT PULL] LM3532 backlight support improvements and relocation
> 

[0] https://lkml.org/lkml/2019/5/8/820

-- 
Best regards,
Jacek Anaszewski

Re: [GIT PULL] Immutable branch between LEDs, MFD and REGULATOR

[Mark Brown]

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

On Thu, May 23, 2019 at 10:07:35PM +0200, Jacek Anaszewski wrote:
> On 5/23/19 10:31 AM, Lee Jones wrote:

> > Once an immutable branch is created, it should never, ever change.  I
> > think this is the second pull-request I've had from you [0] and the
> > second one you've wanted to retract.  That should not happen!

> This is life - it is always possible that some problems will be
> detected in linux-next later in the cycle, either by bots or by other
> people.

If you've created an immutable branch that other people might have
merged you should be doing incremental fixes on top of it and not
changing it unless you've confirmed that nobody else merged it, that's
the whole immutable thing.  If you rebase the commits are still going to
be in other people's trees and will still end up getting merged which
makes a mess.

> Some time ago I referred to Linus' message from 2017 discouraging
> maintainers from cross-merging their trees, which you didn't find
> applicable to existing MFD workflow.

> Recently Linus put stress on that again [0].

There's a difference between just grabbing someone's whole tree and
pulling in a targetted topic branch with only specific overlapping
stuff.  There's also no requirement on people to immediately merge 
such a topic branch, they can always just keep it on file until it 
does become important for dependencies.  A lot of the MFD cross tree
merges are happening because constants introduced in the MFD tree
become build dependencies for other trees.

Historically there were maintainers who just randomly merged people's
entire trees which does cause lots of problems, this isn't that.

> So please, if you find it reasonable to proceed with these immutable
> branches workflow, I would first prefer to see Linus' approval for that.

This is nothing new.

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

Re: [GIT PULL] Immutable branch between LEDs, MFD and REGULATOR

[Jacek Anaszewski]

I've just noticed gmail redirected this message to the Spam folder.
I will have to improve my filters to secure myself against that.

Sorry for late reply and maybe unnecessary escalation of the issue.

On 5/24/19 1:56 PM, Mark Brown wrote:
> On Thu, May 23, 2019 at 10:07:35PM +0200, Jacek Anaszewski wrote:
>> On 5/23/19 10:31 AM, Lee Jones wrote:
> 
>>> Once an immutable branch is created, it should never, ever change.  I
>>> think this is the second pull-request I've had from you [0] and the
>>> second one you've wanted to retract.  That should not happen!
> 
>> This is life - it is always possible that some problems will be
>> detected in linux-next later in the cycle, either by bots or by other
>> people.
> 
> If you've created an immutable branch that other people might have
> merged you should be doing incremental fixes on top of it and not
> changing it unless you've confirmed that nobody else merged it, that's
> the whole immutable thing.  If you rebase the commits are still going to
> be in other people's trees and will still end up getting merged which
> makes a mess.

That's obvious. I checked that the branch wasn't pulled to any of
the affected subsystems. Also double-checked it wasn't present
in linux-next at the time I was dropping the signed tag,
and updating the branch.

>> Some time ago I referred to Linus' message from 2017 discouraging
>> maintainers from cross-merging their trees, which you didn't find
>> applicable to existing MFD workflow.
> 
>> Recently Linus put stress on that again [0].
> 
> There's a difference between just grabbing someone's whole tree and
> pulling in a targetted topic branch with only specific overlapping
> stuff.  There's also no requirement on people to immediately merge
> such a topic branch, they can always just keep it on file until it
> does become important for dependencies.  A lot of the MFD cross tree
> merges are happening because constants introduced in the MFD tree
> become build dependencies for other trees.
> 
> Historically there were maintainers who just randomly merged people's
> entire trees which does cause lots of problems, this isn't that.
> 
>> So please, if you find it reasonable to proceed with these immutable
>> branches workflow, I would first prefer to see Linus' approval for that.
> 
> This is nothing new.

I just wanted to make sure. We will see if Linus will have something
to add.

-- 
Best regards,
Jacek Anaszewski