CVE-2026-53204: firmware: stratix10-rsu: Fix NULL deref on rsu_send_msg() timeout in probe

In the Linux kernel, the following vulnerability has been resolved:

firmware: stratix10-rsu: Fix NULL deref on rsusendmsg() timeout in probe

rsusendmsg() can return -ETIMEDOUT when waitforcompletioninterruptibletimeout() fires while the SMC call is still pending. In stratix10rsuprobe(), the error paths for COMMANDRSUDCMFVERSION, COMMANDRSUDCMFSTATUS, COMMANDRSUMAXRETRY and COMMANDRSUGETSPTTABLE call stratix10svcfreechannel() - which sets chan->scl to NULL - but then fall through and queue the next request on the same channel. The next svc kthread that runs will dereference pdata->chan->scl in its receive callback path, triggering a NULL pointer dereference identical to the one fixed by commit c45f7263100c ("firmware: stratix10-rsu: Fix NULL pointer dereference when RSU is disabled") for the COMMANDRSUSTATUS path.

Apply the same cleanup pattern to the remaining failure paths: remove the async client, free the channel, and return early so no further messages are queued on a channel whose scl has been cleared.

While at it, clean up stratix10rsuprobe() in two ways without changing behavior:

- Drop redundant zero-initialization of fields already cleared by devmkzalloc(): client.receivecb, status. and spt0/1address (INVALIDSPTADDRESS is 0x0).

- Replace five identical 3-line error-cleanup blocks (stratix10svcremoveasyncclient() + stratix10svcfreechannel() + return ret) with goto labels (removeasyncclient, freechannel), matching the standard kernel resource-unwinding pattern and making it easier to extend the probe sequence without forgetting matching cleanup.

Also move initcompletion() next to mutexinit() so sync-primitive initialization is grouped before anything that could trigger a callback.

--- v2: Add a minor clean-up of the function stratix10rsuprobe() to have a centralize exit for all the rsusendasyncmsg() and rsusendmsg().