From: p.zabel@pengutronix.de (Philipp Zabel)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 3/3] reset: Add support for shared reset controls
Date: Thu, 04 Feb 2016 17:55:22 +0100 [thread overview]
Message-ID: <1454604922.3356.80.camel@pengutronix.de> (raw)
In-Reply-To: <56ADCFEF.3040707@redhat.com>
Hi Hans,
Am Sonntag, den 31.01.2016, 10:12 +0100 schrieb Hans de Goede:
> Hi,
>
> On 01/30/2016 12:38 PM, Philipp Zabel wrote:
> > Hi Hans,
> >
> > On Wed, Jan 27, 2016 at 07:15:16PM +0100, Hans de Goede wrote:
> >> In some SoCs some hw-blocks share a reset control. Add support for this
> >> setup by adding new:
> >>
> >> reset_control_get_shared()
> >> devm_reset_control_get_shared()
> >> devm_reset_control_get_shared_by_index()
> >>
> >> methods to get a reset_control. Note that this patch omits adding of_
> >> variants, if these are needed later they can be easily added.
> >>
> >> This patch also changes the behavior of the existing exclusive
> >> reset_control_get() variants, if these are now called more then once
> >> for the same reset_control they will return -EBUSY. To catch existing
> >> drivers triggering this error (there should not be any) a WARN_ON(1)
> >> is added in this path.
> >
> > Which is a good thing.
> >
> >> When a reset_control is shared, the behavior of reset_control_assert /
> >> deassert is changed, for shared reset_controls these will work like the
> >> clock-enable/disable and regulator-on/off functions. They will keep a
> >> deassert_count, and only (re-)assert the reset after reset_control_assert
> >> has been called as many times as reset_control_deassert was called.
> >>
> >> Calling reset_control_assert without first calling reset_control_deassert
> >> is not allowed on a shared reset control. Calling reset_control_reset is
> >> also not allowed on a shared reset control.
> >>
> >> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> >
> > All three patches look very nice. I'll give them a test-drive next week.
> > So far I have one small issue, and I like Stephens suggestion of
> > elaborating on how shared resets are to be used a bit more.
>
> I can do that, where would you like me to put this, a doxygen style comment
> in include/linux/reset.h ?
Sorry for the delay. I had just thought of extending the
reset_control_get_shared comment below, but an overview comment in
reset.h would be fine, too.
[...]
> >> /**
> >> - * of_reset_control_get - Lookup and obtain a reference to a reset controller.
> >> + * reset_control_get_shared - Lookup and obtain a shared reference to a
> >> + * reset controller.
> >> + * @dev: device to be reset by the controller
> >> + * @id: reset line name
> >> + *
> >> + * Returns a struct reset_control or IS_ERR() condition containing errno.
> >
> > How about addressing Stephen's suggestion by extending this kerneldoc comment a
> > bit?
^^^ this.
Now that I think of it, the reset_control_assert function comment should
explicitly state that for shared resets the drivers can't expect their
registers and internal state to be reset, but must be prepared for this
to happen.
best regards
Philipp
next prev parent reply other threads:[~2016-02-04 16:55 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-27 18:15 [PATCH v3 0/3] reset: Add support for shared reset controls Hans de Goede
2016-01-27 18:15 ` [PATCH v3 1/3] reset: Make [of_]reset_control_get[_foo] functions wrappers Hans de Goede
2016-02-04 16:54 ` Philipp Zabel
2016-02-05 18:30 ` Hans de Goede
2016-02-08 9:58 ` Philipp Zabel
2016-01-27 18:15 ` [PATCH v3 2/3] reset: Share struct reset_control between reset_control_get calls Hans de Goede
2016-01-27 18:15 ` [PATCH v3 3/3] reset: Add support for shared reset controls Hans de Goede
2016-01-28 20:20 ` Stephen Warren
2016-01-29 6:18 ` Hans de Goede
2016-01-29 16:21 ` Stephen Warren
2016-01-30 11:38 ` Philipp Zabel
2016-01-31 9:12 ` Hans de Goede
2016-02-04 16:55 ` Philipp Zabel [this message]
2016-02-05 9:08 ` Philipp Zabel
2016-02-05 18:28 ` Hans de Goede
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=1454604922.3356.80.camel@pengutronix.de \
--to=p.zabel@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.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).