Re: Possible regression regarding the name and size of MTD devices on kernel 5.5.4

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Victor,

On Wed, 11 Mar 2020 16:58:31 -0300
Victor Fusco <victor@xxxxxxxxxx> wrote:

> 
> Searching into the git history I've found two changes that seems to have
> introduced this new behavior:
> 
> 1. The merge of physmap_of.c into physmap-core.c made it stop checking the
> mtd_name
> 
> https://github.com/torvalds/linux/commit/642b1e8dbed7bbbf8c4deb3c9a0496f17278badc#diff-25f9c3817991d18e6c24935d91953344L223
> 
> The original implementation was:
> 
> drivers/mtd/maps/physmap_of_core.c:223
> ----------
>         info->list[i].map.name = mtd_name ?: dev_name(&dev->dev);
> ----------
> 
> And the new one:
> 
> drivers/mtd/maps/physmap-core.c:237
> ----------
>         info->maps[i].name = dev_name(&dev->dev);
> ----------
> 
> 2. The merge gpio-addr-flash.c into physmap-core.c made it calculate the size
> differently. Not sure if the new implementation is accurate when there is no
> gpio.
> 
> https://github.com/torvalds/linux/commit/ba32ce95cbd9876eb7f5ec39af87829c8f13a337#diff-82fc46753342e94dc0772828e76af427L372
> 
> The original implementation was:
> 
> drivers/mtd/maps/physmap-core.c:372
> ----------
>         info->maps[i].size = resource_size(res);
> ----------
> 
> And the new one:
> 
> drivers/mtd/maps/physmap-core.c:507
> ----------
>         info->win_order = get_bitmask_order(resource_size(res)) - 1;
>         info->maps[i].size = BIT(info->win_order +
>                      (info->gpios ?
>                       info->gpios->ndescs : 0));
> ----------


Looks like 2 regressions, indeed. Would you mind sending 2 fixes for
that?

Thanks,

Boris

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



[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux