All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lee Jones <lee@kernel.org>
To: Peter Griffin <peter.griffin@linaro.org>
Cc: arnd@arndb.de, krzk@kernel.org, alim.akhtar@samsung.com,
	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 v3 0/2] Add syscon of_syscon_register_regmap api
Date: Wed, 26 Jun 2024 16:48:21 +0100	[thread overview]
Message-ID: <20240626154821.GE2504017@google.com> (raw)
In-Reply-To: <20240621115544.1655458-1-peter.griffin@linaro.org>

On Fri, 21 Jun 2024, Peter Griffin wrote:

> Hi Lee, Arnd, Krzysztof, all,
> 
> This series adds support to syscon driver for a new of_syscon_register_regmap()
> api.
> 
> Platforms such as gs101 require a special regmap to access PMU registers, which
> in the existing upstream client drivers are accessed via syscon regmap. This
> issue was partly solved in [1] whereby a custom regmap is created in exynos-pmu
> and a new API exynos_get_pmu_regmap_by_phandle() created.
> 
> One issue with the approach in [1] is that it required client drivers to be
> updated from syscon_regmap_lookup_by_phandle() to
> exynos_get_pmu_regmap_by_phandle() when obtaining the regmap.
> 
> Whilst updating to exynos_get_pmu_regmap_by_phandle() was OK for exynos
> specific drivers, it meant other drivers like syscon-reboot and syscon-poweroff
> which span multiple SoC architectures could not be easily re-used.
> 
> In previous review feedback for USB phy and gs101 poweroff driver Krzysztof
> requested [2] that we take a more generic approach that other SoCs can also
> leverage.
> 
> The new of_syscon_register_regmap() api overcomes this limitation by allowing
> a SoC driver like exynos-pmu to register it's SoC specific regmap with the
> syscon driver. This keeps the SoC complexity out of syscon driver, and allows
> client drivers to continue using syscon_regmap_lookup_by_phandle() as before.
> The solution allows more code re-use and can be used by other SoC archs.
> 
> Notes on probe ordering
> 
> exynos-pmu runs at postcore_initcall, so all but one of the client drivers
> (ufs phy, usb phy, watchdog) run after the regmap is created and registered.
> 
> The one exception to this is pinctrl-samsung driver which is also
> postcore_initcall level. The exynos_get_pmu_regmap() and
> exynos_get_pmu_regmap_by_phandle() have been temporarily left to support
> -EPROBE_DEFER for pinctrl-samsung driver.
> 
> The longer term plan to solve that probe ordering issue is to enable
> fw_devlink for syscon dt properties so they are correctly listed as
> suppliers in /sys/class/devlink. I tested a PoC patch (see below) for
> fw_devlink and that seemed to work fine. Once fw_devlink supports syscon I
> believe exynos_get_pmu_regmap_by_phandle() api could be removed. The main issue
> currently with fw_devlink syscon support is the wide diversity of dt property
> naming currently in use. That was discussed previously here [3]
> 
> 1248a1256,1257
> > DEFINE_SUFFIX_PROP(syscon_phandle, "syscon-phandle", NULL)
> > DEFINE_SUFFIX_PROP(pmu_syscon, "pmu-syscon", NULL)
> 1358a1368,1369
> >     { .parse_prop = parse_syscon_phandle, },
> >     { .parse_prop = parse_pmu_syscon, },
> 
> 
> Note one previous concern from Saravana about syscon potentially probing
> before exynos-pmu driver and it relying on drivers/Makefile ordering. I tested
> this and even if mfd is listed before soc in drivers/Makefile exynos-pmu
> always probes first due to syscon driver not setting a .of_match_table entry.
> 
> Once the syscon and exynos-pmu patchs are queued I will send patches for
> watchdog and ufs phy drivers to switch back to syscon_regmap_lookup_by_phandle()
> 
> Many thanks,
> 
> Peter.
> 
> [1] https://lore.kernel.org/linux-arm-kernel/20240219204238.356942-1-peter.griffin@linaro.org/T/
> [2] https://lore.kernel.org/lkml/06383015-51b2-4f4c-9fd8-e4f7ce12f44e@kernel.org/
> [3] https://lore.kernel.org/all/CAGETcx-CCpaV7R0O0HpDpoX6KxQBuJiMmKdWA8nDE-5Qj2Sa7g@mail.gmail.com/
> 
> Changes since v2:
>  - Move allocation outside spinlock area (Arnd)
> Link to v2:
>  - https://lore.kernel.org/linux-arm-kernel/20240620112446.1286223-1-peter.griffin@linaro.org/
> 
> Changes since v1:
>  - Collect by tags
>  - Keep syscon lock held for check and adding entry (Krzysztof)
>  - pass pmu_np not np to syscon_node_to_regmap() (William)
> 
> Link to v1:
>  - https://lore.kernel.org/linux-arm-kernel/20240614140421.3172674-1-peter.griffin@linaro.org/
> 
> Peter Griffin (2):
>   mfd: syscon: add of_syscon_register_regmap() API
>   soc: samsung: exynos-pmu: update to use of_syscon_register_regmap()
> 
>  drivers/mfd/syscon.c             | 48 ++++++++++++++++++++++++++++++++
>  drivers/soc/samsung/exynos-pmu.c | 38 ++++++++++---------------
>  include/linux/mfd/syscon.h       |  8 ++++++
>  3 files changed, 70 insertions(+), 24 deletions(-)

Applied and submitted for build testing.

If all is good, I'll send out a PR for the other maintainer(s).

Note to self: ib-mfd-soc-samsung-6.11

-- 
Lee Jones [李琼斯]

  parent reply	other threads:[~2024-06-26 15:48 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-21 11:55 [PATCH v3 0/2] Add syscon of_syscon_register_regmap api Peter Griffin
2024-06-21 11:55 ` [PATCH v3 1/2] mfd: syscon: add of_syscon_register_regmap() API Peter Griffin
2024-06-21 23:56   ` William McVicker
2024-06-24  5:57   ` Krzysztof Kozlowski
2024-06-21 11:55 ` [PATCH v3 2/2] soc: samsung: exynos-pmu: update to use of_syscon_register_regmap() Peter Griffin
2024-06-21 23:57   ` William McVicker
2024-06-24  5:58   ` Krzysztof Kozlowski
2024-06-21 14:54 ` [PATCH v3 0/2] Add syscon of_syscon_register_regmap api Arnd Bergmann
2024-06-26 15:48 ` Lee Jones [this message]
2024-06-28 14:26 ` [GIT PULL] Immutable branch between MFD and SoC Samsung due for the v6.11 merge window Lee Jones

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=20240626154821.GE2504017@google.com \
    --to=lee@kernel.org \
    --cc=alim.akhtar@samsung.com \
    --cc=andre.draszik@linaro.org \
    --cc=arnd@arndb.de \
    --cc=kernel-team@android.com \
    --cc=krzk@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 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.