[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230421164838.52euobr5ohfyxxti@mobilestation>
Date: Fri, 21 Apr 2023 19:48:38 +0300
From: Serge Semin <fancer.lancer@...il.com>
To: David Laight <David.Laight@...LAB.COM>
Cc: 'Joy Chakraborty' <joychakr@...gle.com>,
Mark Brown <broonie@...nel.org>,
Andy Shevchenko <andriy.shevchenko@...el.com>,
"linux-spi@...r.kernel.org" <linux-spi@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"manugautam@...gle.com" <manugautam@...gle.com>,
"rohitner@...gle.com" <rohitner@...gle.com>
Subject: Re: [PATCH v8 5/5] spi: dw: Round of n_bytes to power of 2
On Fri, Apr 21, 2023 at 04:39:30PM +0000, David Laight wrote:
> From: Joy Chakraborty
> > Sent: 21 April 2023 10:22
> ...
> > Sure, I can make the following change in the formatting and send the
> > patch series:
> > dws->n_bytes =
> > roundup_pow_of_two(DIV_ROUND_UP(transfer->bits_per_word,
> > BITS_PER_BYTE));
>
> Won't checkpatch bleat about that?
Why would it?
>
> Is it ever actually valid for the caller to provide a
> value that isn't 8, 16 or 32 ?
Judging by this
https://elixir.bootlin.com/linux/v6.3-rc7/source/drivers/spi/spi.c#L3630
it is. SPI-controller also supports word lengths within the
pre-synthesized range. So it's up to the SPI-peripherals and their
protocols what word length to select.
-Serge(y)
>
> I'm sure it looked as though some other lengths/counts
> where likely to go badly wrong.
>
> I know there are times when it is useful to bit-bang 'odd'
> numbers of bits - like command+address+delay for fast reads
> but that is a sub-32bit transfer so (at least somewhere)
> is 1 word but not all the bits.
>
> David
>
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
> Registration No: 1397386 (Wales)
Powered by blists - more mailing lists