On Thu, Feb 15, 2018 at 04:45:55PM +0100, Jan Kundrát wrote: > How should the interface look like? Is spi_controller->mode_bits a good > place for controllers to advertise this feature (SPI_WORD_DELAY, perhaps?) > as supported, with spi-orion being the only implementation now? If we allow Yup. > each spi_transfer to override this value, is there a common place in the SPI > core which somehow validates a spi_transfer against each controller's > capabilities? I see a code like that (bad_bits, ugly_bits) in spi_setup > which looks like something to be called per-device, not per-transfer. __spi_validate(). > 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.
Attachment:
signature.asc
Description: PGP signature
