In the updated HW-wrapped key code in the android14 kernels, HW-wrapped
keys are only allowed on a multi-block-device filesystem if they have a
compatible HW-wrapped keys implementation. While in principle this is a
good thing to check, my implementation of it, which simply checks
whether the block devices have the same crypto profiles, doesn't work
when device-mapper is being used.
To actually do that check correctly, I think we'd need to add a
HW-wrapped keys implementation name or ID to the crypto capabilities.
That being said, in Android the HW-wrapped keys implementation is a
global thing anyway. So in the interest of not overcomplicating things,
for now let's just drop these extra checks that are causing problems.
Bug: 160883801
Bug: 265180564
Fixes: 4887dd4fe3 ("ANDROID: fscrypt: add support for hardware-wrapped keys")
Fixes: 3918b39c3e ("ANDROID: update "block: add basic hardware-wrapped key support" to v7")
Change-Id: Ia49d62cc2c56447fb898f19bf67df1a38af379f8
Signed-off-by: Eric Biggers <ebiggers@google.com>
Add vendor hook for bh_lru and lru_cache_disable
Bug: 238728493
Signed-off-by: Minchan Kim <minchan@google.com>
Change-Id: I81bfad317cf6e8633186ebb3238644306d7a102d
Signed-off-by: Richard Chang <richardycc@google.com>
(cherry picked from commit 74e2ea264c)
The pagevec batching causes lru_add_drain_all which is too expensive
sometimes. This patch adds a new vendor hook to drain the pagevec
immediately depending on the page's type.
Bug: 251881967
Signed-off-by: Minchan Kim <minchan@google.com>
Change-Id: Id17e14e69197993ddad511a40c96e51674c02834
Signed-off-by: Richard Chang <richardycc@google.com>
(cherry picked from commit 2f8253b7e6)
Add vendor hook for compaction begin/end. The first use would be
to measure compaction durations.
Bug: 229927848
Test: local kernel build test
Signed-off-by: Robin Hsu <robinhsu@google.com>
Change-Id: I3d95434bf49b37199056dc9ddfc36a59a7de17b7
Signed-off-by: Richard Chang <richardycc@google.com>
(cherry picked from commit 13b6bd38bb)
CMA first allocation policy for movable makes CMA(Upstream doesn't)
area always full. It's good for memory efficiency since it could use
up CMA available memory most of time. However, it could cause
cma_alloc slow since it causes a lot page migration all the time.
Let's add vendor hook for someone who want to restore CMA allocation
policy to upstream so they will see less page migration in cma_alloc.
If the vendor_hook returns false, the rmqueue_bulk return 0 without
filling pcp->lists so get_populated_pcp_list will return NULL.
Once get_populated_pcp_list returns NULL, __rmqueue_pcplist will retry
the page allocation with original migratetype(currently, original
migratetype couldn't be MIGRATE_CMA) so the retrial will find
available pages from !MIGRATE_CMA free list.
Bug: 231978523
Signed-off-by: Minchan Kim <minchan@google.com>
Change-Id: Ia031d9bc6f34085b892a8d9923bf5b9b1794f94a
Signed-off-by: Richard Chang <richardycc@google.com>
(cherry picked from commit 0ca85e35bf)
From the UFSHCI 4.0 specification, about the legacy (single queue) mode:
"The host controller always process transfer requests in-order according
to the order submitted to the list. In case of multiple commands with
single doorbell register ringing (batch mode), The dispatch order for
these transfer requests by host controller will base on their index in
the List. A transfer request with lower index value will be executed
before a transfer request with higher index value."
From the UFSHCI 4.0 specification, about the MCQ mode:
"Command Submission
1. Host SW writes an Entry to SQ
2. Host SW updates SQ doorbell tail pointer
Command Processing
3. After fetching the Entry, Host Controller updates SQ doorbell head
pointer
4. Host controller sends COMMAND UPIU to UFS device"
In other words, for both legacy and MCQ mode, UFS controllers are
required to forward commands to the UFS device in the order these
commands have been received from the host.
Note: for legacy mode this is only correct if the host submits one
command at a time. The UFS driver does this.
Bug: 264714656
Change-Id: Ib123827a32828ee4dbe3c5e45d5fb83ffe5314da
Signed-off-by: Bart Van Assche <bvanassche@google.com>
From ZBC-2: "The device server terminates with CHECK CONDITION status, with
the sense key set to ILLEGAL REQUEST, and the additional sense code set to
UNALIGNED WRITE COMMAND a write command, other than an entire medium write
same command, that specifies: a) the starting LBA in a sequential write
required zone set to a value that is not equal to the write pointer for that
sequential write required zone; or b) an ending LBA that is not equal to the
last logical block within a physical block (see SBC-5)."
I am not aware of any other conditions that may trigger the UNALIGNED
WRITE COMMAND response.
Retry unaligned writes in preparation of removing zone locking.
Increase the number of retries for write commands sent to a sequential
zone to the maximum number of outstanding commands.
Bug: 264714656
Change-Id: If89c1f0b4d382978c52382dd3634f39fc15bcaf0
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Measurements have shown that limiting the queue depth to one for zoned
writes has a significant negative performance impact on zoned UFS devices.
Hence this patch that disables zone locking from the mq-deadline scheduler
for storage controllers that support pipelining zoned writes. This patch is
based on the following assumptions:
- Applications submit write requests to sequential write required zones
in order.
- It happens infrequently that zoned write requests are reordered by the
block layer.
- The storage controller does not reorder write requests that have been
submitted to the same hardware queue. This is the case for UFS: the
UFSHCI specification requires that UFS controllers process requests in
order per hardware queue.
- The I/O priority of all pipelined write requests is the same per zone.
- Either no I/O scheduler is used or an I/O scheduler is used that
submits write requests per zone in LBA order.
If applications submit write requests to sequential write required zones
in order, at least one of the pending requests will succeed. Hence, the
number of retries that is required is at most (number of pending
requests) - 1.
Bug: 264714656
Change-Id: I66265cd86e3f21e1a77ee7e49f94b0e756103c9b
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Writes in sequential write required zones must happen at the write
pointer. Even if the submitter of the write commands (e.g. a filesystem)
submits writes for sequential write required zones in order, the block
layer or the storage controller may reorder these write commands.
The zone locking mechanism in the mq-deadline I/O scheduler serializes
write commands for sequential zones. Some but not all storage controllers
require this serialization. Introduce a new flag such that block drivers
can request pipelining of writes for sequential write required zones.
An example of a storage controller standard that requires write
serialization is AHCI (Advanced Host Controller Interface). Submitting
commands to AHCI controllers happens by writing a bit pattern into a
register. Each set bit corresponds to an active command. This mechanism
does not preserve command ordering information.
Bug: 264714656
Change-Id: I1f64eb61571a66b99a0d83bef4438e2187c16f8e
Signed-off-by: Bart Van Assche <bvanassche@google.com>
process_notifier() is called every time a process exits. When multiple
processes exit roughly at the same time, the uid_lock taken from inside
of process_notifier() will create contention which slows down process
exit. Defer stats accounting in such case to avoid lock contention.
Bug: 261537194
Change-Id: Ia1e9a451eab39eb0dda7eb175bfd71c67f3e0a58
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
(cherry picked from commit 5d96c24be923d9011762de19bcfbade68b103759)
pKVM modules can't rely on the usual hyp function kern_hyp_va() to
convert addr from the kernel space to the hyp's. Instead, provide
pkvm_el2_mod_va() that will do the conversion using the token provided
by pkvm_load_el2_module().
Bug: 244543039
Bug: 244373730
Change-Id: I7423b40f1107bb92cd732843c5cdbf1d45662f00
Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
Exporsing HotPlugDetect(HPD) helps userspace to infer HPD
state as defined by VESA DisplayPort Alt Mode on USB Type-C Standard.
This allows userspace to notify users for self help, for instance,
to hint user that the display port cable is probably detached (or)
the display port sink (viz., monitors ect.,) is un-powered.
Also helps to debug issues reported from field.
This change adds an additional attribute "hpd" to the existing
"displayport" attributes.
VESA DisplayPort Alt Mode on USB Type-C Standard defines how
HotPlugDetect(HPD) shall be supported on the USB-C connector
when operating in DisplayPort Alt Mode. This is a read only
node which reflects the current state of HPD.
Valid values:
- 1 when HPD’s logical state is high (HPD_High)
- 0 when HPD’s logical state is low (HPD_Low)
This is also a partial backport from
7f81139487 ("usb: typec: altmodes/displayport: Notify drm subsys of hotplug events")
as part of the logic is dependent on that change.
Bug: 253534975
Bug: 260915739
Change-Id: Id72e8ef6ede84038479649c2b753acdac547dea1
Signed-off-by: Badhri Jagan Sridharan <badhri@google.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/lkml/20221211193755.1392128-1-badhri@google.com/T/
(cherry picked from commit 001b0c780e
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-testing)
Export find_vm_area for obtaining pages of vmalloc'ed memory, which is
required for both GXP and TPU modules.
Bug: 263839332
Change-Id: I1d6c37a5abb6012c3ff295120dd2d3cb2871c820
Signed-off-by: davidchiang <davidchiang@google.com>
Fix the calculation to determine the number of module relocs present in
the '.hyp.reloc' section to divide by the size of 'kvm_nvhe_reloc_t' (4)
instead of the size of a pointer (8).
Fixes: ace5025390 ("ANDROID: KVM: arm64: Resolve hyp module addresses using ELF sections")
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Will Deacon <willdeacon@google.com>
Bug: 261855285
Change-Id: Ia7afc508039d549ae061793afa39fde9d844c069
Modules with an empty '.hyp.text' section do not contain any EL2 code
and should therefore be ignored for the purposes of hypervisor module
loading. Failing to ignore such modules will likely result in a later
loading failure due to the absence of '.hyp.reloc', which is not present
for non-hypervisor modules.
Don't bother parsing the other '.hyp.*' sections for modules with an
empty '.hyp.text' section and return early success to allow the module
to load as a normal kernel module.
Fixes: ace5025390 ("ANDROID: KVM: arm64: Resolve hyp module addresses using ELF sections")
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Will Deacon <willdeacon@google.com>
Bug: 261855285
Change-Id: Idc24f95881c520b40038f77cd5af5ccc1d23624f
Introduce a function that makes it easy to verify whether a write
request is for a sequential write required or sequential write preferred
zone. Simplify blk_req_needs_zone_write_lock() by using the new function.
Bug: 264714656
Change-Id: I24677065f0c3b63900a885da5b4c8ea4ba0fb14c
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Since it is nontrivial to figure out how disk_zone_is_seq() and
blk_rq_zone_is_seq() handle sequential write preferred zones, document
this.
Bug: 264714656
Change-Id: I6d58683c302c29dc3134dcaf422b3e5c092092c1
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Commit 237405ebef ("arm64: cpufeature: Force HWCAP to be based on the
sysreg visible to user-space") forced the hwcaps to use sanitised
user-space view of the id registers. However, the ID register structures
used to select few compat cpufeatures (vfp, crc32, ...) are masked and
hence such hwcaps do not appear in /proc/cpuinfo anymore for PER_LINUX32
personality.
Add the ID register structures explicitly and set the relevant entry as
visible. As these ID registers are now of type visible so make them
available in 64-bit userspace by making necessary changes in register
emulation logic and documentation.
While at it, update the comment for structure ftr_generic_32bits[] which
lists the ID register that use it.
Fixes: 237405ebef ("arm64: cpufeature: Force HWCAP to be based on the sysreg visible to user-space")
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Reviewed-by: James Morse <james.morse@arm.com>
Signed-off-by: Amit Daniel Kachhap <amit.kachhap@arm.com>
Link: https://lore.kernel.org/r/20221103082232.19189-1-amit.kachhap@arm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Bug: 261510586
Change-Id: I9d1a779fe849e0a2069fc3e385c88532db84b7b4
(cherry picked from commit 85f1506337)
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Cortex-A510's erratum #2658417 causes two BF16 instructions to return the
wrong result in rare circumstances when a pair of A510 CPUs are using
shared neon hardware.
The two instructions affected are BFMMLA and VMMLA, support for these is
indicated by the BF16 HWCAP. Remove it on affected platforms.
Signed-off-by: James Morse <james.morse@arm.com>
Link: https://lore.kernel.org/r/20220909165938.3931307-4-james.morse@arm.com
[catalin.marinas@arm.com: add revision to the Kconfig help; remove .type]
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Conflicts:
arch/arm64/include/asm/sysreq.h
1. Added definition for ID_AA64ISAR1_EL1_BF16_MASK
Bug: 261510586
Change-Id: I83a5dd577fc8c0edd83c40b21f3fe54c54b6a9fa
(cherry picked from commit 1bdb0fbb2e)
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
arm64 advertises hardware features to user-space via HWCAPs, and by
emulating access to the CPUs id registers. The cpufeature code has a
sanitised system-wide view of an id register, and a sanitised user-space
view of an id register, where some features use their 'safe' value
instead of the hardware value.
It is currently possible for a HWCAP to be advertised where the user-space
view of the id register does not show the feature as supported.
Erratum workaround need to remove both the HWCAP, and the feature from
the user-space view of the id register. This involves duplicating the
code, and spreading it over cpufeature.c and cpu_errata.c.
Make the HWCAP code use the user-space view of id registers. This ensures
the values never diverge, and allows erratum workaround to remove HWCAP
by modifying the user-space view of the id register.
Signed-off-by: James Morse <james.morse@arm.com>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Link: https://lore.kernel.org/r/20220909165938.3931307-2-james.morse@arm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Bug: 261510586
Change-Id: I86bac3f501bf72ac9ee8fa6e9755ae9fbbdc81e6
(cherry picked from commit 237405ebef)
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Following "ANDROID: fips140: eliminate crypto-fips.a build step", the
only remaining dependency on LTO is the fact that the part of the module
linker script that merges the text and rodata sections and adds some
symbols is guarded by '#ifdef CONFIG_LTO_CLANG'.
This doesn't actually need to be the case, though. So guard it by
alternatively IS_ENABLED(CONFIG_CRYPTO_FIPS140_MOD).
Then, remove the dependency of CRYPTO_FIPS140_MOD on LTO_CLANG.
(Note: the android14-6.1 kernel currently has LTO disabled, which is
part of the motivation for this change. I don't know whether it will
stay that way, though.)
Bug: 188620248
Change-Id: I1aa7b293ac7a793721275e06e3ae40628e26bbc4
Signed-off-by: Eric Biggers <ebiggers@google.com>
To trick the build system into compiling some source files as built-in
code despite their actual destination being fips140.ko, a layer of
indirection was being used where the files were first built into a
static library crypto-fips.a, and then that static library was linked
into fips140.o before the final link of fips140.ko.
The problem with that approach is that it is incompatible with the usual
behavior of linking, where linking to a static library incorporates only
the needed parts of the library, not the whole library. The only reason
that it happened to work anyway is due to the dependency of the fips140
module on LTO, combined with a peculiarity of the way that the kernel
build system built LTO modules: the build system actually created
${modname}.o as a static library (despite the .o suffix), and used the
--whole-archive linker flag when linking ${modname}.ko.
commit c25e1c5582 ("kbuild: do not create *.prelink.o for Clang LTO or
IBT") in Linux v5.19 changed that. Now, ${modname}.o is an object file,
and the --whole-archive flag isn't used when linking ${modname}.ko.
Therefore, the crypto-fips.a hack no longer works, as things from this
static library (such as the initcalls) get lost during linking.
Replace it with a different hack that eliminates the dependency on LTO
and should be less fragile: undefine MODULE in fips140-defs.h, and
re-define it in the one file where it is needed. (For consistency, also
move the definition of __DISABLE_EXPORTS into fips140-defs.h.)
Bug: 188620248
Change-Id: I4a6a5f68381a7540bf37ba610216442dae0d2a7a
Signed-off-by: Eric Biggers <ebiggers@google.com>
KCFI generates ABS32 relocations in the .text section. In the temporary
copy of the .text section that the FIPS integrity check is done on,
these relocations need to be unapplied for the integrity check to pass.
Example from 'llvm-readelf --relocs --wide fips140.ko':
Relocation section '.rela.text' at offset 0x5b4a8 contains 2008 entries:
Offset Info Type Symbol's Value Symbol's Name + Addend
[...]
0000000000000c80 0000092900000102 R_AARCH64_ABS32 0000000050e29065 __kcfi_typeid_pmull_ghash_update_p64 + 0
0000000000000e08 0000092800000102 R_AARCH64_ABS32 0000000050e29065 __kcfi_typeid_pmull_ghash_update_p8 + 0
Bug: 188620248
Change-Id: I85c01641114a66b2603abce467977823469f50c8
Signed-off-by: Eric Biggers <ebiggers@google.com>
CONFIG_CRYPTO_FIPS140_MOD builds a loadable kernel module when set to
'y'. That's very unusual, as it doesn't follow the convention of
loadable modules being 'm'.
I'm guessing that the reason that a bool was used instead of a tristate
is because this functionality is not supported built-in, so there are
only two allowed settings: disabled or modular.
However, there's actually a way to express that in the kconfig language:
a tristate that depends on 'm'. Let's do it that way.
This also eliminates the need to explicitly depend on MODULES.
(Note: I decided to keep MOD in the name, since the word "module" in
"FIPS 140 cryptographic module" is a different meaning of "module", and
I didn't want to bother renaming CRYPTO_FIPS140_MOD_EVAL_TESTING too.)
Bug: 188620248
Change-Id: Ib195d64d68c23ca93dd244d9ac77255992870424
Signed-off-by: Eric Biggers <ebiggers@google.com>
There is no good reason for the CRYPTO_FIPS140 kconfig option to exist
separately from CRYPTO_FIPS140_MOD. It existed mainly to guard some
code in the module loader that was needed only for loading the fips140
module. However, that code has been removed, since an alternate
solution that doesn't require changes to the module loader was found.
The remaining references to CRYPTO_FIPS140 are in:
- scripts/module.lds.S. But the guarded code only affects building the
fips140 module, so CRYPTO_FIPS140_MOD should be used here instead.
- lib/crypto/, for guarding the Android vendor hooks required by the
fips140 module. However, Android vendor hooks are already guarded by
ANDROID_VENDOR_HOOKS. The extra guard by CRYPTO_FIPS140 isn't useful,
especially since CRYPTO_FIPS140 was effectively hardcoded to y anyway.
It did have the side effect of making the hooks be guarded by arm64,
which excluded them from builds of arch/x86/purgatory/. However, a
cleaner way to accomplish that is to check for __DISABLE_EXPORTS,
which handles both arch/x86/purgatory/ and fips140.ko itself.
Bug: 188620248
Change-Id: Ic6141cd2a553540c2bf95774e71de7310926e3ce
Signed-off-by: Eric Biggers <ebiggers@google.com>
Kernel code is expected to support both in-tree and out-of-tree builds.
Fix in-tree builds of the fips140 module by using the full include path
for fips140-defs.h.
Bug: 188620248
Change-Id: Iba5ed888bc6a316bd4d0a97479768f50094d63d0
Signed-off-by: Eric Biggers <ebiggers@google.com>
The customizations to the module linker script required by the fips140
module are currently split between scripts/module.lds.S and a file it
includes, arch/arm64/include/asm/module.lds.h. There isn't actually
anything architecture-specific about the part that was put into the
architecture-specific file, though. Let's move that part into
scripts/module.lds.S so that the fips140 changes are in the same file.
Bug: 188620248
Change-Id: If559a216e026d2107cdf3291b487686fdb21a5e8
Signed-off-by: Eric Biggers <ebiggers@google.com>
This reverts commit 9cb398bd05.
The '__hyprel_{start,end}' symbols are no longer used, so don't bother
generating them.
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Will Deacon <willdeacon@google.com>
Bug: 261855285
Change-Id: I8e8dc5c94a9e67400e73e362e4377032328d86d4
Resolving the addresses of the hypervisor sections within a loadable
module using symbol assignment is fragile, particularly in the face of
mergeable sections (i.e. those emitted with SHF_MERGE by the compiler).
Instead, parse the ELF .hyp.* sections directly and remove the need for
global symbols in the hypervisor module linker script.
Signed-off-by: Will Deacon <will@kernel.org>
[will: Preserve function_nocfi() calls which aren't needed in android14-6.1]
Signed-off-by: Will Deacon <willdeacon@google.com>
Bug: 261855285
Change-Id: I91d88e1a341b91ffe52ffc770dddc9b46ccb3aa4
Currently, only HS descriptors will be updated with endpoint address
during binding process. According to current max_speed in configfs,
this patch will also update SS/SSP descriptors with endpoint address.
Bug: 162562782
Signed-off-by: Ray Chi <raychi@google.com>
Change-Id: I67983ef47df7ac567ec1d3af80921c39c98a545d
(cherry picked from commit 41fe558317)
(cherry picked from commit ba3ec687b7)
There shouldn't be any restriction of the descriptor size (not the
descriptor id for that matter) up to QUERY_DESC_MAX_SIZE. According to the
spec, the caller can use any descriptor size, and it is up to the device to
return the actual size. Therefore there shouldn't be any sizes hardcoded
in the kernel, nor any need to cache it, hence the
ufshcd_map_desc_id_to_length() function is redundant. Always read the
descriptors with QUERY_DESC_MAX_SIZE size.
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Reviewed-by: Bean Huo <beanhuo@micron.com>
Suggested-by: Bean Huo <beanhuo@micron.com>
Change-Id: I7933da0b7ec3771b9faccb2c8fe05bb83f741162
Signed-off-by: Arthur Simchaev <Arthur.Simchaev@wdc.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Bug: 258234315
(cherry picked from commit 16ed9d312b git://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git for-next)
Signed-off-by: Bart Van Assche <bvanassche@google.com>
len argument is not used anymore in ufshcd_set_active_icc_lvl() function.
Change-Id: I351a36061dbc0f2f61bae371892c2de2fed3dcc1
Signed-off-by: Arthur Simchaev <Arthur.Simchaev@wdc.com>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Reviewed-by: Bean Huo <beanhuo@micron.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Bug: 258234315
(cherry picked from commit 01a0d515b7 git://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git for-next)
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Always read the descriptor with QUERY_DESC_MAX_SIZE. According to the
spec, the device returns the actual size.
Change-Id: I29053a66d1f65f674fba6d7e1a6c6e7f546eec74
Signed-off-by: Arthur Simchaev <Arthur.Simchaev@wdc.com>
Reviewed-by: Bean Huo <beanhuo@micron.com>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Bug: 258234315
(cherry picked from commit f2a89b071b git://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git for-next)
Signed-off-by: Bart Van Assche <bvanassche@google.com>
We used to use the extended-feature field in the device descriptor as an
indication that the device supported UFS 2.2 or later. Remove that as this
check is specifically done few lines above.
Change-Id: I3291740eb846215c87cefe36c60fe09a7f4f2856
Signed-off-by: Arthur Simchaev <Arthur.Simchaev@wdc.com>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Reviewed-by: Bean Huo <beanhuo@micron.com>
Reviewed-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Bug: 258234315
(cherry picked from commit 358ae02f47 git://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git for-next)
Signed-off-by: Bart Van Assche <bvanassche@google.com>
dev_err() statements are better to use than pr_err(), so switch to those.
In a similar vein, the check on the dev_req_params pointer here is not
needed, the two places this function is called never pass in a NULL
pointer, so instead of using dev_err() there just remove it.
Change-Id: I012f6a6d02f00a4295dab59ffb6772dce3f77149
Signed-off-by: Andrew Halaney <ahalaney@redhat.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Reviewed-by: Asutosh Das <quic_asutoshd@quicinc.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Bug: 258234315
(cherry picked from commit 1026f7d366 git://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git for-next)
Signed-off-by: Bart Van Assche <bvanassche@google.com>
This bitmask is unconditionally set in the current driver, so all
conditionals using it can be considered bit rot.
Let's take the current default conditional path everywhere and remove
dbg_print_en from the driver.
Change-Id: I7b83c8a11829963efacadd9969b50d3eeb4ec177
Signed-off-by: Andrew Halaney <ahalaney@redhat.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Reviewed-by: Asutosh Das <quic_asutoshd@quicinc.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Bug: 258234315
(cherry picked from commit e4ce23fba3 git://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git for-next)
Signed-off-by: Bart Van Assche <bvanassche@google.com>
The current implementation has abstractions that don't give any benefits.
The print_fn callback (and its only callback implementation,
ufs_qcom_dump_regs_wrapper()) was only used by
ufs_qcom_print_hw_debug_reg_all() and just multiplies len by 4 before
calling ufshcd_dump_regs().
ufs_qcom_print_hw_debug_reg_all() is only called by
ufs_qcom_dump_dbg_regs().
There's no real gain in those abstractions, so let's just do the work
directly in ufs_qcom_dump_dbg_regs() (the dbg_register_dump callback).
Change-Id: I5085c094e56319ea519c2e6e0a28f97be49e4a30
Signed-off-by: Andrew Halaney <ahalaney@redhat.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Reviewed-by: Asutosh Das <quic_asutoshd@quicinc.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Bug: 258234315
(cherry picked from commit 50a427a00c git://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git for-next)
Signed-off-by: Bart Van Assche <bvanassche@google.com>
This code path is only called through one function, and the HBA struct is
already accessed in ufshcd_vops_dbg_register_dump() prior to calling so
there is no way for it to be NULL.
Likewise, the print_fn callback is always supplied within this driver and
is always provided.
Change-Id: I7c0b84767d094568e998bcfa11008a2e19c0554b
Signed-off-by: Andrew Halaney <ahalaney@redhat.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Reviewed-by: Asutosh Das <quic_asutoshd@quicinc.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Bug: 258234315
(cherry picked from commit 921a880827 git://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git for-next)
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Add advanced RPMB support in ufs_bsg:
1. According to the UFS specification, only one RPMB operation can be
performed at any time. We can ensure this by using reserved slot and
its dev_cmd sync operation protection mechanism.
2. For Advanced RPMB, RPMB metadata is packaged in an EHS (Extra Header
Segment) of a command UPIU, and the corresponding reply EHS (from the
device) should also be returned to the user space. bsg_job->request
and bsg_job->reply allow us to pass and return EHS from/back to
userspace.
Compared to normal/legacy RPMB, the advantages of advanced RPMB are:
1. The data length in the Advanced RPMB data read/write command can be
larger than 4KB. For the legacy RPMB, the data length in a single RPMB
data transfer is 256 bytes.
2. All of the advanced RPMB operations will be a single command. For
legacy RPMB, take the read write-counter value as an example, you need
two commands (first SECURITY PROTOCOL OUT, then second SECURITY
PROTOCOL IN).
Change-Id: Iefadc64abb18c1dd6ac5e416ed692be9b7019d71
Signed-off-by: Bean Huo <beanhuo@micron.com>
Reviewed-by: Avri Altman <avri.altman@wdc.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Bug: 258234315
(cherry picked from commit 6ff265fc5e git://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git for-next)
Signed-off-by: Bart Van Assche <bvanassche@google.com>
We need to fill in the total EHS length in UTP Transfer Request Descriptor.
Add this functionality to ufshcd_prepare_req_desc_hdr().
Change-Id: Ifdc93e0877226d437daae95e7385b26d899188d4
Signed-off-by: Bean Huo <beanhuo@micron.com>
Reviewed-by: Avri Altman <avri.altman@wdc.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Bug: 258234315
(cherry picked from commit a4b1c9b9b3 git://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git for-next)
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Check UFS Advanced RPMB LU enablement during ufshcd_lu_init().
Change-Id: Ib923917dd9144f824bc08e4b600e6fd54e1716a5
Signed-off-by: Bean Huo <beanhuo@micron.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Bug: 258234315
(cherry picked from commit f6b9d0fe5c git://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git for-next)
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Take out the "map scatter-gather list to prdt" part of the code in
ufshcd_map_sg() and split it into a new function ufshcd_sgl_to_prdt().
Change-Id: Idd40c405ab09cb1154eae17abcd921b0ea0013c9
Signed-off-by: Bean Huo <beanhuo@micron.com>
Reviewed-by: Avri Altman <avri.altman@wdc.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Bug: 258234315
(cherry picked from commit 7a4df79d0b git://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git for-next)
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Remove checks on job->request_len and job->reply_len because msgcode checks
in a subseqent commit will rule out malicious requests.
Change-Id: I62580fb6e8facf3983d51664e69c821db0bc5684
Signed-off-by: Bean Huo <beanhuo@micron.com>
Acked-by: Avri Altman <avri.altman@wdc.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Bug: 258234315
(cherry picked from commit 64d4864714 git://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git for-next)
Signed-off-by: Bart Van Assche <bvanassche@google.com>
