From: Krzysztof Kozlowski <krzk@kernel.org>
To: Peter Griffin <peter.griffin@linaro.org>,
lee@kernel.org, arnd@arndb.de, alim.akhtar@samsung.com
Cc: linux-arm-kernel@lists.infradead.org,
linux-samsung-soc@vger.kernel.org, linux-kernel@vger.kernel.org,
tudor.ambarus@linaro.org, andre.draszik@linaro.org,
saravanak@google.com, willmcvicker@google.com,
semen.protsenko@linaro.org, kernel-team@android.com
Subject: Re: [PATCH 1/2] mfd: syscon: add of_syscon_register_regmap() API
Date: Wed, 19 Jun 2024 08:29:42 +0200 [thread overview]
Message-ID: <d904bcd0-62e3-47b0-acb2-0cf864fa33fb@kernel.org> (raw)
In-Reply-To: <20240614140421.3172674-2-peter.griffin@linaro.org>
On 14/06/2024 16:04, Peter Griffin wrote:
> The of_syscon_register_regmap() API allows an externally created regmap
> to be registered with syscon. This regmap can then be returned to client
> drivers using the syscon_regmap_lookup_by_phandle() APIs.
>
> The API is used by platforms where mmio access to the syscon registers is
> not possible, and a underlying soc driver like exynos-pmu provides a SoC
> specific regmap that can issue a SMC or hypervisor call to write the
> register.
>
> This approach keeps the SoC complexities out of syscon, but allows common
> drivers such as syscon-poweroff, syscon-reboot and friends that are used
> by many SoCs already to be re-used.
>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> ---
> drivers/mfd/syscon.c | 48 ++++++++++++++++++++++++++++++++++++++
> include/linux/mfd/syscon.h | 8 +++++++
> 2 files changed, 56 insertions(+)
>
> diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c
> index 7d0e91164cba..44991da3ea23 100644
> --- a/drivers/mfd/syscon.c
> +++ b/drivers/mfd/syscon.c
> @@ -192,6 +192,54 @@ static struct regmap *device_node_get_regmap(struct device_node *np,
> return syscon->regmap;
> }
>
> +/**
> + * of_syscon_register_regmap() - Register regmap for specified device node
> + * @np: Device tree node
> + * @regmap: Pointer to regmap object
> + *
> + * Register an externally created regmap object with syscon for the specified
> + * device tree node. This regmap can then be returned to client drivers using
> + * the syscon_regmap_lookup_by_phandle() API.
> + *
> + * Return: 0 on success, negative error code on failure.
> + */
> +int of_syscon_register_regmap(struct device_node *np, struct regmap *regmap)
> +{
> + struct syscon *entry, *syscon = NULL;
> +
> + if (!np || !regmap)
> + return -EINVAL;
> +
> + /* check if syscon entry already exists */
> + spin_lock(&syscon_list_slock);
> +
> + list_for_each_entry(entry, &syscon_list, list)
> + if (entry->np == np) {
> + syscon = entry;
> + break;
> + }
> +
> + spin_unlock(&syscon_list_slock);
> +
> + if (syscon)
> + return -EEXIST;
> +
> + syscon = kzalloc(sizeof(*syscon), GFP_KERNEL);
> + if (!syscon)
> + return -ENOMEM;
> +
> + syscon->regmap = regmap;
> + syscon->np = np;
> +
> + /* register the regmap in syscon list */
> + spin_lock(&syscon_list_slock);
You still have window between the check for existing syscon and adding
to the list. This likely is not an issue now, but it might if we have
more devices using same syscon and we enable asynchronous probing.
> + list_add_tail(&syscon->list, &syscon_list);
> + spin_unlock(&syscon_list_slock);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(of_syscon_register_regmap);
> +
Best regards,
Krzysztof
next prev parent reply other threads:[~2024-06-19 6:29 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-14 14:04 [PATCH 0/2] Add syscon of_syscon_register_regmap api Peter Griffin
2024-06-14 14:04 ` [PATCH 1/2] mfd: syscon: add of_syscon_register_regmap() API Peter Griffin
2024-06-17 9:35 ` André Draszik
2024-06-18 14:43 ` Arnd Bergmann
2024-06-18 17:50 ` Sam Protsenko
2024-06-19 6:29 ` Krzysztof Kozlowski [this message]
2024-06-19 8:17 ` Peter Griffin
2024-06-14 14:04 ` [PATCH 2/2] soc: samsung: exynos-pmu: update to use of_syscon_register_regmap() Peter Griffin
2024-06-17 9:35 ` André Draszik
2024-06-18 14:43 ` Arnd Bergmann
2024-06-18 17:47 ` Sam Protsenko
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=d904bcd0-62e3-47b0-acb2-0cf864fa33fb@kernel.org \
--to=krzk@kernel.org \
--cc=alim.akhtar@samsung.com \
--cc=andre.draszik@linaro.org \
--cc=arnd@arndb.de \
--cc=kernel-team@android.com \
--cc=lee@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=peter.griffin@linaro.org \
--cc=saravanak@google.com \
--cc=semen.protsenko@linaro.org \
--cc=tudor.ambarus@linaro.org \
--cc=willmcvicker@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox