linux-kernel - Re: [PATCH 2/7] phy: exynos5-usbdrd: use exynos_get_pmu_regmap_by

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CADrjBPpQEbxVbDwat1fn=2tYk9r-0up0+SARFZA=qkoeFYz1Mg@mail.gmail.com>
Date: Thu, 25 Apr 2024 11:02:45 +0100
From: Peter Griffin <peter.griffin@...aro.org>
To: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>, Arnd Bergmann <arnd@...db.de>, lee@...nel.org
Cc: André Draszik <andre.draszik@...aro.org>, 
	Vinod Koul <vkoul@...nel.org>, Kishon Vijay Abraham I <kishon@...nel.org>, Rob Herring <robh@...nel.org>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	Marek Szyprowski <m.szyprowski@...sung.com>, Sylwester Nawrocki <s.nawrocki@...sung.com>, 
	Alim Akhtar <alim.akhtar@...sung.com>, Sam Protsenko <semen.protsenko@...aro.org>, 
	Krzysztof Kozlowski <krzk@...nel.org>, Tudor Ambarus <tudor.ambarus@...aro.org>, 
	Will McVicker <willmcvicker@...gle.com>, Roy Luo <royluo@...gle.com>, kernel-team@...roid.com, 
	linux-phy@...ts.infradead.org, devicetree@...r.kernel.org, 
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, 
	linux-samsung-soc@...r.kernel.org
Subject: Re: [PATCH 2/7] phy: exynos5-usbdrd: use exynos_get_pmu_regmap_by_phandle()
 for PMU regs

Hi Krzysztof,

+ Arnd & Lee (syscon maintainers)

On Thu, 25 Apr 2024 at 08:47, Krzysztof Kozlowski
<krzysztof.kozlowski@...aro.org> wrote:
>
> On 23/04/2024 19:06, André Draszik wrote:
> > Some Exynos based SoCs like Tensor gs101 protect the PMU registers for
> > security hardening reasons so that they are only write accessible in
> > EL3 via an SMC call.
> >
> > The Exynos PMU driver handles this transparently when using
> > exynos_get_pmu_regmap_by_phandle().
> >
> > Switch to using that API to support such SoCs. As this driver now no
> > longer depends on mfd syscon remove that header and Kconfig dependency.
> >
> > Signed-off-by: André Draszik <andre.draszik@...aro.org>
> > ---
> >  drivers/phy/samsung/Kconfig              | 1 -
> >  drivers/phy/samsung/phy-exynos5-usbdrd.c | 4 ++--
> >  2 files changed, 2 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/phy/samsung/Kconfig b/drivers/phy/samsung/Kconfig
> > index f10afa3d7ff5..bb63fa710803 100644
> > --- a/drivers/phy/samsung/Kconfig
> > +++ b/drivers/phy/samsung/Kconfig
> > @@ -82,7 +82,6 @@ config PHY_EXYNOS5_USBDRD
> >       depends on HAS_IOMEM
> >       depends on USB_DWC3_EXYNOS
> >       select GENERIC_PHY
> > -     select MFD_SYSCON
> >       default y
> >       help
> >         Enable USB DRD PHY support for Exynos 5 SoC series.
> > diff --git a/drivers/phy/samsung/phy-exynos5-usbdrd.c b/drivers/phy/samsung/phy-exynos5-usbdrd.c
> > index 04171eed5b16..ac208b89f5a6 100644
> > --- a/drivers/phy/samsung/phy-exynos5-usbdrd.c
> > +++ b/drivers/phy/samsung/phy-exynos5-usbdrd.c
> > @@ -18,9 +18,9 @@
> >  #include <linux/phy/phy.h>
> >  #include <linux/platform_device.h>
> >  #include <linux/mutex.h>
> > -#include <linux/mfd/syscon.h>
> >  #include <linux/regmap.h>
> >  #include <linux/regulator/consumer.h>
> > +#include <linux/soc/samsung/exynos-pmu.h>
> >  #include <linux/soc/samsung/exynos-regs-pmu.h>
>
> This is getting out of hand: shall we expect to convert all the drivers
> from generic syscon to Exynos-specific API?

I think certainly for the various exynos phy (usb, ufs, pcie, mipi)
this change is required. I can do some more checking to see what other
drivers are twiddling PMU bits downstream.

> What if one driver is some
> shared IP, like DWC USB3 controller?
>
> I already commented on Google hwrng driver:

I think you mean syscon-poweroff  but I get your point. The
syscon-reboot / poweroff / reboot-mode drivers are examples of drivers
where we may wish to use them, but today we can't as they are using
syscon_regmap_lookup_by_phandle() API.

> I prefer to keep the syscon
> API and change the syscon driver to expose proper regmap. IOW, use
> generic API syscon_regmap_lookup_by_phandle() and the type of regmap
> returned is defined by the provider (so node pointed by phandle).
>

@Arnd - any more thoughts on Krzysztof idea above ^^

@Krzysztof - I did speak to Arnd about the idea you proposed (or my
understanding of it at least), which was external drivers like
exynos-pmu or altera-sysmgr.c could create the regmap and register it
with syscon so it can be returned by
syscon_regmap_lookup_by_phandle(). Arnd's initial feedback was he
would prefer to keep the complexity out of syscon, and have the client
driver support multiple backends (so syscon-reboot for example would
support using either syscon_regmap_lookup_by_phandle() or
exynos_get_pmu_regmap_by_phandle() to obtain it's regmap). There were
also some concerns about syscon having to probe very early for some
platforms.

Thanks,

Peter.