[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1502712773.6179.26.camel@linux.vnet.ibm.com>
Date: Mon, 14 Aug 2017 08:12:53 -0400
From: Mimi Zohar <zohar@...ux.vnet.ibm.com>
To: Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
Cc: Peter Huewe <PeterHuewe@....de>,
Ken Goldman <kgold@...ux.vnet.ibm.com>,
linux-ima-devel@...ts.sourceforge.net,
linux-security-module@...r.kernel.org,
tpmdd-devel@...ts.sourceforge.net, linux-kernel@...r.kernel.org
Subject: Re: Re: [tpmdd-devel] [PATCH] tpm: improve tpm_tis send()
performance by ignoring burstcount
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
Powered by blists - more mailing lists