Double Transfer Rate (DTR) ops are added in spi-mem. But this controller
doesn't support DTR transactions. Since we don't use the default
supports_op(), which rejects all DTR ops, do that explicitly in our
supports_op().
Signed-off-by: Pratyush Yadav <[email protected]>
---
drivers/spi/atmel-quadspi.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/spi/atmel-quadspi.c b/drivers/spi/atmel-quadspi.c
index cb44d1e169aa..4a29fa7ebdac 100644
--- a/drivers/spi/atmel-quadspi.c
+++ b/drivers/spi/atmel-quadspi.c
@@ -285,6 +285,10 @@ static bool atmel_qspi_supports_op(struct spi_mem *mem,
op->dummy.nbytes == 0)
return false;
+ /* DTR ops not supported. */
+ if (op->cmd.dtr || op->addr.dtr || op->dummy.dtr || op->data.dtr)
+ return false;
+
return true;
}
--
2.25.0
On Sat, Apr 25, 2020 at 12:13:56AM +0530, Pratyush Yadav wrote:
> Double Transfer Rate (DTR) ops are added in spi-mem. But this controller
> doesn't support DTR transactions. Since we don't use the default
> supports_op(), which rejects all DTR ops, do that explicitly in our
> supports_op().
It's not ideal that we'd need to explicitly add checks in individual
controller drivers - are we sure that all the others do?
On 30/04/20 12:32PM, Mark Brown wrote:
> On Sat, Apr 25, 2020 at 12:13:56AM +0530, Pratyush Yadav wrote:
>
> > Double Transfer Rate (DTR) ops are added in spi-mem. But this controller
> > doesn't support DTR transactions. Since we don't use the default
> > supports_op(), which rejects all DTR ops, do that explicitly in our
> > supports_op().
>
> It's not ideal that we'd need to explicitly add checks in individual
> controller drivers - are we sure that all the others do?
Most other controllers either don't specify a supports_op function at
all, in which case spi_mem_default_supports_op() is called, or do their
custom logic and then call spi_mem_default_supports_op(). In both those
cases, DTR ops would get rejected because of the call to
spi_mem_default_supports_op(). So they do not need to add the check
explicitly there.
The two exceptions are atmel-quadspi and spi-mtk-nor (which I missed
updating). They don't call the default supports_op, so they need to be
updated to explicitly to reject DTR ops.
Earlier versions of this series discovered the DTR capability from
devicetree. In that case, no change would be required at all, but review
comments suggested I drop those changes. Instead, the controllers should
accept/reject DTR ops in their supports_op hooks.
--
Regards,
Pratyush Yadav
Texas Instruments India
On Thu, Apr 30, 2020 at 05:47:39PM +0530, Pratyush Yadav wrote:
> Most other controllers either don't specify a supports_op function at
> all, in which case spi_mem_default_supports_op() is called, or do their
> custom logic and then call spi_mem_default_supports_op(). In both those
> cases, DTR ops would get rejected because of the call to
> spi_mem_default_supports_op(). So they do not need to add the check
> explicitly there.
> The two exceptions are atmel-quadspi and spi-mtk-nor (which I missed
> updating). They don't call the default supports_op, so they need to be
> updated to explicitly to reject DTR ops.
OK.
> Earlier versions of this series discovered the DTR capability from
> devicetree. In that case, no change would be required at all, but review
> comments suggested I drop those changes. Instead, the controllers should
> accept/reject DTR ops in their supports_op hooks.
It definitely shouldn't be in device tree, this is something that the
silicon supports so we should already be able to figure out if we can
use it with just the compatible.