I'm interfacing with a Silicon Labs ZigBee chip as a network co-processor using their EZSP protocol over SPI (that's documented here FYI). It's a bit non-standard in that they expect you to transmit a command frame, then continue reading off the SPI until a response has been received (which can take up to 300ms). During this whole time, the chip select must stay active, then get released when the whole transaction is done.

The devfs/spidev driver has a struct that contains a csChange field, however that is not exposed anywhere. I tried tweaking the payload in the source to set csChange to 1, and that does seem to give me the behavior that I want in that I can keep submitting multiple Tx() calls and keep the chip select enabled.

This is the basic flow I'll need to make this work:

1. Send a message payload with the bytes of the EZSP command. Set csChange to 1 for this payload so chip select stays enabled.
2. Repeatedly send small (~8 byte) message payloads and read equal amounts of response, keeping csChange at 1.
3. Once one of these calls returns bytes that contain the EZSP response frame terminator, send an empty payload that sets csChange to its default value of 0.

I'm happy to attempt this change myself but thought it would be good to see if anybody has thought about how this might fit in with the Driver and Device interfaces (especially @rakyll).

Thanks!