On Sep 06, Linus Walleij wrote: > On Thu, Sep 6, 2018 at 11:05 AM Lorenzo Bianconi > <lorenzo.bianconi@xxxxxxxxxx> wrote: > > > On Tue, Sep 04, 2018 at 11:49:49PM +0200, Linus Walleij wrote: > > > > > > > So remains to add two new permutations: > > > > bitbang_txrx_be_3wire_cpha[0|1]() and double the > > > > code in spi-bitbang-txrx.h. Not good for maintenance. > > > > > > > So damned if I do, damned if I don't. > > > > > > > But I guess I go for the latter approach? > > > > > > Yes, I think so - there's obviously a lot of overhead from bitbanging > > > this stuff so it's worth it to try to minimize it. > > > > Hi Linus and Mark, > > > > maybe here we can move flags definition in spi_bitbang_bufs routine, e.g: > > > > - return cs->txrx_bufs(spi, cs->txrx_word, nsecs, t, 0); > > + > > + if (spi->master->flags & (SPI_MASTER_NO_TX | SPI_MASTER_NO_RX)) > > + return cs->txrx_bufs(spi, cs->txrx_word, nsecs, t, > > + spi->master->flags); > > + else > > + return cs->txrx_bufs(spi, cs->txrx_word, nsecs, t, 0); > > > > in this way we can unify spi_gpio_txrx_word_mode{0-3}/spi_gpio_spec_txrx_word_mode{0-3} definitions > > in spi-gpio.c and other drivers in the future can use this optimization. What > > do you think? Are there any side affects with that approach? > > I think it's not working because real half-duplex adapters, those > who *REALLY* cannot do RX or TX will attempt to do RX and TX > anyways if we do that. Not that I know if there are any. please correct me if I am wrong but for half-duplex adapters we will have SPI_MASTER_NO_TX or SPI_MASTER_NO_RX set in master flags, so we will pass these flags to the master driver. Moreover at the moment txrx_word[] is set just in (except spi-gpio): - spi-ath79.c - spi-butterfly.c - spi-sh-sci.c - spi-lm70llp.c where flags was always set to 0 before commit 304d34360b09 and where SPI_MASTER_NO_{TX|RX} flags are not actually used. Anyway maybe there is a better solution :) Regards, Lorenzo > > AT lunch I've finally understood, maybe, what needs to be done > so I' working on some better solution. > > Yours, > Linus Walleij