On Mon, Jan 16, 2017 at 11:33:18AM +0200, Jarkko Sakkinen wrote:
> On Fri, Jan 13, 2017 at 04:42:30PM -0800, Andrey Pronin wrote:
> > On Fri, Jan 13, 2017 at 05:28:57PM -0700, Jason Gunthorpe wrote:
> > > On Fri, Jan 13, 2017 at 04:09:54PM -0800, Andrey Pronin wrote:
> > > > Resetting TPM while
On Mon, Jan 16, 2017 at 11:33:18AM +0200, Jarkko Sakkinen wrote:
> On Fri, Jan 13, 2017 at 04:42:30PM -0800, Andrey Pronin wrote:
> > On Fri, Jan 13, 2017 at 05:28:57PM -0700, Jason Gunthorpe wrote:
> > > On Fri, Jan 13, 2017 at 04:09:54PM -0800, Andrey Pronin wrote:
> > > > Resetting TPM while
On Mon, Jan 23, 2017 at 02:19:29PM -0800, Andrey Pronin wrote:
> Simplifying to class vs driver handlers, it checks class suspend
> first. And if it exists, calls it. Otherwise, it calls driver
> suspend. So, it's "either-or", not "first one, then another".
> Unless I'm missing something obvious,
On Mon, Jan 23, 2017 at 02:19:29PM -0800, Andrey Pronin wrote:
> Simplifying to class vs driver handlers, it checks class suspend
> first. And if it exists, calls it. Otherwise, it calls driver
> suspend. So, it's "either-or", not "first one, then another".
> Unless I'm missing something obvious,
On Mon, Jan 23, 2017 at 01:39:01PM -0700, Jason Gunthorpe wrote:
> On Mon, Jan 23, 2017 at 12:02:46PM -0800, Andrey Pronin wrote:
>
> > > But if there is no actual need to do this right now then don't worry
> > > about overdesigning things..
> >
> > OK, I can live with chip->id specific logic in
On Mon, Jan 23, 2017 at 01:39:01PM -0700, Jason Gunthorpe wrote:
> On Mon, Jan 23, 2017 at 12:02:46PM -0800, Andrey Pronin wrote:
>
> > > But if there is no actual need to do this right now then don't worry
> > > about overdesigning things..
> >
> > OK, I can live with chip->id specific logic in
On Mon, Jan 23, 2017 at 12:02:46PM -0800, Andrey Pronin wrote:
> > But if there is no actual need to do this right now then don't worry
> > about overdesigning things..
>
> OK, I can live with chip->id specific logic in probe/shutdown, if that's
> the current approach.
It is where we are
On Mon, Jan 23, 2017 at 12:02:46PM -0800, Andrey Pronin wrote:
> > But if there is no actual need to do this right now then don't worry
> > about overdesigning things..
>
> OK, I can live with chip->id specific logic in probe/shutdown, if that's
> the current approach.
It is where we are
On Mon, Jan 23, 2017 at 12:02:46PM -0800, Andrey Pronin wrote:
> On Tue, Jan 17, 2017 at 04:22:07PM -0700, Jason Gunthorpe wrote:
> > On Tue, Jan 17, 2017 at 03:00:53PM -0800, Andrey Pronin wrote:
> >
> > > Here I was talking not about tpm_tis_spi or tpm_tis. Those can
> > > continue relying on
On Mon, Jan 23, 2017 at 12:02:46PM -0800, Andrey Pronin wrote:
> On Tue, Jan 17, 2017 at 04:22:07PM -0700, Jason Gunthorpe wrote:
> > On Tue, Jan 17, 2017 at 03:00:53PM -0800, Andrey Pronin wrote:
> >
> > > Here I was talking not about tpm_tis_spi or tpm_tis. Those can
> > > continue relying on
On Tue, Jan 17, 2017 at 04:22:07PM -0700, Jason Gunthorpe wrote:
> On Tue, Jan 17, 2017 at 03:00:53PM -0800, Andrey Pronin wrote:
>
> > Here I was talking not about tpm_tis_spi or tpm_tis. Those can
> > continue relying on the core, or register the default handler using
> > .shutdown =
On Tue, Jan 17, 2017 at 04:22:07PM -0700, Jason Gunthorpe wrote:
> On Tue, Jan 17, 2017 at 03:00:53PM -0800, Andrey Pronin wrote:
>
> > Here I was talking not about tpm_tis_spi or tpm_tis. Those can
> > continue relying on the core, or register the default handler using
> > .shutdown =
On Tue, Jan 17, 2017 at 03:00:53PM -0800, Andrey Pronin wrote:
> Here I was talking not about tpm_tis_spi or tpm_tis. Those can
> continue relying on the core, or register the default handler using
> .shutdown = tpm_shutdown. I'm talking about the driver like
> tpm_i2c_infineon, which although
On Tue, Jan 17, 2017 at 03:00:53PM -0800, Andrey Pronin wrote:
> Here I was talking not about tpm_tis_spi or tpm_tis. Those can
> continue relying on the core, or register the default handler using
> .shutdown = tpm_shutdown. I'm talking about the driver like
> tpm_i2c_infineon, which although
On Tue, Jan 17, 2017 at 01:59:33PM -0700, Jason Gunthorpe wrote:
> On Tue, Jan 17, 2017 at 12:13:36PM -0800, Andrey Pronin wrote:
> > > Is there some way we can have the TPM core do this without requiring
> > > the driver to add a shutdown the struct driver?
> > >
> > > Maybe we could put
On Tue, Jan 17, 2017 at 01:59:33PM -0700, Jason Gunthorpe wrote:
> On Tue, Jan 17, 2017 at 12:13:36PM -0800, Andrey Pronin wrote:
> > > Is there some way we can have the TPM core do this without requiring
> > > the driver to add a shutdown the struct driver?
> > >
> > > Maybe we could put
On Tue, Jan 17, 2017 at 12:13:36PM -0800, Andrey Pronin wrote:
> > Is there some way we can have the TPM core do this without requiring
> > the driver to add a shutdown the struct driver?
> >
> > Maybe we could put something in chip->dev->driver? Not sure..
>
> I can play more with it. We can
On Tue, Jan 17, 2017 at 12:13:36PM -0800, Andrey Pronin wrote:
> > Is there some way we can have the TPM core do this without requiring
> > the driver to add a shutdown the struct driver?
> >
> > Maybe we could put something in chip->dev->driver? Not sure..
>
> I can play more with it. We can
On Tue, Jan 17, 2017 at 12:27:28PM -0700, Jason Gunthorpe wrote:
> On Tue, Jan 17, 2017 at 09:58:27AM -0800, Andrey Pronin wrote:
> > > Yes, sorry, I should have mentioned that.. Maybe that is too much to
> > > fix..
> >
> > If we fix sysfs to go through tpm_try_get_ops, then all we can do for
>
On Tue, Jan 17, 2017 at 12:27:28PM -0700, Jason Gunthorpe wrote:
> On Tue, Jan 17, 2017 at 09:58:27AM -0800, Andrey Pronin wrote:
> > > Yes, sorry, I should have mentioned that.. Maybe that is too much to
> > > fix..
> >
> > If we fix sysfs to go through tpm_try_get_ops, then all we can do for
>
On Tue, Jan 17, 2017 at 09:58:27AM -0800, Andrey Pronin wrote:
> > Yes, sorry, I should have mentioned that.. Maybe that is too much to
> > fix..
>
> If we fix sysfs to go through tpm_try_get_ops, then all we can do for
> shutdown is indeed something like
Maybe yes, I also had at one point a
On Tue, Jan 17, 2017 at 09:58:27AM -0800, Andrey Pronin wrote:
> > Yes, sorry, I should have mentioned that.. Maybe that is too much to
> > fix..
>
> If we fix sysfs to go through tpm_try_get_ops, then all we can do for
> shutdown is indeed something like
Maybe yes, I also had at one point a
On Mon, Jan 16, 2017 at 09:19:19AM -0700, Jason Gunthorpe wrote:
> On Fri, Jan 13, 2017 at 04:42:30PM -0800, Andrey Pronin wrote:
> > On Fri, Jan 13, 2017 at 05:28:57PM -0700, Jason Gunthorpe wrote:
> > > On Fri, Jan 13, 2017 at 04:09:54PM -0800, Andrey Pronin wrote:
> > > > Resetting TPM while
On Mon, Jan 16, 2017 at 09:19:19AM -0700, Jason Gunthorpe wrote:
> On Fri, Jan 13, 2017 at 04:42:30PM -0800, Andrey Pronin wrote:
> > On Fri, Jan 13, 2017 at 05:28:57PM -0700, Jason Gunthorpe wrote:
> > > On Fri, Jan 13, 2017 at 04:09:54PM -0800, Andrey Pronin wrote:
> > > > Resetting TPM while
On Fri, Jan 13, 2017 at 04:42:30PM -0800, Andrey Pronin wrote:
> On Fri, Jan 13, 2017 at 05:28:57PM -0700, Jason Gunthorpe wrote:
> > On Fri, Jan 13, 2017 at 04:09:54PM -0800, Andrey Pronin wrote:
> > > Resetting TPM while processing a command may lead to issues
> > > on the next boot. Ensure that
On Fri, Jan 13, 2017 at 04:42:30PM -0800, Andrey Pronin wrote:
> On Fri, Jan 13, 2017 at 05:28:57PM -0700, Jason Gunthorpe wrote:
> > On Fri, Jan 13, 2017 at 04:09:54PM -0800, Andrey Pronin wrote:
> > > Resetting TPM while processing a command may lead to issues
> > > on the next boot. Ensure that
On Fri, Jan 13, 2017 at 04:42:30PM -0800, Andrey Pronin wrote:
> On Fri, Jan 13, 2017 at 05:28:57PM -0700, Jason Gunthorpe wrote:
> > On Fri, Jan 13, 2017 at 04:09:54PM -0800, Andrey Pronin wrote:
> > > Resetting TPM while processing a command may lead to issues
> > > on the next boot. Ensure that
On Fri, Jan 13, 2017 at 04:42:30PM -0800, Andrey Pronin wrote:
> On Fri, Jan 13, 2017 at 05:28:57PM -0700, Jason Gunthorpe wrote:
> > On Fri, Jan 13, 2017 at 04:09:54PM -0800, Andrey Pronin wrote:
> > > Resetting TPM while processing a command may lead to issues
> > > on the next boot. Ensure that
On Fri, Jan 13, 2017 at 05:28:57PM -0700, Jason Gunthorpe wrote:
> On Fri, Jan 13, 2017 at 04:09:54PM -0800, Andrey Pronin wrote:
> > Resetting TPM while processing a command may lead to issues
> > on the next boot. Ensure that we don't have any ongoing
> > commands, and that no further commands
On Fri, Jan 13, 2017 at 05:28:57PM -0700, Jason Gunthorpe wrote:
> On Fri, Jan 13, 2017 at 04:09:54PM -0800, Andrey Pronin wrote:
> > Resetting TPM while processing a command may lead to issues
> > on the next boot. Ensure that we don't have any ongoing
> > commands, and that no further commands
On Fri, Jan 13, 2017 at 04:09:54PM -0800, Andrey Pronin wrote:
> Resetting TPM while processing a command may lead to issues
> on the next boot. Ensure that we don't have any ongoing
> commands, and that no further commands can be sent to the chip
> by unregistering the device in the shutdown
On Fri, Jan 13, 2017 at 04:09:54PM -0800, Andrey Pronin wrote:
> Resetting TPM while processing a command may lead to issues
> on the next boot. Ensure that we don't have any ongoing
> commands, and that no further commands can be sent to the chip
> by unregistering the device in the shutdown
Resetting TPM while processing a command may lead to issues
on the next boot. Ensure that we don't have any ongoing
commands, and that no further commands can be sent to the chip
by unregistering the device in the shutdown handler.
tpm_chip_unregister() waits for the completion of an ongoing
Resetting TPM while processing a command may lead to issues
on the next boot. Ensure that we don't have any ongoing
commands, and that no further commands can be sent to the chip
by unregistering the device in the shutdown handler.
tpm_chip_unregister() waits for the completion of an ongoing
34 matches
Mail list logo
