From: Rasmus Villemoes <ravi@prevas.dk>
To: Anshul Dalal <anshuld@ti.com>
Cc: <u-boot@lists.denx.de>,
Quentin Schulz <quentin.schulz@cherry.de>,
Tom Rini <trini@konsulko.com>
Subject: Re: [PATCH v3 1/2] disk/part.c: ensure strings in struct disk_partition are valid after successful get_info
Date: Tue, 11 Nov 2025 08:58:02 +0100 [thread overview]
Message-ID: <87h5v1c86t.fsf@prevas.dk> (raw)
In-Reply-To: <DE5M18VIB15A.2TVG99O546D0T@ti.com> (Anshul Dalal's message of "Tue, 11 Nov 2025 10:48:49 +0530")
On Tue, Nov 11 2025, Anshul Dalal <anshuld@ti.com> wrote:
>> int part_get_type_by_name(const char *name)
>> {
>> struct part_driver *drv =
>> @@ -322,12 +344,9 @@ int part_get_info_by_type(struct blk_desc *desc, int part, int part_type,
>> struct disk_partition *info)
>> {
>> struct part_driver *drv;
>> + int ret = -ENOENT;
>>
>> if (blk_enabled()) {
>> - /* The common case is no UUID support */
>> - disk_partition_clr_uuid(info);
>> - disk_partition_clr_type_guid(info);
>> -
>> if (part_type == PART_TYPE_UNKNOWN) {
>> drv = part_driver_lookup_type(desc);
>> } else {
>> @@ -339,18 +358,16 @@ int part_get_info_by_type(struct blk_desc *desc, int part, int part_type,
>> desc->part_type);
>> return -EPROTONOSUPPORT;
>> }
>> - if (!drv->get_info) {
>> - PRINTF("## Driver %s does not have the get_info() method\n",
>> - drv->name);
>> - return -ENOSYS;
>> - }
>> - if (drv->get_info(desc, part, info) == 0) {
>> +
>> + ret = part_driver_get_info(drv, desc, part, info);
>> + if (ret && ret != -ENOSYS) {
>> + ret = -ENOENT;
>
> Why are we overwriting the err code from part_driver_get_info here?
That's essentially what the code did originally (it only returned 0 in
case ->get_info returned 0, otherwise it fell through to the "return
-ENOENT" at the bottom). And it turns out that that behaviour is
expected by lots of tests; when I inadvertently changed that logic in v2
to actually propagate whatever error ->get_info returned, lots of tests
broke:
https://lore.kernel.org/u-boot/20251107201927.GA2243313@bill-the-cat/
And this is the only difference between v2 and v3, I tweaked this so it
would preserve that "either success or -ENOENT [or -ENOSYS]" behaviour.
Rasmus
next prev parent reply other threads:[~2025-11-11 7:58 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-10 20:54 [PATCH v3 0/2] 'part name' subcommand and some robustification Rasmus Villemoes
2025-11-10 20:54 ` [PATCH v3 1/2] disk/part.c: ensure strings in struct disk_partition are valid after successful get_info Rasmus Villemoes
2025-11-11 5:18 ` Anshul Dalal
2025-11-11 7:58 ` Rasmus Villemoes [this message]
2025-11-10 20:54 ` [PATCH v3 2/2] cmd/part.c: implement "part name" subcommand Rasmus Villemoes
2025-11-11 5:25 ` Anshul Dalal
2025-11-11 8:00 ` Rasmus Villemoes
2025-11-11 17:27 ` Quentin Schulz
2025-11-11 5:07 ` [PATCH v3 0/2] 'part name' subcommand and some robustification Anshul Dalal
2025-11-18 20:32 ` 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=87h5v1c86t.fsf@prevas.dk \
--to=ravi@prevas.dk \
--cc=anshuld@ti.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox