Hi everyone, I got nerdsniped by this open PR by be  that adds an async API to `embedded-sdmmc`: https://github.com/rust-embedded-community/embedded-sdmmc-rs/pull/176

One of the issues that came up is that SD cards are weird in that when they are used on a shared SPI bus, they apparently need to receive a `0xFF` byte with CS not asserted/high after each communication, before accessing other slaves on the bus. Otherwise a bus conflict can happen because, well, SD cards are weird. The problem is that this kind of non-standard behavior is not supported by the `SpiDevice` trait. One suggestion by thejpster  was to use a second dummy `SpiDevice` on the same bus and send the `0xFF` byte to it to that the SD CS line is kept high. I think this would work in the blocking case but in async world there's no guarantee that this byte would get sent before one of the other slaves uses the bus, so it doesn't solve the problem. I can't think of any other solutions so I was curious if you guys have any ideas.

I feel like behaviors like this could be supported by an `embedded-hal` trait but I'm not sure there's enough interest for something like this. Are there other SPI devices that have weird requirements or is it just SD cards?