[PATCH 0/2] Unify send() callbacks

A portion of send() callbacks have returned length, in many cases just
returning back what was given as an argument, and tpm_crb has returned 0 on
success.  This patch set fixes and unifies the behaviour.

Jarkko Sakkinen (2):
  tpm: Unify the send callback behaviour
  tpm/tpm_i2c_atmel: Return -E2BIG when the transfer is incomplete

 drivers/char/tpm/st33zp24/st33zp24.c |  2 +-
 drivers/char/tpm/tpm_atmel.c         |  2 +-
 drivers/char/tpm/tpm_i2c_atmel.c     | 10 +++++++++-
 drivers/char/tpm/tpm_i2c_infineon.c  |  2 +-
 drivers/char/tpm/tpm_i2c_nuvoton.c   |  2 +-
 drivers/char/tpm/tpm_ibmvtpm.c       |  2 +-
 drivers/char/tpm/tpm_vtpm_proxy.c    |  3 +--
 drivers/char/tpm/xen-tpmfront.c      |  2 +-
 8 files changed, 16 insertions(+), 9 deletions(-)

-- 
2.19.1

Return -E2BIG when the transfer is incomplete. The upper layer does
not retry, so not doing that is incorrect behaviour.

Cc: stable@vger.kernel.org
Fixes: a2871c62e186 ("tpm: Add support for Atmel I2C TPMs")
Signed-off-by: Jarkko Sakkinen <redacted>
---
 drivers/char/tpm/tpm_i2c_atmel.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/char/tpm/tpm_i2c_atmel.c b/drivers/char/tpm/tpm_i2c_atmel.c
index aa11c8a1df5e..8a7e80923091 100644
--- a/drivers/char/tpm/tpm_i2c_atmel.c
+++ b/drivers/char/tpm/tpm_i2c_atmel.c

@@ -69,6 +69,10 @@ static int i2c_atmel_send(struct tpm_chip *chip, u8 *buf, size_t len)
 	if (status < 0)
 		return status;
 
+	/* The upper layer does not support incomplete sends. */
+	if (status != len)
+		return -E2BIG;
+
 	return 0;
 }
 

-- 
2.19.1

The send() callback should never return length as it does not in every
driver except tpm_crb in the success case. The reason is that the main
transmit functionality only cares about whether the transmit was
successful or not and ignores the count completely.

Cc: stable@vger.kernel.org
Signed-off-by: Jarkko Sakkinen <redacted>
---
 drivers/char/tpm/st33zp24/st33zp24.c | 2 +-
 drivers/char/tpm/tpm_atmel.c         | 2 +-
 drivers/char/tpm/tpm_i2c_atmel.c     | 6 +++++-
 drivers/char/tpm/tpm_i2c_infineon.c  | 2 +-
 drivers/char/tpm/tpm_i2c_nuvoton.c   | 2 +-
 drivers/char/tpm/tpm_ibmvtpm.c       | 2 +-
 drivers/char/tpm/tpm_vtpm_proxy.c    | 3 +--
 drivers/char/tpm/xen-tpmfront.c      | 2 +-
 8 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/drivers/char/tpm/st33zp24/st33zp24.c b/drivers/char/tpm/st33zp24/st33zp24.c
index 64dc560859f2..13dc614b7ebc 100644
--- a/drivers/char/tpm/st33zp24/st33zp24.c
+++ b/drivers/char/tpm/st33zp24/st33zp24.c

@@ -436,7 +436,7 @@ static int st33zp24_send(struct tpm_chip *chip, unsigned char *buf,
 			goto out_err;
 	}
 
-	return len;
+	return 0;
 out_err:
 	st33zp24_cancel(chip);
 	release_locality(chip);

diff --git a/drivers/char/tpm/tpm_atmel.c b/drivers/char/tpm/tpm_atmel.c
index 66a14526aaf4..a290b30a0c35 100644
--- a/drivers/char/tpm/tpm_atmel.c
+++ b/drivers/char/tpm/tpm_atmel.c

@@ -105,7 +105,7 @@ static int tpm_atml_send(struct tpm_chip *chip, u8 *buf, size_t count)
 		iowrite8(buf[i], priv->iobase);
 	}
 
-	return count;
+	return 0;
 }
 
 static void tpm_atml_cancel(struct tpm_chip *chip)

diff --git a/drivers/char/tpm/tpm_i2c_atmel.c b/drivers/char/tpm/tpm_i2c_atmel.c
index 4720b2442ffe..aa11c8a1df5e 100644
--- a/drivers/char/tpm/tpm_i2c_atmel.c
+++ b/drivers/char/tpm/tpm_i2c_atmel.c

@@ -65,7 +65,11 @@ static int i2c_atmel_send(struct tpm_chip *chip, u8 *buf, size_t len)
 	dev_dbg(&chip->dev,
 		"%s(buf=%*ph len=%0zx) -> sts=%d\n", __func__,
 		(int)min_t(size_t, 64, len), buf, len, status);
-	return status;
+
+	if (status < 0)
+		return status;
+
+	return 0;
 }
 
 static int i2c_atmel_recv(struct tpm_chip *chip, u8 *buf, size_t count)

diff --git a/drivers/char/tpm/tpm_i2c_infineon.c b/drivers/char/tpm/tpm_i2c_infineon.c
index 3b490d9d90e7..3b4e9672ff6c 100644
--- a/drivers/char/tpm/tpm_i2c_infineon.c
+++ b/drivers/char/tpm/tpm_i2c_infineon.c

@@ -588,7 +588,7 @@ static int tpm_tis_i2c_send(struct tpm_chip *chip, u8 *buf, size_t len)
 	/* go and do it */
 	iic_tpm_write(TPM_STS(tpm_dev.locality), &sts, 1);
 
-	return len;
+	return 0;
 out_err:
 	tpm_tis_i2c_ready(chip);
 	/* The TPM needs some time to clean up here,

diff --git a/drivers/char/tpm/tpm_i2c_nuvoton.c b/drivers/char/tpm/tpm_i2c_nuvoton.c
index 5700cc2ddee1..315a3b4548f7 100644
--- a/drivers/char/tpm/tpm_i2c_nuvoton.c
+++ b/drivers/char/tpm/tpm_i2c_nuvoton.c

@@ -465,7 +465,7 @@ static int i2c_nuvoton_send(struct tpm_chip *chip, u8 *buf, size_t len)
 	}
 
 	dev_dbg(dev, "%s() -> %zd\n", __func__, len);
-	return len;
+	return 0;
 }
 
 static bool i2c_nuvoton_req_canceled(struct tpm_chip *chip, u8 status)

diff --git a/drivers/char/tpm/tpm_ibmvtpm.c b/drivers/char/tpm/tpm_ibmvtpm.c
index 07b5a487d0c8..aeae3222723c 100644
--- a/drivers/char/tpm/tpm_ibmvtpm.c
+++ b/drivers/char/tpm/tpm_ibmvtpm.c

@@ -192,7 +192,7 @@ static int tpm_ibmvtpm_send(struct tpm_chip *chip, u8 *buf, size_t count)
 		rc = 0;
 		ibmvtpm->tpm_processing_cmd = false;
 	} else
-		rc = count;
+		rc = 0;
 
 	spin_unlock(&ibmvtpm->rtce_lock);
 	return rc;

diff --git a/drivers/char/tpm/tpm_vtpm_proxy.c b/drivers/char/tpm/tpm_vtpm_proxy.c
index 26a2be555288..d74f3de74ae6 100644
--- a/drivers/char/tpm/tpm_vtpm_proxy.c
+++ b/drivers/char/tpm/tpm_vtpm_proxy.c

@@ -335,7 +335,6 @@ static int vtpm_proxy_is_driver_command(struct tpm_chip *chip,
 static int vtpm_proxy_tpm_op_send(struct tpm_chip *chip, u8 *buf, size_t count)
 {
 	struct proxy_dev *proxy_dev = dev_get_drvdata(&chip->dev);
-	int rc = 0;
 
 	if (count > sizeof(proxy_dev->buffer)) {
 		dev_err(&chip->dev,

@@ -366,7 +365,7 @@ static int vtpm_proxy_tpm_op_send(struct tpm_chip *chip, u8 *buf, size_t count)
 
 	wake_up_interruptible(&proxy_dev->wq);
 
-	return rc;
+	return 0;
 }
 
 static void vtpm_proxy_tpm_op_cancel(struct tpm_chip *chip)

diff --git a/drivers/char/tpm/xen-tpmfront.c b/drivers/char/tpm/xen-tpmfront.c
index 1259e935fd58..4e2d00cb0d81 100644
--- a/drivers/char/tpm/xen-tpmfront.c
+++ b/drivers/char/tpm/xen-tpmfront.c

@@ -173,7 +173,7 @@ static int vtpm_send(struct tpm_chip *chip, u8 *buf, size_t count)
 		return -ETIME;
 	}
 
-	return count;
+	return 0;
 }
 
 static int vtpm_recv(struct tpm_chip *chip, u8 *buf, size_t count)

-- 
2.19.1

On 2/8/19 9:05 AM, Jarkko Sakkinen wrote:

The send() callback should never return length as it does not in every
driver except tpm_crb in the success case. The reason is that the main
transmit functionality only cares about whether the transmit was
successful or not and ignores the count completely.

Cc: stable@vger.kernel.org
Signed-off-by: Jarkko Sakkinen <redacted>
---
  drivers/char/tpm/st33zp24/st33zp24.c | 2 +-
  drivers/char/tpm/tpm_atmel.c         | 2 +-
  drivers/char/tpm/tpm_i2c_atmel.c     | 6 +++++-
  drivers/char/tpm/tpm_i2c_infineon.c  | 2 +-
  drivers/char/tpm/tpm_i2c_nuvoton.c   | 2 +-
  drivers/char/tpm/tpm_ibmvtpm.c       | 2 +-
  drivers/char/tpm/tpm_vtpm_proxy.c    | 3 +--
  drivers/char/tpm/xen-tpmfront.c      | 2 +-

At least tpm_nsc_send (tpm_nsc.c) and tpm_inf_send (tpm_infineon.c) are 
also returning the number of bytes sent. I would consider tpm_crb the 
outlier that returns 0 and should return the length even though we don't 
need it...

On Fri, Feb 08, 2019 at 09:42:16AM -0500, Stefan Berger wrote: > On 2/8/19 9:05 AM, Jarkko Sakkinen wrote:

At least tpm_nsc_send (tpm_nsc.c) and tpm_inf_send (tpm_infineon.c) are also
returning the number of bytes sent. I would consider tpm_crb the outlier
that returns 0 and should return the length even though we don't need it...

That would be absolutely wrong way the fix the *actual* issue i.e.
callbacks returning garbage (sometimes just passing the length parameter
back as a return value).

/Jarkko

On 2/8/19 10:42 AM, Jarkko Sakkinen wrote:

On Fri, Feb 08, 2019 at 09:42:16AM -0500, Stefan Berger wrote: > On 2/8/19 9:05 AM, Jarkko Sakkinen wrote:

quoted

At least tpm_nsc_send (tpm_nsc.c) and tpm_inf_send (tpm_infineon.c) are also
returning the number of bytes sent. I would consider tpm_crb the outlier
that returns 0 and should return the length even though we don't need it...

That would be absolutely wrong way the fix the *actual* issue i.e.
callbacks returning garbage (sometimes just passing the length parameter
back as a return value).

Then I guess you have to fixes those other two files as well...

/Jarkko

On Fri, Feb 08, 2019 at 10:45:53AM -0500, Stefan Berger wrote:

On 2/8/19 10:42 AM, Jarkko Sakkinen wrote:

quoted

On Fri, Feb 08, 2019 at 09:42:16AM -0500, Stefan Berger wrote: > On 2/8/19 9:05 AM, Jarkko Sakkinen wrote:

quoted

At least tpm_nsc_send (tpm_nsc.c) and tpm_inf_send (tpm_infineon.c) are also
returning the number of bytes sent. I would consider tpm_crb the outlier
that returns 0 and should return the length even though we don't need it...

That would be absolutely wrong way the fix the *actual* issue i.e.
callbacks returning garbage (sometimes just passing the length parameter
back as a return value).

Then I guess you have to fixes those other two files as well...

That's still a better option.

/Jarkko

On 2/8/19 11:07 AM, Jarkko Sakkinen wrote:

On Fri, Feb 08, 2019 at 10:45:53AM -0500, Stefan Berger wrote:

quoted

On 2/8/19 10:42 AM, Jarkko Sakkinen wrote:

quoted

On Fri, Feb 08, 2019 at 09:42:16AM -0500, Stefan Berger wrote: > On 2/8/19 9:05 AM, Jarkko Sakkinen wrote:

quoted

At least tpm_nsc_send (tpm_nsc.c) and tpm_inf_send (tpm_infineon.c) are also
returning the number of bytes sent. I would consider tpm_crb the outlier
that returns 0 and should return the length even though we don't need it...

That would be absolutely wrong way the fix the *actual* issue i.e.
callbacks returning garbage (sometimes just passing the length parameter
back as a return value).

Then I guess you have to fixes those other two files as well...

That's still a better option.

tpm_tis_core.c's tpm_tis_send_main() also needs fixing...

/Jarkko

On Fri, Feb 08, 2019 at 11:19:04AM -0500, Stefan Berger wrote:

On 2/8/19 11:07 AM, Jarkko Sakkinen wrote:

quoted

On Fri, Feb 08, 2019 at 10:45:53AM -0500, Stefan Berger wrote:

quoted

On 2/8/19 10:42 AM, Jarkko Sakkinen wrote:

quoted

On Fri, Feb 08, 2019 at 09:42:16AM -0500, Stefan Berger wrote: > On 2/8/19 9:05 AM, Jarkko Sakkinen wrote:

quoted

At least tpm_nsc_send (tpm_nsc.c) and tpm_inf_send (tpm_infineon.c) are also
returning the number of bytes sent. I would consider tpm_crb the outlier
that returns 0 and should return the length even though we don't need it...

That would be absolutely wrong way the fix the *actual* issue i.e.
callbacks returning garbage (sometimes just passing the length parameter
back as a return value).

Then I guess you have to fixes those other two files as well...

That's still a better option.

tpm_tis_core.c's tpm_tis_send_main() also needs fixing...

Weird I had that fixed in my working area. Probably somehow managed
not to stage that change. It was like the very first things that
I fixed. Updating..

/Jarkko

On Fri, Feb 08, 2019 at 06:26:15PM +0200, Jarkko Sakkinen wrote:

On Fri, Feb 08, 2019 at 11:19:04AM -0500, Stefan Berger wrote:

quoted

On 2/8/19 11:07 AM, Jarkko Sakkinen wrote:

quoted

On Fri, Feb 08, 2019 at 10:45:53AM -0500, Stefan Berger wrote:

quoted

On 2/8/19 10:42 AM, Jarkko Sakkinen wrote:

quoted

On Fri, Feb 08, 2019 at 09:42:16AM -0500, Stefan Berger wrote: > On 2/8/19 9:05 AM, Jarkko Sakkinen wrote:

quoted

At least tpm_nsc_send (tpm_nsc.c) and tpm_inf_send (tpm_infineon.c) are also
returning the number of bytes sent. I would consider tpm_crb the outlier
that returns 0 and should return the length even though we don't need it...

That would be absolutely wrong way the fix the *actual* issue i.e.
callbacks returning garbage (sometimes just passing the length parameter
back as a return value).

Then I guess you have to fixes those other two files as well...

That's still a better option.

tpm_tis_core.c's tpm_tis_send_main() also needs fixing...

Weird I had that fixed in my working area. Probably somehow managed
not to stage that change. It was like the very first things that
I fixed. Updating..

tpm_tis_send() would be the right function.

/Jarkko