Patched in Tegra support.

1 files changed, 4 insertions, 55 deletions

diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle
index 495e5ba1634..c940239d967 100644
--- a/Documentation/CodingStyle
+++ b/Documentation/CodingStyle
@@ -166,8 +166,8 @@ if (condition)
 else
         do_that();
 
-This does not apply if only one branch of a conditional statement is a single
-statement; in the latter case use braces in both branches:
+This does not apply if one branch of a conditional statement is a single
+statement. Use braces in both branches.
 
 if (condition) {
         do_this();
@@ -454,16 +454,6 @@ The preferred style for long (multi-line) comments is:
          * with beginning and ending almost-blank lines.
          */
 
-For files in net/ and drivers/net/ the preferred style for long (multi-line)
-comments is a little different.
-
-        /* The preferred comment style for files in net/ and drivers/net
-         * looks like this.
-         *
-         * It is nearly the same as the generally preferred comment style,
-         * but there is no initial almost-blank line.
-         */
-
 It's also important to comment data, whether they are basic types or derived
 types.  To this end, use just one data declaration per line (no commas for
 multiple data declarations).  This leaves you room for a small comment on each
@@ -681,9 +671,8 @@ ones already enabled by DEBUG.
                 Chapter 14: Allocating memory
 
 The kernel provides the following general purpose memory allocators:
-kmalloc(), kzalloc(), kmalloc_array(), kcalloc(), vmalloc(), and
-vzalloc().  Please refer to the API documentation for further information
-about them.
+kmalloc(), kzalloc(), kcalloc(), vmalloc(), and vzalloc().  Please refer to
+the API documentation for further information about them.
 
 The preferred form for passing a size of a struct is the following:
 
@@ -697,17 +686,6 @@ Casting the return value which is a void pointer is redundant. The conversion
 from void pointer to any other pointer type is guaranteed by the C programming
 language.
 
-The preferred form for allocating an array is the following:
-
-        p = kmalloc_array(n, sizeof(...), ...);
-
-The preferred form for allocating a zeroed array is the following:
-
-        p = kcalloc(n, sizeof(...), ...);
-
-Both forms check for overflow on the allocation size n * sizeof(...),
-and return NULL if that occurred.
-
 
                 Chapter 15: The inline disease
 
@@ -815,35 +793,6 @@ own custom mode, or may have some other magic method for making indentation
 work correctly.
 
 
-                Chapter 19:  Inline assembly
-
-In architecture-specific code, you may need to use inline assembly to interface
-with CPU or platform functionality.  Don't hesitate to do so when necessary.
-However, don't use inline assembly gratuitously when C can do the job.  You can
-and should poke hardware from C when possible.
-
-Consider writing simple helper functions that wrap common bits of inline
-assembly, rather than repeatedly writing them with slight variations.  Remember
-that inline assembly can use C parameters.
-
-Large, non-trivial assembly functions should go in .S files, with corresponding
-C prototypes defined in C header files.  The C prototypes for assembly
-functions should use "asmlinkage".
-
-You may need to mark your asm statement as volatile, to prevent GCC from
-removing it if GCC doesn't notice any side effects.  You don't always need to
-do so, though, and doing so unnecessarily can limit optimization.
-
-When writing a single inline assembly statement containing multiple
-instructions, put each instruction on a separate line in a separate quoted
-string, and end each string except the last with \n\t to properly indent the
-next instruction in the assembly output:
-
-        asm ("magic %reg1, #42\n\t"
-             "more_magic %reg2, %reg3"
-             : /* outputs */ : /* inputs */ : /* clobbers */);
-
-
 
                 Appendix I: References