[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200430121926.GC4633@sirena.org.uk>
Date: Thu, 30 Apr 2020 13:19:26 +0100
From: Mark Brown <broonie@...nel.org>
To: Pratyush Yadav <p.yadav@...com>
Cc: Tudor Ambarus <tudor.ambarus@...rochip.com>,
Miquel Raynal <miquel.raynal@...tlin.com>,
Richard Weinberger <richard@....at>,
Vignesh Raghavendra <vigneshr@...com>,
Nicolas Ferre <nicolas.ferre@...rochip.com>,
Alexandre Belloni <alexandre.belloni@...tlin.com>,
Ludovic Desroches <ludovic.desroches@...rochip.com>,
linux-mtd@...ts.infradead.org, linux-kernel@...r.kernel.org,
linux-spi@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
Sekhar Nori <nsekhar@...com>
Subject: Re: [PATCH v4 02/16] spi: atmel-quadspi: reject DTR ops
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.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists