Change how vendor hooks are instantiated to promote
more complete structure definition in the ABI XML
description without complicating hook definition for
partners.
We don't want to force partners to include all
headers as part of the hook definition in include/trace/hooks/
since that causes extra headers to be included in
source files that runs the risk of changing visibility
resulting in CRC changes to KMI symbols. Instead continue
the practice of using forward declarations in the hook
header files.
Instead of instantiating all hook tracepoints globally in
drivers/android/vendor_hooks.c, use subsystem-specific
vendor_hooks.c if inclusion of subsystem-specific
header files is required. This avoids namespace collisions
between internal header files and limits the exposure
to the internal headers to the instantiation, not the
call sites.
In this patch, all of the scheduler related hooks are
instantiated in kernel/sched/vendor_hooks.c which can
cleanly include scheduler-related header files to
provide full type visibility.
Bug: 233047575
Signed-off-by: Todd Kjos <tkjos@google.com>
Change-Id: Ife5a66c2968de73e3f6d05840411310611e2e175
Remove the obsolete use of CONFIG_TRACEPOINTS in hook definition
header files. The !CONFIG_TRACEPOINTS case is correctly handled
by the included trace header files.
Bug: 233047575
Signed-off-by: Todd Kjos <tkjos@google.com>
Change-Id: I957649bcfef375284f2885cf732ff2960c303837
HCTR2 is a wide-block encryption mode intended to solve a pre-existing
cryptographic weakness due to IV reuse in filename encryption.
Bug: 233652475
Change-Id: Ie1bcff8d61579a6b3e14418f280b97483b2dd670
Signed-off-by: Nathan Huckleberry <nhuck@google.com>
HCTR2 is a tweakable, length-preserving encryption mode that is intended
for use on CPUs with dedicated crypto instructions. HCTR2 has the
property that a bitflip in the plaintext changes the entire ciphertext.
This property fixes a known weakness with filename encryption: when two
filenames in the same directory share a prefix of >= 16 bytes, with
AES-CTS-CBC their encrypted filenames share a common substring, leaking
information. HCTR2 does not have this problem.
More information on HCTR2 can be found here: "Length-preserving
encryption with HCTR2": https://eprint.iacr.org/2021/1441.pdf
Signed-off-by: Nathan Huckleberry <nhuck@google.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Bug: 233652475
Link: https://lore.kernel.org/linux-arm-kernel/20220520181501.2159644-4-nhuck@google.com/T/
(cherry picked from commit 6b2a51ff03)
Change-Id: Ie94df666c40388d100485c9ec05a734dc8fc3c23
Signed-off-by: Nathan Huckleberry <nhuck@google.com>
Add hardware accelerated version of POLYVAL for ARM64 CPUs with
Crypto Extensions support.
This implementation is accelerated using PMULL instructions to perform
the finite field computations. For added efficiency, 8 blocks of the
message are processed simultaneously by precomputing the first 8
powers of the key.
Karatsuba multiplication is used instead of Schoolbook multiplication
because it was found to be slightly faster on ARM64 CPUs. Montgomery
reduction must be used instead of Barrett reduction due to the
difference in modulus between POLYVAL's field and other finite fields.
More information on POLYVAL can be found in the HCTR2 paper:
"Length-preserving encryption with HCTR2":
https://eprint.iacr.org/2021/1441.pdf
Signed-off-by: Nathan Huckleberry <nhuck@google.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Bug: 233652475
Link: https://lore.kernel.org/linux-arm-kernel/20220520181501.2159644-4-nhuck@google.com/T/
(cherry picked from commit 9d2c0b485c)
Change-Id: Ifd07a5703529844d4cb2f9d270e7c4b474ebcf7f
Signed-off-by: Nathan Huckleberry <nhuck@google.com>
Add hardware accelerated version of POLYVAL for x86-64 CPUs with
PCLMULQDQ support.
This implementation is accelerated using PCLMULQDQ instructions to
perform the finite field computations. For added efficiency, 8 blocks
of the message are processed simultaneously by precomputing the first
8 powers of the key.
Schoolbook multiplication is used instead of Karatsuba multiplication
because it was found to be slightly faster on x86-64 machines.
Montgomery reduction must be used instead of Barrett reduction due to
the difference in modulus between POLYVAL's field and other finite
fields.
More information on POLYVAL can be found in the HCTR2 paper:
"Length-preserving encryption with HCTR2":
https://eprint.iacr.org/2021/1441.pdf
Signed-off-by: Nathan Huckleberry <nhuck@google.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Bug: 233652475
Link: https://lore.kernel.org/linux-arm-kernel/20220520181501.2159644-4-nhuck@google.com/T/
(cherry picked from commit 34f7f6c301)
Change-Id: I18a532b8338e62ca7c85d8106ef22eeeab7b3355
Signed-off-by: Nathan Huckleberry <nhuck@google.com>
Add support for HCTR2 as a template. HCTR2 is a length-preserving
encryption mode that is efficient on processors with instructions to
accelerate AES and carryless multiplication, e.g. x86 processors with
AES-NI and CLMUL, and ARM processors with the ARMv8 Crypto Extensions.
As a length-preserving encryption mode, HCTR2 is suitable for
applications such as storage encryption where ciphertext expansion is
not possible, and thus authenticated encryption cannot be used.
Currently, such applications usually use XTS, or in some cases Adiantum.
XTS has the disadvantage that it is a narrow-block mode: a bitflip will
only change 16 bytes in the resulting ciphertext or plaintext. This
reveals more information to an attacker than necessary.
HCTR2 is a wide-block mode, so it provides a stronger security property:
a bitflip will change the entire message. HCTR2 is somewhat similar to
Adiantum, which is also a wide-block mode. However, HCTR2 is designed
to take advantage of existing crypto instructions, while Adiantum
targets devices without such hardware support. Adiantum is also
designed with longer messages in mind, while HCTR2 is designed to be
efficient even on short messages.
HCTR2 requires POLYVAL and XCTR as components. More information on
HCTR2 can be found here: "Length-preserving encryption with HCTR2":
https://eprint.iacr.org/2021/1441.pdf
Signed-off-by: Nathan Huckleberry <nhuck@google.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Bug: 233652475
Link: https://lore.kernel.org/linux-arm-kernel/20220520181501.2159644-4-nhuck@google.com/T/
(cherry picked from commit 7ff554ced7)
Change-Id: Ia97eaf73d2fe8176f20cf41cadf658fb4238269c
Signed-off-by: Nathan Huckleberry <nhuck@google.com>
Add a generic implementation of XCTR mode as a template. XCTR is a
blockcipher mode similar to CTR mode. XCTR uses XORs and little-endian
addition rather than big-endian arithmetic which has two advantages: It
is slightly faster on little-endian CPUs and it is less likely to be
implemented incorrect since integer overflows are not possible on
practical input sizes. XCTR is used as a component to implement HCTR2.
More information on XCTR mode can be found in the HCTR2 paper:
https://eprint.iacr.org/2021/1441.pdf
Signed-off-by: Nathan Huckleberry <nhuck@google.com>
Reviewed-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Bug: 233652475
Link: https://lore.kernel.org/linux-arm-kernel/20220520181501.2159644-4-nhuck@google.com/T/
(cherry picked from commit 17fee07a2a)
Change-Id: Idb978c32cfbe646c22b35798e1dfb01f8e08e5fd
Signed-off-by: Nathan Huckleberry <nhuck@google.com>
When a device kernel builds their own modules that
conflicts with the GKI modules (zram and zsmalloc
for android13-5.15), the dist target will produce a
warning about conflicting source files.
Hence, do not include zram and zsmalloc to the device
dist targets by default when they include //common:kernel_aarch64
only.
If they wish to include zram and zsmalloc in
the distribution on the android13-5.15 branch,
they may add the following to the
dist target:
"//common:kernel_aarch64_modules",
or individual modules:
"//common:kernel_aarch64/drivers/block/zram/zram.ko",
"//common:kernel_aarch64/mm/zsmalloc.ko",
//common:kernel_aarch64_dist continues to include GKI
modules defined by the branch.
Bug: 244215515
Test: manual
Change-Id: Iae701d7d452e6ed3a849fdfd03550551ca2af17e
Signed-off-by: Yifan Hong <elsk@google.com>
Since not all devices require a 32-bit MSI address, add support to the
PCIe host driver to allow setting the DMA mask to 64-bits if the 32-bit
allocation fails. This allows kernels to disable ZONE_DMA32 and bounce
buffering (swiotlb) without risking not being able to get a 32-bit
address during DMA allocation.
Basically, in the slim chance that there are no 32-bit allocations
available, the current PCIe host driver will fail to allocate the
msi_msg page due to a DMA address overflow (seen in [1]). With this
patch, the PCIe host can retry the allocation with a 64-bit DMA mask if
the current PCIe device advertises 64-bit support via its MSI
capabilities.
[1] https://lore.kernel.org/all/Yo0soniFborDl7+C@google.com/
Bug: 241473543
Link: https://lore.kernel.org/r/20220825235404.4132818-3-willmcvicker@google.com
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Will McVicker <willmcvicker@google.com>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Jingoo Han <jingoohan1@gmail.com>
Change-Id: I8936717b26f3dec453b0a944b26a0bb891905100
(cherry picked from commit e99d8c5e803b9a9f0b5a84165dad3b8895446147 https://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/pci.git pci/dwc)
As of 07940c369a ("PCI: dwc: Fix MSI page leakage in suspend/resume"),
the PCIe designware host driver has been using the driver data
allocation for the msi_msg DMA mapping which can result in
a DMA_MAPPING_ERROR due to the DMA overflow check in
dma_direct_map_page() when the address is greater than 32 bits (reported
in [1]). The commit was trying to address a memory leak on
suspend/resume by moving the MSI mapping to dw_pcie_host_init(), but
subsequently dropped the page allocation thinking it wasn't needed.
To fix the DMA mapping issue as well as make msi_msg DMA'able, switch
back to allocating a 32-bit page for the msi_msg. To avoid the
suspend/resume leak, allocate the page in dw_pcie_host_init() since that
shouldn't be called during suspend/resume.
[1] https://lore.kernel.org/all/Yo0soniFborDl7+C@google.com/
Signed-off-by: Will McVicker <willmcvicker@google.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Change-Id: I48f48d069ff27a391cf0043bc23cfe4ac8c32593
(cherry picked from commit 35797e672f)
In ns_to_kernel_old_timeval() definition, the function argument is defined
with const identifier in kernel/time/time.c, but the prototype in
include/linux/time32.h looks different.
- The function is defined in kernel/time/time.c as below:
struct __kernel_old_timeval ns_to_kernel_old_timeval(const s64 nsec)
- The function is decalared in include/linux/time32.h as below:
extern struct __kernel_old_timeval ns_to_kernel_old_timeval(s64 nsec);
Because the variable of arithmethic types isn't modified in the calling scope,
there's no need to mark arguments as const, which was already mentioned during
review (Link[1) of the original patch.
Likewise remove the "const" keyword in both definition and declaration of
ns_to_timespec64() as requested by Arnd (Link[2]).
Fixes: a84d116916 ("y2038: Introduce struct __kernel_old_timeval")
Signed-off-by: Youngmin Nam <youngmin.nam@samsung.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/all/20220712094715.2918823-1-youngmin.nam@samsung.com
Link[1]: https://lore.kernel.org/all/20180310081123.thin6wphgk7tongy@gmail.com/
Link[2]: https://lore.kernel.org/all/CAK8P3a3nknJgEDESGdJH91jMj6R_xydFqWASd8r5BbesdvMBgA@mail.gmail.com/
(cherry picked from commit 46dae32fe6)
Signed-off-by: Todd Kjos <tkjos@google.com>
Change-Id: I223421667b583168d4ce95ec1af2f76fef9fcf3d
Revert "ANDROID: Convert db845c to a mixed build."
Revert submission 2188970-db845c_mixed_build
Reason for revert: It breaks android-mainline
Reverted Changes:
I6cfb1ef19:ANDROID: Convert db845c to a mixed build.
I6680cb8ef:kleaf: Convert db845c to a mixed build.
I6cfb1ef19:ANDROID: Convert db845c to a mixed build.
Signed-off-by: Ulises Mendez Martinez <umendez@google.com>
Change-Id: I0b7b411d2e5cf13aff257b5827479d20092f2b3b
UFS storage devices require bRefClkFreq attribute to be set to operate
correctly at high speed mode. The necessary value is determined by what the
SoC / board supports. The standard doesn't specify a method to query the
value, so the information needs to be fed in separately.
DT information feeds into setting up the clock framework, so platforms
using DT can get the UFS reference clock frequency from the clock
framework. A special node "ref_clk" from the clock array for the UFS
controller node is used as the source for the information.
On the platforms that do not use DT (e.g. Intel), the alternative mechanism
to feed the intended reference clock frequency is necessary. Specifying the
necessary information in DSD of the UFS controller ACPI node is an
alternative mechanism proposed in this patch. Those can be accessed via
firmware property facility in the kernel and in many ways simillar to
querying properties defined in DT.
This patch introduces a small helper function to query a predetermined ACPI
supplied property of the UFS controller, and uses it to attempt retrieving
reference clock value, unless that was already done by the clock
infrastructure.
Link: https://lore.kernel.org/r/20220715210230.1.I365d113d275117dee8fd055ce4fc7e6aebd0bce9@changeid
Reviewed-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Daniil Lunev <dlunev@chromium.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit ca452621b8 git://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git for-next)
Bug: 239946304
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Change-Id: Ifbc20404d72b7a1bbc49fe0652657f397418c055
Since commit 1599069a62 ("phy: core: Warn when phy_power_on is called
before phy_init"), the following warning has been reported:
phy_power_on was called before phy_init
To address this, we need to remove phy_power_on from exynos_ufs_phy_init()
and move it after phy_init. phy_power_off and phy_exit are also necessary
in exynos_ufs_remove().
Link: https://lore.kernel.org/r/20220706020255.151177-4-chanho61.park@samsung.com
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Chanho Park <chanho61.park@samsung.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 3d73b200f9 git://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git for-next)
Bug: 239946304
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Change-Id: I4bbb4c05281e7a07ae8860b8a53a3dcca1e94d9d
Checks information about tx_lanes, but is not used.
Since commit 1e1e465c6d ("scsi/ufs: qcom: Remove ufs_qcom_phy_*() calls
from host"), tx_lanes is deprecated.
As a result, ufs_qcom_link_startup_notify -> POST_CHANGE action does
nothing. If it is not going to be updated, it can be removed.
Link: https://lore.kernel.org/r/20220627235545.16943-1-cw9316.lee@samsung.com
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: ChanWoo Lee <cw9316.lee@samsung.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit bcec04b3cc git://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git for-next)
Bug: 239946304
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Change-Id: I5e0f2daf8506d4798f13091fd7e48976285fe023
Fix build warnings:
1.
../drivers/ufs/host/ufs-mediatek.c:1375:5: error: no previous prototype for function 'ufs_mtk_system_suspend' [-Werror,-Wmissing-prototypes]
int ufs_mtk_system_suspend(struct device *dev)
^
../drivers/ufs/host/ufs-mediatek.c:1375:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
int ufs_mtk_system_suspend(struct device *dev)
^
static
2.
../drivers/ufs/host/ufs-mediatek.c:702:50: error: format specifies type 'unsigned long' but the argument has type 'int' [-Werror,-Wformat]
snprintf(vcc_name, MAX_VCC_NAME, "vcc-ufs%lu", ver);
~~~ ^~~
%d
Link: https://lore.kernel.org/r/20220623035052.18802-2-stanley.chu@mediatek.com
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit e7bf1d5006 git://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git for-next)
Bug: 239946304
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Change-Id: Id57c619219f48dde266be7fceaece0b0085d827d
If CONFIG_PM_SLEEP is not set.
make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu-, will fail:
drivers/ufs/host/ufs-mediatek.c: In function ‘ufs_mtk_vreg_fix_vcc’:
drivers/ufs/host/ufs-mediatek.c:688:46: warning: format ‘%u’ expects argument of type ‘unsigned int’, but argument 4 has type ‘long unsigned int’ [-Wformat=]
snprintf(vcc_name, MAX_VCC_NAME, "vcc-opt%u", res.a1);
~^ ~~~~~~
%lu
drivers/ufs/host/ufs-mediatek.c: In function ‘ufs_mtk_system_suspend’:
drivers/ufs/host/ufs-mediatek.c:1371:8: error: implicit declaration of function ‘ufshcd_system_suspend’; did you mean ‘ufs_mtk_system_suspend’? [-Werror=implicit-function-declaration]
ret = ufshcd_system_suspend(dev);
^~~~~~~~~~~~~~~~~~~~~
ufs_mtk_system_suspend
drivers/ufs/host/ufs-mediatek.c: In function ‘ufs_mtk_system_resume’:
drivers/ufs/host/ufs-mediatek.c:1386:9: error: implicit declaration of function ‘ufshcd_system_resume’; did you mean ‘ufs_mtk_system_resume’? [-Werror=implicit-function-declaration]
return ufshcd_system_resume(dev);
^~~~~~~~~~~~~~~~~~~~
ufs_mtk_system_resume
cc1: some warnings being treated as errors
The declaration of func "ufshcd_system_suspend()" depends on
CONFIG_PM_SLEEP, so the function wrapper ufs_mtk_system_suspend() should
wrapped by CONFIG_PM_SLEEP too.
Link: https://lore.kernel.org/r/20220619115432.205504-1-renzhijie2@huawei.com
Fixes: 3fd23b8dfb ("scsi: ufs: ufs-mediatek: Fix the timing of configuring device regulators")
Reported-by: Hulk Robot <hulkci@huawei.com>
Reviewed-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Ren Zhijie <renzhijie2@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit f54912b228 git://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git for-next)
Bug: 239946304
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Change-Id: I6fcd2d3c4f88bea6d103a2adfb3c6e9d2d27c64d
Some MediaTek UFS platforms support different VCCQx power rails, for
example, both 1.2v and 1.8v VCCQx, in a single kernel image.
To optimize the system power consumption, provide a way to disable and
release the unused power rail during the device probing.
Link: https://lore.kernel.org/r/20220616053725.5681-12-stanley.chu@mediatek.com
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit cb142b6d2f git://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git for-next)
Bug: 239946304
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Change-Id: If6da47c0bf8b997f894b82502f29db114be45970
Support multiple VCC sources in MediaTek UFS platforms.
Two options are provided and distinguished by specific device tree
attributes as below examples,
[Option 1: By numbering]
mediatek,ufs-vcc-by-num;
vcc-opt1-supply = <&mt6373_vbuck4_ufs>;
vcc-opt2-supply = <&mt6363_vemc>;
[Option 2: By UFS version]
mediatek,ufs-vcc-by-ver;
vcc-ufs3-supply = <&mt6373_vbuck4_ufs>;
Link: https://lore.kernel.org/r/20220616053725.5681-11-stanley.chu@mediatek.com
Signed-off-by: Alice Chao <alice.chao@mediatek.com>
Signed-off-by: Peter Wang <peter.wang@mediatek.com>
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit ece418d029 git://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git for-next)
Bug: 239946304
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Change-Id: I1e141d3eb81e140532b8f277970cb784fe510a53
