On Fri, May 22, 2026 at 10:05:55PM -0700, Nathan Chancellor wrote: > On Sat, May 23, 2026 at 05:50:14AM +0100, Yeoreum Yun wrote: > > Hi Nathan, > > > > > Hi Sudeep, > > > > > > On Fri, May 08, 2026 at 06:54:16PM +0100, Sudeep Holla wrote: > > > > Move the FF-A core bring-up and teardown paths into platform driver > > > > probe and remove callbacks, and register a synthetic arm-ffa platform > > > > device to bind the driver. > > > > > > > > This makes the FF-A core lifetime follow the driver model while keeping > > > > the device creation internal to the FF-A core. Use normal platform > > > > driver > > > > registration so the probe path has standard driver-core semantics. > > > > > > > > The synthetic platform device is a temporary bridge until ACPI and > > > > devicetree describe the FF-A core device or object. Once those firmware > > > > description paths are defined, the internal platform device creation can > > > > be dropped and the driver can bind to the firmware-described device > > > > directly. > > > > > > > > Since the transport selection now happens from the platform probe path, > > > > drop the __init annotation from ffa_transport_init(). > > > > > > > > Signed-off-by: Sudeep Holla <[email protected]> > > > > > > I am seeing > > > > > > arm-ffa arm-ffa: probe with driver arm-ffa failed with error -95 > > > > > > on my two arm64 test machines after this change landed in -next as > > > commit e659fc8e537c ("firmware: arm_ffa: Register core as a platform > > > driver"), is this expected? If so, perhaps it should be silenced? > > > > Could you share the .config file you used for this? > > Sure thing! It is attached. If you need anything else, please let me > know.
Thanks! unless there was other error log from ff-a driver, I think this happens because your environment either doesn’t support FF-A or is using an SMCCC version earlier than 1.2 from ffa_version_check() or ffa_transport_init(). If that’s the case, You can ignore this log since this behavior is expected, and the dd core should print an error log. Before this patch, the error was not shown because all FF-A initialization was done during the initcall phase, and nothing was printed even when the initcall function returned an error from caller of initcall. [...] -- Sincerely, Yeoreum Yun
