From: Maxi Saparov <masaparov@coreweave.com>

The SPMC retains the RxTx buffer registration of the current kernel
across kexec. FFA_RXTX_MAP from the kexec'ed kernel is then denied
because the buffers of the previous kernel are still registered, and
the driver fails to probe:

  ARM FF-A: Driver version 1.2
  ARM FF-A: Firmware version 1.1 found
  ARM FF-A: failed to register FFA RxTx buffers

The notification bitmap, when one was created, is retained in the
same way and a later FFA_NOTIFICATION_BITMAP_CREATE is denied.

Add a shutdown callback that releases the notification resources and
unmaps the RxTx buffers. device_shutdown() runs on the kexec path, so
the next kernel finds the SPMC in a clean state and can register its
own buffers. On a regular reboot or power off the extra teardown is
harmless.

Observed on NVIDIA GB200 systems when kexec'ing between kernels with
the FF-A driver active.

Signed-off-by: Maxi Saparov <masaparov@coreweave.com>
---
 drivers/firmware/arm_ffa/driver.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
index 8654b3365c9b..04948be13b08 100644
--- a/drivers/firmware/arm_ffa/driver.c
+++ b/drivers/firmware/arm_ffa/driver.c
@@ -2222,9 +2222,16 @@ static void ffa_remove(struct platform_device *pdev)
 	drv_info = NULL;
 }
 
+static void ffa_shutdown(struct platform_device *pdev)
+{
+	ffa_notifications_cleanup();
+	ffa_rxtx_unmap();
+}
+
 static struct platform_driver ffa_driver = {
 	.probe = ffa_probe,
 	.remove = ffa_remove,
+	.shutdown = ffa_shutdown,
 	.driver = {
 		.name = FFA_PLATFORM_NAME,
 	},

base-commit: 3b5f4b83c4abc0c9b0a7b9e2b44e816611b7f2ec
-- 
2.55.0

Apologies, I failed to spot Carol's earlier patch for the same
problem before sending this:

  https://lore.kernel.org/all/20260818224404.3694580-1-csoto@nvidia.com/

Please disregard my patch in favor of that one. It covers more than
mine does.

Some corroborating data from our side, in case it helps that patch
along. We hit this on NVIDIA GB200 systems in production diagnostics:
after a kexec from a kernel with FF-A active, the next kernel's
FFA_RXTX_MAP is denied and the driver fails to probe until a full
system reset. I can also confirm Carol's observation that unmapping
the buffers alone is not enough. The notification bitmap is retained
by the SPMC in the same way, so the cleanup has to cover both.

Happy to provide Tested-by on the next revision of Carol's patch.

Maxi

On Wed, Aug 26, 2026 at 06:47:11PM -0400, Maxi Saparov wrote:
> Apologies, I failed to spot Carol's earlier patch for the same
> problem before sending this:
> 
>   https://lore.kernel.org/all/20260818224404.3694580-1-csoto@nvidia.com/
> 
> Please disregard my patch in favor of that one. It covers more than
> mine does.
> 
> Some corroborating data from our side, in case it helps that patch
> along. We hit this on NVIDIA GB200 systems in production diagnostics:
> after a kexec from a kernel with FF-A active, the next kernel's
> FFA_RXTX_MAP is denied and the driver fails to probe until a full
> system reset. I can also confirm Carol's observation that unmapping
> the buffers alone is not enough. The notification bitmap is retained
> by the SPMC in the same way, so the cleanup has to cover both.
> 
> Happy to provide Tested-by on the next revision of Carol's patch.
> 

I had replied to Carol with reference to [1]. I prefer that approach, see if
that helps.

-- 
Regards,
Sudeep


[1] https://lore.kernel.org/all/20260729-nostalgic-accurate-raccoon-ab7d7e@sudeepholla/