[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200515153502.GE2836808@arch-x1c3>
Date: Fri, 15 May 2020 16:35:02 +0100
From: Emil Velikov <emil.velikov@...labora.com>
To: Sebastian Reichel <sebastian.reichel@...labora.com>
Cc: Sebastian Reichel <sre@...nel.org>,
Rob Herring <robh+dt@...nel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"Rafael J . Wysocki" <rafael@...nel.org>, linux-pm@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
kernel@...labora.com
Subject: Re: [PATCHv1 13/19] power: supply: sbs-battery: add
POWER_SUPPLY_HEALTH_CALIBRATION_REQUIRED support
On 2020/05/13, Sebastian Reichel wrote:
> Add support for reporting the SBS battery's condition flag
> to userspace using the new "Calibration required" health status.
>
> Signed-off-by: Sebastian Reichel <sebastian.reichel@...labora.com>
> ---
> drivers/power/supply/sbs-battery.c | 27 ++++++++++++++++++++++++---
> 1 file changed, 24 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/power/supply/sbs-battery.c b/drivers/power/supply/sbs-battery.c
> index 4fa553d61db2..2a2b926ad75c 100644
> --- a/drivers/power/supply/sbs-battery.c
> +++ b/drivers/power/supply/sbs-battery.c
> @@ -23,6 +23,7 @@
>
> enum {
> REG_MANUFACTURER_DATA,
> + REG_BATTERY_MODE,
> REG_TEMPERATURE,
> REG_VOLTAGE,
> REG_CURRENT_NOW,
> @@ -94,6 +95,8 @@ static const struct chip_data {
> } sbs_data[] = {
> [REG_MANUFACTURER_DATA] =
> SBS_DATA(POWER_SUPPLY_PROP_PRESENT, 0x00, 0, 65535),
> + [REG_BATTERY_MODE] =
> + SBS_DATA(-1, 0x03, 0, 65535),
Fwiw I really like how neatly the driver is split into components. One thing
which makes me wonder, have you considered reshuffling the sbs_data struct.
In particular:
- index POWER_SUPPLY_PROP, kill off the REG_ enum
- sbs_get_property_index() can go, alongside a couple of unreachable paths
- replace batter_mode (needs calibration) with with PROP_HEALTH + comment
- perhaps even add REG_ADDR_SPEC_INFO 0x1a under POWER_SUPPLY_PROP_PRESENT
- using the min/max seems wasteful, considering only one register is in s16
range while everything else is within u16
Regardless of the questions and trivial suggestions, the series looks spot on.
For the lot:
Reviewed-by: Emil Velikov <emil.velikov@...labora.com>
-Emil
P.S. The reg table is nearly complete only 0x01-0x07, 0x0E, 0x11, 0x1d-0x1f
remain o/
Powered by blists - more mailing lists