Re: [RFC PATCH 1/6] spi: Extend the core to ease integration of SPI memory controllers

Boris Brezillon
2018-02-19T14:32:51Z

On Mon, 19 Feb 2018 14:00:03 +0000
Mark Brown <broonie@kernel.org> wrote:

> On Tue, Feb 06, 2018 at 12:21:15AM +0100, Boris Brezillon wrote:
>
> > + /*
> > + * The controller can implement only the high-level SPI-memory like
> > + * operations if it does not support regular SPI transfers.
> > + */
> > + if (ctlr->mem_ops) {
> > + if (!ctlr->mem_ops->supports_op ||
> > + !ctlr->mem_ops->exec_op)
> > + return -EINVAL;
> > + } else if (!ctlr->transfer && !ctlr->transfer_one &&
> > + !ctlr->transfer_one_message) {
> > + return -EINVAL;
> > + }
>
> BTW your comment isn't describing what the code does - the comment says
> that having the memory operations means the driver can't be a regular
> SPI controller while the code does not do that and only checks that if a
> driver has memory ops it implements two required ones. Indeed the
> existing drivers that are updated to the new API continue to implement
> normal SPI operations.

Definitely not what I wanted to say :-/. I guess replacing 'can' by
'may' would be more appropriate. What I want to say is that SPI
controllers do not have to implement the hooks for regular SPI
operations if they only support SPI-mem like operations, but of course
they can implement those hooks if they support both spi_mem and regular
SPI ops.

This check is here to allow registration of SPI controllers that
support spi_mem ops, regular ops or both, and prevent registration if
both spi_mem and regular hooks are missing.

Is it clearer?

--
Boris Brezillon, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering