On 21/05/2024 22:35, Luca Weiss wrote:
> On Dienstag, 21. Mai 2024 10:58:07 MESZ Krzysztof Kozlowski wrote:
>> On 20/05/2024 17:11, Luca Weiss wrote:
>>> Hi Krzysztof
>>>
>>> Ack, sounds good.
>>>
>>> Maybe also from you, any opinion between these two binding styles?
>>>
>>> So first using index of
Hi Bibo,
kernel test robot noticed the following build errors:
[auto build test ERROR on 3c999d1ae3c75991902a1a7dad0cb62c2a3008b4]
url:
https://github.com/intel-lab-lkp/linux/commits/Bibo-Mao/LoongArch-KVM-Add-steal-time-support-in-kvm-side/20240521-104902
base
On Tue, May 21, 2024 at 9:39 PM Steven Sistare
wrote:
>
> On 5/20/2024 10:28 PM, Jason Wang wrote:
> > On Mon, May 20, 2024 at 11:21 PM Steve Sistare
> > wrote:
> >>
> >> Flush to guarantee no workers are running when suspend returns.
> >>
> >> Fixes: f345a0143b4d ("vhost-vdpa: uAPI to suspend th
On Tue, May 21, 2024 at 9:39 PM Steven Sistare
wrote:
>
> On 5/20/2024 10:30 PM, Jason Wang wrote:
> > On Mon, May 20, 2024 at 11:21 PM Steve Sistare
> > wrote:
> >>
> >> Support the suspend operation. There is little to do, except flush to
> >> guarantee no workers are running when suspend retu
On Tue, May 21, 2024 at 9:39 PM Steven Sistare
wrote:
>
> On 5/20/2024 10:32 PM, Jason Wang wrote:
> > On Mon, May 20, 2024 at 11:21 PM Steve Sistare
> > wrote:
> >>
> >> Flush to guarantee no workers are running when suspend returns.
> >> Add a lock to enforce ordering between clearing running,
Hi Bibo,
kernel test robot noticed the following build warnings:
[auto build test WARNING on 3c999d1ae3c75991902a1a7dad0cb62c2a3008b4]
url:
https://github.com/intel-lab-lkp/linux/commits/Bibo-Mao/LoongArch-KVM-Add-steal-time-support-in-kvm-side/20240521-104902
base
On Tue, May 21, 2024 at 1:49 PM Deepak Gupta wrote:
>
> On Tue, May 21, 2024 at 12:48:16PM +0200, Jiri Olsa wrote:
> >hi,
> >as part of the effort on speeding up the uprobes [0] coming with
> >return uprobe optimization by using syscall instead of the trap
> >on the uretprobe trampoline.
>
> I und
Hi Jirka,
On Tue, May 21, 2024 at 10:24:30PM GMT, Jiri Olsa wrote:
> how about the change below?
Much better. I still have a few comments below. :-)
>
> thanks,
> jirka
>
>
> ---
> diff --git a/man/man2/uretprobe.2 b/man/man2/uretprobe.2
> new file mode 100644
> index ..959b7a47
On Tue, May 21, 2024 at 12:48:16PM +0200, Jiri Olsa wrote:
hi,
as part of the effort on speeding up the uprobes [0] coming with
return uprobe optimization by using syscall instead of the trap
on the uretprobe trampoline.
I understand this provides an optimization on x86. I believe primary reaso
On Dienstag, 21. Mai 2024 10:58:07 MESZ Krzysztof Kozlowski wrote:
> On 20/05/2024 17:11, Luca Weiss wrote:
> > Hi Krzysztof
> >
> > Ack, sounds good.
> >
> > Maybe also from you, any opinion between these two binding styles?
> >
> > So first using index of mboxes for the numbering, where for th
On Tue, May 21, 2024 at 01:48:59PM +0200, Jiri Olsa wrote:
> On Tue, May 21, 2024 at 01:36:25PM +0200, Alejandro Colomar wrote:
> > Hi Jiri,
> >
> > On Tue, May 21, 2024 at 12:48:25PM GMT, Jiri Olsa wrote:
> > > Adding man page for new uretprobe syscall.
> > >
> > > Signed-off-by: Jiri Olsa
> >
On Tue, May 21, 2024 at 11:49:42AM +0200, neil.armstr...@linaro.org wrote:
> On 21/05/2024 11:45, Dmitry Baryshkov wrote:
> > We have been pushing userspace to use mbn files by default for ages.
> > As a preparation for making the firmware-name optional, make the driver
> > use .mbn instead of .mdt
The pull request you sent on Mon, 20 May 2024 20:12:20 -0700:
> https://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux.git
> tags/rproc-v6.10
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/ab7b884a34ffda718cb93c772f575e45e8241c62
Thank you!
--
Deet-doot-d
The pull request you sent on Mon, 20 May 2024 19:58:46 -0700:
> https://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux.git
> tags/rpmsg-v6.10
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/e66128fa8e7e38ebd0b0c95578f8020aec6c0dee
Thank you!
--
Deet-doot-d
Hi Tanmay,
On Fri, May 10, 2024 at 05:51:25PM -0700, Tanmay Shah wrote:
> It is possible that remote processor is already running before
> linux boot or remoteproc platform driver probe. Implement required
> remoteproc framework ops to provide resource table address and
> connect or disconnect wit
On Tue, May 21, 2024 at 04:22:21PM +0200, Oleg Nesterov wrote:
> On 05/21, Jiri Olsa wrote:
> >
> > Currently the application with enabled shadow stack will crash
> > if it sets up return uprobe. The reason is the uretprobe kernel
> > code changes the user space task's stack, but does not update
>
On Fri, May 17, 2024 at 06:56:54PM +0200, Arnaud Pouliquen wrote:
> Add missing @ tags for some rpmsg_eptdev structure parameters.
>
> This fixes warning messages on build:
> drivers/rpmsg/rpmsg_char.c:75: warning: Function parameter or struct member
> 'remote_flow_restricted' not described in 'r
On Mon, May 20, 2024 at 01:27:24PM +0200, AngeloGioacchino Del Regno wrote:
> In scp_ipi_handler(), instead of zeroing out the entire shared
> buffer, which may be as large as 600 bytes, overwrite it with the
> received data, then zero out only the remaining bytes.
>
> Signed-off-by: AngeloGioacch
Manage interrupt coming from coprocessor also when state is
ATTACHED.
Fixes: 35bdafda40cc ("remoteproc: stm32_rproc: Add mutex protection for
workqueue")
Signed-off-by: Gwenael Treuveur
Acked-by: Arnaud Pouliquen
---
drivers/remoteproc/stm32_rproc.c | 2 +-
1 file changed, 1 insertion(+), 1 de
On Tue, 21 May 2024 09:11:08 -0600
Shuah Khan wrote:
> Any thoughts on this patch?
Sorry, this one fell through the cracks. Daniel Bristot has been
maintaining his tools and I thought this was one of his changes.
I'll take a look at it.
-- Steve
Björn Töpel writes:
> From: Björn Töpel
>
> The RISC-V port copies the PGD table from init_mm/swapper_pg_dir to
> all userland page tables, which means that if the PGD level table is
> changed, other page tables has to be updated as well.
>
> Instead of having the PGD changes ripple out to all t
On 4/3/24 19:10, Shuah Khan wrote:
Fix the following -Wformat-security compile warnings adding missing
format arguments:
latency-collector.c: In function ‘show_available’:
latency-collector.c:938:17: warning: format not a string literal and
no format arguments [-Wformat-security]
938 |
On 05/21, Jiri Olsa wrote:
>
> Currently the application with enabled shadow stack will crash
> if it sets up return uprobe. The reason is the uretprobe kernel
> code changes the user space task's stack, but does not update
> shadow stack accordingly.
>
> Adding new functions to update values on sh
On Tue, May 21, 2024 at 03:19:37PM +0200, Alexandre Ghiti wrote:
> On Tue, May 21, 2024 at 1:49 PM Björn Töpel wrote:
> > + if (PageReserved(page)) {
> > + __ClearPageReserved(page);
>
> What's the difference between __ClearPageReserved() and
> ClearPageReserved()? Because it
Alexandre Ghiti writes:
> On Tue, May 21, 2024 at 1:49 PM Björn Töpel wrote:
>>
>> From: Björn Töpel
>>
>> For an architecture to support memory hotplugging, a couple of
>> callbacks needs to be implemented:
>>
>> arch_add_memory()
>> This callback is responsible for adding the physical memo
Alexandre Ghiti writes:
> On Tue, May 21, 2024 at 1:49 PM Björn Töpel wrote:
>>
>> From: Björn Töpel
>>
>> ZONE_DEVICE pages need DEVMAP PTEs support to function
>> (ARCH_HAS_PTE_DEVMAP). Claim another RSW (reserved for software) bit
>> in the PTE for DEVMAP mark, add the corresponding helpers,
On Tue, May 21, 2024 at 1:49 PM Björn Töpel wrote:
>
> From: Björn Töpel
>
> ZONE_DEVICE pages need DEVMAP PTEs support to function
> (ARCH_HAS_PTE_DEVMAP). Claim another RSW (reserved for software) bit
> in the PTE for DEVMAP mark, add the corresponding helpers, and enable
> ARCH_HAS_PTE_DEVMAP
On 5/20/2024 10:32 PM, Jason Wang wrote:
On Mon, May 20, 2024 at 11:21 PM Steve Sistare
wrote:
Flush to guarantee no workers are running when suspend returns.
Add a lock to enforce ordering between clearing running, flushing,
and posting new work in vdpasim_kick_vq. It must be a spin lock
bec
On 5/20/2024 10:30 PM, Jason Wang wrote:
On Mon, May 20, 2024 at 11:21 PM Steve Sistare
wrote:
Support the suspend operation. There is little to do, except flush to
guarantee no workers are running when suspend returns.
Signed-off-by: Steve Sistare
---
drivers/vdpa/vdpa_user/vduse_dev.c |
On 5/20/2024 10:28 PM, Jason Wang wrote:
On Mon, May 20, 2024 at 11:21 PM Steve Sistare
wrote:
Flush to guarantee no workers are running when suspend returns.
Fixes: f345a0143b4d ("vhost-vdpa: uAPI to suspend the device")
Signed-off-by: Steve Sistare
Acked-by: Eugenio Pérez
---
drivers/vh
On Tue, May 21, 2024 at 1:49 PM Björn Töpel wrote:
>
> From: Björn Töpel
>
> Enable ARCH_ENABLE_MEMORY_HOTPLUG and ARCH_ENABLE_MEMORY_HOTREMOVE for
> RISC-V.
>
> Signed-off-by: Björn Töpel
> ---
> arch/riscv/Kconfig | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/riscv/Kconfig b
On Tue, May 21, 2024 at 1:49 PM Björn Töpel wrote:
>
> From: Björn Töpel
>
> For an architecture to support memory hotplugging, a couple of
> callbacks needs to be implemented:
>
> arch_add_memory()
> This callback is responsible for adding the physical memory into the
> direct map, and call
On Tue, 21 May 2024 at 13:20, Kalle Valo wrote:
>
> Dmitry Baryshkov writes:
>
> > On Tue, 21 May 2024 at 12:52, wrote:
> >>
> >> On 21/05/2024 11:45, Dmitry Baryshkov wrote:
> >> > Qualcomm platforms have different sets of the firmware files, which
> >> > differ from platform to platform (and f
On Tue, May 21, 2024 at 1:48 PM Björn Töpel wrote:
>
> From: Björn Töpel
>
> Prepare for memory hotplugging support by changing from __init to
> __meminit for the page table functions that are used by the upcoming
> architecture specific callbacks.
>
> Changing the __init attribute to __meminit,
The new TEE remoteproc device is used to manage remote firmware in a
secure, trusted context. The 'st,stm32mp1-m4-tee' compatibility is
introduced to delegate the loading of the firmware to the trusted
execution context. In such cases, the firmware should be signed and
adhere to the image format de
Split rproc_start()to prepare the update of the management of
the cache table on start, for the support of the firmware loading
by the TEE interface.
- create rproc_set_rsc_table_on_start() to address the management of
the cache table in a specific function, as done in
rproc_reset_rsc_table_on_
The "st,stm32mp1-m4-tee" compatible is utilized in a system configuration
where the Cortex-M4 firmware is loaded by the Trusted execution Environment
(TEE).
For instance, this compatible is used in both the Linux and OP-TEE
device-tree:
- In OP-TEE, a node is defined in the device tree with the
s
Add a remoteproc TEE (Trusted Execution Environment) driver
that will be probed by the TEE bus. If the associated Trusted
application is supported on secure part this driver offers a client
interface to load a firmware in the secure part.
This firmware could be authenticated by the secure trusted a
Main updates from the previous version [1]:
--
1) use proc->table_ptr as unique reference to point to the resource table
--> update remoteproc_core.c to implement management of the resource table
base on rproc->rproc->tee_interface new field:
- on
To prepare for the support of TEE remoteproc, create sub-functions
that can be used in both cases, with and without remoteproc TEE support.
Signed-off-by: Arnaud Pouliquen
---
drivers/remoteproc/stm32_rproc.c | 84 +++-
1 file changed, 51 insertions(+), 33 deletions(-
1) on start:
- Using the TEE loader, the resource table is loaded by an external entity.
In such case the resource table address is not find from the firmware but
provided by the TEE remoteproc framework.
Use the rproc_get_loaded_rsc_table instead of rproc_find_loaded_rsc_table
- test that rproc->c
Add the "st,proc-id" property allowing to identify the remote processor.
This ID is used to define an unique ID, common between Linux, U-boot and
OP-TEE to identify a coprocessor.
This ID will be used in request to OP-TEE remoteproc Trusted Application
to specify the remote processor.
Signed-off-b
Hi Björn,
On Tue, May 21, 2024 at 1:48 PM Björn Töpel wrote:
>
> From: Björn Töpel
>
> Make sure that the altmap parameter is properly passed on to
> vmemmap_populate_hugepages().
>
> Signed-off-by: Björn Töpel
> ---
> arch/riscv/mm/init.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-
On 5/21/24 11:24, Krzysztof Kozlowski wrote:
> On 21/05/2024 10:09, Arnaud Pouliquen wrote:
>> The "st,stm32mp1-m4-tee" compatible is utilized in a system configuration
>> where the Cortex-M4 firmware is loaded by the Trusted execution Environment
>> (TEE).
>> For instance, this compatible is use
On Wed, May 15 2024 at 12:51, Dongli Zhang wrote:
> On 5/13/24 3:46 PM, Thomas Gleixner wrote:
>> So yes, moving the invocation of irq_force_complete_move() before the
>> irq_needs_fixup() call makes sense, but it wants this to actually work
>> correctly:
>> @@ -1097,10 +1098,11 @@ void irq_force_c
From: Björn Töpel
ZONE_DEVICE pages need DEVMAP PTEs support to function
(ARCH_HAS_PTE_DEVMAP). Claim another RSW (reserved for software) bit
in the PTE for DEVMAP mark, add the corresponding helpers, and enable
ARCH_HAS_PTE_DEVMAP for riscv64.
Signed-off-by: Björn Töpel
---
arch/riscv/Kconfig
From: Björn Töpel
Now that RISC-V has memory hotplugging support, virtio-mem can be used
on the platform.
Acked-by: David Hildenbrand
Signed-off-by: Björn Töpel
---
drivers/virtio/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/virtio/Kconfig b/drivers/virt
From: Björn Töpel
Enable ARCH_ENABLE_MEMORY_HOTPLUG and ARCH_ENABLE_MEMORY_HOTREMOVE for
RISC-V.
Signed-off-by: Björn Töpel
---
arch/riscv/Kconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index fe5281398543..2724dc2af29f 100644
--- a/arch/ri
From: Björn Töpel
During memory hot remove, the ptdump functionality can end up touching
stale data. Avoid any potential crashes (or worse), by holding the
memory hotplug read-lock while traversing the page table.
This change is analogous to arm64's commit bf2b59f60ee1 ("arm64/mm:
Hold memory ho
From: Björn Töpel
For an architecture to support memory hotplugging, a couple of
callbacks needs to be implemented:
arch_add_memory()
This callback is responsible for adding the physical memory into the
direct map, and call into the memory hotplugging generic code via
__add_pages() that a
From: Björn Töpel
Add a parameter to the direct map setup function, so it can be used in
arch_add_memory() later.
Reviewed-by: Alexandre Ghiti
Reviewed-by: David Hildenbrand
Reviewed-by: Oscar Salvador
Signed-off-by: Björn Töpel
---
arch/riscv/mm/init.c | 15 ++-
1 file changed,
On Tue, May 21, 2024 at 01:36:25PM +0200, Alejandro Colomar wrote:
> Hi Jiri,
>
> On Tue, May 21, 2024 at 12:48:25PM GMT, Jiri Olsa wrote:
> > Adding man page for new uretprobe syscall.
> >
> > Signed-off-by: Jiri Olsa
> > ---
> > man2/uretprobe.2 | 50 ++
From: Björn Töpel
Prepare for memory hotplugging support by changing from __init to
__meminit for the page table functions that are used by the upcoming
architecture specific callbacks.
Changing the __init attribute to __meminit, avoids that the functions
are removed after init. The __meminit at
From: Björn Töpel
The RISC-V port copies the PGD table from init_mm/swapper_pg_dir to
all userland page tables, which means that if the PGD level table is
changed, other page tables has to be updated as well.
Instead of having the PGD changes ripple out to all tables, the
synchronization can be
From: Björn Töpel
Make sure that the altmap parameter is properly passed on to
vmemmap_populate_hugepages().
Signed-off-by: Björn Töpel
---
arch/riscv/mm/init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
index 2574f6a3b0e7..b
From: Björn Töpel
Memory Hot(Un)Plug support (and ZONE_DEVICE) for the RISC-V port
Introduction
To quote "Documentation/admin-guide/mm/memory-hotplug.rs
Hi Jiri,
On Tue, May 21, 2024 at 12:48:25PM GMT, Jiri Olsa wrote:
> Adding man page for new uretprobe syscall.
>
> Signed-off-by: Jiri Olsa
> ---
> man2/uretprobe.2 | 50
> 1 file changed, 50 insertions(+)
> create mode 100644 man2/uretprobe.2
>
Dmitry Baryshkov writes:
> On Tue, 21 May 2024 at 12:52, wrote:
>>
>> On 21/05/2024 11:45, Dmitry Baryshkov wrote:
>> > Qualcomm platforms have different sets of the firmware files, which
>> > differ from platform to platform (and from board to board, due to the
>> > embedded signatures). Rather
On 2024-05-15 23:05:36 [+0100], Qais Yousef wrote:
> rt_task() checks if a task has RT priority. But depends on your
> dictionary, this could mean it belongs to RT class, or is a 'realtime'
> task, which includes RT and DL classes.
>
> Since this has caused some confusion already on discussion [1]
Adding man page for new uretprobe syscall.
Signed-off-by: Jiri Olsa
---
man2/uretprobe.2 | 50
1 file changed, 50 insertions(+)
create mode 100644 man2/uretprobe.2
diff --git a/man2/uretprobe.2 b/man2/uretprobe.2
new file mode 100644
index 0
Adding uretprobe shadow stack test that runs all existing
uretprobe tests with shadow stack enabled if it's available.
Signed-off-by: Jiri Olsa
---
.../selftests/bpf/prog_tests/uprobe_syscall.c | 60 +++
1 file changed, 60 insertions(+)
diff --git a/tools/testing/selftests/bpf/p
Adding test to verify that when called from outside of the
trampoline provided by kernel, the uretprobe syscall will cause
calling process to receive SIGILL signal and the attached bpf
program is not executed.
Acked-by: Andrii Nakryiko
Reviewed-by: Masami Hiramatsu (Google)
Signed-off-by: Jiri O
Adding test that creates uprobe consumer on uretprobe which changes some
of the registers. Making sure the changed registers are propagated to the
user space when the ureptobe syscall trampoline is used on x86_64.
To be able to do this, adding support to bpf_testmod to create uprobe via
new attrib
Add uretprobe syscall test that compares register values before
and after the uretprobe is hit. It also compares the register
values seen from attached bpf program.
Acked-by: Andrii Nakryiko
Reviewed-by: Masami Hiramatsu (Google)
Signed-off-by: Jiri Olsa
---
tools/include/linux/compiler.h
Adding return uprobe test for shadow stack and making sure it's
working properly. Borrowed some of the code from bpf selftests.
Signed-off-by: Jiri Olsa
---
.../testing/selftests/x86/test_shadow_stack.c | 145 ++
1 file changed, 145 insertions(+)
diff --git a/tools/testing/selft
Adding uretprobe syscall instead of trap to speed up return probe.
At the moment the uretprobe setup/path is:
- install entry uprobe
- when the uprobe is hit, it overwrites probed function's return address
on stack with address of the trampoline that contains breakpoint
instruction
Wiring up uretprobe system call, which comes in following changes.
We need to do the wiring before, because the uretprobe implementation
needs the syscall number.
Note at the moment uretprobe syscall is supported only for native
64-bit process.
Reviewed-by: Oleg Nesterov
Reviewed-by: Masami Hira
Currently the application with enabled shadow stack will crash
if it sets up return uprobe. The reason is the uretprobe kernel
code changes the user space task's stack, but does not update
shadow stack accordingly.
Adding new functions to update values on shadow stack and using
them in uprobe code
hi,
as part of the effort on speeding up the uprobes [0] coming with
return uprobe optimization by using syscall instead of the trap
on the uretprobe trampoline.
The speed up depends on instruction type that uprobe is installed
and depends on specific HW type, please check patch 1 for details.
Pa
On Tue, May 21, 2024 at 01:31:53AM +, Edgecombe, Rick P wrote:
> On Mon, 2024-05-20 at 00:18 +0200, Jiri Olsa wrote:
> > anyway I think we can fix that in another way by using the optimized
> > trampoline,
> > but returning to the user space through iret when shadow stack is detected
> > (as I
On Tue, 21 May 2024 at 12:52, wrote:
>
> On 21/05/2024 11:45, Dmitry Baryshkov wrote:
> > Qualcomm platforms have different sets of the firmware files, which
> > differ from platform to platform (and from board to board, due to the
> > embedded signatures). Rather than listing all the firmware fil
On Tue, 21 May 2024 at 12:49, wrote:
>
> On 21/05/2024 11:45, Dmitry Baryshkov wrote:
> > We have been pushing userspace to use mbn files by default for ages.
> > As a preparation for making the firmware-name optional, make the driver
> > use .mbn instead of .mdt files by default.
>
> I think we s
On 21/05/2024 11:45, Dmitry Baryshkov wrote:
Qualcomm platforms have different sets of the firmware files, which
differ from platform to platform (and from board to board, due to the
embedded signatures). Rather than listing all the firmware files,
including full paths, in the DT, provide a way t
On 21/05/2024 11:45, Dmitry Baryshkov wrote:
We have been pushing userspace to use mbn files by default for ages.
As a preparation for making the firmware-name optional, make the driver
use .mbn instead of .mdt files by default.
I think we should have a mechanism to fallback to .mdt since downs
As the drivers default to loading the firmware from the board-specific
location, drop the firmware-name properties.
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/apq8096-db820c.dts | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/apq8096-db820c.dts
b/
As the drivers default to loading the firmware from the board-specific
location, drop the firmware-name properties. In case of the WCNSS
calibration data drop the path to the file, retaining just the file
name.
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/apq8016-sbc.dts | 5 +---
Make the driver use qcom_fw_helper to autodetect the path to the
calibration data file.
Signed-off-by: Dmitry Baryshkov
---
drivers/remoteproc/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 7bb22fdb64e4..e0ffcaeca03d 1006
Make the driver use qcom_fw_helper to autodetect the path to the
calibration data file.
Signed-off-by: Dmitry Baryshkov
---
drivers/remoteproc/qcom_wcnss.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/remoteproc/qcom_wcnss.c b/drivers/remoteproc/qcom_wcnss.c
index 421a3943a9
We have been pushing userspace to use mbn files by default for ages.
As a preparation for making the firmware-name optional, make the driver
use .mbn instead of .mdt files by default.
Signed-off-by: Dmitry Baryshkov
---
drivers/remoteproc/qcom_wcnss.c | 2 +-
1 file changed, 1 insertion(+), 1 de
Make the driver use qcom_fw_helper to autodetect the path to the
calibration data file.
Signed-off-by: Dmitry Baryshkov
---
drivers/remoteproc/Kconfig | 1 +
drivers/remoteproc/qcom_q6v5_pas.c | 9 +
2 files changed, 10 insertions(+)
diff --git a/drivers/remoteproc/Kconfig b/dri
We have been pushing userspace to use mbn files by default for ages.
As a preparation for making the firmware-name optional, make the driver
use .mbn instead of .mdt files by default.
Signed-off-by: Dmitry Baryshkov
---
drivers/remoteproc/qcom_q6v5_pas.c | 76 +++-
Make the driver use qcom_fw_helper to autodetect the path to the
calibration data file.
Signed-off-by: Dmitry Baryshkov
---
drivers/remoteproc/Kconfig | 1 +
drivers/remoteproc/qcom_q6v5_mss.c | 10 ++
2 files changed, 11 insertions(+)
diff --git a/drivers/remoteproc/Kconfig b/
We have been pushing userspace to use mbn files by default for ages.
As a preparation for making the firmware-name optional, make the driver
use .mbn instead of .mdt files by default.
Signed-off-by: Dmitry Baryshkov
---
drivers/remoteproc/qcom_q6v5_mss.c | 2 +-
1 file changed, 1 insertion(+), 1
Make the driver use qcom_fw_helper to autodetect the path to the
calibration data file.
Signed-off-by: Dmitry Baryshkov
---
drivers/soc/qcom/Kconfig | 1 +
drivers/soc/qcom/wcnss_ctrl.c | 9 +
2 files changed, 10 insertions(+)
diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qco
Make the driver use qcom_fw_helper to autodetect the path to the
calibration data file.
Signed-off-by: Dmitry Baryshkov
---
drivers/net/wireless/ath/wcn36xx/Kconfig | 1 +
drivers/net/wireless/ath/wcn36xx/main.c | 5 +
2 files changed, 6 insertions(+)
diff --git a/drivers/net/wireless/ath/
Qualcomm platforms have different sets of the firmware files, which
differ from platform to platform (and from board to board, due to the
embedded signatures). Rather than listing all the firmware files,
including full paths, in the DT, provide a way to determine firmware
path based on the root DT
This is a followup to the discussion during the Linaro Connect. Remove
most of the firmware-name properties from the board DT by using
root node compatible to detect firmware path.
The most obvious change is that the drivers now have to look for the
MBN firmware files by default, so this might bre
On 21/05/2024 10:09, Arnaud Pouliquen wrote:
> The "st,stm32mp1-m4-tee" compatible is utilized in a system configuration
> where the Cortex-M4 firmware is loaded by the Trusted execution Environment
> (TEE).
> For instance, this compatible is used in both the Linux and OP-TEE
> device-tree:
> - In
On 20/05/2024 17:11, Luca Weiss wrote:
> Hi Krzysztof
>
> Ack, sounds good.
>
> Maybe also from you, any opinion between these two binding styles?
>
> So first using index of mboxes for the numbering, where for the known
> usages the first element (and sometimes the 3rd - ipc-2) are empty <>.
>
Split rproc_start()to prepare the update of the management of
the cache table on start, for the support of the firmware loading
by the TEE interface.
- create rproc_set_rsc_table_on_start() to address the management of
the cache table in a specific function, as done in
rproc_reset_rsc_table_on_
To prepare for the support of TEE remoteproc, create sub-functions
that can be used in both cases, with and without remoteproc TEE support.
Signed-off-by: Arnaud Pouliquen
---
drivers/remoteproc/stm32_rproc.c | 84 +++-
1 file changed, 51 insertions(+), 33 deletions(-
Add a remoteproc TEE (Trusted Execution Environment) driver
that will be probed by the TEE bus. If the associated Trusted
application is supported on secure part this driver offers a client
interface to load a firmware in the secure part.
This firmware could be authenticated by the secure trusted a
The new TEE remoteproc device is used to manage remote firmware in a
secure, trusted context. The 'st,stm32mp1-m4-tee' compatibility is
introduced to delegate the loading of the firmware to the trusted
execution context. In such cases, the firmware should be signed and
adhere to the image format de
The "st,stm32mp1-m4-tee" compatible is utilized in a system configuration
where the Cortex-M4 firmware is loaded by the Trusted execution Environment
(TEE).
For instance, this compatible is used in both the Linux and OP-TEE
device-tree:
- In OP-TEE, a node is defined in the device tree with the
s
Main updates from the previous version [1]:
--
1) use proc->table_ptr as unique reference to point to the resource table
--> update remoteproc_core.c to implement management of the resource table
base on rproc->rproc->tee_interface new field:
- on
Add the "st,proc-id" property allowing to identify the remote processor.
This ID is used to define an unique ID, common between Linux, U-boot and
OP-TEE to identify a coprocessor.
This ID will be used in request to OP-TEE remoteproc Trusted Application
to specify the remote processor.
Signed-off-b
1) on start:
- Using the TEE loader, the resource table is loaded by an external entity.
In such case the resource table address is not find from the firmware but
provided by the TEE remoteproc framework.
Use the rproc_get_loaded_rsc_table instead of rproc_find_loaded_rsc_table
- test that rproc->c
On Tue 2024-05-21 08:34:46, Miroslav Benes wrote:
> Hello,
>
> On Mon, 20 May 2024, zhang warden wrote:
>
> >
> >
> > > On May 20, 2024, at 14:46, Miroslav Benes wrote:
> > >
> > > Hi,
> > >
> > > On Mon, 20 May 2024, Wardenjohn wrote:
> > >
> > >> Livepatch module usually used to modify ke
98 matches
Mail list logo
