lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20130630161748.GB786@mwesterb-mobl.lan>
Date:	Sun, 30 Jun 2013 19:17:48 +0300
From:	Mika Westerberg <mika.westerberg@....fi>
To:	Ryan Mallon <rmallon@...il.com>
Cc:	H Hartley Sweeten <hartleys@...ionengravers.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	spi-devel-general@...ts.sourceforge.net, broonie@...nel.org,
	grant.likely@...aro.org
Subject: Re: [PATCH 4/8] spi: spi-ep93xx: remove bits_per_word() helper

On Sat, Jun 29, 2013 at 09:21:48AM +1000, Ryan Mallon wrote:
> On 29/06/13 04:44, H Hartley Sweeten wrote:
> 
> > This inline helper function is only used to determine the bus width
> > of the current transfer (8 or 16 bit). Add a bool flag to the private
> > structure and set it appropriately for each transfer.
> > 
> > Signed-off-by: H Hartley Sweeten <hsweeten@...ionengravers.com>
> > Cc: Ryan Mallon <rmallon@...il.com>
> > Cc: Mika Westerberg <mika.westerberg@....fi>
> > Cc: Mark Brown <broonie@...nel.org>
> > Cc: Grant Likely <grant.likely@...aro.org>
> > ---
> >  drivers/spi/spi-ep93xx.c | 16 +++++-----------
> >  1 file changed, 5 insertions(+), 11 deletions(-)
> > 
> > diff --git a/drivers/spi/spi-ep93xx.c b/drivers/spi/spi-ep93xx.c
> > index bcfd35a..4fab3bb 100644
> > --- a/drivers/spi/spi-ep93xx.c
> > +++ b/drivers/spi/spi-ep93xx.c
> > @@ -116,6 +116,7 @@ struct ep93xx_spi {
> >  	unsigned long			min_rate;
> >  	unsigned long			max_rate;
> >  	bool				running;
> > +	bool				word_xfer;
> 
> 
> I think this is a slightly confusing name. Maybe something like
> is_16bit_xfer would be better?
> 
> >  	struct workqueue_struct		*wq;
> >  	struct work_struct		msg_work;
> >  	struct completion		wait;
> > @@ -407,17 +408,9 @@ static void ep93xx_spi_chip_setup(const struct ep93xx_spi *espi,
> >  	writew(cr0, espi->regs_base + SSPCR0);
> >  }
> >  
> > -static inline int bits_per_word(const struct ep93xx_spi *espi)
> > -{
> > -	struct spi_message *msg = espi->current_msg;
> > -	struct spi_transfer *t = msg->state;
> > -
> > -	return t->bits_per_word;
> > -}
> > -
> >  static void ep93xx_do_write(struct ep93xx_spi *espi, struct spi_transfer *t)
> >  {
> > -	if (bits_per_word(espi) > 8) {
> > +	if (espi->word_xfer) {
> >  		u16 tx_val = 0;
> >  
> >  		if (t->tx_buf)
> > @@ -436,7 +429,7 @@ static void ep93xx_do_write(struct ep93xx_spi *espi, struct spi_transfer *t)
> >  
> >  static void ep93xx_do_read(struct ep93xx_spi *espi, struct spi_transfer *t)
> >  {
> > -	if (bits_per_word(espi) > 8) {
> > +	if (espi->word_xfer) {
> >  		u16 rx_val;
> >  
> >  		rx_val = readw(espi->regs_base + SSPDR);
> > @@ -522,7 +515,7 @@ ep93xx_spi_dma_prepare(struct ep93xx_spi *espi, enum dma_transfer_direction dir)
> >  	size_t len = t->len;
> >  	int i, ret, nents;
> >  
> > -	if (bits_per_word(espi) > 8)
> > +	if (espi->word_xfer)
> >  		buswidth = DMA_SLAVE_BUSWIDTH_2_BYTES;
> >  	else
> >  		buswidth = DMA_SLAVE_BUSWIDTH_1_BYTE;
> > @@ -699,6 +692,7 @@ static void ep93xx_spi_process_transfer(struct ep93xx_spi *espi,
> >  
> >  	ep93xx_spi_chip_setup(espi, chip);
> >  
> > +	espi->word_xfer = (t->bits_per_word > 8) ? true : false;
> 
> 
> 	espi->word_xfer = (t->bits_per_word > 8);

Or even
	espi->word_xfer = t->bits_per_word > 8;

> This patch is fine, but not sure it is entirely worth it. The
> information is already stored in t->bits_per_word and the cost
> of retrieving it is pretty minimal.

I agree.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ