From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753353AbcG2R1P (ORCPT ); Fri, 29 Jul 2016 13:27:15 -0400 Received: from quartz.orcorp.ca ([184.70.90.242]:38179 "EHLO quartz.orcorp.ca" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753130AbcG2R1N (ORCPT ); Fri, 29 Jul 2016 13:27:13 -0400 Date: Fri, 29 Jul 2016 11:27:02 -0600 From: Jason Gunthorpe To: Andrey Pronin Cc: Jarkko Sakkinen , Peter Huewe , Marcel Selhorst , Christophe Ricard , tpmdd-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org, dtor@chromium.org Subject: Re: [PATCH] tpm: fix cacheline alignment for DMA-able buffers Message-ID: <20160729172702.GB7020@obsidianresearch.com> References: <1469761153-85576-1-git-send-email-apronin@chromium.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1469761153-85576-1-git-send-email-apronin@chromium.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Broken-Reverse-DNS: no host name found for IP address 10.0.0.151 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 28, 2016 at 07:59:13PM -0700, Andrey Pronin wrote: > Annotate buffers used in spi transactions as ____cacheline_aligned > to use in DMA transfers. > > Signed-off-by: Andrey Pronin > drivers/char/tpm/st33zp24/spi.c | 4 ++-- > drivers/char/tpm/tpm_tis_spi.c | 4 ++-- > 2 files changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/char/tpm/st33zp24/spi.c b/drivers/char/tpm/st33zp24/spi.c > index 9f5a011..0e9aad9 100644 > +++ b/drivers/char/tpm/st33zp24/spi.c > @@ -70,8 +70,8 @@ > struct st33zp24_spi_phy { > struct spi_device *spi_device; > > - u8 tx_buf[ST33ZP24_SPI_BUFFER_SIZE]; > - u8 rx_buf[ST33ZP24_SPI_BUFFER_SIZE]; > + u8 tx_buf[ST33ZP24_SPI_BUFFER_SIZE] ____cacheline_aligned; > + u8 rx_buf[ST33ZP24_SPI_BUFFER_SIZE] ____cacheline_aligned; > > int io_lpcpd; > int latency; Hurm, this still looks wrong to me. Aligning the start of buffers is not enough, the DMA'able space must also end on a cache line as well. So, the buffers must also always be placed at the end of the struct. IMHO It would be cleaner and safer to always kmalloc the DMA buffer alone than to try and optimize like this. Jason