devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakob Hauser <jahau@rocketmail.com>
To: Sebastian Reichel <sre@kernel.org>
Cc: Lee Jones <lee@kernel.org>, Liam Girdwood <lgirdwood@gmail.com>,
	Mark Brown <broonie@kernel.org>, Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Beomho Seo <beomho.seo@samsung.com>,
	Chanwoo Choi <cw00.choi@samsung.com>,
	Stephan Gerhold <stephan@gerhold.net>,
	Raymond Hackley <raymondhackley@protonmail.com>,
	Pavel Machek <pavel@ucw.cz>, Axel Lin <axel.lin@ingics.com>,
	ChiYuan Huang <cy_huang@richtek.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	linux-pm@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, phone-devel@vger.kernel.org,
	~postmarketos/upstreaming@lists.sr.ht
Subject: Re: [PATCH v2 8/9] power: supply: rt5033_battery: Adopt status property from charger
Date: Sun, 23 Apr 2023 11:46:37 +0200	[thread overview]
Message-ID: <15a1ad2b-c07b-7470-6c4b-2c8feab667c5@rocketmail.com> (raw)
In-Reply-To: <23260904aab2566faf86d2ac01a31e7f1e024e66.1681646904.git.jahau@rocketmail.com>

Hi Sebastian,

I noticed a small mistake in patch 8.

On 16.04.23 14:44, Jakob Hauser wrote:
> The rt5033-battery fuelgauge can't get a status by itself. The rt5033-charger
> can, let's get this value.
> 
> Tested-by: Raymond Hackley <raymondhackley@protonmail.com>
> Signed-off-by: Jakob Hauser <jahau@rocketmail.com>
> ---
>   drivers/power/supply/rt5033_battery.c | 24 ++++++++++++++++++++++++
>   1 file changed, 24 insertions(+)
> 
> diff --git a/drivers/power/supply/rt5033_battery.c b/drivers/power/supply/rt5033_battery.c
> index 5c04cf305219..48d4cccce4f6 100644
> --- a/drivers/power/supply/rt5033_battery.c
> +++ b/drivers/power/supply/rt5033_battery.c
> @@ -12,6 +12,26 @@
>   #include <linux/mfd/rt5033-private.h>
>   #include <linux/mfd/rt5033.h>
>   
> +static int rt5033_battery_get_status(struct i2c_client *client)
> +{
> +	struct power_supply *charger;
> +	union power_supply_propval val;
> +	int ret;
> +
> +	charger = power_supply_get_by_name("rt5033-charger");
> +	if (!charger)
> +		return -ENODEV;
> +
> +	ret = power_supply_get_property(charger, POWER_SUPPLY_PROP_STATUS, &val);
> +	if (ret) {
> +		power_supply_put(charger);
> +		return POWER_SUPPLY_STATUS_UNKNOWN;
> +	}
> +
> +	power_supply_put(charger);
> +	return val.intval;
> +}
> +

If the rt5033-charger driver is not available, this function returns 
"-ENODEV". Instead of an error, in fact the status node in sysfs just 
reports "-19" then. Userspace layer UPower makes status "unknown" out of 
this.

An error message would spam dmesg anyway, as it would be issued every 
time the battery gets polled by UPower, which is quite regularly. The 
scenario of a missing rt5033-charger driver is not unlikely for devices 
where it's not yet implemented in the devicetree or in the configs of 
the compiled kernel. For the displayed battery icon, UPower assumes 
"discharging" for a single battery in "unknown" state.

It makes more sense to return "POWER_SUPPLY_STATUS_UNKNOWN" right away. 
I'll change that line in v3.

>   static int rt5033_battery_get_capacity(struct i2c_client *client)
>   {
>   	struct rt5033_battery *battery = i2c_get_clientdata(client);
> @@ -84,6 +104,9 @@ static int rt5033_battery_get_property(struct power_supply *psy,
>   	case POWER_SUPPLY_PROP_CAPACITY:
>   		val->intval = rt5033_battery_get_capacity(battery->client);
>   		break;
> +	case POWER_SUPPLY_PROP_STATUS:
> +		val->intval = rt5033_battery_get_status(battery->client);
> +		break;
>   	default:
>   		return -EINVAL;
>   	}
> @@ -96,6 +119,7 @@ static enum power_supply_property rt5033_battery_props[] = {
>   	POWER_SUPPLY_PROP_VOLTAGE_OCV,
>   	POWER_SUPPLY_PROP_PRESENT,
>   	POWER_SUPPLY_PROP_CAPACITY,
> +	POWER_SUPPLY_PROP_STATUS,
>   };
>   
>   static const struct regmap_config rt5033_battery_regmap_config = {

Kind regards,
Jakob

  reply	other threads:[~2023-04-23  9:46 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <cover.1681646904.git.jahau.ref@rocketmail.com>
2023-04-16 12:44 ` [PATCH v2 0/9] Add RT5033 charger device driver Jakob Hauser
2023-04-16 12:44   ` [PATCH v2 1/9] mfd: rt5033: Drop rt5033-battery sub-device Jakob Hauser
2023-04-20  8:05     ` Linus Walleij
2023-04-16 12:44   ` [PATCH v2 2/9] mfd: rt5033: Fix chip revision readout Jakob Hauser
2023-04-16 12:44   ` [PATCH v2 3/9] mfd: rt5033: Fix STAT_MASK, HZ_MASK and AICR defines Jakob Hauser
2023-04-16 12:44   ` [PATCH v2 4/9] mfd: rt5033: Apply preparatory changes before adding rt5033-charger driver Jakob Hauser
2023-04-16 12:44   ` [PATCH v2 5/9] regulator: rt5033: Change regulator names to lowercase Jakob Hauser
2023-04-16 18:32     ` Krzysztof Kozlowski
2023-04-18 21:24       ` Jakob Hauser
2023-04-19  8:40         ` Krzysztof Kozlowski
2023-04-19 22:21           ` Jakob Hauser
2023-04-16 12:44   ` [PATCH v2 6/9] power: supply: rt5033_charger: Add RT5033 charger device driver Jakob Hauser
2023-04-23  1:22     ` kernel test robot
2023-04-23  9:55       ` Jakob Hauser
2023-04-16 12:44   ` [PATCH v2 7/9] power: supply: rt5033_charger: Add cable detection and USB OTG supply Jakob Hauser
2023-04-16 12:44   ` [PATCH v2 8/9] power: supply: rt5033_battery: Adopt status property from charger Jakob Hauser
2023-04-23  9:46     ` Jakob Hauser [this message]
2023-04-16 12:44   ` [PATCH v2 9/9] dt-bindings: Add documentation for rt5033 mfd, regulator and charger Jakob Hauser
2023-04-16 18:39     ` Krzysztof Kozlowski
2023-04-18 21:37       ` Jakob Hauser
2023-04-19  8:42         ` Krzysztof Kozlowski
2023-04-19 22:41           ` Jakob Hauser
2023-04-20  7:59     ` Linus Walleij
2023-04-20  8:03       ` Linus Walleij
2023-04-20 21:16         ` Jakob Hauser
2023-04-21  9:20           ` Linus Walleij
2023-04-21 22:15             ` Jakob Hauser
2023-04-16 18:29   ` [PATCH v2 0/9] Add RT5033 charger device driver Krzysztof Kozlowski

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=15a1ad2b-c07b-7470-6c4b-2c8feab667c5@rocketmail.com \
    --to=jahau@rocketmail.com \
    --cc=axel.lin@ingics.com \
    --cc=beomho.seo@samsung.com \
    --cc=broonie@kernel.org \
    --cc=cw00.choi@samsung.com \
    --cc=cy_huang@richtek.com \
    --cc=devicetree@vger.kernel.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=lee@kernel.org \
    --cc=lgirdwood@gmail.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=phone-devel@vger.kernel.org \
    --cc=raymondhackley@protonmail.com \
    --cc=robh+dt@kernel.org \
    --cc=sre@kernel.org \
    --cc=stephan@gerhold.net \
    --cc=~postmarketos/upstreaming@lists.sr.ht \
    /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).