Le 28/02/2022 à 17:14, Mark Brown a écrit : > >> We discussed that back in 2016 in >> https://lore.kernel.org/linux-spi/20160824112701.GE22076@xxxxxxxxxxxxx/ >> and my understanding at that time was that it was not something that >> could be done at core level. > >> But maybe things have changed since then ? > > What I said then was "it would need a new core feature" which is what > the binding does, I'm suggesting that you also do that for the handling > of the implementation as well. > > Actually now I think about it perhaps this shouldn't be a binding at all > but rather something specified by the client driver - presumably any > system using an affected device is going to need these extra clock > cycles so they'll all need to add the same property. Yes indeed. Therefore in v3 I took a different approach : a flag .cs_off tells to spi_transfer_one_message() that a given transfer has to be performed with chipselect OFF, therefore the consumer has full control of how and when to add those additional fake clock cycles during a transfer, and can eventually add one at anyplace during the transfer. Here an exemple of what will do the consumer. static int idt821034_8bit_write(struct idt821034 *idt821034, u8 val) { struct spi_transfer xfer[] = {{ .tx_buf = &idt821034->spi_tx_buf, .len = 1, },{ .tx_buf = &idt821034->spi_tx_buf, .len = 1, .cs_off = 1, }}; int ret; idt821034->spi_tx_buf = val; ret = spi_sync_transfer(idt821034->spi, xfer, ARRAY_SIZE(xfer)); if (ret) return ret; return 0; } Christophe
