All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mattijs Korpershoek <mkorpershoek@baylibre.com>
To: Federico Fuga via B4 Relay
	<devnull+fuga.studiofuga.com@kernel.org>,
	Tom Rini <trini@konsulko.com>
Cc: u-boot@lists.denx.de, Federico Fuga <fuga@studiofuga.com>
Subject: Re: [PATCH] Fix fastboot handling of partitions when no slots are supported
Date: Thu, 30 Jan 2025 14:49:43 +0100	[thread overview]
Message-ID: <87r04kfm2w.fsf@baylibre.com> (raw)
In-Reply-To: <20250128-fastboot_slot_fix-v1-1-1a4688936662@studiofuga.com>

Hi Federico,

Thank you for the patch.

On mar., janv. 28, 2025 at 12:18, Federico Fuga via B4 Relay <devnull+fuga.studiofuga.com@kernel.org> wrote:

> From: Federico Fuga <fuga@studiofuga.com>
>
> The fastboot module has a bug that prevents some command to work
> properly on devices that haven't an Android-like partition scheme, that
> is, just one spl and one kernel partition, instead of the redundant
> scheme with _a and _b slots.
>
> This is the schema of our NAND storage (board is based on an AllWinner
> A33 sunxi chip):
>
> => mtdparts
>
> device nand0 <1c03000.nand>, # parts = 4
>  #: name         size            net size        offset          mask_flags
>  0: spl          0x00020000      0x00020000      0x00000000      0
>  1: uboot        0x00100000      0x00100000      0x00020000      0
>  2: kernel_a     0x00400000      0x00400000      0x00120000      0
>  3: ubi          0x07ae0000      0x079e0000 (!)  0x00520000      0
>
> active partition: nand0,0 - (spl) 0x00020000 @ 0x00000000
>
> This happens when we try to erase the spl partition using fastboot:
>
> $ fastboot erase spl
> Erasing 'spl_a'               FAILED (remote: 'invalid NAND device')
> fastboot: error: Command failed
>
> The error occurs because getvars fails to handle the error returned by
> nand layer when a partition cannot be found.
>
> Indeed, getvar_get_part_info returns what is returned by
> fastboot_nand_get_part_info (0 on success, 1 on failure) but it should
> return -ENODEV or -EINVAL instead. Since the cause of failure is not
> returned by the nand function, I decided to return -EINVAL to make it
> simple.
>
> Signed-off-by: Federico Fuga <fuga@studiofuga.com>

I could apply this version, finally :)

b4 got a bit confused since it has been send as a v1 but using the
following command worked for me:

$ b4 shazam -s -l --check 20250128-fastboot_slot_fix-v1-1-1a4688936662@studiofuga.com -v1

Now for the patch itself:

Please use 'fastboot:' prefix as a commit title.
Use '$ git log --oneline -- drivers/fastboot/' to see what other commits
where using as a title.

Some more comments below. Please make sure to answer this email to
acknowledge/reject review feedback.
Also, when sending a v2, please make sure to include a changelog.

If you need help setting things up properly, let me know. I'm also
reachable on IRC https://libera.chat/, channel #u-boot, my nickame is mkorpershoek.

> ---
>  drivers/fastboot/fb_getvar.c | 5 ++++-
>  drivers/fastboot/fb_nand.c   | 2 +-
>  2 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/fastboot/fb_getvar.c b/drivers/fastboot/fb_getvar.c
> index 9c2ce65a4e5bce0da6b18aa1b2818f7db556c528..816ed8a6213b5c1f0948a813c6f6a865a4b47ba8 100644
> --- a/drivers/fastboot/fb_getvar.c
> +++ b/drivers/fastboot/fb_getvar.c
> @@ -121,8 +121,11 @@ static int getvar_get_part_info(const char *part_name, char *response,
>  			*size = disk_part.size * disk_part.blksz;
>  	} else if (IS_ENABLED(CONFIG_FASTBOOT_FLASH_NAND)) {
>  		r = fastboot_nand_get_part_info(part_name, &part_info, response);
> -		if (r >= 0 && size)
> +		if (r == 0 && size) {
>  			*size = part_info->size;

Maybe the patch is simpler this way, but I think that it would be better
if fastboot_mmc_get_part_info() and fastboot_nand_get_part_info() would
behave the same. The naming is pretty close already, and having
different behaviours/return codes seems confusing to me.

Is there a strong reason for not modifying fb_nand_lookup() so that it
will return a negative error code?

This way, we can keep the same logic in getvar_get_part_info()

> +		} else {
> +			r = -EINVAL;
> +		}
>  	} else {
>  		fastboot_fail("this storage is not supported in bootloader", response);
>  		r = -ENODEV;
> diff --git a/drivers/fastboot/fb_nand.c b/drivers/fastboot/fb_nand.c
> index afc64fd5280717ae4041ed70268ccc01cfbb0496..9e2f7c01895785a4409eb67ea48abd02a6a6da26 100644
> --- a/drivers/fastboot/fb_nand.c
> +++ b/drivers/fastboot/fb_nand.c
> @@ -151,7 +151,7 @@ static lbaint_t fb_nand_sparse_reserve(struct sparse_storage *info,
>   *
>   * @part_name: Named device to lookup
>   * @part_info: Pointer to returned part_info pointer
> - * @response: Pointer to fastboot response buffer
> + * @response: 0 on success, 1 otherwise

Why has this been modified? @response is still a pointer to fastboot
response buffer.

If we wish to document the return code, use the Return: syntax:

For example, here it would be:

/**
 * fastboot_nand_get_part_info() - Lookup NAND partion by name
 *
 * @part_name: Named device to lookup
 * @part_info: Pointer to returned part_info pointer
 * @response: Pointer to fastboot response buffer
 *
 * Return: 0 on success, 1 otherwise
 */

>   */
>  int fastboot_nand_get_part_info(const char *part_name,
>  				struct part_info **part_info, char *response)
>
> ---
> base-commit: a517796cfa5d8f4ca2f0c11c78c24a08a102c047
> change-id: 20250128-fastboot_slot_fix-69251576d9bb
>
> Best regards,
> -- 
> Federico Fuga <fuga@studiofuga.com>

  reply	other threads:[~2025-01-30 13:49 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-28 11:18 [PATCH] Fix fastboot handling of partitions when no slots are supported Federico Fuga
2025-01-28 11:18 ` Federico Fuga via B4 Relay
2025-01-30 13:49 ` Mattijs Korpershoek [this message]
2025-01-30 15:03   ` Federico Fuga
2025-01-31  7:26     ` Mattijs Korpershoek
  -- strict thread matches above, loose matches on Subject: below --
2025-01-28  9:09 Federico Fuga
2025-01-24 10:49 [PATCH] Fix fastboot handling of partitions when no slots are, supported Federico Fuga
2025-01-27  9:39 ` Federico Fuga
2025-01-28  8:44 ` Mattijs Korpershoek
2025-01-28  9:07   ` Federico Fuga

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=87r04kfm2w.fsf@baylibre.com \
    --to=mkorpershoek@baylibre.com \
    --cc=devnull+fuga.studiofuga.com@kernel.org \
    --cc=fuga@studiofuga.com \
    --cc=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    /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.