linux-kernel - RE: [PATCH v3 2/2] spi: cadence: add support for Cadence XSPI controller

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]

Message-ID: <CY4PR07MB275737A008CBB58C4B108D2FC1D49@CY4PR07MB2757.namprd07.prod.outlook.com>
Date:   Wed, 8 Sep 2021 07:27:35 +0000
From:   Parshuram Raju Thombare <pthombar@...ence.com>
To:     Pratyush Yadav <p.yadav@...com>
CC:     "broonie@...nel.org" <broonie@...nel.org>,
        "lukas@...ner.de" <lukas@...ner.de>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "linux-spi@...r.kernel.org" <linux-spi@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Jayshri Dajiram Pawar <jpawar@...ence.com>,
        Milind Parab <mparab@...ence.com>,
        Konrad Kociolek <konrad@...ence.com>,
        Tudor Ambarus <tudor.ambarus@...rochip.com>,
        Vignesh Raghavendra <vigneshr@...com>
Subject: RE: [PATCH v3 2/2] spi: cadence: add support for Cadence XSPI
 controller

>Depends on SPI_MEM as well.

Ok

>I commented on this last time around as well. This does not look right
>at all. A SPI MEM based driver should *not* need to know anything about
>the subsystem driving it. That is the entire point of the API.
>
>The controller seems to be able to extract the read and write opcodes
>from the SFDP on its own since you don't pass in that information to
>cdns_xspi_nor_read(). It looks like it is tied very heavily to a NOR
>flash, and I am not sure if it can really be used with a NAND flash, or
>something else entirely.
>
>Which makes me wonder how we should handle controllers like these. I
>don't think they fit in very well with the SPI MEM model, since they
>can't execute arbitrary SPI MEM commands very well. At the same time we
>are trying to get rid of mtd/spi-nor/controllers. Dunno...
>
>Mark, Tudor, Vignesh, any ideas?

Ok, then for now I will drop ACMD PIO mode and use only STIG mode.
In STIG mode driver configures bus width and clock edge mode for
command, address and data for each operation. 

Regards,
Parshuram Thombare