| Message ID | 20200424184410.8578-3-p.yadav@ti.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | mtd: spi-nor: add xSPI Octal DTR support | expand |
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.
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.
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; }
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 <p.yadav@ti.com> --- drivers/spi/atmel-quadspi.c | 4 ++++ 1 file changed, 4 insertions(+)