summaryrefslogtreecommitdiffstats
path: root/mm/memblock.c
diff options
context:
space:
mode:
authorOded Gabbay <oded.gabbay@gmail.com>2019-04-06 15:41:35 +0300
committerOded Gabbay <oded.gabbay@gmail.com>2019-04-06 15:41:35 +0300
commit3f5398cfbf051dc1850b4f64fbe5267cbd699ce0 (patch)
treeff654ad945202a88870b42a13da865d8397a36d9 /mm/memblock.c
parentcaa3c8e52582fc4d2ed82afd5e7ea164c18ef4fe (diff)
downloadlinux-3f5398cfbf051dc1850b4f64fbe5267cbd699ce0.tar.bz2
habanalabs: improve IOCTLs behavior when disabled or reset
This patch makes some improvement in how IOCTLs behave when the device is disabled or under reset. The new code checks, at the start of every IOCTL, if the device is disabled or in reset. If so, it prints an appropriate kernel message and returns -EBUSY to user-space. In addition, the code modifies the location of where the hard_reset_pending flag is being set or cleared: 1. It is now cleared immediately after the reset *tear-down* flow is finished but before the re-initialization flow begins. 2. It is being set in the remove function of the device, to make the behavior the same with the hard-reset flow There are two exceptions to the disable or in reset check: 1. The HL_INFO_DEVICE_STATUS opcode in the INFO IOCTL. This opcode allows the user to inquire about the status of the device, whether it is operational, in reset or malfunction (disabled). If the driver will block this IOCTL, the user won't be able to retrieve the status in case of malfunction or in reset. 2. The WAIT_FOR_CS IOCTL. This IOCTL allows the user to inquire about the status of a CS. We want to allow the user to continue to do so, even if we started a soft-reset process because it will allow the user to get the correct error code for each CS he submitted. Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
Diffstat (limited to 'mm/memblock.c')
0 files changed, 0 insertions, 0 deletions