Revert "mach-msm: acpuclock 7627: enabled 98 Mhz"

This reverts commit 567b3f3d375d2b30b098a25a8b4281701472aa67.
scripts: MERGED various commits

-----

scripts: only set CROSS_COMPILE when unset to begin with

Don't mess with CROSS_COMPILE if it's already set up in the user's
environment. This allows the user to specify the cross compiler that
they wish to use.

Change-Id: I15873f79a30e1da91ee34eb31c713e5cd767c372
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>

---

ARM: convert build of appended dtb zImage to list of dtbs

Allow CONFIG_BUILD_ARM_APPENDED_DTB_IMAGE_NAMES to specify
a space separated list of dtbs to append to the zImage,
and name the resulting file zImage-dtb

Change-Id: I36d9108a2349bdbb373e95076dcb1417d8c7dce6
Signed-off-by: Colin Cross <ccross@android.com>
Git-commit: 6a3b63009b2fe3b025a88e8a0a5bcea145dda131
Git-repo: https://android.googlesource.com/kernel/common/
[mittals@codeaurora.org: resolve trivial merge conflicts]
Signed-off-by: Shashank Mittal <mittals@codeaurora.org>

---

script: dtc: clean generated files

Fix "make distclean" to clean up generated dtc files.

Without this patch the following files are left around:
 - dtc-lexer.lex.c
 - dtc-parser.tab.c
 - dtc-parser.tab.h

Change-Id: I0dd3b4804bd244827b02be9446f239b5bfef3d0c
Signed-off-by: Magnus Damm <damm@opensource.se>
Reviewed-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Git-commit: 4f3be1cfa8422c93271dcdb59f223f6c84c70804
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Signed-off-by: David Collins <collinsd@codeaurora.org>

---

scripts: Build dtbs as part of 'all' builds

Make sure to build the dtb targets so that these are tested as part of
building all targets.

Change-Id: I351527d197ef6a60fefe43f3a16b34be86a74dd1
Signed-off-by: David Brown <davidb@codeaurora.org>

---

scripts: Build make targets sequentially.

Added omap2 to the list of defconfigs to scan.
Install headers and kernel modules to separate staging directories
by setting values for INSTALL_HDR_PATH and INSTALL_MOD_PATH.
Build make targets sequentially instead all on one invocation.

Signed-off-by: Andrew Walker <andreww@codeaurora.org>
Change-Id: I87dae363bd536808a74ff368b905d18ae11607b2

---

checkpatch: Add +x check on Device Tree source files

dts and dtsi files should not be given +x permissions.

Change-Id: I23fa5d4012f935f64975471bd6c023b141cde45b
Signed-off-by: Michael Bohan <mbohan@codeaurora.org>

---

checkpatch: Excuse reverts from "summary line over 75 characters" check

Rather than forcing authors of reverts to truncate the summary line
because the "Revert" prefix added pushes it over the character limit,
excuse reverts from this rule.

Change-Id: I395dfff3327e360ef935d4a685c38df6577e3867
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>

---

checkpatch: strlen and strcmp should not be banned

Software security is an important issue, in general, but it is
especially important in Linux kernel code.  Buffer overflows can have
wide-reaching ramifications and can often be readily exploited to
compromise the entire system.  It is important for every developer to
be aware of security issues while writing code.

However, I've noticed a few "rules" about coding that are resulting in
code that isn't any more secure, and has the disadvantage of obscuring
what the code is doing.  In most instances, the "corrected" code is
actually wrong: we've traded a perceived lack of safety for incorrect
behavior.  These obfuscations also make this code more distant from
upstream kernel standards.

I'm only going to focus here on strcmp/strncmp and strlen/strnlen.  I
choose these two, because in the context of the kernel, it's not easy
to make a general rule, such as "always use the 'n' variant".  These
function have different behavior, and the 'n' isn't just a blanket fix
that makes them better.  In many instances, the correct call is the
plain variant (strcpy has a strlcpy variant which is usually helpful).

Let's start with strlen/strnlen.

	size_t strlen(const char *);
	size_t strnlen(const char *, size_t);

The strlen() function scans for a NUL byte within a string, and
returns the number of characters that had to be skipped to get there.

The strnlen() call is similar, but will stop after after a maximal
number of characters, and return that result.  This variant was
intended for storing variable length strings in fixed-sized buffers,
where the full-length case did not have a trailing NUL.  This storage
model is very uncommon, as is the use of strnlen().

The question becomes, what is the maximal length you should be giving
to strnlen().  If the string is truly variable length (allocated and
filled), there really isn't a meaningful value to use for this.  The
only time that a max length makes sense is when you have something
like:

	char name[MAX_NAME_LENGTH];

but, in this case, strnlen() is still probably not what you want to be
using.  It would be safe to use, if you check the result, and if it is
MAX_NAME_LENGTH, raise some kind of error case.  If later code assumes
there is a NUL at the end, there will still be a buffer overflow.  In
this case, it is much better to check the length before storing it in
this field, and make sure there is room for the NUL.

If the string is a constant, passing in a length doesn't make sense,
since you would have to know the length of the string to check that.
There is no safety issue with calling strlen() on a constant.

So, the simple rule for strnlen()/strlen() is:

  - If the string doesn't have an obvious bound length, such as an
    allocated string, use strlen().

  - If the string is a constant, use strlen().

  - If there is a fixed buffer, strnlen() might make sense, but it is
    probably better to change the design to avoid these types of
    strings.

The only case where strnlen really makes sense is when you have a
string that is passed in from the user.  In this case, it is very
important to check the result, and if the length is at the maximum,
return an error, and don't try to do any processing on the string.

Moving on to strcmp/strncmp.  These functions are similar, except that
they take two string arguments, which gives a lot more combinations.

	int strcmp(const char *, const char *);
	int strncmp(const char *, const char *, size_t);

These will walk both strings (at the same time), and stop when
reaching the first difference between them.  This means that they will
never go further than the length of the shortest string being
compared.  As in strnlen, the max argument to strncmp sets a limit on
the comparison.  Similar to strnlen, the results are unusual when the
limit is reached, but in a sense, even worse, since it may consider
the strings equal without ever reaching the end of either.

Looking over the 200 some uses of strncmp in the msm code, almost all
of them do something akin to:

	strncmp(value, constant, strlen(constant))

If the call has added 1 to the 'strlen' result, the strncmp would just
become an inefficient, but otherwise identical version of strcmp.
However, without the +1, this compares the prefix of 'value' instead
of the entire string.  Only one instance of strncmp in the code
appears to be intentionally checking for a prefix.  The rest have
changed a simple string compare into an unintentional prefix match.

Because there are two strings, it is a little more complex to
determine which to use, but it is very similar.  It might seem that
strncmp() would be useful for checking an unknown buffer (say from
userspace).  However, since strncmp()'s result doesn't distinguish
between finding the end of the string, or hitting the max, there's no
way to know.  Some guidelines:

  - If one of the strings has a known bound length (such as a
    constant, or another string whose length has already been
    checked), AND this bound length is within the expected buffer of
    the other string, it is safe to use strcmp().

  - Otherwise, you may need to use something like strnlen() to
    determine a maximum length before calling strcmp().

  - strncmp() is useful to test a string for a prefix.  No other uses
    make sense.

To facilitate fixing these, remove strlen(), strcmp(), and
strcasecmp() from the list of calls that are banned.  Problems with
these calls need to be caught at a higher level (such as review), and
replacing them with the 'n' variants doesn't help anything.

This will be followed by some patches that fixup the incorrect code
introduced by this "ban".

Change-Id: I77dfe1f2f58e8c951e4b38b23f4ec79f8209b1dc
Signed-off-by: David Brown <davidb@codeaurora.org>
Revert "scripts/kallsyms: filter symbols not in kernel address space"

This reverts commit 32d2cde124606ee2241c692bf57db36ea95690b8.
*kernel panic fix*