The SPI sharing utilities are broken for fallible chipselect pins

Start by locating the SPI sharing utilities and reviewing how they handle fallible chipselect errors. Compare the three options in the issue, then confirm the intended policy with maintainers; done requires an agreed approach that prevents concurrent transactions after chipselect failure and corresponding tests or documentation.

This affects all the spi sharing utilities in some way, but I would like to highlight the worst case scenario:

• You are using the mutex or critical section impl
• In thread 1 you do a transaction to device A, but the cs pin fails to deassert
• Before thread 1 even has a chance to react to the error, it is preempted by thread 2
• Thread 2 does a transaction to device B while the cs for device A is still active
• This leads to data corruption at best, and physical damage at worst

Option 1: Infallible only

CS: OutputPin<Error = Infallible>

This is the simplest option. In fact it is even simpler than the existing impls because it allows us to remove the DeviceError enum.

You can still use fallible chipselect pins if you wrap them in some sort of adapter that panics on failure. We could even provide such an adapter.

Option 2: track "poisoned" chipselects

I have some idea how to implement this, it would involve adding a shared flag to each bus, as well as another flag for each SpiDevice. The impl would refuse to do any spi transactions until the offending chipselect is fixed.

This would be a lot of extra overhead and complexity that is completely unnecessary for 99.9% of users. I don't think the compiler will be able to remove the unnecessary overhead.

Option 3: do nothing

Document the broken error handling, how to work around it, and where it is impossible to work around.

If we want to be thorough, the amount of warnings and disclaimers will probably outweigh the amount of actual code:

Conclusions

If you only have infallible chipselect pins, or if you want to panic on chipselect failure, option 1 is the best.

If you actually want to try to gracefully recover from chipselect errors, option 2 is the only real option.

Option 3 isn't good for either group. It is slightly inconvenient for the first group, and it is almost impossible to use correctly for the second group

My recommendation is option 1 because it is the best option for most people. If someone really needs option 2, they can write it for themself, it doesn't need to be in our crate.