From: Stephen Warren <swarren@wwwdotorg.org>
To: Olof Johansson <olof@lixom.net>
Cc: Philipp Zabel <p.zabel@pengutronix.de>,
linux-arm-kernel@lists.infradead.org,
Arnd Bergmann <arnd@arndb.de>, Marek Vasut <marex@denx.de>,
Fabio Estevam <fabio.estevam@freescale.com>,
Mike Turquette <mturquette@linaro.org>,
Pavel Machek <pavel@ucw.cz>, Len Brown <len.brown@intel.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Sascha Hauer <s.hauer@pengutronix.de>,
linux-pm@vger.kernel.org, "Rafael J. Wysocki" <rjw@sisk.pl>,
kernel@pengutronix.de, Shawn Guo <shawn.guo@linaro.org>,
devicetree-discuss@lists.ozlabs.org,
Rob Herring <rob.herring@calxeda.com>,
Grant Likely <grant.likely@secretlab.ca>
Subject: Re: [PATCH v6 3/8] reset: Add driver for gpio-controlled reset pins
Date: Thu, 11 Apr 2013 09:54:44 -0600 [thread overview]
Message-ID: <5166DCC4.6050206@wwwdotorg.org> (raw)
In-Reply-To: <CAOesGMgo61M=oxG6_6EEGu7kL3Wa+HsdEomCxUnvj-Rbdhujgg@mail.gmail.com>
On 04/11/2013 04:35 AM, Olof Johansson wrote:
> On Thu, Mar 28, 2013 at 9:35 AM, Philipp Zabel <p.zabel@pengutronix.de> wrote:
>> This driver implements a reset controller device that toggles gpios
>> connected to reset pins of peripheral ICs. The delay between assertion
>> and de-assertion of the reset signal can be configured.
...
> Since this is a platform driver and not just an OF driver, shouldn't
> you provide a way to specify the same configuration data through a
> platform_data structure as well?
I believe the only practical use-cases for this driver are /currently/
for device-tree platforms. Shouldn't we add the platform_data support
only when some platform actively uses it?
In the past when reviewing new drivers, I pushed for platform drivers to
always implement the platform_data structure up-front, and support using
that if present rather than "falling back" to DT. However, Grant then
shot that down saying that there was no point adding dead code...
(this will also feed into the discussion about simple-framebuffer, which
also only needs DT support right now, but could in theory be extended to
support platform_data in the future if somebody wants).
next prev parent reply other threads:[~2013-04-11 15:54 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-28 16:35 [PATCH v6 0/8] Reset controller API to reset IP modules on i.MX5 and i.MX6 Philipp Zabel
2013-03-28 16:35 ` [PATCH v6 1/8] dt: describe base reset signal binding Philipp Zabel
2013-04-04 13:49 ` Rob Herring
2013-04-09 8:16 ` Philipp Zabel
2013-03-28 16:35 ` [PATCH v6 2/8] reset: Add reset controller API Philipp Zabel
2013-03-28 16:35 ` [PATCH v6 3/8] reset: Add driver for gpio-controlled reset pins Philipp Zabel
2013-04-11 10:35 ` Olof Johansson
2013-04-11 12:37 ` Philipp Zabel
2013-04-11 15:54 ` Stephen Warren [this message]
2013-04-11 16:45 ` Olof Johansson
2013-03-28 16:35 ` [PATCH v6 4/8] ARM i.MX6q: Add GPU, VPU, IPU, and OpenVG resets to System Reset Controller (SRC) Philipp Zabel
2013-03-28 16:35 ` [PATCH v6 5/8] ARM i.MX6q: Link system reset controller (SRC) to IPU in DT Philipp Zabel
2013-03-28 16:35 ` [PATCH v6 6/8] staging: drm/imx: Use SRC to reset IPU Philipp Zabel
2013-03-29 15:12 ` Greg Kroah-Hartman
2013-03-28 16:35 ` [PATCH v6 7/8] ARM i.MX5: Add System Reset Controller (SRC) support for i.MX51 and i.MX53 Philipp Zabel
2013-03-28 16:35 ` [PATCH v6 8/8] ARM i.MX5: Add system reset controller (SRC) to i.MX51 and i.MX53 device tree Philipp Zabel
[not found] ` <1364488523-20310-1-git-send-email-p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2013-03-28 22:07 ` [PATCH v6 0/8] Reset controller API to reset IP modules on i.MX5 and i.MX6 Arnd Bergmann
2013-03-31 14:23 ` Shawn Guo
2013-03-29 10:16 ` Pavel Machek
2013-04-01 6:23 ` Shawn Guo
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=5166DCC4.6050206@wwwdotorg.org \
--to=swarren@wwwdotorg.org \
--cc=arnd@arndb.de \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=fabio.estevam@freescale.com \
--cc=grant.likely@secretlab.ca \
--cc=gregkh@linuxfoundation.org \
--cc=kernel@pengutronix.de \
--cc=len.brown@intel.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-pm@vger.kernel.org \
--cc=marex@denx.de \
--cc=mturquette@linaro.org \
--cc=olof@lixom.net \
--cc=p.zabel@pengutronix.de \
--cc=pavel@ucw.cz \
--cc=rjw@sisk.pl \
--cc=rob.herring@calxeda.com \
--cc=s.hauer@pengutronix.de \
--cc=shawn.guo@linaro.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).