| Message ID | 1348538339.10877.193.camel@rui.sh.intel.com (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
Hi Rui, > > > Hi, Jonghwa, > > > > > > I still do not understand what the problem is. > > > Say if a cooling device fails to bind, the thermal zone device would > > > still work properly, just like the failure cooling device is not > > > referenced in this thermal zone. > > > > > > thanks, > > > rui > > Hi rui, > > No, it doesn't work properly. If it fails to bind some cool dev to > > thermal zone device, it frees thermal zone > > device without canceling delayed work. After freeing thermal zone > > device, system may call work function > > pointed NULL as the timer expired. Thus it requires skipping the > > initialization of polling work or canceling before > > the unregister. > > > hah, I see what the problem is. > ideally, if we fail to bind one cooling device, we should just ignore it > and continue to bind other, what do you think? Yes, this is what we should do. > > does the patch below fix your problem? > If yes, I'll try to rebase it on top of my next tree. This is already fixed in your -next tree, since you applied the fair share patches 10/15. The function bind_tz(tz) does the exact same thing, and continues. Thanks, Durga
On 2012? 09? 25? 12:04, R, Durgadoss wrote: > Hi Rui, > >>>> Hi, Jonghwa, >>>> >>>> I still do not understand what the problem is. >>>> Say if a cooling device fails to bind, the thermal zone device would >>>> still work properly, just like the failure cooling device is not >>>> referenced in this thermal zone. >>>> >>>> thanks, >>>> rui >>> Hi rui, >>> No, it doesn't work properly. If it fails to bind some cool dev to >>> thermal zone device, it frees thermal zone >>> device without canceling delayed work. After freeing thermal zone >>> device, system may call work function >>> pointed NULL as the timer expired. Thus it requires skipping the >>> initialization of polling work or canceling before >>> the unregister. >> >> hah, I see what the problem is. >> ideally, if we fail to bind one cooling device, we should just ignore it >> and continue to bind other, what do you think? > Yes, this is what we should do. > >> does the patch below fix your problem? >> If yes, I'll try to rebase it on top of my next tree. > This is already fixed in your -next tree, since you applied the > fair share patches 10/15. The function bind_tz(tz) does the > exact same thing, and continues. > > Thanks, > Durga I checked that it had been applied on -next branch, I don't commit this patch any more. Thanks, Jonghwa > N?????r??y???b?X???v?^?)?{.n?+????{??h?????}????z?&j:+v???????zZ+??+zf???h???~????i???z? ?w????????&?)?fl=== -- 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
diff --git a/drivers/thermal/thermal_sys.c b/drivers/thermal/thermal_sys.c index 2ab31e4..c5e2c28 100644 --- a/drivers/thermal/thermal_sys.c +++ b/drivers/thermal/thermal_sys.c @@ -1343,20 +1343,17 @@ struct thermal_zone_device *thermal_zone_device_register(const char *type, mutex_lock(&thermal_list_lock); list_add_tail(&tz->node, &thermal_tz_list); - if (ops->bind) - list_for_each_entry(pos, &thermal_cdev_list, node) { - result = ops->bind(tz, pos); - if (result) - break; - } + if (ops->bind) { + list_for_each_entry(pos, &thermal_cdev_list, node) + ops->bind(tz, pos); + } mutex_unlock(&thermal_list_lock); INIT_DELAYED_WORK(&(tz->poll_queue), thermal_zone_device_check); thermal_zone_device_update(tz); - if (!result) - return tz; + return tz; unregister: release_idr(&thermal_tz_idr, &thermal_idr_lock, tz->id);