[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20171221223049.GJ20015@ziepe.ca>
Date: Thu, 21 Dec 2017 15:30:49 -0700
From: Jason Gunthorpe <jgg@...pe.ca>
To: "Shaikh, Azhar" <azhar.shaikh@...el.com>
Cc: "jarkko.sakkinen@...ux.intel.com" <jarkko.sakkinen@...ux.intel.com>,
"javierm@...hat.com" <javierm@...hat.com>,
"peterhuewe@....de" <peterhuewe@....de>,
"linux-security-module@...r.kernel.org"
<linux-security-module@...r.kernel.org>,
"linux-integrity@...r.kernel.org" <linux-integrity@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"tpmdd-devel@...ts.sourceforge.net"
<tpmdd-devel@...ts.sourceforge.net>
Subject: Re: [PATCH] tpm: Fix the driver cleanup code
On Thu, Dec 21, 2017 at 09:54:26PM +0000, Shaikh, Azhar wrote:
> Yes, I checked this part. What I was referring to is any other
> callback function similar to clk_enable if gets added in future and
> then needs to Access ops even after it is set to NULL...
You can't call callback functions after tpm_unregister_chip, it isn't
allowed.
This is a special case where we know the specific implementation of
this specific callback is OK.
> But yes I get your point now.
>
> So do you mean something like this?
Yes
Jason
Powered by blists - more mailing lists