On Fri, 2018-03-16 at 13:58 +0200, Jarkko Sakkinen wrote:
> On Sat, 2018-03-10 at 14:14 -0800, James Bottomley wrote:
> > TPM_BUF_OVERFLOW= BIT(0),
> > + TPM_BUF_2B = BIT(1),
>
> Instead of re-using this I would prefer to have another enum for
> buffer type. tpm_buf_init
On Sat, 2018-03-10 at 14:14 -0800, James Bottomley wrote:
> TPM_BUF_OVERFLOW= BIT(0),
> + TPM_BUF_2B = BIT(1),
Instead of re-using this I would prefer to have another enum for
buffer type. tpm_buf_init() could have the signature:
int tpm_buf_init(unsigned int type);
On 3/12/18 10:59 AM, James Bottomley wrote:
On Mon, 2018-03-12 at 09:00 -0700, J Freyensee wrote:
+int tpm_buf_init(struct tpm_buf *buf, u16 tag, u32 ordinal)
+{
+ int rc;
+
+ rc = __tpm_buf_init(buf);
Assuming that functions like tpm_buf_init() are the top-level API
being define
On Mon, 2018-03-12 at 09:00 -0700, J Freyensee wrote:
> >
> > +int tpm_buf_init(struct tpm_buf *buf, u16 tag, u32 ordinal)
> > +{
> > + int rc;
> > +
> > + rc = __tpm_buf_init(buf);
>
>
> Assuming that functions like tpm_buf_init() are the top-level API
> being defined in this patch, shouldn
+int tpm_buf_init(struct tpm_buf *buf, u16 tag, u32 ordinal)
+{
+ int rc;
+
+ rc = __tpm_buf_init(buf);
Assuming that functions like tpm_buf_init() are the top-level API being
defined in this patch, shouldn't it check if buf is valid before passing
into the internal functions li
This separates out the old tpm_buf_... handling functions from static
inlines into tpm.h and makes them their own tpm-buf.c file. It also
adds handling for tpm2b structures and also incremental pointer
advancing parsers.
Signed-off-by: James Bottomley
---
v2: added this patch to separate out t
