msm: rmt_storage: Add support for reboot notifier

For graceful shutdown or reboot scenarios, RMT storage
sync must be completed successfuly before device shutdown.
So register with reboot notifier to initiate the RMT
storage force sync.

CRs-Fixed: 419695
Change-Id: I6d8783d2ad2b7112fd6e84d3a9dcf033cc804a8c
Signed-off-by: Prasad Sodagudi <psodagud@codeaurora.org>
Signed-off-by: Pratibhasagar V <pratibha@codeaurora.org>
msm: rmt_storage: Do not initiate force sync in recovery mode

In recovery mode, RMT storage daemon does not exists to complete
force sync operation. To complete force sync, RMT storage daemon
and RPC channels are required. So do not initiate force sync
when daemon had not opened RMT storage device node.

CRs-Fixed: 434098
Change-Id: I2522b70fa84568c271467ae4edaa13f3dd3a3fe4
Signed-off-by: Prasad Sodagudi <psodagud@codeaurora.org>
Signed-off-by: Pratibhasagar V <pratibha@codeaurora.org>
msm: rmt_storage: Do not unregister client if there are pending requests

As seen in a corner case where the MODEM initiates an efs_sync from FS
task and waits for the response from APPS. At the same time, APPS reboot
was triggered which causes remoteFS to send force_sync request to
MODEM. Now APPS polls for sync_status from MODEM. Since an efs_sync is
ongoing, there is no more dirty-data to write and MODEM sends success
response to APPS. This causes remoteFS on APPS to proceed with
unregistering the client while the ongoing efs_sync is not completed,
causing MODEM to dog timeout on FS task.

To avoid such cases, remoteFS should wait to check for any ongoing
requests prior to unregistering.

CRs-Fixed: 435986
Change-Id: Ia12263d17099bfc928ed9ae93114050b986e69cc
Signed-off-by: Pratibhasagar V <pratibha@codeaurora.org>