Don't have Zoran's new email address, but probably other might have
answers to my queries.
I have just started with the power-supply framework a day or two back
and so my understanding might not be good enough :)
On Sat, Aug 3, 2013 at 2:08 AM, Zoran Markovic
<zoran.marko...@linaro.org> wrote:
> diff --git a/drivers/power/power_supply_core.c
> b/drivers/power/power_supply_core.c
> index 3b2d5df..e68d598 100644
> --- a/drivers/power/power_supply_core.c
> +++ b/drivers/power/power_supply_core.c
> @@ -67,23 +67,41 @@ static int __power_supply_changed_work(struct device
> *dev, void *data)
>
> static void power_supply_changed_work(struct work_struct *work)
> {
> + unsigned long flags;
> struct power_supply *psy = container_of(work, struct power_supply,
> changed_work);
>
> dev_dbg(psy->dev, "%s\n", __func__);
>
> - class_for_each_device(power_supply_class, NULL, psy,
> - __power_supply_changed_work);
> -
> - power_supply_update_leds(psy);
> -
> - kobject_uevent(&psy->dev->kobj, KOBJ_CHANGE);
> + spin_lock_irqsave(&psy->changed_lock, flags);
> + if (psy->changed) {
Can this be false here? We have reached here as the work was
scheduled after setting it to true..
Maybe a WARN_ON(psy->changed) is more sensible here ?
> + psy->changed = false;
> + spin_unlock_irqrestore(&psy->changed_lock, flags);
> + class_for_each_device(power_supply_class, NULL, psy,
> + __power_supply_changed_work);
> + power_supply_update_leds(psy);
> + kobject_uevent(&psy->dev->kobj, KOBJ_CHANGE);
> + spin_lock_irqsave(&psy->changed_lock, flags);
> + }
> + /* dependent power supplies (e.g. battery) may have changed
> + * state as a result of this event, so poll again and hold
> + * the wakeup_source until all events are processed.
> + */
> + if (!psy->changed)
> + pm_relax(psy->dev);
I got a bit confused here. Does the above comment say this:
The supplies dependent on 'psy' may change states and that *may*
change the state of 'psy' again? And so psy->changed is set to true
again?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
