Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Thu, 10 Jun 2021 15:38:01 +0530
From:   Pratyush Yadav <p.yadav@ti.com>
To:     John Thomson <git@johnthomson.fastmail.com.au>
CC:     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>,
        <linux-mtd@lists.infradead.org>, <linux-kernel@vger.kernel.org>,
        kernel test robot <lkp@intel.com>,
        Dan Carpenter <dan.carpenter@oracle.com>
Subject: Re: [PATCH] mtd: spi-nor: write support for minor aligned partitions
Message-ID: <20210610100759.v57c5wa46ky33waj@ti.com>
References: <20210608040719.14431-1-git@johnthomson.fastmail.com.au>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20210608040719.14431-1-git@johnthomson.fastmail.com.au>
User-Agent: NeoMutt/20171215
Precedence: bulk

On 08/06/21 02:07PM, John Thomson wrote:
> Do not prevent writing to mtd partitions where a partition boundary sits
> on a minor erasesize boundary.
> This addresses a FIXME that has been present since the start of the
> linux git history:
> /* Doesn't start on a boundary of major erase size */
> /* FIXME: Let it be writable if it is on a boundary of
>  * _minor_ erase size though */
> 
> Allow a uniform erase region spi-nor device to be configured
> to use the non-uniform erase regions code path for an erase with:
> CONFIG_MTD_SPI_NOR_USE_VARIABLE_ERASE=y
> 
> On supporting hardware (SECT_4K: majority of current SPI-NOR device)
> provide the facility for an erase to use the least number
> of SPI-NOR operations, as well as access to 4K erase without
> requiring CONFIG_MTD_SPI_NOR_USE_4K_SECTORS
> 
> Introduce erasesize_minor to the mtd struct,
> the smallest erasesize supported by the device

Instead of having just a major and minor erase size, wouldn't it make 
more sense to have a list of all supported erases on a sector? That is, 
instead of hard coding two erase size instead of one, how about 
generalizing the erase machinery to allow any number of erase sizes on a 
sector and then choosing the most efficient one on run time?

For example, imagine a device can support 4K, 64K, and 256K erases on 
each sector. Then you should be able to use 2 x 4K erases if you want to 
erase 8K, 2 x 64K + 1 x 4K erases for 132K and so on.

I am not very familiar with MTD erase machinery so I would like someone 
else to chime in, but I think my suggestion above is the better way 
forward.

-- 
Regards,
Pratyush Yadav
Texas Instruments Inc.