linux-kernel - RE: [PATCH] power: max17042_battery: add HEALTH and TEMP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 4 May 2015 15:07:33 +0000
From:	"Pallala, Ramakrishna" <ramakrishna.pallala@...el.com>
To:	Krzysztof Kozlowski <k.kozlowski.k@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	Sebastian Reichel <sre@...nel.org>
CC:	MyungJoo Ham <myungjoo.ham@...sung.com>
Subject: RE: [PATCH] power: max17042_battery: add HEALTH and TEMP_*
 properties support

Hi,

> W dniu 05.05.2015 o 07:18, Ramakrishna Pallala pisze:
> > This patch adds the support for following battery properties to
> > max17042 fuel gauge driver.
> 
> The patchset itself looks good. Only minor nits and a question at the end.
> 
> >
> > POWER_SUPPLY_PROP_TEMP_ALERT_MIN
> > POWER_SUPPLY_PROP_TEMP_ALERT_MAX
> > POWER_SUPPLY_PROP_TEMP_MIN
> > POWER_SUPPLY_PROP_TEMP_MAX
> > POWER_SUPPLY_PROP_HEALTH
> >
> > Signed-off-by: Ramakrishna Pallala <ramakrishna.pallala@...el.com>
> > ---
> >  drivers/power/max17042_battery.c       |  190
> ++++++++++++++++++++++++++++++--
> >  include/linux/power/max17042_battery.h |    4 +
> >  2 files changed, 183 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/power/max17042_battery.c
> > b/drivers/power/max17042_battery.c
> > index 6cc5e87..d8f15ce 100644
> > --- a/drivers/power/max17042_battery.c
> > +++ b/drivers/power/max17042_battery.c
> > @@ -63,6 +63,8 @@
> >  #define dP_ACC_100	0x1900
> >  #define dP_ACC_200	0x3200
> >
> > +#define MAX17042_VMAX_TOLERENCE		50 /* 50 mV */
> 
> s/TOLERENCE/TOLERANCE/
Ok..

[snip]

> > +
> > +static int max17042_get_battery_health(struct max17042_chip *chip,
> > +int *health) {
> > +	int temp, vavg, vbatt, ret;
> > +	u32 val;
> > +
> > +	ret = regmap_read(chip->regmap, MAX17042_AvgVCELL, &val);
> > +	if (ret < 0)
> > +		goto health_error;
> > +
> > +	/* bits [0-3] unused */
> > +	vavg = val * 625 / 8;
> > +	/* Convert to milli volts */
> 
> s/milli volts/millivolts/
Ok..

[snip]

> > @@ -665,6 +829,8 @@ static const struct power_supply_desc
> max17042_psy_desc = {
> >  	.name		= "max170xx_battery",
> >  	.type		= POWER_SUPPLY_TYPE_BATTERY,
> >  	.get_property	= max17042_get_property,
> > +	.set_property	= max17042_set_property,
> > +	.property_is_writeable	= max17042_property_is_writeable,
> >  	.properties	= max17042_battery_props,
> >  	.num_properties	= ARRAY_SIZE(max17042_battery_props),
> >  };
> > @@ -673,6 +839,8 @@ static const struct power_supply_desc
> max17042_no_current_sense_psy_desc = {
> >  	.name		= "max170xx_battery",
> >  	.type		= POWER_SUPPLY_TYPE_BATTERY,
> >  	.get_property	= max17042_get_property,
> > +	.set_property	= max17042_set_property,
> > +	.property_is_writeable	= max17042_property_is_writeable,
> >  	.properties	= max17042_battery_props,
> >  	.num_properties	= ARRAY_SIZE(max17042_battery_props) - 2,
> >  };
> > diff --git a/include/linux/power/max17042_battery.h
> > b/include/linux/power/max17042_battery.h
> > index cf112b4..89ca4a8 100644
> > --- a/include/linux/power/max17042_battery.h
> > +++ b/include/linux/power/max17042_battery.h
> > @@ -215,6 +215,10 @@ struct max17042_platform_data {
> >  	 * the datasheet although it can be changed by board designers.
> >  	 */
> >  	unsigned int r_sns;
> > +	int         vmin;	/* in milli volts */
> > +	int         vmax;	/* in milli volts */
> 
> s/milli volts/millivolts/
Ok..

> > +	int         temp_min;	/* in tenths of degree Celsius */
> > +	int         temp_max;	/* in tenths of degree Celsius */
> >  };
> >
> >  #endif /* __MAX17042_BATTERY_H_ */
> 
> The question is who will set these values in pdata? We do not have board files
> anymore so I think you should extend the DT bindings so this could be used.

In our platform we don't use device tree...the enumeration is based on SFI model and
there is board file in our platform.

To complete the platforms which use device tree, I can add of_property_read_u32() calls for
new pdata variables and submit the patch.

Thanks,
Ram




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/