From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750859AbdANAaB (ORCPT ); Fri, 13 Jan 2017 19:30:01 -0500 Received: from quartz.orcorp.ca ([184.70.90.242]:60126 "EHLO quartz.orcorp.ca" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750795AbdANAaA (ORCPT ); Fri, 13 Jan 2017 19:30:00 -0500 Date: Fri, 13 Jan 2017 17:28:57 -0700 From: Jason Gunthorpe To: Andrey Pronin Cc: Peter Huewe , Marcel Selhorst , Jarkko Sakkinen , tpmdd-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org, semenzato@chromium.org, groeck@chromium.org Subject: Re: [PATCH] tpm/tpm_i2c_infineon: ensure no ongoing commands on shutdown Message-ID: <20170114002857.GA5851@obsidianresearch.com> References: <20170114000954.17728-1-apronin@chromium.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170114000954.17728-1-apronin@chromium.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-Broken-Reverse-DNS: no host name found for IP address 10.0.0.156 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 handler. > tpm_chip_unregister() waits for the completion of an ongoing > command, if any, and then clears out chip->ops and unregisters > sysfs entities. Unregistering in a shutdown handler seems very strange, it also waits for userspace things, so I wonder if it could be problematic? Maybe just use down_write(&chip->ops_sem); chip->ops = NULL; up_write(&chip->ops_sem); In the shutdown handler? Jason