Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753954AbbLJQtZ (ORCPT ); Thu, 10 Dec 2015 11:49:25 -0500 Received: from mail.kmu-office.ch ([178.209.48.109]:34219 "EHLO mail.kmu-office.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753157AbbLJQtR (ORCPT ); Thu, 10 Dec 2015 11:49:17 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Date: Thu, 10 Dec 2015 08:47:36 -0800 From: Stefan Agner To: Bhuvanchandra DV Cc: broonie@kernel.org, linux-spi@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] spi-fsl-dspi: Fix CTAR Register access In-Reply-To: <1449726930-7378-1-git-send-email-bhuvanchandra.dv@toradex.com> References: <1449726930-7378-1-git-send-email-bhuvanchandra.dv@toradex.com> Message-ID: <6feb4fcd2930f4cc50a9a75565a8e764@agner.ch> User-Agent: Roundcube Webmail/1.1.3 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3453 Lines: 88 On 2015-12-09 21:55, Bhuvanchandra DV wrote: > DSPI instances in Vybrid have a different amount of chip selects > and CTARs (Clock and transfer Attributes Register). In case of > DSPI1 we only have 2 CTAR registers and 4 CS. In present driver > implementation CTAR offset is derived from CS instance which will > lead to out of bound access if chip select instance is greater than > CTAR register instance, hence use single CTAR0 register for all CS > instances. Since we write the CTAR register anyway before each access, > there is no value in using the additional CTAR registers. Also one > should not program a value in CTAS for a CTAR register that is not > present, hence configure CTAS to use CTAR0. This looks to me to be the easiest way to solve the issue for all DSPI instances. Acked-by: Stefan Agner > > Signed-off-by: Bhuvanchandra DV > --- > drivers/spi/spi-fsl-dspi.c | 12 ++++++------ > 1 file changed, 6 insertions(+), 6 deletions(-) > > diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c > index 59a1143..39412c9 100644 > --- a/drivers/spi/spi-fsl-dspi.c > +++ b/drivers/spi/spi-fsl-dspi.c > @@ -167,7 +167,7 @@ static inline int is_double_byte_mode(struct fsl_dspi *dspi) > { > unsigned int val; > > - regmap_read(dspi->regmap, SPI_CTAR(dspi->cs), &val); > + regmap_read(dspi->regmap, SPI_CTAR(0), &val); > > return ((val & SPI_FRAME_BITS_MASK) == SPI_FRAME_BITS(8)) ? 0 : 1; > } > @@ -257,7 +257,7 @@ static u32 dspi_data_to_pushr(struct fsl_dspi > *dspi, int tx_word) > > return SPI_PUSHR_TXDATA(d16) | > SPI_PUSHR_PCS(dspi->cs) | > - SPI_PUSHR_CTAS(dspi->cs) | > + SPI_PUSHR_CTAS(0) | > SPI_PUSHR_CONT; > } > > @@ -290,7 +290,7 @@ static int dspi_eoq_write(struct fsl_dspi *dspi) > */ > if (tx_word && (dspi->len == 1)) { > dspi->dataflags |= TRAN_STATE_WORD_ODD_NUM; > - regmap_update_bits(dspi->regmap, SPI_CTAR(dspi->cs), > + regmap_update_bits(dspi->regmap, SPI_CTAR(0), > SPI_FRAME_BITS_MASK, SPI_FRAME_BITS(8)); > tx_word = 0; > } > @@ -339,7 +339,7 @@ static int dspi_tcfq_write(struct fsl_dspi *dspi) > > if (tx_word && (dspi->len == 1)) { > dspi->dataflags |= TRAN_STATE_WORD_ODD_NUM; > - regmap_update_bits(dspi->regmap, SPI_CTAR(dspi->cs), > + regmap_update_bits(dspi->regmap, SPI_CTAR(0), > SPI_FRAME_BITS_MASK, SPI_FRAME_BITS(8)); > tx_word = 0; > } > @@ -407,7 +407,7 @@ static int dspi_transfer_one_message(struct > spi_master *master, > regmap_update_bits(dspi->regmap, SPI_MCR, > SPI_MCR_CLR_TXF | SPI_MCR_CLR_RXF, > SPI_MCR_CLR_TXF | SPI_MCR_CLR_RXF); > - regmap_write(dspi->regmap, SPI_CTAR(dspi->cs), > + regmap_write(dspi->regmap, SPI_CTAR(0), > dspi->cur_chip->ctar_val); > > trans_mode = dspi->devtype_data->trans_mode; > @@ -566,7 +566,7 @@ static irqreturn_t dspi_interrupt(int irq, void *dev_id) > if (!dspi->len) { > if (dspi->dataflags & TRAN_STATE_WORD_ODD_NUM) { > regmap_update_bits(dspi->regmap, > - SPI_CTAR(dspi->cs), > + SPI_CTAR(0), > SPI_FRAME_BITS_MASK, > SPI_FRAME_BITS(16)); > dspi->dataflags &= ~TRAN_STATE_WORD_ODD_NUM; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/