[lkml]   [2011]   [Dec]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [GIT PULL] power_supply: add power supply scope
    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,
    >> val->intval = ac->state;
    >> break;
    >> + 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?


     \ /
      Last update: 2011-12-08 17:55    [W:0.022 / U:4.444 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site