]> git.ipfire.org Git - thirdparty/kernel/linux.git/commit
firmware: arm_ffa: Correct 32-bit response handling in NOTIFICATION_INFO_GET
authorSudeep Holla <sudeep.holla@arm.com>
Thu, 18 Dec 2025 14:20:01 +0000 (14:20 +0000)
committerSudeep Holla <sudeep.holla@arm.com>
Thu, 18 Dec 2025 14:22:07 +0000 (14:22 +0000)
commitbe4d4543f78074fbebd530ba5109d39a2a34e668
treedffcc26b27d4d7fe2d0af9918a5d8705d542a978
parentf183b1dda4fc0348c4016f6289588d5853ab7936
firmware: arm_ffa: Correct 32-bit response handling in NOTIFICATION_INFO_GET

The FF-A specification allows NOTIFICATION_INFO_GET to return either a
64-bit (FFA_FN64_SUCCESS) or a 32-bit (FFA_SUCCESS) response, depending on
whether the firmware chooses the SMC64 or SMC32 calling convention.

The driver previously detected the response format by checking ret.a0, but
still interpreted the returned ID lists (x3..x17 or w3..w7) as if they always
followed the 64-bit SMC64 layout. In the SMC32 case, the upper 32 bits of
each argument register are undefined by the calling convention, meaning the
driver could read stale or garbage values when parsing notification IDs.

This resulted in incorrectly decoded partition/VCPU IDs whenever the FF-A
firmware used an SMC32 return path.

Fix the issue by:

- Introducing logic to map list indices to the correct u16 offsets,
  depending on whether the response width matches the kernel word size
  or is a 32-bit response on a 64-bit kernel.
- Ensuring that the packed ID list is parsed using the proper layout,
  avoiding reads from undefined upper halves in the SMC32 case.

With this change, NOTIFICATION_INFO_GET now correctly interprets ID list
entries regardless of the response width, aligning the driver with the FF-A
specification.

Fixes: 3522be48d82b ("firmware: arm_ffa: Implement the NOTIFICATION_INFO_GET interface")
Reported-by: Sourav Mohapatra <sourav.mohapatra@arm.com>
Message-Id: <20251218142001.2457111-1-sudeep.holla@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
drivers/firmware/arm_ffa/driver.c