thermal: power_allocator: do not use devm* interfaces
PATCH 1/1 thermal: power_allocator: do not use devm* interfaces
The code in question is called outside of standard driver probe()/remove() callbacks and thus will not benefit from use of devm* infrastructure.
--- drivers/thermal/power_allocator.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
drivers/thermal/power_allocator.c +4 -4
@@ -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 ; }
Signature · 5 lines
2.5.0.rc2.392.g76e840b -- Dmitry
Quoted 5 lines · Dmitry Torokhov
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 <[email protected]>
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
Quoted 10 lines · Javi Merino
Quoted 5 lines · Dmitry Torokhov
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 <[email protected]>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.
Signature · 1 line
Dmitry
Quoted 6 lines · Dmitry Torokhov
Quoted 5 lines · Javi Merino
Quoted 4 lines · Dmitry Torokhov
The code in question is called outside of standard driver probe()/remove() callbacks and thus will not benefit from use of devm* infrastructure.
Quoted 8 lines
Quoted 5 lines
Quoted 1 line
Signed-off-by Dmitry Torokhov <[email protected]>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
Quoted 13 lines · Javi Merino
Quoted 12 lines · Dmitry Torokhov
Quoted 10 lines · Javi Merino
Quoted 5 lines · Dmitry Torokhov
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 <[email protected]>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.
Quoted 8 lines
Quoted 2 lines
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=1722858He 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
Quoted 3 lines
Cheers,
Javi