lkml.org 
[lkml]   [2018]   [Feb]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [PATCH 1/2 v2] tpm: cmd_ready command can be issued only after granting locality
Date

>
> On Tue, Feb 06, 2018 at 09:26:15PM +0000, Winkler, Tomas wrote:
> > >
> > > On Sun, Jan 28, 2018 at 09:17:53PM +0000, Winkler, Tomas wrote:
> > > >
> > > > >
> > > > > On Sun, Jan 28, 2018 at 09:51:00AM +0200, Tomas Winkler wrote:
> > > > >
> > > > > > diff --git a/include/linux/tpm.h b/include/linux/tpm.h index
> > > > > > bcdd3790e94d..06639fb6ab85 100644
> > > > > > +++ b/include/linux/tpm.h
> > > > > > @@ -44,7 +44,7 @@ struct tpm_class_ops {
> > > > > > bool (*update_timeouts)(struct tpm_chip *chip,
> > > > > > unsigned long *timeout_cap);
> > > > > > int (*request_locality)(struct tpm_chip *chip, int loc);
> > > > > > - void (*relinquish_locality)(struct tpm_chip *chip, int loc);
> > > > > > + int (*relinquish_locality)(struct tpm_chip *chip, int loc);
> > > > >
> > > > > This seems wrong.. What is the core code supposed to do if
> > > > > relinquish
> > > fails?
> > > >
> > > > Not much just propage the error to the caller and leave the policy
> > > > decision to it.
> > >
> > > Your patch set must either cover this or keep it as void.
> >
> >
> > How the code is covering other failures in the transmit functions, how
> > is this one different from for example request_locality failure?
> > Why we should not propage this error up?
> >
> > >
> > > A better idea is to print an error to klog.
> > We can do that in addition.
>
> I guess you are right. This can be propagated to the user space so that it
> knows that there is problem. To make the root more visible the klog
> message would make sense.

Thanks, will add an error message.
Tomas


\
 
 \ /
  Last update: 2018-02-08 13:46    [W:0.093 / U:5.780 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site