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

[David Hendricks]

On Thu, Apr 19, 2018 at 3:54 PM, Aaron Durbin <adurbin at google.com> wrote:
> >> OK. It's just moving code around.
> >
> > Yeah, I just want to shuffle code around. Nothing is broken right now, it's
> > just working in a confusing and inconsistent way. We should have an API
> > where the callbacks share the same semantics across all implementations
> > (and also document those semantics more clearly).
>
> I can send some CLs out.

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.

The result would be that functions such as do_spi_flash_cmd() no
longer need to explicitly manage CS by claiming/releasing the SPI bus.
On the other hand, one might want to transfer one or more vectors
without toggling CS, so we may need to expose a way to leave CS alone
e.g. thru struct spi_op or another function parameter.