Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753240AbdHOGJi (ORCPT ); Tue, 15 Aug 2017 02:09:38 -0400 Received: from mga05.intel.com ([192.55.52.43]:15084 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751855AbdHOGJg (ORCPT ); Tue, 15 Aug 2017 02:09:36 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.41,376,1498546800"; d="scan'208";a="1182801671" Date: Tue, 15 Aug 2017 09:09:33 +0300 From: Jarkko Sakkinen To: Mimi Zohar Cc: Peter Huewe , Ken Goldman , linux-ima-devel@lists.sourceforge.net, linux-security-module@vger.kernel.org, tpmdd-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org Subject: Re: Re: [tpmdd-devel] [PATCH] tpm: improve tpm_tis send() performance by ignoring burstcount Message-ID: <20170815060933.3hauk5skfz7fxsby@linux.intel.com> References: <20170807114632.1339-1-nayna@linux.vnet.ibm.com> <20170808191145.kggmoczd5laiccrn@linux.intel.com> <20170811111421.bg2we53rdeecjtac@linux.intel.com> <1502465419.3579.109.camel@linux.vnet.ibm.com> <20170814105130.4jjdcop4mqkoxhgh@linux.intel.com> <20170814105651.eo3e7tokt7mujeba@linux.intel.com> <1502712773.6179.26.camel@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1502712773.6179.26.camel@linux.vnet.ibm.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1245 Lines: 34 On Mon, Aug 14, 2017 at 08:12:53AM -0400, Mimi Zohar wrote: > On Mon, 2017-08-14 at 13:56 +0300, Jarkko Sakkinen wrote: > > > > > Since the main concern about this change is breaking old systems that > > > > might potentially have other peripherals hanging off the LPC bus, can > > > > we define a new Kconfig option, with the default as 'N'? > > > > > > > > Mimi > > > > > > I guess that could make sense but I would like to hear feedback first. > > > > > > /Jarkko > > > > And I'm worried would that it'd be left for many years to come as an > > option. I do not have any metrics what portion of hardware in the field > > would break if this is turned on. > > > > It would slow down kernel testing as I would have to run tests for the > > driver with that option turned on and off because it is a major shift > > from how driver functions. And I have zero idea how long I would go on > > doing this. > > > > One maybe a little bit better option would be to have a sysfs attribute > > for this functionality (disable_burst_count). What do you think about > > that? > > That works! So we'll define a module_param named disable_burst_count, > which can be specified on the boot command line. > > Mimi That would work for me. /Jarkko