linux-kernel - Re: [PATCH v3 00/14] mtd: spi-nor: add xSPI Octal DTR support

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: <20200528102609.0dbb59a5@collabora.com>
Date:   Thu, 28 May 2020 10:26:09 +0200
From:   Boris Brezillon <boris.brezillon@...labora.com>
To:     Mason Yang <masonccyang@...c.com.tw>
Cc:     broonie@...nel.org, tudor.ambarus@...rochip.com,
        miquel.raynal@...tlin.com, richard@....at, vigneshr@...com,
        matthias.bgg@...il.com, p.yadav@...com, juliensu@...c.com.tw,
        linux-kernel@...r.kernel.org, linux-mtd@...ts.infradead.org,
        linux-spi@...r.kernel.org
Subject: Re: [PATCH v3 00/14] mtd: spi-nor: add xSPI Octal DTR support

On Thu, 28 May 2020 15:58:02 +0800
Mason Yang <masonccyang@...c.com.tw> wrote:

> Hello,
> 
> JESD216C has defined specification for Octal 8S-8S-8S and 8D-8D-8D.
> Based on JEDEC216C Basic Flash Parameter Table (BFPT) driver extract
> DWORD-18: command and command extension type.
> DWORD-20: Maximum operation speed of device in Octal mode.
> 
> xSPI profile 1.0 table:
> DWORD-1: Read Fast command, the number of dummy cycles and address nbytes
> 	 for Read Status Register command.
> DWORD-2: Read/Write volatile Register command for CFG Reg2.
> DWORD-4 and DWORD-5: dummy cycles used for various frequencies based on
> maximum speed of device from BFPT 20th DWORD.
> 
> Ccommand sequences to change to octal DTR mode:
> The length of each command sequence is 8 per byte for single SPI mode and
> patching driver to parse and execute these sequences for octal DTR mode.
> 
> By Vignesh's comments to patch these drivers based on Pratyush's patches
> set [1].
> 
> This series adds support for Macronix mx25uw51245g works in octal DTR mode.
> 
> Tested on Macronix's Zynq PicoZed board with Macronix's SPI controller
> (spi-mxic.c) driver patched on mx25uw51245g Octal flash.
> 
> 
> [1] https://patchwork.ozlabs.org/project/linux-mtd/cover/20200525091544.17270-1-p.yadav@ti.com/
> 
> 
> Summary of change log
> v3:
> Add support command sequences to change octal DTR mode and based on
> part of Pratyush's patches set.
> 
> v2: 
> Parse BFPT & xSPI table for Octal 8D-8D-8D mode parameters and enable Octal
> mode in spi_nor_late_init_params().
> Using Macros in spi_nor_spimem_read_data, spi_nor_spimem_write_data and
> so on by Vignesh comments.
> 
> v1:
> Without parsing BFPT & xSPI profile 1.0 table and enter Octal 8D-8D-8D
> mode directly in spi_nor_fixups hooks.
> 
> 
> thnaks for your time and review.
> best regards,
> Mason
> 
> --
> Mason Yang (7):
>   mtd: spi-nor: sfdp: get octal mode maximum speed from BFPT
>   mtd: spi-nor: sfdp: parse xSPI Profile 1.0 table
>   mtd: spi-nor: sfdp: parse command sequences to change octal DTR mode
>   mtd: spi-nor: core: add configuration register 2 read & write support
>   spi: mxic: patch for octal DTR mode support
>   mtd: spi-nor: core: execute command sequences to change octal DTR mode
>   mtd: spi-nor: macronix: Add Octal 8D-8D-8D supports for Macronix
>     mx25uw51245g
> 
> Pratyush Yadav (7):
>   spi: spi-mem: allow specifying whether an op is DTR or not
>   spi: spi-mem: allow specifying a command's extension
>   mtd: spi-nor: add support for DTR protocol
>   mtd: spi-nor: sfdp: prepare BFPT parsing for JESD216 rev D
>   mtd: spi-nor: sfdp: get command opcode extension type from BFPT
>   mtd: spi-nor: core: use dummy cycle and address width info from SFDP
>   mtd: spi-nor: core: enable octal DTR mode when possible

Why are you doing that?! This series is being actively worked on by
Pratyush, and all you gain by sending it on your own is more
confusion. If you have patches on top of a series that's not been
merged yet, mention the dependency in the cover letter, but don't
resend patches that have already been sent and are being reviewed.

I think it's time you spend a bit of time learning about the submission
process, because that's not the first mistake you do, and I'm pretty
sure I already mentioned that in my previous reviews.