Re: [GIT PULL] power_supply: add power supply scope

[Jeremy Fitzhardinge]

On 12/08/2011 02:41 AM, Anton Vorontsov wrote:
> On Wed, Dec 07, 2011 at 05:41:37PM -0800, Jeremy Fitzhardinge wrote:
> [...]
>> diff --git a/drivers/acpi/ac.c b/drivers/acpi/ac.c
>> index 6512b20..ec36c82 100644
>> --- a/drivers/acpi/ac.c
>> +++ b/drivers/acpi/ac.c
>> @@ -142,6 +142,9 @@ static int get_ac_property(struct power_supply *psy,
>>  	case POWER_SUPPLY_PROP_ONLINE:
>>  		val->intval = ac->state;
>>  		break;
>> +	case POWER_SUPPLY_PROP_SCOPE:
>> +		val->intval = POWER_SUPPLY_SCOPE_SYSTEM;
>> +		break;
>>  	default:
>>  		return -EINVAL;
>>  	}
> Mm... how about the rest of the drivers? I.e. drivers/power/*battery.c?
>
> I think it's not a great idea to patch every driver, would be better to make
> it similar to how we handle power_supply.type (w/ default value 'SYSTEM').

Yes.  That patch was mostly so I could test the mechanism.  Certainly
general rule is that if there's no scope attribute then assume System.

> But, thinking more about it... personally, from the ABI point of view, I'd
> like to just see some kind of 'supplicants' directory in the power_supply
> instances, with symlinks to an appropriate devices.

Yes, that was my first proposal, and I have a patch to allow Device
scope power supplies to indicate which "device" it is (which may be a
root of a subtree of devices).  I'm not too sure about making it
multiple devices; at that point I'd be tempted to introduce the notion
of a "power bus" which points to multiple devices and make power
supplies point to that.

> I.e.
> /sys/class/power_supply/battery/supplicants/<device_name>
> is a symlink to /sys/class/HID/.../device.
>
> With a special meaning of an empty directory (or non-existent, or w/ a
> symlink pointing to '/sys/devices/system') -- system power.

Yes.  That's awkward to implement because the kobj isn't exported from
device/base.  But aside from that, its a somewhat awkward interface for
usermode, because it has to end up following symlink and resolving their
paths, and then having special hardcoded knowledge of what particular
paths mean.  When all upower really wants to know is "do I need to
suspend when this supply gets low?".

> That way we may describe any possible power hierarchy.
>
> From the implementation point of view, for now power_supply may just
> conditionally (by introducing power_supply.not_system_power flag)

How is that different from scope?

    J
--
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/