| 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
| ||
|
Date: Tue, 20 Jan 2015 10:50:22 +0000
From: Lee Jones <lee.jones@...aro.org>
To: "Opensource [Adam Thomson]" <Adam.Thomson.Opensource@...semi.com>
Cc: Samuel Ortiz <sameo@...ux.intel.com>,
Jonathan Cameron <jic23@...nel.org>,
Hartmut Knaack <knaack.h@....de>,
"linux-iio@...r.kernel.org" <linux-iio@...r.kernel.org>,
Sebastian Reichel <sre@...nel.org>,
Dmitry Eremin-Solenikov <dbaryshkov@...il.com>,
David Woodhouse <dwmw2@...radead.org>,
"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
Rob Herring <robh+dt@...nel.org>,
Pawel Moll <pawel.moll@....com>,
Mark Rutland <mark.rutland@....com>,
Ian Campbell <ijc+devicetree@...lion.org.uk>,
Kumar Gala <galak@...eaurora.org>,
Grant Likely <grant.likely@...aro.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Joe Perches <joe@...ches.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Support Opensource <Support.Opensource@...semi.com>
Subject: Re: [PATCH v5 1/7] mfd: Add support for DA9150 combined charger &
fuel-gauge device
On Mon, 19 Jan 2015, Opensource [Adam Thomson] wrote:
> On January 19, 2015 11:34, Lee Jones wrote:
>
> > On Mon, 22 Dec 2014, Adam Thomson wrote:
> >
> > > DA9150 is a combined Charger and Fuel-Gauge IC, with additional
> > > GPIO and GPADC functionality.
> > >
> > > Signed-off-by: Adam Thomson <Adam.Thomson.Opensource@...semi.com>
> > > ---
> > > drivers/mfd/Kconfig | 12 +
> > > drivers/mfd/Makefile | 2 +-
> > > drivers/mfd/da9150-core.c | 413 ++++++++++++
> > > include/linux/mfd/da9150/core.h | 68 ++
> > > include/linux/mfd/da9150/registers.h | 1155
> > ++++++++++++++++++++++++++++++++++
> > > 5 files changed, 1649 insertions(+), 1 deletion(-)
> > > create mode 100644 drivers/mfd/da9150-core.c
> > > create mode 100644 include/linux/mfd/da9150/core.h
> > > create mode 100644 include/linux/mfd/da9150/registers.h
> > >
> > > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> > > index 2e6b731..56e80d2 100644
> > > --- a/drivers/mfd/Kconfig
> > > +++ b/drivers/mfd/Kconfig
> > > @@ -195,6 +195,18 @@ config MFD_DA9063
> > > Additional drivers must be enabled in order to use the functionality
> > > of the device.
> > >
> > > +config MFD_DA9150
> > > + tristate "Dialog Semiconductor DA9150 Charger Fuel-Gauge chip"
> > > + depends on I2C=y
> > > + select MFD_CORE
> > > + select REGMAP_I2C
> > > + select REGMAP_IRQ
> > > + help
> > > + This adds support for the DA9150 integrated charger and fuel-gauge
> > > + chip. This driver provides common support for accessing the device.
> > > + Additional drivers must be enabled in order to use the specific
> > > + features of the device.
> > > +
> > > config MFD_DLN2
> > > tristate "Diolan DLN2 support"
> > > select MFD_CORE
> > > diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> > > index 53467e2..f06f4c6 100644
> > > --- a/drivers/mfd/Makefile
> > > +++ b/drivers/mfd/Makefile
> > > @@ -113,7 +113,7 @@ obj-$(CONFIG_MFD_DA9055) += da9055.o
> > >
> > > da9063-objs := da9063-core.o da9063-irq.o da9063-i2c.o
> > > obj-$(CONFIG_MFD_DA9063) += da9063.o
> > > -
> > > +obj-$(CONFIG_MFD_DA9150) += da9150-core.o
> > > obj-$(CONFIG_MFD_MAX14577) += max14577.o
> > > obj-$(CONFIG_MFD_MAX77686) += max77686.o
> > > obj-$(CONFIG_MFD_MAX77693) += max77693.o
> > > diff --git a/drivers/mfd/da9150-core.c b/drivers/mfd/da9150-core.c
> > > new file mode 100644
> > > index 0000000..4d757b9
> > > --- /dev/null
> > > +++ b/drivers/mfd/da9150-core.c
> > > @@ -0,0 +1,413 @@
> > > +/*
> > > + * DA9150 Core MFD Driver
> > > + *
> > > + * Copyright (c) 2014 Dialog Semiconductor
> > > + *
> > > + * Author: Adam Thomson <Adam.Thomson.Opensource@...semi.com>
> > > + *
> > > + * This program is free software; you can redistribute it and/or modify it
> > > + * under the terms of the GNU General Public License as published by the
> > > + * Free Software Foundation; either version 2 of the License, or (at your
> > > + * option) any later version.
> > > + */
> >
> > [...]
> >
> > > +u8 da9150_reg_read(struct da9150 *da9150, u16 reg)
> > > +{
> > > + int val, ret;
> > > +
> > > + ret = regmap_read(da9150->regmap, reg, &val);
> > > + if (ret)
> > > + dev_err(da9150->dev, "Failed to read from reg 0x%x: %d\n",
> > > + reg, ret);
> > > +
> > > + return (u8) val;
> > > +}
> > > +EXPORT_SYMBOL_GPL(da9150_reg_read);
> > > +
> > > +void da9150_reg_write(struct da9150 *da9150, u16 reg, u8 val)
> > > +{
> > > + int ret;
> > > +
> > > + ret = regmap_write(da9150->regmap, reg, val);
> > > + if (ret)
> > > + dev_err(da9150->dev, "Failed to write to reg 0x%x: %d\n",
> > > + reg, ret);
> > > +}
> > > +EXPORT_SYMBOL_GPL(da9150_reg_write);
> > > +
> > > +void da9150_set_bits(struct da9150 *da9150, u16 reg, u8 mask, u8 val)
> > > +{
> > > + int ret;
> > > +
> > > + ret = regmap_update_bits(da9150->regmap, reg, mask, val);
> > > + if (ret)
> > > + dev_err(da9150->dev, "Failed to set bits in reg 0x%x: %d\n",
> > > + reg, ret);
> > > +}
> > > +EXPORT_SYMBOL_GPL(da9150_set_bits);
> > > +
> > > +void da9150_bulk_read(struct da9150 *da9150, u16 reg, int count, u8 *buf)
> > > +{
> > > + int ret;
> > > +
> > > + ret = regmap_bulk_read(da9150->regmap, reg, buf, count);
> > > + if (ret)
> > > + dev_err(da9150->dev, "Failed to bulk read from reg 0x%x: %d\n",
> > > + reg, ret);
> > > +}
> > > +EXPORT_SYMBOL_GPL(da9150_bulk_read);
> > > +
> > > +void da9150_bulk_write(struct da9150 *da9150, u16 reg, int count, const u8
> > *buf)
> > > +{
> > > + int ret;
> > > +
> > > + ret = regmap_raw_write(da9150->regmap, reg, buf, count);
> > > + if (ret)
> > > + dev_err(da9150->dev, "Failed to bulk write to reg 0x%x %d\n",
> > > + reg, ret);
> > > +}
> > > +EXPORT_SYMBOL_GPL(da9150_bulk_write);
> >
> > I've never been a fan of this type of aggregation. Can you explain to
> > me what the point of them is?
>
> I refer you back to our previous discussion some time back:
>
> https://lkml.org/lkml/2014/9/9/284
>
> 'The reason for these is because future patches to add additional functionality
> will introduce I2C access functions which do not use regmap and access the
> device via a separate I2C address for this purpose. I will need to provide
> access functions for that, and so having a common style of I2C access makes
> sense for this driver. Means any access just needs to provide the MFD private
> data, and the relevant functions take care of the rest. I think this is cleaner
> in this instance.'
Well at least I'm consistent.
For my own reference:
Acked-by: Lee Jones <lee.jones@...aro.org>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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/
Powered by blists - more mailing lists