| Message ID | 1347202862-1617-1-git-send-email-lars@metafoo.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Sun, Sep 09, 2012 at 05:01:02PM +0200, Lars-Peter Clausen wrote: > The managed clk functions are currently only available when the generic clk > lookup framework is build. But the managed clk functions are merely wrappers > around clk_get and clk_put and do not depend on any specifics of the generic > lookup functions and there are still quite a few custom implementations of the > clk API. So make the managed functions available whenever the clk API is > implemented. > > The patch also removes the custom implementation of devm_clk_get for the > coldfire platform. > > Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Definitely-Acked-by: Russell King <rmk+kernel@arm.linux.org.uk> Thanks for finally cooking up a patch for this.
On Sun, Sep 09, 2012 at 05:01:02PM +0200, Lars-Peter Clausen wrote: > The managed clk functions are currently only available when the generic clk > lookup framework is build. But the managed clk functions are merely wrappers > around clk_get and clk_put and do not depend on any specifics of the generic > lookup functions and there are still quite a few custom implementations of the > clk API. So make the managed functions available whenever the clk API is > implemented. > The patch also removes the custom implementation of devm_clk_get for the > coldfire platform. I posted a patch for this (clk: Move devm_ APIs out of clkdev into HAVE_CLK) towards the end of the last release cycle and I think reposted it since and it had been sent to the patch tracker too (though I can't find any record of anything except the submission mail now). It would be *really* good to get this merged. Who's looking after clkdev these days? Mike doesn't seem to take patches as he's expecting Russell to take them which was happening for a while but I'm not sure that's the case any more, especially given Russell's followup here. Due to the patch tracker the usual things for following up on unapplied patches don't work terribly well, it's much less likely that it's just an oversight there.
On Mon, Sep 10, 2012 at 12:50:59AM +0100, Mark Brown wrote: > On Sun, Sep 09, 2012 at 05:01:02PM +0200, Lars-Peter Clausen wrote: > > > The managed clk functions are currently only available when the generic clk > > lookup framework is build. But the managed clk functions are merely wrappers > > around clk_get and clk_put and do not depend on any specifics of the generic > > lookup functions and there are still quite a few custom implementations of the > > clk API. So make the managed functions available whenever the clk API is > > implemented. > > > The patch also removes the custom implementation of devm_clk_get for the > > coldfire platform. > > I posted a patch for this (clk: Move devm_ APIs out of clkdev into > HAVE_CLK) towards the end of the last release cycle and I think reposted > it since and it had been sent to the patch tracker too (though I can't > find any record of anything except the submission mail now). It would > be *really* good to get this merged. Note that the patch system doesn't always return error messages anymore (it used to do that reliably, but as it's now a favourite target for spammers and was creating soo much backscatter, which was then filling my mailbox with bounces... that had to change.) However, it will always return a message for a patch that it adds to the database, so if you don't get that then it means something went wrong somewhere and you should check to see whether it exists in the database in case it's the emailed response which got lost. Email today still remains an unreliable transmission medium - there is no guarantee that any message sent will get to its destination, and in the same way, there is no guarantee that any acknowledgement (or NDR) will get back to the originator. > Who's looking after clkdev these days? Mike doesn't seem to take > patches as he's expecting Russell to take them which was happening for a > while but I'm not sure that's the case any more, especially given > Russell's followup here. Due to the patch tracker the usual things for > following up on unapplied patches don't work terribly well, it's much > less likely that it's just an oversight there. Well, in theory I'm the maintainer for clkdev and clk API, so I should take the patch...
On Mon, Sep 10, 2012 at 01:15:24AM +0100, Russell King - ARM Linux wrote: > On Mon, Sep 10, 2012 at 12:50:59AM +0100, Mark Brown wrote: > > I posted a patch for this (clk: Move devm_ APIs out of clkdev into > > HAVE_CLK) towards the end of the last release cycle and I think reposted > > it since and it had been sent to the patch tracker too (though I can't > > find any record of anything except the submission mail now). It would > > be *really* good to get this merged. > Note that the patch system doesn't always return error messages anymore > (it used to do that reliably, but as it's now a favourite target for > spammers and was creating soo much backscatter, which was then filling > my mailbox with bounces... that had to change.) Hrm, that's not ideal. It'd be nice if it were able to do something like always reply if there were patch contents, or if it found things like the KernelVersion line in there. Obviously e-mail is also not time guaranteed so deciding it's not responded (and then working out why it did that) is going to be unreliable too. I do recall seeing the patch in the database but it's not showing up any more so perhaps I was thinking of a different patch. > > Who's looking after clkdev these days? Mike doesn't seem to take > > patches as he's expecting Russell to take them which was happening for a > > while but I'm not sure that's the case any more, especially given > > Russell's followup here. Due to the patch tracker the usual things for > > following up on unapplied patches don't work terribly well, it's much > > less likely that it's just an oversight there. > Well, in theory I'm the maintainer for clkdev and clk API, so I should > take the patch... OK, that's what I'd thought was going on - it was the fact that you'd just acked the patch rather than asked for it to go to the patch tracker or something which made me wonder if things had changed.
On Mon, Sep 10, 2012 at 08:20:21AM +0800, Mark Brown wrote: > On Mon, Sep 10, 2012 at 01:15:24AM +0100, Russell King - ARM Linux wrote: > > Note that the patch system doesn't always return error messages anymore > > (it used to do that reliably, but as it's now a favourite target for > > spammers and was creating soo much backscatter, which was then filling > > my mailbox with bounces... that had to change.) > > Hrm, that's not ideal. It'd be nice if it were able to do something > like always reply if there were patch contents, or if it found things > like the KernelVersion line in there. Obviously e-mail is also not time > guaranteed so deciding it's not responded (and then working out why it > did that) is going to be unreliable too. It tries to - if it finds what it thinks is a patch in the right place in the email. If it doesn't think it found a patch then it won't reply. In other words, if you include a patch without a PATCH FOLLOWS or the --- commit message/diffstat break marker preceding it, it will ignore you. > I do recall seeing the patch in the database but it's not showing up any > more so perhaps I was thinking of a different patch. Well, no patch ever gets deleted from the database... the only way even I can do that is to manually issue the SQL. > OK, that's what I'd thought was going on - it was the fact that you'd > just acked the patch rather than asked for it to go to the patch tracker > or something which made me wonder if things had changed. I kind'a forgot because it's been soo long since I took any of those patches...
Hi Lars-Peter, On 10/09/12 01:01, Lars-Peter Clausen wrote: > The managed clk functions are currently only available when the generic clk > lookup framework is build. But the managed clk functions are merely wrappers > around clk_get and clk_put and do not depend on any specifics of the generic > lookup functions and there are still quite a few custom implementations of the > clk API. So make the managed functions available whenever the clk API is > implemented. > > The patch also removes the custom implementation of devm_clk_get for the > coldfire platform. > > Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Nice work, thanks. Acked-by: Greg Ungerer <gerg@uclinux.org> Regards Greg > --- > arch/m68k/platform/coldfire/clk.c | 6 ---- > drivers/clk/Makefile | 1 + > drivers/clk/clk-devres.c | 55 +++++++++++++++++++++++++++++++++++++ > drivers/clk/clkdev.c | 45 ------------------------------ > 4 files changed, 56 insertions(+), 51 deletions(-) > create mode 100644 drivers/clk/clk-devres.c > > diff --git a/arch/m68k/platform/coldfire/clk.c b/arch/m68k/platform/coldfire/clk.c > index 75f9ee9..9cd13b4 100644 > --- a/arch/m68k/platform/coldfire/clk.c > +++ b/arch/m68k/platform/coldfire/clk.c > @@ -146,9 +146,3 @@ struct clk_ops clk_ops1 = { > }; > #endif /* MCFPM_PPMCR1 */ > #endif /* MCFPM_PPMCR0 */ > - > -struct clk *devm_clk_get(struct device *dev, const char *id) > -{ > - return NULL; > -} > -EXPORT_SYMBOL(devm_clk_get); > diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile > index 6327536..b7b8620 100644 > --- a/drivers/clk/Makefile > +++ b/drivers/clk/Makefile > @@ -1,4 +1,5 @@ > # common clock types > +obj-$(CONFIG_HAVE_CLK) += clk-devres.o > obj-$(CONFIG_CLKDEV_LOOKUP) += clkdev.o > obj-$(CONFIG_COMMON_CLK) += clk.o clk-fixed-rate.o clk-gate.o \ > clk-mux.o clk-divider.o clk-fixed-factor.o > diff --git a/drivers/clk/clk-devres.c b/drivers/clk/clk-devres.c > new file mode 100644 > index 0000000..f1e7a83 > --- /dev/null > +++ b/drivers/clk/clk-devres.c > @@ -0,0 +1,55 @@ > +/* > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License version 2 as > + * published by the Free Software Foundation. > + */ > + > +#include <linux/clk.h> > +#include <linux/device.h> > +#include <linux/export.h> > +#include <linux/gfp.h> > + > +static void devm_clk_release(struct device *dev, void *res) > +{ > + clk_put(*(struct clk **)res); > +} > + > +struct clk *devm_clk_get(struct device *dev, const char *id) > +{ > + struct clk **ptr, *clk; > + > + ptr = devres_alloc(devm_clk_release, sizeof(*ptr), GFP_KERNEL); > + if (!ptr) > + return ERR_PTR(-ENOMEM); > + > + clk = clk_get(dev, id); > + if (!IS_ERR(clk)) { > + *ptr = clk; > + devres_add(dev, ptr); > + } else { > + devres_free(ptr); > + } > + > + return clk; > +} > +EXPORT_SYMBOL(devm_clk_get); > + > +static int devm_clk_match(struct device *dev, void *res, void *data) > +{ > + struct clk **c = res; > + if (!c || !*c) { > + WARN_ON(!c || !*c); > + return 0; > + } > + return *c == data; > +} > + > +void devm_clk_put(struct device *dev, struct clk *clk) > +{ > + int ret; > + > + ret = devres_destroy(dev, devm_clk_release, devm_clk_match, clk); > + > + WARN_ON(ret); > +} > +EXPORT_SYMBOL(devm_clk_put); > diff --git a/drivers/clk/clkdev.c b/drivers/clk/clkdev.c > index d423c9b..442a313 100644 > --- a/drivers/clk/clkdev.c > +++ b/drivers/clk/clkdev.c > @@ -171,51 +171,6 @@ void clk_put(struct clk *clk) > } > EXPORT_SYMBOL(clk_put); > > -static void devm_clk_release(struct device *dev, void *res) > -{ > - clk_put(*(struct clk **)res); > -} > - > -struct clk *devm_clk_get(struct device *dev, const char *id) > -{ > - struct clk **ptr, *clk; > - > - ptr = devres_alloc(devm_clk_release, sizeof(*ptr), GFP_KERNEL); > - if (!ptr) > - return ERR_PTR(-ENOMEM); > - > - clk = clk_get(dev, id); > - if (!IS_ERR(clk)) { > - *ptr = clk; > - devres_add(dev, ptr); > - } else { > - devres_free(ptr); > - } > - > - return clk; > -} > -EXPORT_SYMBOL(devm_clk_get); > - > -static int devm_clk_match(struct device *dev, void *res, void *data) > -{ > - struct clk **c = res; > - if (!c || !*c) { > - WARN_ON(!c || !*c); > - return 0; > - } > - return *c == data; > -} > - > -void devm_clk_put(struct device *dev, struct clk *clk) > -{ > - int ret; > - > - ret = devres_destroy(dev, devm_clk_release, devm_clk_match, clk); > - > - WARN_ON(ret); > -} > -EXPORT_SYMBOL(devm_clk_put); > - > void clkdev_add(struct clk_lookup *cl) > { > mutex_lock(&clocks_mutex); >
On 09/10/2012 02:39 AM, Russell King - ARM Linux wrote: > On Mon, Sep 10, 2012 at 08:20:21AM +0800, Mark Brown wrote: >>[...] >> OK, that's what I'd thought was going on - it was the fact that you'd >> just acked the patch rather than asked for it to go to the patch tracker >> or something which made me wonder if things had changed. > > I kind'a forgot because it's been soo long since I took any of those > patches... Ok, what's the plan? Should I add this patch to the patch tracker? Thanks, - Lars
On Tue, 2012-09-11 at 16:44 +0200, Lars-Peter Clausen wrote: > On 09/10/2012 02:39 AM, Russell King - ARM Linux wrote: > > On Mon, Sep 10, 2012 at 08:20:21AM +0800, Mark Brown wrote: > >>[...] > >> OK, that's what I'd thought was going on - it was the fact that you'd > >> just acked the patch rather than asked for it to go to the patch tracker > >> or something which made me wonder if things had changed. > > > > I kind'a forgot because it's been soo long since I took any of those > > patches... > > Ok, what's the plan? Should I add this patch to the patch tracker? I'd propose to send it to Linus for v3.6 even.
On Tue, Sep 11, 2012 at 04:44:06PM +0200, Lars-Peter Clausen wrote: > On 09/10/2012 02:39 AM, Russell King - ARM Linux wrote: > > On Mon, Sep 10, 2012 at 08:20:21AM +0800, Mark Brown wrote: > >>[...] > >> OK, that's what I'd thought was going on - it was the fact that you'd > >> just acked the patch rather than asked for it to go to the patch tracker > >> or something which made me wonder if things had changed. > > > > I kind'a forgot because it's been soo long since I took any of those > > patches... > > Ok, what's the plan? Should I add this patch to the patch tracker? Yes please.
On 12/09/12 00:50, Artem Bityutskiy wrote: > On Tue, 2012-09-11 at 16:44 +0200, Lars-Peter Clausen wrote: >> On 09/10/2012 02:39 AM, Russell King - ARM Linux wrote: >>> On Mon, Sep 10, 2012 at 08:20:21AM +0800, Mark Brown wrote: >>>> [...] >>>> OK, that's what I'd thought was going on - it was the fact that you'd >>>> just acked the patch rather than asked for it to go to the patch tracker >>>> or something which made me wonder if things had changed. >>> >>> I kind'a forgot because it's been soo long since I took any of those >>> patches... >> >> Ok, what's the plan? Should I add this patch to the patch tracker? > > I'd propose to send it to Linus for v3.6 even. If we do this can we make a decision quickly on it. I need to fix a regression on some ColdFire parts for 3.6. I either need to use this clk patch, which fixes my problem, or a specific patch for the ColdFire clk code http://marc.info/?l=linux-m68k&m=134725225823437&w=2 Regards Greg
On 09/12/2012 03:32 AM, Greg Ungerer wrote: > On 12/09/12 00:50, Artem Bityutskiy wrote: >> On Tue, 2012-09-11 at 16:44 +0200, Lars-Peter Clausen wrote: >>> On 09/10/2012 02:39 AM, Russell King - ARM Linux wrote: >>>> On Mon, Sep 10, 2012 at 08:20:21AM +0800, Mark Brown wrote: >>>>> [...] >>>>> OK, that's what I'd thought was going on - it was the fact that you'd >>>>> just acked the patch rather than asked for it to go to the patch >>>>> tracker >>>>> or something which made me wonder if things had changed. >>>> >>>> I kind'a forgot because it's been soo long since I took any of those >>>> patches... >>> >>> Ok, what's the plan? Should I add this patch to the patch tracker? >> >> I'd propose to send it to Linus for v3.6 even. > > If we do this can we make a decision quickly on it. > > I need to fix a regression on some ColdFire parts for 3.6. I either need > to use this clk patch, which fixes my problem, or a specific patch for the > ColdFire clk code http://marc.info/?l=linux-m68k&m=134725225823437&w=2 > I wouldn't mind having this merged sooner rather than later, there is at least one driver in next which is currently broken due to the missing devm_clk_get. Russell what's your plan for the patch? Maybe under the given circumstances it makes sense to let it go through the m68k tree. - Lars
On Wed, Sep 12, 2012 at 10:43:07PM +0200, Lars-Peter Clausen wrote: > I wouldn't mind having this merged sooner rather than later, there is at least > one driver in next which is currently broken due to the missing devm_clk_get. > Russell what's your plan for the patch? Maybe under the given circumstances it > makes sense to let it go through the m68k tree. Ok, I've merged it but there was no indication in the patch that it was supposed to be a fix... there's no cc: to stable. Does it need to go to stable? When was this brokenness introduced? What's the story for the m68k bit? (Cc on this thread to stable added so they can hear the reply... so if it does end up with a Cc: being added to the commit, they have the background... this is *not* a stable submission request.)
On 09/16/2012 07:31 AM, Russell King - ARM Linux wrote: > On Wed, Sep 12, 2012 at 10:43:07PM +0200, Lars-Peter Clausen wrote: >> I wouldn't mind having this merged sooner rather than later, there is at least >> one driver in next which is currently broken due to the missing devm_clk_get. >> Russell what's your plan for the patch? Maybe under the given circumstances it >> makes sense to let it go through the m68k tree. > > Ok, I've merged it but there was no indication in the patch that it was > supposed to be a fix... there's no cc: to stable. Does it need to go to > stable? When was this brokenness introduced? What's the story for the > m68k bit? For the m68k issues this is not a candidate for stable. The breakage that this fixes did not occur until the 3.6 merge window. The fact that it fixes some breakage on some m68k platforms is more of a side effect, and the original patch author would not have known about this. The underlying problem was with the local m68k/coldfire implementation of devm_clk_get, but this patch makes that code go away completely. Regards Greg ------------------------------------------------------------------------ Greg Ungerer -- Principal Engineer EMAIL: gerg@snapgear.com SnapGear Group, McAfee PHONE: +61 7 3435 2888 8 Gardner Close, FAX: +61 7 3891 3630 Milton, QLD, 4064, Australia WEB: http://www.SnapGear.com
On Sat, Sep 15, 2012 at 10:31:52PM +0100, Russell King - ARM Linux wrote: > On Wed, Sep 12, 2012 at 10:43:07PM +0200, Lars-Peter Clausen wrote: > > I wouldn't mind having this merged sooner rather than later, there is at least > > one driver in next which is currently broken due to the missing devm_clk_get. > > Russell what's your plan for the patch? Maybe under the given circumstances it > > makes sense to let it go through the m68k tree. > > Ok, I've merged it but there was no indication in the patch that it was > supposed to be a fix... there's no cc: to stable. Does it need to go to > stable? When was this brokenness introduced? What's the story for the > m68k bit? What tree is this supposed to go through? I've checked your ARM tree as well as Mike's clock tree but neither seem to carry this patch. The reason I ask is because I want to take a patch series that converts the Unicore32 PWM code to the PWM framework into linux-next but it depends on this patch as well. Thierry
On Tue, Sep 18, 2012 at 10:00:37AM +0200, Thierry Reding wrote: > On Sat, Sep 15, 2012 at 10:31:52PM +0100, Russell King - ARM Linux wrote: > > On Wed, Sep 12, 2012 at 10:43:07PM +0200, Lars-Peter Clausen wrote: > > > I wouldn't mind having this merged sooner rather than later, there is at least > > > one driver in next which is currently broken due to the missing devm_clk_get. > > > Russell what's your plan for the patch? Maybe under the given circumstances it > > > makes sense to let it go through the m68k tree. > > > > Ok, I've merged it but there was no indication in the patch that it was > > supposed to be a fix... there's no cc: to stable. Does it need to go to > > stable? When was this brokenness introduced? What's the story for the > > m68k bit? > > What tree is this supposed to go through? I've checked your ARM tree as > well as Mike's clock tree but neither seem to carry this patch. The > reason I ask is because I want to take a patch series that converts the > Unicore32 PWM code to the PWM framework into linux-next but it depends > on this patch as well. It /is/ in my tree (you'll notice that it is in linux-next.) You're probably looking at my Linaro tree instead, which doesn't carry anything which isn't about to be sent to Linus. I'll publish the branch for this in the next couple of days.
On Tue, Sep 18, 2012 at 10:35:36AM +0100, Russell King - ARM Linux wrote: > On Tue, Sep 18, 2012 at 10:00:37AM +0200, Thierry Reding wrote: > > On Sat, Sep 15, 2012 at 10:31:52PM +0100, Russell King - ARM Linux wrote: > > > On Wed, Sep 12, 2012 at 10:43:07PM +0200, Lars-Peter Clausen wrote: > > > > I wouldn't mind having this merged sooner rather than later, there is at least > > > > one driver in next which is currently broken due to the missing devm_clk_get. > > > > Russell what's your plan for the patch? Maybe under the given circumstances it > > > > makes sense to let it go through the m68k tree. > > > > > > Ok, I've merged it but there was no indication in the patch that it was > > > supposed to be a fix... there's no cc: to stable. Does it need to go to > > > stable? When was this brokenness introduced? What's the story for the > > > m68k bit? > > > > What tree is this supposed to go through? I've checked your ARM tree as > > well as Mike's clock tree but neither seem to carry this patch. The > > reason I ask is because I want to take a patch series that converts the > > Unicore32 PWM code to the PWM framework into linux-next but it depends > > on this patch as well. > > It /is/ in my tree (you'll notice that it is in linux-next.) You're > probably looking at my Linaro tree instead, which doesn't carry > anything which isn't about to be sent to Linus. I must be blind then. next-20120918 doesn't have it. And looking at your tree here[0] doesn't show the commit either. > I'll publish the branch for this in the next couple of days. Are you saying you haven't pushed the branch containing this commit to your tree yet? That would certainly explain why I can't find it. Sorry if I'm being dense. I'll assume that it'll show up in linux-next eventually and that I can push the dependent series as well. Thierry [0]: git://ftp.arm.linux.org.uk/pub/linux/arm/kernel/git-cur/linux-arm.git
On Tue, Sep 18, 2012 at 01:25:55PM +0200, Thierry Reding wrote: > On Tue, Sep 18, 2012 at 10:35:36AM +0100, Russell King - ARM Linux wrote: > > On Tue, Sep 18, 2012 at 10:00:37AM +0200, Thierry Reding wrote: > > > On Sat, Sep 15, 2012 at 10:31:52PM +0100, Russell King - ARM Linux wrote: > > > > On Wed, Sep 12, 2012 at 10:43:07PM +0200, Lars-Peter Clausen wrote: > > > > > I wouldn't mind having this merged sooner rather than later, there is at least > > > > > one driver in next which is currently broken due to the missing devm_clk_get. > > > > > Russell what's your plan for the patch? Maybe under the given circumstances it > > > > > makes sense to let it go through the m68k tree. > > > > > > > > Ok, I've merged it but there was no indication in the patch that it was > > > > supposed to be a fix... there's no cc: to stable. Does it need to go to > > > > stable? When was this brokenness introduced? What's the story for the > > > > m68k bit? I said abouve "I've merged it" - that means, I've put it in my tree... > > > What tree is this supposed to go through? I've checked your ARM tree as > > > well as Mike's clock tree but neither seem to carry this patch. The > > > reason I ask is because I want to take a patch series that converts the > > > Unicore32 PWM code to the PWM framework into linux-next but it depends > > > on this patch as well. > > > > It /is/ in my tree (you'll notice that it is in linux-next.) You're > > probably looking at my Linaro tree instead, which doesn't carry > > anything which isn't about to be sent to Linus. > > I must be blind then. next-20120918 doesn't have it. And looking at your > tree here[0] doesn't show the commit either. Hmm, it's possible I didn't push the tree out... well, I have done so now, so it should be visible from tonight onwards and should be in -next sometime during the next couple of days (it seems to take a couple of days between me pushing stuff out one evening to stuff appearing in -next because of the timezones and timing of sfr's pulls.)
On Tue, Sep 18, 2012 at 09:40:14PM +0100, Russell King - ARM Linux wrote: > On Tue, Sep 18, 2012 at 01:25:55PM +0200, Thierry Reding wrote: > > On Tue, Sep 18, 2012 at 10:35:36AM +0100, Russell King - ARM Linux wrote: > > > On Tue, Sep 18, 2012 at 10:00:37AM +0200, Thierry Reding wrote: > > > > On Sat, Sep 15, 2012 at 10:31:52PM +0100, Russell King - ARM Linux wrote: > > > > > On Wed, Sep 12, 2012 at 10:43:07PM +0200, Lars-Peter Clausen wrote: > > > > > > I wouldn't mind having this merged sooner rather than later, there is at least > > > > > > one driver in next which is currently broken due to the missing devm_clk_get. > > > > > > Russell what's your plan for the patch? Maybe under the given circumstances it > > > > > > makes sense to let it go through the m68k tree. > > > > > > > > > > Ok, I've merged it but there was no indication in the patch that it was > > > > > supposed to be a fix... there's no cc: to stable. Does it need to go to > > > > > stable? When was this brokenness introduced? What's the story for the > > > > > m68k bit? > > I said abouve "I've merged it" - that means, I've put it in my > tree... > > > > > What tree is this supposed to go through? I've checked your ARM tree as > > > > well as Mike's clock tree but neither seem to carry this patch. The > > > > reason I ask is because I want to take a patch series that converts the > > > > Unicore32 PWM code to the PWM framework into linux-next but it depends > > > > on this patch as well. > > > > > > It /is/ in my tree (you'll notice that it is in linux-next.) You're > > > probably looking at my Linaro tree instead, which doesn't carry > > > anything which isn't about to be sent to Linus. > > > > I must be blind then. next-20120918 doesn't have it. And looking at your > > tree here[0] doesn't show the commit either. > > Hmm, it's possible I didn't push the tree out... well, I have done so > now, so it should be visible from tonight onwards and should be in > -next sometime during the next couple of days (it seems to take a > couple of days between me pushing stuff out one evening to stuff > appearing in -next because of the timezones and timing of sfr's pulls.) Okay, I see it both in your tree and in linux-next now. Thanks! Thierry
diff --git a/arch/m68k/platform/coldfire/clk.c b/arch/m68k/platform/coldfire/clk.c index 75f9ee9..9cd13b4 100644 --- a/arch/m68k/platform/coldfire/clk.c +++ b/arch/m68k/platform/coldfire/clk.c @@ -146,9 +146,3 @@ struct clk_ops clk_ops1 = { }; #endif /* MCFPM_PPMCR1 */ #endif /* MCFPM_PPMCR0 */ - -struct clk *devm_clk_get(struct device *dev, const char *id) -{ - return NULL; -} -EXPORT_SYMBOL(devm_clk_get); diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile index 6327536..b7b8620 100644 --- a/drivers/clk/Makefile +++ b/drivers/clk/Makefile @@ -1,4 +1,5 @@ # common clock types +obj-$(CONFIG_HAVE_CLK) += clk-devres.o obj-$(CONFIG_CLKDEV_LOOKUP) += clkdev.o obj-$(CONFIG_COMMON_CLK) += clk.o clk-fixed-rate.o clk-gate.o \ clk-mux.o clk-divider.o clk-fixed-factor.o diff --git a/drivers/clk/clk-devres.c b/drivers/clk/clk-devres.c new file mode 100644 index 0000000..f1e7a83 --- /dev/null +++ b/drivers/clk/clk-devres.c @@ -0,0 +1,55 @@ +/* + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include <linux/clk.h> +#include <linux/device.h> +#include <linux/export.h> +#include <linux/gfp.h> + +static void devm_clk_release(struct device *dev, void *res) +{ + clk_put(*(struct clk **)res); +} + +struct clk *devm_clk_get(struct device *dev, const char *id) +{ + struct clk **ptr, *clk; + + ptr = devres_alloc(devm_clk_release, sizeof(*ptr), GFP_KERNEL); + if (!ptr) + return ERR_PTR(-ENOMEM); + + clk = clk_get(dev, id); + if (!IS_ERR(clk)) { + *ptr = clk; + devres_add(dev, ptr); + } else { + devres_free(ptr); + } + + return clk; +} +EXPORT_SYMBOL(devm_clk_get); + +static int devm_clk_match(struct device *dev, void *res, void *data) +{ + struct clk **c = res; + if (!c || !*c) { + WARN_ON(!c || !*c); + return 0; + } + return *c == data; +} + +void devm_clk_put(struct device *dev, struct clk *clk) +{ + int ret; + + ret = devres_destroy(dev, devm_clk_release, devm_clk_match, clk); + + WARN_ON(ret); +} +EXPORT_SYMBOL(devm_clk_put); diff --git a/drivers/clk/clkdev.c b/drivers/clk/clkdev.c index d423c9b..442a313 100644 --- a/drivers/clk/clkdev.c +++ b/drivers/clk/clkdev.c @@ -171,51 +171,6 @@ void clk_put(struct clk *clk) } EXPORT_SYMBOL(clk_put); -static void devm_clk_release(struct device *dev, void *res) -{ - clk_put(*(struct clk **)res); -} - -struct clk *devm_clk_get(struct device *dev, const char *id) -{ - struct clk **ptr, *clk; - - ptr = devres_alloc(devm_clk_release, sizeof(*ptr), GFP_KERNEL); - if (!ptr) - return ERR_PTR(-ENOMEM); - - clk = clk_get(dev, id); - if (!IS_ERR(clk)) { - *ptr = clk; - devres_add(dev, ptr); - } else { - devres_free(ptr); - } - - return clk; -} -EXPORT_SYMBOL(devm_clk_get); - -static int devm_clk_match(struct device *dev, void *res, void *data) -{ - struct clk **c = res; - if (!c || !*c) { - WARN_ON(!c || !*c); - return 0; - } - return *c == data; -} - -void devm_clk_put(struct device *dev, struct clk *clk) -{ - int ret; - - ret = devres_destroy(dev, devm_clk_release, devm_clk_match, clk); - - WARN_ON(ret); -} -EXPORT_SYMBOL(devm_clk_put); - void clkdev_add(struct clk_lookup *cl) { mutex_lock(&clocks_mutex);
The managed clk functions are currently only available when the generic clk lookup framework is build. But the managed clk functions are merely wrappers around clk_get and clk_put and do not depend on any specifics of the generic lookup functions and there are still quite a few custom implementations of the clk API. So make the managed functions available whenever the clk API is implemented. The patch also removes the custom implementation of devm_clk_get for the coldfire platform. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> --- arch/m68k/platform/coldfire/clk.c | 6 ---- drivers/clk/Makefile | 1 + drivers/clk/clk-devres.c | 55 +++++++++++++++++++++++++++++++++++++ drivers/clk/clkdev.c | 45 ------------------------------ 4 files changed, 56 insertions(+), 51 deletions(-) create mode 100644 drivers/clk/clk-devres.c