[coreboot] How is our SPI API supposed to work?

[Julius Werner]

> While you guys are at it, it might be worth folding spi_claim_bus()
> and spi_release_bus() into these changes so that CS is managed
> automatically for things like SPI flash transactions. Right now they
> return 0 for controllers that don't define ctrlr->claim_bus and
> ctrlr->release_bus, meaning those which do fused ops and might not
> even allow the user to manually drive CS. In those cases the behavior
> feels like silent failure since they don't even attempt to do the
> thing the user asked, yet they are required to be in the common
> codepaths for generic SPI controllers.

This is currently used in the Cr50 driver to send a little wakeup pulse on
CS (without clock) before starting the actually transaction. We also rely
on it for certain Chrome ECs that need a wakeup delay between CS assertion
and the first clock (as you may remember... you wrote that ;) ). So we
can't fully remove it without finding a different solution for those
things. In general, I'm a fan of letting software do stuff explicitly
rather than relying on controller automatism, because it allows you do
things like that and also because controllers often have their own unique
issues when they try to be too clever by themselves. I think it would be
better to keep the explicit CS controls for the controllers that can
support it, and then controllers that don't may not work correctly with
peripherals where it really matters, I guess. (FWIW on many chips you can
pinmux the CS pin to a GPIO and control it that way even if the controller
itself doesn't allow that.)