On Thu, 2018-02-15 at 15:49 +0000, Mark Brown wrote: > On Thu, Feb 15, 2018 at 04:45:55PM +0100, Jan Kundrát wrote: > > > My most important use case is, however, the userspace-facing spidev, and its > > ioctl complicates stuff a bit. The relevant struct has a 16bit padding now > > (used to be 32bit prior to https://patchwork.kernel.org/patch/3715391/). Is > > it OK to use this padding for this feature? Or should I perhaps eat just > > 8bits and limit the delays to an arbitrary value of 255us? Or should I not > > care about that now and let somebody else come up with another "bigger" > > ioctl when they need that space? > > Ugh. Using the whole padding is probably OK. There could be a flag that switches delay_us from being a post xfer delay to being a post word delay. Then no need field needs to be added. If someone wants both a post word and post xfer delay in the same xfer, then they'll just need to split it, which should be possible since it must be longer than one word to need a delay after each word. Not that great either.��.n��������+%������w��{.n�����{����)��jg��������ݢj����G�������j:+v���w�m������w�������h�����٥