driver inclusion
category: bugfix
bugzilla: 13683
CVE: NA

-------------------------------------------------

Orinal commit message:

Currently we only support acc controller reset in kernel. When acc
controller is resetting, users in user space indeed can not send request,
otherwise unexpected error may happen.

This patch adds two APIs for uacce: uacce_reset_prepare, uacce_reset_done.
Acc driver can call them before/after controller reset to do some uacce
related operations.

A new UACCE_ST_RST is added to indicate uacce reset state.
uacce_reset_prepare will send SIGIO to all processes which are using
uacce_queues of current uacce after setting UACCE_ST_RST. By default,
handler of SIGIO will terminate processes, which helps to release all wd
fd queue related resources. After reset done, UACCE_ST_RST can be change
back to UACCE_ST_INIT by uacce_reset_done.

Current uacce states will be as below:

             +--------------------------------------+
             v                                      |
        +-------------+         +----------------+  |
        |UACCE_ST_INIT| ------> |UACCE_ST_OPENNED|  |
        +-------------+ <-----  +----------------+  |
             ^                    |  |              |
             |     +--------------+  |              |
             |     v                 v              |
        +------------+          +--------------+    |
        |UACCE_ST_RST| <------- |UACCE_ST_START| ---+
        +------------+          +--------------+

Known issues:

1. Current state is only for uacce mode1. We need fix to make state model
right in uacce mode2

2. kernel will delay to call release callback in fops, which will lead that
release of hardware queues delay.

e.g. cat /sys/class/uacce/dev_name/attr/available_instances after reset
done, will show instances are still not available in a short time.
Signed-off-by: NZhou Wang <wangzhou1@hisilicon.com>
Reviewed-by: Nxuzaibo <xuzaibo@huawei.com>
Reviewed-by: Nfanghao <fanghao11@huawei.com>
Signed-off-by: NMingqiang Ling <lingmingqiang@huawei.com>
Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>