From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755900AbdLTRoH (ORCPT ); Wed, 20 Dec 2017 12:44:07 -0500 Received: from mail-it0-f66.google.com ([209.85.214.66]:44480 "EHLO mail-it0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755660AbdLTRoC (ORCPT ); Wed, 20 Dec 2017 12:44:02 -0500 X-Google-Smtp-Source: ACJfBoss9mOVXbB8VdbZ1OQuB9jlezzZe/ih3K02vuT9wIpc1ddj9fIPNYmpFpV61mEO3FK0rsFW0g== Date: Wed, 20 Dec 2017 10:44:00 -0700 From: Jason Gunthorpe To: Javier Martinez Canillas Cc: "Shaikh, Azhar" , "Alexander.Steffen@infineon.com" , "hdegoede@redhat.com" , "linux-kernel@vger.kernel.org" , "james@ettle.org.uk" , "arnd@arndb.de" , "jarkko.sakkinen@linux.intel.com" , "peterhuewe@gmx.de" , "gregkh@linuxfoundation.org" , "linux-integrity@vger.kernel.org" Subject: Re: [PATCH 0/4] tpm: fix PS/2 devices not working on Braswell systems due CLKRUN enabled Message-ID: <20171220174400.GA22908@ziepe.ca> References: <20171220113538.16099-1-javierm@redhat.com> <96f3f833-22f8-5400-bd22-7c1c622bbe61@redhat.com> <5FFFAD06ADE1CA4381B3F0F7C6AF58289886F4@ORSMSX109.amr.corp.intel.com> <5FFFAD06ADE1CA4381B3F0F7C6AF58289887AA@ORSMSX109.amr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Dec 20, 2017 at 05:45:16PM +0100, Javier Martinez Canillas wrote: > CHP51 says "LPC Clock Control Using the LPC_CLKRUN# May Not Behave As Expected" > and that the implication is that "The SoC may prevent a peripheral device from > successfully requesting the LPC clock". Now we are back to the beginning - the LPC_CLKRUN protocol is simply broken in BSW chipsets, and it has nothing to do with the TPM? Intel is trying to work around that broken-ness and still preserve power management in the case where only the TPM is connected to the LPC bus.. It is questionable to me if this is even a good idea, or if Linux is the right place to implement this work around (eg something in SMM mode may be more appropriate for a chipset bug) I think your patch is still the right improvement, if the BIOS turned the feature off, we should not turn it back on. Jason