To generate the boot_aggregate log in the IMA subsystem with TPM PCR values,
the TPM driver must be built as built-in and
must be probed before the IMA subsystem is initialized.

However, when the TPM device operates over the FF-A protocol using the CRB interface,
probing fails and returns -EPROBE_DEFER if
the tpm_crb_ffa device — an FF-A device that provides the communication
interface to the tpm_crb driver — has not yet been probed.

To ensure the TPM device operating over the FF-A protocol with
the CRB interface is probed before IMA initialization,
the following conditions must be met:

   1. The corresponding ffa_device must be registered,
      which is done via ffa_init().

   2. The tpm_crb_driver must successfully probe this device via
      tpm_crb_ffa_init().

   3. The tpm_crb driver using CRB over FF-A can then
      be probed successfully. (See crb_acpi_add() and
      tpm_crb_ffa_init() for reference.)

Unfortunately, ffa_init(), tpm_crb_ffa_init(), and crb_acpi_driver_init() are
all registered with device_initcall, which means crb_acpi_driver_init() may
be invoked before ffa_init() and tpm_crb_ffa_init() are completed.

When this occurs, probing the TPM device is deferred.
However, the deferred probe may happen after
the IMA subsystem has already been initialized,
since IMA initialization is performed during late_initcall,
and deferred probing is handled asynchronously via a workqueue.

This patch addresses the issue by ensuring timely probing of
the tpm_crb_ffa device during TPM initialization:

  Patch #1: Change the initcall level of ffa_init() to rootfs_initcall,
            so that the FF-A device is created before any FF-A drivers are loaded.

  Patch #2: When built as built-in, call ffa_register() within tpm_crb_ffa_init()
            to ensure the Secure Partition used by tpm_crb_ffa is already registered
            before the TPM device is probed.

==============
Patch History
==============
  Since v3:
     - remove BUG_ON.
     - https://lore.kernel.org/all/20250611112448.17751-1-yeoreum.yun@arm.com/

  Since v2:
     - rewrite cover letter and commit message:
     - https://lore.kernel.org/all/aEgwpXXftXW6JNRy@e129823.arm.com/

  Since v1:
     - rewrite commit message.
     - https://lore.kernel.org/all/20250606105754.1202649-1-yeoreum.yun@arm.com/

Yeoreum Yun (2):
  firmware: arm_ffa: Change initcall level of ffa_init() to
    rootfs_initcall
  tpm: tpm_crb_ffa: try to probe tpm_crb_ffa when it's built-in

 drivers/char/tpm/tpm_crb_ffa.c    | 19 ++++++++++++++++---
 drivers/firmware/arm_ffa/driver.c |  2 +-
 2 files changed, 17 insertions(+), 4 deletions(-)

--
LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}

On Wed, Jun 18, 2025 at 11:23:00AM +0100, Yeoreum Yun wrote:
> To ensure the TPM device operating over the FF-A protocol with
> the CRB interface is probed before IMA initialization,
> the following conditions must be met:
> 
>    1. The corresponding ffa_device must be registered,
>       which is done via ffa_init().
> 
>    2. The tpm_crb_driver must successfully probe this device via
>       tpm_crb_ffa_init().
> 
>    3. The tpm_crb driver using CRB over FF-A can then
>       be probed successfully. (See crb_acpi_add() and
>       tpm_crb_ffa_init() for reference.)
> 
> Unfortunately, ffa_init(), tpm_crb_ffa_init(), and crb_acpi_driver_init() are
> all registered with device_initcall, which means crb_acpi_driver_init() may
> be invoked before ffa_init() and tpm_crb_ffa_init() are completed.

I get the ffa_init() part i.e, moving it earlier. However for
tpm_crb_ffa_init() and crb_acpi_driver_init(), modules.dep
takes care that they are loaded in order.

For IMA you will need the driver as built-in but that should
be handled via kernel config, not via code changes.

BR, Jarkko

Hi Jarkko,

> On Wed, Jun 18, 2025 at 11:23:00AM +0100, Yeoreum Yun wrote:
> > To ensure the TPM device operating over the FF-A protocol with
> > the CRB interface is probed before IMA initialization,
> > the following conditions must be met:
> >
> >    1. The corresponding ffa_device must be registered,
> >       which is done via ffa_init().
> >
> >    2. The tpm_crb_driver must successfully probe this device via
> >       tpm_crb_ffa_init().
> >
> >    3. The tpm_crb driver using CRB over FF-A can then
> >       be probed successfully. (See crb_acpi_add() and
> >       tpm_crb_ffa_init() for reference.)
> >
> > Unfortunately, ffa_init(), tpm_crb_ffa_init(), and crb_acpi_driver_init() are
> > all registered with device_initcall, which means crb_acpi_driver_init() may
> > be invoked before ffa_init() and tpm_crb_ffa_init() are completed.
>
> I get the ffa_init() part i.e, moving it earlier. However for
> tpm_crb_ffa_init() and crb_acpi_driver_init(), modules.dep
> takes care that they are loaded in order.
> For IMA you will need the driver as built-in but that should
> be handled via kernel config, not via code changes.

In the case of "module" built, it's true.
However what I tell here is when "tpm_crb" and "tpm_crb_ffa" is built
as "built-in" in this case, it couldn't make a "dependency" between
the same initcall level: here is the case of this.

0000000000000888 l       .initcall6.init>-------0000000000000000 crb_acpi_driver_init
000000000000088c l       .initcall6.init>-------0000000000000000 tpm_crb_ffa_driver_init

in this case, wihtout code change, the crb_acpi_driver_init()
is failed since tpm_crb_ffa_driver_init() is called later.

and this couldn't be solved with kconfig --
ARM_FFA_TRANSPORT=y && CONFIG_TCG_CRB=y && CONFIG_TCG_CRB_FFA=y.

The Patch #2 is to proing the tpm_crb_ffa as part of
crb_acpi_driver_init() when TPM uses method ARM-FFA.

If there's another suggestion, let me know please.

Thanks

--
Sincerely,
Yeoreum Yun

On Wed, Jun 25, 2025 at 11:36:19AM +0100, Yeoreum Yun wrote:
> Hi Jarkko,
> 
> > On Wed, Jun 18, 2025 at 11:23:00AM +0100, Yeoreum Yun wrote:
> > > To ensure the TPM device operating over the FF-A protocol with
> > > the CRB interface is probed before IMA initialization,
> > > the following conditions must be met:
> > >
> > >    1. The corresponding ffa_device must be registered,
> > >       which is done via ffa_init().
> > >
> > >    2. The tpm_crb_driver must successfully probe this device via
> > >       tpm_crb_ffa_init().
> > >
> > >    3. The tpm_crb driver using CRB over FF-A can then
> > >       be probed successfully. (See crb_acpi_add() and
> > >       tpm_crb_ffa_init() for reference.)
> > >
> > > Unfortunately, ffa_init(), tpm_crb_ffa_init(), and crb_acpi_driver_init() are
> > > all registered with device_initcall, which means crb_acpi_driver_init() may
> > > be invoked before ffa_init() and tpm_crb_ffa_init() are completed.
> >
> > I get the ffa_init() part i.e, moving it earlier. However for
> > tpm_crb_ffa_init() and crb_acpi_driver_init(), modules.dep
> > takes care that they are loaded in order.
> > For IMA you will need the driver as built-in but that should
> > be handled via kernel config, not via code changes.
> 
> In the case of "module" built, it's true.
> However what I tell here is when "tpm_crb" and "tpm_crb_ffa" is built
> as "built-in" in this case, it couldn't make a "dependency" between
> the same initcall level: here is the case of this.
> 
> 0000000000000888 l       .initcall6.init>-------0000000000000000 crb_acpi_driver_init
> 000000000000088c l       .initcall6.init>-------0000000000000000 tpm_crb_ffa_driver_init
> 
> in this case, wihtout code change, the crb_acpi_driver_init()
> is failed since tpm_crb_ffa_driver_init() is called later.
> 
> and this couldn't be solved with kconfig --
> ARM_FFA_TRANSPORT=y && CONFIG_TCG_CRB=y && CONFIG_TCG_CRB_FFA=y.
> 
> The Patch #2 is to proing the tpm_crb_ffa as part of
> crb_acpi_driver_init() when TPM uses method ARM-FFA.
> 
> If there's another suggestion, let me know please.

Hmm.. I actually got what you mean now. I was looking this from
wrong angle. I think we can pick these patches!

Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>

> 
> Thanks
> 
> --
> Sincerely,
> Yeoreum Yun

BR, Jarkko

On Wed, Jun 25, 2025 at 07:59:53PM +0300, Jarkko Sakkinen wrote:
> On Wed, Jun 25, 2025 at 11:36:19AM +0100, Yeoreum Yun wrote:
> > Hi Jarkko,
> > 
> > > On Wed, Jun 18, 2025 at 11:23:00AM +0100, Yeoreum Yun wrote:
> > > > To ensure the TPM device operating over the FF-A protocol with
> > > > the CRB interface is probed before IMA initialization,
> > > > the following conditions must be met:
> > > >
> > > >    1. The corresponding ffa_device must be registered,
> > > >       which is done via ffa_init().
> > > >
> > > >    2. The tpm_crb_driver must successfully probe this device via
> > > >       tpm_crb_ffa_init().
> > > >
> > > >    3. The tpm_crb driver using CRB over FF-A can then
> > > >       be probed successfully. (See crb_acpi_add() and
> > > >       tpm_crb_ffa_init() for reference.)
> > > >
> > > > Unfortunately, ffa_init(), tpm_crb_ffa_init(), and crb_acpi_driver_init() are
> > > > all registered with device_initcall, which means crb_acpi_driver_init() may
> > > > be invoked before ffa_init() and tpm_crb_ffa_init() are completed.
> > >
> > > I get the ffa_init() part i.e, moving it earlier. However for
> > > tpm_crb_ffa_init() and crb_acpi_driver_init(), modules.dep
> > > takes care that they are loaded in order.
> > > For IMA you will need the driver as built-in but that should
> > > be handled via kernel config, not via code changes.
> > 
> > In the case of "module" built, it's true.
> > However what I tell here is when "tpm_crb" and "tpm_crb_ffa" is built
> > as "built-in" in this case, it couldn't make a "dependency" between
> > the same initcall level: here is the case of this.
> > 
> > 0000000000000888 l       .initcall6.init>-------0000000000000000 crb_acpi_driver_init
> > 000000000000088c l       .initcall6.init>-------0000000000000000 tpm_crb_ffa_driver_init
> > 
> > in this case, wihtout code change, the crb_acpi_driver_init()
> > is failed since tpm_crb_ffa_driver_init() is called later.
> > 
> > and this couldn't be solved with kconfig --
> > ARM_FFA_TRANSPORT=y && CONFIG_TCG_CRB=y && CONFIG_TCG_CRB_FFA=y.
> > 
> > The Patch #2 is to proing the tpm_crb_ffa as part of
> > crb_acpi_driver_init() when TPM uses method ARM-FFA.
> > 
> > If there's another suggestion, let me know please.
> 
> Hmm.. I actually got what you mean now. I was looking this from
> wrong angle. I think we can pick these patches!
> 
> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
> 
> > 
> > Thanks
> > 
> > --
> > Sincerely,
> > Yeoreum Yun
> 
> BR, Jarkko

Applied.

BR, Jarkko

On Wed, Jun 25, 2025 at 08:01:51PM +0300, Jarkko Sakkinen wrote:
> On Wed, Jun 25, 2025 at 07:59:53PM +0300, Jarkko Sakkinen wrote:
> > On Wed, Jun 25, 2025 at 11:36:19AM +0100, Yeoreum Yun wrote:
> > > Hi Jarkko,
> > > 
> > > > On Wed, Jun 18, 2025 at 11:23:00AM +0100, Yeoreum Yun wrote:
> > > > > To ensure the TPM device operating over the FF-A protocol with
> > > > > the CRB interface is probed before IMA initialization,
> > > > > the following conditions must be met:
> > > > >
> > > > >    1. The corresponding ffa_device must be registered,
> > > > >       which is done via ffa_init().
> > > > >
> > > > >    2. The tpm_crb_driver must successfully probe this device via
> > > > >       tpm_crb_ffa_init().
> > > > >
> > > > >    3. The tpm_crb driver using CRB over FF-A can then
> > > > >       be probed successfully. (See crb_acpi_add() and
> > > > >       tpm_crb_ffa_init() for reference.)
> > > > >
> > > > > Unfortunately, ffa_init(), tpm_crb_ffa_init(), and crb_acpi_driver_init() are
> > > > > all registered with device_initcall, which means crb_acpi_driver_init() may
> > > > > be invoked before ffa_init() and tpm_crb_ffa_init() are completed.
> > > >
> > > > I get the ffa_init() part i.e, moving it earlier. However for
> > > > tpm_crb_ffa_init() and crb_acpi_driver_init(), modules.dep
> > > > takes care that they are loaded in order.
> > > > For IMA you will need the driver as built-in but that should
> > > > be handled via kernel config, not via code changes.
> > > 
> > > In the case of "module" built, it's true.
> > > However what I tell here is when "tpm_crb" and "tpm_crb_ffa" is built
> > > as "built-in" in this case, it couldn't make a "dependency" between
> > > the same initcall level: here is the case of this.
> > > 
> > > 0000000000000888 l       .initcall6.init>-------0000000000000000 crb_acpi_driver_init
> > > 000000000000088c l       .initcall6.init>-------0000000000000000 tpm_crb_ffa_driver_init
> > > 
> > > in this case, wihtout code change, the crb_acpi_driver_init()
> > > is failed since tpm_crb_ffa_driver_init() is called later.
> > > 
> > > and this couldn't be solved with kconfig --
> > > ARM_FFA_TRANSPORT=y && CONFIG_TCG_CRB=y && CONFIG_TCG_CRB_FFA=y.
> > > 
> > > The Patch #2 is to proing the tpm_crb_ffa as part of
> > > crb_acpi_driver_init() when TPM uses method ARM-FFA.
> > > 
> > > If there's another suggestion, let me know please.
> > 
> > Hmm.. I actually got what you mean now. I was looking this from
> > wrong angle. I think we can pick these patches!
> > 
> > Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
> > 
> > > 
> > > Thanks
> > > 
> > > --
> > > Sincerely,
> > > Yeoreum Yun
> > 
> > BR, Jarkko
> 
> Applied.

If you are applying 1/2 too, feel free to add

Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>

I was initially thinking of taking it separately as there is no strict
build dependency. But I am fine if you can take them together.

-- 
Regards,
Sudeep

On Wed, Jun 25, 2025 at 08:35:33PM +0100, Sudeep Holla wrote:
> On Wed, Jun 25, 2025 at 08:01:51PM +0300, Jarkko Sakkinen wrote:
> > On Wed, Jun 25, 2025 at 07:59:53PM +0300, Jarkko Sakkinen wrote:
> > > On Wed, Jun 25, 2025 at 11:36:19AM +0100, Yeoreum Yun wrote:
> > > > Hi Jarkko,
> > > > 
> > > > > On Wed, Jun 18, 2025 at 11:23:00AM +0100, Yeoreum Yun wrote:
> > > > > > To ensure the TPM device operating over the FF-A protocol with
> > > > > > the CRB interface is probed before IMA initialization,
> > > > > > the following conditions must be met:
> > > > > >
> > > > > >    1. The corresponding ffa_device must be registered,
> > > > > >       which is done via ffa_init().
> > > > > >
> > > > > >    2. The tpm_crb_driver must successfully probe this device via
> > > > > >       tpm_crb_ffa_init().
> > > > > >
> > > > > >    3. The tpm_crb driver using CRB over FF-A can then
> > > > > >       be probed successfully. (See crb_acpi_add() and
> > > > > >       tpm_crb_ffa_init() for reference.)
> > > > > >
> > > > > > Unfortunately, ffa_init(), tpm_crb_ffa_init(), and crb_acpi_driver_init() are
> > > > > > all registered with device_initcall, which means crb_acpi_driver_init() may
> > > > > > be invoked before ffa_init() and tpm_crb_ffa_init() are completed.
> > > > >
> > > > > I get the ffa_init() part i.e, moving it earlier. However for
> > > > > tpm_crb_ffa_init() and crb_acpi_driver_init(), modules.dep
> > > > > takes care that they are loaded in order.
> > > > > For IMA you will need the driver as built-in but that should
> > > > > be handled via kernel config, not via code changes.
> > > > 
> > > > In the case of "module" built, it's true.
> > > > However what I tell here is when "tpm_crb" and "tpm_crb_ffa" is built
> > > > as "built-in" in this case, it couldn't make a "dependency" between
> > > > the same initcall level: here is the case of this.
> > > > 
> > > > 0000000000000888 l       .initcall6.init>-------0000000000000000 crb_acpi_driver_init
> > > > 000000000000088c l       .initcall6.init>-------0000000000000000 tpm_crb_ffa_driver_init
> > > > 
> > > > in this case, wihtout code change, the crb_acpi_driver_init()
> > > > is failed since tpm_crb_ffa_driver_init() is called later.
> > > > 
> > > > and this couldn't be solved with kconfig --
> > > > ARM_FFA_TRANSPORT=y && CONFIG_TCG_CRB=y && CONFIG_TCG_CRB_FFA=y.
> > > > 
> > > > The Patch #2 is to proing the tpm_crb_ffa as part of
> > > > crb_acpi_driver_init() when TPM uses method ARM-FFA.
> > > > 
> > > > If there's another suggestion, let me know please.
> > > 
> > > Hmm.. I actually got what you mean now. I was looking this from
> > > wrong angle. I think we can pick these patches!
> > > 
> > > Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
> > > 
> > > > 
> > > > Thanks
> > > > 
> > > > --
> > > > Sincerely,
> > > > Yeoreum Yun
> > > 
> > > BR, Jarkko
> > 
> > Applied.
> 
> If you are applying 1/2 too, feel free to add
> 
> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
> 
> I was initially thinking of taking it separately as there is no strict
> build dependency. But I am fine if you can take them together.

Hmm.. Yeah, if you insist to take them, that's fine for me too.

That said, I'm also happy to take care of them :-)

I'll append your review.

> 
> -- 
> Regards,
> Sudeep

BR, Jarkko

On Thu, Jun 26, 2025 at 12:47:17AM +0300, Jarkko Sakkinen wrote:
> On Wed, Jun 25, 2025 at 08:35:33PM +0100, Sudeep Holla wrote:
> > 
> > If you are applying 1/2 too, feel free to add
> > 
> > Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
> > 
> > I was initially thinking of taking it separately as there is no strict
> > build dependency. But I am fine if you can take them together.
> 
> Hmm.. Yeah, if you insist to take them, that's fine for me too.
> 

Ignore me 😄

> That said, I'm also happy to take care of them :-)
> 

Yes, please take them via your tree.

> I'll append your review.

Thanks!

-- 
Regards,
Sudeep

On Thu, Jun 26, 2025 at 08:53:39PM +0100, Sudeep Holla wrote:
> On Thu, Jun 26, 2025 at 12:47:17AM +0300, Jarkko Sakkinen wrote:
> > On Wed, Jun 25, 2025 at 08:35:33PM +0100, Sudeep Holla wrote:
> > > 
> > > If you are applying 1/2 too, feel free to add
> > > 
> > > Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
> > > 
> > > I was initially thinking of taking it separately as there is no strict
> > > build dependency. But I am fine if you can take them together.
> > 
> > Hmm.. Yeah, if you insist to take them, that's fine for me too.
> > 
> 
> Ignore me 😄
> 
> > That said, I'm also happy to take care of them :-)
> > 
> 
> Yes, please take them via your tree.
> 
> > I'll append your review.
> 
> Thanks!

OK cool, cool just syncing up :-)

> 
> -- 
> Regards,
> Sudeep