| Message ID | 20150804163340.GA33245@dtor-ws (mailing list archive) |
|---|---|
| State | Accepted |
| Headers | show |
On Tue, Aug 04, 2015 at 05:33:40PM +0100, Dmitry Torokhov wrote: > The code in question is called outside of standard driver > probe()/remove() callbacks and thus will not benefit from use of devm* > infrastructure. > > Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> We added the devm* calls because Eduardo asked for them in the review. I don't have a strong opinion regarding this, I'll leave the decision to Eduardo. Cheers, Javi -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Aug 05, 2015 at 09:29:11AM +0100, Javi Merino wrote: > On Tue, Aug 04, 2015 at 05:33:40PM +0100, Dmitry Torokhov wrote: > > The code in question is called outside of standard driver > > probe()/remove() callbacks and thus will not benefit from use of devm* > > infrastructure. > > > > Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> > > We added the devm* calls because Eduardo asked for them in the review. > I don't have a strong opinion regarding this, I'll leave the decision > to Eduardo. I tried to look for his reasons, if any, but even in earliest posted versions use devm* for allocating memory I guess this is one of examples of devm* usage in wrong context. Given that you, as you have to, because this is not a device driver, manually freeing that memory with devm_kfree(), the only thing that devm_kzalloc and friends buy you here is extra memory allocations for devres structures and few extra cycles for maintaining them. Thanks.
On Wed, Aug 05, 2015 at 05:50:20PM +0100, Dmitry Torokhov wrote: > On Wed, Aug 05, 2015 at 09:29:11AM +0100, Javi Merino wrote: > > On Tue, Aug 04, 2015 at 05:33:40PM +0100, Dmitry Torokhov wrote: > > > The code in question is called outside of standard driver > > > probe()/remove() callbacks and thus will not benefit from use of devm* > > > infrastructure. > > > > > > Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> > > > > We added the devm* calls because Eduardo asked for them in the review. > > I don't have a strong opinion regarding this, I'll leave the decision > > to Eduardo. > > I tried to look for his reasons, if any, but even in earliest posted > versions use devm* for allocating memory http://thread.gmane.org/gmane.linux.power-management.general/45000/focus=45265 http://thread.gmane.org/gmane.linux.power-management.general/46064/focus=1722858 He didn't give reasons and I didn't ask for them. He insisted on it so I just added it across the board. Cheers, Javi -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Aug 05, 2015 at 06:29:03PM +0100, Javi Merino wrote: > On Wed, Aug 05, 2015 at 05:50:20PM +0100, Dmitry Torokhov wrote: > > On Wed, Aug 05, 2015 at 09:29:11AM +0100, Javi Merino wrote: > > > On Tue, Aug 04, 2015 at 05:33:40PM +0100, Dmitry Torokhov wrote: > > > > The code in question is called outside of standard driver > > > > probe()/remove() callbacks and thus will not benefit from use of devm* > > > > infrastructure. > > > > > > > > Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> > > > > > > We added the devm* calls because Eduardo asked for them in the review. > > > I don't have a strong opinion regarding this, I'll leave the decision > > > to Eduardo. > > > > I tried to look for his reasons, if any, but even in earliest posted > > versions use devm* for allocating memory > > http://thread.gmane.org/gmane.linux.power-management.general/45000/focus=45265 > http://thread.gmane.org/gmane.linux.power-management.general/46064/focus=1722858 > > He didn't give reasons and I didn't ask for them. He insisted on it so I just added > it across the board. Yeah, that's my bad. I believe I had in mind getting the thermal core in a better shape by having proper driver/device matching. But still, looking at the code now, I must agree with Dmitry. As of now, it does not make sense. BR, Eduardo > > Cheers, > Javi
diff --git a/drivers/thermal/power_allocator.c b/drivers/thermal/power_allocator.c index 13ccf00..e9ba29f 100644 --- a/drivers/thermal/power_allocator.c +++ b/drivers/thermal/power_allocator.c @@ -334,7 +334,7 @@ static int allocate_power(struct thermal_zone_device *tz, max_allocatable_power, current_temp, control_temp - current_temp); - devm_kfree(&tz->device, req_power); + kfree(req_power); unlock: mutex_unlock(&tz->lock); @@ -426,7 +426,7 @@ static int power_allocator_bind(struct thermal_zone_device *tz) return -EINVAL; } - params = devm_kzalloc(&tz->device, sizeof(*params), GFP_KERNEL); + params = kzalloc(sizeof(*params), GFP_KERNEL); if (!params) return -ENOMEM; @@ -468,14 +468,14 @@ static int power_allocator_bind(struct thermal_zone_device *tz) return 0; free: - devm_kfree(&tz->device, params); + kfree(params); return ret; } static void power_allocator_unbind(struct thermal_zone_device *tz) { dev_dbg(&tz->device, "Unbinding from thermal zone %d\n", tz->id); - devm_kfree(&tz->device, tz->governor_data); + kfree(tz->governor_data); tz->governor_data = NULL; }
The code in question is called outside of standard driver probe()/remove() callbacks and thus will not benefit from use of devm* infrastructure. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> --- drivers/thermal/power_allocator.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)