linux-kernel - [PATCH v3 00/14] remoteproc: Add support for synchronisaton with rproc

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: <20200424200135.28825-1-mathieu.poirier@linaro.org>
Date:   Fri, 24 Apr 2020 14:01:21 -0600
From:   Mathieu Poirier <mathieu.poirier@...aro.org>
To:     bjorn.andersson@...aro.org, ohad@...ery.com
Cc:     loic.pallardy@...com, arnaud.pouliquen@...com, s-anna@...com,
        linux-remoteproc@...r.kernel.org, corbet@....net,
        linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: [PATCH v3 00/14] remoteproc: Add support for synchronisaton with rproc

This is the third revision of this series that tries to address the
problem of synchronising with a remote processor with as much
flexibility as possible.

Two things to pay attention to:

1) Function rproc_actuate() has been abandoned to avoid creating another
   way to start a remote processor from a kernel driver.  Arnaud expressed
   the opinion that it is semantically questionnable to synchronise with a
   remote processor when calling rproc_boot().  We could rename
   rproc_boot() to rproc_actuate() but I'll wait to see what other people
   think before doing so.

2) The allocation of the synchronisation states has been split from the
   remote processor allocation.  A new function rproc_set_state_machine()
   does all the work now.  Proceeding this way has made the patchset a
   lot more simple.

Other than the above I have tried to address all the comments made on the
second revision.  If a comment was not addressed it simply fell through
the cracks rather than ignored.  In such a case please reiterate your point
of view and I'll be sure to address it.    

Applies cleanly on rproc-next (305ac5a766b1).

Best regards,
Mathieu

Mathieu Poirier (14):
  remoteproc: Make core operations optional
  remoteproc: Introduce function rproc_alloc_internals()
  remoteproc: Add new operation and flags for synchronistation
  remoteproc: Refactor function rproc_boot()
  remoteproc: Refactor function rproc_fw_boot()
  remoteproc: Refactor function rproc_trigger_auto_boot()
  remoteproc: Introducting new start and stop functions
  remoteproc: Call core functions based on synchronisation flag
  remoteproc: Deal with synchronisation when crashing
  remoteproc: Deal with synchronisation when shutting down
  remoteproc: Deal with synchronisation when changing FW image
  remoteproc: Introducing function rproc_set_state_machine()
  remoteproc: Document function rproc_set_state_machine()
  remoteproc: Expose synchronisation flags via debugfs

 Documentation/remoteproc.txt             |  17 ++
 drivers/remoteproc/remoteproc_core.c     | 197 +++++++++++++++++++----
 drivers/remoteproc/remoteproc_debugfs.c  |  21 +++
 drivers/remoteproc/remoteproc_internal.h | 123 +++++++++++++-
 drivers/remoteproc/remoteproc_sysfs.c    |  24 ++-
 include/linux/remoteproc.h               |  27 ++++
 6 files changed, 372 insertions(+), 37 deletions(-)

-- 
2.20.1