| Message ID | 1387575669-21253-2-git-send-email-maxime.ripard@free-electrons.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Maxime, Philipp, On Fri, 20 Dec 2013 22:41:07 +0100, Maxime Ripard wrote: > In some cases, you might need to deassert from reset an hardware block that > doesn't associated to a struct device (CPUs, timers, etc.). > > Add a small helper to retrieve the reset controller from the device tree > without the need to pass a struct device. > > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> > --- > drivers/reset/core.c | 39 ++++++++++++++++++++++++++++++--------- > include/linux/reset.h | 4 ++++ > 2 files changed, 34 insertions(+), 9 deletions(-) I'd like to add that I have the exact same need as Maxime. Maxime needs of_reset_control_get() for timers, and in my case, I need it for CPUs, since I associated a reset controller to CPU nodes in my DT. Funnily, even though Maxime and I work like 3 meters away from each other, both of us came up independently with almost exactly the same implementation to solve the exact same problem, without talking to each other about this need. It's only yesterday that we discovered we've had to solve the same problem. So, definitely looking forward to seeing the feedback about this. Thanks! Thomas
Am Samstag, den 21.12.2013, 09:42 +0100 schrieb Thomas Petazzoni: > Maxime, Philipp, > > On Fri, 20 Dec 2013 22:41:07 +0100, Maxime Ripard wrote: > > In some cases, you might need to deassert from reset an hardware block that > > doesn't associated to a struct device (CPUs, timers, etc.). > > > > Add a small helper to retrieve the reset controller from the device tree > > without the need to pass a struct device. > > > > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> > > --- > > drivers/reset/core.c | 39 ++++++++++++++++++++++++++++++--------- > > include/linux/reset.h | 4 ++++ > > 2 files changed, 34 insertions(+), 9 deletions(-) > > I'd like to add that I have the exact same need as Maxime. Maxime needs > of_reset_control_get() for timers, and in my case, I need it for CPUs, > since I associated a reset controller to CPU nodes in my DT. > > Funnily, even though Maxime and I work like 3 meters away from each > other, both of us came up independently with almost exactly the same > implementation to solve the exact same problem, without talking to each > other about this need. It's only yesterday that we discovered we've had > to solve the same problem. > > So, definitely looking forward to seeing the feedback about this. > > Thanks! This looks like a useful addition. I'll reorder the GPIO reset patch for this. regards Philipp
Hi Philipp, On Mon, Jan 06, 2014 at 06:42:51PM +0100, Philipp Zabel wrote: > Am Samstag, den 21.12.2013, 09:42 +0100 schrieb Thomas Petazzoni: > > Maxime, Philipp, > > > > On Fri, 20 Dec 2013 22:41:07 +0100, Maxime Ripard wrote: > > > In some cases, you might need to deassert from reset an hardware block that > > > doesn't associated to a struct device (CPUs, timers, etc.). > > > > > > Add a small helper to retrieve the reset controller from the device tree > > > without the need to pass a struct device. > > > > > > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> > > > --- > > > drivers/reset/core.c | 39 ++++++++++++++++++++++++++++++--------- > > > include/linux/reset.h | 4 ++++ > > > 2 files changed, 34 insertions(+), 9 deletions(-) > > > > I'd like to add that I have the exact same need as Maxime. Maxime needs > > of_reset_control_get() for timers, and in my case, I need it for CPUs, > > since I associated a reset controller to CPU nodes in my DT. > > > > Funnily, even though Maxime and I work like 3 meters away from each > > other, both of us came up independently with almost exactly the same > > implementation to solve the exact same problem, without talking to each > > other about this need. It's only yesterday that we discovered we've had > > to solve the same problem. > > > > So, definitely looking forward to seeing the feedback about this. > > > > Thanks! > > This looks like a useful addition. I'll reorder the GPIO reset patch for > this. How do you want to get this merged? You'll probably want to take this patch, and patches 2/3 and 3/3 depend on some patches merged by Daniel Lezcano (that I forgot to CC on this, I'll resend). Maybe the best way would be simply to merge this one for 3.14 through your branch, and merge the two other patches in 3.15. Maxime
Am Mittwoch, den 08.01.2014, 11:38 +0100 schrieb Maxime Ripard: > Hi Philipp, > > On Mon, Jan 06, 2014 at 06:42:51PM +0100, Philipp Zabel wrote: > > Am Samstag, den 21.12.2013, 09:42 +0100 schrieb Thomas Petazzoni: > > > Maxime, Philipp, > > > > > > On Fri, 20 Dec 2013 22:41:07 +0100, Maxime Ripard wrote: > > > > In some cases, you might need to deassert from reset an hardware block that > > > > doesn't associated to a struct device (CPUs, timers, etc.). > > > > > > > > Add a small helper to retrieve the reset controller from the device tree > > > > without the need to pass a struct device. > > > > > > > > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> > > > > --- > > > > drivers/reset/core.c | 39 ++++++++++++++++++++++++++++++--------- > > > > include/linux/reset.h | 4 ++++ > > > > 2 files changed, 34 insertions(+), 9 deletions(-) > > > > > > I'd like to add that I have the exact same need as Maxime. Maxime needs > > > of_reset_control_get() for timers, and in my case, I need it for CPUs, > > > since I associated a reset controller to CPU nodes in my DT. > > > > > > Funnily, even though Maxime and I work like 3 meters away from each > > > other, both of us came up independently with almost exactly the same > > > implementation to solve the exact same problem, without talking to each > > > other about this need. It's only yesterday that we discovered we've had > > > to solve the same problem. > > > > > > So, definitely looking forward to seeing the feedback about this. > > > > > > Thanks! > > > > This looks like a useful addition. I'll reorder the GPIO reset patch for > > this. > > How do you want to get this merged? You'll probably want to take this > patch, and patches 2/3 and 3/3 depend on some patches merged by Daniel > Lezcano (that I forgot to CC on this, I'll resend). > > Maybe the best way would be simply to merge this one for 3.14 through > your branch, and merge the two other patches in 3.15. Alright, this is applied to my branch. I'll wait a bit for feedback on the GPIO reset patches and then send a pull request. regards Philipp
On Wed, Jan 08, 2014 at 12:11:34PM +0100, Philipp Zabel wrote: > Am Mittwoch, den 08.01.2014, 11:38 +0100 schrieb Maxime Ripard: > > On Mon, Jan 06, 2014 at 06:42:51PM +0100, Philipp Zabel wrote: > > > Am Samstag, den 21.12.2013, 09:42 +0100 schrieb Thomas Petazzoni: > > > > Maxime, Philipp, > > > > > > > > On Fri, 20 Dec 2013 22:41:07 +0100, Maxime Ripard wrote: > > > > > In some cases, you might need to deassert from reset an hardware block that > > > > > doesn't associated to a struct device (CPUs, timers, etc.). > > > > > > > > > > Add a small helper to retrieve the reset controller from the device tree > > > > > without the need to pass a struct device. > > > > > > > > > > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> > > > > > --- > > > > > drivers/reset/core.c | 39 ++++++++++++++++++++++++++++++--------- > > > > > include/linux/reset.h | 4 ++++ > > > > > 2 files changed, 34 insertions(+), 9 deletions(-) > > > > > > > > I'd like to add that I have the exact same need as Maxime. Maxime needs > > > > of_reset_control_get() for timers, and in my case, I need it for CPUs, > > > > since I associated a reset controller to CPU nodes in my DT. > > > > > > > > Funnily, even though Maxime and I work like 3 meters away from each > > > > other, both of us came up independently with almost exactly the same > > > > implementation to solve the exact same problem, without talking to each > > > > other about this need. It's only yesterday that we discovered we've had > > > > to solve the same problem. > > > > > > > > So, definitely looking forward to seeing the feedback about this. > > > > > > > > Thanks! > > > > > > This looks like a useful addition. I'll reorder the GPIO reset patch for > > > this. > > > > How do you want to get this merged? You'll probably want to take this > > patch, and patches 2/3 and 3/3 depend on some patches merged by Daniel > > Lezcano (that I forgot to CC on this, I'll resend). > > > > Maybe the best way would be simply to merge this one for 3.14 through > > your branch, and merge the two other patches in 3.15. > > Alright, this is applied to my branch. I'll wait a bit for feedback on > the GPIO reset patches and then send a pull request. Great then, thanks! Maxime
Hi Philipp, On Wed, Jan 08, 2014 at 12:11:34PM +0100, Philipp Zabel wrote: > > How do you want to get this merged? You'll probably want to take this > > patch, and patches 2/3 and 3/3 depend on some patches merged by Daniel > > Lezcano (that I forgot to CC on this, I'll resend). > > > > Maybe the best way would be simply to merge this one for 3.14 through > > your branch, and merge the two other patches in 3.15. > > Alright, this is applied to my branch. I'll wait a bit for feedback on > the GPIO reset patches and then send a pull request. It doesn't seem to be in 3.14. Did I miss something? Thanks, Maxime
diff --git a/drivers/reset/core.c b/drivers/reset/core.c index d1b6089..4f3dda7 100644 --- a/drivers/reset/core.c +++ b/drivers/reset/core.c @@ -127,15 +127,16 @@ int reset_control_deassert(struct reset_control *rstc) EXPORT_SYMBOL_GPL(reset_control_deassert); /** - * reset_control_get - Lookup and obtain a reference to a reset controller. - * @dev: device to be reset by the controller + * of_reset_control_get - Lookup and obtain a reference to a reset controller. + * @node: device to be reset by the controller * @id: reset line name * * Returns a struct reset_control or IS_ERR() condition containing errno. * * Use of id names is optional. */ -struct reset_control *reset_control_get(struct device *dev, const char *id) +struct reset_control *of_reset_control_get(struct device_node *node, + const char *id) { struct reset_control *rstc = ERR_PTR(-EPROBE_DEFER); struct reset_controller_dev *r, *rcdev; @@ -144,13 +145,10 @@ struct reset_control *reset_control_get(struct device *dev, const char *id) int rstc_id; int ret; - if (!dev) - return ERR_PTR(-EINVAL); - if (id) - index = of_property_match_string(dev->of_node, + index = of_property_match_string(node, "reset-names", id); - ret = of_parse_phandle_with_args(dev->of_node, "resets", "#reset-cells", + ret = of_parse_phandle_with_args(node, "resets", "#reset-cells", index, &args); if (ret) return ERR_PTR(ret); @@ -185,12 +183,35 @@ struct reset_control *reset_control_get(struct device *dev, const char *id) return ERR_PTR(-ENOMEM); } - rstc->dev = dev; rstc->rcdev = rcdev; rstc->id = rstc_id; return rstc; } +EXPORT_SYMBOL_GPL(of_reset_control_get); + +/** + * reset_control_get - Lookup and obtain a 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. + * + * Use of id names is optional. + */ +struct reset_control *reset_control_get(struct device *dev, const char *id) +{ + struct reset_control *rstc; + + if (!dev) + return ERR_PTR(-EINVAL); + + rstc = of_reset_control_get(dev->of_node, id); + if (!IS_ERR(rstc)) + rstc->dev = dev; + + return rstc; +} EXPORT_SYMBOL_GPL(reset_control_get); /** diff --git a/include/linux/reset.h b/include/linux/reset.h index 6082247..a398025 100644 --- a/include/linux/reset.h +++ b/include/linux/reset.h @@ -1,6 +1,8 @@ #ifndef _LINUX_RESET_H_ #define _LINUX_RESET_H_ +#include <linux/of.h> + struct device; struct reset_control; @@ -8,6 +10,8 @@ int reset_control_reset(struct reset_control *rstc); int reset_control_assert(struct reset_control *rstc); int reset_control_deassert(struct reset_control *rstc); +struct reset_control *of_reset_control_get(struct device_node *node, + const char *id); struct reset_control *reset_control_get(struct device *dev, const char *id); void reset_control_put(struct reset_control *rstc); struct reset_control *devm_reset_control_get(struct device *dev, const char *id);
In some cases, you might need to deassert from reset an hardware block that doesn't associated to a struct device (CPUs, timers, etc.). Add a small helper to retrieve the reset controller from the device tree without the need to pass a struct device. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> --- drivers/reset/core.c | 39 ++++++++++++++++++++++++++++++--------- include/linux/reset.h | 4 ++++ 2 files changed, 34 insertions(+), 9 deletions(-)