Hi Krzysztof, + Arnd & Lee (syscon maintainers) On Thu, 25 Apr 2024 at 08:47, Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx> 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@xxxxxxxxxx> > > --- > > 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.
