The UFS driver uses blk_mq_tagset_busy_iter() when identifying task
management requests to complete, however blk_mq_tagset_busy_iter()
doesn't work.
blk_mq_tagset_busy_iter() only iterates requests dispatched by the block
layer. That appears as if it might have started since commit 37f4a24c24
("blk-mq: centralise related handling into blk_mq_get_driver_tag") which
removed 'data->hctx->tags->rqs[rq->tag] = rq' from blk_mq_rq_ctx_init()
which gets called:
blk_get_request
blk_mq_alloc_request
__blk_mq_alloc_request
blk_mq_rq_ctx_init
Since UFS task management requests are not dispatched by the block
layer, hctx->tags->rqs[rq->tag] remains NULL, and since
blk_mq_tagset_busy_iter() relies on finding requests using
hctx->tags->rqs[rq->tag], UFS task management requests are never found by
blk_mq_tagset_busy_iter().
By using blk_mq_tagset_busy_iter(), the UFS driver was relying on internal
details of the block layer, which was fragile and subsequently got
broken. Fix by removing the use of blk_mq_tagset_busy_iter() and having
the driver keep track of task management requests.
Fixes: 1235fc569e ("scsi: ufs: core: Fix task management request completion timeout")
Fixes: 69a6c269c0 ("scsi: ufs: Use blk_{get,put}_request() to allocate and free TMFs")
Cc: stable@vger.kernel.org
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Bug: 200291871
Link: https://lore.kernel.org/linux-scsi/20210922091059.4040-1-adrian.hunter@intel.com/
Change-Id: I4e11f40c7371fd66b3a6b570d06c956b113df142
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Before adding more data members in struct ufs_hba_with_hpb, rename this
data structure. This patch does not change any functionality.
Bug: 200291871
Change-Id: I6b0365ebcf8adf6cfa009218d8c4dc96fa629bde
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Currently the core UFS driver does not have a vops to notify when the
device is operational. This commit introduces a hook, which serves to
notify device completing initialization and is ready to accept I/O.
This is required by the FIPS140-2 [1] self integrity test of inline
encryption engine, which must run whenever the host controller is reset.
The code requires sleeping while waiting for I/O to complete and allocating
some memory dynamically, which requires the vendor hook to be restricted.
[1] https://csrc.nist.gov/publications/detail/fips/140/2/final
Bug: 185809932
Signed-off-by: Konstantin Vyshetsky <vkon@google.com>
Change-Id: I6f476f9c2e2b50574d2898c3f1ef6b648d92df24
Before this patch, someone who wants to use VMAP_STACK when
KASAN_GENERIC enabled must explicitly select KASAN_VMALLOC.
>From Will's suggestion [1]:
> I would _really_ like to move to VMAP stack unconditionally, and
> that would effectively force KASAN_VMALLOC to be set if KASAN is in use
Because VMAP_STACK now depends on either HW_TAGS or KASAN_VMALLOC if
KASAN enabled, in order to make VMAP_STACK selected unconditionally,
we bind KANSAN_GENERIC and KASAN_VMALLOC together.
Note that SW_TAGS supports neither VMAP_STACK nor KASAN_VMALLOC now,
so this is the first step to make VMAP_STACK selected unconditionally.
Bind KANSAN_GENERIC and KASAN_VMALLOC together is supposed to cost more
memory at runtime, thus the alternative is using SW_TAGS KASAN instead.
[1]: https://lore.kernel.org/lkml/20210204150100.GE20815@willie-the-truck/
Suggested-by: Will Deacon <will@kernel.org>
Signed-off-by: Lecopzer Chen <lecopzer.chen@mediatek.com>
Link: https://lore.kernel.org/r/20210324040522.15548-6-lecopzer.chen@mediatek.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Bug: 201711661
(cherry picked from commit acc3042d62)
Signed-off-by: Yee Lee <yee.lee@mediatek.com>
Change-Id: Ic7884e3acafa02361c8a250028ceebdb1780a49e
After KASAN_VMALLOC works in arm64, we can randomize module region
into vmalloc area now.
Test:
VMALLOC area ffffffc010000000 fffffffdf0000000
before the patch:
module_alloc_base/end ffffffc008b80000 ffffffc010000000
after the patch:
module_alloc_base/end ffffffdcf4bed000 ffffffc010000000
And the function that insmod some modules is fine.
Suggested-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Lecopzer Chen <lecopzer.chen@mediatek.com>
Link: https://lore.kernel.org/r/20210324040522.15548-5-lecopzer.chen@mediatek.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Bug: 201711661
(cherry picked from commit 31d02e7ab0)
Signed-off-by: Yee Lee <yee.lee@mediatek.com>
Change-Id: I513f205113752b396245e9e8d64b973fcd7ffcb1
Linux support KAsan for VMALLOC since commit 3c5c3cfb9e
("kasan: support backing vmalloc space with real shadow memory")
Like how the MODULES_VADDR does now, just not to early populate
the VMALLOC_START between VMALLOC_END.
Before:
MODULE_VADDR: no mapping, no zero shadow at init
VMALLOC_VADDR: backed with zero shadow at init
After:
MODULE_VADDR: no mapping, no zero shadow at init
VMALLOC_VADDR: no mapping, no zero shadow at init
Thus the mapping will get allocated on demand by the core function
of KASAN_VMALLOC.
----------- vmalloc_shadow_start
| |
| |
| | <= non-mapping
| |
| |
|-----------|
|///////////|<- kimage shadow with page table mapping.
|-----------|
| |
| | <= non-mapping
| |
------------- vmalloc_shadow_end
|00000000000|
|00000000000| <= Zero shadow
|00000000000|
------------- KASAN_SHADOW_END
Signed-off-by: Lecopzer Chen <lecopzer.chen@mediatek.com>
Acked-by: Andrey Konovalov <andreyknvl@gmail.com>
Tested-by: Andrey Konovalov <andreyknvl@gmail.com>
Tested-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://lore.kernel.org/r/20210324040522.15548-2-lecopzer.chen@mediatek.com
[catalin.marinas@arm.com: add a build check on VMALLOC_START != MODULES_END]
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Bug: 201711661
(cherry picked from commit 9a0732efa7)
Signed-off-by: Yee Lee <yee.lee@mediatek.com>
Change-Id: I82c4b624685cc9e083d720904787df2326cb9cc0
This lets us avoid doing unnecessary work on hardware that does not
support MTE, and will allow us to freely use MTE instructions in the
code called by mte_thread_switch().
Since this would mean that we do a redundant check in
mte_check_tfsr_el1(), remove it and add two checks now required in its
callers. This also avoids an unnecessary DSB+ISB sequence on the syscall
exit path for hardware not supporting MTE.
Fixes: 65812c6921 ("arm64: mte: Enable async tag check fault")
Cc: <stable@vger.kernel.org> # 5.13.x
Signed-off-by: Peter Collingbourne <pcc@google.com>
Link: https://linux-review.googlesource.com/id/I02fd000d1ef2c86c7d2952a7f099b254ec227a5d
Link: https://lore.kernel.org/r/20210915190336.398390-1-pcc@google.com
[catalin.marinas@arm.com: adjust the commit log slightly]
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
(cherry picked from commit 8c8a3b5bd9)
Change-Id: I131933b18581a40cea9abf556625c80b12e4e974
Bug: 192536783
When KASAN_HW_TAGS is selected, KASAN is enabled at boot time, and the
hardware supports MTE, we'll initialize `kernel_gcr_excl` with a value
dependent on KASAN_TAG_MAX. While the resulting value is a constant
which depends on KASAN_TAG_MAX, we have to perform some runtime work to
generate the value, and have to read the value from memory during the
exception entry path. It would be better if we could generate this as a
constant at compile-time, and use it as such directly.
Early in boot within __cpu_setup(), we initialize GCR_EL1 to a safe
value, and later override this with the value required by KASAN. If
CONFIG_KASAN_HW_TAGS is not selected, or if KASAN is disabeld at boot
time, the kernel will not use IRG instructions, and so the initial value
of GCR_EL1 is does not matter to the kernel. Thus, we can instead have
__cpu_setup() initialize GCR_EL1 to a value consistent with
KASAN_TAG_MAX, and avoid the need to re-initialize it during hotplug and
resume form suspend.
This patch makes arem64 use a compile-time constant KERNEL_GCR_EL1
value, which is compatible with KASAN_HW_TAGS when this is selected.
This removes the need to re-initialize GCR_EL1 dynamically, and acts as
an optimization to the entry assembly, which no longer needs to load
this value from memory. The redundant initialization hooks are removed.
In order to do this, KASAN_TAG_MAX needs to be visible outside of the
core KASAN code. To do this, I've moved the KASAN_TAG_* values into
<linux/kasan-tags.h>.
There should be no functional change as a result of this patch.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Andrey Konovalov <andreyknvl@gmail.com>
Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Peter Collingbourne <pcc@google.com>
Cc: Vincenzo Frascino <vincenzo.frascino@arm.com>
Cc: Will Deacon <will@kernel.org>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Andrey Konovalov <andreyknvl@gmail.com>
Tested-by: Andrey Konovalov <andreyknvl@gmail.com>
Link: https://lore.kernel.org/r/20210714143843.56537-3-mark.rutland@arm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
(cherry picked from commit 8286824789)
Change-Id: I397025af7051bedcdd35987af5deec46c228f8e2
Signed-off-by: Peter Collingbourne <pcc@google.com>
Bug: 192536783
Somehow the android/abi_gki_aarch64.xml file became executable in a
previous commit. Fix this up by setting the mode properly.
Bug: 149040612
Cc: Chun-Hung Wu <chun-hung.wu@mediatek.com>
Cc: Sandeep Patil <sspatil@google.com>
Fixes: 55d7c4eca6 ("ANDROID: Update symbol list for mtk")
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Iecb61df3481cf2a257d2f999297a98cdbcb38295
This patch does not add any new symbol, but make the symbol list order
by the module.
Bug: 194515348
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Change-Id: I0bec2f90a46ec92d7e391ab9e9c49180c4d87ae9
Select Type-C related configs for Rockchip SoCs.
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
Change-Id: I301d6538998a56788d88ab860e4270122783c918
This adds optional vbus control for husb311 Type-C controller.
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
Change-Id: Idebff3cee16b10a9df4fa90b75d01b6a2223a5a4
At present, there is no requirement for PD3.0 PPS function,
the driver has not verified this function.
Change-Id: Ib78bf1f96f806cca4a20567db2a7cbaf0fba01af
Signed-off-by: Wang Jie <dave.wang@rock-chips.com>
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
Add device tree binding document for Hynetek husb311 Type-C chip driver.
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
Change-Id: Ibe54b039ee773c5a99d5f7688d0695999fb45611
move alpha scale to crtc feature and add hdr10/dolby hdr info to
feature to interaction with userspace, and remove alpha_scale_prop from
rockchip_drm_drv.c
Signed-off-by: Sandy Huang <hjc@rock-chips.com>
Change-Id: Ic56c7a53c890702ce4a70167ea9926aa32b29fa7
move alpha scale to crtc feature and add hdr10/dolby hdr info to feature
to interaction with userspace.
Signed-off-by: Sandy Huang <hjc@rock-chips.com>
Change-Id: I492647a22b41bf43c3127bd56b2ed0b3b95284a2
used_layers should reset to 0 before count
port_mux.
And also fix the follow warning:
drivers/gpu/drm/rockchip/rockchip_drm_vop2.c:2538:26: warning: Value
stored to 'vp' during its initialization is never read
drivers/gpu/drm/rockchip/rockchip_drm_vop2.c:2537:21: warning: Value
stored to 'layer' during its initialization is never read
Fixes: e013d2544c ("drm/rockchip: vop2: Assign plane for vp by
plane_mask")
Change-Id: I56b1576070392b7b262ef65b19cf14d1bfde0586
Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
