Please add PTR_RET tree.

Temporary branch for PTR_RET -> PTR_ERR_OR_ZERO and associated cleanups.

git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux.git PTR_RET

Log appended. Contributors and people who didn't already ack CC'd.

Cheers,
Rusty.

commit 6e8b8726ad503214ba66e34aed69aff41de33489

Author: Rusty Russell <[email protected]>
Date:   Mon Jul 15 11:19:32 2013 +0930

PTR_RET is now PTR_ERR_OR_ZERO

True, it's often used in return statements, but after much bikeshedding it's probably better to have an explicit name.

(I tried just putting the IS_ERR check inside PTR_ERR itself and gcc usually generated no more code. But that clashes current expectations of how PTR_ERR behaves, so having a separate function is better).

commit 8c6ffba0eddc8c110dbf444f51354ce42069abfc

Author: Rusty Russell <[email protected]>
Date:   Mon Jul 15 11:20:32 2013 +0930

PTR_RET is now PTR_ERR_OR_ZERO(): Replace most.

Sweep of the simple cases.

commit 228b82211b47b597fa75dff2ac146b40eaaddf18

Author: Rusty Russell <[email protected]>
Date:   Mon Jul 15 11:21:32 2013 +0930

s390: Replace weird use of PTR_RET.

Saves repeating "(void __force *)__uptr" but it's less clear. Using the output of PTR_RET() to determine the error rather than just testing IS_ERR() is odd.

For example, I *assume* __gptr_to_uptr() never returns NULL? Because the __ret would be 0 for the old code. The new version is clearer, IMHO:
it would try to get_user() on that address.

If you hate this variant, I can just s/PTR_RET/PTR_ERR_OR_ZERO/ instead.

commit 5d7e438629413586ab78779751caa6e713c2234c

Author: Rusty Russell <[email protected]>
Date:   Mon Jul 15 11:22:32 2013 +0930

acpi: Replace weird use of PTR_RET.

This functions is really weird. It sets rc to -ENOMEM, then overrides it. It was converted to PTR_RET in a1458187 when it should have simply been rewritten.

This version makes it more explicit, with a single IS_ERR() test.

commit 5795c6ac7c77dc2363c41948cf828916c17cf78f

Author: Rusty Russell <[email protected]>
Date:   Mon Jul 15 11:23:32 2013 +0930

pinctrl: don't use PTR_RET().

We've already tested that it's an error.

commit 60d676c007964576e83d791fc0908af8d133519f

Author: Rusty Russell <[email protected]>
Date:   Mon Jul 15 11:24:08 2013 +0930

remoteproc: don't use PTR_RET().

We've already tested that it's an error.

commit 8a1d41cfeaf59a07acc7b1b3620ad6aa5cf47dc2

Author: Rusty Russell <[email protected]>
Date:   Mon Jul 15 11:24:08 2013 +0930

staging/zcache: don't use PTR_RET().

We've already tested that it's an error.

commit 6b4f2b56a48c8ea9775bd2b29681725d4474367a

Author: Rusty Russell <[email protected]>
Date:   Mon Jul 15 11:24:08 2013 +0930

mm/oom_kill: remove weird use of ERR_PTR()/PTR_ERR().

The normal expectation for ERR_PTR() is to put a negative errno into a pointer. oom_kill puts the magic -1 in the result (and has since pre-git), which is probably clearer with an explicit cast.

Hi Rusty,

Added from tomorrow.

Thanks for adding your subsystem tree as a participant of linux-next. As you may know, this is not a judgment of your code. The purpose of linux-next is for integration testing and to lower the impact of conflicts between subsystems in the next merge window.

You will need to ensure that the patches/commits in your tree/series have been:
* submitted under GPL v2 (or later) and include the Contributor's Signed-off-by,
* posted to the relevant mailing list,
* reviewed by you (or another maintainer of your subsystem tree),
* successfully unit tested, and
* destined for the current or next Linux merge window.

Basically, this should be just what you would send to Linus (or ask him to fetch). It is allowed to be rebased if you deem it necessary.

Cheers,
Stephen Rothwell 
[email protected]

Legal Stuff:
By participating in linux-next, your subsystem tree contributions are
public and will be included in the linux-next trees.  You may be sent
e-mail messages indicating errors or other issues when the
patches/commits from your subsystem tree are merged and tested in
linux-next.  These messages may also be cross-posted to the linux-next
mailing list, the linux-kernel mailing list, etc.  The linux-next tree
project and IBM (my employer) make no warranties regarding the linux-next
project, the testing procedures, the results, the e-mails, etc.  If you
don't agree to these ground rules, let me know and I'll remove your tree
from participation in linux-next.

Please remove PTR_RET tree, it's merged.

Cheers,
Rusty.

Hi Rusty,

OK, thanks for letting me know.

Cheers,
Stephen Rothwell                    [email protected]