Fix the following kernel-doc warnings:
drivers/ufs/core/ufs-mcq.c:87: warning: Function parameter or member 'hba' not described in 'ufshcd_mcq_config_mac'
drivers/ufs/core/ufs-mcq.c:87: warning: Function parameter or member 'max_active_cmds' not described in 'ufshcd_mcq_config_mac'
drivers/ufs/core/ufs-mcq.c:107: warning: Function parameter or member 'hba' not described in 'ufshcd_mcq_req_to_hwq'
drivers/ufs/core/ufs-mcq.c:107: warning: Function parameter or member 'req' not described in 'ufshcd_mcq_req_to_hwq'
drivers/ufs/core/ufs-mcq.c:128: warning: Function parameter or member 'hba' not described in 'ufshcd_mcq_decide_queue_depth'
Link: https://lore.kernel.org/r/20230202220155.561115-1-bvanassche@acm.org
Fixes: 854f84e7feeb ("scsi: ufs: core: mcq: Find hardware queue to queue request")
Fixes: 2468da61ea09 ("scsi: ufs: core: mcq: Configure operation and runtime interface")
Fixes: 7224c806876e ("scsi: ufs: core: mcq: Calculate queue depth")
Cc: Asutosh Das <quic_asutoshd@quicinc.com>
Change-Id: Ieee720d2b8f3bc26618f00f146ba32dd3f48aa67
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Reviewed-by: Asutosh Das <quic_asutoshd@quicinc.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit b62c8292d223c8e7eafb3cfd2e997cbb63d15e23 git://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git for-next)
Signed-off-by: Bart Van Assche <bvanassche@google.com>
The three DMA memory regions allocated for the host memory space are
documented to require alignment of 128, 1024, and 1024 respectively, but
the returned address is checked for PAGE_SIZE alignment.
In the case where these allocations are serviced by e.g. the Arm SMMU, the
size and alignment will be determined by its supported page sizes. In most
cases SZ_4K and a few larger sizes are available.
In the typical configuration this does not cause problems, but in the event
that the system PAGE_SIZE is increased beyond 4k, it's no longer reasonable
to expect that the allocation will be PAGE_SIZE aligned.
Limit the DMA alignment check to the actual alignment requirements written
in the comments in the code, to avoid the UFS core refusing to initialize
with such configuration.
Link: https://lore.kernel.org/r/20230201034917.1902330-1-quic_bjorande@quicinc.com
Change-Id: Iddb462133be5473b012ef58997d6e05867c7f2cc
Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Reviewed-by: Asutosh Das <quic_asutoshd@quicinc.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 339aa12218728cad1caf6de3ff7a83771aeed164 git://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git for-next)
Signed-off-by: Bart Van Assche <bvanassche@google.com>
On SM8550, depending on the Qunipro, we can run with G5 or G4. For now,
when the major version is 5 or above, we go with G5. Therefore, we need to
specifically tell UFS HC that.
Change-Id: Ia1fc8ac41940599dd616f1777165fd3e2cf0ef29
Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 9c02aa24bf404a39ec509d9f50539056b9b128f7 git://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git for-next)
Signed-off-by: Bart Van Assche <bvanassche@google.com>
All UFS host controllers support DMA clustering. Hence enable DMA
clustering.
Notes:
- The max_segment_size parameter implements the 256 KiB limit for the
PRDT. The dma_boundary parameter represents a boundary that must not be
crossed by DMA scatter/gather lists. I'm not aware of any restrictions
on DMA scatter/gather lists in the UFSHCI specification other than the
256 KiB limit for the PRDT and the 32-bit address restriction for
controllers that only support 32-bits DMA. The latter restriction is
already handled by ufshcd_set_dma_mask().
- Without patch "scsi: ufs: exynos: Fix the maximum segment size", this
patch breaks support for the Exynos controller.
The history of the dma_boundary parameter in the UFS driver is as
follows:
* The initial UFS driver did not set the dma_boundary parameter.
* Commit 4dd4130a72 ("scsi: make sure all drivers set the use_clustering
flag") set the .use_clustering flag.
* Commit 4af14d113b ("scsi: remove the use_clustering flag") removed the
use_clustering flag and set the dma_boundary parameter instead.
Cc: Avri Altman <avri.altman@wdc.com>
Cc: Alim Akhtar <alim.akhtar@samsung.com>
Cc: Kiwoong Kim <kwmad.kim@samsung.com>
Change-Id: I7a14065dee3278b93f51e66b132dd2ffbc3020c4
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 13f87983fb91454e4a534bb41b5b2b43afe97798 git://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git for-next)
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Prepare for enabling DMA clustering and also for supporting PAGE_SIZE !=
4096 by declaring explicitly that the maximum segment size is 4096 bytes
for Exynos UFS host controllers. Add this code in
exynos_ufs_hce_enable_notify() such that it happens after scsi_host_alloc()
and before __scsi_init_queue() is called by the LUN scanning code.
Cc: Alim Akhtar <alim.akhtar@samsung.com>
Cc: Kiwoong Kim <kwmad.kim@samsung.com>
Change-Id: Idce6f25fbe5fccb964d590bbafdcf3d793c0a443
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>
Tested-by: Alim Akhtar <alim.akhtar@samsung.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 9a80bc5debf74b09f3a8bbc02cfba8d04e2048d0 git://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git for-next)
Signed-off-by: Bart Van Assche <bvanassche@google.com>
The Exynos UFS controller only supports scatter/gather list elements that
are aligned on a 4 KiB boundary. Fix DMA alignment in case PAGE_SIZE !=
4096. Rename UFSHCD_QUIRK_ALIGN_SG_WITH_PAGE_SIZE into
UFSHCD_QUIRK_4KB_DMA_ALIGNMENT.
Cc: Kiwoong Kim <kwmad.kim@samsung.com>
Fixes: 2b2bfc8aa5 ("scsi: ufs: Introduce a quirk to allow only page-aligned sg entries")
Change-Id: Ice7b3d32192e0c7f6f607ad4ca64071062fa8b17
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>
Tested-by: Alim Akhtar <alim.akhtar@samsung.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 86bd0c4a2a5dc4265884648cb92c681646509692 git://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git for-next)
Signed-off-by: Bart Van Assche <bvanassche@google.com>
This is updated by
tools/bazel run //common-modules/virtual-device:virtual_device_aarch64_abi_update_symbol_list
Test: TH
Bug: 267694690
Change-Id: I876704cc5d0aa84647f3dbf1e30c08dd5136286a
Signed-off-by: Yifan Hong <elsk@google.com>
This optimization allows us to re-create higher order block mappings in
the host stage2 pagetables after we teardown a guest VM. The coalescing
code is triggered on host_stage2_set_owner_locked path when we annotate
the entries in the host stage2 page-tables with an invalid entry that has
the owner set to PKVM_ID_HOST. This can also be triggered from
page_relinquish when we do page insertion in the ballooning code.
When the host reclaims ownership during guest teardown, the page table
walker drops the refcount of the counted entries and clears out
unreferenced entries (refcount == 1). Clearing out the entry installs a
zero PTE. When the host stage2 receives a data abort because there is no
mapping associated, it will try to create the largest possible block
mapping from the founded leaf entry.
With the current patch, we increase the chances of finding a leaf entry
that has level < 3 if the requested region comes from a reclaimed torned
down VM memory. This has the advantage of reducing the TLB pressure at
host stage2.
To be able to do coalescing, we modify the way we do refcounting by not
counting the following descriptor types at host stage 2:
- non-zero invalid PTEs
- any descriptor that has at least one of the reserved-high bits(58-55)
toogled
- non-default attribute mappings
- page table descriptors
The algorithm works as presented below:
Is refcount(child(pte_table)) == 1 ?
Yes -> (because we left only default mappings)
Zap the table by setting 0 in the pte_table
and put the page that holds the level 3 entries
back into the memcache
level 2
+---------+
| |
| ... |
| pte_table---+ level 3 -> we can now re-create a 2Mb mapping
| ... | +---> +---------+
| | | |
| | | |
| | |def entry|
+---------+ | |
|def entry|
| |
| ... |
+---------+
This (v3) is a re-work of the previous version which fixes some issues on
the stage2_unmap path:
When we register a pKVM IOMMU we unmap the MMIO region from the host
stage2. While we treat most of the MMIO regions as default mappings in
the coalescing change, we end up decrementing the page table page
refcount for a default mapping which breaks the refcounting. Fix this by
adding a check which verifies if we have a default mapping before
decrementing the reference.
Bug: 222044487
Test: dump the host stage2 pagetables and view the mapping
Change-Id: I518fcbd7f022e77965eef54dd59dac07425db3a5
Signed-off-by: Sebastian Ene <sebastianene@google.com>
Signed-off-by: Will Deacon <willdeacon@google.com>
The backport commit 77a0deb5d5 ("BACKPORT: kasan: fill in cache and
object in complete_report_info") did not resolve the conflict due to the
folio patchset missing in 5.15 correctly: complete_report_info needs to
check PageSlab to make sure that the page is a slab page.
Add a PageSlab check to complete_report_info.
Bug: 254721825
Reported-by: Peter Collingbourne <pcc@google.com>
Fixes: 77a0deb5d5 ("BACKPORT: kasan: fill in cache and object in complete_report_info")
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
Change-Id: I307ddbd9315134f825b37a0c7254a033453a46ef
There is more information available in the SCSI logging mechanism than
in the SCSI ftrace event output, e.g. ASC and ASCQ sense codes. Hence
enable the SCSI logging mechanism. For more information about this
mechanism, see also the documentation of the scsi_logging_level
parameter on https://www.kernel.org/doc/html/v6.1/scsi/scsi-parameters.html
and also
https://github.com/torvalds/linux/blob/master/drivers/scsi/scsi_logging.h.
Bug: 268210743
Test: adb shell 'echo -1 > /sys/module/scsi_mod/parameters/scsi_logging_level && dmesg -w'
Change-Id: Ia0f048c3646714c62461d54271de1822377e61d8
Signed-off-by: Bart Van Assche <bvanassche@google.com>
LTS v5.15.91 commit b03f7ed9af ("scsi: ufs: core: Fix
devfreq deadlocks") didn't apply cleanly and it led to a
probable merge conflict which broke DB845c (sdm845).
Bug: 146449535
Fixes: e3d8fe0993 (Merge 5.15.91 into android14-5.15)
Change-Id: I308d6425f49e924dad412d5b5a93dc71c1881cbf
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
This reverts commit 3ce7942d7b.
UFS G4 patchseries broke RB5 (sm8250). Reverting a minimal
set of patches to get the device booting again.
Bug: 146449535
Change-Id: I26a755402561c6ec445a514f5b59f40d7e207cef
Suggested-by: Bart Van Assche <bvanassche@google.com>
Suggested-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
This reverts commit ac7823b077.
UFS G4 patchseries broke RB5 (sm8250). Reverting a minimal
set of patches to get the device booting again.
Bug: 146449535
Change-Id: I33155982effdcedcbf836e5355fbed646236ea48
Suggested-by: Bart Van Assche <bvanassche@google.com>
Suggested-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
The HOST_PAGE_PENDING_RECLAIM and HOST_PAGE_NEED_POISONING flags are now
no longer used, remove them.
Bug: 229972313
Bug: 238945523
Change-Id: Ib88a22c486f9c5eab95f0763ff949426f883be83
Signed-off-by: Quentin Perret <qperret@google.com>
The __pkvm_teardown_vm hypercall can take a long time. According to my
measurement on Pixel 6, up to 150+ms. The vast majority of that time is
spent walking the guest stage-2 page-table to put its pages in the
'pending reclaim' state, which was introduced to allow poisoning the
pages asynchronously. Given that pKVM is fundamentally non-preemptible,
those 150+ms are not acceptable.
In order to spread the work in multiple smaller sections, let's split the
teardown procedure in two. A first hypercall will be used to place a VM
in a 'dying' state after all the required sanity checks have been done
(e.g. checking that no vCPUs are currently loaded). Once in a dying
state, the hypervisor will deny any attempt to load vCPUs and run the
VM, but accept requests to reclaim guest pages. Once all guest pages have
been reclaimed, the host can issue a second hypercall to finalize the
teardown, which will free the handle and return all pages used to store
guest metadata at EL2 back to EL1.
This was tested on Pixel 6 with android14-6.1, and concurrently running
a memory intensive benchmark on the host and a large protected guest.
The length of EL2 periods have been measured by parsing pKVM traces and
the results showed that all outliers of 200+us have been entirely
eliminated.
Bug: 229972313
Bug: 238945523
Change-Id: Iaa426a964e1f7a5e48e9365aaec4700a62b3b776
Signed-off-by: Quentin Perret <qperret@google.com>
When a guest relinquishes a page to the host (because of e.g.
balooning), it issues a hypercall where the hypervisor puts the page in
the 'pending reclaim' state. It is then the host's responsibility to
call the reclaim hypercall to trigger the page poisoning before dropping
the GUP pin.
In order to reduce dependencies on the 'pending reclaim' state which
will be reworked very soon, rework the relinquish path to poison the
pages synchronously, hence removing the need for the host to issue a
reclaim call. The page ownership is now synchronously returned to the
host on the back of the relinquish hcall.
Bug: 229972313
Bug: 238945523
Change-Id: I85fd3485308209357bcdeb855de07da227fac0fe
Signed-off-by: Quentin Perret <qperret@google.com>
This reverts commit fe0be0c1c4.
Reason for revert: Appears to be the root-cause behind b/267581040
Change-Id: I51ac488de4326d39c7e33f37764cba0b65b84caf
Signed-off-by: Will Deacon <willdeacon@google.com>
commit a23039c7306f53416ba35d230201398ea34f4640 upstream.
Some selftests depend on information provided by the CPUID instruction.
To support this dependency the selftests implement private wrappers for
CPUID.
Duplication of the CPUID wrappers should be avoided.
Both gcc and clang/LLVM provide __cpuid_count() macros but neither
the macro nor its header file are available in all the compiler
versions that need to be supported by the selftests. __cpuid_count()
as provided by gcc is available starting with gcc v4.4, so it is
not available if the latest tests need to be run in all the
environments required to support kernels v4.9 and v4.14 that
have the minimal required gcc v3.2.
Duplicate gcc's __cpuid_count() macro to provide a centrally defined
macro for __cpuid_count() to help eliminate the duplicate CPUID wrappers
while continuing to compile in older environments.
Suggested-by: Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Cc: Kyle Huey <me@kylehuey.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e89908201e2509354c40158b517945bf3d645812 upstream.
ARRAY_SIZE is defined in several selftests. Remove definitions from
individual test files and include header file for the define instead.
ARRAY_SIZE define is added in a separate patch to prepare for this
change.
Remove ARRAY_SIZE from vm tests and pickup the one defined in
kselftest.h.
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Cc: Kyle Huey <me@kylehuey.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 066b34aa5461f6072dbbecb690f4fe446b736ebf upstream.
tools/include/linux/kernel.h and kselftest_harness.h are missing
ifndef guard around ARRAY_SIZE define. Fix them to avoid duplicate
define errors during compile when another file defines it. This
problem was found when compiling selftests that include a header
with ARRAY_SIZE define.
ARRAY_SIZE is defined in several selftests. There are about 25+
duplicate defines in various selftests source and header files.
Add ARRAY_SIZE to kselftest.h in preparation for removing duplicate
ARRAY_SIZE defines from individual test files.
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Cc: Kyle Huey <me@kylehuey.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3afee2118132e93e5f6fa636dfde86201a860ab3 upstream.
This event is just specified for SCO and eSCO link types.
On the reception of a HCI_Synchronous_Connection_Complete for a BDADDR
of an existing LE connection, LE link type and a status that triggers the
second case of the packet processing a NULL pointer dereference happens,
as conn->link is NULL.
Signed-off-by: Soenke Huster <soenke.huster@eknoes.de>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Ovidiu Panait <ovidiu.panait@eng.windriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e400ad8b7e6a1b9102123c6240289a811501f7d9 upstream.
Old, circa 2002 chipsets have a bug: they don't go idle when they are
supposed to. So, a workaround was added to slow the CPU down and
ensure that the CPU waits a bit for the chipset to actually go idle.
This workaround is ancient and has been in place in some form since
the original kernel ACPI implementation.
But, this workaround is very painful on modern systems. The "inl()"
can take thousands of cycles (see Link: for some more detailed
numbers and some fun kernel archaeology).
First and foremost, modern systems should not be using this code.
Typical Intel systems have not used it in over a decade because it is
horribly inferior to MWAIT-based idle.
Despite this, people do seem to be tripping over this workaround on
AMD system today.
Limit the "dummy wait" workaround to Intel systems. Keep Modern AMD
systems from tripping over the workaround. Remotely modern Intel
systems use intel_idle instead of this code and will, in practice,
remain unaffected by the dummy wait.
Reported-by: K Prateek Nayak <kprateek.nayak@amd.com>
Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Tested-by: K Prateek Nayak <kprateek.nayak@amd.com>
Link: https://lore.kernel.org/all/20220921063638.2489-1-kprateek.nayak@amd.com/
Link: https://lkml.kernel.org/r/20220922184745.3252932-1-dave.hansen@intel.com
Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a408f33e895e455f16cf964cb5cd4979b658db7b upstream.
When online resizing is performed twice consecutively, the error message
"Superblock checksum does not match superblock" is displayed for the
second time. Here's the reproducer:
mkfs.ext4 -F /dev/sdb 100M
mount /dev/sdb /tmp/test
resize2fs /dev/sdb 5G
resize2fs /dev/sdb 6G
To solve this issue, we moved the update of the checksum after the
es->s_overhead_clusters is updated.
Fixes: 026d0d27c488 ("ext4: reduce computation of overhead during resize")
Fixes: de394a86658f ("ext4: update s_overhead_clusters in the superblock during an on-line resize")
Signed-off-by: Baokun Li <libaokun1@huawei.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Jan Kara <jack@suse.cz>
Cc: stable@kernel.org
Link: https://lore.kernel.org/r/20221117040341.1380702-2-libaokun1@huawei.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Oleksandr Tymoshenko <ovt@google.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 1417f59ac0b02130ee56c0c50794b9b257be3d17 ]
If the function sdma_load_context() fails, the sdma_desc will be
freed, but the allocated desc->bd is forgot to be freed.
We already met the sdma_load_context() failure case and the log as
below:
[ 450.699064] imx-sdma 30bd0000.dma-controller: Timeout waiting for CH0 ready
...
In this case, the desc->bd will not be freed without this change.
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Reviewed-by: Sascha Hauer <s.hauer@pengutronix.de>
Link: https://lore.kernel.org/r/20221130090800.102035-1-hui.wang@canonical.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit ccf1e1626d37745d0a697db67407beec9ae9d4b8 ]
Make sure calibration values are defined to prevent potential kernel
crashes. This fixes a hypothetical issue for virtual or clone devices
inspired by a similar fix for DS4.
Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit a3d81bc1eaef48e34dd0b9b48eefed9e02a06451 ]
The following kernel panic can be triggered when a task with pid=1 attaches
a prog that attempts to send killing signal to itself, also see [1] for more
details:
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
CPU: 3 PID: 1 Comm: systemd Not tainted 6.1.0-09652-g59fe41b5255f #148
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x100/0x178 lib/dump_stack.c:106
panic+0x2c4/0x60f kernel/panic.c:275
do_exit.cold+0x63/0xe4 kernel/exit.c:789
do_group_exit+0xd4/0x2a0 kernel/exit.c:950
get_signal+0x2460/0x2600 kernel/signal.c:2858
arch_do_signal_or_restart+0x78/0x5d0 arch/x86/kernel/signal.c:306
exit_to_user_mode_loop kernel/entry/common.c:168 [inline]
exit_to_user_mode_prepare+0x15f/0x250 kernel/entry/common.c:203
__syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline]
syscall_exit_to_user_mode+0x1d/0x50 kernel/entry/common.c:296
do_syscall_64+0x44/0xb0 arch/x86/entry/common.c:86
entry_SYSCALL_64_after_hwframe+0x63/0xcd
So skip task with pid=1 in bpf_send_signal_common() to avoid the panic.
[1] https://lore.kernel.org/bpf/20221222043507.33037-1-sunhao.th@gmail.com
Signed-off-by: Hao Sun <sunhao.th@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Stanislav Fomichev <sdf@google.com>
Link: https://lore.kernel.org/bpf/20230106084838.12690-1-sunhao.th@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit ef10d57936ead5e817ef7cea6a87531085e77773 ]
There is no "no-emmc" property, so intention for SD/SDIO only nodes was
to use "no-mmc".
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit b025b4f5c288e29bbea421613a5b4eacf9261fbb ]
"make dtbs_check":
arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dtb: pca9547@77: $nodename:0: 'pca9547@77' does not match '^(i2c-?)?mux'
From schema: Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.yaml
arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dtb: pca9547@77: Unevaluated properties are not allowed ('#address-cells', '#size-cells', 'i2c@4' were unexpected)
From schema: Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.yaml
...
Fix this by renaming PCA954x nodes to "i2c-mux", to match the I2C bus
multiplexer/switch DT bindings and the Generic Names Recommendation in
the Devicetree Specification.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 42825d1f269355d63554ab3c3762611e4d8053e9 ]
"make dtbs_check":
arch/arm/boot/dts/vf610-zii-dev-rev-b.dtb: tca9548@70: $nodename:0: 'tca9548@70' does not match '^(i2c-?)?mux'
From schema: Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.yaml
arch/arm/boot/dts/vf610-zii-dev-rev-b.dtb: tca9548@70: Unevaluated properties are not allowed ('#address-cells', '#size-cells', 'i2c@0', 'i2c@1', 'i2c@2', 'i2c@3', 'i2c@4' were unexpected)
From schema: /scratch/geert/linux/linux-renesas/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.yaml
...
Fix this by renaming PCA9548 nodes to "i2c-mux", to match the I2C bus
multiplexer/switch DT bindings and the Generic Names Recommendation in
the Devicetree Specification.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit f78985f9f58380eec37f82c8a2c765aa7670fc29 ]
"make dtbs_check":
arch/arm/boot/dts/imx53-ppd.dtb: i2c-switch@70: $nodename:0: 'i2c-switch@70' does not match '^(i2c-?)?mux'
From schema: Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.yaml
arch/arm/boot/dts/imx53-ppd.dtb: i2c-switch@70: Unevaluated properties are not allowed ('#address-cells', '#size-cells', 'i2c@0', 'i2c@1', 'i2c@2', 'i2c@3', 'i2c@4', 'i2c@5', 'i2c@6', 'i2c@7' were unexpected)
From schema: Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.yaml
Fix this by renaming the PCA9547 node to "i2c-mux", to match the I2C bus
multiplexer/switch DT bindings and the Generic Names Recommendation in
the Devicetree Specification.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Currently pKVM modules can only restrict the host stage-2 permissions of
some pages with no way of relaxing them later on. Also, modules lack the
ability to unmap pages from the host without mapping them in the
hypervisor as they only have access to the host-to-hyp-donation path.
In order to give modules more flexibility, make the
hyp_protect_host_page() function a lot more generic by allowing it to
relax permissions as well as "map" with !R!W!X.
Bug: 264070847
Change-Id: Id6751fe147ea8b86a416a1c3326a2d75f04b623d
Signed-off-by: Quentin Perret <qperret@google.com>
In order to let vendor pKVM modules change the permission of host pages,
introduce a new concept of module-owned pages. This flag is stored in
the vmemmap so it can be set for pages that have been unmapped from the
host and for which the stage-2 PTEs are invalid.
Bug: 264070847
Change-Id: Ic831d3873cf7d31a2bd9f411306d657cc2f4db01
Signed-off-by: Quentin Perret <qperret@google.com>
We will soon need to fetch part of the page state outside of invalid
PTE entries, so provide the input address to the get_page_state()
helper.
Bug: 264070847
Change-Id: I02e0c7538a15cad8e63591bfab67c6de125631fe
Signed-off-by: Quentin Perret <qperret@google.com>
scripts/gen_gki_modules_headers.sh:
Add an option to only keep unique symbols during the
symbol list prep phase as for header generation symbol
list needs to be unique union of all vendor symbol
lists in an ascending order.
This reduces the array size and improves the lookup
time for the binary search.
Bug: 232430739
Test: TH
Fixes: 0a903fe828 ("ANDROID: GKI: Header generation fix and improvements")
Change-Id: Ib6868f5a8eb0b3713e192bec111804e993e3d085
Signed-off-by: Ramji Jiyani <ramjiyani@google.com>
Add description of sysfs files
Test: none
Bug: 210958368
Change-Id: I8ddb678e0e0f1dbbcfb9455d6e17b726337d585c
Signed-off-by: Paul Lawrence <paullawrence@google.com>
This reverts commit dc855f8bdf.
Support existing users of ext4 who upgrade kernel version
Test: runs
Bug: 210958368
Change-Id: I06ad3c7870b67080dfd6d72917751b20193a4fd6
Signed-off-by: Paul Lawrence <paullawrence@google.com>
