Good day,
On Tue, Jun 10, 2025 at 12:27:38PM -0700, Tanmay Shah wrote:
> It's a valid use case to have only one core enabled in cluster in split
> mode. Remove exact core count expecatation from the driver.
I suggest:
"When operating in split mode, it is a valid usecase to have only one core
ena
On Mon, 9 Jun 2025 at 10:33, Arnaud POULIQUEN
wrote:
>
> Hello Mathieu,
>
> On 6/9/25 17:23, Mathieu Poirier wrote:
> > On Tue, Jun 03, 2025 at 12:08:02PM +0200, Arnaud Pouliquen wrote:
> >> Hello Bjorn and Mathieu,
> >>
> >> I am resending this
Good morning,
On Tue, Jun 03, 2025 at 12:08:04PM +0200, Arnaud Pouliquen wrote:
> Add a remoteproc TEE (Trusted Execution Environment) driver that will be
> probed by the TEE bus. If the associated Trusted application is supported
> on the secure part, this driver offers a client interface to load
On Tue, Jun 03, 2025 at 12:08:02PM +0200, Arnaud Pouliquen wrote:
> Hello Bjorn and Mathieu,
>
> I am resending this series after waiting for over two months for Bjorn's
> feedback, despite a prior reminder.
>
> Please could you coordinate between yourselves to determine who will continue
> revie
Good day,
On Fri, Jun 06, 2025 at 09:55:13AM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan
>
> i.MX95 features a Cortex-M33 core, six Cortex-A55 cores, and
> one Cortex-M7 core. The System Control Management Interface(SCMI)
> firmware runs on the M33 core. The i.MX95 SCMI firmware named System
>
Good day,
On Wed, May 21, 2025 at 10:24:03PM +0800, Wentao Liang wrote:
> In mt8195_scp_c1_irq_handler(), only the IPC interrupt bit
> (MT8192_SCP_IPC_INT_BIT) was checked., but does not handle
> when this bit is not set. This could lead to unhandled watchdog
> events. This could lead to unhandled
On Tue, May 13, 2025 at 11:14:34AM +0530, Beleswar Padhi wrote:
> This series refactors a lot of functions & callbacks from
> ti_k3_dsp_remoteproc.c, ti_k3_r5_remoteproc.c and ti_k3_m4_remoteproc.c
> drivers. This is a consolidated and final series as part of the
> refactoring of K3 remoteproc driv
On Sat, May 17, 2025 at 06:53:29PM +0530, Beleswar Prasad Padhi wrote:
>
> On 5/16/2025 9:15 PM, Mathieu Poirier wrote:
> > On Tue, May 13, 2025 at 11:14:38AM +0530, Beleswar Padhi wrote:
> > > The rproc_detach() function invokes __rproc_detach() before
> > >
On Tue, May 13, 2025 at 11:14:38AM +0530, Beleswar Padhi wrote:
> The rproc_detach() function invokes __rproc_detach() before
> rproc_unprepare_device(). The __rproc_detach() function sets the
> rproc->state to "RPROC_DETACHED".
>
> However, the TI K3 M4 driver erroneously looks for "RPROC_ATTACHE
On Fri, May 09, 2025 at 11:59:26PM +0800, Dawei Li wrote:
> Introduce new eptdev abstraction based on anon inode. The new API is
> exactly same with legacy one except:
>
> - It's anonymous and devnode/path free.
> - Its fops->open() is empty.
>
> Signed-off-by: Dawei Li
> ---
> drivers/rpmsg/rp
Hi,
On Fri, May 09, 2025 at 11:59:25PM +0800, Dawei Li wrote:
> Current uAPI implementation for rpmsg ctrl & char device manipulation is
> abstracted in procedures below:
>
> Current uAPI implementation for rpmsg ctrl & char device manipulation is
> abstracted in procedures below:
> - fd = open("
On Tue, May 13, 2025 at 04:52:46PM +0100, Bjorn Andersson wrote:
> Clearing the table_sz on cleanup seemed reasonable, but further
> discussions concluded that this merely working around the issue
> and that the fix is incomplete.
>
> As such, revert commit efdde3d73ab2 ("remoteproc: core: Clear t
On Thu, May 15, 2025 at 12:21:14PM -0500, Andrew Davis wrote:
> On 5/13/25 10:52 AM, Bjorn Andersson wrote:
> > Clearing the table_sz on cleanup seemed reasonable, but further
> > discussions concluded that this merely working around the issue
> > and that the fix is incomplete.
> >
> > As such, r
On Tue, May 06, 2025 at 09:59:44AM -0700, Tanmay Shah wrote:
> Powering off RPU using force_pwrdwn call results in system failure
> if there are multiple users of that RPU node. Better mechanism is to use
> request_node and release_node EEMI calls. With use of these EEMI calls,
> platform managemen
On Fri, Apr 25, 2025 at 04:11:00PM +0530, Beleswar Padhi wrote:
> This series refactors a lot of functions & callbacks from
> ti_k3_dsp_remoteproc.c, ti_k3_r5_remoteproc.c and ti_k3_m4_remoteproc.c
> drivers. This is a consolidated and final series as part of the
> refactoring of K3 remoteproc driv
On Fri, Apr 25, 2025 at 04:11:12PM +0530, Beleswar Padhi wrote:
> The mailbox .rx_callback implementations in TI K3 R5, DSP and M4
> remoteproc drivers handle inbound mailbox messages in the same way.
> Introduce a common driver 'ti_k3_common.c' and refactor the
> implementations into a common func
On Fri, Apr 25, 2025 at 04:11:07PM +0530, Beleswar Padhi wrote:
> The ti_k3_r5_remoteproc.c driver previously hardcoded device memory
> region addresses and names. Change this to use the k3_r5_rproc_mem_data
> structure to store memory information. This aligns with K3 DSP and M4
> drivers, and can
On Fri, Apr 25, 2025 at 04:11:10PM +0530, Beleswar Padhi wrote:
> The ti_k3_m4_remoteproc.c driver previously hardcoded device memory
> region addresses and names. Change this to use the k3_rproc_mem_data
> structure to store memory information. This aligns with DSP and R5
> drivers, and can be ref
On Fri, Apr 25, 2025 at 04:11:10PM +0530, Beleswar Padhi wrote:
> The ti_k3_m4_remoteproc.c driver previously hardcoded device memory
> region addresses and names. Change this to use the k3_rproc_mem_data
> structure to store memory information. This aligns with DSP and R5
> drivers, and can be ref
On Wed, Apr 30, 2025 at 05:20:41PM +0800, Xiaolei Wang wrote:
> In the rproc_attach() function, if rproc_handle_resources() returns
> failure, the resources requested in imx_rproc_prepare() should be
> released, since almost the same thing is done in imx_rproc_prepare() and
> rproc_resource_cleanup
On Tue, May 06, 2025 at 09:36:19AM -0300, Hiago De Franco wrote:
> Hi Peng,
>
> On Tue, May 06, 2025 at 12:38:35PM +0800, Peng Fan wrote:
> > On Mon, May 05, 2025 at 12:48:47PM -0300, Hiago De Franco wrote:
> > >From: Hiago De Franco
> > >
> > >For the i.MX8X and i.MX8 family SoCs, when the M-cor
I have started reviewing this patchset but due to its size, it will
take me several days or weeks, depending on workload and other patches
on this list. I will advise when I am done.
Thanks,
Mathieu
On Fri, 25 Apr 2025 at 04:41, Beleswar Padhi wrote:
>
> This series refactors a lot of functions
On Tue, 29 Apr 2025 at 04:46, Thorsten Blum wrote:
>
> kzalloc() already zero-initializes the destination buffer, making
> strscpy() sufficient for safely copying the name. The additional NUL-
> padding performed by strscpy_pad() is unnecessary.
>
> The size parameter is optional, and strscpy() au
On Mon, 28 Apr 2025 at 20:20, Xiaolei Wang wrote:
>
>
> On 4/26/25 14:53, Xiaolei Wang wrote:
> > When rproc->state = RPROC_DETACHED is attached to remote processor
> > through rproc_attach(), if rproc_handle_resources() returns failure,
> > then the clean table should be released, otherwise the f
Hi Xiaolei,
On Sat, Apr 26, 2025 at 02:53:47PM +0800, Xiaolei Wang wrote:
> When rproc->state = RPROC_DETACHED and rproc_attach() is used
> to attach to the remote processor, if rproc_handle_resources()
> returns a failure, the resources allocated by rproc_prepare_device()
> should be released, ot
On Sat, 26 Apr 2025 at 07:46, xiaolei wang wrote:
>
>
> On 4/26/25 21:18, Peng Fan wrote:
> > CAUTION: This email comes from a non Wind River email account!
> > Do not click links or open attachments unless you recognize the sender and
> > know the content is safe.
> >
> > On Sat, Apr 26, 2025 at
On Sat, 26 Apr 2025 at 06:41, Peng Fan wrote:
>
> On Wed, Apr 23, 2025 at 04:21:56PM -0300, Hiago De Franco wrote:
> >Hi Mathieu,
> >
> >On Wed, Apr 23, 2025 at 11:14:17AM -0600, Mathieu Poirier wrote:
> >> Good morning,
> >>
> >> On Wed, Apr
On Thu, Apr 24, 2025 at 08:22:51PM +0800, Xiaolei Wang wrote:
> Release all carveouts under imx_rproc after rproc_attach() fails to solve
> the following kmemleak:
>
Please provide more details on the steps needed to reproduce this problem and
where in rproc_attach() the original failure occured.
On Wed, 23 Apr 2025 at 13:22, Hiago De Franco wrote:
>
> Hi Mathieu,
>
> On Wed, Apr 23, 2025 at 11:14:17AM -0600, Mathieu Poirier wrote:
> > Good morning,
> >
> > On Wed, Apr 23, 2025 at 12:51:31PM -0300, Hiago De Franco wrote:
> > > From: Hiago De Franc
Arnaud, Daniel, Iuliana, Andrew and Tanmay - please test this patchset
on the platforms you are working on.
Thanks,
Mathieu
On Wed, 23 Apr 2025 at 13:42, Rob Herring (Arm) wrote:
>
> While there's a common function to parse "memory-region" properties for
> DMA pool regions, there's not anything
Good morning,
On Wed, Apr 23, 2025 at 12:51:31PM -0300, Hiago De Franco wrote:
> From: Hiago De Franco
>
> The "clocks" device tree property is not mandatory, and if not provided
> Linux will shut down the remote processor power domain during boot if it
> is not present, even if it is running (e
On Tue, 22 Apr 2025 at 12:30, Tanmay Shah wrote:
>
>
>
> On 4/22/25 12:49 PM, Mathieu Poirier wrote:
> > On Tue, 22 Apr 2025 at 10:10, Tanmay Shah wrote:
> >>
> >>
> >>
> >> On 4/22/25 10:59 AM, Mathieu Poirier wrote:
> >>>
On Tue, 22 Apr 2025 at 10:10, Tanmay Shah wrote:
>
>
>
> On 4/22/25 10:59 AM, Mathieu Poirier wrote:
> > Good morning,
> >
> > On Mon, Apr 14, 2025 at 11:46:01AM -0700, Tanmay Shah wrote:
> >> Powering off RPU using force_pwrdwn call results in system fail
Good morning,
On Mon, Apr 14, 2025 at 11:46:01AM -0700, Tanmay Shah wrote:
> Powering off RPU using force_pwrdwn call results in system failure
> if there are multiple users of that RPU node. Better mechanism is to use
> request_node and release_node EEMI calls. With use of these EEMI calls,
> pla
sc callback to handle resource table parsing and to
> process DSP-specific resource, to determine if waiting is needed.
>
> Update imx_dsp_rproc_start() to handle this condition accordingly.
>
> Signed-off-by: Iuliana Prodan
Applied.
Thanks,
Mathieu
> ---
> Changes in v5:
>
On Tue, 15 Apr 2025 at 05:04, Iuliana Prodan wrote:
>
> On 4/14/2025 6:41 PM, Mathieu Poirier wrote:
> > On Thu, Apr 10, 2025 at 12:30:30AM +0300, Iuliana Prodan (OSS) wrote:
> >> From: Iuliana Prodan
> >>
> >> Some DSP firmware requires a FW_READY signal
sc callback to handle resource table parsing and to
> process DSP-specific resource, to determine if waiting is needed.
>
> Update imx_dsp_rproc_start() to handle this condition accordingly.
>
> Signed-off-by: Iuliana Prodan
> ---
> Changes in v4:
> - Reviews from Mathieu Poiri
d, Apr 02, 2025 at 09:43:55AM +0800, Peng Fan wrote:
> >>> On Tue, Apr 01, 2025 at 10:05:03AM -0600, Mathieu Poirier wrote:
> >>> >On Tue, Apr 01, 2025 at 09:41:24AM +0800, Peng Fan wrote:
> >>...
> >>> >
> >>> >The core is already che
On Tue, 8 Apr 2025 at 02:47, Iuliana Prodan wrote:
>
> Hello Mathieu,
>
> On 4/7/2025 7:17 PM, Mathieu Poirier wrote:
> > Good morning,
> >
> > On Thu, Apr 03, 2025 at 01:01:24PM +0300, Iuliana Prodan (OSS) wrote:
> >> From: Iuliana Prodan
> >>
&
t handle_rsc callback to handle resource table parsing and to
> process DSP-specific resource, to determine if waiting is needed.
>
> Update imx_dsp_rproc_start() to handle this condition accordingly.
>
> Signed-off-by: Iuliana Prodan
> ---
> Changes in v3:
> - Reviews
On Sat, Mar 29, 2025 at 08:56:29PM +0800, Peng Fan wrote:
> On Fri, Mar 28, 2025 at 08:14:41AM -0600, Mathieu Poirier wrote:
> >On Fri, Mar 28, 2025 at 12:50:12PM +0800, Peng Fan wrote:
> >> On Thu, Mar 27, 2025 at 11:46:33AM -0600, Mathieu Poirier wrote:
> >> >H
On Wed, Apr 02, 2025 at 05:19:25PM +0800, Xiangzhi Tang wrote:
> Add host driver to control the mediatek Risc-V coprocessor
>
> 1.Support rproc mechanism to load vcm firmware from filesystem
> 2.Support SMC services to request ATF to setting vcp boot sequence
> 3.Host communicated with VCP depends
On Tue, Apr 01, 2025 at 09:41:24AM +0800, Peng Fan wrote:
> On Mon, Mar 31, 2025 at 09:40:41AM -0600, Mathieu Poirier wrote:
> >On Sat, Mar 29, 2025 at 08:56:29PM +0800, Peng Fan wrote:
> >> On Fri, Mar 28, 2025 at 08:14:41AM -0600, Mathieu Poirier wrote:
> >> >On F
On Tue, Apr 01, 2025 at 10:04:02PM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan
>
> Same as commit 47e6ab07018e ("remoteproc: imx_dsp_rproc: Add mutex
> protection for workqueue") and commit 35bdafda40cc ("remoteproc:
> stm32_rproc: Add mutex protection for workqueue"), imx_rproc driver
> also h
On Fri, Mar 28, 2025 at 12:50:12PM +0800, Peng Fan wrote:
> On Thu, Mar 27, 2025 at 11:46:33AM -0600, Mathieu Poirier wrote:
> >Hi,
> >
> >On Wed, Mar 26, 2025 at 10:02:14AM +0800, Peng Fan (OSS) wrote:
> >> From: Peng Fan
> >>
> >> There is cas
Hi,
On Wed, Mar 26, 2025 at 10:02:14AM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan
>
> There is case as below could trigger kernel dump:
> Use U-Boot to start remote processor(rproc) with resource table
> published to a fixed address by rproc. After Kernel boots up,
> stop the rproc, load a ne
Implement handle_rsc callback to handle resource table parsing and to
> process DSP-specific resource, to determine if waiting is needed.
>
> Update imx_dsp_rproc_start() to handle this condition accordingly.
>
> Signed-off-by: Iuliana Prodan
> ---
> Changes in v2:
> - R
Jiri Slaby (SUSE)
> Cc: Bjorn Andersson
> Cc: Mathieu Poirier
> Cc: linux-remotep...@vger.kernel.org
> ---
> drivers/remoteproc/pru_rproc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/remoteproc/pru_rproc.c b/drivers/remoteproc/pru_rpr
On Fri, Mar 14, 2025 at 05:17:19PM +0200, Daniel Baluta wrote:
> Add documentation for 'run_stall' imx_dsp_rproc struct member.
> This also fixes the following warning:
>
> warning: Function parameter or struct member 'run_stall'
> not described in 'imx_dsp_rproc'
>
> Fixes: 0184b4fdbad1 ("imx_ds
from IMX DSP
> remoteproc driver because there is no Device Tree users.
>
> Changes since v4:
> https://lore.kernel.org/lkml/20250305100037.373782-3-daniel.bal...@nxp.com/T/
> - picked-up R-b tags from Frank Li and Peng Fan
> - reworded commit message of patch 8/8 as p
Good day,
On Wed, Mar 05, 2025 at 12:00:36PM +0200, Daniel Baluta wrote:
> DSP on i.MX8MP doesn't have a direct reset line so according to hardware
> design team in order to handle assert/deassert/reset functionality we
> need to use a combination of control bits from two modules. Audio block
> co
atch/20250212085222.107102-6-daniel.bal...@nxp.com/
>
> Note that we can safely remove the fsl,dsp-ctrl property usage from IMX DSP
> remoteproc driver because there is no Device Tree users.
>
> Changes since v4:
> https://lore.kernel.org/lkml/20250305100037.373782-3-daniel.bal...
Good morning,
On Wed, Mar 05, 2025 at 02:39:23PM +0200, Iuliana Prodan (OSS) wrote:
> From: Iuliana Prodan
>
> Some DSP firmware requires a FW_READY signal before proceeding,
> while others do not.
> Introduce imx_dsp_rproc_wait_fw_ready() to check the resource table
> and determine if waiting i
On Mon, Feb 17, 2025 at 03:58:58PM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan
>
> Address warning: "Function parameter or struct member 'is_iomem' not
> described in 'omap_rproc_da_to_va'" with adding comment for is_iomem.
>
> Reported-by: kernel test robot
> Closes:
> https://lore.kernel.o
On Sat, Jan 11, 2025 at 07:42:48PM +0100, Krzysztof Kozlowski wrote:
> Few code simplifications without functional impact. Not tested on
> hardware.
>
> Best regards,
> Krzysztof
>
> ---
> Krzysztof Kozlowski (5):
> remoteproc: keystone: Simplify returning syscon PTR_ERR
> remoteproc
On Thu, Dec 19, 2024 at 04:35:40PM +0530, Beleswar Padhi wrote:
> This series uses various devm_ helpers to simplify device removal path in
> ti_k3_r5_remoteproc driver. This is the first series in the TI K3
> Remoteproc refactoring as long planned since [0].
>
> Testing Done:
> 1. Tested boot of
On Wed, 4 Dec 2024 at 04:11, Beleswar Padhi wrote:
>
> This series uses various devm_ helpers to simplify device removal path in
> ti_k3_r5_remoteproc driver. This is the first series in the TI K3
> Remoteproc refactoring as long planned since [0].
>
> Testing Done:
> 1. Tested boot of R5F remotep
On Wed, Dec 11, 2024 at 03:20:07PM +0800, Chen-Yu Tsai wrote:
> When multi-core SCP support was added, the driver was made to populate
> platform devices for all the sub-nodes. This ended up adding platform
> devices for the rpmsg sub-nodes as well, which never actually get used,
> since rpmsg devi
On Fri, 6 Dec 2024 at 10:05, Mathieu Poirier wrote:
>
> On Thu, 5 Dec 2024 at 11:22, Arnaud POULIQUEN
> wrote:
> >
> > Hello Mathieu,
> >
> > Thanks for the review!
> > I just need to clarify a point below before preparing the next revision.
> >
On Thu, 5 Dec 2024 at 11:22, Arnaud POULIQUEN
wrote:
>
> Hello Mathieu,
>
> Thanks for the review!
> I just need to clarify a point below before preparing the next revision.
>
> On 12/3/24 18:22, Mathieu Poirier wrote:
> > On Thu, Nov 28, 2024 at 09:42:10AM +0
Good day,
On Mon, Dec 02, 2024 at 02:28:25PM +0800, Chen-Yu Tsai wrote:
> When multi-core SCP support was added, the driver was made to populate
> platform devices for all the sub-nodes. This ended up adding platform
> devices for the rpmsg sub-nodes as well, which never actually get used,
> since
F segments into memory.
> Rename this to a more explicit name: load_segments().
This is introducing more code churn than is worth it. Please enhance the usage
comment for ->load() as part of the previous patch and drop this one.
I am done reviewing this set.
Thanks,
Mathieu
>
> Su
On Thu, Nov 28, 2024 at 09:42:12AM +0100, Arnaud Pouliquen wrote:
> The two methods to load the firmware to memory should be exclusive.
>
> - make load_segments optional returning 0 if not set in
> rproc_load_segments(),
> - ensure that load_segments() and load_fw() are not both set,
> - do not
On Thu, Nov 28, 2024 at 09:42:10AM +0100, Arnaud Pouliquen wrote:
> This patch updates the rproc_ops structures to include two new optional
> operations.
>
> - The load_fw() op is responsible for loading the remote processor
> non-ELF firmware image before starting the boot sequence. This ops will
On Thu, Nov 28, 2024 at 09:42:10AM +0100, Arnaud Pouliquen wrote:
> This patch updates the rproc_ops structures to include two new optional
> operations.
>
> - The load_fw() op is responsible for loading the remote processor
> non-ELF firmware image before starting the boot sequence. This ops will
Good morning,
On Thu, Nov 28, 2024 at 09:42:09AM +0100, Arnaud Pouliquen wrote:
> 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
On Fri, Nov 22, 2024 at 06:51:27PM +0100, Arnaud Pouliquen wrote:
> In the rproc_alloc() function, on error, put_device(&rproc->dev) is
> called, leading to the call of the rproc_type_release() function.
> An error can occurs before ida_alloc is called.
>
> In such case in rproc_type_release(), th
On Wed, 20 Nov 2024 at 09:39, Arnaud POULIQUEN
wrote:
>
>
>
> On 11/20/24 17:04, Mathieu Poirier wrote:
> > On Tue, 19 Nov 2024 at 13:38, Mathieu Poirier
> > wrote:
> >>
> >> On Tue, 19 Nov 2024 at 11:14, Arnaud POULIQUEN
> >> wrote:
>
On Tue, 19 Nov 2024 at 13:38, Mathieu Poirier
wrote:
>
> On Tue, 19 Nov 2024 at 11:14, Arnaud POULIQUEN
> wrote:
> >
> > Hello Mathieu,
> >
> > On 11/18/24 18:52, Mathieu Poirier wrote:
> > > On Mon, Nov 04, 2024 at 02:35:12PM +0100, Arnaud Poul
On Tue, 19 Nov 2024 at 11:14, Arnaud POULIQUEN
wrote:
>
> Hello Mathieu,
>
> On 11/18/24 18:52, Mathieu Poirier wrote:
> > On Mon, Nov 04, 2024 at 02:35:12PM +0100, Arnaud Pouliquen wrote:
> >> This patch updates the rproc_ops struct to include an optional
> >>
On Mon, Nov 04, 2024 at 02:35:12PM +0100, Arnaud Pouliquen wrote:
> This patch updates the rproc_ops struct to include an optional
> release_fw function.
>
> The release_fw ops is responsible for releasing the remote processor
> firmware image. The ops is called in the following cases:
>
> - An
On Mon, Nov 04, 2024 at 02:35:12PM +0100, Arnaud Pouliquen wrote:
> This patch updates the rproc_ops struct to include an optional
> release_fw function.
>
> The release_fw ops is responsible for releasing the remote processor
> firmware image. The ops is called in the following cases:
>
> - An
On Mon, Nov 04, 2024 at 02:35:10PM +0100, Arnaud Pouliquen wrote:
> 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 by the
I have applied all 3 patches in this set.
Thanks,
Mathieu
On Mon, Oct 21, 2024 at 03:45:55PM -0500, Andrew Davis wrote:
> While it should be safe to use normal memset() on these memories as they
> are mapped as Normal Non-Cached, using the memset_io() provides stronger
> guarantees on access alig
On Fri, Oct 25, 2024 at 01:40:45PM +0530, Mukesh Ojha wrote:
> On Mon, Oct 21, 2024 at 09:12:47AM -0600, Mathieu Poirier wrote:
> > Hi Mukesh,
> >
> > On Wed, Oct 16, 2024 at 10:25:46AM +0530, Mukesh Ojha wrote:
> > > Multiple call to glink_subdev_stop() for
Good day,
On Wed, Oct 23, 2024 at 12:21:11PM -0400, Laurentiu Mihalcea wrote:
> From: Laurentiu Mihalcea
>
> Add new compatible for imx95's CM7 with SOF.
>
> Signed-off-by: Laurentiu Mihalcea
> ---
> .../bindings/remoteproc/fsl,imx-rproc.yaml| 58 +--
> 1 file changed, 53
Hello Daniel,
On Fri, Oct 18, 2024 at 02:09:29PM +0300, Daniel Baluta wrote:
> Currently we generate notifyids in the linux kernel and override
> those found in rsc_table.
>
> This doesn't play well with users expecting to use the exact ids
> from rsc_table.
>
> So, use predefined notifyids foun
On Wed, Oct 09, 2024 at 10:01:08AM +0200, Arnaud Pouliquen wrote:
> The new TEE remoteproc driver 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 s
On Wed, Oct 09, 2024 at 10:01:05AM +0200, Arnaud Pouliquen wrote:
> This patch updates the rproc_ops struct to include an optional
> release_fw function.
>
> The release_fw ops is responsible for releasing the remote processor
> firmware image. The ops is called in the following cases:
>
> - An
On Wed, Oct 09, 2024 at 10:01:03AM +0200, Arnaud Pouliquen wrote:
> 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 by the
Hi Mukesh,
On Wed, Oct 16, 2024 at 10:25:46AM +0530, Mukesh Ojha wrote:
> Multiple call to glink_subdev_stop() for the same remoteproc can happen
> if rproc_stop() fails from Process-A that leaves the rproc state to
> RPROC_CRASHED state later a call to recovery_store from user space in
> Process
On Wed, Oct 16, 2024 at 11:41:39AM -0500, Andrew Davis wrote:
> Hello all,
>
> This is a follow up to [0] that adds the same for the other two K3
> RemoteProc drivers. Series is based on rproc-next branch.
>
> Thanks,
> Andrew
>
> [0] https://lore.kernel.org/lkml/20241007132441.2732215-1-a...@ke
On Wed, Oct 16, 2024 at 10:37:35AM -0500, Andrew Davis wrote:
> On 10/16/24 10:26 AM, Mathieu Poirier wrote:
> > On Mon, Oct 14, 2024 at 09:56:11AM -0500, Andrew Davis wrote:
> > > On 10/7/24 8:23 AM, Arnd Bergmann wrote:
> > > > From: Arnd Bergmann
> > >
On Mon, Oct 14, 2024 at 09:56:11AM -0500, Andrew Davis wrote:
> On 10/7/24 8:23 AM, Arnd Bergmann wrote:
> > From: Arnd Bergmann
> >
> > The k3-m4 remoteproc driver was merged with incorrect dependencies.
> > Despite multiple people trying to fix this, the version 6.12-rc2
> > remains broken and
On Tue, Oct 15, 2024 at 06:58:33PM +0200, Richard Weinberger wrote:
> Mathieu,
>
> Am Dienstag, 15. Oktober 2024, 18:48:08 CEST schrieb Mathieu Poirier:
> > Good morning Richard,
> >
> > On Fri, Oct 11, 2024 at 02:39:22PM +0200, Richard Weinberger wrote:
> > >
On Fri, Oct 11, 2024 at 03:09:08PM +0200, Krzysztof Kozlowski wrote:
> Simplify drivers in few places around probe function.
>
> Best regards,
> Krzysztof
>
> ---
> Krzysztof Kozlowski (10):
> remoteproc: da8xx: Handle deferred probe
> remoteproc: da8xx: Simplify with dev_err_probe()
Good morning Richard,
On Fri, Oct 11, 2024 at 02:39:22PM +0200, Richard Weinberger wrote:
> Texas Instruments ships a patch in their vendor kernels,
> which adds a new NS message that includes a description field.
> While TI is free to do whatever they want in their copy of the kernel,
> it become
Hi Arnd,
On Mon, Oct 07, 2024 at 01:23:57PM +, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> The k3-m4 remoteproc driver was merged with incorrect dependencies.
> Despite multiple people trying to fix this, the version 6.12-rc2
> remains broken and causes a build failure with CONFIG_TI_SCI_
>From hereon and starting with this version, I will not review patchets that
don't pass the compilation bots.
Mathieu
On Tue, Oct 08, 2024 at 07:07:40PM +0800, kernel test robot wrote:
> Hi Arnaud,
>
> kernel test robot noticed the following build warnings:
>
> [auto build test WARNING on 9852d
On Mon, Oct 07, 2024 at 01:23:57PM +, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> The k3-m4 remoteproc driver was merged with incorrect dependencies.
> Despite multiple people trying to fix this, the version 6.12-rc2
> remains broken and causes a build failure with CONFIG_TI_SCI_PROTOCOL=m
On Tue, 1 Oct 2024 at 07:35, Jason Gunthorpe wrote:
>
> On Mon, Sep 30, 2024 at 10:40:30AM -0600, Mathieu Poirier wrote:
> > On Mon, Aug 12, 2024 at 03:28:11PM +0800, Lu Baolu wrote:
> > > An iommu domain is allocated in rproc_enable_iommu() and is attached to
> > >
On Fri, Sep 27, 2024 at 02:51:38AM +, Mark-PK Tsai (蔡沛剛) wrote:
> Hi,
>
> Could someone help to review it or provide suggestions?
> Any comments are welcome.
>
> This patch is intended to allow the rproc driver to handle the
> following use-after-free issue:
>
>
> ### UAF log
What does "UA
On Tue, Sep 24, 2024 at 02:43:40PM +0200, Markus Elfring wrote:
> From: Markus Elfring
> Date: Tue, 24 Sep 2024 14:28:35 +0200
>
> An of_node_put(rmem_np) call was immediately used after a pointer check
> for a of_reserved_mem_lookup() call in three function implementations.
> Thus call such a fu
On Mon, Aug 12, 2024 at 03:28:11PM +0800, Lu Baolu wrote:
> An iommu domain is allocated in rproc_enable_iommu() and is attached to
> rproc->dev.parent in the same function.
>
> Use iommu_paging_domain_alloc() to make it explicit.
>
> Signed-off-by: Lu Baolu
> Reviewed-by: Jason Gunthorpe
> Lin
On Tue, Sep 24, 2024 at 12:52:42PM -0700, Linus Torvalds wrote:
> On Tue, 24 Sept 2024 at 12:31, Linus Torvalds
> wrote:
> >
> > It's in my tree now, but please fix asap.
>
> Argh, now that I noticed it, I can no longer unsee it.
>
> So I did this
>
> - depends on ARCH_K3 || COMPILE_TEST
On Wed, Sep 18, 2024 at 04:43:32PM +0200, Arnaud POULIQUEN wrote:
> Hello Mathieu,
>
> On 8/30/24 11:51, Arnaud Pouliquen wrote:
> > Add support for releasing remote processor firmware through
> > the Trusted Execution Environment (TEE) interface.
> >
> > The tee_rproc_release_fw() function is ca
On Tue, Sep 17, 2024 at 06:56:58PM +0200, Arnaud POULIQUEN wrote:
> Hello Mathieu,
>
> On 9/12/24 17:26, Mathieu Poirier wrote:
> > On Fri, Aug 30, 2024 at 11:51:44AM +0200, Arnaud Pouliquen wrote:
> >> Add support for releasing remote processor firmware through
&g
On Tue, 17 Sept 2024 at 03:13, Kumar, Udit wrote:
>
> Hi Mathieu,
>
> On 9/17/2024 2:07 PM, Mathieu Poirier wrote:
> > On Mon, 16 Sept 2024 at 23:20, Kumar, Udit wrote:
> >> On 9/16/2024 8:50 PM, Mathieu Poirier wrote:
> >>> On Mon, 16 Sept 2024 at 0
s
On Tue, 17 Sept 2024 at 03:40, Beleswar Prasad Padhi wrote:
>
> Hi Mathieu,
>
> On 17/09/24 14:07, Mathieu Poirier wrote:
> > On Mon, 16 Sept 2024 at 23:20, Kumar, Udit wrote:
> >> On 9/16/2024 8:50 PM, Mathieu Poirier wrote:
> >>> On Mon, 16
On Wed, 18 Sept 2024 at 09:40, Abdellatif El Khlifi
wrote:
>
> Hi Mathieu,
>
> > Introduce remoteproc support for Corstone-1000 external systems
> >
> > The Corstone-1000 IoT Reference Design Platform supports up to two
> > external systems processors. These processors can be switched on or off
>
1 - 100 of 1101 matches
Mail list logo
