linux-kernel - Re: [PATCH 1/2] spi: spi-mem: add spi_mem_dtr_supports

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 5 Feb 2021 10:44:13 +0100
From:   Miquel Raynal <miquel.raynal@...tlin.com>
To:     Pratyush Yadav <p.yadav@...com>
Cc:     Mark Brown <broonie@...nel.org>, <linux-spi@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <zhengxunli@...c.com.tw>
Subject: Re: [PATCH 1/2] spi: spi-mem: add spi_mem_dtr_supports_op()

Hi Pratyush,

Pratyush Yadav <p.yadav@...com> wrote on Thu, 4 Feb 2021 19:42:17 +0530:

> spi_mem_default_supports_op() rejects DTR ops by default to ensure that
> the controller drivers that haven't been updated with DTR support
> continue to reject them. It also makes sure that controllers that don't
> support DTR mode at all (which is most of them at the moment) also
> reject them.
> 
> This means that controller drivers that want to support DTR mode can't
> use spi_mem_default_supports_op(). Driver authors have to roll their own
> supports_op() function and mimic the buswidth checks. See
> spi-cadence-quadspi.c for example. Or even worse, driver authors might
> skip it completely or get it wrong.
> 
> Add spi_mem_dtr_supports_op(). It provides a basic sanity check for DTR
> ops and performs the buswidth requirement check. Move the logic for
> checking buswidth in spi_mem_default_supports_op() to a separate
> function so the logic is not repeated twice.
> 
> Signed-off-by: Pratyush Yadav <p.yadav@...com>

I am not a SPI-NOR expert but for what I know this approach looks good
to me. Let's see what other maintainers think.

Reviewed-by: Miquel Raynal <miquel.raynal@...tlin.com>

Thanks,
Miquèl