[Uboot-stm32] [PATCH] dfu: dfu_mtd: set max_buf_size to erasesize also for NOR devices

[Patrick DELAUNAY]

Thanks Patrice,

On 4/20/21 12:24 PM, Patrice CHOTARD wrote:
> Hi Patrick
>
> On 3/4/21 5:47 PM, Patrick Delaunay wrote:
>> For NOR devices the logical DFU buffer size is the sector_size,
>> as it is done in dfu_sf.c or in spi/sf_mtd.c
>> (sf_mtd_info.erasesize = flash->sector_size)
>>
>> For NAND the DFU size was already limited to erasesize as
>> has_pages = true.
>>
>> So the mtd dfu backend can use this erasesize for all the MTD devices,
>> NOR and NAND with dfu->max_buf_size = mtd->erasesize
>>
>> This difference was initially copied from MTD command, where
>> data is fully available in RAM without size limitation.
>>
>> This patch avoids to have many sector write in dfu_mtd.c at the end
>> of the DFU transfer and avoids issues with USB timeout or WATCHDOG.
>>
>> Signed-off-by: Patrick Delaunay <patrick.delaunay at foss.st.com>
>> ---
>>
>>   drivers/dfu/dfu_mtd.c | 5 +----
>>   1 file changed, 1 insertion(+), 4 deletions(-)
>>
>> diff --git a/drivers/dfu/dfu_mtd.c b/drivers/dfu/dfu_mtd.c
>> index ca67585a7e..7efb3cbd79 100644
>> --- a/drivers/dfu/dfu_mtd.c
>> +++ b/drivers/dfu/dfu_mtd.c
>> @@ -252,7 +252,6 @@ int dfu_fill_entity_mtd(struct dfu_entity *dfu, char *devstr, char *s)
>>   {
>>   	char *st;
>>   	struct mtd_info *mtd;
>> -	bool has_pages;
>>   	int ret, part;
>>   
>>   	mtd = get_mtd_device_nm(devstr);
>> @@ -262,9 +261,7 @@ int dfu_fill_entity_mtd(struct dfu_entity *dfu, char *devstr, char *s)
>>   
>>   	dfu->dev_type = DFU_DEV_MTD;
>>   	dfu->data.mtd.info = mtd;
>> -
>> -	has_pages = mtd->type == MTD_NANDFLASH || mtd->type == MTD_MLCNANDFLASH;
>> -	dfu->max_buf_size = has_pages ? mtd->erasesize : 0;
>> +	dfu->max_buf_size = mtd->erasesize;
>>   
>>   	st = strsep(&s, " ");
>>   	if (!strcmp(st, "raw")) {
>>
> Reviewed-by: Patrice Chotard <patrice.chotard at foss.st.com>
>
> Thanks
>
> Patrice


Lukasz, any remarks on your side?


Can I take this patch in my first STM32 pull request for v2020.10 ?

or a PR is already planed on your side ?

http://patchwork.ozlabs.org/project/uboot/patch/20210304174748.1.I1d824180669d63e22275f082e7ac0fe50c2b8646@changeid/


Regards

Patrick