* [GIT PULL, RESEND] Reset controller fixes and updates
@ 2014-03-19 9:00 Philipp Zabel
2014-03-27 0:34 ` Arnd Bergmann
0 siblings, 1 reply; 4+ messages in thread
From: Philipp Zabel @ 2014-03-19 9:00 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd, Olof,
The following changes since commit 38dbfb59d1175ef458d006556061adeaa8751b72:
Linus 3.14-rc1 (2014-02-02 16:42:13 -0800)
are available in the git repository at:
git://git.pengutronix.de/git/pza/linux.git reset/for_v3.15
for you to fetch changes up to b424080a9e086e683ad5fdc624a7cf3c024e0c0f:
reset: Add optional resets and stubs (2014-03-09 19:53:45 +0100)
regards
Philipp
----------------------------------------------------------------
Maxime Ripard (1):
reset: Add of_reset_control_get
Philipp Zabel (2):
reset: allow drivers to request probe deferral
reset: Add optional resets and stubs
Rashika Kheria (1):
reset: Mark function as static and remove unused function in core.c
drivers/reset/core.c | 71 +++++++++++++++++++++++----------------------------
include/linux/reset.h | 65 +++++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 96 insertions(+), 40 deletions(-)
^ permalink raw reply [flat|nested] 4+ messages in thread* [GIT PULL, RESEND] Reset controller fixes and updates 2014-03-19 9:00 [GIT PULL, RESEND] Reset controller fixes and updates Philipp Zabel @ 2014-03-27 0:34 ` Arnd Bergmann 2014-03-27 9:55 ` Philipp Zabel 0 siblings, 1 reply; 4+ messages in thread From: Arnd Bergmann @ 2014-03-27 0:34 UTC (permalink / raw) To: linux-arm-kernel On Wednesday 19 March 2014, Philipp Zabel wrote: > The following changes since commit 38dbfb59d1175ef458d006556061adeaa8751b72: > > Linus 3.14-rc1 (2014-02-02 16:42:13 -0800) > > are available in the git repository at: > > git://git.pengutronix.de/git/pza/linux.git reset/for_v3.15 > > for you to fetch changes up to b424080a9e086e683ad5fdc624a7cf3c024e0c0f: > > reset: Add optional resets and stubs (2014-03-09 19:53:45 +0100) > I've merged them into next/drivers now, sorry for the delay. Just one question that came in another thread, about the interface when the reset controllers are disabled: You return ERR_PTR(-ENOSYS) from reset_control_get_optional() here, and WARN_ON() any functions called later. Are you sure this is the best interface? We have other subsystems that just return a NULL pointer in this case so it doesn't trigger IS_ERR(), and then you can pass the NULL pointer into the other functions without causing an error message. Arnd ^ permalink raw reply [flat|nested] 4+ messages in thread
* [GIT PULL, RESEND] Reset controller fixes and updates 2014-03-27 0:34 ` Arnd Bergmann @ 2014-03-27 9:55 ` Philipp Zabel 2014-03-27 11:19 ` Arnd Bergmann 0 siblings, 1 reply; 4+ messages in thread From: Philipp Zabel @ 2014-03-27 9:55 UTC (permalink / raw) To: linux-arm-kernel Am Donnerstag, den 27.03.2014, 01:34 +0100 schrieb Arnd Bergmann: > On Wednesday 19 March 2014, Philipp Zabel wrote: > > The following changes since commit 38dbfb59d1175ef458d006556061adeaa8751b72: > > > > Linus 3.14-rc1 (2014-02-02 16:42:13 -0800) > > > > are available in the git repository at: > > > > git://git.pengutronix.de/git/pza/linux.git reset/for_v3.15 > > > > for you to fetch changes up to b424080a9e086e683ad5fdc624a7cf3c024e0c0f: > > > > reset: Add optional resets and stubs (2014-03-09 19:53:45 +0100) > > > > I've merged them into next/drivers now, sorry for the delay. Thanks. > Just one question that came in another thread, about the interface when > the reset controllers are disabled: You return ERR_PTR(-ENOSYS) > from reset_control_get_optional() here, and WARN_ON() any functions > called later. Are you sure this is the best interface? We have other > subsystems that just return a NULL pointer in this case so it doesn't > trigger IS_ERR(), and then you can pass the NULL pointer into the > other functions without causing an error message. If the framework is enabled, but no reset control is set in the device tree, reset_control_get_optional() returns -ENODEV. As the driver has to check for errors anyway, returning -ENOSYS instead of NULL seemed to be more explicit about what is going on. I see that the regulator framework returns NULL in the stubs, though, so for the sake of consistency, we could change reset.h to do the same: rstc = reset_control_get_optional(dev, NULL); if (PTR_ERR(rstc) == -ENODEV || PTR_ERR(rstc) == -ENOSYS) { soft_reset_instead(); rstc = NULL; } --> rstc = reset_control_get_optional(dev, NULL); if (PTR_ERR(rstc) == -ENODEV || rstc == NULL) { soft_reset_instead(); rstc = NULL; } should work well enough. regards Philipp ^ permalink raw reply [flat|nested] 4+ messages in thread
* [GIT PULL, RESEND] Reset controller fixes and updates 2014-03-27 9:55 ` Philipp Zabel @ 2014-03-27 11:19 ` Arnd Bergmann 0 siblings, 0 replies; 4+ messages in thread From: Arnd Bergmann @ 2014-03-27 11:19 UTC (permalink / raw) To: linux-arm-kernel On Thursday 27 March 2014 10:55:44 Philipp Zabel wrote: > Am Donnerstag, den 27.03.2014, 01:34 +0100 schrieb Arnd Bergmann: > > On Wednesday 19 March 2014, Philipp Zabel wrote: > > > Just one question that came in another thread, about the interface when > > the reset controllers are disabled: You return ERR_PTR(-ENOSYS) > > from reset_control_get_optional() here, and WARN_ON() any functions > > called later. Are you sure this is the best interface? We have other > > subsystems that just return a NULL pointer in this case so it doesn't > > trigger IS_ERR(), and then you can pass the NULL pointer into the > > other functions without causing an error message. > > If the framework is enabled, but no reset control is set in the device > tree, reset_control_get_optional() returns -ENODEV. As the driver has to > check for errors anyway, returning -ENOSYS instead of NULL seemed to be > more explicit about what is going on. I see that the regulator framework > returns NULL in the stubs, though, so for the sake of consistency, we > could change reset.h to do the same: > > rstc = reset_control_get_optional(dev, NULL); > if (PTR_ERR(rstc) == -ENODEV || > PTR_ERR(rstc) == -ENOSYS) { > soft_reset_instead(); > rstc = NULL; > } > --> > rstc = reset_control_get_optional(dev, NULL); > if (PTR_ERR(rstc) == -ENODEV || rstc == NULL) { > soft_reset_instead(); > rstc = NULL; > } > > should work well enough. Actually, I would argue that when you do this, the normal implementation of reset_control_get_optional() should also return NULL in case there is no reset controller. That's at least how I would read the 'optional' part of the function name. It would let the users simply do rstc = reset_control_get_optional(dev, NULL); if (IS_ERR(rstc) return PTR_ERR(rstc); /* something went wrong, e.g. -EPROBE_DEFER */ if (!rstc) soft_reset_instead(); We should under no circumstances have an interface that forces driver writers to use IS_ERR_OR_NULL(), because everybody always gets that wrong. Arnd ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2014-03-27 11:19 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-03-19 9:00 [GIT PULL, RESEND] Reset controller fixes and updates Philipp Zabel 2014-03-27 0:34 ` Arnd Bergmann 2014-03-27 9:55 ` Philipp Zabel 2014-03-27 11:19 ` Arnd Bergmann
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).