Re: [PATCH 14/15] power: supply: Add driver for Cherry Trail Whiskey Cove PMIC Fuel Gauge

Hans de Goede
2017-03-22T17:03:36Z

Hi,

On 17-03-17 18:58, Andy Shevchenko wrote:
> On Fri, 2017-03-17 at 10:55 +0100, Hans de Goede wrote:
>> Add a driver for the Cherry Trail Whiskey Cove PMIC Fuel Gauge, note
>> the Cherry Trail Whiskey Cove PMIC Fuel Gauge block is purely a fuel
>> gauge
>> and not a full battery controller. As such it offers a platform_data
>> callback for extra power_supply properties for the actual external-
>> charger
>> ic driver and does not register a power_supply itself.
>
> ic -> IC
>
> Can we move to something like built-in device properties for additional
> properties instead of extending platform data?
>
>> +config CHT_WC_FUEL_GAUGE
>
> I would use similar pattern:
>
> FUEL_GAUGE_INTEL_CHTWC (or FUEL_GAUGE_CHTWC, but this might be less
> obvious about vendor)

Good point, although all the fuel-gauge's seem to use
BATTERY as prefix, so I've gone with that.

>
>> --- /dev/null
>> +++ b/drivers/power/supply/cht_wc_fuel_gauge.c
>> @@ -0,0 +1,209 @@
>> +/*
>> + * Intel CHT Whiskey Cove Fuel Gauge driver
>
> CHT -> Cherry Trail

Fixed.

>
>> + *
>> + * Cherrytrail Whiskey Cove devices have 2 functional blocks which
>> interact
>> + * with the battery.
>
> Cherry Trail?

Since after discussion about how to deal with the charger / fuel_gauge
comment v2 is going to be a stand-alone power_supply driver this
comment has been dropped.

>
>> +#define REG_CHARGE_NOW 0x05
>> +#define REG_VOLTAGE_NOW 0x09
>> +#define REG_CURRENT_NOW 0x0a
>> +#define REG_CURRENT_AVG 0x0b
>> +#define REG_CHARGE_FULL 0x10
>> +#define REG_CHARGE_DESIGN 0x18
>> +#define REG_VOLTAGE_AVG 0x19
>
>> +#define REG_VOLTAGE_OCV 0x1b /* Only updated during
>> charging */
>
> I think comment makes more sense where actual update is happening in the
> code.
>
>> +
>> +static int cht_wc_fg_read(struct cht_wc_fg_data *fg, u8 reg,
>> + union power_supply_propval *val, int scale,
>> + int sign_extend)
>> +{
>> + int ret;
>> +
>> + ret = i2c_smbus_read_word_data(fg->client, reg);
>> + if (ret < 0)
>> + return ret;
>> +
>> + if (sign_extend)
>> + ret = sign_extend32(ret, 15);
>
> Magic?

Nope just simply dealing with i2c_smbus_read_word_data always
returning 16 bit unsigned data (or a negative error code)
and some of the registers being 16 bit signed.

>
>> +
>> + val->intval = ret * scale;
>> +
>> + return 0;
>> +}
>
>
>> +
>> +int cht_wc_fg_get_property(enum power_supply_property prop,
>> + union power_supply_propval *val)
>> +{
>> + int ret = 0;
>
> Sounds like redundant assignment...

No longer redundant in v2.

>
>> +
>> + mutex_lock(&cht_wc_fg_mutex);
>> +
>>
>
>> + if (!cht_wc_fg) {
>> + ret = -ENXIO;
>> + goto out_unlock;
>> + }
>
> ...otherwise maybe
>
> ret = cht_wc_fg ? 0 : -ENXIO;
> if (ret)
> goto ...;
>
> ?

With the stand-alone power_supply driver version this ugliness is gone.

>
>> + default:
>> + ret = -ENODATA;
>> + }
>> +out_unlock:
>> + mutex_unlock(&cht_wc_fg_mutex);
>> + return ret;
>> +}
>> +EXPORT_SYMBOL_GPL(cht_wc_fg_get_property);
>
>> +
>> +static int cht_wc_fg_probe(struct i2c_client *client,
>> + const struct i2c_device_id *i2c_id)
>> +{
>> + struct device *dev = &client->dev;
>> + struct cht_wc_fg_data *fg;
>> + acpi_status status;
>> + unsigned long long ptyp;
>
>> + status = acpi_evaluate_integer(ACPI_HANDLE(dev), "PTYP",
>> NULL, &ptyp);
>> + if (ACPI_FAILURE(status)) {
>> + dev_err(dev, "Failed to get PTYPE\n");
>> + return -ENODEV;
>> + }
>> +
>> + /*
>> + * The same ACPI HID is used with different PMICs check PTYP
>> to
>> + * ensure that we are dealing with a Whiskey Cove PMIC.
>> + */
>> + if (ptyp != CHT_WC_FG_PTYPE)
>> + return -ENODEV;
>
> Logically I would split this part to be a main driver for device which
> would use actual driver based on this, though I think it too much churn
> for no benefit right now.

Ack.

>
>> + mutex_lock(&cht_wc_fg_mutex);
>> + cht_wc_fg = fg;
>> + mutex_unlock(&cht_wc_fg_mutex);
>
> It's pity we have no common storage of single possible present device
> drivers in the kernel. I would use some kind of framework rather then
> keeping all those global variables with locking. Perhaps radix / RB
> tree.

With the stand-alone power_supply driver version this ugliness is gone.

Regards,

Hans