From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751357AbdBXL4P (ORCPT ); Fri, 24 Feb 2017 06:56:15 -0500 Received: from mga01.intel.com ([192.55.52.88]:43993 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751324AbdBXL4H (ORCPT ); Fri, 24 Feb 2017 06:56:07 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.35,200,1484035200"; d="scan'208";a="52291439" Date: Fri, 24 Feb 2017 13:55:52 +0200 From: Jarkko Sakkinen To: Peter Huewe Cc: Jason Gunthorpe , tpmdd-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org, peterhuewe@gmx.de, Christophe Ricard , stable@vger.kernel.org, Alexander Steffen Subject: Re: [PATCH 4/5] tpm_tis_spi: Remove limitation of transfers to MAX_SPI_FRAMESIZE bytes Message-ID: <20170224115552.rmg7ox2rneoz75yf@intel.com> References: <1487261306-2494-1-git-send-email-peter.huewe@infineon.com> <1487261306-2494-5-git-send-email-peter.huewe@infineon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1487261306-2494-5-git-send-email-peter.huewe@infineon.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo User-Agent: Mutt/1.6.2-neo (2016-08-21) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Feb 16, 2017 at 04:08:25PM +0000, Peter Huewe wrote: > Limiting transfers to MAX_SPI_FRAMESIZE was not expected by the upper > layers, as tpm_tis has no such limitation. Add a loop to hide that > limitation. > > Cc: > Fixes: 0edbfea537d1 ("tpm/tpm_tis_spi: Add support for spi phy") > Signed-off-by: Alexander Steffen > Signed-off-by: Peter Huewe > --- > drivers/char/tpm/tpm_tis_spi.c | 108 ++++++++++++++++++++++------------------- > 1 file changed, 57 insertions(+), 51 deletions(-) > > diff --git a/drivers/char/tpm/tpm_tis_spi.c b/drivers/char/tpm/tpm_tis_spi.c > index 16938e2253d2..b50c5b072df3 100644 > --- a/drivers/char/tpm/tpm_tis_spi.c > +++ b/drivers/char/tpm/tpm_tis_spi.c > @@ -61,68 +61,74 @@ static int tpm_tis_spi_transfer(struct tpm_tis_data *data, u32 addr, u8 len, > { > struct tpm_tis_spi_phy *phy = to_tpm_tis_spi_phy(data); > int ret; > - struct spi_message m; > - struct spi_transfer spi_xfer = { > - .tx_buf = phy->tx_buf, > - .rx_buf = phy->rx_buf, > - .len = 4, > - .cs_change = 1, > - }; > - > - if (len > MAX_SPI_FRAMESIZE) > - return -ENOMEM; > > - phy->tx_buf[0] = direction | (len - 1); > - phy->tx_buf[1] = 0xd4; > - phy->tx_buf[2] = addr >> 8; > - phy->tx_buf[3] = addr; > + spi_bus_lock(phy->spi_device->master); > > - spi_message_init(&m); > - spi_message_add_tail(&spi_xfer, &m); > + while (len) { > + struct spi_message m; > + struct spi_transfer spi_xfer = { > + .tx_buf = phy->tx_buf, > + .rx_buf = phy->rx_buf, > + .len = 4, > + .cs_change = 1, > + }; I like the habbit of keeping all the declarations in the beginning of the function as we mostly have in the subsystem. It gives a fast view what the function eats and how much stack it uses. If you really think that declaring spi_xfer here is a good idea please create a separate "helper" function for it. /Jarkko From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jarkko Sakkinen Subject: Re: [PATCH 4/5] tpm_tis_spi: Remove limitation of transfers to MAX_SPI_FRAMESIZE bytes Date: Fri, 24 Feb 2017 13:55:52 +0200 Message-ID: <20170224115552.rmg7ox2rneoz75yf@intel.com> References: <1487261306-2494-1-git-send-email-peter.huewe@infineon.com> <1487261306-2494-5-git-send-email-peter.huewe@infineon.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <1487261306-2494-5-git-send-email-peter.huewe-d0qZbvYSIPpWk0Htik3J/w@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tpmdd-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: Peter Huewe Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org, Christophe Ricard List-Id: tpmdd-devel@lists.sourceforge.net On Thu, Feb 16, 2017 at 04:08:25PM +0000, Peter Huewe wrote: > Limiting transfers to MAX_SPI_FRAMESIZE was not expected by the upper > layers, as tpm_tis has no such limitation. Add a loop to hide that > limitation. > > Cc: > Fixes: 0edbfea537d1 ("tpm/tpm_tis_spi: Add support for spi phy") > Signed-off-by: Alexander Steffen > Signed-off-by: Peter Huewe > --- > drivers/char/tpm/tpm_tis_spi.c | 108 ++++++++++++++++++++++------------------- > 1 file changed, 57 insertions(+), 51 deletions(-) > > diff --git a/drivers/char/tpm/tpm_tis_spi.c b/drivers/char/tpm/tpm_tis_spi.c > index 16938e2253d2..b50c5b072df3 100644 > --- a/drivers/char/tpm/tpm_tis_spi.c > +++ b/drivers/char/tpm/tpm_tis_spi.c > @@ -61,68 +61,74 @@ static int tpm_tis_spi_transfer(struct tpm_tis_data *data, u32 addr, u8 len, > { > struct tpm_tis_spi_phy *phy = to_tpm_tis_spi_phy(data); > int ret; > - struct spi_message m; > - struct spi_transfer spi_xfer = { > - .tx_buf = phy->tx_buf, > - .rx_buf = phy->rx_buf, > - .len = 4, > - .cs_change = 1, > - }; > - > - if (len > MAX_SPI_FRAMESIZE) > - return -ENOMEM; > > - phy->tx_buf[0] = direction | (len - 1); > - phy->tx_buf[1] = 0xd4; > - phy->tx_buf[2] = addr >> 8; > - phy->tx_buf[3] = addr; > + spi_bus_lock(phy->spi_device->master); > > - spi_message_init(&m); > - spi_message_add_tail(&spi_xfer, &m); > + while (len) { > + struct spi_message m; > + struct spi_transfer spi_xfer = { > + .tx_buf = phy->tx_buf, > + .rx_buf = phy->rx_buf, > + .len = 4, > + .cs_change = 1, > + }; I like the habbit of keeping all the declarations in the beginning of the function as we mostly have in the subsystem. It gives a fast view what the function eats and how much stack it uses. If you really think that declaring spi_xfer here is a good idea please create a separate "helper" function for it. /Jarkko ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot