[RFC 0/4] tpm_crb: Add command and response buffer chunking support

[RFC 0/4] tpm_crb: Add command and response buffer chunking support

[Arun Menon]

The new version of TCG TPM v185 (currently under review [1]) supports
sending data/commands in chunks for the CRB (Command Response Buffer)
interface. This is in line with the initiative to support PQC algorithms.

This series implements the logic to send and receive larger TPM
cmd/rsp between the linux guest and the TPM backend in chunks.
Currently, the TPM CRB driver is limited by the physical size of the
MMIO window. When userspace attempts to send a payload that exceeds this
size, the driver rejects it.

This series introduces chunking support. The driver now checks the CRB
interface capability for CRB_INTF_CAP_CRB_CHUNK. If supported by the
backend, the driver will slice oversized commands into MMIO-sized
chunks, signalling the backend via CRB_START_NEXT_CHUNK, and finalizing
with CRB_START_INVOKE. Responses are also read back in a similar chunked
manner.

If the backend does not support chunking, the driver retains its legacy
behaviour and enforces the standard size limits.

This feature also requires the QEMU to interpret the data in chunks and
forward it to the TPM backend and subsequently dispatch the TPM response
in chunks back to the linux guest. This is implemented in [2]

[1] https://trustedcomputinggroup.org/wp-content/uploads/PC-Client-Specific-Platform-TPM-Profile-for-TPM-2p0-v1p07_rc1_121225.pdf
[2] https://lore.kernel.org/qemu-devel/20260319135316.37412-1-armenon@redhat.com/

Arun Menon (4):
  tpm_crb: Add definition of TPM CRB chunking fields
  tpm_crb: Add new wrapper function to invoke start method
  tpm_crb: Implement command and response chunking logic
  tpm: Increase TPM_BUFSIZE to 64kB for chunking support

 drivers/char/tpm/tpm.h     |   2 +-
 drivers/char/tpm/tpm_crb.c | 194 ++++++++++++++++++++++++++-----------
 2 files changed, 137 insertions(+), 59 deletions(-)

-- 
2.53.0

[RFC 1/4] tpm_crb: Add definition of TPM CRB chunking fields

[Arun Menon]

- Add 2 new registers for invoking the start method
  and add CRB_INTF_CAP_CRB_CHUNK as the new TCG TPM
  specifies this CRB Interface Identifier that decides
  if chunking is allowed.
- Refer section 6.4.2.2 of the specification document [1]

[1] https://trustedcomputinggroup.org/wp-content/uploads/PC-Client-Specific-Platform-TPM-Profile-for-TPM-2p0-v1p07_rc1_121225.pdf

Signed-off-by: Arun Menon <armenon@redhat.com>
---
 drivers/char/tpm/tpm_crb.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c
index 6c25305c256ef..67c0061d4cab7 100644
--- a/drivers/char/tpm/tpm_crb.c
+++ b/drivers/char/tpm/tpm_crb.c
@@ -56,12 +56,18 @@ enum crb_ctrl_sts {
 
 enum crb_start {
 	CRB_START_INVOKE	= BIT(0),
+	CRB_START_RESP_RETRY = BIT(1),
+	CRB_START_NEXT_CHUNK = BIT(2),
 };
 
 enum crb_cancel {
 	CRB_CANCEL_INVOKE	= BIT(0),
 };
 
+enum crb_intf {
+	CRB_INTF_CAP_CRB_CHUNK = BIT(10),
+};
+
 struct crb_regs_head {
 	u32 loc_state;
 	u32 reserved1;
-- 
2.53.0

[RFC 2/4] tpm_crb: Add new wrapper function to invoke start method

[Arun Menon]

- Extract start invocation code into a separate function called
  crb_trigger_tpm. This will be helpful in repeatedly calling the
  start method with different bits set to toggle between start,
  nextChunk or crbRspRetry behaviours.
- Based on the bit set, we signal the TPM to consume
  contents of the command/response buffer.
- No functional change intended.

Signed-off-by: Arun Menon <armenon@redhat.com>
---
 drivers/char/tpm/tpm_crb.c | 50 ++++++++++++++++++++------------------
 1 file changed, 27 insertions(+), 23 deletions(-)

diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c
index 67c0061d4cab7..10128d078245c 100644
--- a/drivers/char/tpm/tpm_crb.c
+++ b/drivers/char/tpm/tpm_crb.c
@@ -445,6 +445,32 @@ static int tpm_crb_smc_start(struct device *dev, unsigned long func_id)
 }
 #endif
 
+static int crb_trigger_tpm(struct tpm_chip *chip, u32 start_cmd)
+{
+	struct crb_priv *priv = dev_get_drvdata(&chip->dev);
+	int rc;
+	/* The reason for the extra quirk is that the PTT in 4th Gen Core CPUs
+	 * report only ACPI start but in practice seems to require both
+	 * CRB start, hence invoking CRB start method if hid == MSFT0101.
+	 */
+	if (priv->sm == ACPI_TPM2_COMMAND_BUFFER ||
+	    priv->sm == ACPI_TPM2_MEMORY_MAPPED ||
+	    !strcmp(priv->hid, "MSFT0101"))
+		iowrite32(start_cmd, &priv->regs_t->ctrl_start);
+	if (priv->sm == ACPI_TPM2_START_METHOD ||
+	    priv->sm == ACPI_TPM2_COMMAND_BUFFER_WITH_START_METHOD)
+		rc = crb_do_acpi_start(chip);
+	if (priv->sm == ACPI_TPM2_COMMAND_BUFFER_WITH_ARM_SMC) {
+		iowrite32(start_cmd, &priv->regs_t->ctrl_start);
+		rc = tpm_crb_smc_start(&chip->dev, priv->smc_func_id);
+	}
+	if (priv->sm == ACPI_TPM2_CRB_WITH_ARM_FFA) {
+		iowrite32(start_cmd, &priv->regs_t->ctrl_start);
+		rc = tpm_crb_ffa_start(CRB_FFA_START_TYPE_COMMAND, chip->locality);
+	}
+	return rc;
+}
+
 static int crb_send(struct tpm_chip *chip, u8 *buf, size_t bufsiz, size_t len)
 {
 	struct crb_priv *priv = dev_get_drvdata(&chip->dev);
@@ -470,29 +496,7 @@ static int crb_send(struct tpm_chip *chip, u8 *buf, size_t bufsiz, size_t len)
 	/* Make sure that cmd is populated before issuing start. */
 	wmb();
 
-	/* The reason for the extra quirk is that the PTT in 4th Gen Core CPUs
-	 * report only ACPI start but in practice seems to require both
-	 * CRB start, hence invoking CRB start method if hid == MSFT0101.
-	 */
-	if (priv->sm == ACPI_TPM2_COMMAND_BUFFER ||
-	    priv->sm == ACPI_TPM2_MEMORY_MAPPED ||
-	    !strcmp(priv->hid, "MSFT0101"))
-		iowrite32(CRB_START_INVOKE, &priv->regs_t->ctrl_start);
-
-	if (priv->sm == ACPI_TPM2_START_METHOD ||
-	    priv->sm == ACPI_TPM2_COMMAND_BUFFER_WITH_START_METHOD)
-		rc = crb_do_acpi_start(chip);
-
-	if (priv->sm == ACPI_TPM2_COMMAND_BUFFER_WITH_ARM_SMC) {
-		iowrite32(CRB_START_INVOKE, &priv->regs_t->ctrl_start);
-		rc = tpm_crb_smc_start(&chip->dev, priv->smc_func_id);
-	}
-
-	if (priv->sm == ACPI_TPM2_CRB_WITH_ARM_FFA) {
-		iowrite32(CRB_START_INVOKE, &priv->regs_t->ctrl_start);
-		rc = tpm_crb_ffa_start(CRB_FFA_START_TYPE_COMMAND, chip->locality);
-	}
-
+	rc = crb_trigger_tpm(chip, CRB_START_INVOKE);
 	if (rc)
 		return rc;
 
-- 
2.53.0

Re: [RFC 2/4] tpm_crb: Add new wrapper function to invoke start method

[Jarkko Sakkinen]

On Tue, Mar 24, 2026 at 12:48:01PM +0530, Arun Menon wrote:
> - Extract start invocation code into a separate function called
>   crb_trigger_tpm. This will be helpful in repeatedly calling the
>   start method with different bits set to toggle between start,
>   nextChunk or crbRspRetry behaviours.
> - Based on the bit set, we signal the TPM to consume
>   contents of the command/response buffer.
> - No functional change intended.

Please write a proper commit message, which is not a task list.

> 
> Signed-off-by: Arun Menon <armenon@redhat.com>
> ---
>  drivers/char/tpm/tpm_crb.c | 50 ++++++++++++++++++++------------------
>  1 file changed, 27 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c
> index 67c0061d4cab7..10128d078245c 100644
> --- a/drivers/char/tpm/tpm_crb.c
> +++ b/drivers/char/tpm/tpm_crb.c
> @@ -445,6 +445,32 @@ static int tpm_crb_smc_start(struct device *dev, unsigned long func_id)
>  }
>  #endif
>  
> +static int crb_trigger_tpm(struct tpm_chip *chip, u32 start_cmd)
> +{
> +	struct crb_priv *priv = dev_get_drvdata(&chip->dev);
> +	int rc;
> +	/* The reason for the extra quirk is that the PTT in 4th Gen Core CPUs
> +	 * report only ACPI start but in practice seems to require both
> +	 * CRB start, hence invoking CRB start method if hid == MSFT0101.
> +	 */
> +	if (priv->sm == ACPI_TPM2_COMMAND_BUFFER ||
> +	    priv->sm == ACPI_TPM2_MEMORY_MAPPED ||
> +	    !strcmp(priv->hid, "MSFT0101"))
> +		iowrite32(start_cmd, &priv->regs_t->ctrl_start);
> +	if (priv->sm == ACPI_TPM2_START_METHOD ||
> +	    priv->sm == ACPI_TPM2_COMMAND_BUFFER_WITH_START_METHOD)
> +		rc = crb_do_acpi_start(chip);
> +	if (priv->sm == ACPI_TPM2_COMMAND_BUFFER_WITH_ARM_SMC) {
> +		iowrite32(start_cmd, &priv->regs_t->ctrl_start);
> +		rc = tpm_crb_smc_start(&chip->dev, priv->smc_func_id);
> +	}
> +	if (priv->sm == ACPI_TPM2_CRB_WITH_ARM_FFA) {
> +		iowrite32(start_cmd, &priv->regs_t->ctrl_start);
> +		rc = tpm_crb_ffa_start(CRB_FFA_START_TYPE_COMMAND, chip->locality);
> +	}
> +	return rc;
> +}
> +
>  static int crb_send(struct tpm_chip *chip, u8 *buf, size_t bufsiz, size_t len)
>  {
>  	struct crb_priv *priv = dev_get_drvdata(&chip->dev);
> @@ -470,29 +496,7 @@ static int crb_send(struct tpm_chip *chip, u8 *buf, size_t bufsiz, size_t len)
>  	/* Make sure that cmd is populated before issuing start. */
>  	wmb();
>  
> -	/* The reason for the extra quirk is that the PTT in 4th Gen Core CPUs
> -	 * report only ACPI start but in practice seems to require both
> -	 * CRB start, hence invoking CRB start method if hid == MSFT0101.
> -	 */
> -	if (priv->sm == ACPI_TPM2_COMMAND_BUFFER ||
> -	    priv->sm == ACPI_TPM2_MEMORY_MAPPED ||
> -	    !strcmp(priv->hid, "MSFT0101"))
> -		iowrite32(CRB_START_INVOKE, &priv->regs_t->ctrl_start);
> -
> -	if (priv->sm == ACPI_TPM2_START_METHOD ||
> -	    priv->sm == ACPI_TPM2_COMMAND_BUFFER_WITH_START_METHOD)
> -		rc = crb_do_acpi_start(chip);
> -
> -	if (priv->sm == ACPI_TPM2_COMMAND_BUFFER_WITH_ARM_SMC) {
> -		iowrite32(CRB_START_INVOKE, &priv->regs_t->ctrl_start);
> -		rc = tpm_crb_smc_start(&chip->dev, priv->smc_func_id);
> -	}
> -
> -	if (priv->sm == ACPI_TPM2_CRB_WITH_ARM_FFA) {
> -		iowrite32(CRB_START_INVOKE, &priv->regs_t->ctrl_start);
> -		rc = tpm_crb_ffa_start(CRB_FFA_START_TYPE_COMMAND, chip->locality);
> -	}
> -
> +	rc = crb_trigger_tpm(chip, CRB_START_INVOKE);
>  	if (rc)
>  		return rc;
>  
> -- 
> 2.53.0
> 

BR, Jarkko

Re: [RFC 2/4] tpm_crb: Add new wrapper function to invoke start method

[Arun Menon]

On Tue, Mar 24, 2026 at 12:42:19PM +0200, Jarkko Sakkinen wrote:
> On Tue, Mar 24, 2026 at 12:48:01PM +0530, Arun Menon wrote:
> > - Extract start invocation code into a separate function called
> >   crb_trigger_tpm. This will be helpful in repeatedly calling the
> >   start method with different bits set to toggle between start,
> >   nextChunk or crbRspRetry behaviours.
> > - Based on the bit set, we signal the TPM to consume
> >   contents of the command/response buffer.
> > - No functional change intended.
> 
> Please write a proper commit message, which is not a task list.

Yes, I shall do that. Thank you for taking a look.

> 
> > 
> > Signed-off-by: Arun Menon <armenon@redhat.com>
> > ---
> >  drivers/char/tpm/tpm_crb.c | 50 ++++++++++++++++++++------------------
> >  1 file changed, 27 insertions(+), 23 deletions(-)
> > 
> > diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c
> > index 67c0061d4cab7..10128d078245c 100644
> > --- a/drivers/char/tpm/tpm_crb.c
> > +++ b/drivers/char/tpm/tpm_crb.c
> > @@ -445,6 +445,32 @@ static int tpm_crb_smc_start(struct device *dev, unsigned long func_id)
> >  }
> >  #endif
> >  
> > +static int crb_trigger_tpm(struct tpm_chip *chip, u32 start_cmd)
> > +{
> > +	struct crb_priv *priv = dev_get_drvdata(&chip->dev);
> > +	int rc;
> > +	/* The reason for the extra quirk is that the PTT in 4th Gen Core CPUs
> > +	 * report only ACPI start but in practice seems to require both
> > +	 * CRB start, hence invoking CRB start method if hid == MSFT0101.
> > +	 */
> > +	if (priv->sm == ACPI_TPM2_COMMAND_BUFFER ||
> > +	    priv->sm == ACPI_TPM2_MEMORY_MAPPED ||
> > +	    !strcmp(priv->hid, "MSFT0101"))
> > +		iowrite32(start_cmd, &priv->regs_t->ctrl_start);
> > +	if (priv->sm == ACPI_TPM2_START_METHOD ||
> > +	    priv->sm == ACPI_TPM2_COMMAND_BUFFER_WITH_START_METHOD)
> > +		rc = crb_do_acpi_start(chip);
> > +	if (priv->sm == ACPI_TPM2_COMMAND_BUFFER_WITH_ARM_SMC) {
> > +		iowrite32(start_cmd, &priv->regs_t->ctrl_start);
> > +		rc = tpm_crb_smc_start(&chip->dev, priv->smc_func_id);
> > +	}
> > +	if (priv->sm == ACPI_TPM2_CRB_WITH_ARM_FFA) {
> > +		iowrite32(start_cmd, &priv->regs_t->ctrl_start);
> > +		rc = tpm_crb_ffa_start(CRB_FFA_START_TYPE_COMMAND, chip->locality);
> > +	}
> > +	return rc;
> > +}
> > +
> >  static int crb_send(struct tpm_chip *chip, u8 *buf, size_t bufsiz, size_t len)
> >  {
> >  	struct crb_priv *priv = dev_get_drvdata(&chip->dev);
> > @@ -470,29 +496,7 @@ static int crb_send(struct tpm_chip *chip, u8 *buf, size_t bufsiz, size_t len)
> >  	/* Make sure that cmd is populated before issuing start. */
> >  	wmb();
> >  
> > -	/* The reason for the extra quirk is that the PTT in 4th Gen Core CPUs
> > -	 * report only ACPI start but in practice seems to require both
> > -	 * CRB start, hence invoking CRB start method if hid == MSFT0101.
> > -	 */
> > -	if (priv->sm == ACPI_TPM2_COMMAND_BUFFER ||
> > -	    priv->sm == ACPI_TPM2_MEMORY_MAPPED ||
> > -	    !strcmp(priv->hid, "MSFT0101"))
> > -		iowrite32(CRB_START_INVOKE, &priv->regs_t->ctrl_start);
> > -
> > -	if (priv->sm == ACPI_TPM2_START_METHOD ||
> > -	    priv->sm == ACPI_TPM2_COMMAND_BUFFER_WITH_START_METHOD)
> > -		rc = crb_do_acpi_start(chip);
> > -
> > -	if (priv->sm == ACPI_TPM2_COMMAND_BUFFER_WITH_ARM_SMC) {
> > -		iowrite32(CRB_START_INVOKE, &priv->regs_t->ctrl_start);
> > -		rc = tpm_crb_smc_start(&chip->dev, priv->smc_func_id);
> > -	}
> > -
> > -	if (priv->sm == ACPI_TPM2_CRB_WITH_ARM_FFA) {
> > -		iowrite32(CRB_START_INVOKE, &priv->regs_t->ctrl_start);
> > -		rc = tpm_crb_ffa_start(CRB_FFA_START_TYPE_COMMAND, chip->locality);
> > -	}
> > -
> > +	rc = crb_trigger_tpm(chip, CRB_START_INVOKE);
> >  	if (rc)
> >  		return rc;
> >  
> > -- 
> > 2.53.0
> > 
> 
> BR, Jarkko
> 

Regards,
Arun Menon

Re: [RFC 2/4] tpm_crb: Add new wrapper function to invoke start method

[Jarkko Sakkinen]

On Tue, Mar 24, 2026 at 06:13:20PM +0530, Arun Menon wrote:
> 
> On Tue, Mar 24, 2026 at 12:42:19PM +0200, Jarkko Sakkinen wrote:
> > On Tue, Mar 24, 2026 at 12:48:01PM +0530, Arun Menon wrote:
> > > - Extract start invocation code into a separate function called
> > >   crb_trigger_tpm. This will be helpful in repeatedly calling the
> > >   start method with different bits set to toggle between start,
> > >   nextChunk or crbRspRetry behaviours.
> > > - Based on the bit set, we signal the TPM to consume
> > >   contents of the command/response buffer.
> > > - No functional change intended.
> > 
> > Please write a proper commit message, which is not a task list.
> 
> Yes, I shall do that. Thank you for taking a look.

Yeah, and now is good time to improve cosmetic details like this.

I rather take closer look at code when I can run it as I'm not LLM
coding agent, I need to run to understand cannot hallucinate it :-)

BR, Jarkko

Re: [RFC 2/4] tpm_crb: Add new wrapper function to invoke start method

[Arun Menon]

On Wed, Apr 08, 2026 at 11:36:06AM +0300, Jarkko Sakkinen wrote:
> On Tue, Mar 24, 2026 at 06:13:20PM +0530, Arun Menon wrote:
> > 
> > On Tue, Mar 24, 2026 at 12:42:19PM +0200, Jarkko Sakkinen wrote:
> > > On Tue, Mar 24, 2026 at 12:48:01PM +0530, Arun Menon wrote:
> > > > - Extract start invocation code into a separate function called
> > > >   crb_trigger_tpm. This will be helpful in repeatedly calling the
> > > >   start method with different bits set to toggle between start,
> > > >   nextChunk or crbRspRetry behaviours.
> > > > - Based on the bit set, we signal the TPM to consume
> > > >   contents of the command/response buffer.
> > > > - No functional change intended.
> > > 
> > > Please write a proper commit message, which is not a task list.
> > 
> > Yes, I shall do that. Thank you for taking a look.
> 
> Yeah, and now is good time to improve cosmetic details like this.
> 
> I rather take closer look at code when I can run it as I'm not LLM
> coding agent, I need to run to understand cannot hallucinate it :-)

Makes total sense. I have updated the commit messages in v2.
https://lore.kernel.org/lkml/20260324181244.17741-2-armenon@redhat.com/

> 
> BR, Jarkko

Regards,
Arun Menon

[RFC 3/4] tpm_crb: Implement command and response chunking logic

[Arun Menon]

Add support for sending and receiving TPM command data in chunks when
the payload exceeds the physical size of the hardware MMIO window.

This introduces the following changes:

- crb_map_io(): Checks the device interface capability to determine if
  chunking is supported, setting the chunking_supported flag. It also
  stores the hardware's maximum response buffer size in priv->rsp_size.
- crb_send(): Iteratively writes command chunks to the fixed priv->cmd
  MMIO window. It signals the TPM backend to process intermediate chunks
  using CRB_START_NEXT_CHUNK, and signals the final chunk to begin
  execution using CRB_START_INVOKE.
- crb_recv(): Parses the expected response size from the initial TPM
  header. It then iteratively reads chunks from the fixed priv->rsp
  MMIO window into the destination buffer, advancing the buffer offset
  until the complete response is retrieved.

Signed-off-by: Arun Menon <armenon@redhat.com>
---
 drivers/char/tpm/tpm_crb.c | 150 +++++++++++++++++++++++++++----------
 1 file changed, 109 insertions(+), 41 deletions(-)

diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c
index 10128d078245c..fb63cc3737253 100644
--- a/drivers/char/tpm/tpm_crb.c
+++ b/drivers/char/tpm/tpm_crb.c
@@ -104,11 +104,13 @@ struct crb_priv {
 	u8 __iomem *cmd;
 	u8 __iomem *rsp;
 	u32 cmd_size;
+	u32 rsp_size;
 	u32 smc_func_id;
 	u32 __iomem *pluton_start_addr;
 	u32 __iomem *pluton_reply_addr;
 	u8 ffa_flags;
 	u8 ffa_attributes;
+	bool chunking_supported;
 };
 
 struct tpm2_crb_smc {
@@ -368,38 +370,6 @@ static u8 crb_status(struct tpm_chip *chip)
 	return sts;
 }
 
-static int crb_recv(struct tpm_chip *chip, u8 *buf, size_t count)
-{
-	struct crb_priv *priv = dev_get_drvdata(&chip->dev);
-	unsigned int expected;
-
-	/* A sanity check that the upper layer wants to get at least the header
-	 * as that is the minimum size for any TPM response.
-	 */
-	if (count < TPM_HEADER_SIZE)
-		return -EIO;
-
-	/* If this bit is set, according to the spec, the TPM is in
-	 * unrecoverable condition.
-	 */
-	if (ioread32(&priv->regs_t->ctrl_sts) & CRB_CTRL_STS_ERROR)
-		return -EIO;
-
-	/* Read the first 8 bytes in order to get the length of the response.
-	 * We read exactly a quad word in order to make sure that the remaining
-	 * reads will be aligned.
-	 */
-	memcpy_fromio(buf, priv->rsp, 8);
-
-	expected = be32_to_cpup((__be32 *)&buf[2]);
-	if (expected > count || expected < TPM_HEADER_SIZE)
-		return -EIO;
-
-	memcpy_fromio(&buf[8], &priv->rsp[8], expected - 8);
-
-	return expected;
-}
-
 static int crb_do_acpi_start(struct tpm_chip *chip)
 {
 	union acpi_object *obj;
@@ -474,6 +444,8 @@ static int crb_trigger_tpm(struct tpm_chip *chip, u32 start_cmd)
 static int crb_send(struct tpm_chip *chip, u8 *buf, size_t bufsiz, size_t len)
 {
 	struct crb_priv *priv = dev_get_drvdata(&chip->dev);
+	size_t offset = 0;
+	size_t chunk_size;
 	int rc = 0;
 
 	/* Zero the cancel register so that the next command will not get
@@ -481,7 +453,7 @@ static int crb_send(struct tpm_chip *chip, u8 *buf, size_t bufsiz, size_t len)
 	 */
 	iowrite32(0, &priv->regs_t->ctrl_cancel);
 
-	if (len > priv->cmd_size) {
+	if (len > priv->cmd_size && !priv->chunking_supported) {
 		dev_err(&chip->dev, "invalid command count value %zd %d\n",
 			len, priv->cmd_size);
 		return -E2BIG;
@@ -491,16 +463,101 @@ static int crb_send(struct tpm_chip *chip, u8 *buf, size_t bufsiz, size_t len)
 	if (priv->sm == ACPI_TPM2_COMMAND_BUFFER_WITH_PLUTON)
 		__crb_cmd_ready(&chip->dev, priv, chip->locality);
 
-	memcpy_toio(priv->cmd, buf, len);
+	while (offset < len) {
+		chunk_size = min_t(size_t, len - offset, priv->cmd_size);
+
+		memcpy_toio(priv->cmd, buf + offset, chunk_size);
+		offset += chunk_size;
+
+		/* Make sure that cmd is populated before issuing start. */
+		wmb();
+		if (offset < len) {
+			rc = crb_trigger_tpm(chip, CRB_START_NEXT_CHUNK);
+			if (rc)
+				return rc;
+			if (!crb_wait_for_reg_32(&priv->regs_t->ctrl_start,
+			    CRB_START_NEXT_CHUNK, 0, TPM2_TIMEOUT_C)) {
+				dev_err(&chip->dev,
+					"Timeout waiting for backend to consume chunk\n");
+				return -ETIME;
+			}
+		} else {
+			rc = crb_trigger_tpm(chip, CRB_START_INVOKE);
+			if (rc)
+				return rc;
+		}
+	}
+	return crb_try_pluton_doorbell(priv, false);
+}
 
-	/* Make sure that cmd is populated before issuing start. */
-	wmb();
+static int crb_recv(struct tpm_chip *chip, u8 *buf, size_t count)
+{
+	struct crb_priv *priv = dev_get_drvdata(&chip->dev);
+	unsigned int expected;
+	size_t offset = 0;
+	size_t chunk_size;
+	size_t first_read;
+	int rc;
 
-	rc = crb_trigger_tpm(chip, CRB_START_INVOKE);
-	if (rc)
-		return rc;
+	/* A sanity check that the upper layer wants to get at least the header
+	 * as that is the minimum size for any TPM response.
+	 */
+	if (count < TPM_HEADER_SIZE)
+		return -EIO;
 
-	return crb_try_pluton_doorbell(priv, false);
+	/* If this bit is set, according to the spec, the TPM is in
+	 * unrecoverable condition.
+	 */
+	if (ioread32(&priv->regs_t->ctrl_sts) & CRB_CTRL_STS_ERROR)
+		return -EIO;
+
+	/* Read the first 8 bytes in order to get the length of the response.
+	 * We read exactly a quad word in order to make sure that the remaining
+	 * reads will be aligned.
+	 */
+	memcpy_fromio(buf, priv->rsp, 8);
+
+	expected = be32_to_cpup((__be32 *)&buf[2]);
+	if (expected > count || expected < TPM_HEADER_SIZE)
+		return -EIO;
+
+	/*
+	 * Set chunk_size by comparing the size of the buffer that the upper layer has
+	 * allocated (count) to the hardware tpm limit (priv->rsp_size).
+	 * This is to prevent buffer overflow while writing to buf.
+	 */
+	chunk_size = min_t(size_t, count, priv->rsp_size);
+
+	/*
+	 * Compare the actual size of the response we found in the header to the chunk_size.
+	 */
+	first_read = min_t(size_t, expected, chunk_size);
+
+	memcpy_fromio(&buf[8], &priv->rsp[8], first_read - 8);
+	offset = first_read;
+
+	while (offset < expected) {
+		if (!priv->chunking_supported) {
+			dev_err(&chip->dev, "Response larger than MMIO and chunking not supported\n");
+			return -EIO;
+		}
+
+		rc = crb_trigger_tpm(chip, CRB_START_NEXT_CHUNK);
+		if (rc)
+			return rc;
+
+		if (!crb_wait_for_reg_32(&priv->regs_t->ctrl_start,
+					 CRB_START_NEXT_CHUNK, 0, TPM2_TIMEOUT_C)) {
+			dev_err(&chip->dev, "Timeout waiting for backend response\n");
+			return -ETIME;
+		}
+
+		chunk_size = min_t(size_t, expected - offset, priv->rsp_size);
+		memcpy_fromio(buf + offset, priv->rsp, chunk_size);
+		offset += chunk_size;
+	}
+
+	return expected;
 }
 
 static void crb_cancel(struct tpm_chip *chip)
@@ -727,6 +784,15 @@ static int crb_map_io(struct acpi_device *device, struct crb_priv *priv,
 		goto out;
 	}
 
+	if (priv->regs_h) {
+		u32 intf_id = ioread32((u32 __iomem *)&priv->regs_h->intf_id);
+
+		if (intf_id & CRB_INTF_CAP_CRB_CHUNK) {
+			priv->chunking_supported = true;
+			dev_info(dev, "CRB Chunking is supported by backend\n");
+		}
+	}
+
 	memcpy_fromio(&__rsp_pa, &priv->regs_t->ctrl_rsp_pa, 8);
 	rsp_pa = le64_to_cpu(__rsp_pa);
 	rsp_size = ioread32(&priv->regs_t->ctrl_rsp_size);
@@ -764,8 +830,10 @@ static int crb_map_io(struct acpi_device *device, struct crb_priv *priv,
 	priv->rsp = priv->cmd;
 
 out:
-	if (!ret)
+	if (!ret) {
 		priv->cmd_size = cmd_size;
+		priv->rsp_size = rsp_size;
+	}
 
 	__crb_go_idle(dev, priv, 0);
 
-- 
2.53.0

Re: [RFC 3/4] tpm_crb: Implement command and response chunking logic

[Jarkko Sakkinen]

On Tue, Mar 24, 2026 at 12:48:02PM +0530, Arun Menon wrote:
> Add support for sending and receiving TPM command data in chunks when
> the payload exceeds the physical size of the hardware MMIO window.
> 
> This introduces the following changes:
> 
> - crb_map_io(): Checks the device interface capability to determine if
>   chunking is supported, setting the chunking_supported flag. It also
>   stores the hardware's maximum response buffer size in priv->rsp_size.
> - crb_send(): Iteratively writes command chunks to the fixed priv->cmd
>   MMIO window. It signals the TPM backend to process intermediate chunks
>   using CRB_START_NEXT_CHUNK, and signals the final chunk to begin
>   execution using CRB_START_INVOKE.
> - crb_recv(): Parses the expected response size from the initial TPM
>   header. It then iteratively reads chunks from the fixed priv->rsp
>   MMIO window into the destination buffer, advancing the buffer offset
>   until the complete response is retrieved.
> 
> Signed-off-by: Arun Menon <armenon@redhat.com>

This is also just description of wha this adds. I'd lessen the detail
and write a description that describes motivation and logic of the
change. It's a good test for author knowledge, as if you really get
the topic you can explain its gist. In addition, it can be reflected
to implementation (vs. the descriptions that are pseudocode in English)

Since this RFC and QEMU does not have the feature in release it is
good to polish stuff like this.

> ---
>  drivers/char/tpm/tpm_crb.c | 150 +++++++++++++++++++++++++++----------
>  1 file changed, 109 insertions(+), 41 deletions(-)
> 
> diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c
> index 10128d078245c..fb63cc3737253 100644
> --- a/drivers/char/tpm/tpm_crb.c
> +++ b/drivers/char/tpm/tpm_crb.c
> @@ -104,11 +104,13 @@ struct crb_priv {
>  	u8 __iomem *cmd;
>  	u8 __iomem *rsp;
>  	u32 cmd_size;
> +	u32 rsp_size;
>  	u32 smc_func_id;
>  	u32 __iomem *pluton_start_addr;
>  	u32 __iomem *pluton_reply_addr;
>  	u8 ffa_flags;
>  	u8 ffa_attributes;
> +	bool chunking_supported;
>  };
>  
>  struct tpm2_crb_smc {
> @@ -368,38 +370,6 @@ static u8 crb_status(struct tpm_chip *chip)
>  	return sts;
>  }
>  
> -static int crb_recv(struct tpm_chip *chip, u8 *buf, size_t count)
> -{
> -	struct crb_priv *priv = dev_get_drvdata(&chip->dev);
> -	unsigned int expected;
> -
> -	/* A sanity check that the upper layer wants to get at least the header
> -	 * as that is the minimum size for any TPM response.
> -	 */
> -	if (count < TPM_HEADER_SIZE)
> -		return -EIO;
> -
> -	/* If this bit is set, according to the spec, the TPM is in
> -	 * unrecoverable condition.
> -	 */
> -	if (ioread32(&priv->regs_t->ctrl_sts) & CRB_CTRL_STS_ERROR)
> -		return -EIO;
> -
> -	/* Read the first 8 bytes in order to get the length of the response.
> -	 * We read exactly a quad word in order to make sure that the remaining
> -	 * reads will be aligned.
> -	 */
> -	memcpy_fromio(buf, priv->rsp, 8);
> -
> -	expected = be32_to_cpup((__be32 *)&buf[2]);
> -	if (expected > count || expected < TPM_HEADER_SIZE)
> -		return -EIO;
> -
> -	memcpy_fromio(&buf[8], &priv->rsp[8], expected - 8);
> -
> -	return expected;
> -}
> -
>  static int crb_do_acpi_start(struct tpm_chip *chip)
>  {
>  	union acpi_object *obj;
> @@ -474,6 +444,8 @@ static int crb_trigger_tpm(struct tpm_chip *chip, u32 start_cmd)
>  static int crb_send(struct tpm_chip *chip, u8 *buf, size_t bufsiz, size_t len)
>  {
>  	struct crb_priv *priv = dev_get_drvdata(&chip->dev);
> +	size_t offset = 0;
> +	size_t chunk_size;
>  	int rc = 0;
>  
>  	/* Zero the cancel register so that the next command will not get
> @@ -481,7 +453,7 @@ static int crb_send(struct tpm_chip *chip, u8 *buf, size_t bufsiz, size_t len)
>  	 */
>  	iowrite32(0, &priv->regs_t->ctrl_cancel);
>  
> -	if (len > priv->cmd_size) {
> +	if (len > priv->cmd_size && !priv->chunking_supported) {
>  		dev_err(&chip->dev, "invalid command count value %zd %d\n",
>  			len, priv->cmd_size);
>  		return -E2BIG;
> @@ -491,16 +463,101 @@ static int crb_send(struct tpm_chip *chip, u8 *buf, size_t bufsiz, size_t len)
>  	if (priv->sm == ACPI_TPM2_COMMAND_BUFFER_WITH_PLUTON)
>  		__crb_cmd_ready(&chip->dev, priv, chip->locality);
>  
> -	memcpy_toio(priv->cmd, buf, len);
> +	while (offset < len) {
> +		chunk_size = min_t(size_t, len - offset, priv->cmd_size);
> +
> +		memcpy_toio(priv->cmd, buf + offset, chunk_size);
> +		offset += chunk_size;
> +
> +		/* Make sure that cmd is populated before issuing start. */
> +		wmb();
> +		if (offset < len) {
> +			rc = crb_trigger_tpm(chip, CRB_START_NEXT_CHUNK);
> +			if (rc)
> +				return rc;
> +			if (!crb_wait_for_reg_32(&priv->regs_t->ctrl_start,
> +			    CRB_START_NEXT_CHUNK, 0, TPM2_TIMEOUT_C)) {
> +				dev_err(&chip->dev,
> +					"Timeout waiting for backend to consume chunk\n");
> +				return -ETIME;
> +			}
> +		} else {
> +			rc = crb_trigger_tpm(chip, CRB_START_INVOKE);
> +			if (rc)
> +				return rc;
> +		}
> +	}
> +	return crb_try_pluton_doorbell(priv, false);
> +}
>  
> -	/* Make sure that cmd is populated before issuing start. */
> -	wmb();
> +static int crb_recv(struct tpm_chip *chip, u8 *buf, size_t count)
> +{
> +	struct crb_priv *priv = dev_get_drvdata(&chip->dev);
> +	unsigned int expected;
> +	size_t offset = 0;
> +	size_t chunk_size;
> +	size_t first_read;
> +	int rc;
>  
> -	rc = crb_trigger_tpm(chip, CRB_START_INVOKE);
> -	if (rc)
> -		return rc;
> +	/* A sanity check that the upper layer wants to get at least the header
> +	 * as that is the minimum size for any TPM response.
> +	 */
> +	if (count < TPM_HEADER_SIZE)
> +		return -EIO;
>  
> -	return crb_try_pluton_doorbell(priv, false);
> +	/* If this bit is set, according to the spec, the TPM is in
> +	 * unrecoverable condition.
> +	 */
> +	if (ioread32(&priv->regs_t->ctrl_sts) & CRB_CTRL_STS_ERROR)
> +		return -EIO;
> +
> +	/* Read the first 8 bytes in order to get the length of the response.
> +	 * We read exactly a quad word in order to make sure that the remaining
> +	 * reads will be aligned.
> +	 */
> +	memcpy_fromio(buf, priv->rsp, 8);
> +
> +	expected = be32_to_cpup((__be32 *)&buf[2]);
> +	if (expected > count || expected < TPM_HEADER_SIZE)
> +		return -EIO;
> +
> +	/*
> +	 * Set chunk_size by comparing the size of the buffer that the upper layer has
> +	 * allocated (count) to the hardware tpm limit (priv->rsp_size).
> +	 * This is to prevent buffer overflow while writing to buf.
> +	 */
> +	chunk_size = min_t(size_t, count, priv->rsp_size);
> +
> +	/*
> +	 * Compare the actual size of the response we found in the header to the chunk_size.
> +	 */
> +	first_read = min_t(size_t, expected, chunk_size);
> +
> +	memcpy_fromio(&buf[8], &priv->rsp[8], first_read - 8);
> +	offset = first_read;
> +
> +	while (offset < expected) {
> +		if (!priv->chunking_supported) {
> +			dev_err(&chip->dev, "Response larger than MMIO and chunking not supported\n");
> +			return -EIO;
> +		}
> +
> +		rc = crb_trigger_tpm(chip, CRB_START_NEXT_CHUNK);
> +		if (rc)
> +			return rc;
> +
> +		if (!crb_wait_for_reg_32(&priv->regs_t->ctrl_start,
> +					 CRB_START_NEXT_CHUNK, 0, TPM2_TIMEOUT_C)) {
> +			dev_err(&chip->dev, "Timeout waiting for backend response\n");
> +			return -ETIME;
> +		}
> +
> +		chunk_size = min_t(size_t, expected - offset, priv->rsp_size);
> +		memcpy_fromio(buf + offset, priv->rsp, chunk_size);
> +		offset += chunk_size;
> +	}
> +
> +	return expected;
>  }
>  
>  static void crb_cancel(struct tpm_chip *chip)
> @@ -727,6 +784,15 @@ static int crb_map_io(struct acpi_device *device, struct crb_priv *priv,
>  		goto out;
>  	}
>  
> +	if (priv->regs_h) {
> +		u32 intf_id = ioread32((u32 __iomem *)&priv->regs_h->intf_id);
> +
> +		if (intf_id & CRB_INTF_CAP_CRB_CHUNK) {
> +			priv->chunking_supported = true;
> +			dev_info(dev, "CRB Chunking is supported by backend\n");
> +		}
> +	}
> +
>  	memcpy_fromio(&__rsp_pa, &priv->regs_t->ctrl_rsp_pa, 8);
>  	rsp_pa = le64_to_cpu(__rsp_pa);
>  	rsp_size = ioread32(&priv->regs_t->ctrl_rsp_size);
> @@ -764,8 +830,10 @@ static int crb_map_io(struct acpi_device *device, struct crb_priv *priv,
>  	priv->rsp = priv->cmd;
>  
>  out:
> -	if (!ret)
> +	if (!ret) {
>  		priv->cmd_size = cmd_size;
> +		priv->rsp_size = rsp_size;
> +	}
>  
>  	__crb_go_idle(dev, priv, 0);
>  
> -- 
> 2.53.0
> 

BR, Jarkko

Re: [RFC 3/4] tpm_crb: Implement command and response chunking logic

[Arun Menon]

On Tue, Mar 24, 2026 at 12:45:29PM +0200, Jarkko Sakkinen wrote:
> On Tue, Mar 24, 2026 at 12:48:02PM +0530, Arun Menon wrote:
> > Add support for sending and receiving TPM command data in chunks when
> > the payload exceeds the physical size of the hardware MMIO window.
> > 
> > This introduces the following changes:
> > 
> > - crb_map_io(): Checks the device interface capability to determine if
> >   chunking is supported, setting the chunking_supported flag. It also
> >   stores the hardware's maximum response buffer size in priv->rsp_size.
> > - crb_send(): Iteratively writes command chunks to the fixed priv->cmd
> >   MMIO window. It signals the TPM backend to process intermediate chunks
> >   using CRB_START_NEXT_CHUNK, and signals the final chunk to begin
> >   execution using CRB_START_INVOKE.
> > - crb_recv(): Parses the expected response size from the initial TPM
> >   header. It then iteratively reads chunks from the fixed priv->rsp
> >   MMIO window into the destination buffer, advancing the buffer offset
> >   until the complete response is retrieved.
> > 
> > Signed-off-by: Arun Menon <armenon@redhat.com>
> 
> This is also just description of wha this adds. I'd lessen the detail
> and write a description that describes motivation and logic of the
> change. It's a good test for author knowledge, as if you really get
> the topic you can explain its gist. In addition, it can be reflected
> to implementation (vs. the descriptions that are pseudocode in English)

Sure, I will replace the commit message with motivation+logic instead of
explaining the code step by step.

> 
> Since this RFC and QEMU does not have the feature in release it is
> good to polish stuff like this.
> 
> > ---
> >  drivers/char/tpm/tpm_crb.c | 150 +++++++++++++++++++++++++++----------
> >  1 file changed, 109 insertions(+), 41 deletions(-)
> > 
> > diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c
> > index 10128d078245c..fb63cc3737253 100644
> > --- a/drivers/char/tpm/tpm_crb.c
> > +++ b/drivers/char/tpm/tpm_crb.c
> > @@ -104,11 +104,13 @@ struct crb_priv {
> >  	u8 __iomem *cmd;
> >  	u8 __iomem *rsp;
> >  	u32 cmd_size;
> > +	u32 rsp_size;
> >  	u32 smc_func_id;
> >  	u32 __iomem *pluton_start_addr;
> >  	u32 __iomem *pluton_reply_addr;
> >  	u8 ffa_flags;
> >  	u8 ffa_attributes;
> > +	bool chunking_supported;
> >  };
> >  
> >  struct tpm2_crb_smc {
> > @@ -368,38 +370,6 @@ static u8 crb_status(struct tpm_chip *chip)
> >  	return sts;
> >  }
> >  
> > -static int crb_recv(struct tpm_chip *chip, u8 *buf, size_t count)
> > -{
> > -	struct crb_priv *priv = dev_get_drvdata(&chip->dev);
> > -	unsigned int expected;
> > -
> > -	/* A sanity check that the upper layer wants to get at least the header
> > -	 * as that is the minimum size for any TPM response.
> > -	 */
> > -	if (count < TPM_HEADER_SIZE)
> > -		return -EIO;
> > -
> > -	/* If this bit is set, according to the spec, the TPM is in
> > -	 * unrecoverable condition.
> > -	 */
> > -	if (ioread32(&priv->regs_t->ctrl_sts) & CRB_CTRL_STS_ERROR)
> > -		return -EIO;
> > -
> > -	/* Read the first 8 bytes in order to get the length of the response.
> > -	 * We read exactly a quad word in order to make sure that the remaining
> > -	 * reads will be aligned.
> > -	 */
> > -	memcpy_fromio(buf, priv->rsp, 8);
> > -
> > -	expected = be32_to_cpup((__be32 *)&buf[2]);
> > -	if (expected > count || expected < TPM_HEADER_SIZE)
> > -		return -EIO;
> > -
> > -	memcpy_fromio(&buf[8], &priv->rsp[8], expected - 8);
> > -
> > -	return expected;
> > -}
> > -
> >  static int crb_do_acpi_start(struct tpm_chip *chip)
> >  {
> >  	union acpi_object *obj;
> > @@ -474,6 +444,8 @@ static int crb_trigger_tpm(struct tpm_chip *chip, u32 start_cmd)
> >  static int crb_send(struct tpm_chip *chip, u8 *buf, size_t bufsiz, size_t len)
> >  {
> >  	struct crb_priv *priv = dev_get_drvdata(&chip->dev);
> > +	size_t offset = 0;
> > +	size_t chunk_size;
> >  	int rc = 0;
> >  
> >  	/* Zero the cancel register so that the next command will not get
> > @@ -481,7 +453,7 @@ static int crb_send(struct tpm_chip *chip, u8 *buf, size_t bufsiz, size_t len)
> >  	 */
> >  	iowrite32(0, &priv->regs_t->ctrl_cancel);
> >  
> > -	if (len > priv->cmd_size) {
> > +	if (len > priv->cmd_size && !priv->chunking_supported) {
> >  		dev_err(&chip->dev, "invalid command count value %zd %d\n",
> >  			len, priv->cmd_size);
> >  		return -E2BIG;
> > @@ -491,16 +463,101 @@ static int crb_send(struct tpm_chip *chip, u8 *buf, size_t bufsiz, size_t len)
> >  	if (priv->sm == ACPI_TPM2_COMMAND_BUFFER_WITH_PLUTON)
> >  		__crb_cmd_ready(&chip->dev, priv, chip->locality);
> >  
> > -	memcpy_toio(priv->cmd, buf, len);
> > +	while (offset < len) {
> > +		chunk_size = min_t(size_t, len - offset, priv->cmd_size);
> > +
> > +		memcpy_toio(priv->cmd, buf + offset, chunk_size);
> > +		offset += chunk_size;
> > +
> > +		/* Make sure that cmd is populated before issuing start. */
> > +		wmb();
> > +		if (offset < len) {
> > +			rc = crb_trigger_tpm(chip, CRB_START_NEXT_CHUNK);
> > +			if (rc)
> > +				return rc;
> > +			if (!crb_wait_for_reg_32(&priv->regs_t->ctrl_start,
> > +			    CRB_START_NEXT_CHUNK, 0, TPM2_TIMEOUT_C)) {
> > +				dev_err(&chip->dev,
> > +					"Timeout waiting for backend to consume chunk\n");
> > +				return -ETIME;
> > +			}
> > +		} else {
> > +			rc = crb_trigger_tpm(chip, CRB_START_INVOKE);
> > +			if (rc)
> > +				return rc;
> > +		}
> > +	}
> > +	return crb_try_pluton_doorbell(priv, false);
> > +}
> >  
> > -	/* Make sure that cmd is populated before issuing start. */
> > -	wmb();
> > +static int crb_recv(struct tpm_chip *chip, u8 *buf, size_t count)
> > +{
> > +	struct crb_priv *priv = dev_get_drvdata(&chip->dev);
> > +	unsigned int expected;
> > +	size_t offset = 0;
> > +	size_t chunk_size;
> > +	size_t first_read;
> > +	int rc;
> >  
> > -	rc = crb_trigger_tpm(chip, CRB_START_INVOKE);
> > -	if (rc)
> > -		return rc;
> > +	/* A sanity check that the upper layer wants to get at least the header
> > +	 * as that is the minimum size for any TPM response.
> > +	 */
> > +	if (count < TPM_HEADER_SIZE)
> > +		return -EIO;
> >  
> > -	return crb_try_pluton_doorbell(priv, false);
> > +	/* If this bit is set, according to the spec, the TPM is in
> > +	 * unrecoverable condition.
> > +	 */
> > +	if (ioread32(&priv->regs_t->ctrl_sts) & CRB_CTRL_STS_ERROR)
> > +		return -EIO;
> > +
> > +	/* Read the first 8 bytes in order to get the length of the response.
> > +	 * We read exactly a quad word in order to make sure that the remaining
> > +	 * reads will be aligned.
> > +	 */
> > +	memcpy_fromio(buf, priv->rsp, 8);
> > +
> > +	expected = be32_to_cpup((__be32 *)&buf[2]);
> > +	if (expected > count || expected < TPM_HEADER_SIZE)
> > +		return -EIO;
> > +
> > +	/*
> > +	 * Set chunk_size by comparing the size of the buffer that the upper layer has
> > +	 * allocated (count) to the hardware tpm limit (priv->rsp_size).
> > +	 * This is to prevent buffer overflow while writing to buf.
> > +	 */
> > +	chunk_size = min_t(size_t, count, priv->rsp_size);
> > +
> > +	/*
> > +	 * Compare the actual size of the response we found in the header to the chunk_size.
> > +	 */
> > +	first_read = min_t(size_t, expected, chunk_size);
> > +
> > +	memcpy_fromio(&buf[8], &priv->rsp[8], first_read - 8);
> > +	offset = first_read;
> > +
> > +	while (offset < expected) {
> > +		if (!priv->chunking_supported) {
> > +			dev_err(&chip->dev, "Response larger than MMIO and chunking not supported\n");
> > +			return -EIO;
> > +		}
> > +
> > +		rc = crb_trigger_tpm(chip, CRB_START_NEXT_CHUNK);
> > +		if (rc)
> > +			return rc;
> > +
> > +		if (!crb_wait_for_reg_32(&priv->regs_t->ctrl_start,
> > +					 CRB_START_NEXT_CHUNK, 0, TPM2_TIMEOUT_C)) {
> > +			dev_err(&chip->dev, "Timeout waiting for backend response\n");
> > +			return -ETIME;
> > +		}
> > +
> > +		chunk_size = min_t(size_t, expected - offset, priv->rsp_size);
> > +		memcpy_fromio(buf + offset, priv->rsp, chunk_size);
> > +		offset += chunk_size;
> > +	}
> > +
> > +	return expected;
> >  }
> >  
> >  static void crb_cancel(struct tpm_chip *chip)
> > @@ -727,6 +784,15 @@ static int crb_map_io(struct acpi_device *device, struct crb_priv *priv,
> >  		goto out;
> >  	}
> >  
> > +	if (priv->regs_h) {
> > +		u32 intf_id = ioread32((u32 __iomem *)&priv->regs_h->intf_id);
> > +
> > +		if (intf_id & CRB_INTF_CAP_CRB_CHUNK) {
> > +			priv->chunking_supported = true;
> > +			dev_info(dev, "CRB Chunking is supported by backend\n");
> > +		}
> > +	}
> > +
> >  	memcpy_fromio(&__rsp_pa, &priv->regs_t->ctrl_rsp_pa, 8);
> >  	rsp_pa = le64_to_cpu(__rsp_pa);
> >  	rsp_size = ioread32(&priv->regs_t->ctrl_rsp_size);
> > @@ -764,8 +830,10 @@ static int crb_map_io(struct acpi_device *device, struct crb_priv *priv,
> >  	priv->rsp = priv->cmd;
> >  
> >  out:
> > -	if (!ret)
> > +	if (!ret) {
> >  		priv->cmd_size = cmd_size;
> > +		priv->rsp_size = rsp_size;
> > +	}
> >  
> >  	__crb_go_idle(dev, priv, 0);
> >  
> > -- 
> > 2.53.0
> > 
> 
> BR, Jarkko
> 

Regards,
Arun Menon

[RFC 4/4] tpm: Increase TPM_BUFSIZE to 64kB for chunking support

[Arun Menon]

- In tpm_common_write() the size of the command is checked against
  TPM_BUFSIZE. We therefore need to increase the TPM_BUFSIZE to allow
  support for larger commands.

Signed-off-by: Arun Menon <armenon@redhat.com>
---
 drivers/char/tpm/tpm.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
index 87d68ddf270a7..a6933eb075296 100644
--- a/drivers/char/tpm/tpm.h
+++ b/drivers/char/tpm/tpm.h
@@ -33,7 +33,7 @@
 #endif
 
 #define TPM_MINOR		224	/* officially assigned */
-#define TPM_BUFSIZE		4096
+#define TPM_BUFSIZE		65536
 #define TPM_NUM_DEVICES		65536
 #define TPM_RETRY		50
 
-- 
2.53.0

Re: [RFC 0/4] tpm_crb: Add command and response buffer chunking support

[Jarkko Sakkinen]

On Tue, Mar 24, 2026 at 12:47:59PM +0530, Arun Menon wrote:
> The new version of TCG TPM v185 (currently under review [1]) supports
> sending data/commands in chunks for the CRB (Command Response Buffer)
> interface. This is in line with the initiative to support PQC algorithms.
> 
> This series implements the logic to send and receive larger TPM
> cmd/rsp between the linux guest and the TPM backend in chunks.
> Currently, the TPM CRB driver is limited by the physical size of the
> MMIO window. When userspace attempts to send a payload that exceeds this
> size, the driver rejects it.
> 
> This series introduces chunking support. The driver now checks the CRB
> interface capability for CRB_INTF_CAP_CRB_CHUNK. If supported by the
> backend, the driver will slice oversized commands into MMIO-sized
> chunks, signalling the backend via CRB_START_NEXT_CHUNK, and finalizing
> with CRB_START_INVOKE. Responses are also read back in a similar chunked
> manner.
> 
> If the backend does not support chunking, the driver retains its legacy
> behaviour and enforces the standard size limits.
> 
> This feature also requires the QEMU to interpret the data in chunks and
> forward it to the TPM backend and subsequently dispatch the TPM response
> in chunks back to the linux guest. This is implemented in [2]
> 
> [1] https://trustedcomputinggroup.org/wp-content/uploads/PC-Client-Specific-Platform-TPM-Profile-for-TPM-2p0-v1p07_rc1_121225.pdf
> [2] https://lore.kernel.org/qemu-devel/20260319135316.37412-1-armenon@redhat.com/
> 
> Arun Menon (4):
>   tpm_crb: Add definition of TPM CRB chunking fields
>   tpm_crb: Add new wrapper function to invoke start method
>   tpm_crb: Implement command and response chunking logic
>   tpm: Increase TPM_BUFSIZE to 64kB for chunking support
> 
>  drivers/char/tpm/tpm.h     |   2 +-
>  drivers/char/tpm/tpm_crb.c | 194 ++++++++++++++++++++++++++-----------
>  2 files changed, 137 insertions(+), 59 deletions(-)
> 
> -- 
> 2.53.0
> 

When QEMU has the feature available?

BR, Jarkko

Re: [RFC 0/4] tpm_crb: Add command and response buffer chunking support

[Arun Menon]

Hi Jarkko,

On Tue, Mar 24, 2026 at 12:41:26PM +0200, Jarkko Sakkinen wrote:
> On Tue, Mar 24, 2026 at 12:47:59PM +0530, Arun Menon wrote:
> > The new version of TCG TPM v185 (currently under review [1]) supports
> > sending data/commands in chunks for the CRB (Command Response Buffer)
> > interface. This is in line with the initiative to support PQC algorithms.
> > 
> > This series implements the logic to send and receive larger TPM
> > cmd/rsp between the linux guest and the TPM backend in chunks.
> > Currently, the TPM CRB driver is limited by the physical size of the
> > MMIO window. When userspace attempts to send a payload that exceeds this
> > size, the driver rejects it.
> > 
> > This series introduces chunking support. The driver now checks the CRB
> > interface capability for CRB_INTF_CAP_CRB_CHUNK. If supported by the
> > backend, the driver will slice oversized commands into MMIO-sized
> > chunks, signalling the backend via CRB_START_NEXT_CHUNK, and finalizing
> > with CRB_START_INVOKE. Responses are also read back in a similar chunked
> > manner.
> > 
> > If the backend does not support chunking, the driver retains its legacy
> > behaviour and enforces the standard size limits.
> > 
> > This feature also requires the QEMU to interpret the data in chunks and
> > forward it to the TPM backend and subsequently dispatch the TPM response
> > in chunks back to the linux guest. This is implemented in [2]
> > 
> > [1] https://trustedcomputinggroup.org/wp-content/uploads/PC-Client-Specific-Platform-TPM-Profile-for-TPM-2p0-v1p07_rc1_121225.pdf
> > [2] https://lore.kernel.org/qemu-devel/20260319135316.37412-1-armenon@redhat.com/
> > 
> > Arun Menon (4):
> >   tpm_crb: Add definition of TPM CRB chunking fields
> >   tpm_crb: Add new wrapper function to invoke start method
> >   tpm_crb: Implement command and response chunking logic
> >   tpm: Increase TPM_BUFSIZE to 64kB for chunking support
> > 
> >  drivers/char/tpm/tpm.h     |   2 +-
> >  drivers/char/tpm/tpm_crb.c | 194 ++++++++++++++++++++++++++-----------
> >  2 files changed, 137 insertions(+), 59 deletions(-)
> > 
> > -- 
> > 2.53.0
> > 
> 
> When QEMU has the feature available?

The QEMU patches are in review at the moment,
here is the link: https://lore.kernel.org/qemu-devel/20260319135316.37412-1-armenon@redhat.com/
Hoping to have them merged soon.

> 
> BR, Jarkko
> 

Regards,
Arun Menon

Re: [RFC 0/4] tpm_crb: Add command and response buffer chunking support

[Jarkko Sakkinen]

On Tue, Mar 24, 2026 at 06:11:11PM +0530, Arun Menon wrote:
> Hi Jarkko,
> 
> On Tue, Mar 24, 2026 at 12:41:26PM +0200, Jarkko Sakkinen wrote:
> > On Tue, Mar 24, 2026 at 12:47:59PM +0530, Arun Menon wrote:
> > > The new version of TCG TPM v185 (currently under review [1]) supports
> > > sending data/commands in chunks for the CRB (Command Response Buffer)
> > > interface. This is in line with the initiative to support PQC algorithms.
> > > 
> > > This series implements the logic to send and receive larger TPM
> > > cmd/rsp between the linux guest and the TPM backend in chunks.
> > > Currently, the TPM CRB driver is limited by the physical size of the
> > > MMIO window. When userspace attempts to send a payload that exceeds this
> > > size, the driver rejects it.
> > > 
> > > This series introduces chunking support. The driver now checks the CRB
> > > interface capability for CRB_INTF_CAP_CRB_CHUNK. If supported by the
> > > backend, the driver will slice oversized commands into MMIO-sized
> > > chunks, signalling the backend via CRB_START_NEXT_CHUNK, and finalizing
> > > with CRB_START_INVOKE. Responses are also read back in a similar chunked
> > > manner.
> > > 
> > > If the backend does not support chunking, the driver retains its legacy
> > > behaviour and enforces the standard size limits.
> > > 
> > > This feature also requires the QEMU to interpret the data in chunks and
> > > forward it to the TPM backend and subsequently dispatch the TPM response
> > > in chunks back to the linux guest. This is implemented in [2]
> > > 
> > > [1] https://trustedcomputinggroup.org/wp-content/uploads/PC-Client-Specific-Platform-TPM-Profile-for-TPM-2p0-v1p07_rc1_121225.pdf
> > > [2] https://lore.kernel.org/qemu-devel/20260319135316.37412-1-armenon@redhat.com/
> > > 
> > > Arun Menon (4):
> > >   tpm_crb: Add definition of TPM CRB chunking fields
> > >   tpm_crb: Add new wrapper function to invoke start method
> > >   tpm_crb: Implement command and response chunking logic
> > >   tpm: Increase TPM_BUFSIZE to 64kB for chunking support
> > > 
> > >  drivers/char/tpm/tpm.h     |   2 +-
> > >  drivers/char/tpm/tpm_crb.c | 194 ++++++++++++++++++++++++++-----------
> > >  2 files changed, 137 insertions(+), 59 deletions(-)
> > > 
> > > -- 
> > > 2.53.0
> > > 
> > 
> > When QEMU has the feature available?
> 
> The QEMU patches are in review at the moment,
> here is the link: https://lore.kernel.org/qemu-devel/20260319135316.37412-1-armenon@redhat.com/
> Hoping to have them merged soon.

Right, and additional question: what about swtpm?

For both, to give detailed review, good enough is their main branch
(i.e. as long as upstream accepts them I can use them).

> 
> > 
> > BR, Jarkko
> > 
> 
> Regards,
> Arun Menon
> 

BR, Jarkko

Re: [RFC 0/4] tpm_crb: Add command and response buffer chunking support

[Arun Menon]

On Wed, Apr 08, 2026 at 11:34:54AM +0300, Jarkko Sakkinen wrote:
> On Tue, Mar 24, 2026 at 06:11:11PM +0530, Arun Menon wrote:
> > Hi Jarkko,
> > 
> > On Tue, Mar 24, 2026 at 12:41:26PM +0200, Jarkko Sakkinen wrote:
> > > On Tue, Mar 24, 2026 at 12:47:59PM +0530, Arun Menon wrote:
> > > > The new version of TCG TPM v185 (currently under review [1]) supports
> > > > sending data/commands in chunks for the CRB (Command Response Buffer)
> > > > interface. This is in line with the initiative to support PQC algorithms.
> > > > 
> > > > This series implements the logic to send and receive larger TPM
> > > > cmd/rsp between the linux guest and the TPM backend in chunks.
> > > > Currently, the TPM CRB driver is limited by the physical size of the
> > > > MMIO window. When userspace attempts to send a payload that exceeds this
> > > > size, the driver rejects it.
> > > > 
> > > > This series introduces chunking support. The driver now checks the CRB
> > > > interface capability for CRB_INTF_CAP_CRB_CHUNK. If supported by the
> > > > backend, the driver will slice oversized commands into MMIO-sized
> > > > chunks, signalling the backend via CRB_START_NEXT_CHUNK, and finalizing
> > > > with CRB_START_INVOKE. Responses are also read back in a similar chunked
> > > > manner.
> > > > 
> > > > If the backend does not support chunking, the driver retains its legacy
> > > > behaviour and enforces the standard size limits.
> > > > 
> > > > This feature also requires the QEMU to interpret the data in chunks and
> > > > forward it to the TPM backend and subsequently dispatch the TPM response
> > > > in chunks back to the linux guest. This is implemented in [2]
> > > > 
> > > > [1] https://trustedcomputinggroup.org/wp-content/uploads/PC-Client-Specific-Platform-TPM-Profile-for-TPM-2p0-v1p07_rc1_121225.pdf
> > > > [2] https://lore.kernel.org/qemu-devel/20260319135316.37412-1-armenon@redhat.com/
> > > > 
> > > > Arun Menon (4):
> > > >   tpm_crb: Add definition of TPM CRB chunking fields
> > > >   tpm_crb: Add new wrapper function to invoke start method
> > > >   tpm_crb: Implement command and response chunking logic
> > > >   tpm: Increase TPM_BUFSIZE to 64kB for chunking support
> > > > 
> > > >  drivers/char/tpm/tpm.h     |   2 +-
> > > >  drivers/char/tpm/tpm_crb.c | 194 ++++++++++++++++++++++++++-----------
> > > >  2 files changed, 137 insertions(+), 59 deletions(-)
> > > > 
> > > > -- 
> > > > 2.53.0
> > > > 
> > > 
> > > When QEMU has the feature available?
> > 
> > The QEMU patches are in review at the moment,
> > here is the link: https://lore.kernel.org/qemu-devel/20260319135316.37412-1-armenon@redhat.com/
> > Hoping to have them merged soon.
> 
> Right, and additional question: what about swtpm?

Hi Jarkko,

Apologies for the delay in following up.
Regarding your question about swtpm, I’ve looped in Stefan Berger who 
should be able to provide more technical context on that front.

I also wanted to gently point you toward the latest revision of this
series v2, as I’ve addressed some feedback since our last exchange.
latest : https://lore.kernel.org/lkml/20260324181244.17741-1-armenon@redhat.com/

I’ve been working on the QEMU integration side in the meantime to ensure
the end-to-end flow is solid.
qemu link : https://lore.kernel.org/qemu-devel/20260422103018.123608-1-armenon@redhat.com/

I look forward to your feedback when time permits.

> 
> For both, to give detailed review, good enough is their main branch
> (i.e. as long as upstream accepts them I can use them).
> 
> > 
> > > 
> > > BR, Jarkko
> > > 
> > 
> > Regards,
> > Arun Menon
> > 
> 
> BR, Jarkko

Regards,
Arun Menon

Re: [RFC 0/4] tpm_crb: Add command and response buffer chunking support

[Jarkko Sakkinen]

On Thu, Apr 23, 2026 at 04:13:27PM +0530, Arun Menon wrote:
> On Wed, Apr 08, 2026 at 11:34:54AM +0300, Jarkko Sakkinen wrote:
> > On Tue, Mar 24, 2026 at 06:11:11PM +0530, Arun Menon wrote:
> > > Hi Jarkko,
> > > 
> > > On Tue, Mar 24, 2026 at 12:41:26PM +0200, Jarkko Sakkinen wrote:
> > > > On Tue, Mar 24, 2026 at 12:47:59PM +0530, Arun Menon wrote:
> > > > > The new version of TCG TPM v185 (currently under review [1]) supports
> > > > > sending data/commands in chunks for the CRB (Command Response Buffer)
> > > > > interface. This is in line with the initiative to support PQC algorithms.
> > > > > 
> > > > > This series implements the logic to send and receive larger TPM
> > > > > cmd/rsp between the linux guest and the TPM backend in chunks.
> > > > > Currently, the TPM CRB driver is limited by the physical size of the
> > > > > MMIO window. When userspace attempts to send a payload that exceeds this
> > > > > size, the driver rejects it.
> > > > > 
> > > > > This series introduces chunking support. The driver now checks the CRB
> > > > > interface capability for CRB_INTF_CAP_CRB_CHUNK. If supported by the
> > > > > backend, the driver will slice oversized commands into MMIO-sized
> > > > > chunks, signalling the backend via CRB_START_NEXT_CHUNK, and finalizing
> > > > > with CRB_START_INVOKE. Responses are also read back in a similar chunked
> > > > > manner.
> > > > > 
> > > > > If the backend does not support chunking, the driver retains its legacy
> > > > > behaviour and enforces the standard size limits.
> > > > > 
> > > > > This feature also requires the QEMU to interpret the data in chunks and
> > > > > forward it to the TPM backend and subsequently dispatch the TPM response
> > > > > in chunks back to the linux guest. This is implemented in [2]
> > > > > 
> > > > > [1] https://trustedcomputinggroup.org/wp-content/uploads/PC-Client-Specific-Platform-TPM-Profile-for-TPM-2p0-v1p07_rc1_121225.pdf
> > > > > [2] https://lore.kernel.org/qemu-devel/20260319135316.37412-1-armenon@redhat.com/
> > > > > 
> > > > > Arun Menon (4):
> > > > >   tpm_crb: Add definition of TPM CRB chunking fields
> > > > >   tpm_crb: Add new wrapper function to invoke start method
> > > > >   tpm_crb: Implement command and response chunking logic
> > > > >   tpm: Increase TPM_BUFSIZE to 64kB for chunking support
> > > > > 
> > > > >  drivers/char/tpm/tpm.h     |   2 +-
> > > > >  drivers/char/tpm/tpm_crb.c | 194 ++++++++++++++++++++++++++-----------
> > > > >  2 files changed, 137 insertions(+), 59 deletions(-)
> > > > > 
> > > > > -- 
> > > > > 2.53.0
> > > > > 
> > > > 
> > > > When QEMU has the feature available?
> > > 
> > > The QEMU patches are in review at the moment,
> > > here is the link: https://lore.kernel.org/qemu-devel/20260319135316.37412-1-armenon@redhat.com/
> > > Hoping to have them merged soon.
> > 
> > Right, and additional question: what about swtpm?
> 
> Hi Jarkko,
> 
> Apologies for the delay in following up.
> Regarding your question about swtpm, I’ve looped in Stefan Berger who 
> should be able to provide more technical context on that front.
> 
> I also wanted to gently point you toward the latest revision of this
> series v2, as I’ve addressed some feedback since our last exchange.
> latest : https://lore.kernel.org/lkml/20260324181244.17741-1-armenon@redhat.com/
> 
> I’ve been working on the QEMU integration side in the meantime to ensure
> the end-to-end flow is solid.
> qemu link : https://lore.kernel.org/qemu-devel/20260422103018.123608-1-armenon@redhat.com/
> 
> I look forward to your feedback when time permits.

Thanks I'll move this to my TODO folder for detailed look. I'm
right now travelling in Hungary but will look in detail next
week.

BR, Jarkko

Re: [RFC 0/4] tpm_crb: Add command and response buffer chunking support

[Stefan Berger]

On 4/23/26 6:43 AM, Arun Menon wrote:
> On Wed, Apr 08, 2026 at 11:34:54AM +0300, Jarkko Sakkinen wrote:
>> On Tue, Mar 24, 2026 at 06:11:11PM +0530, Arun Menon wrote:
>>> Hi Jarkko,
>>>
>>> On Tue, Mar 24, 2026 at 12:41:26PM +0200, Jarkko Sakkinen wrote:
>>>> On Tue, Mar 24, 2026 at 12:47:59PM +0530, Arun Menon wrote:
>>>>> The new version of TCG TPM v185 (currently under review [1]) supports
>>>>> sending data/commands in chunks for the CRB (Command Response Buffer)
>>>>> interface. This is in line with the initiative to support PQC algorithms.
>>>>>
>>>>> This series implements the logic to send and receive larger TPM
>>>>> cmd/rsp between the linux guest and the TPM backend in chunks.
>>>>> Currently, the TPM CRB driver is limited by the physical size of the
>>>>> MMIO window. When userspace attempts to send a payload that exceeds this
>>>>> size, the driver rejects it.
>>>>>
>>>>> This series introduces chunking support. The driver now checks the CRB
>>>>> interface capability for CRB_INTF_CAP_CRB_CHUNK. If supported by the
>>>>> backend, the driver will slice oversized commands into MMIO-sized
>>>>> chunks, signalling the backend via CRB_START_NEXT_CHUNK, and finalizing
>>>>> with CRB_START_INVOKE. Responses are also read back in a similar chunked
>>>>> manner.
>>>>>
>>>>> If the backend does not support chunking, the driver retains its legacy
>>>>> behaviour and enforces the standard size limits.
>>>>>
>>>>> This feature also requires the QEMU to interpret the data in chunks and
>>>>> forward it to the TPM backend and subsequently dispatch the TPM response
>>>>> in chunks back to the linux guest. This is implemented in [2]
>>>>>
>>>>> [1] https://trustedcomputinggroup.org/wp-content/uploads/PC-Client-Specific-Platform-TPM-Profile-for-TPM-2p0-v1p07_rc1_121225.pdf
>>>>> [2] https://lore.kernel.org/qemu-devel/20260319135316.37412-1-armenon@redhat.com/
>>>>>
>>>>> Arun Menon (4):
>>>>>    tpm_crb: Add definition of TPM CRB chunking fields
>>>>>    tpm_crb: Add new wrapper function to invoke start method
>>>>>    tpm_crb: Implement command and response chunking logic
>>>>>    tpm: Increase TPM_BUFSIZE to 64kB for chunking support

64kb? I am only increasing the TPM buffer to 8kb. More does not seem to 
be necessary.

>>>>>
>>>>>   drivers/char/tpm/tpm.h     |   2 +-
>>>>>   drivers/char/tpm/tpm_crb.c | 194 ++++++++++++++++++++++++++-----------
>>>>>   2 files changed, 137 insertions(+), 59 deletions(-)
>>>>>
>>>>> -- 
>>>>> 2.53.0
>>>>>
>>>>
>>>> When QEMU has the feature available?
>>>
>>> The QEMU patches are in review at the moment,
>>> here is the link: https://lore.kernel.org/qemu-devel/20260319135316.37412-1-armenon@redhat.com/
>>> Hoping to have them merged soon.
>>
>> Right, and additional question: what about swtpm?

I am waiting for https://github.com/trustedComputingGroup/tpm to show 
rev185 with PQC support so that I can merge my patches based on 'their' 
PQC support into the public libtpms repo.

Re: [RFC 0/4] tpm_crb: Add command and response buffer chunking support

[Jarkko Sakkinen]

On Fri, Apr 24, 2026 at 04:54:03PM -0400, Stefan Berger wrote:
> 
> 
> On 4/23/26 6:43 AM, Arun Menon wrote:
> > On Wed, Apr 08, 2026 at 11:34:54AM +0300, Jarkko Sakkinen wrote:
> > > On Tue, Mar 24, 2026 at 06:11:11PM +0530, Arun Menon wrote:
> > > > Hi Jarkko,
> > > > 
> > > > On Tue, Mar 24, 2026 at 12:41:26PM +0200, Jarkko Sakkinen wrote:
> > > > > On Tue, Mar 24, 2026 at 12:47:59PM +0530, Arun Menon wrote:
> > > > > > The new version of TCG TPM v185 (currently under review [1]) supports
> > > > > > sending data/commands in chunks for the CRB (Command Response Buffer)
> > > > > > interface. This is in line with the initiative to support PQC algorithms.
> > > > > > 
> > > > > > This series implements the logic to send and receive larger TPM
> > > > > > cmd/rsp between the linux guest and the TPM backend in chunks.
> > > > > > Currently, the TPM CRB driver is limited by the physical size of the
> > > > > > MMIO window. When userspace attempts to send a payload that exceeds this
> > > > > > size, the driver rejects it.
> > > > > > 
> > > > > > This series introduces chunking support. The driver now checks the CRB
> > > > > > interface capability for CRB_INTF_CAP_CRB_CHUNK. If supported by the
> > > > > > backend, the driver will slice oversized commands into MMIO-sized
> > > > > > chunks, signalling the backend via CRB_START_NEXT_CHUNK, and finalizing
> > > > > > with CRB_START_INVOKE. Responses are also read back in a similar chunked
> > > > > > manner.
> > > > > > 
> > > > > > If the backend does not support chunking, the driver retains its legacy
> > > > > > behaviour and enforces the standard size limits.
> > > > > > 
> > > > > > This feature also requires the QEMU to interpret the data in chunks and
> > > > > > forward it to the TPM backend and subsequently dispatch the TPM response
> > > > > > in chunks back to the linux guest. This is implemented in [2]
> > > > > > 
> > > > > > [1] https://trustedcomputinggroup.org/wp-content/uploads/PC-Client-Specific-Platform-TPM-Profile-for-TPM-2p0-v1p07_rc1_121225.pdf
> > > > > > [2] https://lore.kernel.org/qemu-devel/20260319135316.37412-1-armenon@redhat.com/
> > > > > > 
> > > > > > Arun Menon (4):
> > > > > >    tpm_crb: Add definition of TPM CRB chunking fields
> > > > > >    tpm_crb: Add new wrapper function to invoke start method
> > > > > >    tpm_crb: Implement command and response chunking logic
> > > > > >    tpm: Increase TPM_BUFSIZE to 64kB for chunking support
> 
> 64kb? I am only increasing the TPM buffer to 8kb. More does not seem to be
> necessary.
> 
> > > > > > 
> > > > > >   drivers/char/tpm/tpm.h     |   2 +-
> > > > > >   drivers/char/tpm/tpm_crb.c | 194 ++++++++++++++++++++++++++-----------
> > > > > >   2 files changed, 137 insertions(+), 59 deletions(-)
> > > > > > 
> > > > > > -- 
> > > > > > 2.53.0
> > > > > > 
> > > > > 
> > > > > When QEMU has the feature available?
> > > > 
> > > > The QEMU patches are in review at the moment,
> > > > here is the link: https://lore.kernel.org/qemu-devel/20260319135316.37412-1-armenon@redhat.com/
> > > > Hoping to have them merged soon.
> > > 
> > > Right, and additional question: what about swtpm?
> 
> I am waiting for https://github.com/trustedComputingGroup/tpm to show rev185
> with PQC support so that I can merge my patches based on 'their' PQC support
> into the public libtpms repo.
> 

Oh, great to hear, thanks for heads up.

Whenever that happens I'll update BuildRoot packages for libtpms and swtpm.

BR, Jarkko

Re: [RFC 0/4] tpm_crb: Add command and response buffer chunking support

[Arun Menon]

On Fri, Apr 24, 2026 at 04:54:03PM -0400, Stefan Berger wrote:
> 
> 
> On 4/23/26 6:43 AM, Arun Menon wrote:
> > On Wed, Apr 08, 2026 at 11:34:54AM +0300, Jarkko Sakkinen wrote:
> > > On Tue, Mar 24, 2026 at 06:11:11PM +0530, Arun Menon wrote:
> > > > Hi Jarkko,
> > > > 
> > > > On Tue, Mar 24, 2026 at 12:41:26PM +0200, Jarkko Sakkinen wrote:
> > > > > On Tue, Mar 24, 2026 at 12:47:59PM +0530, Arun Menon wrote:
> > > > > > The new version of TCG TPM v185 (currently under review [1]) supports
> > > > > > sending data/commands in chunks for the CRB (Command Response Buffer)
> > > > > > interface. This is in line with the initiative to support PQC algorithms.
> > > > > > 
> > > > > > This series implements the logic to send and receive larger TPM
> > > > > > cmd/rsp between the linux guest and the TPM backend in chunks.
> > > > > > Currently, the TPM CRB driver is limited by the physical size of the
> > > > > > MMIO window. When userspace attempts to send a payload that exceeds this
> > > > > > size, the driver rejects it.
> > > > > > 
> > > > > > This series introduces chunking support. The driver now checks the CRB
> > > > > > interface capability for CRB_INTF_CAP_CRB_CHUNK. If supported by the
> > > > > > backend, the driver will slice oversized commands into MMIO-sized
> > > > > > chunks, signalling the backend via CRB_START_NEXT_CHUNK, and finalizing
> > > > > > with CRB_START_INVOKE. Responses are also read back in a similar chunked
> > > > > > manner.
> > > > > > 
> > > > > > If the backend does not support chunking, the driver retains its legacy
> > > > > > behaviour and enforces the standard size limits.
> > > > > > 
> > > > > > This feature also requires the QEMU to interpret the data in chunks and
> > > > > > forward it to the TPM backend and subsequently dispatch the TPM response
> > > > > > in chunks back to the linux guest. This is implemented in [2]
> > > > > > 
> > > > > > [1] https://trustedcomputinggroup.org/wp-content/uploads/PC-Client-Specific-Platform-TPM-Profile-for-TPM-2p0-v1p07_rc1_121225.pdf
> > > > > > [2] https://lore.kernel.org/qemu-devel/20260319135316.37412-1-armenon@redhat.com/
> > > > > > 
> > > > > > Arun Menon (4):
> > > > > >    tpm_crb: Add definition of TPM CRB chunking fields
> > > > > >    tpm_crb: Add new wrapper function to invoke start method
> > > > > >    tpm_crb: Implement command and response chunking logic
> > > > > >    tpm: Increase TPM_BUFSIZE to 64kB for chunking support
> 
> 64kb? I am only increasing the TPM buffer to 8kb. More does not seem to be
> necessary.

That was a mistake in v1. I have changed that to 8kb in v2.
https://lore.kernel.org/all/20260324181244.17741-5-armenon@redhat.com/

> 
> > > > > > 
> > > > > >   drivers/char/tpm/tpm.h     |   2 +-
> > > > > >   drivers/char/tpm/tpm_crb.c | 194 ++++++++++++++++++++++++++-----------
> > > > > >   2 files changed, 137 insertions(+), 59 deletions(-)
> > > > > > 
> > > > > > -- 
> > > > > > 2.53.0
> > > > > > 
> > > > > 
> > > > > When QEMU has the feature available?
> > > > 
> > > > The QEMU patches are in review at the moment,
> > > > here is the link: https://lore.kernel.org/qemu-devel/20260319135316.37412-1-armenon@redhat.com/
> > > > Hoping to have them merged soon.
> > > 
> > > Right, and additional question: what about swtpm?
> 
> I am waiting for https://github.com/trustedComputingGroup/tpm to show rev185
> with PQC support so that I can merge my patches based on 'their' PQC support
> into the public libtpms repo.
> 

Regards,
Arun Menon

Re: [RFC 4/4] tpm: Increase TPM_BUFSIZE to 64kB for chunking support

[kernel test robot]

BCC: lkp@intel.com
CC: oe-kbuild-all@lists.linux.dev
In-Reply-To: <20260324071803.324774-5-armenon@redhat.com>
References: <20260324071803.324774-5-armenon@redhat.com>
TO: Arun Menon <armenon@redhat.com>

Hi Arun,

[This is a private test report for your RFC patch.]
kernel test robot noticed the following build warnings:

[auto build test WARNING on char-misc/char-misc-testing]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Arun-Menon/tpm_crb-Add-definition-of-TPM-CRB-chunking-fields/20260326-015436
base:   char-misc/char-misc-testing
patch link:    https://lore.kernel.org/r/20260324071803.324774-5-armenon%40redhat.com
patch subject: [RFC 4/4] tpm: Increase TPM_BUFSIZE to 64kB for chunking support
:::::: branch date: 2 days ago
:::::: commit date: 2 days ago
config: openrisc-randconfig-r072-20260328 (https://download.01.org/0day-ci/archive/20260328/202603280809.fCfcehTj-lkp@intel.com/config)
compiler: or1k-linux-gcc (GCC) 12.5.0
smatch: v0.5.0-9004-gb810ac53

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Reported-by: Dan Carpenter <error27@gmail.com>
| Closes: https://lore.kernel.org/r/202603280809.fCfcehTj-lkp@intel.com/

smatch warnings:
drivers/char/tpm/tpm_tis_i2c.c:235 tpm_tis_i2c_write_bytes() warn: impossible condition '(len > 65536 - 1) => (0-u16max > u16max)'

vim +235 drivers/char/tpm/tpm_tis_i2c.c

bbc23a07b0728c Alexander Steffen  2022-06-08  224  
bbc23a07b0728c Alexander Steffen  2022-06-08  225  static int tpm_tis_i2c_write_bytes(struct tpm_tis_data *data, u32 addr, u16 len,
bbc23a07b0728c Alexander Steffen  2022-06-08  226  				   const u8 *value,
bbc23a07b0728c Alexander Steffen  2022-06-08  227  				   enum tpm_tis_io_mode io_mode)
bbc23a07b0728c Alexander Steffen  2022-06-08  228  {
bbc23a07b0728c Alexander Steffen  2022-06-08  229  	struct tpm_tis_i2c_phy *phy = to_tpm_tis_i2c_phy(data);
bbc23a07b0728c Alexander Steffen  2022-06-08  230  	struct i2c_msg msg = { .addr = phy->i2c_client->addr };
bbc23a07b0728c Alexander Steffen  2022-06-08  231  	u8 reg = tpm_tis_i2c_address_to_register(addr);
bbc23a07b0728c Alexander Steffen  2022-06-08  232  	int ret;
83e7e5d89f04d1 Alexander Sverdlin 2023-05-24  233  	u16 wrote = 0;
bbc23a07b0728c Alexander Steffen  2022-06-08  234  
bbc23a07b0728c Alexander Steffen  2022-06-08 @235  	if (len > TPM_BUFSIZE - 1)
bbc23a07b0728c Alexander Steffen  2022-06-08  236  		return -EIO;
bbc23a07b0728c Alexander Steffen  2022-06-08  237  
bbc23a07b0728c Alexander Steffen  2022-06-08  238  	phy->io_buf[0] = reg;
bbc23a07b0728c Alexander Steffen  2022-06-08  239  	msg.buf = phy->io_buf;
83e7e5d89f04d1 Alexander Sverdlin 2023-05-24  240  	while (wrote < len) {
83e7e5d89f04d1 Alexander Sverdlin 2023-05-24  241  		/* write register and data in one go */
83e7e5d89f04d1 Alexander Sverdlin 2023-05-24  242  		msg.len = sizeof(reg) + len - wrote;
83e7e5d89f04d1 Alexander Sverdlin 2023-05-24  243  		if (msg.len > I2C_SMBUS_BLOCK_MAX)
83e7e5d89f04d1 Alexander Sverdlin 2023-05-24  244  			msg.len = I2C_SMBUS_BLOCK_MAX;
83e7e5d89f04d1 Alexander Sverdlin 2023-05-24  245  
83e7e5d89f04d1 Alexander Sverdlin 2023-05-24  246  		memcpy(phy->io_buf + sizeof(reg), value + wrote,
83e7e5d89f04d1 Alexander Sverdlin 2023-05-24  247  		       msg.len - sizeof(reg));
83e7e5d89f04d1 Alexander Sverdlin 2023-05-24  248  
bbc23a07b0728c Alexander Steffen  2022-06-08  249  		ret = tpm_tis_i2c_retry_transfer_until_ack(data, &msg);
bbc23a07b0728c Alexander Steffen  2022-06-08  250  		if (ret < 0)
bbc23a07b0728c Alexander Steffen  2022-06-08  251  			return ret;
83e7e5d89f04d1 Alexander Sverdlin 2023-05-24  252  		wrote += msg.len - sizeof(reg);
83e7e5d89f04d1 Alexander Sverdlin 2023-05-24  253  	}
bbc23a07b0728c Alexander Steffen  2022-06-08  254  
bbc23a07b0728c Alexander Steffen  2022-06-08  255  	return 0;
bbc23a07b0728c Alexander Steffen  2022-06-08  256  }
bbc23a07b0728c Alexander Steffen  2022-06-08  257  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki