This converts some of the visually simpler cases that have been split
over multiple lines. I only did the ones that are easy to verify the
resulting diff by having just that final GFP_KERNEL argument on the next
line.
Somebody should probably do a proper coccinelle script for this, but for
me the trivial script actually resulted in an assertion failure in the
middle of the script. I probably had made it a bit _too_ trivial.
So after fighting that far a while I decided to just do some of the
syntactically simpler cases with variations of the previous 'sed'
scripts.
The more syntactically complex multi-line cases would mostly really want
whitespace cleanup anyway.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This was done entirely with mindless brute force, using
git grep -l '\<k[vmz]*alloc_objs*(.*, GFP_KERNEL)' |
xargs sed -i 's/\(alloc_objs*(.*\), GFP_KERNEL)/\1)/'
to convert the new alloc_obj() users that had a simple GFP_KERNEL
argument to just drop that argument.
Note that due to the extreme simplicity of the scripting, any slightly
more complex cases spread over multiple lines would not be triggered:
they definitely exist, but this covers the vast bulk of the cases, and
the resulting diff is also then easier to check automatically.
For the same reason the 'flex' versions will be done as a separate
conversion.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This is the result of running the Coccinelle script from
scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to
avoid scalar types (which need careful case-by-case checking), and
instead replace kmalloc-family calls that allocate struct or union
object instances:
Single allocations: kmalloc(sizeof(TYPE), ...)
are replaced with: kmalloc_obj(TYPE, ...)
Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...)
are replaced with: kmalloc_objs(TYPE, COUNT, ...)
Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...)
are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...)
(where TYPE may also be *VAR)
The resulting allocations no longer return "void *", instead returning
"TYPE *".
Signed-off-by: Kees Cook <kees@kernel.org>
Pull SoC devicetree updates from Arnd Bergmann:
"There are a handful of new SoCs this time, all of these are more or
less related to chips in a wider family:
- SpacemiT Key Stone K3 is an 8-core risc-v chip, and the first
widely available RVA23 implementation. Note that this is entirely
unrelated with the similarly named Texas Instruments K3 chip family
that follwed the TI Keystone2 SoC.
- The Realtek Kent family of SoCs contains three chip models
rtd1501s, rtd1861b and rtd1920s, and is related to their earlier
Set-top-box and NAS products such as rtd1619, but is built on newer
Arm Cortex-A78 cores.
- The Qualcomm Milos family includes the Snapdragon 7s Gen 3 (SM7635)
mobile phone SoC built around Armv9 Kryo cores of the Arm
Cortex-A720 generation. This one is used in the Fairphone Gen 6
- Qualcomm Kaanapali is a new SoC based around eight high performance
Oryon CPU cores
- NXP i.MX8QP and i.MX952 are both feature reduced versions of chips
we already support, i.e. the i.MX8QM and i.MX952, with fewer CPU
cores and I/O interfaces.
As part of a cleanup, a number of SoC specific devicetree files got
removed because they did not have a single board using the .dtsi files
and they were never compile tested as a result: Samsung s3c6400, ST
spear320s, ST stm32mp21xc/stm32mp23xc/stm32mp25xc, Renesas
r8a779m0/r8a779m2/r8a779m4/r8a779m6/r8a779m7/r8a779m8/r8a779mb/
r9a07g044c1/r9a07g044l1/r9a07g054l1/r9a09g047e37, and TI
am3703/am3715. All of these could be restored easily if a new board
gets merged.
Broadcom/Cavium/Marvell ThunderX2 gets removed along with its only
machine, as all remaining users are assumed to be using ACPI based
firmware.
A relatively small number of 43 boards get added this time, and almost
all of them for arm64. Aside from the reference boards for the newly
added SoCs, this includes:
- Three server boards use 32-bit ASpeed BMCs
- One more reference board for 32-bit Microchip LAN9668
- 64-bit Arm single-board computers based on Amlogic s905y4, CIX
sky1, NXP ls1028a/imx8mn/imx8mp/imx91/imx93/imx95, Qualcomm
qcs6490/qrb2210 and Rockchip rk3568/rk3588s
- Carrier board for SOMs using Intel agilex5, Marvell Armada 7020,
NXP iMX8QP, Mediatek mt8370/mt8390 and rockchip rk3588
- Two mobile phones using Snapdragon 845
- A gaming device and a NAS box, both based on Rockchips rk356x
On top of the newly added boards and SoCs, there is a lot of
background activity going into cleanups, in particular towards getting
a warning-free dtc build, and the usual work on adding support for
more hardware on the previously added machines"
* tag 'soc-dt-7.0' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (757 commits)
dt-bindings: intel: Add Agilex eMMC support
arm64: dts: socfpga: agilex: add emmc support
arm64: dts: intel: agilex5: Add simple-bus node on top of dma controller node
ARM: dts: socfpga: fix dtbs_check warning for fpga-region
ARM: dts: socfpga: add #address-cells and #size-cells for sram node
dt-bindings: altera: document syscon as fallback for sys-mgr
arm64: dts: altera: Use lowercase hex
dt-bindings: arm: altera: combine Intel's SoCFPGA into altera.yaml
arm64: dts: socfpga: agilex5: Add IOMMUS property for ethernet nodes
arm64: dts: socfpga: agilex5: add support for modular board
dt-bindings: intel: Add Agilex5 SoCFPGA modular board
arm64: dts: socfpga: agilex5: Add dma-coherent property
arm64: dts: realtek: Add Kent SoC and EVB device trees
dt-bindings: arm: realtek: Add Kent Soc family compatibles
ARM: dts: samsung: Drop s3c6400.dtsi
ARM: dts: nuvoton: Minor whitespace cleanup
MAINTAINERS: Add Falcon DB
arm64: dts: a7k: add COM Express boards
ARM: dts: microchip: Drop usb_a9g20-dab-mmx.dtsi
arm64: dts: rockchip: Fix rk3588 PCIe range mappings
...
Merge the support for loading and managing the TrustZone-based remote
processors found in the Glymur platform through a topic branch, as it's
a mix of qcom-soc and remoteproc patches.
Qualcomm remote processor may rely on Static and Dynamic resources for
it to be functional. Static resources are fixed like for example,
memory-mapped addresses required by the subsystem and dynamic
resources, such as shared memory in DDR etc., are determined at
runtime during the boot process.
For most of the Qualcomm SoCs, when run with Gunyah or older QHEE
hypervisor, all the resources whether it is static or dynamic, is
managed by the hypervisor. Dynamic resources if it is present for a
remote processor will always be coming from secure world via SMC call
while static resources may be present in remote processor firmware
binary or it may be coming qcom_scm_pas_get_rsc_table() SMC call along
with dynamic resources.
Some of the remote processor drivers, such as video, GPU, IPA, etc., do
not check whether resources are present in their remote processor
firmware binary. In such cases, the caller of this function should set
input_rt and input_rt_size as NULL and zero respectively. Remoteproc
framework has method to check whether firmware binary contain resources
or not and they should be pass resource table pointer to input_rt and
resource table size to input_rt_size and this will be forwarded to
TrustZone for authentication. TrustZone will then append the dynamic
resources and return the complete resource table in the passed output
buffer.
More about documentation on resource table format can be found in
include/linux/remoteproc.h
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260105-kvmrprocv10-v10-11-022e96815380@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
On SoCs running with a non-Gunyah-based hypervisor, Linux must take
responsibility for creating the SHM bridge both for metadata (before
calling qcom_scm_pas_init_image()) and for remoteproc memory (before
calling qcom_scm_pas_auth_and_reset()). We have taken care the things
required for qcom_scm_pas_auth_and_reset(). Lets put these awareness
of above conditions into qcom_scm_pas_init_image() and
qcom_scm_pas_metadata_release().
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260105-kvmrprocv10-v10-10-022e96815380@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
For memory passed to TrustZone (TZ), it must either be part of a pool
registered with TZ or explicitly registered via SHMbridge SMC calls.
When Gunyah hypervisor is present, PAS SMC calls from Linux running at
EL1 are trapped by Gunyah running @ EL2, which handles SHMbridge
creation for both metadata and remoteproc carveout memory before
invoking the calls to TZ.
On SoCs running with a non-Gunyah-based hypervisor, Linux must take
responsibility for creating the SHM bridge before invoking PAS SMC
calls. For the auth_and_reset() call, the remoteproc carveout memory
must first be registered with TZ via a SHMbridge SMC call and once
authentication and reset are complete, the SHMbridge memory can be
deregistered.
Introduce qcom_scm_pas_prepare_and_auth_reset(), which sets up the SHM
bridge over the remoteproc carveout memory when Linux operates at EL2.
This behavior is indicated by a new field added to the PAS context data
structure. The function then invokes the auth_and_reset SMC call.
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260105-kvmrprocv10-v10-8-022e96815380@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
As a superset of the existing metadata context, the PAS context
structure enables both remoteproc and non-remoteproc subsystems to
better support scenarios where the SoC runs with or without the Gunyah
hypervisor. To reflect this, relevant SCM and metadata functions are
updated to incorporate PAS context awareness and remove metadata context
data structure completely.
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260105-kvmrprocv10-v10-5-022e96815380@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
When the Peripheral Authentication Service (PAS) method runs on a SoC
where Linux operates at EL2 (i.e., without the Gunyah hypervisor), the
reset sequences are handled by TrustZone. In such cases, Linux must
perform additional steps before invoking PAS SMC calls, such as creating
a SHM bridge. Therefore, PAS SMC calls require awareness and handling of
these additional steps when Linux runs at EL2.
To support this, there is a need for a data structure that can be
initialized prior to invoking any SMC or MDT functions. This structure
allows those functions to determine whether they are operating in the
presence or absence of the Gunyah hypervisor and behave accordingly.
Currently, remoteproc and non-remoteproc subsystems use different
variants of the MDT loader helper API, primarily due to differences in
metadata context handling. Remoteproc subsystems retain the metadata
context until authentication and reset are completed, while
non-remoteproc subsystems (e.g., video, graphics, IPA, etc.) do not
retain the metadata context and can free it within the
qcom_scm_pas_init() call by passing a NULL context parameter and due to
these differences, it is not possible to extend metadata context
handling to support remoteproc and non remoteproc subsystem use PAS
operations, when Linux operates at EL2.
Add PAS context data structure allocator helper function.
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260105-kvmrprocv10-v10-4-022e96815380@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
When the kernel issues an SMC (Secure Monitor Call) and the firmware
requests the kernel to wait, the waiting thread enters an
uninterruptible (D) state. In case of an extended wait request by the
firmware, any device suspend request, cannot proceed because of the
thread stuck in D state. This blocks the device suspend.
Replace wait_for_completion() with wait_for_completion_state(...,
TASK_IDLE), so that the waiting thread, show up in TASK_IDLE state,
instead of TASK_UNINTERRUPTIBLE (D state). This allows the thread to
block until completion, without blocking the device suspend.
Reviewed-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Reviewed-by: Bartosz Golaszewski <brgl@kernel.org>
Signed-off-by: Unnathi Chalicheemala <unnathi.chalicheemala@oss.qualcomm.com>
Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Link: https://lore.kernel.org/r/20251217-multi_waitq_scm-v11-3-f21e50e792b8@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
