Merge tag 'arm64-stable' of git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64

Pull ARM64 fixes from Catalin Marinas:
 - Compat register fault reporting fix
 - Documentation clarification on tagged pointers
 - hwcap widened to 64-bit (user space already reading it as 64-bit)

* tag 'arm64-stable' of git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64:
  arm64: Widen hwcap to be 64 bit
  arm64: Correctly report LR and SP for compat tasks
  arm64: documentation: tighten up tagged pointer documentation
  arm64: Make do_bad_area() function static

1 files changed, 7 insertions, 7 deletions

diff --git a/Documentation/arm64/tagged-pointers.txt b/Documentation/arm64/tagged-pointers.txt
index 264e9841563a..d9995f1f51b3 100644
--- a/Documentation/arm64/tagged-pointers.txt
+++ b/Documentation/arm64/tagged-pointers.txt
@@ -18,17 +18,17 @@ this byte for application use, with the following caveats:
             parameters containing user virtual addresses *must* have
             their top byte cleared before trapping to the kernel.
 
-        (2) Tags are not guaranteed to be preserved when delivering
-            signals. This means that signal handlers in applications
-            making use of tags cannot rely on the tag information for
-            user virtual addresses being maintained for fields inside
-            siginfo_t. One exception to this rule is for signals raised
-            in response to debug exceptions, where the tag information
+        (2) Non-zero tags are not preserved when delivering signals.
+            This means that signal handlers in applications making use
+            of tags cannot rely on the tag information for user virtual
+            addresses being maintained for fields inside siginfo_t.
+            One exception to this rule is for signals raised in response
+            to watchpoint debug exceptions, where the tag information
             will be preserved.
 
         (3) Special care should be taken when using tagged pointers,
             since it is likely that C compilers will not hazard two
-            addresses differing only in the upper bits.
+            virtual addresses differing only in the upper byte.
 
 The architecture prevents the use of a tagged PC, so the upper byte will
 be set to a sign-extension of bit 55 on exception return.