From: Peter Griffin <peter.griffin@linaro.org>
To: Guenter Roeck <linux@roeck-us.net>
Cc: arnd@arndb.de, krzysztof.kozlowski@linaro.org,
wim@linux-watchdog.org, alim.akhtar@samsung.com,
jaewon02.kim@samsung.com, semen.protsenko@linaro.org,
kernel-team@android.com, tudor.ambarus@linaro.org,
andre.draszik@linaro.org, saravanak@google.com,
willmcvicker@google.com, linux-fsd@tesla.com,
linux-watchdog@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-samsung-soc@vger.kernel.org
Subject: Re: [PATCH v2 1/2] soc: samsung: exynos-pmu: Add regmap support for SoCs that protect PMU regs
Date: Tue, 30 Jan 2024 15:01:54 +0000 [thread overview]
Message-ID: <CADrjBPrr5t-ZbYH-agsfniztBCtf15UMMmUGTNuHTX3dm=Rkxw@mail.gmail.com> (raw)
In-Reply-To: <b1798b8a-5794-4c79-a1d3-50259fa3ba81@roeck-us.net>
Hi Guenter,
Thanks for the feedback.
On Tue, 30 Jan 2024 at 06:26, Guenter Roeck <linux@roeck-us.net> wrote:
>
> On 1/29/24 13:19, Peter Griffin wrote:
> > Some Exynos based SoCs like Tensor gs101 protect the PMU registers for
> > security hardening reasons so that they are only accessible in el3 via an
> > SMC call.
> >
> > As most Exynos drivers that need to write PMU registers currently obtain a
> > regmap via syscon (phys, pinctrl, watchdog). Support for the above usecase
> > is implemented in this driver using a custom regmap similar to syscon to
> > handle the SMC call. Platforms that don't secure PMU registers, get a mmio
> > regmap like before. As regmaps abstract out the underlying register access
> > changes to the leaf drivers are minimal.
> >
> > A new API exynos_get_pmu_regmap_by_phandle() is provided for leaf drivers
> > that currently use syscon_regmap_lookup_by_phandle(). This also handles
> > deferred probing.
> >
> > Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> > ---
> [ ... ]
>
> > +/**
> > + * exynos_get_pmu_regmap
> > + * Find the pmureg previously configured in probe() and return regmap property.
> > + * Return: regmap if found or error if not found.
> > + */
> > struct regmap *exynos_get_pmu_regmap(void)
> > {
> > struct device_node *np = of_find_matching_node(NULL,
> > exynos_pmu_of_device_ids);
> > if (np)
> > - return syscon_node_to_regmap(np);
> > + return exynos_get_pmu_regmap_by_phandle(np, NULL);
> > return ERR_PTR(-ENODEV);
> > }
> > EXPORT_SYMBOL_GPL(exynos_get_pmu_regmap);
> >
> > +/**
> > + * exynos_get_pmu_regmap_by_phandle
> > + * Find the pmureg previously configured in probe() and return regmap property.
> > + * Return: regmap if found or error if not found.
> > + *
> > + * @np: Pointer to device's Device Tree node
> > + * @property: Device Tree property name which references the pmu
> > + */
> > +struct regmap *exynos_get_pmu_regmap_by_phandle(struct device_node *np,
> > + const char *property)
> > +{
> > + struct device *dev;
> > + struct exynos_pmu_context *ctx;
> > + struct device_node *pmu_np;
> > +
> > + if (property)
> > + pmu_np = of_parse_phandle(np, property, 0);
> > + else
> > + pmu_np = np;
> > +
> > + if (!pmu_np)
> > + return ERR_PTR(-ENODEV);
> > +
> > + dev = driver_find_device_by_of_node(&exynos_pmu_driver.driver,
> > + (void *)pmu_np);
> > + of_node_put(pmu_np);
> > + if (!dev)
> > + return ERR_PTR(-EPROBE_DEFER);
> > +
> > + ctx = dev_get_drvdata(dev);
> > +
> > + return ctx->pmureg;
> > +}
> > +EXPORT_SYMBOL_GPL(exynos_get_pmu_regmap_by_phandle);
> > +
>
> I think there should be a detailed comment explaining why the complexity
> is necessary instead of just returning pmu_context->pmureg.
Ok, I'll add a detailed comment for v3.
Thanks,
Peter
next prev parent reply other threads:[~2024-01-30 15:02 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-29 21:19 [PATCH v2 0/2] Add regmap support to exynos-pmu for protected PMU regs Peter Griffin
2024-01-29 21:19 ` [PATCH v2 1/2] soc: samsung: exynos-pmu: Add regmap support for SoCs that protect " Peter Griffin
2024-01-29 23:01 ` Sam Protsenko
2024-01-30 14:51 ` Peter Griffin
2024-01-30 6:26 ` Guenter Roeck
2024-01-30 15:01 ` Peter Griffin [this message]
2024-01-30 16:01 ` Krzysztof Kozlowski
2024-02-01 11:29 ` Peter Griffin
2024-02-05 11:03 ` Krzysztof Kozlowski
2024-02-01 12:51 ` Peter Griffin
2024-02-05 13:13 ` Krzysztof Kozlowski
2024-02-07 11:42 ` Peter Griffin
2024-02-07 14:48 ` Krzysztof Kozlowski
2024-01-29 21:19 ` [PATCH v2 2/2] watchdog: s3c2410_wdt: use exynos_get_pmu_regmap_by_phandle() for " Peter Griffin
2024-01-29 22:25 ` Saravana Kannan
2024-01-30 3:38 ` Sam Protsenko
2024-01-30 15:31 ` Peter Griffin
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='CADrjBPrr5t-ZbYH-agsfniztBCtf15UMMmUGTNuHTX3dm=Rkxw@mail.gmail.com' \
--to=peter.griffin@linaro.org \
--cc=alim.akhtar@samsung.com \
--cc=andre.draszik@linaro.org \
--cc=arnd@arndb.de \
--cc=devicetree@vger.kernel.org \
--cc=jaewon02.kim@samsung.com \
--cc=kernel-team@android.com \
--cc=krzysztof.kozlowski@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-fsd@tesla.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=linux-watchdog@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=saravanak@google.com \
--cc=semen.protsenko@linaro.org \
--cc=tudor.ambarus@linaro.org \
--cc=willmcvicker@google.com \
--cc=wim@linux-watchdog.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;
as well as URLs for NNTP newsgroup(s).