From: Anton Vorontsov <cbouatmailru@gmail.com>
To: Richard Hughes <hughsient@gmail.com>
Cc: linux-acpi <linux-acpi@vger.kernel.org>,
spyro@f2s.com, Bastien Nocera <hadess@hadess.net>,
linux-kernel@vger.kernel.org
Subject: Re: Exporting struct power_supply.use_for_apm
Date: Wed, 22 Jun 2011 19:38:07 +0400 [thread overview]
Message-ID: <20110622153807.GA17144@oksana.dev.rtsoft.ru> (raw)
In-Reply-To: <BANLkTimy_b1qva63DumxU=SBLHXMaPS2cg@mail.gmail.com>
Hello,
On Wed, Jun 22, 2011 at 03:25:03PM +0100, Richard Hughes wrote:
> Hi, if this isn't the correct mailing list please yell. I'm the author
> of upower which is a userspace service that presents the power devices
> in the system as a DBus interface for the session to use.
>
> In struct power_supply there is a boolean use_for_apm which seems to
> be 1 for devices actually powering the system, and 0 for devices
> attached to the machine. Would this be sane to export into sysfs as
> something sane?
Nope, use_for_apm is a legacy stuff. It just says which battery should
be reported via /proc/apm interface (if arch supports it).
It should be removed completely someday.
> The reason I ask, is that upower has to decide if the system as a
> whole has several high level states, e.g. "low-power" or
> "critically-low-power" and for that it needs to decide if the battery
> backing the power supply device is critical to the system power state.
> This would mean that a ACPI battery or UPS running low would mean the
> system is low, but a USB mouse or a wacom tablet would not prompt the
> low power warning.
>
> This email has been triggered by a bug report :
> https://bugs.freedesktop.org/show_bug.cgi?id=38569 in which the kernel
> patch http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=59d2334ac9f4255f5f8f3e4e1bf41653e0bba99e;hp=4da361b69102cdffe73006771eae7504d2cb8736
> added the power_supply device which confuses upower.
>
> The alternative is to change the wacom power_supply code from
> type=POWER_SUPPLY_TYPE_BATTERY to something else, e.g.
> POWER_SUPPLY_TYPE_ACCESSORY which upower can easily key from. I really
> don't want to blacklist "battery_wacom" as that seems like such a
> hack.
Yeah, that seems sane. But I'm not sure if that should be a type thing.
Instead, we might want to introduce additional
'struct device **supplied_to_devs' field in the 'struct power_supply'
(we have supplied_to field, but it won't work as it holds only device
names).
So, the logic should be:
bool power_supply_is_system_supply(device)
{
for_each_supplied_to(device, supplied_to) {
if (!is_power_supply(supplied_to)
return false;
return power_supply_is_system_supply(supplied_to)
}
return true;
}
And the kernel might export 'system_supply' property for each
battery.
Wacom driver will need just a small modification: it should fill
supplied_to_devs with its struct device.
Plus, someday we might want to expose 'supplied_to' via sysfs
directory.
E.g., if supplied_to_devs == NULL, then /sys/power_supply/BAT/supplied_to/
symlinks to /sys/devices. I.e. it's a system battery/mains.
If psy->supplied_to_devs == { dev1, dev2 }, then supplied_to/ contains
symlinks to only these devices.
Typical system with a removable battery (both AC0 and BAT0 power the
whole system):
AC0/supplied_to -> /sys/devices
BAT0/supplied_to -> /sys/devices
battery_wacom/supplied_to -> /sys/devices/pci0000\:00/0000\:00\:1c.0/wacom_input_device
Typical system with a electrically non-removable battery, i.e. AC0 only
powers BAT0, which powers a system:
AC0/supplied_to -> /sys/devices/platform/BAT0
BAT0/supplied_to -> /sys/devices
battery_wacom/supplied_to -> /sys/devices/pci0000\:00/0000\:00\:1c.0/wacom_input_device
--
Anton Vorontsov
Email: cbouatmailru@gmail.com
prev parent reply other threads:[~2011-06-22 15:38 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-22 14:25 Exporting struct power_supply.use_for_apm Richard Hughes
2011-06-22 15:38 ` Anton Vorontsov [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110622153807.GA17144@oksana.dev.rtsoft.ru \
--to=cbouatmailru@gmail.com \
--cc=hadess@hadess.net \
--cc=hughsient@gmail.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=spyro@f2s.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).