MIME-Version: 1.0
References: <c26dfdf9ce56e92d23530a09db386b283e62845d.1638289204.git.geert+renesas@glider.be>
 <20211201072328.GA31765@lst.de>
In-Reply-To: <20211201072328.GA31765@lst.de>
From:   Geert Uytterhoeven <geert@linux-m68k.org>
Date:   Wed, 1 Dec 2021 11:08:40 +0100
Message-ID: <CAMuHMdV7PbXwuBNBn4TtjXUvjzWiOQTYoOJTEACyN-k4DUj5-Q@mail.gmail.com>
Subject: Re: [PATCH/RFC -nxt] mtd_blkdevs: Set GENHD_FL_NO_PART
To:     Christoph Hellwig <hch@lst.de>
Cc:     Jens Axboe <axboe@kernel.dk>,
        Miquel Raynal <miquel.raynal@bootlin.com>,
        Richard Weinberger <richard@nod.at>,
        Vignesh Raghavendra <vigneshr@ti.com>,
        Tudor Ambarus <tudor.ambarus@microchip.com>,
        Michael Walle <michael@walle.cc>,
        Pratyush Yadav <p.yadav@ti.com>,
        MTD Maling List <linux-mtd@lists.infradead.org>,
        linux-block@vger.kernel.org,
        Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Hi Christoph,

On Wed, Dec 1, 2021 at 8:23 AM Christoph Hellwig <hch@lst.de> wrote:
> On Tue, Nov 30, 2021 at 05:23:46PM +0100, Geert Uytterhoeven wrote:
> > When DT declares the partitions of an spi-nor device using
> > "fixed-partitions", the individual mtdblockN partitions are now scanned
> > for partitition tables, which should not happen.
> >
> > Fix this by setting the GENHD_FL_NO_PART flag in the MTD block layer
> > interface.
> >
> > Fixes: 1ebe2e5f9d68e94c ("block: remove GENHD_FL_EXT_DEVT")
> > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > ---
> > Seen with e.g. arch/arm/boot/dts/r8a7791-koelsch.dts.
> > I only noticed because I have debug code to measure QSPI performance,
> > which informed me about 8 x 512 bytes being read from each partition
> > detected.
> >
> > RFC as I'm not sure this is correct in all cases.
> > I did verify that in the absence of "fixed-partitions", the spi-nor
> > device is not scanned for partitions before and after commit
> > 1ebe2e5f9d68e94c.
>
> As far as I can tell mtd fixed partitions have nothing to do with
> the block layer concept of partitions.  What kind of behavior change
> did you see?

After the aforementioned commit, 8 x 512 bytes are being read from
the start of each partition described by "fixed-partitions".
Dmesg difference with debug print added to spi_nor_spimem_read_data():

  renesas_spi e6b10000.spi: registered master spi0
  spi spi0.0: setup mode 3, 8 bits/w, 30000000 Hz max --> 0
  spi-nor spi0.0: s25fl512s (65536 Kbytes)
  3 fixed-partitions partitions found on MTD device spi0.0
  Creating 3 MTD partitions on "spi0.0":
  0x000000000000-0x000000080000 : "loader"
+ spi-nor spi0.0: spi_nor_spimem_read_data: from 0 len 512
+ spi-nor spi0.0: spi_nor_spimem_read_data: from 512 len 512
+ spi-nor spi0.0: spi_nor_spimem_read_data: from 1024 len 512
+ spi-nor spi0.0: spi_nor_spimem_read_data: from 1536 len 512
+ spi-nor spi0.0: spi_nor_spimem_read_data: from 2048 len 512
+ spi-nor spi0.0: spi_nor_spimem_read_data: from 2560 len 512
+ spi-nor spi0.0: spi_nor_spimem_read_data: from 3072 len 512
+ spi-nor spi0.0: spi_nor_spimem_read_data: from 3584 len 512
  0x000000080000-0x000000600000 : "user"
+ spi-nor spi0.0: spi_nor_spimem_read_data: from 524288 len 512
+ spi-nor spi0.0: spi_nor_spimem_read_data: from 524800 len 512
+ spi-nor spi0.0: spi_nor_spimem_read_data: from 525312 len 512
+ spi-nor spi0.0: spi_nor_spimem_read_data: from 525824 len 512
+ spi-nor spi0.0: spi_nor_spimem_read_data: from 526336 len 512
+ spi-nor spi0.0: spi_nor_spimem_read_data: from 526848 len 512
+ spi-nor spi0.0: spi_nor_spimem_read_data: from 527360 len 512
+ spi-nor spi0.0: spi_nor_spimem_read_data: from 527872 len 512
  0x000000600000-0x000004000000 : "flash"
+ spi-nor spi0.0: spi_nor_spimem_read_data: from 6291456 len 512
+ spi-nor spi0.0: spi_nor_spimem_read_data: from 6291968 len 512
+ spi-nor spi0.0: spi_nor_spimem_read_data: from 6292480 len 512
+ spi-nor spi0.0: spi_nor_spimem_read_data: from 6292992 len 512
+ spi-nor spi0.0: spi_nor_spimem_read_data: from 6293504 len 512
+ spi-nor spi0.0: spi_nor_spimem_read_data: from 6294016 len 512
+ spi-nor spi0.0: spi_nor_spimem_read_data: from 6294528 len 512
+ spi-nor spi0.0: spi_nor_spimem_read_data: from 6295040 len 512
  renesas_spi e6b10000.spi: registered child spi0.0
  renesas_spi e6b10000.spi: probed

Thanks!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds