From: "Arnd Bergmann" <arnd@arndb.de>
To: "Philipp Zabel" <p.zabel@pengutronix.de>,
"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>
Subject: Re: [RFC PATCH 2/2] mfd: syscon: allow reset control for syscon devices
Date: Tue, 06 Dec 2022 15:18:23 +0100 [thread overview]
Message-ID: <b29dceb0-a07f-4e12-9e7b-6fead4db826d@app.fastmail.com> (raw)
In-Reply-To: <a83f62d604e70a8e58309dc7a5e2e3515227e1c4.camel@pengutronix.de>
On Tue, Dec 6, 2022, at 10:25, Philipp Zabel wrote:
> On Di, 2022-12-06 at 09:41 +0100, Arnd Bergmann wrote:
>> Philipp, what is the earliest point at which
>> reset_controller_register() can be called? Is that
>> possible before postcore_initcall() or driver_register()?
>
> reset_controller_register() only initializes a few fields in the passed
> rcdev structure and adds it to a static list under a static mutex, so
> there's not much of a limit.
Ok, in that case I think we should at least leave the option of
doing the reset from an early syscon as well.
> However, reset controllers that choose to register early without
> creating a platform device may run into issues with devlink inhibiting
> reset consumers' probe [1].
Right. I think the is generally a problem of "early" code, so
device drivers should avoid doing this if at all possible, but at
the same time it makes sense for infrastructure to tolerate drivers
doing it.
Arnd
next prev parent reply other threads:[~2022-12-06 14:18 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
2022-12-06 9:25 ` Philipp Zabel
2022-12-06 14:18 ` Arnd Bergmann [this message]
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=b29dceb0-a07f-4e12-9e7b-6fead4db826d@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).