Some i2s bus GPIOs maybe designed multiplex, the default
is input, we need to configure IN/OUT dynamically.
Change-Id: I2e0f0f972d6f9fa3fc8e8fc9f5dfd5d4e6deaee1
Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
The function param_read() and param_exped() do the same thing,
so this patch uses the more general param_read() instead of
the param_exped(), and delete the param_exped() directly.
Change-Id: Ic097069c28a717ff5f70ceaa36a22ea1bd26b76f
Signed-off-by: William Wu <william.wu@rock-chips.com>
This reverts commit f86b9bf622 which is
commit f4ac712e4f upstream.
Jari Ruusu writes:
Above change "block: ratelimit handle_bad_sector() message"
upstream commit f4ac712e4f
in 4.19.154 kernel is not completely OK.
Removing casts from arguments 4 and 5 produces these compile warnings:
...
For 64 bit systems it is only compile time cosmetic warning. For 32 bit
system + CONFIG_LBDAF=n it introduces bugs: output formats are "%llu" and
passed parameters are 32 bits. That is not OK.
Upstream kernels have hardcoded 64 bit sector_t. In older stable trees
sector_t can be either 64 or 32 bit. In other words, backport of above patch
needs to keep those original casts.
And Tetsuo Handa writes:
Indeed, commit f4ac712e4f ("block: ratelimit handle_bad_sector() message")
depends on commit 72deb455b5 ("block: remove CONFIG_LBDAF") which was merged
into 5.2 kernel.
So let's revert it.
Change-Id: I5a83d4009db1aaed899b48724d757bb327b14a10
Reported-by: Jari Ruusu <jariruusu@users.sourceforge.net>
Reported-by: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Sasha Levin <sashal@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
(cherry picked from git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
commit fd732693294f8d013ff14d5d1574acadb7fd9fc3)
This patch allows user to set MCLK_I2Sx_OUT2IO freq
by CLK_SET_RATE_PARENT.
Change-Id: Ie8f3163726d34c7cf3ee206bbc1d0866049d6eda
Signed-off-by: Sugar Zhang <sugar.zhang@rock-chips.com>
LDCH will compete with LSC/3DLUT for the DDR bus,
which may cause LDCH to read the map table exception.
so isp enable LDCH in 2th frame.
Signed-off-by: Xu Hongfei <xuhf@rock-chips.com>
Change-Id: If84139362ee9ca8de43714915f4387923cf21000
when iommu pagefault, mark_irq to disable iommu interrupt,
then handle the fault, and unmark_irq to enable hardware.
Change-Id: Id40868bfab67ac27e12c181d83a8e70a09a1e498
Signed-off-by: Ding Wei <leo.ding@rock-chips.com>
1. update safe read, limit max op size.
2. add dsp time init.
3. add dsp frame control msg.
4. support flip.
5. support file export/import, calib data read/write.
6. add align calculate func.
Signed-off-by: Zhenke Fan <fanzy.fan@rock-chips.com>
Change-Id: I714aec690d00c9aa6f7f4ef58c3616bfcbf238bb
This is useful for debuggers, and is already the default for clang
(incidentally). Make sure it is on for all users/compilers.
Bug: 160841764
Change-Id: Ibb9a0c6900728d4cce3eccb57fb4c38268a89f24
Signed-off-by: Alistair Delva <adelva@google.com>
The width of ADC PGA gain is 4 and we need to mask them.
Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
Change-Id: I8b8f76a7feb4fa9c9e2066385f73035c1797730d
While adding SiI9022A support to the iwg23s board, it came
up that when the HDMI transmitter is in pass through mode the
device is not compliant with the I2C specification anymore,
as it requires a far bigger tbuf, due to a delay the HDMI
transmitter is adding when relaying the STOP condition on the
monitor i2c side of things.
When not providing an appropriate delay after the STOP condition
the i2c bus would get stuck. Also, any other traffic on the bus
while talking to the monitor may cause the transaction to fail
or even cause issues with the i2c bus as well.
I2c-gates seemed to reach consent as a possible way to address
these issues, and as such this patch is implementing a solution
based on that. Since others are clearly relying on the current
implementation of the driver, this patch won't require any DT
changes.
Since we don't want any interference during the DDC Bus
Request/Grant procedure and while talking to the monitor, we
have to use the adapter locking primitives rather than the
i2c-mux locking primitives.
Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Reviewed-by: Peter Rosin <peda@axentia.se>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Tested-by: Yannick Fertré <yannick.fertre@st.com>
Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1541505156-8097-1-git-send-email-fabrizio.castro@bp.renesas.com
(cherry picked from commit 21d808405f)
Signed-off-by: Sandy Huang <hjc@rock-chips.com>
Change-Id: Idb1a4b5d3c12b47d89693790fb03486ba0021ab5
This reverts commit 60005ae6b0.
Which make cpu unstable now.
Change-Id: Ib22d3ca75709f810a22d8754aac40cfab120022b
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
Provide the user-to-kernel translator under XFRM_USER_COMPAT, that
creates for 32-bit xfrm-user message a 64-bit translation.
The translation is afterwards reused by xfrm_user code just as if
userspace had sent 64-bit message.
Signed-off-by: Dmitry Safonov <dima@arista.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
(cherry picked from commit 5106f4a8ac)
[adelva: nlmsg_parse_deprecated -> nlmsg_parse]
Bug: 163141236
Signed-off-by: Alistair Delva <adelva@google.com>
Change-Id: If15999b86e4704b75307fbcc3d7f0c8d8bc89e7a
Currently nlmsg_unicast() is used by functions that dump structures that
can be different in size for compat tasks, see dump_one_state() and
dump_one_policy().
The following nlmsg_unicast() users exist today in xfrm:
Function | Message can be different
| in size on compat
-------------------------------------------|------------------------------
xfrm_get_spdinfo() | N
xfrm_get_sadinfo() | N
xfrm_get_sa() | Y
xfrm_alloc_userspi() | Y
xfrm_get_policy() | Y
xfrm_get_ae() | N
Besides, dump_one_state() and dump_one_policy() can be used by filtered
netlink dump for XFRM_MSG_GETSA, XFRM_MSG_GETPOLICY.
Just as for xfrm multicast, allocate frag_list for compat skb journey
down to recvmsg() which will give user the desired skb according to
syscall bitness.
Signed-off-by: Dmitry Safonov <dima@arista.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
(cherry picked from commit 5f3eea6b7e)
Bug: 163141236
Signed-off-by: Alistair Delva <adelva@google.com>
Change-Id: Id1a606ddd9d7dfe73a448eeb252b1bfd8dbd2fcb
Provide the kernel-to-user translator under XFRM_USER_COMPAT, that
creates for 64-bit xfrm-user message a 32-bit translation and puts it
in skb's frag_list. net/compat.c layer provides MSG_CMSG_COMPAT to
decide if the message should be taken from skb or frag_list.
(used by wext-core which has also an ABI difference)
Kernel sends 64-bit xfrm messages to the userspace for:
- multicast (monitor events)
- netlink dumps
Wire up the translator to xfrm_nlmsg_multicast().
Signed-off-by: Dmitry Safonov <dima@arista.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
(cherry picked from commit 5461fc0c8d)
Bug: 163141236
Signed-off-by: Alistair Delva <adelva@google.com>
Change-Id: Id8b59587d60feb9b9f0ce96be9d140d694573fe3
Add a skeleton for xfrm_compat module and provide API to register it in
xfrm_state.ko. struct xfrm_translator will have function pointers to
translate messages received from 32-bit userspace or to be sent to it
from 64-bit kernel.
module_get()/module_put() are used instead of rcu_read_lock() as the
module will vmalloc() memory for translation.
The new API is registered with xfrm_state module, not with xfrm_user as
the former needs translator for user_policy set by setsockopt() and
xfrm_user already uses functions from xfrm_state.
Signed-off-by: Dmitry Safonov <dima@arista.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
(cherry picked from commit c9e7c76d70)
[adelva: Edited around some context changes]
Bug: 163141236
Signed-off-by: Alistair Delva <adelva@google.com>
Change-Id: Ic825c6a0367fa192cc3f7af6b7d2682ef8f9d58b
So we can use the new download_from_ci script.
Bug: 172085130
Change-Id: I679ba3fc334b29ae82806f09e2acfc4dad486bd1
Signed-off-by: Will McVicker <willmcvicker@google.com>
PAC pointer authentication signs the return address against the value
of the stack pointer, to prevent stack overrun exploits from corrupting
the control flow. However, this requires that the AUTIASP is issued with
SP holding the same value as it held when the PAC value was generated.
The Poly1305 NEON code got this wrong, resulting in crashes on PAC
capable hardware.
Fixes: f569ca1647 ("crypto: arm64/poly1305 - incorporate OpenSSL/CRYPTOGAMS ...")
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Bug: 152722841
Link: https://lore.kernel.org/linux-crypto/20201026230027.25813-1-ardb@kernel.org/
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Change-Id: Ib5282ac56ba5158c7d97195c2460701006bf82f6
The change to encrypt a fifth ChaCha block using scalar instructions
caused the chacha20-neon, xchacha20-neon, and xchacha12-neon self-tests
to start failing on big endian arm64 kernels. The bug is that the
keystream block produced in 32-bit scalar registers is directly XOR'd
with the data words, which are loaded and stored in native endianness.
Thus in big endian mode the data bytes end up XOR'd with the wrong
bytes. Fix it by byte-swapping the keystream words in big endian mode.
Fixes: 2fe55987b2 ("crypto: arm64/chacha - use combined SIMD/ALU routine for more speed")
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
(cherry picked from commit 4b6d196c9c)
Bug: 152722841
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Change-Id: I007e5b4aa9f6dfdaea839f3fa74740321a82c682
On big endian arm64 kernels, the xchacha20-neon and xchacha12-neon
self-tests fail because hchacha_block_neon() outputs little endian words
but the C code expects native endianness. Fix it to output the words in
native endianness (which also makes it match the arm32 version).
Fixes: cc7cf991e9 ("crypto: arm64/chacha20 - add XChaCha20 support")
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
(cherry picked from commit f86d17e9ef)
Bug: 152722841
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Change-Id: I5a74cfd06508ed4ab6202282ce28a481fdb07641
