mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Arnd Bergmann" <arnd@arndb.de>
To: "Jeremy Kerr" <jk@codeconstruct.com.au>,
	"Philipp Zabel" <p.zabel@pengutronix.de>,
	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: Wed, 07 Dec 2022 09:59:32 +0100	[thread overview]
Message-ID: <5a57e163-c705-4308-93ac-11e0cea2804b@app.fastmail.com> (raw)
In-Reply-To: <ff70222596646757cbd6e2f24aadf3247183061d.camel@codeconstruct.com.au>

On Wed, Dec 7, 2022, at 08:56, Jeremy Kerr wrote:
> Hi Arnd,
>
> Thanks for taking a look a this. Just a question about the early
> approach; I'm not too familiar with the internals of the syscon/regmap
> infrastructure:
>
>> > 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.
>
> OK, sounds good - I'll add a direct of_reset_control_get_<variant>() in
> the early of_syscon_register path, which should work in a similar way to
> the clocks properties.
>
> However: this may conflict with the later platform_device syscon; if the
> late syscon tries to of_reset_control_get_exclusive() the same reset
> controller (because it's the same syscon node), that will (of course)
> fail.
>
> Hence a question about the syscon infrastructure: how are the late- and
> early- syscon registrations supposed to interact? Should I allow for
> there to be two syscons registered (one through of_syscon_register(),
> the other through the platform device probe), or do we expect that to
> never happen?
>
> In case of the former, I can just grab a shared handle to the reset
> controller instead, but I want to make sure that's the correct thing to do.

Hmm, it's clearly not doing what I was remembering it to do ;-)

Before 2014 commit bdb0066df96e ("mfd: syscon: Decouple syscon interface
from platform devices"), it was supposed to be the same regmap in
both cases, with the linked list being maintained to ensure we
never get more than one instance for device_node.

After this commit, I see that the platform_driver no longer matches
syscon nodes from devicetree, but only those nodes that have
platform_device.dev.name="syscon" and are created from board
files. The only user of manually created syscon devices at the
time was mach-clps711x, but that has been converted to DT
a long time ago, so I don't even see anything using the
platform_device at all.

This would in turn indicate that we can completely remove the
platform_driver code, but I don't see how your RFC patch then
had any effect because it wouldn't actually perform the
reset for any devices in mainline kernels.

    Arnd

  reply	other threads:[~2022-12-07  9:00 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 " 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
2022-12-07  7:56         ` Jeremy Kerr
2022-12-07  8:59           ` Arnd Bergmann [this message]
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=5a57e163-c705-4308-93ac-11e0cea2804b@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

all inboxes | Powered by JetHome®