Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Cristian Marussi <cristian.marussi@arm.com>
Cc: linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, arm-scmi@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, linux-doc@vger.kernel.org,
	sudeep.holla@kernel.org, james.quinlan@broadcom.com,
	f.fainelli@gmail.com, vincent.guittot@linaro.org,
	etienne.carriere@st.com, peng.fan@oss.nxp.com,
	michal.simek@amd.com, d-gole@ti.com, elif.topuz@arm.com,
	lukasz.luba@arm.com, philip.radford@arm.com, brauner@kernel.org,
	souvik.chakravarty@arm.com, david@kernel.org,
	subrahmanya.lingappa@oss.qualcomm.com, leitao@kernel.org,
	kas@kernel.org, puranjay@kernel.org, usama.arif@linux.dev,
	kernel-team@meta.com
Subject: Re: [PATCH v6 03/22] firmware: arm_scmi: Introduce protocol instance notifiers
Date: Tue, 28 Jul 2026 01:00:04 +0100	[thread overview]
Message-ID: <20260728010004.35fcac96@jic23-huawei> (raw)
In-Reply-To: <20260724144430.1440170-4-cristian.marussi@arm.com>

On Fri, 24 Jul 2026 15:44:11 +0100
Cristian Marussi <cristian.marussi@arm.com> wrote:

> Allow protocols themselves to register for their own notifications and
> provide their own notifier callbacks. Each protocol can now register one
> unique per-protocol instance notifier block whose callback will be
> registered on the proper notification chain as usual: such notifier will
> be automatically removed during the protocol de-initialiazation phase.
> 

Would be nice to say why they might do this. I'm sure it becomes
apparent later in the series, but anyone looking just this patch
is missing that useful information.

I'd also like something here to talk briefly about why it is fine to
drop the lock briefly on the unregister side.

> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>


> diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
> index 8e06e40d1a11..0f9e8dfc6137 100644
> --- a/drivers/firmware/arm_scmi/driver.c
> +++ b/drivers/firmware/arm_scmi/driver.c
...


> @@ -2367,13 +2402,29 @@ int scmi_protocol_acquire(const struct scmi_handle *handle, u8 protocol_id)
>  void scmi_protocol_release(const struct scmi_handle *handle, u8 protocol_id)
>  {
>  	struct scmi_info *info = handle_to_scmi_info(handle);
> +	struct notifier_block *proto_notifier_nb = NULL;
>  	struct scmi_protocol_instance *pi;
>  
> -	mutex_lock(&info->protocols_mtx);
> -	pi = idr_find(&info->protocols, protocol_id);
> -	if (WARN_ON(!pi))
> -		goto out;
> +	scoped_guard(mutex, &info->protocols_mtx) {
> +		pi = idr_find(&info->protocols, protocol_id);
> +		if (WARN_ON(!pi))
> +			return;
> +
> +		proto_notifier_nb = pi->pno.nb;
> +		/* Ensure NULL is visible */
> +		smp_store_mb(pi->pno.nb, NULL);
> +	}
>  

I'd like to see a little commentary on safety of not holding
the mutex over the whole sequence.  Can anything mess around
with pi between the code getting hold of it and the release below?
I assume the refcount is enough.

> +	if (proto_notifier_nb) {
> +		int ret;
> +
> +		ret = scmi_protocol_notifier_unregister(pi->handle, &pi->pno);
> +		if (ret)

Maybe this changes later but if not get rid of ret. It kind of suggests
the value itself is useful in a way that isn't true.

		if (scm_protocol_notifier_unregister(pi->handle, &pi->pno))
			dev_err();

> +			dev_err(handle->dev,
> +				"Failed to release protocol notifier\n");
> +	}
> +
> +	guard(mutex)(&info->protocols_mtx);
>  	if (refcount_dec_and_test(&pi->users)) {
>  		void *gid = pi->gid;
>  
> @@ -2391,9 +2442,6 @@ void scmi_protocol_release(const struct scmi_handle *handle, u8 protocol_id)
>  		dev_dbg(handle->dev, "De-Initialized protocol: 0x%X\n",
>  			protocol_id);
>  	}
> -
> -out:
> -	mutex_unlock(&info->protocols_mtx);
>  }
>  



  reply	other threads:[~2026-07-28  0:00 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-24 14:44 [PATCH v6 00/22] Introduce SCMI Telemetry support Cristian Marussi
2026-07-24 14:44 ` [PATCH v6 01/22] firmware: arm_scmi: Add new SCMIv4.0 error codes definitions Cristian Marussi
2026-07-27 23:41   ` Jonathan Cameron
2026-07-24 14:44 ` [PATCH v6 02/22] firmware: arm_scmi: Allow registration of unknown-size events/reports Cristian Marussi
2026-07-27 23:47   ` Jonathan Cameron
2026-07-24 14:44 ` [PATCH v6 03/22] firmware: arm_scmi: Introduce protocol instance notifiers Cristian Marussi
2026-07-28  0:00   ` Jonathan Cameron [this message]
2026-07-24 14:44 ` [PATCH v6 04/22] dt-bindings: firmware: arm,scmi: Add support for telemetry protocol Cristian Marussi
2026-07-24 14:44 ` [PATCH v6 05/22] include: trace: Add Telemetry trace events Cristian Marussi
2026-07-28  0:05   ` Jonathan Cameron
2026-07-24 14:44 ` [PATCH v6 06/22] firmware: arm_scmi: Add basic Telemetry support Cristian Marussi
2026-07-28  1:27   ` Jonathan Cameron
2026-07-24 14:44 ` [PATCH v6 07/22] firmware: arm_scmi: Add support to parse SHMTIs areas Cristian Marussi
2026-07-24 14:44 ` [PATCH v6 08/22] firmware: arm_scmi: Add Telemetry configuration operations Cristian Marussi
2026-07-24 14:44 ` [PATCH v6 09/22] firmware: arm_scmi: Add Telemetry DataEvent read capabilities Cristian Marussi
2026-07-24 14:44 ` [PATCH v6 10/22] firmware: arm_scmi: Add support for Telemetry reset Cristian Marussi
2026-07-24 14:44 ` [PATCH v6 11/22] firmware: arm_scmi: Add Telemetry notification support Cristian Marussi
2026-07-24 14:44 ` [PATCH v6 12/22] firmware: arm_scmi: Add support for boot-on Telemetry Cristian Marussi
2026-07-24 14:44 ` [PATCH v6 13/22] firmware: arm_scmi: Add Telemetry generation counter Cristian Marussi
2026-07-24 14:44 ` [PATCH v6 14/22] firmware: arm_scmi: Add common per-protocol debugfs support Cristian Marussi
2026-07-24 14:44 ` [PATCH v6 15/22] firmware: arm_scmi: Add Telemetry debugfs SHMTI dump support Cristian Marussi
2026-07-24 14:44 ` [PATCH v6 16/22] firmware: arm_scmi: Add Telemetry debugfs ABI documentation Cristian Marussi
2026-07-24 14:44 ` [PATCH v6 17/22] firmware: arm_scmi: Expose per-instance identifier Cristian Marussi
2026-07-24 14:44 ` [PATCH v6 18/22] uapi: Add ARM SCMI Telemetry definitions Cristian Marussi
2026-07-24 14:44 ` [PATCH v6 19/22] firmware: arm_scmi: Add System Telemetry driver Cristian Marussi
2026-07-24 14:44 ` [PATCH v6 20/22] docs: ioctl-number: Add SCMI Ioctls Cristian Marussi
2026-07-24 14:44 ` [PATCH v6 21/22] [RFC] Documentation: Add SCMI System Telemetry documentation Cristian Marussi
2026-07-24 15:05   ` Jonathan Corbet
2026-07-24 14:44 ` [PATCH v6 22/22] [RFC] tools/scmi: Add SCMI Telemetry testing tool Cristian Marussi

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=20260728010004.35fcac96@jic23-huawei \
    --to=jic23@kernel.org \
    --cc=arm-scmi@vger.kernel.org \
    --cc=brauner@kernel.org \
    --cc=cristian.marussi@arm.com \
    --cc=d-gole@ti.com \
    --cc=david@kernel.org \
    --cc=elif.topuz@arm.com \
    --cc=etienne.carriere@st.com \
    --cc=f.fainelli@gmail.com \
    --cc=james.quinlan@broadcom.com \
    --cc=kas@kernel.org \
    --cc=kernel-team@meta.com \
    --cc=leitao@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lukasz.luba@arm.com \
    --cc=michal.simek@amd.com \
    --cc=peng.fan@oss.nxp.com \
    --cc=philip.radford@arm.com \
    --cc=puranjay@kernel.org \
    --cc=souvik.chakravarty@arm.com \
    --cc=subrahmanya.lingappa@oss.qualcomm.com \
    --cc=sudeep.holla@kernel.org \
    --cc=usama.arif@linux.dev \
    --cc=vincent.guittot@linaro.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox