From: Andre Przywara <andre.przywara@arm.com>
To: Ben Horgan <ben.horgan@arm.com>,
Lorenzo Pieralisi <lpieralisi@kernel.org>,
Hanjun Guo <guohanjun@huawei.com>,
Sudeep Holla <sudeep.holla@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
"Rafael J . Wysocki" <rafael@kernel.org>,
Len Brown <lenb@kernel.org>, James Morse <james.morse@arm.com>,
Reinette Chatre <reinette.chatre@intel.com>,
Fenghua Yu <fenghuay@nvidia.com>
Cc: Jonathan Cameron <jic23@kernel.org>,
Srivathsa L Rao <srivathsa.rao@oss.qualcomm.com>,
Ganapatrao Kulkarni <ganapatrao.kulkarni@oss.qualcomm.com>,
Trilok Soni <tsoni@quicinc.com>,
Srinivas Ramana <sramana@qti.qualcomm.com>,
Niyas Sait <niyas.sait@arm.com>, Lee Trager <lee@trager.us>,
Ritwick Sharma <ritwick.sharma@arm.com>,
Gavin Shan <gshan@redhat.com>,
linux-acpi@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v10 08/14] arm_mpam: propagate MSC access errors for interrupt control
Date: Fri, 11 Sep 2026 18:19:04 +0200 [thread overview]
Message-ID: <a305546a-29f4-45fb-a3e6-09a051733a2a@arm.com> (raw)
In-Reply-To: <89a13b60-a1fe-442f-ab0d-b0d37a118ad1@arm.com>
Hi Ben,
On 9/11/26 16:26, Ben Horgan wrote:
> Hi Andre,
>
> On 11/09/2026 12:28, Andre Przywara wrote:
>> Allow the functions dealing with interrupt registration and enablement
>> to check for and return errors, and propagate MSC read and write errors
>> from the lower level up.
>> This does not cover the IRQ handler yet, as this needs some more
>> attention.
>>
>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>> Reviewed-by: Srivathsa L Rao <srivathsa.rao@oss.qualcomm.com>
>
> Commenting here as this is the last error propagation patch. I think we need a clean boundary for
> the error propagation. As you said a while back I think we can propagate error for all non-static
> functions from mpam_devices.c and the callers can discard the errors if appropriate. For instance,
> mpam_reset_class_locked() should propagate any error.
So I checked all non-static functions in mpam_devices.c: most either
don't deal with MSCs at all, or already propagate errors.
The two outliers are mpam_disable(), which must be "void", due to it
being called via DECLARE_WORK, and mpam_reset_class_locked(), as you
write above. The latter is a bit sad, because the caller is void, so any
errors would be discarded there anyway, but for the sake of completeness
we should indeed propagate here.
And I guess it doesn't make sense to continue the vMSC or RIS list
iterations after detecting the first error, but we just bail out
immediately? Because any error would trigger mpam_disable() anyway?
Cheers,
Andre
>
> Thanks,
>
> Ben
>
>> ---
>> drivers/resctrl/mpam_devices.c | 31 +++++++++++++++----------------
>> 1 file changed, 15 insertions(+), 16 deletions(-)
>>
>> diff --git a/drivers/resctrl/mpam_devices.c b/drivers/resctrl/mpam_devices.c
>> index 558efab75f911..eb26c25b9f970 100644
>> --- a/drivers/resctrl/mpam_devices.c
>> +++ b/drivers/resctrl/mpam_devices.c
>> @@ -1105,7 +1105,9 @@ static int mpam_msc_hw_probe(struct mpam_msc *msc)
>> }
>>
>> /* Clear any stale errors */
>> - mpam_msc_clear_esr(msc);
>> + ret = mpam_msc_clear_esr(msc);
>> + if (ret)
>> + return ret;
>>
>> spin_lock(&partid_max_lock);
>> mpam_partid_max = min(mpam_partid_max, msc->partid_max);
>> @@ -2668,9 +2670,7 @@ static int mpam_enable_msc_ecr(void *_msc)
>> {
>> struct mpam_msc *msc = _msc;
>>
>> - __mpam_write_reg(msc, MPAMF_ECR, MPAMF_ECR_INTEN);
>> -
>> - return 0;
>> + return __mpam_write_reg(msc, MPAMF_ECR, MPAMF_ECR_INTEN);
>> }
>>
>> /* This can run in mpam_disable(), and the interrupt handler on the same CPU */
>> @@ -2678,9 +2678,7 @@ static int mpam_disable_msc_ecr(void *_msc)
>> {
>> struct mpam_msc *msc = _msc;
>>
>> - __mpam_write_reg(msc, MPAMF_ECR, 0);
>> -
>> - return 0;
>> + return __mpam_write_reg(msc, MPAMF_ECR, 0);
>> }
>>
>> static irqreturn_t __mpam_irq_handler(int irq, struct mpam_msc *msc)
>> @@ -2777,11 +2775,13 @@ static int mpam_register_irqs(void)
>> return err;
>> }
>>
>> - mutex_lock(&msc->error_irq_lock);
>> - msc->error_irq_req = true;
>> - mpam_touch_msc(msc, mpam_enable_msc_ecr, msc);
>> - msc->error_irq_hw_enabled = true;
>> - mutex_unlock(&msc->error_irq_lock);
>> + scoped_guard(mutex, &msc->error_irq_lock) {
>> + msc->error_irq_req = true;
>> + err = mpam_touch_msc(msc, mpam_enable_msc_ecr, msc);
>> + if (err)
>> + return err;
>> + msc->error_irq_hw_enabled = true;
>> + }
>> }
>>
>> return 0;
>> @@ -2800,10 +2800,10 @@ static void mpam_unregister_irqs(void)
>> if (irq <= 0)
>> continue;
>>
>> - mutex_lock(&msc->error_irq_lock);
>> + guard(mutex)(&msc->error_irq_lock);
>> if (msc->error_irq_hw_enabled) {
>> - mpam_touch_msc(msc, mpam_disable_msc_ecr, msc);
>> - msc->error_irq_hw_enabled = false;
>> + if (!mpam_touch_msc(msc, mpam_disable_msc_ecr, msc))
>> + msc->error_irq_hw_enabled = false;
>> }
>>
>> if (msc->error_irq_req) {
>> @@ -2815,7 +2815,6 @@ static void mpam_unregister_irqs(void)
>> }
>> msc->error_irq_req = false;
>> }
>> - mutex_unlock(&msc->error_irq_lock);
>> }
>> }
>>
>
next prev parent reply other threads:[~2026-09-11 16:19 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-11 11:28 [PATCH v10 00/14] arm_mpam: Add MPAM-Fb firmware support Andre Przywara
2026-09-11 11:28 ` [PATCH v10 01/14] arm_mpam: let low level MSC accessors return an error Andre Przywara
2026-09-11 11:28 ` [PATCH v10 02/14] arm_mpam: propagate MSC access errors for hw_probe functions Andre Przywara
2026-09-11 11:28 ` [PATCH v10 03/14] arm_mpam: propagate MSC access errors for MBWU counters Andre Przywara
2026-09-11 11:28 ` [PATCH v10 04/14] arm_mpam: propagate MSC access errors for msmon helpers Andre Przywara
2026-09-11 11:28 ` [PATCH v10 05/14] arm_mpam: propagate MSC access errors for __ris_msmon_read() Andre Przywara
2026-09-11 11:28 ` [PATCH v10 06/14] arm_mpam: propagate MSC access errors for state saving function Andre Przywara
2026-09-11 11:28 ` [PATCH v10 07/14] arm_mpam: propagate MSC access errors for mpam_reprogram_ris_partid() Andre Przywara
2026-09-11 11:28 ` [PATCH v10 08/14] arm_mpam: propagate MSC access errors for interrupt control Andre Przywara
2026-09-11 14:26 ` Ben Horgan
2026-09-11 16:19 ` Andre Przywara [this message]
2026-09-11 16:23 ` Ben Horgan
2026-09-11 11:28 ` [PATCH v10 09/14] arm_mpam: prepare mon_sel locking for MPAM-Fb Andre Przywara
2026-09-11 11:28 ` [PATCH v10 10/14] arm_mpam: add MPAM-Fb MSC firmware access support Andre Przywara
2026-09-11 15:13 ` Ben Horgan
2026-09-24 15:25 ` Andre Przywara
2026-09-11 11:28 ` [PATCH v10 11/14] arm_mpam: change MPAM-Fb error IRQ to use a threaded IRQ handler Andre Przywara
2026-09-11 11:28 ` [PATCH v10 12/14] arm_mpam: detect and enable MPAM-Fb PCC support Andre Przywara
2026-09-11 15:09 ` Ben Horgan
2026-09-21 16:09 ` Andre Przywara
2026-09-21 16:28 ` Ben Horgan
2026-09-24 9:48 ` Sudeep Holla
2026-09-24 10:35 ` Andre Przywara
2026-09-15 16:33 ` Ben Horgan
2026-09-24 15:26 ` Andre Przywara
2026-09-11 11:28 ` [RFC PATCH v10 13/14] ACPICA: actbl2.h: MPAM: adapt to MPAM ACPI v3.1 changes Andre Przywara
2026-09-11 11:28 ` [RFC PATCH v10 14/14] acpi: arm64: use MPAM-Fb offset field from ACPI table Andre Przywara
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=a305546a-29f4-45fb-a3e6-09a051733a2a@arm.com \
--to=andre.przywara@arm.com \
--cc=ben.horgan@arm.com \
--cc=catalin.marinas@arm.com \
--cc=fenghuay@nvidia.com \
--cc=ganapatrao.kulkarni@oss.qualcomm.com \
--cc=gshan@redhat.com \
--cc=guohanjun@huawei.com \
--cc=james.morse@arm.com \
--cc=jic23@kernel.org \
--cc=lee@trager.us \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=niyas.sait@arm.com \
--cc=rafael@kernel.org \
--cc=reinette.chatre@intel.com \
--cc=ritwick.sharma@arm.com \
--cc=sramana@qti.qualcomm.com \
--cc=srivathsa.rao@oss.qualcomm.com \
--cc=sudeep.holla@kernel.org \
--cc=tsoni@quicinc.com \
--cc=will@kernel.org \
/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.