Re: [GIT PULL] power_supply: add power supply scope
From: Daniel Nicoletti
Date: Fri Dec 09 2011 - 15:00:13 EST
>>> diff --git a/drivers/power/power_supply_sysfs.c b/drivers/power/power_supply_sysfs.c
>>> index e15d4c9..21178eb 100644
>>> --- a/drivers/power/power_supply_sysfs.c
>>> +++ b/drivers/power/power_supply_sysfs.c
>>> @@ -63,6 +63,9 @@ static ssize_t power_supply_show_property(struct device *dev,
>>> static char *capacity_level_text[] = {
>>> "Unknown", "Critical", "Low", "Normal", "High", "Full"
>>> };
>>> + static char *scope_text[] = {
>>> + "Unknown", "System", "Device"
>>> + };
>>> ssize_t ret = 0;
>>> struct power_supply *psy = dev_get_drvdata(dev);
>>> const ptrdiff_t off = attr - power_supply_attrs;
>>> @@ -95,6 +98,8 @@ static ssize_t power_supply_show_property(struct device *dev,
>>> return sprintf(buf, "%s\n", capacity_level_text[value.intval]);
>>> else if (off == POWER_SUPPLY_PROP_TYPE)
>>> return sprintf(buf, "%s\n", type_text[value.intval]);
>>> + else if (off == POWER_SUPPLY_PROP_SCOPE)
>>> + return sprintf(buf, "%s\n", scope_text[value.intval]);
>> Should we really handle the PROP_SCOPE as a dynamic property?
>> Maybe do it similar to PROP_TYPE, so that drivers will only need to
>> specity the scope during registration, and not bother w/ handling
>> it in theirs get_property() callbacks?
>
> I don't really know. I guess its possible in theory that a device could
> change scope on the fly if its power was re-routed. But then, the type
> can change too (if, for example, a UPS switched between AC and battery
> power, or a HID device switching between corded USB power or cordless
> battery power), so I'm not really sure what the rationale is either
> way. (I guess you model power supplies switching type as having
> multiple power supplies which turn themselves on and offline?)
But isn't the scope about powering or not the system? If so even if
the device is now using AC it will not be powering the computer.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/