Le 22/08/2022 à 19:15, Mark Brown a écrit : > On Thu, Aug 18, 2022 at 06:35:39PM +0000, Christophe Leroy wrote: > >> 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. > > Hrm, we should already be able to synthesize that with cs_change though > there's usability challenges there and AFAICT it doesn't work for the > first transfer which your proposal would so there's a functional benefit > even if you don't need it for your device right now. It would be good > if you could have a look at using cs_change for your use case. Sorry, I > don't think I'd fully realised what you were looking to accomplish here > until I saw your proposal. I think we already addressed this possibility back in 2016, see https://lore.kernel.org/linux-spi/20160824111206.GD22076@xxxxxxxxxxxxx/ The conclusion was that it was not possible to accomplish it with cs_change. Or did we miss something at that time ? My understanding is that if you set cs_change for any transfer of a message except the last, then CS goes OFF then ON again between the said transfer and the following one. If you set cs_change for the last transfer of a message, then CS stays ON until next message instead of going OFF as usual. My need is to transfer a fake byte with CS off at the end of a message. I still can't see how cs_change can achieve that. Thanks Christophe
