All of lore.kernel.org
 help / color / mirror / Atom feed
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, 12 Jan 2024 16:14:48 +0900	[thread overview]
Message-ID: <d9cf5631-951e-45a0-930f-cc3afac05df9@gmail.com> (raw)
In-Reply-To: <740bf235110e05eae9ec7768603e6e2a@walle.cc>

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(&region[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.

> Also this should be written as
> 
> if (!spi_nor_has_uniform_erase(nor))
>   spi_nor_set_mtd_eraseregions(nor);
> 
> return 0;
> 
> -michael
> 
OK, thanks!

>>  }
>>
>>  static int spi_nor_hw_reset(struct spi_nor *nor)
>> @@ -3531,7 +3580,9 @@ int spi_nor_scan(struct spi_nor *nor, const char *name,
>>          return ret;
>>
>>      /* No mtd_info fields should be used up to this point. */
>> -    spi_nor_set_mtd_info(nor);
>> +    ret = spi_nor_set_mtd_info(nor);
>> +    if (ret)
>> +        return ret;
>>
>>      dev_info(dev, "%s (%lld Kbytes)\n", info->name,
>>              (long long)mtd->size >> 10);

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

  reply	other threads:[~2024-01-12  7:15 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 [this message]
2024-01-12  9:22     ` Tudor Ambarus
2024-01-19  6:29     ` Takahiro Kuwano
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=d9cf5631-951e-45a0-930f-cc3afac05df9@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.