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

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 <[email protected]>
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.

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.

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.

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.

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.

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.

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.

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.