All of lore.kernel.org
 help / color / mirror / Atom feed
From: Liam Breck <liam@networkimprov.net>
To: Sebastian Reichel <sre@kernel.org>
Cc: Tony Lindgren <tony@atomide.com>,
	linux-pm@vger.kernel.org, Hans de Goede <hdegoede@redhat.com>
Subject: Re: [PATCH v1 7/7] power: bq24190_charger: Set bq24190-battery device .type=unknown
Date: Thu, 23 Mar 2017 12:05:37 -0700	[thread overview]
Message-ID: <CAKvHMgQCq0zBeYXHL9hkbvtndEbrNocPzuPeRcPfKEON0+W4zA@mail.gmail.com> (raw)
In-Reply-To: <20170323133729.jexsnpwrmbxswn26@earth>

On Thu, Mar 23, 2017 at 6:37 AM, Sebastian Reichel <sre@kernel.org> wrote:
> Hi,
>
> On Thu, Mar 23, 2017 at 04:31:50AM -0700, Liam Breck wrote:
>>> That still leaves the health status reading, though. From
>>> userspace's point-of-view this should be merged into the
>>> battery device, if fuel-gauge can't provide that information.
>>
>> I think the bigger issue is that multiple sysfs devices for what is
>> conceptually one power supply is awkward. With the addition of static
>> battery object, we have yet another set of properties which belong to
>> that supply.
>
> The simple-battery is consumed by the fuel-gauge, so not a problem.
>
>> A solution to this would be a core registry which allows various
>> drivers to submit properties to a named supply. Properties with the
>> same id (e.g. health) are OK given a tag (input-V, NTC-1, battery-V)
>> to differentiate them. Duplicates would be dropped (e.g. both drivers
>> submit monitored-battery stats). The result would be represented in
>> sysfs as a single device, where each property would appear as a file
>> or directory as necessary. And perhaps also as a file "health_summary"
>> which indicates whether there's trouble below decks.
>
> Yes, that would be the proper solution. Might become important, if
> more platforms with multiple chips providing battery information
> appear. Since I don't think you want to implement your suggestion,

If you're genuinely interested, I could probably ask Matt to work on this...

> I suggest sticking to the custom "bat_fault" sysfs property. That
> should already be exposed for the charger device as far as I can
> see.

  reply	other threads:[~2017-03-23 19:05 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-21 22:09 [PATCH v1 0/7] BQ24190 support for power_supply_battery_info and DT binding Liam Breck
2017-03-21 22:09 ` [PATCH v1 1/7] devicetree: power: battery: Add properties for pre-charge and end-charge current Liam Breck
2017-03-24  9:01   ` Sebastian Reichel
2017-03-25  0:34     ` Liam Breck
2017-03-29  0:43       ` Rob Herring
     [not found]   ` <20170321220921.5834-2-liam-RYWXG+zxWwBdeoIcmNTgJF6hYfS7NtTn@public.gmane.org>
2017-03-22 12:04     ` Hans de Goede
2017-03-29  0:39     ` Rob Herring
2017-03-29  1:42       ` Liam Breck
2017-03-21 22:09 ` [PATCH v1 2/7] devicetree: power: Add docs for TI BQ24190 battery charger Liam Breck
2017-03-24  9:00   ` Sebastian Reichel
     [not found]   ` <20170321220921.5834-3-liam-RYWXG+zxWwBdeoIcmNTgJF6hYfS7NtTn@public.gmane.org>
2017-03-22 12:04     ` Hans de Goede
2017-03-29  0:47     ` Rob Herring
2017-03-29  1:48       ` Liam Breck
2017-03-21 22:09 ` [PATCH v1 3/7] power: power_supply_core: Add *_battery_info fields for pre- and end-charge current Liam Breck
2017-03-22 12:12   ` Hans de Goede
2017-03-24  9:07   ` Sebastian Reichel
2017-03-21 22:09 ` [PATCH v1 4/7] power: bq24190_charger: Uniform pm_runtime_get() failure handling Liam Breck
2017-03-22 12:14   ` Hans de Goede
2017-03-22 15:35   ` Tony Lindgren
2017-03-24  9:13   ` Sebastian Reichel
2017-03-21 22:09 ` [PATCH v1 5/7] power: bq24190_charger: Reorder init sequence in probe() Liam Breck
2017-03-22 12:14   ` Hans de Goede
2017-03-22 15:36     ` Tony Lindgren
2017-03-21 22:09 ` [PATCH v1 6/7] power: bq24190_charger: Add power_supply_battery_info and devicetree support Liam Breck
2017-03-22 12:15   ` Hans de Goede
2017-03-24  9:20   ` Sebastian Reichel
2017-03-21 22:09 ` [PATCH v1 7/7] power: bq24190_charger: Set bq24190-battery device .type=unknown Liam Breck
2017-03-22 12:25   ` Hans de Goede
2017-03-22 13:15     ` Hans de Goede
2017-03-22 13:37       ` Liam Breck
2017-03-22 14:41         ` Hans de Goede
2017-03-22 18:33           ` Liam Breck
2017-03-23  8:18             ` Hans de Goede
2017-03-23  8:55               ` Liam Breck
2017-03-22 13:22     ` Liam Breck
2017-03-23 10:52   ` Sebastian Reichel
2017-03-23 11:31     ` Liam Breck
2017-03-23 13:37       ` Sebastian Reichel
2017-03-23 19:05         ` Liam Breck [this message]
2017-03-23 20:47     ` Liam Breck
2017-03-24  9:39       ` Sebastian Reichel
2017-03-24 10:44         ` Liam Breck
2017-03-24 11:22           ` Sebastian Reichel
2017-03-24 11:56             ` Liam Breck
2017-03-29 14:12               ` Sebastian Reichel
2017-04-14 22:43     ` Liam Breck

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=CAKvHMgQCq0zBeYXHL9hkbvtndEbrNocPzuPeRcPfKEON0+W4zA@mail.gmail.com \
    --to=liam@networkimprov.net \
    --cc=hdegoede@redhat.com \
    --cc=linux-pm@vger.kernel.org \
    --cc=sre@kernel.org \
    --cc=tony@atomide.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 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.