lwn.git/drivers/remoteproc/remoteproc_sysfs.c, branch docs-next

remoteproc: Make rproc_class constant

2024-03-26T17:24:38+00:00

Since commit 43a7206b0963 ("driver core: class: make class_register() take a const *"), the driver core allows for struct class to be in read-only memory, so move the rproc_class structure to be declared at build time placing it into read-only memory, instead of having to be dynamically allocated at boot time. Cc: Greg Kroah-Hartman Suggested-by: Greg Kroah-Hartman Signed-off-by: Ricardo B. Marliere Link: https://lore.kernel.org/r/20240305-class_cleanup-remoteproc2-v1-1-1b139e9828c9@marliere.net Signed-off-by: Mathieu Poirier

remoteproc: core: Move state checking to remoteproc_core

2022-04-14T17:13:33+00:00

There is no mutex protection of these state checking for 'stop' and 'detach' which can't guarantee there is no another instance is trying to do same operation. Consider two instances case: Instance1: echo stop > /sys/class/remoteproc/remoteproc0/state Instance2: echo stop > /sys/class/remoteproc/remoteproc0/state The issue is that the instance2 case may success, Or it may fail with -EINVAL, which is uncertain. So move this state checking in rproc_cdev_write() and state_store() for 'stop', 'detach' operation to 'rproc_shutdown' , 'rproc_detach' function under the mutex protection. Signed-off-by: Shengjiu Wang Link: https://lore.kernel.org/r/1648434012-16655-3-git-send-email-shengjiu.wang@nxp.com Signed-off-by: Mathieu Poirier

remoteproc: core: Remove state checking before calling rproc_boot()

2022-04-14T17:08:26+00:00

There is no mutex protection of the state checking before rproc_boot(), which can't guarantee there is no another instance is trying to do same operation. Consider two instances case: Instance1: echo start > /sys/class/remoteproc/remoteproc0/state Instance2: echo start > /sys/class/remoteproc/remoteproc0/state ... Instance2: echo stop > /sys/class/remoteproc/remoteproc0/state ... Instance1: echo stop > /sys/class/remoteproc/remoteproc0/state The one issue is that the instance2 case may success when 'start' happens at same time as instance1, then rproc->power = 2; Or it may fail with -BUSY, then rproc->power = 1; which is uncertain. The another issue is for 'stop' operation, if the rproc->power = 1, when instance2 'stop' the remoteproc the instance1 will be impacted for it still needs the service at that time. The reference counter rproc->power is used to manage state changing and there is mutex protection in each operation function for multi instance case. So remove this state checking in rproc_cdev_write() and state_store() for 'start' operation, just let reference counter rproc->power to manage the behaviors. Signed-off-by: Shengjiu Wang Link: https://lore.kernel.org/r/1648434012-16655-2-git-send-email-shengjiu.wang@nxp.com Signed-off-by: Mathieu Poirier

remoteproc: Change rproc_shutdown() to return a status

2022-03-11T20:31:55+00:00

The rproc_shutdown() function is currently not returning any error code, and any failures within rproc_stop() are not passed back to the users. Change the signature to return a success value back to the callers. The remoteproc sysfs and cdev interfaces are also updated to return back this status to userspace. Signed-off-by: Suman Anna Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220213201246.25952-2-s-anna@ti.com

remoteproc: Introduce sysfs_read_only flag

2022-03-04T16:28:25+00:00

The remoteproc framework provides sysfs interfaces for changing the firmware name and for starting/stopping a remote processor through the sysfs files 'state' and 'firmware'. The 'coredump' file is used to set the coredump configuration. The 'recovery' sysfs file can also be used similarly to control the error recovery state machine of a remoteproc. These interfaces are currently allowed irrespective of how the remoteprocs were booted (like remoteproc self auto-boot, remoteproc client-driven boot etc). These interfaces can adversely affect a remoteproc and its clients especially when a remoteproc is being controlled by a remoteproc client driver(s). Also, not all remoteproc drivers may want to support the sysfs interfaces by default. Add support to make the remoteproc sysfs files read only by introducing a state flag 'sysfs_read_only' that the individual remoteproc drivers can set based on their usage needs. The default behavior is to allow the sysfs operations as before. Implement attribute_group->is_visible() to make the sysfs entries read only when 'sysfs_read_only' flag is set. Signed-off-by: Puranjay Mohan Link: https://lore.kernel.org/r/20220216081224.9956-2-p-mohan@ti.com Signed-off-by: Mathieu Poirier

remoteproc: Properly deal with a detach request when attached

2021-03-18T13:02:10+00:00

This patch introduces the capability to detach a remote processor that has been attached to by the remoteproc core. For that to happen a rproc::ops::detach() operation needs to be available. Signed-off-by: Mathieu Poirier Reviewed-by: Arnaud Pouliquen Link: https://lore.kernel.org/r/20210312162453.1234145-17-mathieu.poirier@linaro.org Signed-off-by: Bjorn Andersson

remoteproc: Properly deal with a stop request when attached

2021-03-18T13:02:09+00:00

Allow a remote processor that was started by another entity to be switched off by the remoteproc core. For that to happen a rproc::ops::stop() operation needs to be available. Signed-off-by: Mathieu Poirier Reviewed-by: Arnaud Pouliquen Link: https://lore.kernel.org/r/20210312162453.1234145-16-mathieu.poirier@linaro.org Signed-off-by: Bjorn Andersson

remoteproc: Properly deal with a start request when attached

2021-03-18T13:02:09+00:00

This patch takes into account scenarios where a remote processor has been attached to when receiving a "start" command from sysfs. As with the case with the running state, the command can't be carried out if the remote processor is already in operation. Signed-off-by: Mathieu Poirier Reviewed-by: Arnaud Pouliquen Link: https://lore.kernel.org/r/20210312162453.1234145-15-mathieu.poirier@linaro.org Signed-off-by: Bjorn Andersson

remoteproc: Properly represent the attached state

2021-03-18T12:54:52+00:00

There is a need to know when a remote processor has been attached to rather than booted by the remoteproc core. In order to avoid manipulating two variables, i.e rproc::autonomous and rproc::state, get rid of the former and simply use the newly introduced RPROC_ATTACHED state. Signed-off-by: Mathieu Poirier Reviewed-by: Peng Fan Reviewed-by: Arnaud Pouliquen Link: https://lore.kernel.org/r/20210312162453.1234145-5-mathieu.poirier@linaro.org Signed-off-by: Bjorn Andersson

remoteproc: Add new RPROC_ATTACHED state

2021-03-18T12:54:52+00:00

Add a new RPROC_ATTACHED state to take into account scenarios where the remoteproc core needs to attach to a remote processor that is booted by another entity. Signed-off-by: Mathieu Poirier Reviewed-by: Peng Fan Reviewed-by: Arnaud Pouliquen Link: https://lore.kernel.org/r/20210312162453.1234145-4-mathieu.poirier@linaro.org Signed-off-by: Bjorn Andersson