firmware: stratix10-rsu: avoid blocking reboot_image sysfs when busy

Writes to the reboot_image sysfs attribute went through rsu_send_msg(),
which unconditionally takes priv->lock with mutex_lock(). If another RSU
operation is in flight (e.g. a DCMF status query from probe or a
concurrent sysfs read path), userspace writers get stuck in the kernel
waiting on the mutex instead of being told the device is busy.

Split rsu_send_msg() into an inner __rsu_send_msg_locked() helper that
performs the SMC transaction with the caller holding priv->lock, plus
two thin wrappers: rsu_send_msg() preserves the original blocking
behaviour for existing callers, and rsu_try_send_msg() uses
mutex_trylock() and returns -EBUSY immediately when the lock is held.

Use rsu_try_send_msg() from reboot_image_store() so the write returns
-EBUSY without blocking when an RSU operation is already running.
Userspace can retry on -EBUSY. No functional change for other sysfs
attributes.

This keeps blocking rsu_send_msg() for existing callers, add
rsu_try_send_msg() with -EBUSY only for reboot_image_store(). That
matches the original goal (avoid a second reboot_image write blocking
behind priv->lock) without changing sysfs behaviour for the other
attributes. The earlier idea of using mutex_trylock() in all of
rsu_send_msg() and returning -EAGAIN would have been harder to justify
for userspace (echo does not retry on that).

Tze Yee tested the patch on an Agilex SoC devkit.

[Test 1] Idle reboot_image write (success path)
Result:
   # insmod stratix10-rsu.ko
   # echo 0x01000000 > .../reboot_image
   # echo "exit=$?"
   exit=0
   # ./rsu_client --log
         VERSION: 0x00000202
           STATE: 0x00000000
   CURRENT IMAGE: 0x0000000001000000
      FAIL IMAGE: 0x0000000000000000
       ERROR LOC: 0x00000000
   ERROR DETAILS: 0x00000000
   RETRY COUNTER: 0x00000000
   Operation completed

[Test 2] reboot_image while priv->lock is held (-EBUSY path)
To get a deterministic busy window without flooding the service layer,
add a local debug helper (module parameter debug_hold_lock_sec +
kthread that holds priv->lock for N seconds after probe).

Result:
   # insmod stratix10-rsu.ko debug_hold_lock_sec=60
   [  121.220904] stratix10-rsu stratix10-rsu.0: TEST: RSU lock held for
60 s - try reboot_image now
   # echo 0x01000000 > .../reboot_image
   -sh: echo: write error: Device or resource busy
   # echo "during hold: exit=$?"
   during hold: exit=1
   [  183.268706] stratix10-rsu stratix10-rsu.0: TEST: RSU lock released
   # echo 0x01000000 > .../reboot_image
   # echo "after release: exit=$?"
   after release: exit=0

Together, these results match the intended behaviour: reboot_image
fails fast with -EBUSY when the RSU mutex is already held, and
succeeds once the lock is available.

Assisted-by: Claude:claude-opus-4-7
Tested-by: Tze Yee Ng <tze.yee.ng@altera.com>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>

0 files changed, 0 insertions, 0 deletions