fix for "error: implicit declaration of function 'devres_alloc'" in Mar9 tree

fix for "error: implicit declaration of function 'devres_alloc'" in Mar9 tree

[Paul Gortmaker]

There are a couple builds showing:

drivers/base/regmap/regmap.c:331: error: implicit declaration of function 'devres_alloc'
drivers/base/regmap/regmap.c:338: error: implicit declaration of function 'devres_add'
drivers/base/regmap/regmap.c:340: error: implicit declaration of function 'devres_free'
drivers/base/regmap/regmap.c:421: error: implicit declaration of function 'dev_err'
make[4]: *** [drivers/base/regmap/regmap.o] Error 1

This is caused by commit 19694b5ea1d3 which just appeared in today's next
tree exposing another implicit device.h user.  Just a quick note that I'll
take care of it by adding regmap.c to the below commit.

Paul.

---

commit 6382876888313b6c9e2002247d9fa24f02835651
Author: Paul Gortmaker <paul.gortmaker@windriver.com>
Date:   Sun Jan 22 11:23:42 2012 -0500

    device.h: cleanup users outside of linux/include (C files)
    
    For files that are actively using linux/device.h, make sure
    that they call it out.  This will allow us to clean up some
    of the implicit uses of linux/device.h within include/*
    without introducing build regressions.

Re: fix for "error: implicit declaration of function 'devres_alloc'" in Mar9 tree

[Mark Brown]

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

On Fri, Mar 09, 2012 at 10:11:56AM -0500, Paul Gortmaker wrote:

> drivers/base/regmap/regmap.c:421: error: implicit declaration of function 'dev_err'
> make[4]: *** [drivers/base/regmap/regmap.o] Error 1

> This is caused by commit 19694b5ea1d3 which just appeared in today's next
> tree exposing another implicit device.h user.  Just a quick note that I'll
> take care of it by adding regmap.c to the below commit.

No, it's not caused by that - in the subsystem tree there's an explicit
inclusion of linux/device.h in the public header which is what is being
relied on here.  You've gone and deleted that inclusion without CCing
the patch to the subsystem and now you're sending a fix again without a
CC to either me or the relevant list, and without even a mention in the
subject line.

In order to avoid bisection breakage I've applied one of the several
fixes for this that were sent to me today, please drop your change.

This stuff would go a lot more smoothly if you were to at least let
people know when you make changes, especially when issues introduced by
your changes get noticed.

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

Re: fix for "error: implicit declaration of function 'devres_alloc'" in Mar9 tree

[Paul Gortmaker]

On Sun, Mar 11, 2012 at 8:48 AM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Fri, Mar 09, 2012 at 10:11:56AM -0500, Paul Gortmaker wrote:
>
>> drivers/base/regmap/regmap.c:421: error: implicit declaration of function 'dev_err'
>> make[4]: *** [drivers/base/regmap/regmap.o] Error 1
>
>> This is caused by commit 19694b5ea1d3 which just appeared in today's next
>> tree exposing another implicit device.h user.  Just a quick note that I'll
>> take care of it by adding regmap.c to the below commit.
>
> No, it's not caused by that - in the subsystem tree there's an explicit
> inclusion of linux/device.h in the public header which is what is being
> relied on here.  You've gone and deleted that inclusion without CCing
> the patch to the subsystem and now you're sending a fix again without a
> CC to either me or the relevant list, and without even a mention in the
> subject line.

We are talking about a trivial fix here, and the deletion was one of about
fifty similar one-line deletions in include/linux, of which many files don't
even have clear owners.  So, while I can appreciate you wanting a CC,
it just wasn't practical in this case in my opinion.

>
> In order to avoid bisection breakage I've applied one of the several
> fixes for this that were sent to me today, please drop your change.

I don't see how this avoids any bisection breakage -- you've now introduced
a dependency that wasn't there before -- i.e. I would have to make sure
your change is present before my changes get pulled.  In any case I can
just ensure I have the exact same change as you and it will make sure
my series remains bisectable.

>
> This stuff would go a lot more smoothly if you were to at least let
> people know when you make changes, especially when issues introduced by
> your changes get noticed.

I've worked to get at least three different regulator regression fixes in,
None of those were related to any changes I made.  You were on the
to/CC of those fixes, and I even made changes as you requested.  My
point is that I do my best to follow implicit and explicit processes.  If
you've somehow come to conclude otherwise, I'm sorry to hear that.

Paul.

Re: fix for "error: implicit declaration of function 'devres_alloc'" in Mar9 tree

[Mark Brown]

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

On Sun, Mar 11, 2012 at 12:09:39PM -0400, Paul Gortmaker wrote:
> On Sun, Mar 11, 2012 at 8:48 AM, Mark Brown
> > On Fri, Mar 09, 2012 at 10:11:56AM -0500, Paul Gortmaker wrote:

> >> This is caused by commit 19694b5ea1d3 which just appeared in today's next
> >> tree exposing another implicit device.h user.  Just a quick note that I'll
> >> take care of it by adding regmap.c to the below commit.

> > relied on here.  You've gone and deleted that inclusion without CCing
> > the patch to the subsystem and now you're sending a fix again without a
> > CC to either me or the relevant list, and without even a mention in the
> > subject line.

> We are talking about a trivial fix here, and the deletion was one of about
> fifty similar one-line deletions in include/linux, of which many files don't
> even have clear owners.  So, while I can appreciate you wanting a CC,
> it just wasn't practical in this case in my opinion.

The above doesn't just apply to the original patch, it applies even more
strongly to the followup patch where none of the above issues apply.

Honestly I do think that if you made at least some effort to let
subsytem maintainers know about all this header reorganisation you're
doing you'd introduce a lot less breakage, it's hardly surprising that
people keep on developing with the headers they can see.

> > In order to avoid bisection breakage I've applied one of the several
> > fixes for this that were sent to me today, please drop your change.

> I don't see how this avoids any bisection breakage -- you've now introduced
> a dependency that wasn't there before -- i.e. I would have to make sure
> your change is present before my changes get pulled.  In any case I can
> just ensure I have the exact same change as you and it will make sure
> my series remains bisectable.

It will be fine, there's no dependency.  If regmap is merged first
there's obviously no issue as it doesn't have your header faffing in.
If regmap is merged second then the branch that gets pulled will have
Stephen's change applied to it before it gets Linus' tree so no commit
will exist where we've only got your commit which introduces the problem
and no fix.  On the other hand an incremental fix in your tree only
means that if your tree is merged second there will be at least one
commit which is broken.

This applies to any fixups for the fallout from your changes, except in
very rare circumstances adding the extra includes is always going to be
safe in any tree and this means that people working in the tree can see
what's going to be happening, making things less error prone.

> > This stuff would go a lot more smoothly if you were to at least let
> > people know when you make changes, especially when issues introduced by
> > your changes get noticed.

> I've worked to get at least three different regulator regression fixes in,
> None of those were related to any changes I made.  You were on the
> to/CC of those fixes, and I even made changes as you requested.  My
> point is that I do my best to follow implicit and explicit processes.  If
> you've somehow come to conclude otherwise, I'm sorry to hear that.

If you'd CCed me when you noticed the additional breakage from your
change or you'd written followups to the people submitting fixes
normally which said something like "This is due to more header
reorganisations I've done, I've fixed it on my branch see X for details"
things would've worked better.

As it is I was seeing fixes from people which made no sense given the
recent activity in the tree plus followups from you which had no content
other than links (which isn't good practice) to a message which itself
just references git changes things by hash (which is quite bad, commit
IDs aren't directly legible and can change) and had to faff around with
the logs to figure out what you'd done.

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