From: Sebastian Reichel <sebastian.reichel@collabora.com>
Cc: linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] power: supply: leds: add a not-charging trigger
Date: Sat, 25 Jul 2026 04:40:09 +0200 [thread overview]
Message-ID: <amQWViWt8ovRisp0@venus> (raw)
In-Reply-To: <b31e36e3c6b36e1b65880d91b53f6f3f9611a102.camel@dirkwinkel.cc>
[-- Attachment #1: Type: text/plain, Size: 2976 bytes --]
Hi,
On Tue, Jul 21, 2026 at 08:56:47AM +0200, Steffen Dirkwinkel wrote:
> On Tue, 2026-07-21 at 00:23 +0200, Sebastian Reichel wrote:
> > On Thu, Jun 25, 2026 at 07:07:35PM +0200, Steffen Dirkwinkel wrote:
> > > From: Steffen Dirkwinkel <s.dirkwinkel@beckhoff.com>
> > >
> > > We intend to use this with a gpio-charger ups device that reports
> > > charging or not-charging based on a gpio to set a "power failure" led.
> > >
> > > Signed-off-by: Steffen Dirkwinkel <s.dirkwinkel@beckhoff.com>
> > > ---
> > > drivers/power/supply/power_supply_leds.c | 7 +++++++
> > > include/linux/power_supply.h | 1 +
> > > 2 files changed, 8 insertions(+)
> >
> > POWER_SUPPLY_STATUS_NOT_CHARGING means, that a battery is neither
> > charged **nor discharged**. I think the NOT_CHARGING status has a
> > bad name, but it's ABI and cannot be changed easily. But I certainly
> > don't want it to spread further. Let's find a better name for this
> > trigger. Maybe idle?
>
> Hm, I guess I was also mislead by the name, as it's somewhat correct for my
> usecase, our gpio connected ups is indicating "not-charging" via a gpio and I'm
> using it as a gpio-charger charge-status-gpio.
>
> I guess it would be more correct if I could map the gpio-charger charge status
> to switch between charging and discharging instead of indicating not-charging.
> If you agree I'd add that as an option via device tree binding there and add a
> discharging trigger instead of the not charging one to the led triggers:
>
> charge-status-discharging:
> type: boolean
> description:
> Interpret a deasserted charge-status-gpio as "discharging" instead of
> "not charging".
For a normal charger your gpio would be the ONLINE state effectively
(i.e. "gpios" in the binding). For most devices that's basically the
only thing a charger reports.
Looking at UPS support in the mainline kernel, it does not look like
anyone used it so far (not just with gpio-charger; I cannot finy *any*
user for POWER_SUPPLY_TYPE_UPS). I do see some issues with some of
the power-supply framework's properties as a UPS is basically a
combination of a charger and a battery. I wonder if it's better to
simply expose them separately to avoid these problems.
Can you share a bit more details about your platform? Would it be
possible to expose your UPS like this?
ups_charger: charger {
compatible = "gpio-charger";
charger-type = "mains";
gpios = <your_status_gpio>;
};
ups_battery: battery {
compatible = "gpio-battery";
power-supplies = <&ups_charger>;
/*
* does not yet exist, any GPIOs are optional. In the simple
* case it creates a TYPE_BATTERY device, which sets its own
* status based on the ONLINE state of the charger it is being
* supplied from. Potentially could have a gpio to notify
* critical battery status.
*/
};
Greetings,
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2026-07-25 2:40 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-25 17:07 [PATCH 0/2] power: supply: leds: add triggers for non battery type Steffen Dirkwinkel
2026-06-25 17:07 ` [PATCH 1/2] power: supply: leds: create triggers based on properties, not type Steffen Dirkwinkel
2026-07-24 5:58 ` [REGRESSION]: " Borah, Chaitanya Kumar
2026-07-24 7:33 ` Steffen Dirkwinkel
2026-07-24 10:13 ` Borah, Chaitanya Kumar
2026-06-25 17:07 ` [PATCH 2/2] power: supply: leds: add a not-charging trigger Steffen Dirkwinkel
2026-07-20 22:23 ` Sebastian Reichel
2026-07-21 6:56 ` Steffen Dirkwinkel
2026-07-25 2:40 ` Sebastian Reichel [this message]
2026-07-20 22:23 ` (subset) [PATCH 0/2] power: supply: leds: add triggers for non battery type Sebastian Reichel
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=amQWViWt8ovRisp0@venus \
--to=sebastian.reichel@collabora.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.