From: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
To: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: kvm@vger.kernel.org, kvmarm@lists.linux.dev, maz@kernel.org,
will@kernel.org, catalin.marinas@arm.com,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, steven.price@arm.com,
aneesh.kumar@kernel.org, oupton@kernel.org, gshan@redhat.com,
joey.gouly@arm.com, tabba@google.com, yuzenghui@huawei.com,
linux-coco@lists.linux.dev, gankulkarni@os.amperecomputing.com,
sdonthineni@nvidia.com, alpergun@google.com,
fj0570is@fujitsu.com, WeiLin.Chang@arm.com,
lpieralisi@kernel.org, enju.kohei@fujitsu.com
Subject: Re: [PATCH v18 6/7] firmware: arm_rmm: Ensure the RMM has GPT entries for memory
Date: Wed, 23 Sep 2026 09:46:06 -0700 [thread overview]
Message-ID: <20260923094606.00003c6b@oss.qualcomm.com> (raw)
In-Reply-To: <2164b046-bbbb-4cfb-b797-5df27fbe313f@arm.com>
On Tue, 22 Sep 2026 23:55:52 +0100
Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
> On 21/09/2026 22:58, Jonathan Cameron wrote:
> >
> >>>>> static int __init arm64_init_rmi(void)
> >>>>> {
> >>>>> int ret;
> >>>>> @@ -786,8 +970,24 @@ static int __init arm64_init_rmi(void)
> >>>>> if (ret) {
> >>>>> pr_err("RMM activate failed\n");
> >>>>> ret = ret < 0 ? ret : -ENXIO;
> >>>>> + return ret;
> >>>>
> >>>> Why did this change?
> >>>
> >>> Rebase messed up. I will restore it.
> >>
> >> Actually this is not. We dont have to check the metadata if
> >> we couldn't activate the RMM. Also, the failure path at the
> >> bottom has "deactivate", which again is not needed. So
> >> it is the right thing to do.
> >
> > Only after this patch? Not from the previous patch?
> >
> >>
> >>>
> >>>>
> >>>>> }
> >>>>> + ret = rmi_init_metadata();
> >>>>> + if (ret)
> >>>>
> >>>> And this is hitting another bit of guidance in cleanup.h.
> >>>> Functions shouldn't be mixing __free and friends with
> >>>> gotos. Again, not a bug here but there are large ugly
> >>>> monsters around this stuff, hence the blanket guidance.
> >>>> I haven't thought that hard on how you avoid it here, but
> >>>> usually it's a combination of suitable helpers and wrappers
> >>>> and resulting code is often more readable as a result.
> >>
> >> I could change the hunk to something like, but that looks ugly.
> >>
> >> @@ -1010,20 +1010,12 @@ static int __init arm64_init_rmi(void)
> >> return ret;
> >> }
> >>
> >> - ret = rmi_init_metadata();
> >> - if (ret)
> >> - goto out_deactivate;
> >> + if (!rmi_init_metadata() &&
> >> !register_memory_notifier(&rmi_memory_nb)) {
> >> + arm64_rmi_is_available = true;
> >> + pr_info("RMI configured\n");
> >> + return 0;
> >> + }
> >>
> >> - ret = register_memory_notifier(&rmi_memory_nb);
> >> - if (ret)
> >> - goto out_deactivate;
> >> -
> >> - arm64_rmi_is_available = true;
> >> - pr_info("RMI configured\n");
> >> -
> >> - return 0;
> >> -
> >> -out_deactivate:
> >> WARN_ON(rmi_sro_memxfer_cmd(sro, GFP_KERNEL,
> >> SMC_RMI_RMM_DEACTIVATE));
> >> return ret;
> >> }
> >>
> >>
> >> Either ways, we have to cleanup the object on return, no matter
> >> the route we take. So the original form is much more readable
> >> for me.
> >
> > Agree to more readable, but that fragility of mixing __free() and
> > goto is a real problem that has tripped many folk up - hence
> > the perhaps overly strict guidance. Rather than avoiding the goto, I'd just
> > not use __free() - go old school and have two labels for errors
> > and an extra manual free in the good path.
> >
> > pr_info("RMI configured\n:);
> > kfree(sro);
> >
> > return 0;
> >
> > out_deactivate:
> > WARN_ON(rmi_sro_memxfer_cmd(sro, GFP_KERNEL, SMC_RMI_RMM_DEACTIVATE));
> > out_free_sro:
> > kfree(sro);
> > return ret;
> > }
> >
> > Sometime the new toys aren't the right answer.
>
> I have the following hunk on top of this patch, that could do the trick.
>
> diff --git a/drivers/firmware/arm_rmm/rmi.c b/drivers/firmware/arm_rmm/rmi.c
> index bcdbed26cf08d..4385f49068965 100644
> --- a/drivers/firmware/arm_rmm/rmi.c
> +++ b/drivers/firmware/arm_rmm/rmi.c
> @@ -1033,20 +1033,19 @@ static int __init arm64_init_rmi(void)
> return ret;
> }
>
> - ret = rmi_init_metadata();
> - if (ret)
> - goto out_deactivate;
> -
> - ret = register_memory_notifier(&rmi_memory_nb);
> - if (ret)
> - goto out_deactivate;
> -
> - arm64_rmi_is_available = true;
> - pr_info("RMI configured\n");
> -
> - return 0;
> -
> -out_deactivate:
> + do {
> + ret = rmi_init_metadata();
> + if (ret)
> + break;
> + ret = register_memory_notifier(&rmi_memory_nb);
> + if (ret)
> + break;
> + arm64_rmi_is_available = true;
> + pr_info("RMI configured\n");
> + return 0;
> + } while (0);
> +
> + /* De-activate the RMM and reclaim any donated memory */
> WARN_ON(rmi_sro_memxfer_cmd(sro, GFP_KERNEL,
> SMC_RMI_RMM_DEACTIVATE));
> return ret;
I'd just use gotos or an actual help function. But your code to
look after long term - so up to you :)
>
> Cheers
> Suzuki
>
> >
> > Jonathan
> >
> >
> >
> >
> >>
> >> Cheers
> >> Suzuki
> >>
> >>>>
> >>>
> >>> I will see if I can improve it.
> >>>
> >>> Cheers
> >>> Suzuki
> >>>
> >>
> >
>
next prev parent reply other threads:[~2026-09-23 16:46 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-12 8:36 [PATCH v18 0/7] firmware: arm_rmm: Add RMM v2.0 base RMI support Suzuki K Poulose
2026-09-12 8:36 ` [PATCH v18 1/7] firmware: arm_rmm: Add SMC definitions for calling the RMM Suzuki K Poulose
2026-09-12 8:45 ` sashiko-bot
2026-09-12 9:04 ` Suzuki K Poulose
2026-09-14 0:28 ` Gavin Shan
2026-09-19 1:27 ` Jonathan Cameron
2026-09-21 9:27 ` Suzuki K Poulose
2026-09-21 10:02 ` Suzuki K Poulose
2026-09-21 21:27 ` Jonathan Cameron
2026-09-23 22:34 ` Suzuki K Poulose
2026-09-21 10:14 ` Suzuki K Poulose
2026-09-21 21:29 ` Jonathan Cameron
2026-09-21 21:33 ` Jonathan Cameron
2026-09-12 8:36 ` [PATCH v18 2/7] firmware: arm_rmm: Check for RMI support at init Suzuki K Poulose
2026-09-14 1:04 ` Gavin Shan
2026-09-14 10:27 ` Sudeep Holla
2026-09-23 22:31 ` Suzuki K Poulose
2026-09-19 1:27 ` Jonathan Cameron
2026-09-21 9:00 ` Suzuki K Poulose
2026-09-21 21:37 ` Jonathan Cameron
2026-09-12 8:36 ` [PATCH v18 3/7] firmware: arm_rmm: Configure the RMM with the host's page size Suzuki K Poulose
2026-09-14 1:21 ` Gavin Shan
2026-09-14 6:34 ` Suzuki K Poulose
2026-09-19 1:27 ` Jonathan Cameron
2026-09-21 9:31 ` Suzuki K Poulose
2026-09-12 8:36 ` [PATCH v18 4/7] firmware: arm_rmm: Add support for SRO Suzuki K Poulose
2026-09-12 8:48 ` sashiko-bot
2026-09-12 10:28 ` Suzuki K Poulose
2026-09-14 5:04 ` Gavin Shan
2026-09-14 6:22 ` Suzuki K Poulose
2026-09-14 8:19 ` Suzuki K Poulose
2026-09-14 9:59 ` Gavin Shan
2026-09-14 9:50 ` Gavin Shan
2026-09-14 12:50 ` Sudeep Holla
2026-09-14 14:02 ` Suzuki K Poulose
2026-09-14 14:47 ` Suzuki K Poulose
2026-09-19 1:27 ` Jonathan Cameron
2026-09-21 12:42 ` Suzuki K Poulose
2026-09-21 21:46 ` Jonathan Cameron
2026-09-12 8:36 ` [PATCH v18 5/7] firmware: arm_rmm: Activate the RMM Suzuki K Poulose
2026-09-14 5:06 ` Gavin Shan
2026-09-19 1:27 ` Jonathan Cameron
2026-09-21 9:04 ` Suzuki K Poulose
2026-09-12 8:36 ` [PATCH v18 6/7] firmware: arm_rmm: Ensure the RMM has GPT entries for memory Suzuki K Poulose
2026-09-12 8:46 ` sashiko-bot
2026-09-13 6:59 ` Suzuki K Poulose
2026-09-14 5:41 ` Gavin Shan
2026-09-14 8:38 ` Suzuki K Poulose
2026-09-16 18:23 ` Alper Gun
2026-09-21 9:30 ` Suzuki K Poulose
2026-09-19 1:27 ` Jonathan Cameron
2026-09-21 9:32 ` Suzuki K Poulose
2026-09-21 13:38 ` Suzuki K Poulose
2026-09-21 21:58 ` Jonathan Cameron
2026-09-22 22:55 ` Suzuki K Poulose
2026-09-23 16:46 ` Jonathan Cameron [this message]
2026-09-12 8:36 ` [PATCH v18 7/7] firmware: arm_rmm: Add wrappers for Realm related RMI commands Suzuki K Poulose
2026-09-14 5:46 ` Gavin Shan
2026-09-15 19:35 ` Alper Gun
2026-09-15 19:55 ` Suzuki K Poulose
2026-09-19 1:27 ` Jonathan Cameron
2026-09-21 21:53 ` [PATCH v18 0/7] firmware: arm_rmm: Add RMM v2.0 base RMI support Jonathan Cameron
2026-09-21 22:38 ` Suzuki K Poulose
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=20260923094606.00003c6b@oss.qualcomm.com \
--to=jonathan.cameron@oss.qualcomm.com \
--cc=WeiLin.Chang@arm.com \
--cc=alpergun@google.com \
--cc=aneesh.kumar@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=enju.kohei@fujitsu.com \
--cc=fj0570is@fujitsu.com \
--cc=gankulkarni@os.amperecomputing.com \
--cc=gshan@redhat.com \
--cc=joey.gouly@arm.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-coco@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=maz@kernel.org \
--cc=oupton@kernel.org \
--cc=sdonthineni@nvidia.com \
--cc=steven.price@arm.com \
--cc=suzuki.poulose@arm.com \
--cc=tabba@google.com \
--cc=will@kernel.org \
--cc=yuzenghui@huawei.com \
/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.