In BUILD.bazel, explicitly list abi_definition,
kmi_symbol_list, and additional_kmi_symbol_lists.
This avoids using the glob expression which may
accidentally match editor backup files.
Bug: 246344503
Test: TH
Change-Id: I8fbad63bf744672ba5b76b51cc908926d7b10849
Signed-off-by: Yifan Hong <elsk@google.com>
GZIP-compressed files end with 4 byte data that represents the size
of the original input. The decompressors (the self-extracting kernel)
exploit it to know the vmlinux size beforehand. To mimic the GZIP's
trailer, Kbuild provides cmd_{bzip2,lzma,lzo,lz4,xzkern,zstd22}.
Unfortunately these macros are used everywhere despite the appended
size data is only useful for the decompressors.
There is no guarantee that such hand-crafted trailers are safely ignored.
In fact, the kernel refuses compressed initramdfs with the garbage data.
That is why usr/Makefile overrides size_append to make it no-op.
To limit the use of such broken compressed files, this commit renames
the existing macros as follows:
cmd_bzip2 --> cmd_bzip2_with_size
cmd_lzma --> cmd_lzma_with_size
cmd_lzo --> cmd_lzo_with_size
cmd_lz4 --> cmd_lz4_with_size
cmd_xzkern --> cmd_xzkern_with_size
cmd_zstd22 --> cmd_zstd22_with_size
To keep the decompressors working, I updated the following Makefiles
accordingly:
arch/arm/boot/compressed/Makefile
arch/h8300/boot/compressed/Makefile
arch/mips/boot/compressed/Makefile
arch/parisc/boot/compressed/Makefile
arch/s390/boot/compressed/Makefile
arch/sh/boot/compressed/Makefile
arch/x86/boot/compressed/Makefile
I reused the current macro names for the normal usecases; they produce
the compressed data in the proper format.
I did not touch the following:
arch/arc/boot/Makefile
arch/arm64/boot/Makefile
arch/csky/boot/Makefile
arch/mips/boot/Makefile
arch/riscv/boot/Makefile
arch/sh/boot/Makefile
kernel/Makefile
This means those Makefiles will stop appending the size data.
I dropped the 'override size_append' hack from usr/Makefile.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <n.schier@avm.de>
Bug: 135791357
(cherry picked from commit 7ce7e984ab2b218d6e92d5165629022fe2daf9ee
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master)
Signed-off-by: SzuWei Lin <szuweilin@google.com>
Change-Id: I3f0ebdf13b2edb00fd405afdfacfe94e0e5fbee7
Because GKI has various serial drivers built in (8250, pl031, samsung,
sprd, geni) for earlycon, if they succeed probes for full functionality,
(such as if they are specified in DT as UART devices), the kernel would
unconditionally set up the first console device as the default console,
which is not generally desirable for production.
Enable CONFIG_NULL_TTY and enable "console=ttynull" by default. This
causes the kernel to always be silent unless a kernel console device is
explicitly specified on the cmdline. This has no effect on earlycon
"boot console" devices, just normal "console" devices.
Bug: 223797063
Change-Id: Id4cd0615bad79462f39397427380302b1904e42b
Signed-off-by: Alistair Delva <adelva@google.com>
The 0-day test-bot found this warning:
include/trace/hooks/thermal.h:16:25: warning: 'struct cpufreq_policy'
declared inside parameter list will not be visible outside of this
definition or declaration
Fixed by this patch.
Reported-by: kernel test robot <lkp@intel.com>
Fixes: b3efd2ad71 ("ANDROID: remove inclusions from hook definition headers")
Signed-off-by: Todd Kjos <tkjos@google.com>
Change-Id: I27d178f5056ab417b24eb14ca8dcb95f0d20cac7
As a result of this change:
- fips140 is no longer part of the GKI build but a
separate module, so it is not signed
(CONFIG_MODULE_SIG_ALL is not set)
- GKI images (e.g. system_dlkm image, boot images)
etc. are no longer part of the build -- because
they are unnecessary.
- The build config no longer inherits from build.config.gki.aarch64
directly to avoid building unnecessary system_dklm, boot images,
GKI artifacts, etc.
Test: BUILD_CONFIG=common/build.config.gki.aarch64.fips140 build/build.sh
Test: tools/bazel build //common:fips140_dist
Bug: 232083350
Change-Id: I2cb0ee0b55c2a5ea46e6d73ecad4aa97585c1989
Signed-off-by: Yifan Hong <elsk@google.com>
To avoid changing the visibiliy of data types when including
hook definition headers remove header file inclusions from
the hook definition header files.
Instead, the hook definition headers should just have forward
declarations that don't require full definition.
To provide full definitions of the types for the KMI, the
headers that define the types should be included by the
source file that instantiates the hooks - normally
vendor_hooks.c.
Bug: 233047575
Signed-off-by: Todd Kjos <tkjos@google.com>
Change-Id: Iaaa1a6f45a356569c04ad2fea0b1514e0454f041
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 6b2a51ff03bf0c54cbc699ee85a9a49eb203ebfc)
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 9d2c0b485c46c7c5f781067c60300def5d1365cb)
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 34f7f6c3011276313383099156be287ac745bcea)
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 7ff554ced7c7d7cf77586e07474e8633e011e2d0)
Change-Id: Ia97eaf73d2fe8176f20cf41cadf658fb4238269c
Signed-off-by: Nathan Huckleberry <nhuck@google.com>
Add support for POLYVAL, an ε-Δ-universal hash function similar to
GHASH. This patch only uses POLYVAL as a component to implement HCTR2
mode. It should be noted that POLYVAL was originally specified for use
in AES-GCM-SIV (RFC 8452), but the kernel does not currently support
this mode.
POLYVAL is implemented as an shash algorithm. The implementation is
modified from ghash-generic.c.
For more information on POLYVAL see:
Length-preserving encryption with HCTR2:
https://eprint.iacr.org/2021/1441.pdf
AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption:
https://datatracker.ietf.org/doc/html/rfc8452
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 f3c923a09c4c4f5861b1ed53cf75673992a6ba68)
Change-Id: I7a7e177ecddaa103421b3b4e2d2f072e30e0c934
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 17fee07a2ac577da18b44dd658a9c3c864281c49)
Change-Id: Idb978c32cfbe646c22b35798e1dfb01f8e08e5fd
Signed-off-by: Nathan Huckleberry <nhuck@google.com>
Instead of falling back to C code to do a memcpy of the output of the
last block, handle this in the asm code directly if possible, which is
the case if the entire input is longer than 16 bytes.
Cc: Nathan Huckleberry <nhuck@google.com>
Cc: Eric Biggers <ebiggers@google.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Bug: 233652475
Link: https://lore.kernel.org/all/Yf39x1mHvRsM1jvi@gondor.apana.org.au/
(cherry picked from commit 8daa399edeed4cfa792ccea12beda50d445ab6a0)
Signed-off-by: Nathan Huckleberry <nhuck@google.com>
Change-Id: I0e3410783af6ec18e1143d88bba379ce2fddd2d4
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)
Re-work the msi_msg DMA allocation logic to use dmam_alloc_coherent()
which uses the coherent DMA mask to try to return an allocation within
the DMA mask limits. With that, we now can drop the msi_page parameter
in struct dw_pcie_rp. This allows kernel configurations that disable
ZONE_DMA32 to continue supporting a 32-bit DMA mask. Without this patch,
the PCIe host device will fail to probe when ZONE_DMA32 is disabled.
Bug: 241473543
Link: https://lore.kernel.org/r/20220825235404.4132818-2-willmcvicker@google.com
Fixes: 35797e672ff0 ("PCI: dwc: Fix MSI msi_msg DMA mapping")
Reported-by: Isaac J. Manjarres <isaacmanjarres@google.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: Ib76ffe9d90743a09c633e9f39428403aabd983e3
(cherry picked from commit 423511ec23e2a6fa7830ed76b0283268e795d09d 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 35797e672ff0610224d80e3cc08393fef1032f9a)
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 46dae32fe625a75f549c3a70edc77b778197bb05)
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 ca452621b82916a81ea0f10f9f0158815f3365d0 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 1599069a62c6 ("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 3d73b200f9893d8f5ba5d105e8b69c8d16744fa2 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 bcec04b3cce4c498ef0d416a3a2aaf0369578151 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 e7bf1d50063ce0dcae84ddbd27531a3ecec59e28 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: 3fd23b8dfb54 ("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 f54912b228a8df6c0133e31bc75628677bb8c6e5 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
