From: Matt Helsley <matthltc@us.ibm.com>
To: Rajiv Andrade <srajiv@linux.vnet.ibm.com>
Cc: linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
dave@linux.vnet.ibm.com, jmorris@namei.org,
zohar@linux.vnet.ibm.com
Subject: Re: [PATCH 1/2] TPM: sysfs functions consolidation
Date: Thu, 29 Jan 2009 16:19:09 -0800 [thread overview]
Message-ID: <1233274749.12333.38.camel@localhost> (raw)
In-Reply-To: <83b938103ecea5b82372cf55c722d7e986959f62.1233269000.git.srajiv@linux.vnet.ibm.com>
On Thu, 2009-01-29 at 21:01 -0200, Rajiv Andrade wrote:
> According to Dave Hansen's comments on the tpm_show_*, some of these functions
> present a pattern when allocating data[] memory space and also when setting its
> content. A new function was created so that this pattern could be consolidated.
> Also, replaced the data[] command vectors and its indexes by meaningful structures
> as pointed out by Matt Helsley too.
>
> Signed-off-by: Rajiv Andrade <srajiv@linux.vnet.ibm.com>
> ---
> drivers/char/tpm/tpm.c | 410 +++++++++++++++++-------------------------------
> drivers/char/tpm/tpm.h | 117 ++++++++++++++
> 2 files changed, 258 insertions(+), 269 deletions(-)
>
> diff --git a/drivers/char/tpm/tpm.c b/drivers/char/tpm/tpm.c
> index 9c47dc4..58ea16f 100644
> --- a/drivers/char/tpm/tpm.c
> +++ b/drivers/char/tpm/tpm.c
<snip>
> - rc = transmit_cmd(chip, data, sizeof(data),
> + rc = transmit_cmd(chip, &tpm_cmd, TPM_INTERNAL_RESULT_SIZE,
> "attempting to determine the timeouts");
> if (rc)
> goto duration;
>
> - if (be32_to_cpu(*((__be32 *) (data + TPM_GET_CAP_RET_SIZE_IDX)))
> + if (be32_to_cpu(tpm_cmd.header.out.length)
> != 4 * sizeof(u32))
> goto duration;
>
> + timeout_cap = &tpm_cmd.params.getcap_out.cap.timeout;
> /* Don't overwrite default if value is 0 */
> - timeout =
> - be32_to_cpu(*((__be32 *) (data + TPM_GET_CAP_RET_UINT32_1_IDX)));
> + timeout = be32_to_cpu(timeout_cap->a);
> if (timeout)
> chip->vendor.timeout_a = usecs_to_jiffies(timeout);
> - timeout =
> - be32_to_cpu(*((__be32 *) (data + TPM_GET_CAP_RET_UINT32_2_IDX)));
> + timeout = be32_to_cpu(timeout_cap->b);
> if (timeout)
> chip->vendor.timeout_b = usecs_to_jiffies(timeout);
> - timeout =
> - be32_to_cpu(*((__be32 *) (data + TPM_GET_CAP_RET_UINT32_3_IDX)));
> + timeout = be32_to_cpu(timeout_cap->c);
> if (timeout)
> chip->vendor.timeout_c = usecs_to_jiffies(timeout);
> - timeout =
> - be32_to_cpu(*((__be32 *) (data + TPM_GET_CAP_RET_UINT32_4_IDX)));
> + timeout = be32_to_cpu(timeout_cap->d);
> if (timeout)
> chip->vendor.timeout_d = usecs_to_jiffies(timeout);
Are jiffies really the appropriate units of time for the needs of this
driver? I could easily be wrong but I thought most drivers were
discouraged from using jiffies since HZ is configurable...
>
> duration:
> - memcpy(data, tpm_cap, sizeof(tpm_cap));
> - data[TPM_CAP_IDX] = TPM_CAP_PROP;
> - data[TPM_CAP_SUBCAP_IDX] = TPM_CAP_PROP_TIS_DURATION;
> + tpm_cmd.header.in = tpm_getcap_header;
> + tpm_cmd.params.getcap_in.cap = TPM_CAP_PROP;
> + tpm_cmd.params.getcap_in.subcap_size = cpu_to_be32(4);
> + tpm_cmd.params.getcap_in.subcap = TPM_CAP_PROP_TIS_DURATION;
>
> - rc = transmit_cmd(chip, data, sizeof(data),
> + rc = transmit_cmd(chip, &tpm_cmd, TPM_INTERNAL_RESULT_SIZE,
> "attempting to determine the durations");
> if (rc)
> return;
>
> - if (be32_to_cpu(*((__be32 *) (data + TPM_GET_CAP_RET_SIZE_IDX)))
> + if (be32_to_cpu(tpm_cmd.header.out.return_code)
> != 3 * sizeof(u32))
> return;
> -
> + timeout_cap = &tpm_cmd.params.getcap_out.cap.timeout;
> chip->vendor.duration[TPM_SHORT] =
> - usecs_to_jiffies(be32_to_cpu
> - (*((__be32 *) (data +
> - TPM_GET_CAP_RET_UINT32_1_IDX))));
> + usecs_to_jiffies(be32_to_cpu(timeout_cap->a));
> /* The Broadcom BCM0102 chipset in a Dell Latitude D820 gets the above
> * value wrong and apparently reports msecs rather than usecs. So we
> * fix up the resulting too-small TPM_SHORT value to make things work.
> @@ -565,13 +578,9 @@ duration:
> chip->vendor.duration[TPM_SHORT] = HZ;
>
> chip->vendor.duration[TPM_MEDIUM] =
> - usecs_to_jiffies(be32_to_cpu
> - (*((__be32 *) (data +
> - TPM_GET_CAP_RET_UINT32_2_IDX))));
> + usecs_to_jiffies(be32_to_cpu(timeout_cap->b));
> chip->vendor.duration[TPM_LONG] =
> - usecs_to_jiffies(be32_to_cpu
> - (*((__be32 *) (data +
> - TPM_GET_CAP_RET_UINT32_3_IDX))));
> + usecs_to_jiffies(be32_to_cpu(timeout_cap->c));
OK, so it looks like these timeouts are short, medium, and long-duration
timeouts and those correspond to "a", "b", and "c". What's "d"? Also
this suggests slightly-better names for these fields. If you can think
of short names suggesting why these separate, varying-length timeouts
are needed that could be even better.
<snip>
> diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h
> index 8e30df4..867987d 100644
> --- a/drivers/char/tpm/tpm.h
> +++ b/drivers/char/tpm/tpm.h
<snip>
> +struct timeout_t {
> + __be32 a;
> + __be32 b;
> + __be32 c;
> + __be32 d;
> +}__attribute__((packed));
As I pointed out above I think these could use better names. I also
noticed that there are timeout_a, timeout_b, etc. fields of another
struct (somewhere under "chips" if I recall..). Perhaps similar naming
-- maybe even this struct -- should be (re)used?
<snip>
Cheers,
-Matt Helsley
next prev parent reply other threads:[~2009-01-30 0:19 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-29 23:01 [PATCH 0/2] TPM: refactoring and integrity Rajiv Andrade
2009-01-29 23:01 ` [PATCH 1/2] TPM: sysfs functions consolidation Rajiv Andrade
2009-01-29 23:01 ` [PATCH 2/2] TPM: integrity interface Rajiv Andrade
2009-01-30 0:19 ` Matt Helsley [this message]
2009-01-30 14:43 ` [PATCH 1/2] TPM: sysfs functions consolidation Rajiv Andrade
2009-01-29 23:50 ` [PATCH 2/2 - repost] TPM: integrity interface Rajiv Andrade
-- strict thread matches above, loose matches on Subject: below --
2009-02-02 17:23 [PATCH 0/2] TPM: refactoring and integrity Rajiv Andrade
2009-02-02 17:23 ` [PATCH 1/2] TPM: sysfs functions consolidation Rajiv Andrade
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1233274749.12333.38.camel@localhost \
--to=matthltc@us.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=dave@linux.vnet.ibm.com \
--cc=jmorris@namei.org \
--cc=linux-kernel@vger.kernel.org \
--cc=srajiv@linux.vnet.ibm.com \
--cc=zohar@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.