From: "Arnd Bergmann" <arnd@arndb.de>
To: "Jeremy Kerr" <jk@codeconstruct.com.au>,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
"Lee Jones" <lee@kernel.org>, "Rob Herring" <robh+dt@kernel.org>,
"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
"Philipp Zabel" <p.zabel@pengutronix.de>
Subject: Re: [RFC PATCH 2/2] mfd: syscon: allow reset control for syscon devices
Date: Tue, 06 Dec 2022 09:41:10 +0100 [thread overview]
Message-ID: <e46a680f-e891-489c-9747-98ae3df42ade@app.fastmail.com> (raw)
In-Reply-To: <20221206073916.1606125-3-jk@codeconstruct.com.au>
On Tue, Dec 6, 2022, at 08:39, Jeremy Kerr wrote:
> Simple syscon devices may require deassertion of a reset signal in order
> to access their register set. Rather than requiring a custom driver to
> implement this, we can use the generic "resets" specifiers to link a
> reset line to the syscon.
>
> This change adds an optional reset line to the syscon device
> description, and code to perform the deassertion/assertion on
> probe/remove.
>
> Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au>
I see that this will only work after the device has been registered,
but not for early users of the syscon framework that bypass the
device logic and just call device_node_to_regmap() or
syscon_regmap_lookup*() during early boot.
It should be possible to solve this by adding the reset logic
into the of_syscon_register() function and using the
of_reset_control_get*() helpers instead of the devm_* ones,
but I'm not sure if that causes other problems with probe
order, or if that helps at all, if reset drivers already
require the device subsystem to be running.
Philipp, what is the earliest point at which
reset_controller_register() can be called? Is that
possible before postcore_initcall() or driver_register()?
Arnd
next prev parent reply other threads:[~2022-12-06 8:41 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-06 7:39 [RFC PATCH 0/2] Add reset control for mfd syscon devices Jeremy Kerr
2022-12-06 7:39 ` [RFC PATCH 1/2] dt-bindings: mfd/syscon: Add resets property Jeremy Kerr
2022-12-06 13:09 ` Rob Herring
2022-12-06 7:39 ` [RFC PATCH 2/2] mfd: syscon: allow reset control for syscon devices Jeremy Kerr
2022-12-06 8:41 ` Arnd Bergmann [this message]
2022-12-06 9:25 ` Philipp Zabel
2022-12-06 14:18 ` Arnd Bergmann
2022-12-07 7:56 ` Jeremy Kerr
2022-12-07 8:59 ` Arnd Bergmann
2022-12-07 9:28 ` Jeremy Kerr
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=e46a680f-e891-489c-9747-98ae3df42ade@app.fastmail.com \
--to=arnd@arndb.de \
--cc=devicetree@vger.kernel.org \
--cc=jk@codeconstruct.com.au \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=lee@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=p.zabel@pengutronix.de \
--cc=robh+dt@kernel.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).