All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v3] power: supply: sbs-battery: Handle unsupported PROP_TIME_TO_EMPTY_NOW
@ 2024-04-18 17:34 Nícolas F. R. A. Prado
  2024-04-19  7:26 ` AngeloGioacchino Del Regno
  2024-04-19 16:03 ` Nícolas F. R. A. Prado
  0 siblings, 2 replies; 8+ messages in thread
From: Nícolas F. R. A. Prado @ 2024-04-18 17:34 UTC (permalink / raw)
  To: Sebastian Reichel
  Cc: kernel, linux-pm, linux-kernel, Pin-yen Lin, Hsin-Te Yuan,
	Nícolas F. R. A. Prado

Despite the RunTimeToEmpty() (0x11) function being defined in the SBS
specification as required, it seems that not all batteries implement it.
On platforms with such batteries, reading the property will cause an
error to be printed:

power_supply sbs-8-000b: driver failed to report `time_to_empty_now' property: -5

This not only pollutes the log, distracting from real problems on the
device, but also prevents the uevent file from being read since it
contains all properties, including the faulty one.

The following table summarizes the findings for a handful of platforms:

Platform                                Status  Manufacturer    Model
------------------------------------------------------------------------
mt8186-corsola-steelix-sku131072        OK      BYD             L22B3PG0
mt8195-cherry-tomato-r2                 NOT OK  PANASON         AP16L5J
mt8192-asurada-spherion-r0              NOT OK  PANASON         AP15O5L
mt8183-kukui-jacuzzi-juniper-sku16      NOT OK  LGC KT0         AP16L8J
mt8173-elm-hana                         OK      Sunwoda         L18D3PG1
sc7180-trogdor-lazor-limozeen-nots-r5   NOT OK  Murata          AP18C4K
sc7180-trogdor-kingoftown               NOT OK  333-AC-0D-A     GG02047XL
rk3399-gru-kevin                        OK      SDI             4352D51

Detect if this is one of the quirky batteries during presence update, so
that hot-plugging works as expected, and if so report -ENODATA for
POWER_SUPPLY_PROP_TIME_TO_EMPTY_NOW, which removes it from uevent and
prevents throwing errors.

Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
---
Changes in v3:
- Reordered variable declarations and removed unneeded initialization
- Link to v2: https://lore.kernel.org/r/20240415-sbs-time-empty-now-error-v2-1-32d8a747e308@collabora.com

Changes in v2:
- Reworked patch to lay down and use a proper quirk infrastructure, and
  update the quirks on the presence update callback so it works properly
  even when hot-plugging different batteries
- Link to v1: https://lore.kernel.org/r/20240307-sbs-time-empty-now-error-v1-1-18d0f8702330@collabora.com
---
 drivers/power/supply/sbs-battery.c | 55 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 55 insertions(+)

diff --git a/drivers/power/supply/sbs-battery.c b/drivers/power/supply/sbs-battery.c
index a6c204c08232..2b1481b81b78 100644
--- a/drivers/power/supply/sbs-battery.c
+++ b/drivers/power/supply/sbs-battery.c
@@ -214,6 +214,7 @@ struct sbs_info {
 	struct delayed_work		work;
 	struct mutex			mode_lock;
 	u32				flags;
+	u32				quirks;
 	int				technology;
 	char				strings[NR_STRING_BUFFERS][I2C_SMBUS_BLOCK_MAX + 1];
 };
@@ -263,6 +264,54 @@ static void sbs_disable_charger_broadcasts(struct sbs_info *chip)
 		dev_dbg(&chip->client->dev, "%s\n", __func__);
 }
 
+/* Required by the spec, but missing in some implementations */
+#define SBS_QUIRK_BROKEN_TTE_NOW	BIT(0)
+
+struct sbs_quirk_entry {
+	const char *manufacturer;
+	const char *model;
+	u32 flags;
+};
+
+static const struct sbs_quirk_entry sbs_quirks[] = {
+	{"PANASON", "AP16L5J", SBS_QUIRK_BROKEN_TTE_NOW},
+	{"PANASON", "AP15O5L", SBS_QUIRK_BROKEN_TTE_NOW},
+	{"LGC KT0", "AP16L8J", SBS_QUIRK_BROKEN_TTE_NOW},
+	{"Murata", "AP18C4K", SBS_QUIRK_BROKEN_TTE_NOW},
+	{"333-AC-0D-A", "GG02047XL", SBS_QUIRK_BROKEN_TTE_NOW},
+};
+
+static const char *sbs_get_constant_string(struct sbs_info *chip,
+					   enum power_supply_property psp);
+
+static void sbs_update_quirks(struct sbs_info *chip)
+{
+	const char *manufacturer;
+	const char *model;
+	unsigned int i;
+
+	/* reset quirks from battery before the hot-plug event */
+	chip->quirks = 0;
+
+	manufacturer = sbs_get_constant_string(chip, POWER_SUPPLY_PROP_MANUFACTURER);
+	model = sbs_get_constant_string(chip, POWER_SUPPLY_PROP_MODEL_NAME);
+	if (IS_ERR(manufacturer) || IS_ERR(model)) {
+		dev_warn(&chip->client->dev, "Couldn't read manufacturer and model to set quirks\n");
+		return;
+	}
+
+	for (i = 0; i < ARRAY_SIZE(sbs_quirks); i++) {
+		if (strcmp(manufacturer, sbs_quirks[i].manufacturer))
+			continue;
+		if (strcmp(model, sbs_quirks[i].model))
+			continue;
+		chip->quirks |= sbs_quirks[i].flags;
+	}
+
+	if (chip->quirks & SBS_QUIRK_BROKEN_TTE_NOW)
+		dev_info(&chip->client->dev, "Added quirk disabling TIME_TO_EMPTY_NOW\n");
+}
+
 static int sbs_update_presence(struct sbs_info *chip, bool is_present)
 {
 	struct i2c_client *client = chip->client;
@@ -323,6 +372,8 @@ static int sbs_update_presence(struct sbs_info *chip, bool is_present)
 	dev_dbg(&client->dev, "PEC: %s\n", (client->flags & I2C_CLIENT_PEC) ?
 		"enabled" : "disabled");
 
+	sbs_update_quirks(chip);
+
 	if (!chip->is_present && is_present && !chip->charger_broadcasts)
 		sbs_disable_charger_broadcasts(chip);
 
@@ -614,6 +665,10 @@ static int sbs_get_battery_property(struct i2c_client *client,
 	struct sbs_info *chip = i2c_get_clientdata(client);
 	s32 ret;
 
+	if (psp == POWER_SUPPLY_PROP_TIME_TO_EMPTY_NOW &&
+	    chip->quirks & SBS_QUIRK_BROKEN_TTE_NOW)
+		return -ENODATA;
+
 	ret = sbs_read_word_data(client, sbs_data[reg_offset].addr);
 	if (ret < 0)
 		return ret;

---
base-commit: 7b4f2bc91c15fdcf948bb2d9741a9d7d54303f8d
change-id: 20240307-sbs-time-empty-now-error-322bc074d3f2

Best regards,
-- 
Nícolas F. R. A. Prado <nfraprado@collabora.com>


^ permalink raw reply related	[flat|nested] 8+ messages in thread

* Re: [PATCH v3] power: supply: sbs-battery: Handle unsupported PROP_TIME_TO_EMPTY_NOW
  2024-04-18 17:34 [PATCH v3] power: supply: sbs-battery: Handle unsupported PROP_TIME_TO_EMPTY_NOW Nícolas F. R. A. Prado
@ 2024-04-19  7:26 ` AngeloGioacchino Del Regno
  2024-04-19 13:25   ` Sebastian Reichel
  2024-04-19 16:03 ` Nícolas F. R. A. Prado
  1 sibling, 1 reply; 8+ messages in thread
From: AngeloGioacchino Del Regno @ 2024-04-19  7:26 UTC (permalink / raw)
  To: Nícolas F. R. A. Prado, Sebastian Reichel
  Cc: kernel, linux-pm, linux-kernel, Pin-yen Lin, Hsin-Te Yuan

Il 18/04/24 19:34, Nícolas F. R. A. Prado ha scritto:
> Despite the RunTimeToEmpty() (0x11) function being defined in the SBS
> specification as required, it seems that not all batteries implement it.
> On platforms with such batteries, reading the property will cause an
> error to be printed:
> 
> power_supply sbs-8-000b: driver failed to report `time_to_empty_now' property: -5
> 
> This not only pollutes the log, distracting from real problems on the
> device, but also prevents the uevent file from being read since it
> contains all properties, including the faulty one.
> 
> The following table summarizes the findings for a handful of platforms:
> 
> Platform                                Status  Manufacturer    Model
> ------------------------------------------------------------------------
> mt8186-corsola-steelix-sku131072        OK      BYD             L22B3PG0
> mt8195-cherry-tomato-r2                 NOT OK  PANASON         AP16L5J
> mt8192-asurada-spherion-r0              NOT OK  PANASON         AP15O5L
> mt8183-kukui-jacuzzi-juniper-sku16      NOT OK  LGC KT0         AP16L8J
> mt8173-elm-hana                         OK      Sunwoda         L18D3PG1
> sc7180-trogdor-lazor-limozeen-nots-r5   NOT OK  Murata          AP18C4K
> sc7180-trogdor-kingoftown               NOT OK  333-AC-0D-A     GG02047XL
> rk3399-gru-kevin                        OK      SDI             4352D51
> 
> Detect if this is one of the quirky batteries during presence update, so
> that hot-plugging works as expected, and if so report -ENODATA for
> POWER_SUPPLY_PROP_TIME_TO_EMPTY_NOW, which removes it from uevent and
> prevents throwing errors.
> 
> Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>

Nícolas, please, I think that sending this commit to stable for backporting
makes a lot of sense since you're actually fixing laptops (that does not
really require a Fixes tag) that are supported upstream since .. lots of time
ago.

In any case, this LGTM.

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH v3] power: supply: sbs-battery: Handle unsupported PROP_TIME_TO_EMPTY_NOW
  2024-04-19  7:26 ` AngeloGioacchino Del Regno
@ 2024-04-19 13:25   ` Sebastian Reichel
  0 siblings, 0 replies; 8+ messages in thread
From: Sebastian Reichel @ 2024-04-19 13:25 UTC (permalink / raw)
  To: AngeloGioacchino Del Regno
  Cc: Nícolas F. R. A. Prado, kernel, linux-pm, linux-kernel,
	Pin-yen Lin, Hsin-Te Yuan

[-- Attachment #1: Type: text/plain, Size: 2482 bytes --]

Hi,

On Fri, Apr 19, 2024 at 09:26:41AM +0200, AngeloGioacchino Del Regno wrote:
> Il 18/04/24 19:34, Nícolas F. R. A. Prado ha scritto:
> > Despite the RunTimeToEmpty() (0x11) function being defined in the SBS
> > specification as required, it seems that not all batteries implement it.
> > On platforms with such batteries, reading the property will cause an
> > error to be printed:
> > 
> > power_supply sbs-8-000b: driver failed to report `time_to_empty_now' property: -5
> > 
> > This not only pollutes the log, distracting from real problems on the
> > device, but also prevents the uevent file from being read since it
> > contains all properties, including the faulty one.
> > 
> > The following table summarizes the findings for a handful of platforms:
> > 
> > Platform                                Status  Manufacturer    Model
> > ------------------------------------------------------------------------
> > mt8186-corsola-steelix-sku131072        OK      BYD             L22B3PG0
> > mt8195-cherry-tomato-r2                 NOT OK  PANASON         AP16L5J
> > mt8192-asurada-spherion-r0              NOT OK  PANASON         AP15O5L
> > mt8183-kukui-jacuzzi-juniper-sku16      NOT OK  LGC KT0         AP16L8J
> > mt8173-elm-hana                         OK      Sunwoda         L18D3PG1
> > sc7180-trogdor-lazor-limozeen-nots-r5   NOT OK  Murata          AP18C4K
> > sc7180-trogdor-kingoftown               NOT OK  333-AC-0D-A     GG02047XL
> > rk3399-gru-kevin                        OK      SDI             4352D51
> > 
> > Detect if this is one of the quirky batteries during presence update, so
> > that hot-plugging works as expected, and if so report -ENODATA for
> > POWER_SUPPLY_PROP_TIME_TO_EMPTY_NOW, which removes it from uevent and
> > prevents throwing errors.
> > 
> > Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
> 
> Nícolas, please, I think that sending this commit to stable for backporting
> makes a lot of sense since you're actually fixing laptops (that does not
> really require a Fixes tag) that are supported upstream since .. lots of time
> ago.
> 
> In any case, this LGTM.
> 
> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>

Considering we have a single commit adding TTE, it should be fine to
just add a Fixes tag for that:

Fixes: 6ea0126631b0 ("power: supply: sbs-battery: add support for time_to_empty_now attribute")

-- Sebastian

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH v3] power: supply: sbs-battery: Handle unsupported PROP_TIME_TO_EMPTY_NOW
  2024-04-18 17:34 [PATCH v3] power: supply: sbs-battery: Handle unsupported PROP_TIME_TO_EMPTY_NOW Nícolas F. R. A. Prado
  2024-04-19  7:26 ` AngeloGioacchino Del Regno
@ 2024-04-19 16:03 ` Nícolas F. R. A. Prado
  2024-04-22  8:10   ` Hsin-Te Yuan
  1 sibling, 1 reply; 8+ messages in thread
From: Nícolas F. R. A. Prado @ 2024-04-19 16:03 UTC (permalink / raw)
  To: Sebastian Reichel
  Cc: kernel, linux-pm, linux-kernel, Pin-yen Lin, Hsin-Te Yuan

On Thu, Apr 18, 2024 at 01:34:23PM -0400, Nícolas F. R. A. Prado wrote:
> Despite the RunTimeToEmpty() (0x11) function being defined in the SBS
> specification as required, it seems that not all batteries implement it.
> On platforms with such batteries, reading the property will cause an
> error to be printed:
> 
> power_supply sbs-8-000b: driver failed to report `time_to_empty_now' property: -5
> 
> This not only pollutes the log, distracting from real problems on the
> device, but also prevents the uevent file from being read since it
> contains all properties, including the faulty one.
> 
> The following table summarizes the findings for a handful of platforms:
> 
> Platform                                Status  Manufacturer    Model
> ------------------------------------------------------------------------
> mt8186-corsola-steelix-sku131072        OK      BYD             L22B3PG0
> mt8195-cherry-tomato-r2                 NOT OK  PANASON         AP16L5J
> mt8192-asurada-spherion-r0              NOT OK  PANASON         AP15O5L
> mt8183-kukui-jacuzzi-juniper-sku16      NOT OK  LGC KT0         AP16L8J
> mt8173-elm-hana                         OK      Sunwoda         L18D3PG1
> sc7180-trogdor-lazor-limozeen-nots-r5   NOT OK  Murata          AP18C4K
> sc7180-trogdor-kingoftown               NOT OK  333-AC-0D-A     GG02047XL
> rk3399-gru-kevin                        OK      SDI             4352D51
> 
> Detect if this is one of the quirky batteries during presence update, so
> that hot-plugging works as expected, and if so report -ENODATA for
> POWER_SUPPLY_PROP_TIME_TO_EMPTY_NOW, which removes it from uevent and
> prevents throwing errors.
> 
> Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
> ---

Hi,

I'm coming back with more information after some more testing has been done.

Most importantly, in the meantime, a parallel investigation uncovered that the
time_to_empty_now issue was actually in the EC firmware:
https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/5465747

So the other faulty properties (which I'll mention below) could also be due to
the EC firmware. These are the EC firmware version for the platforms with
additional issues:
* RW version:    juniper_v2.0.2509-9101a0730
* RW version:    lazor_v2.0.6519-9923041f79

Hsin-Te, do you have information on whether it's an EC issue in this case as
well?

The following table shows all the faulty properties per platform:

Platform                               Manufacturer  Model      Faulty properties
---------------------------------------------------------------------------------
mt8186-corsola-steelix-sku131072       BYD           L22B3PG0   -
mt8195-cherry-tomato-r2                PANASON       AP16L5J    time_to_empty_now
mt8192-asurada-spherion-r0             PANASON       AP15O5L    time_to_empty_now
mt8183-kukui-jacuzzi-juniper-sku16     LGC KT0       AP16L8J    time_to_empty_now
                                                                capacity_error_margin
								constant_charge_current_max
								constant_charge_voltage_max
								current_avg
								technology
								manufacture_year
								manufacture_month
								manufacture_day
								SPEC_INFO
mt8173-elm-hana                        Sunwoda       L18D3PG1   -
sc7180-trogdor-lazor-limozeen-nots-r5  Murata        AP18C4K    time_to_empty_now
                                                                capacity_error_margin
								constant_charge_current_max
								constant_charge_voltage_max
								current_avg
sc7180-trogdor-kingoftown              333-AC-0D-A   GG02047XL  time_to_empty_now
rk3399-gru-kevin                       SDI           4352D51    -

If it turns out to not be an EC issue for the properties other than the
time_to_empty_now, then quirks will need to be added for them. As for SPEC_INFO
it's fine to keep it the way it is, as it already fails gracefully by falling
back to disabled PEC. However it does mean sbs_update_quirks() would need to be
moved up in sbs_update_presence(), or it will never run when SPEC_INFO fails.

Also, the battery vendor for limozeen is actually "Murata ", with a trailing
space...

While at it, I also tested whether PEC was broken on all platforms (which have
the SBS battery behind the EC I2C tunnel) to see if it could have any relation
with the faulty properties:

					                        PEC
Platform                               Manufacturer  Model      Status
------------------------------------------------------------------------
mt8186-corsola-steelix-sku131072       BYD           L22B3PG0   NOT SUPPORTED
mt8195-cherry-tomato-r2                PANASON       AP16L5J    NOT SUPPORTED
mt8192-asurada-spherion-r0             PANASON       AP15O5L    NOT SUPPORTED
mt8183-kukui-jacuzzi-juniper-sku16     LGC KT0       AP16L8J    NOT SUPPORTED
mt8173-elm-hana                        Sunwoda       L18D3PG1   BROKEN
sc7180-trogdor-lazor-limozeen-nots-r5  Murata        AP18C4K    NOT SUPPORTED
sc7180-trogdor-kingoftown              333-AC-0D-A   GG02047XL  NOT SUPPORTED
rk3399-gru-kevin                       SDI           4352D51    BROKEN

Where on the platforms marked BROKEN all properties would fail like so:
power_supply sbs-9-000b: driver failed to report `status' property: -74

Those platforms indeed had PEC enabled:
<6>[   18.109211] sbs-battery 9-000b: PEC: enabled

and I verified the reported SBS version was SBS_VERSION_1_1_WITH_PEC.

Meanwhile, all the other platforms, marked NOT SUPPORTED, didn't actually have
PEC enabled:
<6>[   14.563070] sbs-battery 8-000b: PEC: disabled

which I verified was due to version SBS_VERSION_1_0 being reported (except for
jacuzzi, which fails to report a version).

So all platforms that had batteries that support PEC, have broken PEC, but most
don't support it. In any case there doesn't seem to be a correlation with the
properties that the batteries support, so it looks to be an orthogonal issue.

Thanks,
Nícolas

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH v3] power: supply: sbs-battery: Handle unsupported PROP_TIME_TO_EMPTY_NOW
  2024-04-19 16:03 ` Nícolas F. R. A. Prado
@ 2024-04-22  8:10   ` Hsin-Te Yuan
  2024-05-09 15:25     ` Nícolas F. R. A. Prado
  0 siblings, 1 reply; 8+ messages in thread
From: Hsin-Te Yuan @ 2024-04-22  8:10 UTC (permalink / raw)
  To: Nícolas F. R. A. Prado
  Cc: Sebastian Reichel, kernel, linux-pm, linux-kernel, Pin-yen Lin,
	Hsin-Te Yuan

On Sat, Apr 20, 2024 at 12:03 AM Nícolas F. R. A. Prado
<nfraprado@collabora.com> wrote:
>
> On Thu, Apr 18, 2024 at 01:34:23PM -0400, Nícolas F. R. A. Prado wrote:
> > Despite the RunTimeToEmpty() (0x11) function being defined in the SBS
> > specification as required, it seems that not all batteries implement it.
> > On platforms with such batteries, reading the property will cause an
> > error to be printed:
> >
> > power_supply sbs-8-000b: driver failed to report `time_to_empty_now' property: -5
> >
> > This not only pollutes the log, distracting from real problems on the
> > device, but also prevents the uevent file from being read since it
> > contains all properties, including the faulty one.
> >
> > The following table summarizes the findings for a handful of platforms:
> >
> > Platform                                Status  Manufacturer    Model
> > ------------------------------------------------------------------------
> > mt8186-corsola-steelix-sku131072        OK      BYD             L22B3PG0
> > mt8195-cherry-tomato-r2                 NOT OK  PANASON         AP16L5J
> > mt8192-asurada-spherion-r0              NOT OK  PANASON         AP15O5L
> > mt8183-kukui-jacuzzi-juniper-sku16      NOT OK  LGC KT0         AP16L8J
> > mt8173-elm-hana                         OK      Sunwoda         L18D3PG1
> > sc7180-trogdor-lazor-limozeen-nots-r5   NOT OK  Murata          AP18C4K
> > sc7180-trogdor-kingoftown               NOT OK  333-AC-0D-A     GG02047XL
> > rk3399-gru-kevin                        OK      SDI             4352D51
> >
> > Detect if this is one of the quirky batteries during presence update, so
> > that hot-plugging works as expected, and if so report -ENODATA for
> > POWER_SUPPLY_PROP_TIME_TO_EMPTY_NOW, which removes it from uevent and
> > prevents throwing errors.
> >
> > Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
> > ---
>
> Hi,
>
> I'm coming back with more information after some more testing has been done.
>
> Most importantly, in the meantime, a parallel investigation uncovered that the
> time_to_empty_now issue was actually in the EC firmware:
> https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/5465747
>
> So the other faulty properties (which I'll mention below) could also be due to
> the EC firmware. These are the EC firmware version for the platforms with
> additional issues:
> * RW version:    juniper_v2.0.2509-9101a0730
> * RW version:    lazor_v2.0.6519-9923041f79
>
> Hsin-Te, do you have information on whether it's an EC issue in this case as
> well?
>
> The following table shows all the faulty properties per platform:
>
> Platform                               Manufacturer  Model      Faulty properties
> ---------------------------------------------------------------------------------
> mt8186-corsola-steelix-sku131072       BYD           L22B3PG0   -
> mt8195-cherry-tomato-r2                PANASON       AP16L5J    time_to_empty_now
> mt8192-asurada-spherion-r0             PANASON       AP15O5L    time_to_empty_now
> mt8183-kukui-jacuzzi-juniper-sku16     LGC KT0       AP16L8J    time_to_empty_now
>                                                                 capacity_error_margin
>                                                                 constant_charge_current_max
>                                                                 constant_charge_voltage_max
>                                                                 current_avg
>                                                                 technology
>                                                                 manufacture_year
>                                                                 manufacture_month
>                                                                 manufacture_day
>                                                                 SPEC_INFO
> mt8173-elm-hana                        Sunwoda       L18D3PG1   -
> sc7180-trogdor-lazor-limozeen-nots-r5  Murata        AP18C4K    time_to_empty_now
>                                                                 capacity_error_margin
>                                                                 constant_charge_current_max
>                                                                 constant_charge_voltage_max
>                                                                 current_avg
> sc7180-trogdor-kingoftown              333-AC-0D-A   GG02047XL  time_to_empty_now
> rk3399-gru-kevin                       SDI           4352D51    -
>
> If it turns out to not be an EC issue for the properties other than the
> time_to_empty_now, then quirks will need to be added for them. As for SPEC_INFO
> it's fine to keep it the way it is, as it already fails gracefully by falling
> back to disabled PEC. However it does mean sbs_update_quirks() would need to be
> moved up in sbs_update_presence(), or it will never run when SPEC_INFO fails.
>
> Also, the battery vendor for limozeen is actually "Murata ", with a trailing
> space...
>
> While at it, I also tested whether PEC was broken on all platforms (which have
> the SBS battery behind the EC I2C tunnel) to see if it could have any relation
> with the faulty properties:
>
>                                                                 PEC
> Platform                               Manufacturer  Model      Status
> ------------------------------------------------------------------------
> mt8186-corsola-steelix-sku131072       BYD           L22B3PG0   NOT SUPPORTED
> mt8195-cherry-tomato-r2                PANASON       AP16L5J    NOT SUPPORTED
> mt8192-asurada-spherion-r0             PANASON       AP15O5L    NOT SUPPORTED
> mt8183-kukui-jacuzzi-juniper-sku16     LGC KT0       AP16L8J    NOT SUPPORTED
> mt8173-elm-hana                        Sunwoda       L18D3PG1   BROKEN
> sc7180-trogdor-lazor-limozeen-nots-r5  Murata        AP18C4K    NOT SUPPORTED
> sc7180-trogdor-kingoftown              333-AC-0D-A   GG02047XL  NOT SUPPORTED
> rk3399-gru-kevin                       SDI           4352D51    BROKEN
>
> Where on the platforms marked BROKEN all properties would fail like so:
> power_supply sbs-9-000b: driver failed to report `status' property: -74
>
> Those platforms indeed had PEC enabled:
> <6>[   18.109211] sbs-battery 9-000b: PEC: enabled
>
> and I verified the reported SBS version was SBS_VERSION_1_1_WITH_PEC.
>
> Meanwhile, all the other platforms, marked NOT SUPPORTED, didn't actually have
> PEC enabled:
> <6>[   14.563070] sbs-battery 8-000b: PEC: disabled
>
> which I verified was due to version SBS_VERSION_1_0 being reported (except for
> jacuzzi, which fails to report a version).
>
> So all platforms that had batteries that support PEC, have broken PEC, but most
> don't support it. In any case there doesn't seem to be a correlation with the
> properties that the batteries support, so it looks to be an orthogonal issue.
>
> Thanks,
> Nícolas

It looks like the firmware version of juniper is too old. Could you
update the firmware and test it again?
Also, Could you provide the error you get from lazor?

Regards,
Hsin-Te

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH v3] power: supply: sbs-battery: Handle unsupported PROP_TIME_TO_EMPTY_NOW
  2024-04-22  8:10   ` Hsin-Te Yuan
@ 2024-05-09 15:25     ` Nícolas F. R. A. Prado
  2024-05-09 15:43       ` AngeloGioacchino Del Regno
  0 siblings, 1 reply; 8+ messages in thread
From: Nícolas F. R. A. Prado @ 2024-05-09 15:25 UTC (permalink / raw)
  To: Hsin-Te Yuan
  Cc: Sebastian Reichel, kernel, linux-pm, linux-kernel, Pin-yen Lin

On Mon, Apr 22, 2024 at 04:10:23PM +0800, Hsin-Te Yuan wrote:
> On Sat, Apr 20, 2024 at 12:03 AM Nícolas F. R. A. Prado
> <nfraprado@collabora.com> wrote:
> >
> > On Thu, Apr 18, 2024 at 01:34:23PM -0400, Nícolas F. R. A. Prado wrote:
> > > Despite the RunTimeToEmpty() (0x11) function being defined in the SBS
> > > specification as required, it seems that not all batteries implement it.
> > > On platforms with such batteries, reading the property will cause an
> > > error to be printed:
> > >
> > > power_supply sbs-8-000b: driver failed to report `time_to_empty_now' property: -5
> > >
> > > This not only pollutes the log, distracting from real problems on the
> > > device, but also prevents the uevent file from being read since it
> > > contains all properties, including the faulty one.
> > >
> > > The following table summarizes the findings for a handful of platforms:
> > >
> > > Platform                                Status  Manufacturer    Model
> > > ------------------------------------------------------------------------
> > > mt8186-corsola-steelix-sku131072        OK      BYD             L22B3PG0
> > > mt8195-cherry-tomato-r2                 NOT OK  PANASON         AP16L5J
> > > mt8192-asurada-spherion-r0              NOT OK  PANASON         AP15O5L
> > > mt8183-kukui-jacuzzi-juniper-sku16      NOT OK  LGC KT0         AP16L8J
> > > mt8173-elm-hana                         OK      Sunwoda         L18D3PG1
> > > sc7180-trogdor-lazor-limozeen-nots-r5   NOT OK  Murata          AP18C4K
> > > sc7180-trogdor-kingoftown               NOT OK  333-AC-0D-A     GG02047XL
> > > rk3399-gru-kevin                        OK      SDI             4352D51
> > >
> > > Detect if this is one of the quirky batteries during presence update, so
> > > that hot-plugging works as expected, and if so report -ENODATA for
> > > POWER_SUPPLY_PROP_TIME_TO_EMPTY_NOW, which removes it from uevent and
> > > prevents throwing errors.
> > >
> > > Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
> > > ---
> >
> > Hi,
> >
> > I'm coming back with more information after some more testing has been done.
> >
> > Most importantly, in the meantime, a parallel investigation uncovered that the
> > time_to_empty_now issue was actually in the EC firmware:
> > https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/5465747
> >
> > So the other faulty properties (which I'll mention below) could also be due to
> > the EC firmware. These are the EC firmware version for the platforms with
> > additional issues:
> > * RW version:    juniper_v2.0.2509-9101a0730
> > * RW version:    lazor_v2.0.6519-9923041f79
> >
> > Hsin-Te, do you have information on whether it's an EC issue in this case as
> > well?
> >
> > The following table shows all the faulty properties per platform:
> >
> > Platform                               Manufacturer  Model      Faulty properties
> > ---------------------------------------------------------------------------------
> > mt8186-corsola-steelix-sku131072       BYD           L22B3PG0   -
> > mt8195-cherry-tomato-r2                PANASON       AP16L5J    time_to_empty_now
> > mt8192-asurada-spherion-r0             PANASON       AP15O5L    time_to_empty_now
> > mt8183-kukui-jacuzzi-juniper-sku16     LGC KT0       AP16L8J    time_to_empty_now
> >                                                                 capacity_error_margin
> >                                                                 constant_charge_current_max
> >                                                                 constant_charge_voltage_max
> >                                                                 current_avg
> >                                                                 technology
> >                                                                 manufacture_year
> >                                                                 manufacture_month
> >                                                                 manufacture_day
> >                                                                 SPEC_INFO
> > mt8173-elm-hana                        Sunwoda       L18D3PG1   -
> > sc7180-trogdor-lazor-limozeen-nots-r5  Murata        AP18C4K    time_to_empty_now
> >                                                                 capacity_error_margin
> >                                                                 constant_charge_current_max
> >                                                                 constant_charge_voltage_max
> >                                                                 current_avg
> > sc7180-trogdor-kingoftown              333-AC-0D-A   GG02047XL  time_to_empty_now
> > rk3399-gru-kevin                       SDI           4352D51    -
> >
[..]
> 
> It looks like the firmware version of juniper is too old. Could you
> update the firmware and test it again?
> Also, Could you provide the error you get from lazor?

Getting back on this, we were finally able to update the EC firmware for both
juniper and limozeen and all the issues were fixed. I have added the logs below
just for reference. So I guess the only change we could have upstream would be a
message suggesting the user to update the EC firmware in case the SBS is behind
the CrosEC and it starts throwing errors. I'll prepare a patch for that.

Thanks,
Nícolas

limozeen:
+ cat /sys/class/power_supply/sbs-12-000b/time_to_empty_now
3932100
+ cat /sys/class/power_supply/sbs-12-000b/capacity_error_margin
3
+ cat /sys/class/power_supply/sbs-12-000b/constant_charge_current_max
0
+ cat /sys/class/power_supply/sbs-12-000b/constant_charge_voltage_max
0
+ cat /sys/class/power_supply/sbs-12-000b/current_avg
0
+ cat /sys/class/power_supply/sbs-12-000b/uevent
DEVTYPE=power_supply
OF_NAME=sbs-battery
OF_FULLNAME=/soc@0/geniqup@ac0000/spi@a80000/ec@0/i2c-tunnel/sbs-battery@b
OF_COMPATIBLE_0=sbs,sbs-battery
OF_COMPATIBLE_N=1
POWER_SUPPLY_NAME=sbs-12-000b
POWER_SUPPLY_TYPE=Battery
POWER_SUPPLY_STATUS=Full
POWER_SUPPLY_CAPACITY_LEVEL=Full
POWER_SUPPLY_HEALTH=Unknown
POWER_SUPPLY_PRESENT=1
POWER_SUPPLY_TECHNOLOGY=Li-poly
POWER_SUPPLY_CYCLE_COUNT=2
POWER_SUPPLY_VOLTAGE_NOW=12293000
POWER_SUPPLY_CURRENT_NOW=0
POWER_SUPPLY_CURRENT_AVG=0
POWER_SUPPLY_CAPACITY=97
POWER_SUPPLY_CAPACITY_ERROR_MARGIN=3
POWER_SUPPLY_TEMP=194
POWER_SUPPLY_TIME_TO_EMPTY_NOW=3932100
POWER_SUPPLY_TIME_TO_EMPTY_AVG=3932100
POWER_SUPPLY_TIME_TO_FULL_AVG=3932100
POWER_SUPPLY_SERIAL_NUMBER=023e
POWER_SUPPLY_VOLTAGE_MIN_DESIGN=11400000
POWER_SUPPLY_VOLTAGE_MAX_DESIGN=11400000
POWER_SUPPLY_ENERGY_NOW=42420000
POWER_SUPPLY_ENERGY_FULL=43700000
POWER_SUPPLY_ENERGY_FULL_DESIGN=51630000
POWER_SUPPLY_CHARGE_NOW=3451000
POWER_SUPPLY_CHARGE_FULL=3555000
POWER_SUPPLY_CHARGE_FULL_DESIGN=4200000
POWER_SUPPLY_CONSTANT_CHARGE_CURRENT_MAX=0
POWER_SUPPLY_CONSTANT_CHARGE_VOLTAGE_MAX=0
POWER_SUPPLY_MANUFACTURE_YEAR=2021
POWER_SUPPLY_MANUFACTURE_MONTH=3
POWER_SUPPLY_MANUFACTURE_DAY=14
POWER_SUPPLY_MANUFACTURER=Murata KT00304012
POWER_SUPPLY_MODEL_NAME=AP18C4K
+ cat /sys/class/chromeos/cros_ec/version
RO version:    lazor_v2.0.23149-099cd3e539
RW version:    lazor_v2.0.23149-099cd3e539

juniper:
+ cat /sys/class/power_supply/sbs-12-000b/time_to_empty_now
3932100
+ cat /sys/class/power_supply/sbs-12-000b/capacity_error_margin
3
+ cat /sys/class/power_supply/sbs-12-000b/constant_charge_current_max
0
+ cat /sys/class/power_supply/sbs-12-000b/constant_charge_voltage_max
0
+ cat /sys/class/power_supply/sbs-12-000b/current_avg
0
+ cat /sys/class/power_supply/sbs-12-000b/technology
Li-ion
+ cat /sys/class/power_supply/sbs-12-000b/manufacture_year
2020
+ cat /sys/class/power_supply/sbs-12-000b/manufacture_month
10
+ cat /sys/class/power_supply/sbs-12-000b/manufacture_day
7
+ cat /sys/class/power_supply/sbs-12-000b/uevent
DEVTYPE=power_supply
OF_NAME=sbs-battery
OF_FULLNAME=/soc/spi@11012000/cros-ec@0/i2c-tunnel/sbs-battery@b
OF_COMPATIBLE_0=sbs,sbs-battery
OF_COMPATIBLE_N=1
POWER_SUPPLY_NAME=sbs-12-000b
POWER_SUPPLY_TYPE=Battery
POWER_SUPPLY_STATUS=Full
POWER_SUPPLY_CAPACITY_LEVEL=Full
POWER_SUPPLY_HEALTH=Unknown
POWER_SUPPLY_PRESENT=1
POWER_SUPPLY_TECHNOLOGY=Li-ion
POWER_SUPPLY_CYCLE_COUNT=8
POWER_SUPPLY_VOLTAGE_NOW=8210000
POWER_SUPPLY_CURRENT_NOW=0
POWER_SUPPLY_CURRENT_AVG=0
POWER_SUPPLY_CAPACITY=99
POWER_SUPPLY_CAPACITY_ERROR_MARGIN=3
POWER_SUPPLY_TEMP=215
POWER_SUPPLY_TIME_TO_EMPTY_NOW=3932100
POWER_SUPPLY_TIME_TO_EMPTY_AVG=3932100
POWER_SUPPLY_TIME_TO_FULL_AVG=3932100
POWER_SUPPLY_SERIAL_NUMBER=26c9
POWER_SUPPLY_VOLTAGE_MIN_DESIGN=7500000
POWER_SUPPLY_VOLTAGE_MAX_DESIGN=7500000
POWER_SUPPLY_ENERGY_NOW=34990000
POWER_SUPPLY_ENERGY_FULL=35170000
POWER_SUPPLY_ENERGY_FULL_DESIGN=39940000
POWER_SUPPLY_CHARGE_NOW=4262000
POWER_SUPPLY_CHARGE_FULL=4284000
POWER_SUPPLY_CHARGE_FULL_DESIGN=4865000
POWER_SUPPLY_CONSTANT_CHARGE_CURRENT_MAX=0
POWER_SUPPLY_CONSTANT_CHARGE_VOLTAGE_MAX=0
POWER_SUPPLY_MANUFACTURE_YEAR=2020
POWER_SUPPLY_MANUFACTURE_MONTH=10
POWER_SUPPLY_MANUFACTURE_DAY=7
POWER_SUPPLY_MANUFACTURER=LGC KT0
POWER_SUPPLY_MODEL_NAME=AP16L8J
+ cat /sys/class/chromeos/cros_ec/version
RO version:    juniper_v2.0.2796-7246101293
RW version:    juniper_v2.0.2796-7246101293

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH v3] power: supply: sbs-battery: Handle unsupported PROP_TIME_TO_EMPTY_NOW
  2024-05-09 15:25     ` Nícolas F. R. A. Prado
@ 2024-05-09 15:43       ` AngeloGioacchino Del Regno
  2024-05-13 13:27         ` Nícolas F. R. A. Prado
  0 siblings, 1 reply; 8+ messages in thread
From: AngeloGioacchino Del Regno @ 2024-05-09 15:43 UTC (permalink / raw)
  To: Nícolas F. R. A. Prado, Hsin-Te Yuan
  Cc: Sebastian Reichel, kernel, linux-pm, linux-kernel, Pin-yen Lin

Il 09/05/24 17:25, Nícolas F. R. A. Prado ha scritto:
> On Mon, Apr 22, 2024 at 04:10:23PM +0800, Hsin-Te Yuan wrote:
>> On Sat, Apr 20, 2024 at 12:03 AM Nícolas F. R. A. Prado
>> <nfraprado@collabora.com> wrote:
>>>
>>> On Thu, Apr 18, 2024 at 01:34:23PM -0400, Nícolas F. R. A. Prado wrote:
>>>> Despite the RunTimeToEmpty() (0x11) function being defined in the SBS
>>>> specification as required, it seems that not all batteries implement it.
>>>> On platforms with such batteries, reading the property will cause an
>>>> error to be printed:
>>>>
>>>> power_supply sbs-8-000b: driver failed to report `time_to_empty_now' property: -5
>>>>
>>>> This not only pollutes the log, distracting from real problems on the
>>>> device, but also prevents the uevent file from being read since it
>>>> contains all properties, including the faulty one.
>>>>
>>>> The following table summarizes the findings for a handful of platforms:
>>>>
>>>> Platform                                Status  Manufacturer    Model
>>>> ------------------------------------------------------------------------
>>>> mt8186-corsola-steelix-sku131072        OK      BYD             L22B3PG0
>>>> mt8195-cherry-tomato-r2                 NOT OK  PANASON         AP16L5J
>>>> mt8192-asurada-spherion-r0              NOT OK  PANASON         AP15O5L
>>>> mt8183-kukui-jacuzzi-juniper-sku16      NOT OK  LGC KT0         AP16L8J
>>>> mt8173-elm-hana                         OK      Sunwoda         L18D3PG1
>>>> sc7180-trogdor-lazor-limozeen-nots-r5   NOT OK  Murata          AP18C4K
>>>> sc7180-trogdor-kingoftown               NOT OK  333-AC-0D-A     GG02047XL
>>>> rk3399-gru-kevin                        OK      SDI             4352D51
>>>>
>>>> Detect if this is one of the quirky batteries during presence update, so
>>>> that hot-plugging works as expected, and if so report -ENODATA for
>>>> POWER_SUPPLY_PROP_TIME_TO_EMPTY_NOW, which removes it from uevent and
>>>> prevents throwing errors.
>>>>
>>>> Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
>>>> ---
>>>
>>> Hi,
>>>
>>> I'm coming back with more information after some more testing has been done.
>>>
>>> Most importantly, in the meantime, a parallel investigation uncovered that the
>>> time_to_empty_now issue was actually in the EC firmware:
>>> https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/5465747
>>>
>>> So the other faulty properties (which I'll mention below) could also be due to
>>> the EC firmware. These are the EC firmware version for the platforms with
>>> additional issues:
>>> * RW version:    juniper_v2.0.2509-9101a0730
>>> * RW version:    lazor_v2.0.6519-9923041f79
>>>
>>> Hsin-Te, do you have information on whether it's an EC issue in this case as
>>> well?
>>>
>>> The following table shows all the faulty properties per platform:
>>>
>>> Platform                               Manufacturer  Model      Faulty properties
>>> ---------------------------------------------------------------------------------
>>> mt8186-corsola-steelix-sku131072       BYD           L22B3PG0   -
>>> mt8195-cherry-tomato-r2                PANASON       AP16L5J    time_to_empty_now
>>> mt8192-asurada-spherion-r0             PANASON       AP15O5L    time_to_empty_now
>>> mt8183-kukui-jacuzzi-juniper-sku16     LGC KT0       AP16L8J    time_to_empty_now
>>>                                                                  capacity_error_margin
>>>                                                                  constant_charge_current_max
>>>                                                                  constant_charge_voltage_max
>>>                                                                  current_avg
>>>                                                                  technology
>>>                                                                  manufacture_year
>>>                                                                  manufacture_month
>>>                                                                  manufacture_day
>>>                                                                  SPEC_INFO
>>> mt8173-elm-hana                        Sunwoda       L18D3PG1   -
>>> sc7180-trogdor-lazor-limozeen-nots-r5  Murata        AP18C4K    time_to_empty_now
>>>                                                                  capacity_error_margin
>>>                                                                  constant_charge_current_max
>>>                                                                  constant_charge_voltage_max
>>>                                                                  current_avg
>>> sc7180-trogdor-kingoftown              333-AC-0D-A   GG02047XL  time_to_empty_now
>>> rk3399-gru-kevin                       SDI           4352D51    -
>>>
> [..]
>>
>> It looks like the firmware version of juniper is too old. Could you
>> update the firmware and test it again?
>> Also, Could you provide the error you get from lazor?
> 
> Getting back on this, we were finally able to update the EC firmware for both
> juniper and limozeen and all the issues were fixed. I have added the logs below
> just for reference. So I guess the only change we could have upstream would be a
> message suggesting the user to update the EC firmware in case the SBS is behind
> the CrosEC and it starts throwing errors. I'll prepare a patch for that.
> 

...yes, but then you can't do that in the sbs-battery driver, but rather in the
CrOS EC - so you'd have to link this and the other driver (beware: I'm not
proposing to do that!), which wouldn't be the cleanest of options.

Perhaps we could check "how many times *in a row, from boot*" the readout is
failing and dynamically add the quirk with a big pr_warn().

I guess that could work but, at the same time, that's code to engineer very
carefully, or we'd risk breaking machines that would get that reading to work,
for example, only after a suspend-resume cycle (which is bad, yes, but still)
or other oddities...

Any other ideas?

Cheers,
Angelo


> Thanks,
> Nícolas
> 
> limozeen:
> + cat /sys/class/power_supply/sbs-12-000b/time_to_empty_now
> 3932100
> + cat /sys/class/power_supply/sbs-12-000b/capacity_error_margin
> 3
> + cat /sys/class/power_supply/sbs-12-000b/constant_charge_current_max
> 0
> + cat /sys/class/power_supply/sbs-12-000b/constant_charge_voltage_max
> 0
> + cat /sys/class/power_supply/sbs-12-000b/current_avg
> 0
> + cat /sys/class/power_supply/sbs-12-000b/uevent
> DEVTYPE=power_supply
> OF_NAME=sbs-battery
> OF_FULLNAME=/soc@0/geniqup@ac0000/spi@a80000/ec@0/i2c-tunnel/sbs-battery@b
> OF_COMPATIBLE_0=sbs,sbs-battery
> OF_COMPATIBLE_N=1
> POWER_SUPPLY_NAME=sbs-12-000b
> POWER_SUPPLY_TYPE=Battery
> POWER_SUPPLY_STATUS=Full
> POWER_SUPPLY_CAPACITY_LEVEL=Full
> POWER_SUPPLY_HEALTH=Unknown
> POWER_SUPPLY_PRESENT=1
> POWER_SUPPLY_TECHNOLOGY=Li-poly
> POWER_SUPPLY_CYCLE_COUNT=2
> POWER_SUPPLY_VOLTAGE_NOW=12293000
> POWER_SUPPLY_CURRENT_NOW=0
> POWER_SUPPLY_CURRENT_AVG=0
> POWER_SUPPLY_CAPACITY=97
> POWER_SUPPLY_CAPACITY_ERROR_MARGIN=3
> POWER_SUPPLY_TEMP=194
> POWER_SUPPLY_TIME_TO_EMPTY_NOW=3932100
> POWER_SUPPLY_TIME_TO_EMPTY_AVG=3932100
> POWER_SUPPLY_TIME_TO_FULL_AVG=3932100
> POWER_SUPPLY_SERIAL_NUMBER=023e
> POWER_SUPPLY_VOLTAGE_MIN_DESIGN=11400000
> POWER_SUPPLY_VOLTAGE_MAX_DESIGN=11400000
> POWER_SUPPLY_ENERGY_NOW=42420000
> POWER_SUPPLY_ENERGY_FULL=43700000
> POWER_SUPPLY_ENERGY_FULL_DESIGN=51630000
> POWER_SUPPLY_CHARGE_NOW=3451000
> POWER_SUPPLY_CHARGE_FULL=3555000
> POWER_SUPPLY_CHARGE_FULL_DESIGN=4200000
> POWER_SUPPLY_CONSTANT_CHARGE_CURRENT_MAX=0
> POWER_SUPPLY_CONSTANT_CHARGE_VOLTAGE_MAX=0
> POWER_SUPPLY_MANUFACTURE_YEAR=2021
> POWER_SUPPLY_MANUFACTURE_MONTH=3
> POWER_SUPPLY_MANUFACTURE_DAY=14
> POWER_SUPPLY_MANUFACTURER=Murata KT00304012
> POWER_SUPPLY_MODEL_NAME=AP18C4K
> + cat /sys/class/chromeos/cros_ec/version
> RO version:    lazor_v2.0.23149-099cd3e539
> RW version:    lazor_v2.0.23149-099cd3e539
> 
> juniper:
> + cat /sys/class/power_supply/sbs-12-000b/time_to_empty_now
> 3932100
> + cat /sys/class/power_supply/sbs-12-000b/capacity_error_margin
> 3
> + cat /sys/class/power_supply/sbs-12-000b/constant_charge_current_max
> 0
> + cat /sys/class/power_supply/sbs-12-000b/constant_charge_voltage_max
> 0
> + cat /sys/class/power_supply/sbs-12-000b/current_avg
> 0
> + cat /sys/class/power_supply/sbs-12-000b/technology
> Li-ion
> + cat /sys/class/power_supply/sbs-12-000b/manufacture_year
> 2020
> + cat /sys/class/power_supply/sbs-12-000b/manufacture_month
> 10
> + cat /sys/class/power_supply/sbs-12-000b/manufacture_day
> 7
> + cat /sys/class/power_supply/sbs-12-000b/uevent
> DEVTYPE=power_supply
> OF_NAME=sbs-battery
> OF_FULLNAME=/soc/spi@11012000/cros-ec@0/i2c-tunnel/sbs-battery@b
> OF_COMPATIBLE_0=sbs,sbs-battery
> OF_COMPATIBLE_N=1
> POWER_SUPPLY_NAME=sbs-12-000b
> POWER_SUPPLY_TYPE=Battery
> POWER_SUPPLY_STATUS=Full
> POWER_SUPPLY_CAPACITY_LEVEL=Full
> POWER_SUPPLY_HEALTH=Unknown
> POWER_SUPPLY_PRESENT=1
> POWER_SUPPLY_TECHNOLOGY=Li-ion
> POWER_SUPPLY_CYCLE_COUNT=8
> POWER_SUPPLY_VOLTAGE_NOW=8210000
> POWER_SUPPLY_CURRENT_NOW=0
> POWER_SUPPLY_CURRENT_AVG=0
> POWER_SUPPLY_CAPACITY=99
> POWER_SUPPLY_CAPACITY_ERROR_MARGIN=3
> POWER_SUPPLY_TEMP=215
> POWER_SUPPLY_TIME_TO_EMPTY_NOW=3932100
> POWER_SUPPLY_TIME_TO_EMPTY_AVG=3932100
> POWER_SUPPLY_TIME_TO_FULL_AVG=3932100
> POWER_SUPPLY_SERIAL_NUMBER=26c9
> POWER_SUPPLY_VOLTAGE_MIN_DESIGN=7500000
> POWER_SUPPLY_VOLTAGE_MAX_DESIGN=7500000
> POWER_SUPPLY_ENERGY_NOW=34990000
> POWER_SUPPLY_ENERGY_FULL=35170000
> POWER_SUPPLY_ENERGY_FULL_DESIGN=39940000
> POWER_SUPPLY_CHARGE_NOW=4262000
> POWER_SUPPLY_CHARGE_FULL=4284000
> POWER_SUPPLY_CHARGE_FULL_DESIGN=4865000
> POWER_SUPPLY_CONSTANT_CHARGE_CURRENT_MAX=0
> POWER_SUPPLY_CONSTANT_CHARGE_VOLTAGE_MAX=0
> POWER_SUPPLY_MANUFACTURE_YEAR=2020
> POWER_SUPPLY_MANUFACTURE_MONTH=10
> POWER_SUPPLY_MANUFACTURE_DAY=7
> POWER_SUPPLY_MANUFACTURER=LGC KT0
> POWER_SUPPLY_MODEL_NAME=AP16L8J
> + cat /sys/class/chromeos/cros_ec/version
> RO version:    juniper_v2.0.2796-7246101293
> RW version:    juniper_v2.0.2796-7246101293
> _______________________________________________

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH v3] power: supply: sbs-battery: Handle unsupported PROP_TIME_TO_EMPTY_NOW
  2024-05-09 15:43       ` AngeloGioacchino Del Regno
@ 2024-05-13 13:27         ` Nícolas F. R. A. Prado
  0 siblings, 0 replies; 8+ messages in thread
From: Nícolas F. R. A. Prado @ 2024-05-13 13:27 UTC (permalink / raw)
  To: AngeloGioacchino Del Regno
  Cc: Hsin-Te Yuan, Sebastian Reichel, kernel, linux-pm, linux-kernel,
	Pin-yen Lin

On Thu, May 09, 2024 at 05:43:42PM +0200, AngeloGioacchino Del Regno wrote:
> Il 09/05/24 17:25, Nícolas F. R. A. Prado ha scritto:
> > On Mon, Apr 22, 2024 at 04:10:23PM +0800, Hsin-Te Yuan wrote:
> > > On Sat, Apr 20, 2024 at 12:03 AM Nícolas F. R. A. Prado
> > > <nfraprado@collabora.com> wrote:
> > > > 
> > > > On Thu, Apr 18, 2024 at 01:34:23PM -0400, Nícolas F. R. A. Prado wrote:
[..]
> > 
> > Getting back on this, we were finally able to update the EC firmware for both
> > juniper and limozeen and all the issues were fixed. I have added the logs below
> > just for reference. So I guess the only change we could have upstream would be a
> > message suggesting the user to update the EC firmware in case the SBS is behind
> > the CrosEC and it starts throwing errors. I'll prepare a patch for that.
> > 
> 
> ...yes, but then you can't do that in the sbs-battery driver, but rather in the
> CrOS EC - so you'd have to link this and the other driver (beware: I'm not
> proposing to do that!), which wouldn't be the cleanest of options.

I *was* actually thinking of adding the log in the sbs driver by checking the
parent's compatible, since that's already done elsewhere in that driver to
disable PEC:

	if (of_device_is_compatible(client->dev.parent->of_node, "google,cros-ec-i2c-tunnel")

But now that you mention it, indeed if we're only printing a warning, it would
be best to do it in the EC i2c tunnel driver. And that's all that I'm proposing
to do: log a warning telling the user to update their EC firmware, as that
should fix the readouts, and not add any quirk to the driver.

Thanks,
Nícolas

> 
> Perhaps we could check "how many times *in a row, from boot*" the readout is
> failing and dynamically add the quirk with a big pr_warn().
> 
> I guess that could work but, at the same time, that's code to engineer very
> carefully, or we'd risk breaking machines that would get that reading to work,
> for example, only after a suspend-resume cycle (which is bad, yes, but still)
> or other oddities...
> 
> Any other ideas?
> 
> Cheers,
> Angelo

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2024-05-13 13:27 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-04-18 17:34 [PATCH v3] power: supply: sbs-battery: Handle unsupported PROP_TIME_TO_EMPTY_NOW Nícolas F. R. A. Prado
2024-04-19  7:26 ` AngeloGioacchino Del Regno
2024-04-19 13:25   ` Sebastian Reichel
2024-04-19 16:03 ` Nícolas F. R. A. Prado
2024-04-22  8:10   ` Hsin-Te Yuan
2024-05-09 15:25     ` Nícolas F. R. A. Prado
2024-05-09 15:43       ` AngeloGioacchino Del Regno
2024-05-13 13:27         ` Nícolas F. R. A. Prado

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.