On Wed, Jul 07, 2021 at 01:25:03PM +0000, Vincent Pelletier wrote: > Add the HWMON driver for DA9063 > > Originally-from: Opensource [Steve Twiss] <stwiss.opensource@xxxxxxxxxxx> > Signed-off-by: Vincent Pelletier <plr.vincent@xxxxxxxxx> > --- > Changes in v3: > - changed original author's Signed-off-by into an Originally-from. > - dropped license boilerplate > - only return ETIMEOUT if ADC result is not ready by the time the IRQ > either triggered or timed out > - removed unnecessary lists > - changed a duplicate init_comptetion into a more useful reinit_completion > - dropped unused platform_set_drvdata > - moved temperature offset reading from mfd driver > > Changes in v2: > - drop of_match_table: this should be meaningless in such sub-function > driver (at least judging by other sub-function drivers for the da9063) > - sort includes > - switch to devm_hwmon_device_register_with_info > - registers.h changes moved to patch 1 > - add SPDX header > > This patch depends on patch 1/3. > Originally submitted by Steve Twiss in 2014: > https://marc.info/?l=linux-kernel&m=139560868309857&w=2 > > drivers/hwmon/Kconfig | 10 ++ > drivers/hwmon/Makefile | 1 + > drivers/hwmon/da9063-hwmon.c | 260 +++++++++++++++++++++++++++++++++++ > 3 files changed, 271 insertions(+) > create mode 100644 drivers/hwmon/da9063-hwmon.c > > diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig > index 87624902ea80..17244cfaa855 100644 > --- a/drivers/hwmon/Kconfig > +++ b/drivers/hwmon/Kconfig > @@ -515,6 +515,16 @@ config SENSORS_DA9055 > This driver can also be built as a module. If so, the module > will be called da9055-hwmon. > > +config SENSORS_DA9063 > + tristate "Dialog Semiconductor DA9063" > + depends on MFD_DA9063 > + help > + If you say yes here you get support for the hardware > + monitoring features of the DA9063 Power Management IC. > + > + This driver can also be built as a module. If so, the module > + will be called da9063-hwmon. > + > config SENSORS_I5K_AMB > tristate "FB-DIMM AMB temperature sensor on Intel 5000 series chipsets" > depends on PCI > diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile > index 59e78bc212cf..6855711ed9ec 100644 > --- a/drivers/hwmon/Makefile > +++ b/drivers/hwmon/Makefile > @@ -60,6 +60,7 @@ obj-$(CONFIG_SENSORS_CORSAIR_CPRO) += corsair-cpro.o > obj-$(CONFIG_SENSORS_CORSAIR_PSU) += corsair-psu.o > obj-$(CONFIG_SENSORS_DA9052_ADC)+= da9052-hwmon.o > obj-$(CONFIG_SENSORS_DA9055)+= da9055-hwmon.o > +obj-$(CONFIG_SENSORS_DA9063) += da9063-hwmon.o > obj-$(CONFIG_SENSORS_DELL_SMM) += dell-smm-hwmon.o > obj-$(CONFIG_SENSORS_DME1737) += dme1737.o > obj-$(CONFIG_SENSORS_DRIVETEMP) += drivetemp.o > diff --git a/drivers/hwmon/da9063-hwmon.c b/drivers/hwmon/da9063-hwmon.c > new file mode 100644 > index 000000000000..6367685536a1 > --- /dev/null > +++ b/drivers/hwmon/da9063-hwmon.c > @@ -0,0 +1,260 @@ > +// SPDX-License-Identifier: GPL-2.0-or-later > +/* da9063-hwmon.c - Hardware monitor support for DA9063 > + * Copyright (C) 2014 Dialog Semiconductor Ltd. > + * Copyright (C) 2021 Vincent Pelletier <plr.vincent@xxxxxxxxx> > + */ > + > +#include <linux/delay.h> > +#include <linux/err.h> > +#include <linux/hwmon.h> > +#include <linux/hwmon-sysfs.h> Unnecessary include. > +#include <linux/init.h> > +#include <linux/kernel.h> > +#include <linux/mfd/da9063/core.h> > +#include <linux/mod_devicetable.h> I don't immediately see where this include is needed. Is this a leftover ? > +#include <linux/module.h> > +#include <linux/platform_device.h> > +#include <linux/regmap.h> > +#include <linux/slab.h> > +#include <linux/string.h> Same here. > + > +#define DA9063_ADC_RES (1 << (DA9063_ADC_RES_L_BITS + DA9063_ADC_RES_M_BITS)) > +#define DA9063_ADC_MAX (DA9063_ADC_RES - 1) > +#define DA9063_2V5 2500 > +#define DA9063_5V0 5000 > +#define DA9063_5V5 5500 > +#define DA9063_TJUNC_M -398 It doesn't matter here (I think), but it would be better to surround the above with () to ensure that the '-' is not interpreted as arithmetic operator. > +#define DA9063_TJUNC_O 330000 > +#define DA9063_VBBAT_M 2048 > + > +enum da9063_adc { > + DA9063_CHAN_VSYS = DA9063_ADC_MUX_VSYS, > + DA9063_CHAN_ADCIN1 = DA9063_ADC_MUX_ADCIN1, > + DA9063_CHAN_ADCIN2 = DA9063_ADC_MUX_ADCIN2, > + DA9063_CHAN_ADCIN3 = DA9063_ADC_MUX_ADCIN3, > + DA9063_CHAN_TJUNC = DA9063_ADC_MUX_T_SENSE, > + DA9063_CHAN_VBBAT = DA9063_ADC_MUX_VBBAT, > + DA9063_CHAN_LDO_G1 = DA9063_ADC_MUX_LDO_G1, > + DA9063_CHAN_LDO_G2 = DA9063_ADC_MUX_LDO_G2, > + DA9063_CHAN_LDO_G3 = DA9063_ADC_MUX_LDO_G3 Many of the above defines are not used. Do you plan a follow-up commit to use them ? Otherwise please drop unused defines. > +}; > + > +struct da9063_hwmon { > + struct da9063 *da9063; > + struct mutex hwmon_mutex; > + struct completion adc_ready; > + signed char tjunc_offset; I am curious: 'char' implies 'signed'. Any reason for using 'signed' ? Also, note that on most architectures the resulting code is more complex when using 'char' instead of 'int'. This is seen easily by compiling the driver for arm64: Replacing the above 'signed char' with 'int' reduces code size by 32 bytes. > +}; > + > +static int da9063_adc_manual_read(struct da9063_hwmon *hwmon, int channel) > +{ > + int ret; > + unsigned char val; > + unsigned char data[2]; > + int adc_man; Should this be unsigned int ? > + > + mutex_lock(&hwmon->hwmon_mutex); > + > + val = (channel & DA9063_ADC_MUX_MASK) | DA9063_ADC_MAN; > + ret = regmap_update_bits(hwmon->da9063->regmap, DA9063_REG_ADC_MAN, > + DA9063_ADC_MUX_MASK | DA9063_ADC_MAN, val); > + if (ret < 0) > + goto err_mread; > + > + ret = wait_for_completion_timeout(&hwmon->adc_ready, > + msecs_to_jiffies(100)); > + reinit_completion(&hwmon->adc_ready); This is unusual. Normally I see init_completion() or reinit_completion() ahead of calls to wait functions. If a request timed out and an interrupt happened after the timeout, the next request would return immediately with the previous result, since complete() would be called on the re-initialized completion handler. That doesn't seem to be correct to me. > + if (ret == 0) > + dev_dbg(hwmon->da9063->dev, > + "Timeout while waiting for ADC completion IRQ\n"); > + > + ret = regmap_read(hwmon->da9063->regmap, DA9063_REG_ADC_MAN, &adc_man); > + if (ret < 0) > + goto err_mread; > + > + /* data value is not ready */ > + if (adc_man & DA9063_ADC_MAN) { > + ret = -ETIMEDOUT; > + goto err_mread; > + } > + > + ret = regmap_bulk_read(hwmon->da9063->regmap, > + DA9063_REG_ADC_RES_L, data, 2); > + if (ret < 0) > + goto err_mread; > + > + ret = (data[0] & DA9063_ADC_RES_L_MASK) >> DA9063_ADC_RES_L_SHIFT; > + ret |= data[1] << DA9063_ADC_RES_L_BITS; > +err_mread: > + mutex_unlock(&hwmon->hwmon_mutex); > + return ret; > +} > + > +static irqreturn_t da9063_hwmon_irq_handler(int irq, void *irq_data) > +{ > + struct da9063_hwmon *hwmon = irq_data; > + > + complete(&hwmon->adc_ready); > + return IRQ_HANDLED; > +} > + > +static umode_t da9063_is_visible(const void *drvdata, enum > + hwmon_sensor_types type, u32 attr, int channel) > +{ > + return 0444; > +} > + > +static const enum da9063_adc da9063_in_index[] = { > + DA9063_CHAN_VSYS, DA9063_CHAN_VBBAT > +}; > + > +static int da9063_read(struct device *dev, enum hwmon_sensor_types type, > + u32 attr, int channel, long *val) > +{ > + struct da9063_hwmon *hwmon = dev_get_drvdata(dev); > + enum da9063_adc adc_channel; > + int tmp; > + > + switch (type) { > + case hwmon_in: > + if (attr != hwmon_in_input) > + return -EOPNOTSUPP; > + adc_channel = da9063_in_index[channel]; > + break; > + case hwmon_temp: > + if (attr != hwmon_temp_input) > + return -EOPNOTSUPP; > + adc_channel = DA9063_CHAN_TJUNC; > + break; > + default: > + return -EOPNOTSUPP; > + } > + > + tmp = da9063_adc_manual_read(hwmon, adc_channel); > + if (tmp < 0) > + return tmp; > + > + switch (adc_channel) { > + case DA9063_CHAN_VSYS: > + *val = ((DA9063_5V5 - DA9063_2V5) * tmp) / DA9063_ADC_MAX + > + DA9063_2V5; > + break; > + case DA9063_CHAN_TJUNC: > + tmp -= hwmon->tjunc_offset; > + *val = DA9063_TJUNC_M * tmp + DA9063_TJUNC_O; > + break; > + case DA9063_CHAN_VBBAT: > + *val = (DA9063_5V0 * tmp) / DA9063_ADC_MAX; > + break; > + default: > + return -EINVAL; > + } > + > + return 0; > +} > + > +static const char * const da9063_in_name[] = { > + "VSYS", "VBBAT" > +}; > + > +static int da9063_read_string(struct device *dev, enum hwmon_sensor_types type, > + u32 attr, int channel, const char **str) > +{ > + switch (type) { > + case hwmon_in: > + if (attr != hwmon_in_label) > + return -EOPNOTSUPP; > + *str = da9063_in_name[channel]; > + break; > + case hwmon_temp: > + if (attr != hwmon_temp_label) > + return -EOPNOTSUPP; > + *str = "TJUNC"; > + break; > + default: > + return -EOPNOTSUPP; > + } > + > + return 0; > +} > + > +static const struct hwmon_ops da9063_ops = { > + .is_visible = da9063_is_visible, > + .read = da9063_read, > + .read_string = da9063_read_string, > +}; > + > +static const struct hwmon_channel_info *da9063_channel_info[] = { > + HWMON_CHANNEL_INFO(chip, HWMON_C_REGISTER_TZ), > + HWMON_CHANNEL_INFO(in, > + HWMON_I_INPUT | HWMON_I_LABEL, > + HWMON_I_INPUT | HWMON_I_LABEL), > + HWMON_CHANNEL_INFO(temp, > + HWMON_T_INPUT | HWMON_T_LABEL), > + NULL > +}; > + > +static const struct hwmon_chip_info da9063_chip_info = { > + .ops = &da9063_ops, > + .info = da9063_channel_info, > +}; > + > +static int da9063_hwmon_probe(struct platform_device *pdev) > +{ > + struct da9063 *da9063 = dev_get_drvdata(pdev->dev.parent); > + struct da9063_hwmon *hwmon; > + struct device *hwmon_dev; > + unsigned int tmp; > + int irq; > + int ret; > + > + hwmon = devm_kzalloc(&pdev->dev, sizeof(struct da9063_hwmon), > + GFP_KERNEL); > + if (!hwmon) > + return -ENOMEM; > + > + mutex_init(&hwmon->hwmon_mutex); > + init_completion(&hwmon->adc_ready); > + hwmon->da9063 = da9063; > + > + irq = platform_get_irq_byname(pdev, DA9063_DRVNAME_HWMON); > + if (irq < 0) > + return irq; > + > + ret = devm_request_threaded_irq(&pdev->dev, irq, NULL, > + da9063_hwmon_irq_handler, > + IRQF_TRIGGER_LOW | IRQF_ONESHOT, > + "HWMON", hwmon); > + if (ret) { > + dev_err(&pdev->dev, "Failed to request IRQ.\n"); > + return ret; > + } > + > + ret = regmap_read(da9063->regmap, DA9063_REG_T_OFFSET, &tmp); > + if (ret < 0) { > + tmp = 0; > + dev_warn(&pdev->dev, > + "Temperature trimming value cannot be read (defaulting to 0)\n"); > + } > + hwmon->tjunc_offset = (signed char) tmp; Nit: Unnecessary space after typecast (checkpatch --strict would tell you). Also, I am curious: The temperature offset is a standard hwmon attribute. Is it an oversight to not report it, or is it on purpose ? > + > + hwmon_dev = devm_hwmon_device_register_with_info(&pdev->dev, "da9063", > + hwmon, > + &da9063_chip_info, > + NULL); > + > + return PTR_ERR_OR_ZERO(hwmon_dev); > +} > + > +static struct platform_driver da9063_hwmon_driver = { > + .probe = da9063_hwmon_probe, > + .driver = { > + .name = DA9063_DRVNAME_HWMON, > + }, > +}; > +module_platform_driver(da9063_hwmon_driver); > + > +MODULE_DESCRIPTION("Hardware monitor support device driver for Dialog DA9063"); > +MODULE_AUTHOR("Vincent Pelletier <plr.vincent@xxxxxxxxx>"); > +MODULE_LICENSE("GPL v2"); > +MODULE_ALIAS("platform:" DA9063_DRVNAME_HWMON);