[PATCH] bootstd: Use -c flag with bootdev order

[PATCH] bootstd: Use -c flag with bootdev order

[Simon Glass]

Update this command to use a -c flag rather than a special 'clear'
argument.

Link: https://patchwork.ozlabs.org/project/uboot/patch/20250501133726.2627373-16-sjg@chromium.org/

Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: Quentin Schulz <quentin.schulz@cherry.de>
---

 cmd/bootdev.c             |  4 ++--
 doc/usage/cmd/bootdev.rst | 10 +++++-----
 test/boot/bootdev.c       |  2 +-
 3 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/cmd/bootdev.c b/cmd/bootdev.c
index f05a865f609..8ed2c96e50a 100644
--- a/cmd/bootdev.c
+++ b/cmd/bootdev.c
@@ -148,7 +148,7 @@ static int do_bootdev_order(struct cmd_tbl *cmdtp, int flag, int argc,
 	if (ret)
 		return ret;
 	if (argc == 2) {
-		if (!strncmp(argv[1], "clear", strlen(argv[1]))) {
+		if (!strcmp(argv[1], "-c")) {
 			bootdev_set_order(NULL);
 
 			return 0;
@@ -176,7 +176,7 @@ static int do_bootdev_order(struct cmd_tbl *cmdtp, int flag, int argc,
 U_BOOT_LONGHELP(bootdev,
 	"list [-p]         - list all available bootdevs (-p to probe)\n"
 	"bootdev hunt [-l|<spec>]  - use hunt drivers to find bootdevs\n"
-	"bootdev order [clear] | [<spec>,...]  - view or update bootdev order\n"
+	"bootdev order [-c] | [<spec>,...]  - view or update bootdev order\n"
 	"bootdev select <bd>       - select a bootdev by name | label | seq\n"
 	"bootdev info [-p]         - show information about a bootdev (-p to probe)");
 
diff --git a/doc/usage/cmd/bootdev.rst b/doc/usage/cmd/bootdev.rst
index abede194cba..76e56c26f21 100644
--- a/doc/usage/cmd/bootdev.rst
+++ b/doc/usage/cmd/bootdev.rst
@@ -13,7 +13,7 @@ Synopsis
 
     bootdev list [-p]        - list all available bootdevs (-p to probe)
     bootdev hunt [-l|<spec>] - use hunt drivers to find bootdevs
-    bootdev order [clear] | [<spec> ...]  - view or update bootdev order
+    bootdev order [-c] | [<spec> ...]  - view or update bootdev order
     bootdev select <bm>      - select a bootdev by name
     bootdev info [-p]        - show information about a bootdev
 
@@ -85,11 +85,11 @@ bootdev order
 This allows the bootdev order to be examined or set. With no argument the
 current ordering is shown, one item per line.
 
-The argument can either be 'clear' or a space-separated list of labels. Each
-label can be the name of a bootdev (e.g. "mmc1.bootdev"), a bootdev sequence
-number ("3") or a media uclass ("mmc") with an optional sequence number (mmc2).
+The argument is a space-separated list of labels. Each label can be the name of
+a bootdev (e.g. "mmc1.bootdev"), a bootdev sequence number ("3") or a media
+uclass ("mmc") with an optional sequence number (mmc2).
 
-Use `bootdev order clear` to clear any ordering and use the default.
+Use `bootdev order -c` to clear any ordering and use the default.
 
 By default, the ordering is defined by the `boot_targets` environment variable
 or, failing that, the bootstd node in the devicetree ("bootdev-order" property).
diff --git a/test/boot/bootdev.c b/test/boot/bootdev.c
index 84280caf7b5..ff3da505d85 100644
--- a/test/boot/bootdev.c
+++ b/test/boot/bootdev.c
@@ -793,7 +793,7 @@ static int bootdev_test_cmd_order(struct unit_test_state *uts)
 	ut_assert_nextline("mmc1");
 	ut_assert_console_end();
 
-	ut_assertok(run_command("bootdev order clear", 0));
+	ut_assertok(run_command("bootdev order -c", 0));
 	ut_assertok(run_command("bootdev order", 0));
 	ut_assert_nextline("No ordering");
 	ut_assert_console_end();
-- 
2.34.1

base-commit: d0792b0848712a84b5fe20ba60f699b48def807e
branch: schc3

Re: [PATCH] bootstd: Use -c flag with bootdev order

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 522 bytes --]

On Sat, May 24, 2025 at 06:42:45AM +0100, Simon Glass wrote:

> Update this command to use a -c flag rather than a special 'clear'
> argument.
> 
> Link: https://patchwork.ozlabs.org/project/uboot/patch/20250501133726.2627373-16-sjg@chromium.org/
> 
> Signed-off-by: Simon Glass <sjg@chromium.org>
> Suggested-by: Quentin Schulz <quentin.schulz@cherry.de>
[snip]
> -- 
> 2.34.1
> 
> base-commit: d0792b0848712a84b5fe20ba60f699b48def807e
> branch: schc3

This is unfortunately not on mainline.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH] bootstd: Use -c flag with bootdev order

[Quentin Schulz]

Hi Simon,

On 5/24/25 7:42 AM, Simon Glass wrote:
> Update this command to use a -c flag rather than a special 'clear'
> argument.
> 

I don't see the commit which adds the clear command to either master or 
next branch, so maybe just fix that in the original commit before 
sending a pull request instead of via fixups?

Did I miss something instead maybe?

Cheers,
Quentin

Re: [PATCH] bootstd: Use -c flag with bootdev order

[Simon Glass]

Hi Quentin,

On Mon, 26 May 2025 at 08:48, Quentin Schulz <quentin.schulz@cherry.de> wrote:
>
> Hi Simon,
>
> On 5/24/25 7:42 AM, Simon Glass wrote:
> > Update this command to use a -c flag rather than a special 'clear'
> > argument.
> >
>
> I don't see the commit which adds the clear command to either master or
> next branch, so maybe just fix that in the original commit before
> sending a pull request instead of via fixups?

Tom rejected that series (or 'changes requested' to be specific). I
added it to my tree in merge-request 68:

d93f42d6e3d bootstd: Provide a command to select the bootdev order

>
> Did I miss something instead maybe?

I didn't send out my 'applied' emails for this series, so it was
silently applied to my tree, so far as the mailing list was concerned.
Tom wants me to operate my tree silently so I don't always send the
emails...

Regards,
Simon

Re: [PATCH] bootstd: Use -c flag with bootdev order

[Quentin Schulz]

Hi Simon,

On 5/26/25 10:35 AM, Simon Glass wrote:
> Hi Quentin,
> 
> On Mon, 26 May 2025 at 08:48, Quentin Schulz <quentin.schulz@cherry.de> wrote:
>>
>> Hi Simon,
>>
>> On 5/24/25 7:42 AM, Simon Glass wrote:
>>> Update this command to use a -c flag rather than a special 'clear'
>>> argument.
>>>
>>
>> I don't see the commit which adds the clear command to either master or
>> next branch, so maybe just fix that in the original commit before
>> sending a pull request instead of via fixups?
> 
> Tom rejected that series (or 'changes requested' to be specific). I
> added it to my tree in merge-request 68:
> 
> d93f42d6e3d bootstd: Provide a command to select the bootdev order
> 

If changes are required to merge the merge request and considering that 
you are the owner of both the patch being fixed up and the merge 
request, maybe sending a vN+1 instead of fixups would make sense? 
Especially if you haven't sent the "applied" mails like you say below?

I would rather avoid reviewing patches on top of commits that may never 
make it to the main tree.

>>
>> Did I miss something instead maybe?
> 
> I didn't send out my 'applied' emails for this series, so it was
> silently applied to my tree, so far as the mailing list was concerned.
> Tom wants me to operate my tree silently so I don't always send the
> emails...
> 

I don't want to pour fuel on the fire but this whole ordeal between you 
and Tom needs to be sorted out, I'm essentially not even looking at any 
of your patches anymore even when I'm in Cc/To. From an outsider PoV, 
the situation is confusing and frustrating. Please do not take this as 
an invitation to include me in the "fights". Nobody likes to see 
arguments lasting months even if they are not part of it. "Fights" may 
sometimes be necessary and healthy for a project but this has become 
anxiety-provoking to me, hence my reluctance to look at any thread you 
both are part of. I also want to be able to again trust that the few 
reviews I occasionally make on the mailing list are useful because they 
are for patches that have a chance of being merged and based on code 
that was merged or soon to be merged (in a maintainer tree with high 
chances of being merged in a subsequent merge request to the main tree).

Quentin

Re: [PATCH] bootstd: Use -c flag with bootdev order

[Simon Glass]

Hi Quentin,

On Mon, 26 May 2025 at 10:09, Quentin Schulz <quentin.schulz@cherry.de> wrote:
>
> Hi Simon,
>
> On 5/26/25 10:35 AM, Simon Glass wrote:
> > Hi Quentin,
> >
> > On Mon, 26 May 2025 at 08:48, Quentin Schulz <quentin.schulz@cherry.de> wrote:
> >>
> >> Hi Simon,
> >>
> >> On 5/24/25 7:42 AM, Simon Glass wrote:
> >>> Update this command to use a -c flag rather than a special 'clear'
> >>> argument.
> >>>
> >>
> >> I don't see the commit which adds the clear command to either master or
> >> next branch, so maybe just fix that in the original commit before
> >> sending a pull request instead of via fixups?
> >
> > Tom rejected that series (or 'changes requested' to be specific). I
> > added it to my tree in merge-request 68:
> >
> > d93f42d6e3d bootstd: Provide a command to select the bootdev order
> >
>
> If changes are required to merge the merge request and considering that
> you are the owner of both the patch being fixed up and the merge
> request, maybe sending a vN+1 instead of fixups would make sense?
> Especially if you haven't sent the "applied" mails like you say below?
>
> I would rather avoid reviewing patches on top of commits that may never
> make it to the main tree.
>
> >>
> >> Did I miss something instead maybe?
> >
> > I didn't send out my 'applied' emails for this series, so it was
> > silently applied to my tree, so far as the mailing list was concerned.
> > Tom wants me to operate my tree silently so I don't always send the
> > emails...
> >
>
> I don't want to pour fuel on the fire but this whole ordeal between you
> and Tom needs to be sorted out, I'm essentially not even looking at any
> of your patches anymore even when I'm in Cc/To. From an outsider PoV,
> the situation is confusing and frustrating. Please do not take this as
> an invitation to include me in the "fights". Nobody likes to see
> arguments lasting months even if they are not part of it. "Fights" may
> sometimes be necessary and healthy for a project but this has become
> anxiety-provoking to me, hence my reluctance to look at any thread you
> both are part of. I also want to be able to again trust that the few
> reviews I occasionally make on the mailing list are useful because they
> are for patches that have a chance of being merged and based on code
> that was merged or soon to be merged (in a maintainer tree with high
> chances of being merged in a subsequent merge request to the main tree).

Thanks for your comments. I fully agree.

Regards,
Simon