All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Andersson <andersson@kernel.org>
To: Mukesh Ojha <quic_mojha@quicinc.com>
Cc: konrad.dybcio@linaro.org, linux-arm-msm@vger.kernel.org,
	 linux-kernel@vger.kernel.org, linus.walleij@linaro.org,
	linux-gpio@vger.kernel.org,
	 Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
	Kathiravan Thirumoorthy <quic_kathirav@quicinc.com>
Subject: Re: [PATCH v12 2/9] firmware: qcom: scm: provide a read-modify-write function
Date: Sat, 2 Mar 2024 13:09:39 -0600	[thread overview]
Message-ID: <xht25xxxzxmb24yobz4drmo5u4btlqo4akhscow7g5to7zyh3g@75bl5ddhib43> (raw)
In-Reply-To: <20240227155308.18395-3-quic_mojha@quicinc.com>

On Tue, Feb 27, 2024 at 09:23:01PM +0530, Mukesh Ojha wrote:
> It is possible that different bits of a secure register is used
> for different purpose and currently, there is no such available
> function from SCM driver to do that; one similar usage was pointed
> by Srinivas K. inside pinctrl-msm where interrupt configuration
> register lying in secure region and written via read-modify-write
> operation.
> 
> Export qcom_scm_io_rmw() to do read-modify-write operation on secure
> register and reuse it wherever applicable, also document scm_lock
> to convey its usage.
> 
> Suggested-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com>
> Tested-by: Kathiravan Thirumoorthy <quic_kathirav@quicinc.com> # IPQ9574 and IPQ5332
> ---
>  drivers/firmware/qcom/qcom_scm.c       | 33 ++++++++++++++++++++++++++
>  include/linux/firmware/qcom/qcom_scm.h |  1 +
>  2 files changed, 34 insertions(+)
> 
> diff --git a/drivers/firmware/qcom/qcom_scm.c b/drivers/firmware/qcom/qcom_scm.c
> index 2d0ba529cf56..8f766fce5f7c 100644
> --- a/drivers/firmware/qcom/qcom_scm.c
> +++ b/drivers/firmware/qcom/qcom_scm.c
> @@ -193,6 +193,11 @@ static void qcom_scm_bw_disable(void)
>  }
>  
>  enum qcom_scm_convention qcom_scm_convention = SMC_CONVENTION_UNKNOWN;
> +/*
> + * scm_lock to serialize call to query SMC convention and
> + * to atomically operate(read-modify-write) on different
> + * bits of secure register.
> + */
>  static DEFINE_SPINLOCK(scm_lock);
>  
>  static enum qcom_scm_convention __get_convention(void)
> @@ -481,6 +486,34 @@ static int qcom_scm_disable_sdi(void)
>  	return ret ? : res.result[0];
>  }
>  
> +int qcom_scm_io_rmw(phys_addr_t addr, unsigned int mask, unsigned int val)
> +{
> +	unsigned long flags;
> +	unsigned int old;
> +	unsigned int new;
> +	int ret;
> +
> +	if (!__scm)
> +		return -EPROBE_DEFER;
> +
> +	/*
> +	 * Lock to atomically do rmw operation on different bits
> +	 * of secure register
> +	 */

A spinlock does not make something globally atomic, all you have made
sure is that:
1) qcom_scm_io_rmw() can not happen concurrently with __get_convention()

The reuse of the lock makes me wonder what the use case you're having a
need to protect #1... When is rmw happening concurrently with convention
detection?

2) Two qcom_scm_io_rmw() can not happen concurrently

What happens if a separate process invokes qcom_scm_io_write() of the
same address concurrently with qcom_scm_io_rmw()?


Quite likely neither of these will happen in practice, and I'm guessing
that there will not be any caching issues etc among different calls to
qcom_scm_io_*(), and hence this spinlock serves just to complicate the
implementation.

Please add a kernel-doc comment to this function (and perhaps
qcom_scm_io_write()) and describe that we don't guarantee this operation
to happen atomically - or if you have a valid reason, document that and
it's exact limitations.


PS. I would have been perfectly happy with us not adding a rmw function.
You're adding 34 lines of code to save 2*3 lines of duplicated, easy to
understand, code.

Regards,
Bjorn

> +	spin_lock_irqsave(&scm_lock, flags);
> +	ret = qcom_scm_io_readl(addr, &old);
> +	if (ret)
> +		goto unlock;
> +
> +	new = (old & ~mask) | (val & mask);
> +
> +	ret = qcom_scm_io_writel(addr, new);
> +unlock:
> +	spin_unlock_irqrestore(&scm_lock, flags);
> +	return ret;
> +}
> +EXPORT_SYMBOL_GPL(qcom_scm_io_rmw);
> +
>  static int __qcom_scm_set_dload_mode(struct device *dev, bool enable)
>  {
>  	struct qcom_scm_desc desc = {
> diff --git a/include/linux/firmware/qcom/qcom_scm.h b/include/linux/firmware/qcom/qcom_scm.h
> index ccaf28846054..3a8bb2e603b3 100644
> --- a/include/linux/firmware/qcom/qcom_scm.h
> +++ b/include/linux/firmware/qcom/qcom_scm.h
> @@ -82,6 +82,7 @@ bool qcom_scm_pas_supported(u32 peripheral);
>  
>  int qcom_scm_io_readl(phys_addr_t addr, unsigned int *val);
>  int qcom_scm_io_writel(phys_addr_t addr, unsigned int val);
> +int qcom_scm_io_rmw(phys_addr_t addr, unsigned int mask, unsigned int val);
>  
>  bool qcom_scm_restore_sec_cfg_available(void);
>  int qcom_scm_restore_sec_cfg(u32 device_id, u32 spare);
> -- 
> 2.43.0.254.ga26002b62827
> 

  reply	other threads:[~2024-03-02 19:09 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-27 15:52 [PATCH v12 0/9] Misc SCM driver changes Mukesh Ojha
2024-02-27 15:53 ` [PATCH v12 1/9] firmware: qcom: scm: Rename scm_query_lock to scm_lock Mukesh Ojha
2024-03-02 19:10   ` Bjorn Andersson
2024-02-27 15:53 ` [PATCH v12 2/9] firmware: qcom: scm: provide a read-modify-write function Mukesh Ojha
2024-03-02 19:09   ` Bjorn Andersson [this message]
2024-03-05 10:39     ` Mukesh Ojha
2024-02-27 15:53 ` [PATCH v12 3/9] firmware: qcom: scm: Modify only the download bits in TCSR register Mukesh Ojha
2024-03-02 19:13   ` Bjorn Andersson
2024-03-05 10:43     ` Mukesh Ojha
2024-02-27 15:53 ` [PATCH v12 4/9] firmware: qcom: scm: Rework dload mode availability check Mukesh Ojha
2024-03-02 19:16   ` Bjorn Andersson
2024-03-05 10:54     ` Mukesh Ojha
2024-02-27 15:53 ` [PATCH v12 5/9] pinctrl: qcom: Use qcom_scm_io_rmw() function Mukesh Ojha
2024-02-29 13:56   ` Linus Walleij
2024-02-27 15:53 ` [PATCH v12 6/9] firmware: qcom: scm: Remove log reporting memory allocation failure Mukesh Ojha
2024-03-02 19:18   ` Bjorn Andersson
2024-02-27 15:53 ` [PATCH v12 7/9] firmware: qcom: scm: Fix __scm->dev assignement Mukesh Ojha
2024-03-02 19:25   ` Bjorn Andersson
2024-03-18 13:08     ` Mukesh Ojha
2024-03-19  1:17       ` Pavan Kondeti
2024-03-19 10:08         ` Mukesh Ojha
2024-03-19 10:22           ` Pavan Kondeti
2024-03-19 14:39             ` Mukesh Ojha
2024-02-27 15:53 ` [PATCH v12 8/9] firmware: qcom: scm: Add check to prevent Null pointer dereference Mukesh Ojha
2024-02-27 16:56   ` Elliot Berman
2024-02-28 15:08     ` Mukesh Ojha
2024-03-01 23:42   ` Konrad Dybcio
2024-03-02 18:57   ` Bjorn Andersson
2024-02-27 15:53 ` [PATCH v12 9/9] firmware: scm: Remove redundant scm argument from qcom_scm_waitq_wakeup() Mukesh Ojha
2024-03-02 19:23   ` Bjorn Andersson

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=xht25xxxzxmb24yobz4drmo5u4btlqo4akhscow7g5to7zyh3g@75bl5ddhib43 \
    --to=andersson@kernel.org \
    --cc=konrad.dybcio@linaro.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=quic_kathirav@quicinc.com \
    --cc=quic_mojha@quicinc.com \
    --cc=srinivas.kandagatla@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 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.