[GIT PULL] regulator updates for v3.13-rc1

[GIT PULL] regulator updates for v3.13-rc1

[Mark Brown]

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

The following changes since commit 6ce4eac1f600b34f2f7f58f9cd8f0503d79e42ae:

  Linux 3.13-rc1 (2013-11-22 11:30:55 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git tags/regulator-v3.13-rc1

for you to fetch changes up to 90ba0813db2c96c82e9ba24f30fb96a24a2cd3a8:

  Merge remote-tracking branch 'regulator/fix/pfuze100' into regulator-linus (2013-11-24 14:02:50 +0000)

----------------------------------------------------------------

regulator: Fixes for v3.13

A bunch of fixes, a few driver specific ones and a framework fix for
voltage enumeration on fixed voltage regulators which had previously
worked but had been misplaced during some refactoring causing problems
for users that needed to know the voltage.

----------------------------------------------------------------
Charles Keepax (1):
      regulator: arizona-micsupp: Correct wm5110 voltage selection

Guennadi Liakhovetski (1):
      regulator: fixed: fix regulator_list_voltage() for regression

Laurent Pinchart (1):
      regulator: gpio-regulator: Don't oops on missing regulator-type property

Mark Brown (4):
      Merge remote-tracking branch 'regulator/fix/arizona' into regulator-linus
      Merge remote-tracking branch 'regulator/fix/fixed' into regulator-linus
      Merge remote-tracking branch 'regulator/fix/gpio' into regulator-linus
      Merge remote-tracking branch 'regulator/fix/pfuze100' into regulator-linus

Tim Harvey (1):
      regulator: pfuze100: allow misprogrammed ID

 drivers/regulator/arizona-micsupp.c    | 54 ++++++++++++++++++++++++++++++++--
 drivers/regulator/core.c               |  3 ++
 drivers/regulator/gpio-regulator.c     |  7 ++++-
 drivers/regulator/pfuze100-regulator.c | 12 ++++++--
 4 files changed, 70 insertions(+), 6 deletions(-)

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [GIT PULL] regulator updates for v3.13-rc1

[Linus Torvalds]

On Mon, Nov 25, 2013 at 9:40 AM, Mark Brown <broonie@kernel.org> wrote:
>
> Mark Brown (4):
>       Merge remote-tracking branch 'regulator/fix/arizona' into regulator-linus
>       Merge remote-tracking branch 'regulator/fix/fixed' into regulator-linus
>       Merge remote-tracking branch 'regulator/fix/gpio' into regulator-linus
>       Merge remote-tracking branch 'regulator/fix/pfuze100' into regulator-linus

Btw, I suspect you could/should have just used an "octopus merge" to
merge these kinds of small independent branches in one go. Just list
all the branches you want to merge for one single "git merge", and
you're done.

I don't necessarily recommend doing that in general, but octopus
merges are actually quite nice for this kind of situation in that it
avoids having excessive empty merge commits. Now we end up having your
four merges, and then my one merge on top: so we have five merges for
four actual fixes. Octopus merges can end up making the history more
readable by avoiding that kind of somewhat excessive merge activity
that you otherwise easily get from having lots of small topic
branches.

But it's up to you. I like seeing topic branches, and that part is
absolutely a good git habit to get into. Octopus merges then have the
upside that they then avoid having lots of pointless small merge
commits to tie them all together, but they can make it slightly more
challenging to figure out what went wrong if problems happen. So in
this case, one option might have been to merge the three independent
driver fixes with one single octopus merge, and then merge the core
fix separately as a normal merge.

Whatever. Not a big deal, I just thought I'd mention it if you perhaps
didn't realize that git happily merges multiple branches at once..

              Linus

Re: [GIT PULL] regulator updates for v3.13-rc1

[Mark Brown]

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

On Mon, Nov 25, 2013 at 01:10:01PM -0800, Linus Torvalds wrote:

> Btw, I suspect you could/should have just used an "octopus merge" to
> merge these kinds of small independent branches in one go. Just list
> all the branches you want to merge for one single "git merge", and
> you're done.

Yes, it's a more accurate reflection of what I'm doing since none of the
individual merges is a meaningful stage in development - either the
topics get used or the final for-linus and for-next merges get used but
not anything in between.  In fact my script originally started off doing
octopus merges but then Takashi complained at me saying you'd get
annoyed so I switched to the stack of merges.

> But it's up to you. I like seeing topic branches, and that part is
> absolutely a good git habit to get into. Octopus merges then have the
> upside that they then avoid having lots of pointless small merge
> commits to tie them all together, but they can make it slightly more
> challenging to figure out what went wrong if problems happen. So in
> this case, one option might have been to merge the three independent
> driver fixes with one single octopus merge, and then merge the core
> fix separately as a normal merge.

> Whatever. Not a big deal, I just thought I'd mention it if you perhaps
> didn't realize that git happily merges multiple branches at once..

If you're OK with octopus merges for things like this I'll definitely
take another look at using them, the enormous stack of merge commits
always looks noisy to me in the logs and pull requests and for things
like driver updates there's unlikely to be much doubt about which branch
it was if there's a problem.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [GIT PULL] regulator updates for v3.13-rc1

[Linus Torvalds]

On Mon, Nov 25, 2013 at 4:39 PM, Mark Brown <broonie@kernel.org> wrote:
>
> If you're OK with octopus merges for things like this I'll definitely
> take another look at using them, the enormous stack of merge commits
> always looks noisy to me in the logs and pull requests and for things
> like driver updates there's unlikely to be much doubt about which branch
> it was if there's a problem.

Yeah, I'm definitely ok with octopus merges, and I do them myself
occasionally (especially with the -tip tree, which I get as many
separate pull requests - see for example commit 669fc2f0c70a).

And various maintainers use them too - Ingo does them for x86, Russell
King does them for ARM, Roland Dreier for infiniband, Paul McKenney
for rcu stuff, etc etc. Len Brown used to do them for ACPI all the
time.

But I do ask people to use them judiciously. Octopus merges are good
for the "many small topic branches" kind of thing. But they should
generally be avoided for big merges.

Obligatory git trick of the day:

    git rev-list --parents HEAD |
        egrep '^.{128}' |
        cut -d' ' -f1 |
        git log --no-walk --stdin --oneline

shows you the octopus merges. A couple of the older ones are bogus and
come from the bad old days when git didn't properly filter parent
lists, so there are redundant parents making a commit _look_ like an
octopus merge even though it's really just merging one branch. Maybe
Takashi hit one of those bugs back when..

                      Linus

Re: [GIT PULL] regulator updates for v3.13-rc1

[Linus Torvalds]

On Mon, Nov 25, 2013 at 4:39 PM, Mark Brown <broonie@kernel.org> wrote:
>
> If you're OK with octopus merges for things like this I'll definitely
> take another look at using them, the enormous stack of merge commits
> always looks noisy to me in the logs and pull requests and for things
> like driver updates there's unlikely to be much doubt about which branch
> it was if there's a problem.

Christ. When you start doing octopus merges, you don't do it by half
measures, do you?

I just pulled the sound updates from Takashi, and as a result got your
merge commit 2cde51fbd0f3. That one has 66 parents.

That kind of merge either needs to be split up, or gitk needs to be
made better about visualizing it, because it ends up being *so* wide
that the history is hard to read.

I think you'll find that having that many parents also breaks old
versions of git.

Anyway, I'd suggest you try to limit octopus merges to ~15 parents or
less to make the visualization tools not go crazy.  Maybe aim for just
10 or so in most cases.

It's pulled, and it's fine, but there's clearly a balance between
"octopus merges are fine" and "Christ, that's not an octopus, that's a
Cthulhu merge".

                Linus

Re: [GIT PULL] regulator updates for v3.13-rc1

[Mark Brown]

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

On Tue, Jan 21, 2014 at 11:16:57AM -0800, Linus Torvalds wrote:
> On Mon, Nov 25, 2013 at 4:39 PM, Mark Brown <broonie@kernel.org> wrote:

> > If you're OK with octopus merges for things like this I'll definitely
> > take another look at using them, the enormous stack of merge commits
> > always looks noisy to me in the logs and pull requests and for things
> > like driver updates there's unlikely to be much doubt about which branch
> > it was if there's a problem.

> Christ. When you start doing octopus merges, you don't do it by half
> measures, do you?

:)  It seems Takashi was right then.

> That kind of merge either needs to be split up, or gitk needs to be
> made better about visualizing it, because it ends up being *so* wide
> that the history is hard to read.

> I think you'll find that having that many parents also breaks old
> versions of git.

> Anyway, I'd suggest you try to limit octopus merges to ~15 parents or
> less to make the visualization tools not go crazy.  Maybe aim for just
> 10 or so in most cases.

Ah, I'd not noticed that one - I tend to find gitk output pretty hard to
work with at the best of times once you hit lots of merges in a short
time unless I limit it to particular subsets of code and once there's
filtering it seems to cope well with both approaches (modulo the detail
on the final merge commit).  Long lived branches that go from -rc1 to
the next merge window aren't at all friendly to visualisation tools.

I can easily limit it, anyway.  Or another option would be to have a
branch which collects the merges incrementally rather than respining
them all the time (but has no development itself) - I *think* that may
be a bit more friendly to visualisation tools if done right but I seem
to recall that such integration only branches were frowned upon?

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [GIT PULL] regulator updates for v3.13-rc1

[Takashi Iwai]

At Tue, 21 Jan 2014 11:16:57 -0800,
Linus Torvalds wrote:
> 
> On Mon, Nov 25, 2013 at 4:39 PM, Mark Brown <broonie@kernel.org> wrote:
> >
> > If you're OK with octopus merges for things like this I'll definitely
> > take another look at using them, the enormous stack of merge commits
> > always looks noisy to me in the logs and pull requests and for things
> > like driver updates there's unlikely to be much doubt about which branch
> > it was if there's a problem.
> 
> Christ. When you start doing octopus merges, you don't do it by half
> measures, do you?
> 
> I just pulled the sound updates from Takashi, and as a result got your
> merge commit 2cde51fbd0f3. That one has 66 parents.
> 
> That kind of merge either needs to be split up, or gitk needs to be
> made better about visualizing it, because it ends up being *so* wide
> that the history is hard to read.

Yep, sorry, it's my fault that I overlooked Medusa there.
I usually check with gitk, but at this time, I checked the results
only via --no-merges option for concentrating on the real changes.
Now I looked at it, and I was turned into sto..n...e......


Takashi

> I think you'll find that having that many parents also breaks old
> versions of git.
> 
> Anyway, I'd suggest you try to limit octopus merges to ~15 parents or
> less to make the visualization tools not go crazy.  Maybe aim for just
> 10 or so in most cases.
> 
> It's pulled, and it's fine, but there's clearly a balance between
> "octopus merges are fine" and "Christ, that's not an octopus, that's a
> Cthulhu merge".
> 
>                 Linus
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: [GIT PULL] regulator updates for v3.13-rc1

[H. Peter Anvin]

On 01/21/2014 11:16 AM, Linus Torvalds wrote:
> On Mon, Nov 25, 2013 at 4:39 PM, Mark Brown <broonie@kernel.org> wrote:
>>
>> If you're OK with octopus merges for things like this I'll definitely
>> take another look at using them, the enormous stack of merge commits
>> always looks noisy to me in the logs and pull requests and for things
>> like driver updates there's unlikely to be much doubt about which branch
>> it was if there's a problem.
> 
> Christ. When you start doing octopus merges, you don't do it by half
> measures, do you?
> 
> I just pulled the sound updates from Takashi, and as a result got your
> merge commit 2cde51fbd0f3. That one has 66 parents.
> 

For sheer amusement value: the tip-bot uses a private git tree to keep
track of what it has mailed and not mailed.  At least once it produced a
243-input octopus merge.

	-hpa