Re: [PATCH] spi: Avoid setting the chip select if we don't need to

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jul 01, 2020 at 06:26:24AM +0000, Ardelean, Alexandru wrote:
> On Mon, 2020-06-29 at 16:41 -0700, Douglas Anderson wrote:

> > +	spi->controller->last_cs_enable = enable;
> > +	spi->controller->last_cs_mode_high = spi->mode & SPI_CS_HIGH;

> I don't feel like this is the best approach for the SPI CS handling,
> because it's pretty difficult to guess the last CS state, and whether this
> return would cause other weirder issues [like not toggling CS when it
> should].

There's no guesswork involved here - the only thing that should be
setting the chip select is the SPI core so other than at startup we
always know the state of the chip select.

> Maybe a question is: when should this CS be toggled [or not]?
> Is it between 2 calls of spi_transfer_one_message() or between 2
> spi_transfers?
> Or, is "xfer->cs_change == 1" where it shouldn't be?

This is well documented, it's asserted while a message is being
transferred unless changed by cs_change in which case we do whatever the
opposite of the default action is.

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux