During get clock routine there is a possiblity that clock
index that is used for enable clock routine may become
un-initialized with incorrect clock index which might ind-
use zero isp clocks to be enabled and eventually make an
unclocked access. So, initialize clock index correctly ba-
sed on all combinations of clock names for given target
device tree.
Change-Id: I42cc72db45d29d79a84984b10dbb3c9c8112894b
Signed-off-by: Lokesh Kumar Aakulu <lkumar@codeaurora.org>
In function binder_transaction_priority(), we access
desired_prio before initialzing it.
This patch fix this.
Change-Id: I9d14d50f9a128010476a65b52631630899a44633
Signed-off-by: Ganesh Mahendran <opensource.ganesh@gmail.com>
Delta battery SOC interrupt can fire during boot just after
registering the interrupts before disabling it through vote() on
delta_bsoc_irq_en_votable during driver probe. When this happens,
from the delta_bsoc interrupt handler, an attempt to disable the
interrupt can be made by fg_charge_full_update() if charge_done
is not set. This will in turn acquire the mutex lock of votable
while trying to do disable_irq() which needs synchronization.
Prevent this situation by using disable_irq_nosync() when
disabling the interrupts from votable callbacks.
CRs-Fixed: 2125269
Change-Id: I1b617c4afd39c544ce79f9396030b730c55445a7
Signed-off-by: Subbaraman Narayanamurthy <subbaram@codeaurora.org>
Currently, wait for soc_update completion is attempted once again
only when the wait is interrupted. Try waiting again even when it
is timed out. This should help IMA_ATOMIC transactions go through
reliably.
Change-Id: I8d31fc41020b8c05ff4d562ae205eaa278d7ffcb
Signed-off-by: Subbaraman Narayanamurthy <subbaram@codeaurora.org>
Set TP to display-unblank status when firstly probe up, so that
TP can detect interrupt and report touch event without press
power key.
Change-Id: I6e4ea48551463c6d0f747987d7c255987e3a11df
Signed-off-by: Jin Fu <jinf@codeaurora.org>
In the case of gsi_free_inst() called, whole f_gst structure is freed.
GSI control related API like gsi_ctrl_dev_poll do not check if f_gsi
is freed or not, only check gsi_ctrl_port is NULL or not.
If GSI driver is opened by userspace, gsi_free_inst() is executed,
mark inst_exist to false but do not free instance structures and
deregister misc device until misc device is closed.
Besides, in the GSI control related API read/write/ioctl/poll,
check if GSI instance is freed or not.
Change-Id: I4245964989a1284f5180efb69b64bd63e9104059
Signed-off-by: Liangliang Lu <luliang@codeaurora.org>
In order to support multiple recoveries without WLAN host driver,
clear recovery flag properly for debug state and also move WLAN
host driver ops check to proper place during powerup and shutdown.
Change-Id: I8cb17a495f6106bd07fe29dba282d4168c9f7411
CRs-fixed: 2124999
Signed-off-by: Yue Ma <yuem@codeaurora.org>
Since PCIe bus driver is going to deprecate msm_pcie_recover_config
API, PCIe device driver needs to keep a default copy of PCI config
space after PCI probe which will be used for recovering config space
for SSR and PCI linkdown recovery.
Change-Id: I4fb0db35770d616ad75b8b7329f99fd6a40e9385
CRs-fixed: 2124999
Signed-off-by: Yue Ma <yuem@codeaurora.org>
On systems that use mark-based routing it may be necessary for
routing lookups to use marks in order for packets to be routed
correctly. An example of such a system is Android, which uses
socket marks to route packets via different networks.
Currently, routing lookups in tunnel mode always use a mark of
zero, making routing incorrect on such systems.
This patch adds a new output_mark element to the xfrm state and
a corresponding XFRMA_OUTPUT_MARK netlink attribute. The output
mark differs from the existing xfrm mark in two ways:
1. The xfrm mark is used to match xfrm policies and states, while
the xfrm output mark is used to set the mark (and influence
the routing) of the packets emitted by those states.
2. The existing mark is constrained to be a subset of the bits of
the originating socket or transformed packet, but the output
mark is arbitrary and depends only on the state.
The use of a separate mark provides additional flexibility. For
example:
- A packet subject to two transforms (e.g., transport mode inside
tunnel mode) can have two different output marks applied to it,
one for the transport mode SA and one for the tunnel mode SA.
- On a system where socket marks determine routing, the packets
emitted by an IPsec tunnel can be routed based on a mark that
is determined by the tunnel, not by the marks of the
unencrypted packets.
- Support for setting the output marks can be introduced without
breaking any existing setups that employ both mark-based
routing and xfrm tunnel mode. Simply changing the code to use
the xfrm mark for routing output packets could xfrm mark could
change behaviour in a way that breaks these setups.
If the output mark is unspecified or set to zero, the mark is not
set or changed.
[backport of upstream 077fbac405bfc6d41419ad6c1725804ad4e9887c]
Bug: 63589535
Test: https://android-review.googlesource.com/452776/ passes
Tested: make allyesconfig; make -j64
Tested: https://android-review.googlesource.com/452776
Signed-off-by: Lorenzo Colitti <lorenzo@google.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Change-Id: I76120fba036e21780ced31ad390faf491ea81e52
Subash reported that commit 42a7b32b73 ("xfrm: Add oif to dst lookups")
broke a wifi use case that uses fib rules and xfrms. The intent of
42a7b32b73 was driven by VRFs with IPsec. As a compromise relax the
use of oif in xfrm lookups to L3 master devices only (ie., oif is either
an L3 master device or is enslaved to a master device).
[cherry-pick of upstream 11d7a0bb95eaaba1741bb24a7c3c169c82f09c7b]
Bug: 63589535
Change-Id: Ibadb15341f6c6c7077eccfaa2c66b3bb86b251bf
Fixes: 42a7b32b73 ("xfrm: Add oif to dst lookups")
Reported-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Add helper to lookup l3mdev master index given a device index.
[cherry-pick of upstream 1a8524794fc7c70f44ac28e3a6e8fd637bc41f14]
Bug: 63589535
Change-Id: I3d0758a5d0eb03791726014c9c1e32e187391e6f
Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Before calling kgsl_pwrctrl_clk_set_rate(), make sure the
RBBM timer clock is available. This avoids warning messages
in the driver log.
Change-Id: I0cd21b7253c802e8522d570056c8aeda02729267
Signed-off-by: Archana Obannagari <aobann@codeaurora.org>
Remove sending the content stream type message for HDMI sinks.
This message is applicable only for DP receivers.
Sending this message for HDMI sinks is a write to unknown
space which causes undefined behavior on some sinks.
Change-Id: Id4894021528c17ebaeb5818a2bdcf7ae9c91c070
Signed-off-by: Abhinav Kumar <abhinavk@codeaurora.org>
This reverts commit 792779946e.
This is reverted to fix the weston display.
Change-Id: Iff811f643a8756d6d0921a743736f1a535893883
Signed-off-by: suresh <suresh@codeaurora.org>
The NVID programming for Display Port needs to be set to twice
the 'n' divider of the pixel clock RCG for 5.4 GHz link rate.
Add change to take care of this in Display Port driver.
Change-Id: Ied31f67372d9738e96d1d908acd96a02b82d4630
Signed-off-by: Padmanabhan Komanduru <pkomandu@codeaurora.org>
The parent of DP VCO divided mux clock needs to be set from the
Display Port driver based on the link rate. Add the dtsi entries
needs for this support for msm8998.
Change-Id: I76c2568579735f20106e40a359fd0052a2f51fbf
Signed-off-by: Padmanabhan Komanduru <pkomandu@codeaurora.org>
The DP VCO divided mux clock has two parent dividers div_two
and div_four. The parent for this needs to be set based on the
link rate frequency as per the hardware programming guide and
not based on the auto PLL calculation logic. Add support to set
the correct parent for this.
Change-Id: Ia2d340a4e8790d90161c1f4a7c8273449fa3f53c
Signed-off-by: Padmanabhan Komanduru <pkomandu@codeaurora.org>
This change starts using dl_max_packet_size value sent by host
as part of USB RNDIS init message communication. Using default
dl_max_packet_size value results into low throughput with more
data loss on host side as host side RNDIS can't support
de-aggregation (applicable for Linux Host RNDIS driver) or it
ignores received more data then host side RNDIS can handle. To
use fine tune dl_max_packet_size for better throughput, driver
selects minimum value between host supported dl_max_packet_size
and default size (i.e. 9216 bytes as RNDIS IN aggregation size).
Change-Id: I00c81bc905a032867c537536b01bf32584c37e63
Signed-off-by: Vijayavardhan Vennapusa <vvreddy@codeaurora.org>
Android has an unusual setup where the kernel needs to target
[arch]-linux-gnu to avoid Android userspace-specific flags and
optimizations, but AOSP doesn't ship a matching binutils.
Add a new variable CLANG_TRIPLE which can override the "-target" triple
used to compile the kernel, while using a different CROSS_COMPILE to
pick the binutils/gcc installation. For Android you'd do something
like:
export CLANG_TRIPLE=aarch64-linux-gnu-
export CROSS_COMPILE=aarch64-linux-android-
If you don't need something like this, leave CLANG_TRIPLE unset and it
will default to CROSS_COMPILE.
Change-Id: Ib544c37f4ee4ed005437471b2984486a3e7c0da7
Signed-off-by: Greg Hackmann <ghackmann@google.com>
clang raises 'asm-operand-widths' warnings in inline assembly code when
the size of an operand is < 64 bits and the operand width is unspecified.
Most warnings are raised in macros, i.e. the datatype of the operand may
vary. Most of these warnings are fixed in upstream, however we consider it
isn't worth the effort/risk to backport all the necessary changes. On
future CrOS kernels >= v4.13 the warning should be re-enabled.
Change-Id: Ia331bc83d44b8c1499450aefb45c576cd29ebf55
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Greg Hackmann <ghackmann@google.com>
clang generates plenty of these warnings in different parts of the code.
They are mostly caused by container_of() and other macros which declare
a "const <type> *" variable for their internal use which triggers a
"duplicate 'const' specifier" warning if the <type> is already const
qualified.
Change-Id: I85ffb201003d3a04fe8b8ff94478344250d2db68
Wording-mostly-from: Michael Davidson <md@google.com>
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Greg Hackmann <ghackmann@google.com>
With the following commit:
8f91869766c0 ("x86/build: Fix stack alignment for CLang")
cc-option is only used to determine the name of the stack alignment option
supported by the compiler, but not to verify that the actual parameter
<option>=N is valid in combination with the other CFLAGS.
This causes problems (as reported by the kbuild robot) with older GCC versions
which only support stack alignment on a boundary of 16 bytes or higher.
Also use (__)cc_option to add the stack alignment option to CFLAGS to
make sure only valid options are added.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Bernhard.Rosenkranzer@linaro.org
Cc: Greg Hackmann <ghackmann@google.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Michael Davidson <md@google.com>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephen Hines <srhines@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: dianders@chromium.org
Fixes: 8f91869766c0 ("x86/build: Fix stack alignment for CLang")
Link: http://lkml.kernel.org/r/20170817182047.176752-1-mka@chromium.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
(cherry picked from commit 9e8730b178a2472fca3123e909d6e69cc8127778)
Signed-off-by: Greg Hackmann <ghackmann@google.com>
Change-Id: Ia2c932ede0096fe399131e958e0aaf4835039294
Commit:
d77698df39a5 ("x86/build: Specify stack alignment for clang")
intended to use the same stack alignment for clang as with gcc.
The two compilers use different options to configure the stack alignment
(gcc: -mpreferred-stack-boundary=n, clang: -mstack-alignment=n).
The above commit assumes that the clang option uses the same parameter
type as gcc, i.e. that the alignment is specified as 2^n. However clang
interprets the value of this option literally to use an alignment of n,
in consequence the stack remains misaligned.
Change the values used with -mstack-alignment to be the actual alignment
instead of a power of two.
cc-option isn't used here with the typical pattern of KBUILD_CFLAGS +=
$(call cc-option ...). The reason is that older gcc versions don't
support the -mpreferred-stack-boundary option, since cc-option doesn't
verify whether the alternative option is valid it would incorrectly
select the clang option -mstack-alignment..
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Bernhard.Rosenkranzer@linaro.org
Cc: Greg Hackmann <ghackmann@google.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Michael Davidson <md@google.com>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephen Hines <srhines@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: dianders@chromium.org
Link: http://lkml.kernel.org/r/20170817004740.170588-1-mka@chromium.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
(cherry picked from commit 8f91869766c00622b2eaa8ee567db4f333b78c1a)
Signed-off-by: Greg Hackmann <ghackmann@google.com>
Change-Id: I7991bfed754f5ac10ac8b383c20ec89d56b2afc0
Clang may emit absolute symbol references when building in non-PIC mode,
even when using the default 'small' code model, which is already mostly
position independent to begin with, due to its use of adrp/add pairs
that have a relative range of +/- 4 GB. The remedy is to pass the -fpie
flag, which can be done safely now that the code has been updated to avoid
GOT indirections (which may be emitted due to the compiler assuming that
the PIC/PIE code may end up in a shared library that is subject to ELF
symbol preemption)
Passing -fpie when building code that needs to execute at an a priori
unknown offset is arguably an improvement in any case, and given that
the recent visibility changes allow the PIC build to pass with GCC as
well, let's add -fpie for all arm64 builds rather than only for Clang.
Tested-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20170818194947.19347-5-ard.biesheuvel@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
(cherry picked from commit 91ee5b21ee026c49e4e7483de69b55b8b47042be)
Signed-off-by: Greg Hackmann <ghackmann@google.com>
Change-Id: I0a011945239d39a2d1eb04c20bf1b9ceb7d2b91d
To prevent the compiler from emitting absolute references to the section
markers when running in PIC mode, override the visibility to 'hidden' for
all contents of asm/sections.h
Tested-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20170818194947.19347-4-ard.biesheuvel@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
(cherry picked from commit 0426a4e68f18d75515414361de9e3e1445d2644e)
Signed-off-by: Greg Hackmann <ghackmann@google.com>
Change-Id: Ia438c3f0aa6abdbd9057dfe1db732a25aa98ef40
The motivation for commit abb2ea7dfd82 ("compiler, clang: suppress
warning for unused static inline functions") was to suppress clang's
warnings about unused static inline functions.
For configs without CONFIG_OPTIMIZE_INLINING enabled, such as any non-x86
architecture, `inline' in the kernel implies that
__attribute__((always_inline)) is used.
Some code depends on that behavior, see
https://lkml.org/lkml/2017/6/13/918:
net/built-in.o: In function `__xchg_mb':
arch/arm64/include/asm/cmpxchg.h:99: undefined reference to `__compiletime_assert_99'
arch/arm64/include/asm/cmpxchg.h:99: undefined reference to `__compiletime_assert_99
The full fix would be to identify these breakages and annotate the
functions with __always_inline instead of `inline'. But since we are
late in the 4.12-rc cycle, simply carry forward the forced inlining
behavior and work toward moving arm64, and other architectures, toward
CONFIG_OPTIMIZE_INLINING behavior.
(cherry picked from commit 9a04dbcfb33b4012d0ce8c0282f1e3ca694675b1)
Change-Id: I13891c2f1e588d8c7febe5d2d57134abb31d6ecd
Link: http://lkml.kernel.org/r/alpine.DEB.2.10.1706261552200.1075@chino.kir.corp.google.com
Signed-off-by: David Rientjes <rientjes@google.com>
Reported-by: Sodagudi Prasad <psodagud@codeaurora.org>
Tested-by: Sodagudi Prasad <psodagud@codeaurora.org>
Tested-by: Matthias Kaehlcke <mka@chromium.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Hackmann <ghackmann@google.com>
undef memcpy() and friends in boot/string.c so that the functions
defined here will have the correct names, otherwise we end up
up trying to redefine __builtin_memcpy() etc.
Surprisingly, GCC allows this (and, helpfully, discards the
__builtin_ prefix from the function name when compiling it),
but clang does not.
Adding these #undef's appears to preserve what I assume was
the original intent of the code.
(cherry picked from commit 18d5e6c34a8eda438d5ad8b3b15f42dab01bf05d)
Change-Id: I616a6a8ece533166367d987597e8c405c96441a2
Signed-off-by: Michael Davidson <md@google.com>
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Acked-by: H. Peter Anvin <hpa@zytor.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Bernhard.Rosenkranzer@linaro.org
Cc: Greg Hackmann <ghackmann@google.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20170724235155.79255-1-mka@chromium.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Hackmann <ghackmann@google.com>
Replace the inline asm which exports struct offsets as ELF symbols
with proper const variables exposing the same values. This works
around an issue with Clang which does not interpret the "i" (or "I")
constraints in the same way as GCC.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
(cherry picked from commit f4857f4c2ee9aa4e2aacac1a845352b00197fb57)
Signed-off-by: Greg Hackmann <ghackmann@google.com>
Change-Id: I1f882de15bd447d6fc41858dfc0cbfd3f6e2466c
clang generates plenty of these warnings in different parts of the code,
to an extent that the warnings are little more than noise. Disable the
'address-of-packed-member' warning.
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
(cherry picked from commit bfb38988c51e440fd7062ddf3157f7d8b1dd5d70)
Signed-off-by: Greg Hackmann <ghackmann@google.com>
Change-Id: I35ecf1b35a908d41ee791a8a651e3cfb4edd081b
For gcc stack alignment is configured with -mpreferred-stack-boundary=N,
clang has the option -mstack-alignment=N for that purpose. Use the same
alignment as with gcc.
If the alignment is not specified clang assumes an alignment of
16 bytes, as required by the standard ABI. However as mentioned in
d9b0cde91c ("x86-64, gcc: Use -mpreferred-stack-boundary=3 if
supported") the standard kernel entry on x86-64 leaves the stack
on an 8-byte boundary, as a consequence clang will keep the stack
misaligned.
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Acked-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
(cherry picked commit d77698df39a512911586834d303275ea5fda74d0)
Signed-off-by: Greg Hackmann <ghackmann@google.com>
Change-Id: I4283d10c6fe31cf194b35adc5371732b89eb3ae3
cc-option is used to enable compiler options for the boot code if they
are available. The macro uses KBUILD_CFLAGS and KBUILD_CPPFLAGS for the
check, however these flags aren't used to build the boot code, in
consequence cc-option can yield wrong results. For example
-mpreferred-stack-boundary=2 is never set with a 64-bit compiler,
since the setting is only valid for 16 and 32-bit binaries. This
is also the case for 32-bit kernel builds, because the option -m32 is
added to KBUILD_CFLAGS after the assignment of REALMODE_CFLAGS.
Use __cc-option instead of cc-option for the boot mode options.
The macro receives the compiler options as parameter instead of using
KBUILD_C*FLAGS, for the boot code we pass REALMODE_CFLAGS.
Also use separate statements for the __cc-option checks instead
of performing them in the initial assignment of REALMODE_CFLAGS since
the variable is an input of the macro.
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Acked-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
(cherry picked commit 032a2c4f65a2f81c93e161a11197ba19bc14a909)
Signed-off-by: Greg Hackmann <ghackmann@google.com>
Change-Id: I7756f875771edb00238eb770be912f713407681a
cc-option uses KBUILD_CFLAGS and KBUILD_CPPFLAGS when it determines
whether an option is supported or not. This is fine for options used to
build the kernel itself, however some components like the x86 boot code
use a different set of flags.
Add the new macro __cc-option which is a more generic version of
cc-option with additional parameters. One parameter is the compiler
with which the check should be performed, the other the compiler options
to be used instead KBUILD_C*FLAGS.
Refactor cc-option and hostcc-option to use __cc-option and move
hostcc-option to scripts/Kbuild.include.
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Suggested-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Michal Marek <mmarek@suse.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
(cherry picked from commit 9f3f1fd299768782465cb32cdf0dd4528d11f26b)
Signed-off-by: Greg Hackmann <ghackmann@google.com>
Conflicts:
scripts/Kbuild.include
Change-Id: I4c8288b9c74bd6b9199307a0e04b78a27e28361d
People complained about ARCH_HWEIGHT_CFLAGS and how it throws a wrench
into kcov, lto, etc, experimentations.
Add asm versions for __sw_hweight{32,64}() and do explicit saving and
restoring of clobbered registers. This gets rid of the special calling
convention. We get to call those functions on !X86_FEATURE_POPCNT CPUs.
We still need to hardcode POPCNT and register operands as some old gas
versions which we support, do not know about POPCNT.
Btw, remove redundant REX prefix from 32-bit POPCNT because alternatives
can do padding now.
Suggested-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1464605787-20603-1-git-send-email-bp@alien8.de
Signed-off-by: Ingo Molnar <mingo@kernel.org>
(cherry picked from commit f5967101e9de12addcda4510dfbac66d7c5779c3)
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Greg Hackmann <ghackmann@google.com>
Conflicts:
lib/Makefile
Change-Id: Ie7e6dce51c7093b1162337ec8bfc5abde0d79688
The constraint "rm" allows the compiler to put mix_const into memory.
When the input operand is a memory location then MUL needs an operand
size suffix, since Clang can't infer the multiplication width from the
operand.
Add and use the _ASM_MUL macro which determines the operand size and
resolves to the NUL instruction with the corresponding suffix.
This fixes the following error when building with clang:
CC arch/x86/lib/kaslr.o
/tmp/kaslr-dfe1ad.s: Assembler messages:
/tmp/kaslr-dfe1ad.s:182: Error: no instruction mnemonic suffix given and no register operands; can't size instruction
Upstream commit: 121843eb02a6
Change-Id: I53f51839705dabeb6c950d1def3a45881294129c
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Cc: Grant Grundler <grundler@chromium.org>
Cc: Greg Hackmann <ghackmann@google.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Michael Davidson <md@google.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20170501224741.133938-1-mka@chromium.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Hackmann <ghackmann@google.com>
aes_ctrby8_avx-x86_64.S uses the C preprocessor for token pasting
of character sequences that are not valid preprocessor tokens.
While this is allowed when preprocessing assembler files it exposes
an incompatibilty between the clang and gcc preprocessors where
clang does not strip leading white space from macro parameters,
leading to the CONCAT(%xmm, i) macro expansion on line 96 resulting
in a token with a space character embedded in it.
While this could be resolved by deleting the offending space character,
the assembler is perfectly capable of doing the token pasting correctly
for itself so we can just get rid of the preprocessor macros.
Signed-off-by: Michael Davidson <md@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
(cherry picked from commit fdb2726f4e61c5e3abc052f547d5a5f6c0dc5504)
Signed-off-by: Greg Hackmann <ghackmann@google.com>
Change-Id: I087414d3575ea7b8703f39d429ccbf0361b314ae
clang currently does not support these optimizations, only enable them
when they are available.
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Cc: Greg Hackmann <ghackmann@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Michael Davidson <md@google.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: grundler@chromium.org
Link: http://lkml.kernel.org/r/20170413172609.118122-1-mka@chromium.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
(cherry picked from commit 2c4fd1ac3ff167c91272dc43c7bfd2269ef61557)
Signed-off-by: Greg Hackmann <ghackmann@google.com>
Change-Id: Id040421dcf782c9a5b20a72cf68360b36da8f824
Commit abb2ea7dfd82 ("compiler, clang: suppress warning for unused
static inline functions") just caused more warnings due to re-defining
the 'inline' macro.
So undef it before re-defining it, and also add the 'notrace' attribute
like the gcc version that this is overriding does.
Maybe this makes clang happier.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 6d53cefb18e4646fb4bf62ccb6098fb3808486df)
Signed-off-by: Greg Hackmann <ghackmann@google.com>
Change-Id: Ie01b45583954c6104c854a3810e35c1171764e78
GCC explicitly does not warn for unused static inline functions for
-Wunused-function. The manual states:
Warn whenever a static function is declared but not defined or
a non-inline static function is unused.
Clang does warn for static inline functions that are unused.
It turns out that suppressing the warnings avoids potentially complex
Suppress the warning for clang.
Signed-off-by: David Rientjes <rientjes@google.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit abb2ea7dfd82451d85ce669b811310c05ab5ca46)
Signed-off-by: Greg Hackmann <ghackmann@google.com>
Change-Id: I68e6246b03c962cc87b9d0bf4b7fefeda27068c0
The default __UNIQUE_ID macro in compiler.h fails to work for some drivers:
drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c:615:1: error: redefinition of
'__UNIQUE_ID_firmware615'
BRCMF_FW_NVRAM_DEF(4354, "brcmfmac4354-sdio.bin", "brcmfmac4354-sdio.txt");
This adds a copy of the version we use for gcc-4.3 and higher, as the same
one works with all versions of clang that I could find in svn (2.6 and higher).
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Michal Marek <mmarek@suse.com>
(cherry picked from commit b41c29b0527c7fd6a95d0f71274abb79933bf960)
Signed-off-by: Greg Hackmann <ghackmann@google.com>
Change-Id: I161dfa3ccb6b226966c3c87bba6b2fff1561bc61
clang warns about unused inline functions by default:
arch/arm/crypto/aes-cipher-glue.c:68:1: warning: unused function '__inittest' [-Wunused-function]
arch/arm/crypto/aes-cipher-glue.c:69:1: warning: unused function '__exittest' [-Wunused-function]
As these appear in every single module, let's just disable the warnings by marking the
two functions as __maybe_unused.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Miroslav Benes <mbenes@suse.cz>
Acked-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Jessica Yu <jeyu@redhat.com>
(cherry picked from commit 1f318a8bafcfba9f0d623f4870c4e890fd22e659)
Signed-off-by: Greg Hackmann <ghackmann@google.com>
Change-Id: I39c75bdb61834020320d41a678dfcc9442f07e4b
