From: Takahiro Kuwano <tkuw584924@gmail.com>
To: Michael Walle <mwalle@kernel.org>
Cc: linux-mtd@lists.infradead.org, tudor.ambarus@linaro.org,
pratyush@kernel.org, miquel.raynal@bootlin.com, richard@nod.at,
vigneshr@ti.com, Bacem.Daassi@infineon.com,
Takahiro Kuwano <Takahiro.Kuwano@infineon.com>
Subject: Re: [PATCH] mtd: spi-nor: core: Set mtd->eraseregions for non-uniform erase map
Date: Fri, 19 Jan 2024 15:29:09 +0900 [thread overview]
Message-ID: <d63b6363-2d90-4fed-97c3-be69948aae57@gmail.com> (raw)
In-Reply-To: <d9cf5631-951e-45a0-930f-cc3afac05df9@gmail.com>
On 1/12/2024 4:14 PM, Takahiro Kuwano wrote:
> On 1/5/2024 9:23 PM, Michael Walle wrote:
>> Hi,
>>
>>> -static void spi_nor_set_mtd_info(struct spi_nor *nor)
>>> +static int spi_nor_set_mtd_eraseregions(struct spi_nor *nor)
>>> +{
>>> + struct spi_nor_erase_map *map = &nor->params->erase_map;
>>> + struct spi_nor_erase_region *region = map->regions;
>>> + struct mtd_info *mtd = &nor->mtd;
>>> + struct mtd_erase_region_info *mtd_region;
>>> + u32 erase_size;
>>> + u8 erase_mask;
>>> + int n_regions, i, j;
>>> +
>>> + for (i = 0; !spi_nor_region_is_last(®ion[i]); i++)
>>> + ;
>>
>> Please put that into a helper which returns the number of regions.
>>
> Yes, I will do it.
>
>> FWIW, I really dislike the magic around encoding all sorts of stuff
>> into the offset. It makes the code just hard to read.
>>
>>
>>> +
>>> + n_regions = i + 1;
>>> + mtd_region = devm_kcalloc(nor->dev, n_regions, sizeof(*mtd_region),
>>> + GFP_KERNEL);
>>
>> Who's the owner? mtd->dev or nor->dev?
>>
> I think it should be nor->dev.
> The mtd device is not yet registered at this point.
>
>>> + if (!mtd_region)
>>> + return -ENOMEM;
>>> +
>>> + for (i = 0; i < n_regions; i++) {
>>> + if (region[i].offset & SNOR_OVERLAID_REGION) {
>>
>> Btw. what is an overlaid region? I couldn't find any comment
>> about it.
>>
> It is the remaining part of regular sector that overlaid by 4KB sectors.
> In SEMPER case, regular sector is 256KB. If 32 x 4KB sectors are overlaid on
> bottom address, 128KB is overlaid region. The erase opcode for this region is
> same as 256KB sectors.
>
>>> + erase_size = region[i].size;
>>> + } else {
>>> + erase_mask = region[i].offset & SNOR_ERASE_TYPE_MASK;
>>> +
>>> + for (j = SNOR_ERASE_TYPE_MAX - 1; j >= 0; j--) {
>>> + if (erase_mask & BIT(j)) {
>>> + erase_size = map->erase_type[j].size;
>>> + break;
>>> + }
>>> + }
>>> + }
>>> + mtd_region[i].erasesize = erase_size;
>>> + mtd_region[i].numblocks = div64_ul(region[i].size, erase_size);
>>> + mtd_region[i].offset = region[i].offset &
>>> + ~SNOR_ERASE_FLAGS_MASK;
>>> + }
>>> +
>>> + mtd->numeraseregions = n_regions;
>>> + mtd->eraseregions = mtd_region;
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static int spi_nor_set_mtd_info(struct spi_nor *nor)
>>> {
>>> struct mtd_info *mtd = &nor->mtd;
>>> struct device *dev = nor->dev;
>>> @@ -3439,6 +3483,11 @@ static void spi_nor_set_mtd_info(struct spi_nor *nor)
>>> mtd->_resume = spi_nor_resume;
>>> mtd->_get_device = spi_nor_get_device;
>>> mtd->_put_device = spi_nor_put_device;
>>> +
>>> + if (spi_nor_has_uniform_erase(nor))
>>> + return 0;
>>> +
>>> + return spi_nor_set_mtd_eraseregions(nor);
>>
>> mtd->erasesize is set somewhere else, please move it into this
>> function, because it will also have a special case for the
>> non_uniform flashes. Maybe we'll need our own erasesize stored
>> together with the opcode.
>>
> Let me introduce params->erasesize which set through SFDP parse, then
>
> mtd->erasesize = nor->params->erasesize;
>
> like as other 'size' params.
>
I tried to implement this, but found mtd->erasesize is set in some fixup hooks
in manufacturer driver and need to think carefully about changing them.
Let me do this later in another series of patches.
Thanks,
Takahiro
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2024-01-19 6:29 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-25 8:03 [PATCH] mtd: spi-nor: core: Set mtd->eraseregions for non-uniform erase map tkuw584924
2024-01-05 12:23 ` Michael Walle
2024-01-12 7:14 ` Takahiro Kuwano
2024-01-12 9:22 ` Tudor Ambarus
2024-01-19 6:29 ` Takahiro Kuwano [this message]
2024-01-19 6:55 ` Tudor Ambarus
2024-01-19 8:35 ` Takahiro Kuwano
2024-01-19 12:49 ` Michael Walle
2024-01-12 9:43 ` Tudor Ambarus
2024-01-12 10:12 ` Tudor Ambarus
2024-01-12 12:01 ` Michael Walle
2024-01-12 12:22 ` Tudor Ambarus
2024-01-12 12:28 ` Michael Walle
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d63b6363-2d90-4fed-97c3-be69948aae57@gmail.com \
--to=tkuw584924@gmail.com \
--cc=Bacem.Daassi@infineon.com \
--cc=Takahiro.Kuwano@infineon.com \
--cc=linux-mtd@lists.infradead.org \
--cc=miquel.raynal@bootlin.com \
--cc=mwalle@kernel.org \
--cc=pratyush@kernel.org \
--cc=richard@nod.at \
--cc=tudor.ambarus@linaro.org \
--cc=vigneshr@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox