Enable CONFIG_TCG_FTPM_TEE as a module for all
the platforms to support firmware-based TPM
through OP-TEE.

Bloat-o-meter Statistics :
add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0)
Function  old           new             delta
Total: Before=32968311, After=32968311, chg +0.00%

Signed-off-by: Atharv Dubey <a-dubey@ti.com>
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 35e9eb180c9a..493a29fbd48f 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -530,6 +530,7 @@ CONFIG_IPMI_SI=m
 CONFIG_HW_RANDOM=y
 CONFIG_HW_RANDOM_VIRTIO=y
 CONFIG_TCG_TPM=y
+CONFIG_TCG_FTPM_TEE=m
 CONFIG_TCG_TIS=m
 CONFIG_TCG_TIS_SPI=m
 CONFIG_TCG_TIS_SPI_CR50=y
-- 
2.34.1

On 11/02/2026 07:15, Atharv Dubey wrote:
> Enable CONFIG_TCG_FTPM_TEE as a module for all
> the platforms to support firmware-based TPM
> through OP-TEE.

What all platforms? Again, this is not your distro defconfig. Explain
why do we want it in upstream.

Please wrap commit message according to Linux coding style / submission
process (neither too early nor over the limit):
https://elixir.bootlin.com/linux/v6.4-rc1/source/Documentation/process/submitting-patches.rst#L597

> 
> Bloat-o-meter Statistics :
> add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0)
> Function  old           new             delta
> Total: Before=32968311, After=32968311, chg +0.00%

Really? You put here a proof that not enabling built-in has no built-in
impact?

Best regards,
Krzysztof

On 2/11/26 12:22 AM, Krzysztof Kozlowski wrote:
> On 11/02/2026 07:15, Atharv Dubey wrote:
>> Enable CONFIG_TCG_FTPM_TEE as a module for all
>> the platforms to support firmware-based TPM
>> through OP-TEE.
> 
> What all platforms? Again, this is not your distro defconfig. Explain
> why do we want it in upstream.
> 

"All" seems correct here, the fTPM TA is usable by any ARM64 platform
with OP-TEE support, which looks to be just about everyone[0].

Why do we want it upstream?: to support firmware-based TPM
through OP-TEE.

What more are you looking for, how do we prove some feature that was
deemed useful enough to include in the kernel is useful enough to enable?

> Please wrap commit message according to Linux coding style / submission
> process (neither too early nor over the limit):
> https://elixir.bootlin.com/linux/v6.4-rc1/source/Documentation/process/submitting-patches.rst#L597
> 
>>
>> Bloat-o-meter Statistics :
>> add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0)
>> Function  old           new             delta
>> Total: Before=32968311, After=32968311, chg +0.00%
> 
> Really? You put here a proof that not enabling built-in has no built-in
> impact?
> 

Does it hurt to add? You never know if there are follow-on effects due
to definitions when setting a module (yes that would probably be a bug
but it can happen). Rules like "add Bloat-o-meter results to defconfig
change patches" work much better when you don't add "except when it's
obvious to Krzysztof that there should be no size change"..

Andrew

[0] https://github.com/OP-TEE/optee_os/tree/master/core/arch/arm

> Best regards,
> Krzysztof
>

On 13/02/2026 16:26, Andrew Davis wrote:
> On 2/11/26 12:22 AM, Krzysztof Kozlowski wrote:
>> On 11/02/2026 07:15, Atharv Dubey wrote:
>>> Enable CONFIG_TCG_FTPM_TEE as a module for all
>>> the platforms to support firmware-based TPM
>>> through OP-TEE.
>>
>> What all platforms? Again, this is not your distro defconfig. Explain
>> why do we want it in upstream.
>>
> 
> "All" seems correct here, the fTPM TA is usable by any ARM64 platform
> with OP-TEE support, which looks to be just about everyone[0].
> 
> Why do we want it upstream?: to support firmware-based TPM
> through OP-TEE.
> 
> What more are you looking for, how do we prove some feature that was
> deemed useful enough to include in the kernel is useful enough to enable?

Most of other commits also claimed similar, so I want to be sure that
this one is real "all". Probably this should build on top of existing
OPTEE support.


> 
>> Please wrap commit message according to Linux coding style / submission
>> process (neither too early nor over the limit):
>> https://elixir.bootlin.com/linux/v6.4-rc1/source/Documentation/process/submitting-patches.rst#L597
>>
>>>
>>> Bloat-o-meter Statistics :
>>> add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0)
>>> Function  old           new             delta
>>> Total: Before=32968311, After=32968311, chg +0.00%
>>
>> Really? You put here a proof that not enabling built-in has no built-in
>> impact?
>>
> 
> Does it hurt to add? You never know if there are follow-on effects due
> to definitions when setting a module (yes that would probably be a bug
> but it can happen). Rules like "add Bloat-o-meter results to defconfig
> change patches" work much better when you don't add "except when it's
> obvious to Krzysztof that there should be no size change"..
> 
> Andrew

Reading this bloatometer actually takes time (including comparison of
two long numbers) which is much longer than just saying "it's a module
so no impact on kernel size"... which then you will understand is
completely redundant statement. Placing here bloatometer actually
encourages to check WHY it is there, like there was some useful
information. Redundant information is not useful information.

There is no rule to add bloatometer for modules. It's completely
pointless. The benefit of bloatometer is when you make built-ins.

But if we go to redundant information, maybe we should also mention here:
1. time of building Image.gz
2. time of building modules
3. impact on running dtbs_check
4. list of new user-space interfaces exposed

Best regards,
Krzysztof