Re: Build error on -next due to tpm_crb.c changes?

[Stuart Yoder]

On 3/11/25 4:17 PM, Sudeep Holla wrote:
> On Tue, Mar 11, 2025 at 01:25:50PM -0500, Stuart Yoder wrote:
> > On 3/11/25 11:51 AM, Thorsten Leemhuis wrote:
> > > On 11.03.25 16:53, Stuart Yoder wrote:
> > > > On 3/11/25 10:21 AM, Thorsten Leemhuis wrote:
> > > > > On 05.03.25 18:36, Stuart Yoder wrote:
> > > > [...]
> > > > So, it should not be possible on one had have
> > > > CONFIG_TCG_ARM_CRB_FFA being true when building tpm_crb.c
> > > > and false resulting in the tpm_crb_ffa.o not being
> > > > picked up in the build.
> > >
> > > Many thx for the answer. Maybe Fedora's way to prepare the .config files
> > > (which my package builds use to be close to Fedora's official packages)
> > > is doing something odd/wrong. Will take a closer look and report back.
> >
> > I've been experimenting with some different build config combinations
> > and have reproduced what must be the issue.
> >
> > This works fine:
> > <*>   TPM 2.0 CRB Interface                                         < >
> > TPM CRB over Arm FF-A Transport
> >
> > This works fine:
> > < >   TPM 2.0 CRB Interface                                         <*>
> > TPM CRB over Arm FF-A Transport
> >
> > This works fine:
> > <*>   TPM 2.0 CRB Interface                                         <*>
> > TPM CRB over Arm FF-A Transport
> >
> > This works fine:
> > <M>   TPM 2.0 CRB Interface                                         <M>
> > TPM CRB over Arm FF-A Transport
> >
> > This fails:
> > <*>   TPM 2.0 CRB Interface                                         <M>
> > TPM CRB over Arm FF-A Transport
> >
> > The 2 drivers are coupled, so we can't have one built as a module
> > and the other built-in.
> >
> > I'm not a Kconfig expert, and need to do some fiddling to see
> > if I can find a Kconfig syntax that prevents that failure scenario.
>
> 	default y if (TCG_CRB && ARM_FFA_TRANSPORT)
>
> is the issue here. You can select it as built-in if either or one of the
> TCG_CRB and ARM_FFA_TRANSPORT is a module, but that is exactly what happens.
> Not sure if default value is a must for you. But just depends on each of
> these should be good enough and enable it in defconfig if needed. Or
> you can have multiple default at least 4 combinations I can see. Both
> are =y and either and both are =m

I would like a default, because if someone enables both
ARM_FFA_TRANSPORT and TPM_CRB I don't want them to forget to
turn on TCG_ARM_CRB_FFA.

I've experimented with a few ways of doing this and I think
this is simplest and gives the behavior we want:

config TCG_ARM_CRB_FFA
        tristate "TPM CRB over Arm FF-A Transport"
        depends on ARM_FFA_TRANSPORT && TCG_CRB
        default TCG_CRB

The TCG_ARM_CRB_FFA option only appears if both FFA and
TPM_CRB are enabled. And the default tracks the value
of TPM_CRB.

Thanks,
Stuart