[PATCH 12/15] drivers/regulator: ab8500: Split up probe() into manageable pieces

[broonie@opensource.wolfsonmicro.com (Mark Brown)]

On Mon, May 07, 2012 at 07:04:59PM +0100, Lee Jones wrote:
> On 7 May 2012 17:58, Mark Brown <broonie@opensource.wolfsonmicro.com> wrote:

> > This doesn't apply against current regulator code.

> It doesn't? I rebased it onto -rc5 which was the latest at time of
> submission.

This isn't a bugfix that should be rushed into Linus' tree for 3.4!
You're missing the best part of a release cycle of development here,
including at least one incompatible API change.  

If you're developing new code you should always submit against the tree
it's supposed to be applied to; as a rule of thumb -next is a good
approximation though subsystems do things slightly differently,
especially in the creation of topic branches.  Even where the code will
get applied to Linus' tree then merged as a new topic branch you should
verify that there aren't any other changes in -next that affect it (eg,
an API you rely on having changed or other changes to the same file
which conflict with yours).

> > Please also at least
> > try to use changelogs that match the subsystem you're submitting
> > against.

> What do you mean? Isn't "drivers/regulator" in the subject line enough?

As I said you should use changelogs that match the subsystem you are
submitting against.  Essentially nothing in the regulator tree uses
this, as you should be able to see from inspection of the changelogs:

$ git shortlog next/master drivers/regulator | wc -l
1059
$ git shortlog drivers/regulator | grep drivers/regulator | wc -l
6

Generally everything uses "regulator: ".  You should always make an
effort to do this for whatever subsystem you're working with.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120507/5d89fce0/attachment.sig>