linux-kernel - [PATCH 0/3] Rework TI K3 R5F remoteproc driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20241224091457.1050233-1-b-padhi@ti.com>
Date: Tue, 24 Dec 2024 14:44:54 +0530
From: Beleswar Padhi <b-padhi@...com>
To: <andersson@...nel.org>, <mathieu.poirier@...aro.org>
CC: <afd@...com>, <hnagalla@...com>, <u-kumar1@...com>, <s-vadapalli@...com>,
        <srk@...com>, <jan.kiszka@...mens.com>,
        <christophe.jaillet@...adoo.fr>, <jkangas@...hat.com>,
        <eballetbo@...hat.com>, <b-padhi@...com>,
        <linux-remoteproc@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: [PATCH 0/3] Rework TI K3 R5F remoteproc driver

This series cleans up the TI R5F remoteproc driver by addressing various bugs.
This is also the second series as part of the refactoring of K3 remoteproc
drivers[0]. The third and final series for K3 Refactoring will be posted soon
which will deal with the TI DSP and TI M4 drivers. The R5F driver takes care of
configuring dual core R5Fs in Lockstep/Split mode and therefore has worked out
separate data structures & reset logic than the DSP/M4 drivers which deal with
single core CPUs. Therefore, I wish to exclude R5F driver from the common
refactoring in the upcoming final series.

NOTE:
This series is _dependent_ upon the below series which does devm_ cleanup
https://lore.kernel.org/all/20241219110545.1898883-1-b-padhi@ti.com/

Bugs fixed in this series:
1. Fixed IPC-Only mode attach for R5F cores. PATCH #1
2. Fixed IPC-Only mode attach for DSP cores. (Included in this series, as this
was related to point 1 and fix is similar) PATCH #2
3. Fixed support to load firmware from userspace by refactoring wait mechanism
logic into prepare()/start() ops. PATCH #3

Testing Done:
1. Tested boot of R5F remoteprocs in MCU and MAIN voltage domain in both
IPC-Only mode and Kernel remoteproc mode in all Jacinto K3 devices.
2. Tested Lockstep, Split and Single-CPU Mode configuration (wherever
applicable) of R5F remoteprocs in all Jacinto K3 devices.
3. Tested shutdown of R5F remoteprocs from Linux userspace and also by
executing `modprobe -r ti_k3_r5_remoteproc`.
4. Tested usecases where firmware not available at Kernel boot time, but later
in sysfs, able to load firmware into a remotecore and start it.
5. Tested that each patch in this series generates no new warnings/errors.
Exception: Using the "wait_event_interruptible_timeout" macro in PATCH #3 raises
a -Wshadow warning, which is expected as it is called out in the implementation
of the macro itself[1].

Thanks,
Beleswar

[0]: https://lore.kernel.org/all/20241219110545.1898883-1-b-padhi@ti.com/
[1]: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/include/linux/wait.h#n289

Beleswar Padhi (3):
  remoteproc: k3-r5: Fix checks in k3_r5_rproc_{mbox_callback/kick}
  remoteproc: k3-dsp: Fix checks in k3_dsp_rproc_{mbox_callback/kick}
  remoteproc: k3-r5: Refactor sequential core power up/down operations

 drivers/remoteproc/ti_k3_dsp_remoteproc.c |  53 +++++--
 drivers/remoteproc/ti_k3_r5_remoteproc.c  | 167 +++++++++++++---------
 2 files changed, 139 insertions(+), 81 deletions(-)

-- 
2.34.1