Hi.  Is it legal to use zero for 'len' field of struct spi_transfer?

I mean, len=0, tx_buf=rx_buf=NULL, delay_usecs!=0.
Some SPI devices need slightly long delay before first CLK edge after

CS assertion.  To achieve this, I think inserting using a zero length

transfer before real transfers.  But it seems some drivers do not

handle this case properly.
Is this driver's bug, or we need additional delay field in struct

spi_device for such case?
---

Atsushi Nemoto

--

Yes that should work ... it's uncommon, but not illegal.  Some

controller drivers may even handle that right!
If the delay were zero and cs_change didn't indicate a need to

briefly deselect the chip, it might make sense to reject such
For future reference ... could you identify a few such devices,

and say what "long" is relative to the clock period?
Some folk have just slowed down the clock in such cases, but
I'd like to avoid new parameters to cover case that can already

be expressed in the programming interface.  Cases that can't be

expressed ... different issue.  I suspect any patches updating

timing parameters should use nanoseconds not microseconds, fwiw.
- Dave

--

Thank you.  I suppose spi-bitbang can handle that right.  Then I'm
Well, the device I have is so special custom one implemented by PIC or

something.  It needs 100us or so with 200ns clock period.  Slowing

down might be an another solution but some spi driver cannot use such
OK, if I had enough time to make a patch for uptodate version of the

driver ;)
---

Atsushi Nemoto

--