All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
To: Quentin Schulz <quentin.schulz@cherry.de>
Cc: u-boot@lists.denx.de,  Tom Rini <trini@konsulko.com>,
	 Patrick Delaunay <patrick.delaunay@foss.st.com>,
	 Marek Vasut <marex@denx.de>,
	 Emil Kronborg <emil.kronborg@protonmail.com>
Subject: Re: [PATCH 3/3] env: mmc: rework mmc_env_partition_by_guid() to work with two separate partitions
Date: Thu, 19 Sep 2024 09:01:40 +0200	[thread overview]
Message-ID: <87y13oktyj.fsf@prevas.dk> (raw)
In-Reply-To: <72e37714-bdac-4334-a2a9-18d6ea954b73@cherry.de> (Quentin Schulz's message of "Wed, 18 Sep 2024 18:59:29 +0200")

Quentin Schulz <quentin.schulz@cherry.de> writes:

> Hi Rasmus,
>
> For this patch and the previous one, should we have test(s) to make
> sure we don't regress?
>

That's obviously a good idea. But I don't have any idea how I'd go about
writing such tests. AFAICT, there is no existing tests of the "find env
partition by GUID" logic that I could amend, or any tests of any of the
"find the mmc partition containing the env" for that matter. Pointers
appreciated.

FWIW, on my end, I think I'll enable CONFIG_PARTITION_TYPE_GUID on all
our configs and stop defining the real values of the ENV_OFFSET, so that
our boards will start depending on the guid logic to find the env
partitions. Which will then at least eventually find a regression, but
unfortunately we usually lag some months behind on upgrading, and very
rarely have resources for checking -rcX, so we would only find it after
a release.

Rasmus

  reply	other threads:[~2024-09-19  7:01 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-12 13:41 [PATCH 0/3] env: mmc: fix use of two separate partitions with proper type GUID Rasmus Villemoes
2024-09-12 13:41 ` [PATCH 1/3] env: mmc: refactor mmc_offset_try_partition() Rasmus Villemoes
2024-09-18 16:59   ` Quentin Schulz
2024-09-19  6:53     ` Rasmus Villemoes
2024-09-23 11:04       ` Quentin Schulz
2024-09-12 13:41 ` [PATCH 2/3] env: mmc: do not return an offset before the start of the partition Rasmus Villemoes
2024-09-12 13:41 ` [PATCH 3/3] env: mmc: rework mmc_env_partition_by_guid() to work with two separate partitions Rasmus Villemoes
2024-09-18 16:59   ` Quentin Schulz
2024-09-19  7:01     ` Rasmus Villemoes [this message]
2024-09-23 11:10       ` Quentin Schulz
2024-10-01 13:43 ` [PATCH 0/3] env: mmc: fix use of two separate partitions with proper type GUID Rasmus Villemoes
2024-10-01 14:43   ` Tom Rini
2024-10-01 17:37 ` Tom Rini

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=87y13oktyj.fsf@prevas.dk \
    --to=rasmus.villemoes@prevas.dk \
    --cc=emil.kronborg@protonmail.com \
    --cc=marex@denx.de \
    --cc=patrick.delaunay@foss.st.com \
    --cc=quentin.schulz@cherry.de \
    --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.