These values were multiplied with 10 by xiaomi to allow
more specific configurations. This requires changes in
the display HAL which are not part of the open source
qcom display HAL. Hence decrease the values by dividing
through 10 and rounding to nearest integer to support
the qcom display HAL.
This caused unexpected behaviour in some apps without the
display HAL changes. (e.g. pictures are shown too small
in Reddit app, sliding in Gboard is too sensitive)
It is assumed that the value is too high if the height
is above 1000. The changes have been done with this script:
for panel in $(ls arch/arm64/boot/dts/vendor/qcom/display/dsi-panel-{j,k,l}*); do
height=$(sed -n "s/^.*qcom,mdss-pan-physical-height-dimension = <\([0-9]\+\)>;/\1/p" ${panel})
width=$(sed -n "s/^.*qcom,mdss-pan-physical-width-dimension = <\([0-9]\+\)>;/\1/p" ${panel})
if [[ ${height} > 1000 ]]; then
height=$(python3 -c "print(round(${height} / 10))")
width=$(python3 -c "print(round(${width} / 10))")
sed -i "s/^\(.*qcom,mdss-pan-physical-height-dimension = <\)[0-9]\+\(>;\)/\1${height}\2/g" ${panel}
sed -i "s/^\(.*qcom,mdss-pan-physical-width-dimension = <\)[0-9]\+\(>;\)/\1${width}\2/g" ${panel}
fi
done
Change-Id: Ia99595bf038d8f9302e36e5a02aae48912243c96
* This prevents inclusion of drivers/staging/greybus/tools/Android.mk
which will conflict in case we have more than 1 kernel tree in AOSP
source dir.
Change-Id: I335bca7b6d6463b1ffc673ab5367603347516e13
Currently struct ipa_wdi_conn_in_params occupies 1588 bytes and putting
it on the stack is rather expensive, which could potentially lead to
stack corruption.
Fix is to reduce stack usage in dp_ipa_setup by dynamically allocating
struct ipa_wdi_conn_in_params on the heap.
Change-Id: I8f71f44906a5c95f37627f7573b57b7825daaa7e
CRs-Fixed: 2852027
LLVM_IAS=1 controls enabling clang's integrated assembler via
-integrated-as. This was an explicit opt in until we could enable
assembler support in Clang for more architecures. Now we have support
and CI coverage of LLVM_IAS=1 for all architecures except a few more
bugs affecting s390 and powerpc.
This commit flips the default from opt in via LLVM_IAS=1 to opt out via
LLVM_IAS=0. CI systems or developers that were previously doing builds
with CC=clang or LLVM=1 without explicitly setting LLVM_IAS must now
explicitly opt out via LLVM_IAS=0, otherwise they will be implicitly
opted-in.
This finally shortens the command line invocation when cross compiling
with LLVM to simply:
$ make ARCH=arm64 LLVM=1
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Bug: 209655537
[nd: conflict in Documentation/kbuild/llvm.rst]
(cherry picked from commit f12b034afeb3a977bbb1c6584dedc0f3dc666f14)
Change-Id: I026d42aa40c83eb149c8e39fe91a0b0164ff71b0
We get constant feedback that the command line invocation of make is too
long when compiling with LLVM. CROSS_COMPILE is helpful when a toolchain
has a prefix of the target triple, or is an absolute path outside of
$PATH.
Since a Clang binary is generally multi-targeted, we can infer a given
target from SRCARCH/ARCH. If CROSS_COMPILE is not set, simply set
--target= for CLANG_FLAGS, KBUILD_CFLAGS, and KBUILD_AFLAGS based on
$SRCARCH.
Previously, we'd cross compile via:
$ ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make LLVM=1 LLVM_IAS=1
Now:
$ ARCH=arm64 make LLVM=1 LLVM_IAS=1
For native builds (not involving cross compilation) we now explicitly
specify a target triple rather than rely on the implicit host triple.
Link: https://github.com/ClangBuiltLinux/linux/issues/1399
Suggested-by: Arnd Bergmann <arnd@kernel.org>
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Suggested-by: Masahiro Yamada <masahiroy@kernel.org>
Suggested-by: Nathan Chancellor <nathan@kernel.org>
Acked-by: Arnd Bergmann <arnd@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Acked-by: Miguel Ojeda <ojeda@kernel.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Bug: 209655537
(cherry picked from commit 231ad7f409f16b9f9505f69e058dff488a7e6bde)
Change-Id: I6f61a4937e6af22deda66eeaac6c667c889dc683
When building with LLVM_IAS=1, there is no point to specifying
'--prefix=' because that flag is only used to find GNU cross tools,
which will not be used indirectly when using the integrated assembler.
All of the tools are invoked directly from PATH or a full path specified
via the command line, which does not depend on the value of '--prefix='.
Sharing commands to reproduce issues becomes a little bit easier without
a '--prefix=' value because that '--prefix=' value is specific to a
user's machine due to it being an absolute path.
Some further notes from Fangrui Song:
clang can spawn GNU as (if -f?no-integrated-as is specified) and GNU
objcopy (-f?no-integrated-as and -gsplit-dwarf and -g[123]).
objcopy is only used for GNU as assembled object files.
With integrated assembler, the object file streamer creates .o and
.dwo simultaneously.
With GNU as, two objcopy commands are needed to extract .debug*.dwo to
.dwo files && another command to remove .debug*.dwo sections.
A small consequence of this change (to keep things simple) is that
'--prefix=' will always be specified now, even with a native build, when
it was not before. This should not be an issue due to the way that the
Makefile searches for the prefix (based on elfedit's location). This
ends up improving the experience for host builds because PATH is better
respected and matches GCC's behavior more closely. See the below thread
for more details:
https://lore.kernel.org/r/20210205213651.GA16907@Ryzen-5-4500U.localdomain/
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
(cherry picked from commit eec08090bcc113643522d4272dc0b945045aba74)
Bug: 209655537
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Change-Id: I90f232a1551afb9118176a61ac5de38384a171fd
This flag was originally added to allow clang to find the GNU cross
tools in commit 785f11aa59 ("kbuild: Add better clang cross build
support"). This flag was not enough to find the tools at times so
'--prefix' was added to the list in commit ef8c4ed9db ("kbuild: allow
to use GCC toolchain not in Clang search path") and improved upon in
commit ca9b31f6bb9c ("Makefile: Fix GCC_TOOLCHAIN_DIR prefix for Clang
cross compilation"). Now that '--prefix' specifies a full path and
prefix, '--gcc-toolchain' serves no purpose because the kernel builds
with '-nostdinc' and '-nostdlib'.
This has been verified with self compiled LLVM 10.0.1 and LLVM 13.0.0 as
well as a distribution version of LLVM 11.1.0 without binutils in the
LLVM toolchain locations.
Link: https://reviews.llvm.org/D97902
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Fangrui Song <maskray@google.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Tested-by: Nick Desaulniers <ndesaulniers@google.com>
Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
(cherry picked from commit c91d4e47e10ee4d3163838b1b727fe1d0664115b)
Bug: 209655537
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Change-Id: Ie1f64ed8562964ceba21e402a3d97850f6471508
When using AMD's Optimizing C/C++ Compiler (AOCC), the build fails due
to a # character in the version string, which is interpreted as a
comment:
$ make CC=clang defconfig init/main.o
include/config/auto.conf.cmd:1374: *** invalid syntax in conditional. Stop.
$ sed -n 1374p include/config/auto.conf.cmd
ifneq "$(CC_VERSION_TEXT)" "AMD clang version 11.0.0 (CLANG: AOCC_2.3.0-Build#85 2020_11_10) (based on LLVM Mirror.Version.11.0.0)"
Remove all # characters in the version string so that the build does not
fail unexpectedly.
Link: https://github.com/ClangBuiltLinux/linux/issues/1298
Reported-by: Michael Fuckner <michael@fuckner.net>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
(cherry picked from commit c75173a26948363bdd11a0d5b90bd012ce4cc2e7)
Bug: 209655537
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Change-Id: Ie2ba7041325f13865b59b43517111674519ce386
I noticed we're invoking $(CC) via $(shell) more than once to check the
version. Let's reuse the first string captured in $CC_VERSION_TEXT.
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
[masahiro.yamada:
CC_VERSION_TEXT is assigned by = instead of :=, so this $(shell ) is
evaluated multiple times anyway. The number of $(CC) invocations will
be still the same. Replacing 'grep' with the built-in $(findstring )
will give real performance benefit.]
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
(cherry picked from commit db07562aeac77923370bff4733d8b0e09cbc93c4)
Bug: 209655537
Change-Id: Ib8745c014472a9d63e51e98f9474cced778d57df
FROMGIT: Kernel: Xiaomi kernel changes for Xiaomi 12 Lite Android S
The Patch based on QualComm release TAG:LA.UM.9.14.r1-18300.05-LAHAINA.QSSI12.0-1
The kernel config file used is taoyao_QGKI.config
Signed-off-by: jiahao <jiahao@xiaomi.com>
Change-Id: Ie81ca042c1c9187468339728f8d1066060fb8702
FROMGIT: Kernel: Xiaomi kernel changes for Xiaomi 12 Lite Android S
The Patch based on QualComm release TAG:LA.UM.9.14.r1-18300.05-LAHAINA.QSSI12.0-1
The kernel config file used is taoyao_QGKI.config
Signed-off-by: jiahao <jiahao@xiaomi.com>
Change-Id: Ie81ca042c1c9187468339728f8d1066060fb8702
FROMGIT: Kernel: Xiaomi kernel changes for Xiaomi 12 Lite Android S
The Patch based on QualComm release TAG:LA.UM.9.14.r1-18300.05-LAHAINA.QSSI12.0-1
Signed-off-by: jiahao <jiahao@xiaomi.com>
Change-Id: I187c73b82315c8fb5e58f9db344a0b41d90d73f3
BoringSSL does not implement the ENGINE API. In Android we do not seem
to rely on the PKCS#11 -> DER extraction. Hence, make this conditional
on the SSL library used.
Bug: 135570712
Signed-off-by: Matthias Maennich <maennich@google.com>
Change-Id: I84af6633dd470083497087c7dd1a2734480e2b0e
sfr->buf_size is in shared memory and can be modified by malicious user.
OOB write is possible when the size is made higher than actual sfr data
buffer. Cap the size to allocated size for such cases.
Cc: stable@vger.kernel.org
Fixes: d96d3f30c0 ("[media] media: venus: hfi: add Venus HFI files")
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
CRs-Fixed: 3947576
Change-Id: I483a5feff3dfa35dae8f444e57601d2d1d85246f
Git-commit: f4b211714bcc70effa60c34d9fa613d182e3ef1e
Git-repo: https://gitlab.freedesktop.org/linux-media/media-committers.git
Signed-off-by: Vikash Garodia <quic_vgarodia@quicinc.com>
(cherry picked from commit 56820042f93c80d21cd1442b6a6f4d8fa496598c)
qsize represents size of shared queued between driver and video
firmware. Firmware can modify this value to an invalid large value. In
such situation, empty_space will be bigger than the space actually
available. Since new_wr_idx is not checked, so the following code will
result in an OOB write.
...
qsize = qhdr->q_size
if (wr_idx >= rd_idx)
empty_space = qsize - (wr_idx - rd_idx)
....
if (new_wr_idx < qsize) {
memcpy(wr_ptr, packet, dwords << 2) --> OOB write
Add check to ensure qsize is within the allocated size while
reading and writing packets into the queue.
Cc: stable@vger.kernel.org
Fixes: d96d3f30c0 ("[media] media: venus: hfi: add Venus HFI files")
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
CRs-Fixed: 3935673
Change-Id: Ifb907d4a4c82f853081492e06e68180476367ed5
Git-commit: 69baf245b23e20efda0079238b27fc63ecf13de1
Git-repo: https://gitlab.freedesktop.org/linux-media/media-committers.git
Signed-off-by: Vikash Garodia <quic_vgarodia@quicinc.com>
(cherry picked from commit 11f9d2350e2c6bce56f1aa27ffbab7085da38aae)
words_count denotes the number of words in total payload, while data
points to payload of various property within it. When words_count
reaches last word, data can access memory beyond the total payload. This
can lead to OOB access. With this patch, the utility api for handling
individual properties now returns the size of data consumed. Accordingly
remaining bytes are calculated before parsing the payload, thereby
eliminates the OOB access possibilities.
Cc: stable@vger.kernel.org
Fixes: 1a73374a04 ("media: venus: hfi_parser: add common capability parser")
CRs-Fixed: 3935669
Change-Id: I692e4a8dea110f0650fe26e07207408087a4d19b
Git-commit: 9edaaa8e3e15aab1ca413ab50556de1975bcb329
Git-repo: https://gitlab.freedesktop.org/linux-media/media-committers.git
Signed-off-by: Vikash Garodia <quic_vgarodia@quicinc.com>
(cherry picked from commit fd9b658c8ab9faa6fbb96004ad4a853c9b30236f)
There is a possibility that init_codecs is invoked multiple times during
manipulated payload from video firmware. In such case, if codecs_count
can get incremented to value more than MAX_CODEC_NUM, there can be OOB
access. Reset the count so that it always starts from beginning.
Cc: stable@vger.kernel.org
Fixes: 1a73374a04 ("media: venus: hfi_parser: add common capability parser")
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
CRs-Fixed: 3935643
Change-Id: I6216e773af65082e4775b415789ffd549e0bed2d
Git-commit: 172bf5a9ef70a399bb227809db78442dc01d9e48
Git-repo: https://gitlab.freedesktop.org/linux-media/media-committers.git
Signed-off-by: Vikash Garodia <quic_vgarodia@quicinc.com>
(cherry picked from commit 91f42e0f9cae5ee5f9d8f4286762c3bfb2e66dd3)
Upstream commit bac1ec551434 ("usb: xhci: Set quirk for
XHCI_SG_TRB_CACHE_SIZE_QUIRK") introduced a new quirk in XHCI
which fixes XHC timeout, which was seen on synopsys XHCs while
using SG buffers. But the support for this quirk isn't present
in the DWC3 layer.
We will encounter this XHCI timeout/hung issue if we run iperf
loopback tests using RTL8156 ethernet adaptor on DWC3 targets
with scatter-gather enabled. This gets resolved after enabling
the XHCI_SG_TRB_CACHE_SIZE_QUIRK. This patch enables it using
the xhci device property since its needed for DWC3 controller.
In Synopsys DWC3 databook,
Table 9-3: xHCI Debug Capability Limitations
Chained TRBs greater than TRB cache size: The debug capability
driver must not create a multi-TRB TD that describes smaller
than a 1K packet that spreads across 8 or more TRBs on either
the IN TR or the OUT TR.
Change-Id: I51c065d76939b6fc34e80dc970568ba5c9d40567
Cc: stable@vger.kernel.org #5.11
Signed-off-by: Prashanth K <quic_prashk@quicinc.com>
Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/20240116055816.1169821-2-quic_prashk@quicinc.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Prashanth K <quic_prashk@quicinc.com>
Upstream commit bac1ec551434 ("usb: xhci: Set quirk for
XHCI_SG_TRB_CACHE_SIZE_QUIRK") introduced a new quirk in XHCI
which fixes XHC timeout, which was seen on synopsys XHCs while
using SG buffers. Currently this quirk can only be set using
xhci private data. But there are some drivers like dwc3/host.c
which adds adds quirks using software node for xhci device.
Hence set this xhci quirk by iterating over device properties.
Change-Id: I29c31b05727851fd7c22809febc64589113bc1b9
Cc: stable@vger.kernel.org # 5.11
Fixes: bac1ec551434 ("usb: xhci: Set quirk for XHCI_SG_TRB_CACHE_SIZE_QUIRK")
Signed-off-by: Prashanth K <quic_prashk@quicinc.com>
Link: https://lore.kernel.org/r/20240116055816.1169821-3-quic_prashk@quicinc.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Prashanth K <quic_prashk@quicinc.com>
The Synopsys xHC has an internal TRB cache of size TRB_CACHE_SIZE for
each endpoint. The default value for TRB_CACHE_SIZE is 16 for SS and 8
for HS. The controller loads and updates the TRB cache from the transfer
ring in system memory whenever the driver issues a start transfer or
update transfer command.
For chained TRBs, the Synopsys xHC requires that the total amount of
bytes for all TRBs loaded in the TRB cache be greater than or equal to 1
MPS. Or the chain ends within the TRB cache (with a last TRB).
If this requirement is not met, the controller will not be able to send
or receive a packet and it will hang causing a driver timeout and error.
This can be a problem if a class driver queues SG requests with many
small-buffer entries. The XHCI driver will create a chained TRB for each
entry which may trigger this issue.
This patch adds logic to the XHCI driver to detect and prevent this from
happening.
For every (TRB_CACHE_SIZE - 2), we check the total buffer size of
the SG list and if the last window of (TRB_CACHE_SIZE - 2) SG list length
and we don't make up at least 1 MPS, we create a temporary buffer to
consolidate full SG list into the buffer.
We check at (TRB_CACHE_SIZE - 2) window because it is possible that there
would be a link and/or event data TRB that take up to 2 of the cache
entries.
We discovered this issue with devices on other platforms but have not
yet come across any device that triggers this on Linux. But it could be
a real problem now or in the future. All it takes is N number of small
chained TRBs. And other instances of the Synopsys IP may have smaller
values for the TRB_CACHE_SIZE which would exacerbate the problem.
Change-Id: I6d34805c32756c48b07be2ffa9aad72ab5af2bbe
Signed-off-by: Tejas Joglekar <joglekar@synopsys.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20201208092912.1773650-3-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Prashanth K <quic_prashk@quicinc.com>
Enable RTL815x Ethernet dongle support for sdxlemur.
Change-Id: Ida1265bd8642af0b9211dea5cf6330d8487274b0
Signed-off-by: Prashanth K <quic_prashk@quicinc.com>
