mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "David Hildenbrand (Arm)" <david@kernel.org>
To: Cristian Marussi <cristian.marussi@arm.com>,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, arm-scmi@vger.kernel.org,
	linux-doc@vger.kernel.org
Cc: 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, jic23@kernel.org,
	elif.topuz@arm.com, lukasz.luba@arm.com, philip.radford@arm.com,
	souvik.chakravarty@arm.com, leitao@kernel.org, kas@kernel.org,
	puranjay@kernel.org, usama.arif@linux.dev, kernel-team@meta.com,
	Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
Subject: Re: [PATCH v12 03/25] firmware: arm_scmi: Introduce protocol instance notifiers
Date: Tue, 22 Sep 2026 15:44:48 +0200	[thread overview]
Message-ID: <c80354c7-0153-4a82-a9a1-9e2fd2929449@kernel.org> (raw)
In-Reply-To: <20260920091928.2014972-4-cristian.marussi@arm.com>

On 9/20/26 11:19, Cristian Marussi wrote:
> SCMI Protocol notifications are typically used by SCMI drivers to detect
> and react to particular conditions: this was the assumption and the classic
> usage scenario upon which the SCMI notification framework was built.

Was the paragraph supposed to start with "SCMI notifications" ? Because later
you describe how some protocols might want to reuse the "existing SCMI
Notifications machinery", and here you talk about the traditional usage.

> -	mutex_lock(&info->protocols_mtx);
> -	pi = idr_find(&info->protocols, protocol_id);
> +	scoped_guard(mutex, &info->protocols_mtx) {
> +		pi = idr_find(&info->protocols, protocol_id);
> +		if (pi) {
> +			refcount_inc(&pi->users);
> +		} else {
> +			const struct scmi_protocol *proto;
>  
> -	if (pi) {
> -		refcount_inc(&pi->users);
> -	} else {
> -		const struct scmi_protocol *proto;
> +			/* Fails if protocol not registered on bus */
> +			proto = scmi_protocol_get(protocol_id, &info->version);
> +			if (!proto)
> +				return ERR_PTR(-EPROBE_DEFER);
>  
> -		/* Fails if protocol not registered on bus */
> -		proto = scmi_protocol_get(protocol_id, &info->version);
> -		if (proto)
>  			pi = scmi_alloc_init_protocol_instance(info, proto);
> -		else
> -			pi = ERR_PTR(-EPROBE_DEFER);
> +			if (IS_ERR(pi))
> +				return pi;
> +
> +			proto_notifier_nb = READ_ONCE(pi->pno.nb);
> +		}
> +	}
> +
> +	if (proto_notifier_nb) {
> +		if (scmi_protocol_notifier_register(pi->handle, &pi->pno))
> +			dev_warn(handle->dev,
> +				 "Failed to register protocol notifier\n");


	if (proto_notifier_nb &&
	    scmi_protocol_notifier_register(pi->handle, &pi->pno))
		dev_warn(handle->dev, ...)

As we dropped the mutex, I assume somebody else could move ahead and
refcount_inc(&pi->users) + return before the notifier was registered? Is that
expected?


>  	}
> -	mutex_unlock(&info->protocols_mtx);
>  
>  	return pi;
>  }
> @@ -2366,13 +2398,35 @@ 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;
>  
> +		/*
> +		 * If a protocol notifier was registered and this is the
> +		 * last istance releasing the protocol, mark the notifier

s/istance/instance/

> +		 * for un-registration: note that the notifier itself counts
> +		 * as one user, as for any other regular notification, so if a
> +		 * protocol notifier is registered and there are only 2 users
> +		 * active we can derive that this is the last protocol
> +		 * instance de-registering.
> +		 */
> +		if (scmi_protocol_notifier_registered(&pi->pno) &&
> +		    refcount_read(&pi->users) == 2)
> +			proto_notifier_nb = READ_ONCE(pi->pno.nb);
> +	}
> +

We drop the mutex now temporarily. What happens if another instance gets
registered (incrementing &pi->users) just after we dropped the lock and
unregister the notifier?

Shouldn't we care about that or why is it ok?

-- 
Cheers,

David

  reply	other threads:[~2026-09-22 13:44 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-20  9:19 [PATCH v12 00/25] Introduce SCMI Telemetry support Cristian Marussi
2026-09-20  9:19 ` [PATCH v12 01/25] firmware: arm_scmi: Add new SCMIv4.0 error codes definitions Cristian Marussi
2026-09-22 12:20   ` David Hildenbrand (Arm)
2026-09-22 17:32     ` Cristian Marussi
2026-09-20  9:19 ` [PATCH v12 02/25] firmware: arm_scmi: Allow registration of unknown-size events/reports Cristian Marussi
2026-09-22 13:15   ` David Hildenbrand (Arm)
2026-09-20  9:19 ` [PATCH v12 03/25] firmware: arm_scmi: Introduce protocol instance notifiers Cristian Marussi
2026-09-22 13:44   ` David Hildenbrand (Arm) [this message]
2026-09-20  9:19 ` [PATCH v12 04/25] dt-bindings: firmware: arm,scmi: Add support for telemetry protocol Cristian Marussi
2026-09-20  9:19 ` [PATCH v12 05/25] include: trace: Add Telemetry trace events Cristian Marussi
2026-09-22 13:48   ` David Hildenbrand (Arm)
2026-09-20  9:19 ` [PATCH v12 06/25] firmware: arm_scmi: Add basic Telemetry support Cristian Marussi
2026-09-22 14:42   ` David Hildenbrand (Arm)
2026-09-20  9:19 ` [PATCH v12 07/25] firmware: arm_scmi: Add support to parse SHMTIs areas Cristian Marussi
2026-09-20  9:19 ` [PATCH v12 08/25] firmware: arm_scmi: Add Telemetry configuration operations Cristian Marussi
2026-09-20  9:19 ` [PATCH v12 09/25] firmware: arm_scmi: Add Telemetry DataEvent read capabilities Cristian Marussi
2026-09-20  9:19 ` [PATCH v12 10/25] firmware: arm_scmi: Add support for Telemetry reset Cristian Marussi
2026-09-20  9:19 ` [PATCH v12 11/25] firmware: arm_scmi: Add Telemetry notification support Cristian Marussi
2026-09-20  9:19 ` [PATCH v12 12/25] firmware: arm_scmi: Add support for boot-on Telemetry Cristian Marussi
2026-09-20  9:19 ` [PATCH v12 13/25] firmware: arm-scmi: Add telemetry generic event support Cristian Marussi
2026-09-20  9:19 ` [PATCH v12 14/25] firmware: arm_scmi: Add Telemetry generation counter event Cristian Marussi
2026-09-20  9:19 ` [PATCH v12 15/25] firmware: arm_scmi: Add common per-protocol debugfs support Cristian Marussi
2026-09-20  9:19 ` [PATCH v12 16/25] firmware: arm_scmi: Add Telemetry debugfs SHMTI dump support Cristian Marussi
2026-09-20  9:19 ` [PATCH v12 17/25] firmware: arm_scmi: Add Telemetry debugfs ABI documentation Cristian Marussi
2026-09-20  9:19 ` [PATCH v12 18/25] firmware: arm_scmi: Expose per-instance identifier Cristian Marussi
2026-09-20  9:19 ` [PATCH v12 19/25] firmware: arm_scmi: Add un-managed methods to get/put protocols operations Cristian Marussi
2026-09-20  9:19 ` [PATCH v12 20/25] uapi: Add ARM SCMI Telemetry definitions Cristian Marussi
2026-09-20  9:19 ` [PATCH v12 21/25] firmware: arm_scmi: Add System Telemetry driver Cristian Marussi
2026-09-20  9:19 ` [PATCH v12 22/25] docs: ioctl-number: Add SCMI Ioctls Cristian Marussi
2026-09-20  9:19 ` [PATCH v12 23/25] [RFC] Documentation: Add SCMI System Telemetry documentation Cristian Marussi
2026-09-20  9:19 ` [PATCH v12 24/25] [RFC] tools/scmi: Add SCMI Telemetry testing tool Cristian Marussi
2026-09-20  9:19 ` [PATCH v12 25/25] [RFC] kselftest/arm64: Add SCMI Telemetry UAPI compliance testcases 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=c80354c7-0153-4a82-a9a1-9e2fd2929449@kernel.org \
    --to=david@kernel.org \
    --cc=arm-scmi@vger.kernel.org \
    --cc=cristian.marussi@arm.com \
    --cc=d-gole@ti.com \
    --cc=elif.topuz@arm.com \
    --cc=etienne.carriere@st.com \
    --cc=f.fainelli@gmail.com \
    --cc=james.quinlan@broadcom.com \
    --cc=jic23@kernel.org \
    --cc=jonathan.cameron@oss.qualcomm.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-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=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

all inboxes | Powered by JetHome®