[PATCH 1/6] mfd: da9063: Rename PMIC_DA9063 to PMIC_CHIP_ID_DA9063

[PATCH 1/6] mfd: da9063: Rename PMIC_DA9063 to PMIC_CHIP_ID_DA9063

[Marek Vasut]

The PMIC_DA9063 is a complete misnomer, it denotes the value of the
DA9063 chip ID register, so rename it as such. It is also the value
of chip ID register of DA9063L though, so drop the enum as all the
DA9063 "models" share the same chip ID and thus the distinction will
have to be made using DT or otherwise.

Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Lee Jones <lee.jones@linaro.org>
Cc: Mark Brown <broonie@kernel.org>
Cc: Steve Twiss <stwiss.opensource@diasemi.com>
Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>
Cc: linux-renesas-soc@vger.kernel.org
---
 drivers/mfd/da9063-core.c            | 2 +-
 drivers/mfd/da9063-i2c.c             | 2 +-
 drivers/regulator/da9063-regulator.c | 2 +-
 include/linux/mfd/da9063/core.h      | 4 +---
 4 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/mfd/da9063-core.c b/drivers/mfd/da9063-core.c
index 6c2870d4e754..00b3caee4e21 100644
--- a/drivers/mfd/da9063-core.c
+++ b/drivers/mfd/da9063-core.c
@@ -192,7 +192,7 @@ int da9063_device_init(struct da9063 *da9063, unsigned int irq)
 		dev_err(da9063->dev, "Cannot read chip model id.\n");
 		return -EIO;
 	}
-	if (model != PMIC_DA9063) {
+	if (model != PMIC_CHIP_ID_DA9063) {
 		dev_err(da9063->dev, "Invalid chip model id: 0x%02x\n", model);
 		return -ENODEV;
 	}
diff --git a/drivers/mfd/da9063-i2c.c b/drivers/mfd/da9063-i2c.c
index 981805a2c521..7f84030c8d53 100644
--- a/drivers/mfd/da9063-i2c.c
+++ b/drivers/mfd/da9063-i2c.c
@@ -280,7 +280,7 @@ static int da9063_i2c_remove(struct i2c_client *i2c)
 }
 
 static const struct i2c_device_id da9063_i2c_id[] = {
-	{"da9063", PMIC_DA9063},
+	{ "da9063", PMIC_CHIP_ID_DA9063 },
 	{},
 };
 MODULE_DEVICE_TABLE(i2c, da9063_i2c_id);
diff --git a/drivers/regulator/da9063-regulator.c b/drivers/regulator/da9063-regulator.c
index 6a8f9cd69f52..87c884ae0064 100644
--- a/drivers/regulator/da9063-regulator.c
+++ b/drivers/regulator/da9063-regulator.c
@@ -585,7 +585,7 @@ static struct da9063_dev_model regulators_models[] = {
 	{
 		.regulator_info = da9063_regulator_info,
 		.n_regulators = ARRAY_SIZE(da9063_regulator_info),
-		.dev_model = PMIC_DA9063,
+		.dev_model = PMIC_CHIP_ID_DA9063,
 	},
 	{ }
 };
diff --git a/include/linux/mfd/da9063/core.h b/include/linux/mfd/da9063/core.h
index f3ae65db4c86..664f650d0086 100644
--- a/include/linux/mfd/da9063/core.h
+++ b/include/linux/mfd/da9063/core.h
@@ -29,9 +29,7 @@
 #define DA9063_DRVNAME_RTC		"da9063-rtc"
 #define DA9063_DRVNAME_VIBRATION	"da9063-vibration"
 
-enum da9063_models {
-	PMIC_DA9063 = 0x61,
-};
+#define PMIC_CHIP_ID_DA9063		0x61
 
 enum da9063_variant_codes {
 	PMIC_DA9063_AD = 0x3,
-- 
2.16.2

[PATCH 2/6] mfd: da9063: Replace model with type

[Marek Vasut]

The model number stored in the struct da9063 is the same for all
variants of the da9063 since it is the chip ID, which is always
the same. Replace that with a separate identifier instead, which
allows us to discern the DA9063 variants by setting the type
based on either DT match or otherwise.

Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Lee Jones <lee.jones@linaro.org>
Cc: Mark Brown <broonie@kernel.org>
Cc: Steve Twiss <stwiss.opensource@diasemi.com>
Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>
Cc: linux-renesas-soc@vger.kernel.org
---
 drivers/mfd/da9063-core.c            | 1 -
 drivers/mfd/da9063-i2c.c             | 5 +++--
 drivers/regulator/da9063-regulator.c | 6 +++---
 include/linux/mfd/da9063/core.h      | 6 +++++-
 4 files changed, 11 insertions(+), 7 deletions(-)

diff --git a/drivers/mfd/da9063-core.c b/drivers/mfd/da9063-core.c
index 00b3caee4e21..7360b76b4f72 100644
--- a/drivers/mfd/da9063-core.c
+++ b/drivers/mfd/da9063-core.c
@@ -215,7 +215,6 @@ int da9063_device_init(struct da9063 *da9063, unsigned int irq)
 		return -ENODEV;
 	}
 
-	da9063->model = model;
 	da9063->variant_code = variant_code;
 
 	ret = da9063_irq_init(da9063);
diff --git a/drivers/mfd/da9063-i2c.c b/drivers/mfd/da9063-i2c.c
index 7f84030c8d53..5544ce8e3363 100644
--- a/drivers/mfd/da9063-i2c.c
+++ b/drivers/mfd/da9063-i2c.c
@@ -236,7 +236,7 @@ static const struct of_device_id da9063_dt_ids[] = {
 };
 MODULE_DEVICE_TABLE(of, da9063_dt_ids);
 static int da9063_i2c_probe(struct i2c_client *i2c,
-	const struct i2c_device_id *id)
+			    const struct i2c_device_id *id)
 {
 	struct da9063 *da9063;
 	int ret;
@@ -248,6 +248,7 @@ static int da9063_i2c_probe(struct i2c_client *i2c,
 	i2c_set_clientdata(i2c, da9063);
 	da9063->dev = &i2c->dev;
 	da9063->chip_irq = i2c->irq;
+	da9063->type = (enum da9063_type)id->driver_data;
 
 	if (da9063->variant_code == PMIC_DA9063_AD) {
 		da9063_regmap_config.rd_table = &da9063_ad_readable_table;
@@ -280,7 +281,7 @@ static int da9063_i2c_remove(struct i2c_client *i2c)
 }
 
 static const struct i2c_device_id da9063_i2c_id[] = {
-	{ "da9063", PMIC_CHIP_ID_DA9063 },
+	{ "da9063", PMIC_TYPE_DA9063 },
 	{},
 };
 MODULE_DEVICE_TABLE(i2c, da9063_i2c_id);
diff --git a/drivers/regulator/da9063-regulator.c b/drivers/regulator/da9063-regulator.c
index 87c884ae0064..9b5c28392ae6 100644
--- a/drivers/regulator/da9063-regulator.c
+++ b/drivers/regulator/da9063-regulator.c
@@ -98,7 +98,7 @@ struct da9063_regulator_info {
 struct da9063_dev_model {
 	const struct da9063_regulator_info	*regulator_info;
 	unsigned				n_regulators;
-	unsigned				dev_model;
+	enum da9063_type			type;
 };
 
 /* Single regulator settings */
@@ -585,7 +585,7 @@ static struct da9063_dev_model regulators_models[] = {
 	{
 		.regulator_info = da9063_regulator_info,
 		.n_regulators = ARRAY_SIZE(da9063_regulator_info),
-		.dev_model = PMIC_CHIP_ID_DA9063,
+		.type = PMIC_TYPE_DA9063,
 	},
 	{ }
 };
@@ -741,7 +741,7 @@ static int da9063_regulator_probe(struct platform_device *pdev)
 
 	/* Find regulators set for particular device model */
 	for (model = regulators_models; model->regulator_info; model++) {
-		if (model->dev_model == da9063->model)
+		if (model->dev_model == da9063->type)
 			break;
 	}
 	if (!model->regulator_info) {
diff --git a/include/linux/mfd/da9063/core.h b/include/linux/mfd/da9063/core.h
index 664f650d0086..eb234582dcb2 100644
--- a/include/linux/mfd/da9063/core.h
+++ b/include/linux/mfd/da9063/core.h
@@ -31,6 +31,10 @@
 
 #define PMIC_CHIP_ID_DA9063		0x61
 
+enum da9063_type {
+	PMIC_TYPE_DA9063 = 0,
+};
+
 enum da9063_variant_codes {
 	PMIC_DA9063_AD = 0x3,
 	PMIC_DA9063_BB = 0x5,
@@ -76,7 +80,7 @@ enum da9063_irqs {
 struct da9063 {
 	/* Device */
 	struct device	*dev;
-	unsigned short	model;
+	enum da9063_type type;
 	unsigned char	variant_code;
 	unsigned int	flags;
 
-- 
2.16.2

[PATCH 3/6] mfd: da9063: Add DA9063L type

[Marek Vasut]

Add type for DA9063L, which is a reduced variant of the DA9063
without RTC block and with less regulators.

Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Lee Jones <lee.jones@linaro.org>
Cc: Mark Brown <broonie@kernel.org>
Cc: Steve Twiss <stwiss.opensource@diasemi.com>
Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>
Cc: linux-renesas-soc@vger.kernel.org
---
 include/linux/mfd/da9063/core.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/mfd/da9063/core.h b/include/linux/mfd/da9063/core.h
index eb234582dcb2..c3e917dd1860 100644
--- a/include/linux/mfd/da9063/core.h
+++ b/include/linux/mfd/da9063/core.h
@@ -33,6 +33,7 @@
 
 enum da9063_type {
 	PMIC_TYPE_DA9063 = 0,
+	PMIC_TYPE_DA9063L,
 };
 
 enum da9063_variant_codes {
-- 
2.16.2

[PATCH 4/6] mfd: da9063: Disallow RTC on DA9063L

[Marek Vasut]

The DA9063L does not contain RTC block, unlike the full DA9063.
Do not allow binding RTC driver on this variant of the chip.

Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Lee Jones <lee.jones@linaro.org>
Cc: Mark Brown <broonie@kernel.org>
Cc: Steve Twiss <stwiss.opensource@diasemi.com>
Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>
Cc: linux-renesas-soc@vger.kernel.org
---
 drivers/mfd/da9063-core.c | 18 +++++++++++-------
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/drivers/mfd/da9063-core.c b/drivers/mfd/da9063-core.c
index 7360b76b4f72..263c83006413 100644
--- a/drivers/mfd/da9063-core.c
+++ b/drivers/mfd/da9063-core.c
@@ -101,14 +101,14 @@ static const struct mfd_cell da9063_devs[] = {
 		.of_compatible = "dlg,da9063-onkey",
 	},
 	{
+		.name		= DA9063_DRVNAME_VIBRATION,
+	},
+	{	/* Only present on DA9063 , not on DA9063L */
 		.name		= DA9063_DRVNAME_RTC,
 		.num_resources	= ARRAY_SIZE(da9063_rtc_resources),
 		.resources	= da9063_rtc_resources,
 		.of_compatible	= "dlg,da9063-rtc",
 	},
-	{
-		.name		= DA9063_DRVNAME_VIBRATION,
-	},
 };
 
 static int da9063_clear_fault_log(struct da9063 *da9063)
@@ -163,7 +163,7 @@ int da9063_device_init(struct da9063 *da9063, unsigned int irq)
 {
 	struct da9063_pdata *pdata = da9063->dev->platform_data;
 	int model, variant_id, variant_code;
-	int ret;
+	int da9063_devs_len, ret;
 
 	ret = da9063_clear_fault_log(da9063);
 	if (ret < 0)
@@ -225,9 +225,13 @@ int da9063_device_init(struct da9063 *da9063, unsigned int irq)
 
 	da9063->irq_base = regmap_irq_chip_get_base(da9063->regmap_irq);
 
-	ret = mfd_add_devices(da9063->dev, -1, da9063_devs,
-			      ARRAY_SIZE(da9063_devs), NULL, da9063->irq_base,
-			      NULL);
+	da9063_devs_len = ARRAY_SIZE(da9063_devs);
+	/* RTC, the last device in the list, is only present on DA9063 */
+	if (da9063->type == PMIC_TYPE_DA9063L)
+		da9063_devs_len -= 1;
+
+	ret = mfd_add_devices(da9063->dev, -1, da9063_devs, da9063_devs_len,
+			      NULL, da9063->irq_base, NULL);
 	if (ret)
 		dev_err(da9063->dev, "Cannot add MFD cells\n");
 
-- 
2.16.2

[PATCH 5/6] mfd: da9063: Handle less LDOs on DA9063L

[Marek Vasut]

Move the LDOs present only on DA9063 at the end of the list, so that
the DA9063L can simply indicate less LDOs and still share the list of
regulators with DA9063.

Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Lee Jones <lee.jones@linaro.org>
Cc: Mark Brown <broonie@kernel.org>
Cc: Steve Twiss <stwiss.opensource@diasemi.com>
Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>
Cc: linux-renesas-soc@vger.kernel.org
---
 drivers/regulator/da9063-regulator.c | 76 +++++++++++++++++++++---------------
 1 file changed, 45 insertions(+), 31 deletions(-)

diff --git a/drivers/regulator/da9063-regulator.c b/drivers/regulator/da9063-regulator.c
index 9b5c28392ae6..92569bed24b9 100644
--- a/drivers/regulator/da9063-regulator.c
+++ b/drivers/regulator/da9063-regulator.c
@@ -529,6 +529,32 @@ static const struct da9063_regulator_info da9063_regulator_info[] = {
 		.ilimit = BFIELD(DA9063_REG_BUCK_ILIM_A,
 				 DA9063_BMEM_ILIM_MASK),
 	},
+	{
+		DA9063_LDO(DA9063, LDO3, 900, 20, 3440),
+		.suspend = BFIELD(DA9063_REG_DVC_1, DA9063_VLDO3_SEL),
+		.oc_event = BFIELD(DA9063_REG_STATUS_D, DA9063_LDO3_LIM),
+	},
+	{
+		DA9063_LDO(DA9063, LDO7, 900, 50, 3600),
+		.suspend = BFIELD(DA9063_REG_LDO7_CONT, DA9063_VLDO7_SEL),
+		.oc_event = BFIELD(DA9063_REG_STATUS_D, DA9063_LDO7_LIM),
+	},
+	{
+		DA9063_LDO(DA9063, LDO8, 900, 50, 3600),
+		.suspend = BFIELD(DA9063_REG_LDO8_CONT, DA9063_VLDO8_SEL),
+		.oc_event = BFIELD(DA9063_REG_STATUS_D, DA9063_LDO8_LIM),
+	},
+	{
+		DA9063_LDO(DA9063, LDO9, 950, 50, 3600),
+		.suspend = BFIELD(DA9063_REG_LDO9_CONT, DA9063_VLDO9_SEL),
+	},
+	{
+		DA9063_LDO(DA9063, LDO11, 900, 50, 3600),
+		.suspend = BFIELD(DA9063_REG_LDO11_CONT, DA9063_VLDO11_SEL),
+		.oc_event = BFIELD(DA9063_REG_STATUS_D, DA9063_LDO11_LIM),
+	},
+
+	/* The following LDOs are present only on DA9063, not on DA9063L */
 	{
 		DA9063_LDO(DA9063, LDO1, 600, 20, 1860),
 		.suspend = BFIELD(DA9063_REG_DVC_1, DA9063_VLDO1_SEL),
@@ -537,11 +563,6 @@ static const struct da9063_regulator_info da9063_regulator_info[] = {
 		DA9063_LDO(DA9063, LDO2, 600, 20, 1860),
 		.suspend = BFIELD(DA9063_REG_DVC_1, DA9063_VLDO2_SEL),
 	},
-	{
-		DA9063_LDO(DA9063, LDO3, 900, 20, 3440),
-		.suspend = BFIELD(DA9063_REG_DVC_1, DA9063_VLDO3_SEL),
-		.oc_event = BFIELD(DA9063_REG_STATUS_D, DA9063_LDO3_LIM),
-	},
 	{
 		DA9063_LDO(DA9063, LDO4, 900, 20, 3440),
 		.suspend = BFIELD(DA9063_REG_DVC_2, DA9063_VLDO4_SEL),
@@ -555,29 +576,11 @@ static const struct da9063_regulator_info da9063_regulator_info[] = {
 		DA9063_LDO(DA9063, LDO6, 900, 50, 3600),
 		.suspend = BFIELD(DA9063_REG_LDO6_CONT, DA9063_VLDO6_SEL),
 	},
-	{
-		DA9063_LDO(DA9063, LDO7, 900, 50, 3600),
-		.suspend = BFIELD(DA9063_REG_LDO7_CONT, DA9063_VLDO7_SEL),
-		.oc_event = BFIELD(DA9063_REG_STATUS_D, DA9063_LDO7_LIM),
-	},
-	{
-		DA9063_LDO(DA9063, LDO8, 900, 50, 3600),
-		.suspend = BFIELD(DA9063_REG_LDO8_CONT, DA9063_VLDO8_SEL),
-		.oc_event = BFIELD(DA9063_REG_STATUS_D, DA9063_LDO8_LIM),
-	},
-	{
-		DA9063_LDO(DA9063, LDO9, 950, 50, 3600),
-		.suspend = BFIELD(DA9063_REG_LDO9_CONT, DA9063_VLDO9_SEL),
-	},
+
 	{
 		DA9063_LDO(DA9063, LDO10, 900, 50, 3600),
 		.suspend = BFIELD(DA9063_REG_LDO10_CONT, DA9063_VLDO10_SEL),
 	},
-	{
-		DA9063_LDO(DA9063, LDO11, 900, 50, 3600),
-		.suspend = BFIELD(DA9063_REG_LDO11_CONT, DA9063_VLDO11_SEL),
-		.oc_event = BFIELD(DA9063_REG_STATUS_D, DA9063_LDO11_LIM),
-	},
 };
 
 /* Link chip model with regulators info table */
@@ -587,6 +590,11 @@ static struct da9063_dev_model regulators_models[] = {
 		.n_regulators = ARRAY_SIZE(da9063_regulator_info),
 		.type = PMIC_TYPE_DA9063,
 	},
+	{
+		.regulator_info = da9063_regulator_info,
+		.n_regulators = ARRAY_SIZE(da9063_regulator_info) - 6,
+		.type = PMIC_TYPE_DA9063L,
+	},
 	{ }
 };
 
@@ -641,28 +649,34 @@ static struct of_regulator_match da9063_matches[] = {
 	[DA9063_ID_BPERI]            = { .name = "bperi",           },
 	[DA9063_ID_BCORES_MERGED]    = { .name = "bcores-merged"    },
 	[DA9063_ID_BMEM_BIO_MERGED]  = { .name = "bmem-bio-merged", },
+	[DA9063_ID_LDO3]             = { .name = "ldo3",            },
+	[DA9063_ID_LDO7]             = { .name = "ldo7",            },
+	[DA9063_ID_LDO8]             = { .name = "ldo8",            },
+	[DA9063_ID_LDO9]             = { .name = "ldo9",            },
+	[DA9063_ID_LDO11]            = { .name = "ldo11",           },
+	/* The following LDOs are present only on DA9063, not on DA9063L */
 	[DA9063_ID_LDO1]             = { .name = "ldo1",            },
 	[DA9063_ID_LDO2]             = { .name = "ldo2",            },
-	[DA9063_ID_LDO3]             = { .name = "ldo3",            },
 	[DA9063_ID_LDO4]             = { .name = "ldo4",            },
 	[DA9063_ID_LDO5]             = { .name = "ldo5",            },
 	[DA9063_ID_LDO6]             = { .name = "ldo6",            },
-	[DA9063_ID_LDO7]             = { .name = "ldo7",            },
-	[DA9063_ID_LDO8]             = { .name = "ldo8",            },
-	[DA9063_ID_LDO9]             = { .name = "ldo9",            },
 	[DA9063_ID_LDO10]            = { .name = "ldo10",           },
-	[DA9063_ID_LDO11]            = { .name = "ldo11",           },
 };
 
 static struct da9063_regulators_pdata *da9063_parse_regulators_dt(
 		struct platform_device *pdev,
 		struct of_regulator_match **da9063_reg_matches)
 {
+	struct da9063 *da9063 = dev_get_drvdata(pdev->dev.parent);
 	struct da9063_regulators_pdata *pdata;
 	struct da9063_regulator_data *rdata;
 	struct device_node *node;
+	int da9063_matches_len = ARRAY_SIZE(da9063_matches);
 	int i, n, num;
 
+	if (da9063->type == PMIC_TYPE_DA9063L)
+		da9063_matches_len -= 6;
+
 	node = of_get_child_by_name(pdev->dev.parent->of_node, "regulators");
 	if (!node) {
 		dev_err(&pdev->dev, "Regulators device node not found\n");
@@ -670,7 +684,7 @@ static struct da9063_regulators_pdata *da9063_parse_regulators_dt(
 	}
 
 	num = of_regulator_match(&pdev->dev, node, da9063_matches,
-				 ARRAY_SIZE(da9063_matches));
+				 da9063_matches_len);
 	of_node_put(node);
 	if (num < 0) {
 		dev_err(&pdev->dev, "Failed to match regulators\n");
@@ -689,7 +703,7 @@ static struct da9063_regulators_pdata *da9063_parse_regulators_dt(
 	pdata->n_regulators = num;
 
 	n = 0;
-	for (i = 0; i < ARRAY_SIZE(da9063_matches); i++) {
+	for (i = 0; i < da9063_matches_len; i++) {
 		if (!da9063_matches[i].init_data)
 			continue;
 
-- 
2.16.2

[PATCH 6/6] mfd: da9063: Add DA9063L support

[Marek Vasut]

Add support for DA9063L, which is a reduced variant of the DA9063
with less regulators and without RTC.

Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Lee Jones <lee.jones@linaro.org>
Cc: Mark Brown <broonie@kernel.org>
Cc: Steve Twiss <stwiss.opensource@diasemi.com>
Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>
Cc: linux-renesas-soc@vger.kernel.org
---
 drivers/mfd/da9063-i2c.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mfd/da9063-i2c.c b/drivers/mfd/da9063-i2c.c
index 5544ce8e3363..84bbd2bbcd2a 100644
--- a/drivers/mfd/da9063-i2c.c
+++ b/drivers/mfd/da9063-i2c.c
@@ -232,6 +232,7 @@ static struct regmap_config da9063_regmap_config = {
 
 static const struct of_device_id da9063_dt_ids[] = {
 	{ .compatible = "dlg,da9063", },
+	{ .compatible = "dlg,da9063l", },
 	{ }
 };
 MODULE_DEVICE_TABLE(of, da9063_dt_ids);
@@ -282,6 +283,7 @@ static int da9063_i2c_remove(struct i2c_client *i2c)
 
 static const struct i2c_device_id da9063_i2c_id[] = {
 	{ "da9063", PMIC_TYPE_DA9063 },
+	{ "da9063l", PMIC_TYPE_DA9063L },
 	{},
 };
 MODULE_DEVICE_TABLE(i2c, da9063_i2c_id);
-- 
2.16.2

Re: [PATCH 1/6] mfd: da9063: Rename PMIC_DA9063 to PMIC_CHIP_ID_DA9063

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 313 bytes --]

On Wed, May 23, 2018 at 01:42:25PM +0200, Marek Vasut wrote:
> The PMIC_DA9063 is a complete misnomer, it denotes the value of the
> DA9063 chip ID register, so rename it as such. It is also the value
> of chip ID register of DA9063L though, so drop the enum as all the

Acked-by: Mark Brown <broonie@kernel.org>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 2/6] mfd: da9063: Replace model with type

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 304 bytes --]

On Wed, May 23, 2018 at 01:42:26PM +0200, Marek Vasut wrote:
> The model number stored in the struct da9063 is the same for all
> variants of the da9063 since it is the chip ID, which is always
> the same. Replace that with a separate identifier instead, which

Acked-by: Mark Brown <broonie@kernel.org>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 5/6] mfd: da9063: Handle less LDOs on DA9063L

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 273 bytes --]

On Wed, May 23, 2018 at 01:42:29PM +0200, Marek Vasut wrote:
> Move the LDOs present only on DA9063 at the end of the list, so that
> the DA9063L can simply indicate less LDOs and still share the list of
> regulators with DA9063.

Acked-by: Mark Brown <broonie@kernel.org>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 6/6] mfd: da9063: Add DA9063L support

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 212 bytes --]

On Wed, May 23, 2018 at 01:42:30PM +0200, Marek Vasut wrote:
> Add support for DA9063L, which is a reduced variant of the DA9063
> with less regulators and without RTC.

Acked-by: Mark Brown <broonie@kernel.org>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 1/6] mfd: da9063: Rename PMIC_DA9063 to PMIC_CHIP_ID_DA9063

[Geert Uytterhoeven]

On Wed, May 23, 2018 at 1:42 PM, Marek Vasut <marek.vasut@gmail.com> wrote:
> The PMIC_DA9063 is a complete misnomer, it denotes the value of the
> DA9063 chip ID register, so rename it as such. It is also the value
> of chip ID register of DA9063L though, so drop the enum as all the
> DA9063 "models" share the same chip ID and thus the distinction will
> have to be made using DT or otherwise.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 2/6] mfd: da9063: Replace model with type

[Geert Uytterhoeven]

On Wed, May 23, 2018 at 1:42 PM, Marek Vasut <marek.vasut@gmail.com> wrote:
> The model number stored in the struct da9063 is the same for all
> variants of the da9063 since it is the chip ID, which is always
> the same. Replace that with a separate identifier instead, which
> allows us to discern the DA9063 variants by setting the type
> based on either DT match or otherwise.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>

> --- a/drivers/mfd/da9063-i2c.c
> +++ b/drivers/mfd/da9063-i2c.c
> @@ -248,6 +248,7 @@ static int da9063_i2c_probe(struct i2c_client *i2c,
>         i2c_set_clientdata(i2c, da9063);
>         da9063->dev = &i2c->dev;
>         da9063->chip_irq = i2c->irq;
> +       da9063->type = (enum da9063_type)id->driver_data;

Nit: I think this cast (from unsigned long) is not needed.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 3/6] mfd: da9063: Add DA9063L type

[Geert Uytterhoeven]

On Wed, May 23, 2018 at 1:42 PM, Marek Vasut <marek.vasut@gmail.com> wrote:
> Add type for DA9063L, which is a reduced variant of the DA9063
> without RTC block and with less regulators.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 4/6] mfd: da9063: Disallow RTC on DA9063L

[Geert Uytterhoeven]

On Wed, May 23, 2018 at 1:42 PM, Marek Vasut <marek.vasut@gmail.com> wrote:
> The DA9063L does not contain RTC block, unlike the full DA9063.
> Do not allow binding RTC driver on this variant of the chip.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 5/6] mfd: da9063: Handle less LDOs on DA9063L

[Geert Uytterhoeven]

On Wed, May 23, 2018 at 1:42 PM, Marek Vasut <marek.vasut@gmail.com> wrote:
> Move the LDOs present only on DA9063 at the end of the list, so that
> the DA9063L can simply indicate less LDOs and still share the list of
> regulators with DA9063.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 6/6] mfd: da9063: Add DA9063L support

[Geert Uytterhoeven]

On Wed, May 23, 2018 at 1:42 PM, Marek Vasut <marek.vasut@gmail.com> wrote:
> Add support for DA9063L, which is a reduced variant of the DA9063
> with less regulators and without RTC.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 2/6] mfd: da9063: Replace model with type

[Marek Vasut]

On 05/23/2018 01:55 PM, Geert Uytterhoeven wrote:
> On Wed, May 23, 2018 at 1:42 PM, Marek Vasut <marek.vasut@gmail.com> wrote:
>> The model number stored in the struct da9063 is the same for all
>> variants of the da9063 since it is the chip ID, which is always
>> the same. Replace that with a separate identifier instead, which
>> allows us to discern the DA9063 variants by setting the type
>> based on either DT match or otherwise.
>>
>> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
> 
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> 
>> --- a/drivers/mfd/da9063-i2c.c
>> +++ b/drivers/mfd/da9063-i2c.c
>> @@ -248,6 +248,7 @@ static int da9063_i2c_probe(struct i2c_client *i2c,
>>         i2c_set_clientdata(i2c, da9063);
>>         da9063->dev = &i2c->dev;
>>         da9063->chip_irq = i2c->irq;
>> +       da9063->type = (enum da9063_type)id->driver_data;
> 
> Nit: I think this cast (from unsigned long) is not needed.

Dropped

-- 
Best regards,
Marek Vasut

RE: [PATCH 6/6] mfd: da9063: Add DA9063L support

[Steve Twiss]

Thanks Marek,

> On 23 May 2018 12:43 Marek Vasut wrote,
>
> To: linux-kernel@vger.kernel.org
> Cc: Marek Vasut <marek.vasut+renesas@gmail.com>; Geert Uytterhoeven <geert+renesas@glider.be>;
> Lee Jones <lee.jones@linaro.org>; Mark Brown <broonie@kernel.org>; Steve Twiss <stwiss.opensource@diasemi.com>;
> Wolfram Sang <wsa+renesas@sang-engineering.com>; linux-renesas-soc@vger.kernel.org
> Subject: [PATCH 6/6] mfd: da9063: Add DA9063L support
>
> Add support for DA9063L, which is a reduced variant of the DA9063 with less regulators and without RTC.
>

There's potentially more to this file. Without an RTC the regmap access tables would change and the
usual DA9063 (BB silicon) tables would become invalid.
The tables for da9063_bb_readable_ranges, da9063_bb_writeable_ranges, da9063_bb_volatile_ranges,
would need to be updated for DA9063L, if a new chip model was needed.

The new ranges would be this (see below), and would remove any RTC accesses in the new chip model.

static const struct regmap_range da9063l_bb_readable_ranges[] = {
	{
		.range_min = DA9063_REG_PAGE_CON,
		.range_max = DA9063_REG_MON_A10_RES,
	}, {
		.range_min = DA9063_REG_SEQ,
		.range_max = DA9063_REG_ID_32_31,
	}, {
		.range_min = DA9063_REG_SEQ_A,
		.range_max = DA9063_REG_AUTO3_LOW,
	}, {
		.range_min = DA9063_REG_T_OFFSET,
		.range_max = DA9063_BB_REG_GP_ID_19,
	}, {
		.range_min = DA9063_REG_CHIP_ID,
		.range_max = DA9063_REG_CHIP_VARIANT,
	},
};

static const struct regmap_range da9063l_bb_writeable_ranges[] = {
	{
		.range_min = DA9063_REG_PAGE_CON,
		.range_max = DA9063_REG_PAGE_CON,
	}, {
		.range_min = DA9063_REG_FAULT_LOG,
		.range_max = DA9063_REG_VSYS_MON,
	}, {
		.range_min = DA9063_REG_SEQ,
		.range_max = DA9063_REG_ID_32_31,
	}, {
		.range_min = DA9063_REG_SEQ_A,
		.range_max = DA9063_REG_AUTO3_LOW,
	}, {
		.range_min = DA9063_REG_CONFIG_I,
		.range_max = DA9063_BB_REG_MON_REG_4,
	}, {
		.range_min = DA9063_BB_REG_GP_ID_0,
		.range_max = DA9063_BB_REG_GP_ID_19,
	},
};

static const struct regmap_range da9063l_bb_volatile_ranges[] = {
	{
		.range_min = DA9063_REG_PAGE_CON,
		.range_max = DA9063_REG_EVENT_D,
	}, {
		.range_min = DA9063_REG_CONTROL_A,
		.range_max = DA9063_REG_CONTROL_B,
	}, {
		.range_min = DA9063_REG_CONTROL_E,
		.range_max = DA9063_REG_CONTROL_F,
	}, {
		.range_min = DA9063_REG_BCORE2_CONT,
		.range_max = DA9063_REG_LDO11_CONT,
	}, {
		.range_min = DA9063_REG_DVC_1,
		.range_max = DA9063_REG_ADC_MAN,
	}, {
		.range_min = DA9063_REG_ADC_RES_L,
		.range_max = DA9063_REG_MON_A10_RES,
	}, {
		.range_min = DA9063_REG_SEQ,
		.range_max = DA9063_REG_SEQ,
	}, {
		.range_min = DA9063_REG_EN_32K,
		.range_max = DA9063_REG_EN_32K,
	}, {
		.range_min = DA9063_BB_REG_MON_REG_5,
		.range_max = DA9063_BB_REG_MON_REG_6,
	},
};

However this is a larger and more wide-ranging change compared to the one proposed by Marek,
and would require other alterations to fit this in. Also I'm undecided to what it would really add
apart from a new chip model: I have been told accessing the DA9063 RTC register locations has
no effect in the DA9063L.

If the maintainers are happy with this, and if a chip model addition is really needed in future
it can be added later if required.

Acked-by: Steve Twiss <stwiss.opensource@diasemi.com>

Regards,
Steve

> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> Cc: Lee Jones <lee.jones@linaro.org>
> Cc: Mark Brown <broonie@kernel.org>
> Cc: Steve Twiss <stwiss.opensource@diasemi.com>
> Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>
> Cc: linux-renesas-soc@vger.kernel.org
> ---
>  drivers/mfd/da9063-i2c.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/mfd/da9063-i2c.c b/drivers/mfd/da9063-i2c.c index 5544ce8e3363..84bbd2bbcd2a 100644
> --- a/drivers/mfd/da9063-i2c.c
> +++ b/drivers/mfd/da9063-i2c.c
> @@ -232,6 +232,7 @@ static struct regmap_config da9063_regmap_config = {
>  
>  static const struct of_device_id da9063_dt_ids[] = {
>  	{ .compatible = "dlg,da9063", },
> +	{ .compatible = "dlg,da9063l", },
>  	{ }
>  };
>  MODULE_DEVICE_TABLE(of, da9063_dt_ids); @@ -282,6 +283,7 @@ static int da9063_i2c_remove(struct i2c_client *i2c)
>  
>  static const struct i2c_device_id da9063_i2c_id[] = {
>  	{ "da9063", PMIC_TYPE_DA9063 },
> +	{ "da9063l", PMIC_TYPE_DA9063L },
>  	{},
>  };
>  MODULE_DEVICE_TABLE(i2c, da9063_i2c_id);
> --
> 2.16.2

RE: [PATCH 1/6] mfd: da9063: Rename PMIC_DA9063 to PMIC_CHIP_ID_DA9063

[Steve Twiss]

Hi Marek,

On 23 May 2018 12:42 Marek Vasut wrote:

> To: linux-kernel@vger.kernel.org
> Cc: Marek Vasut <marek.vasut+renesas@gmail.com>; Geert Uytterhoeven <geert+renesas@glider.be>; Lee Jones <lee.jones@linaro.org>; Mark Brown <broonie@kernel.org>; Steve Twiss <stwiss.opensource@diasemi.com>; Wolfram Sang <wsa+renesas@sang-engineering.com>; linux-renesas-soc@vger.kernel.org
> Subject: [PATCH 1/6] mfd: da9063: Rename PMIC_DA9063 to PMIC_CHIP_ID_DA9063
>
> The PMIC_DA9063 is a complete misnomer, it denotes the value of the
> DA9063 chip ID register, so rename it as such. It is also the value of chip ID register of DA9063L though, so drop the enum as all the
> DA9063 "models" share the same chip ID and thus the distinction will have to be made using DT or otherwise.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> Cc: Lee Jones <lee.jones@linaro.org>
> Cc: Mark Brown <broonie@kernel.org>
> Cc: Steve Twiss <stwiss.opensource@diasemi.com>
> Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>
> Cc: linux-renesas-soc@vger.kernel.org
> ---
>  drivers/mfd/da9063-core.c            | 2 +-
>  drivers/mfd/da9063-i2c.c             | 2 +-
>  drivers/regulator/da9063-regulator.c | 2 +-
>  include/linux/mfd/da9063/core.h      | 4 +---
>  4 files changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/mfd/da9063-core.c b/drivers/mfd/da9063-core.c index 6c2870d4e754..00b3caee4e21 100644
> --- a/drivers/mfd/da9063-core.c
> +++ b/drivers/mfd/da9063-core.c
> @@ -192,7 +192,7 @@ int da9063_device_init(struct da9063 *da9063, unsigned int irq)
>  		dev_err(da9063->dev, "Cannot read chip model id.\n");
>  		return -EIO;
>  	}
> -	if (model != PMIC_DA9063) {
> +	if (model != PMIC_CHIP_ID_DA9063) {
>  		dev_err(da9063->dev, "Invalid chip model id: 0x%02x\n", model);
>  		return -ENODEV;
>  	}
> diff --git a/drivers/mfd/da9063-i2c.c b/drivers/mfd/da9063-i2c.c index 981805a2c521..7f84030c8d53 100644
> --- a/drivers/mfd/da9063-i2c.c
> +++ b/drivers/mfd/da9063-i2c.c
> @@ -280,7 +280,7 @@ static int da9063_i2c_remove(struct i2c_client *i2c)  }
>  
>  static const struct i2c_device_id da9063_i2c_id[] = {
> -	{"da9063", PMIC_DA9063},
> +	{ "da9063", PMIC_CHIP_ID_DA9063 },
>  	{},
>  };
>  MODULE_DEVICE_TABLE(i2c, da9063_i2c_id); diff --git a/drivers/regulator/da9063-regulator.c b/drivers/regulator/da9063-regulator.c
> index 6a8f9cd69f52..87c884ae0064 100644
> --- a/drivers/regulator/da9063-regulator.c
> +++ b/drivers/regulator/da9063-regulator.c
> @@ -585,7 +585,7 @@ static struct da9063_dev_model regulators_models[] = {
>  	{
>  		.regulator_info = da9063_regulator_info,
>  		.n_regulators = ARRAY_SIZE(da9063_regulator_info),
> -		.dev_model = PMIC_DA9063,
> +		.dev_model = PMIC_CHIP_ID_DA9063,
>  	},
>  	{ }
>  };
> diff --git a/include/linux/mfd/da9063/core.h b/include/linux/mfd/da9063/core.h index f3ae65db4c86..664f650d0086 100644
> --- a/include/linux/mfd/da9063/core.h
> +++ b/include/linux/mfd/da9063/core.h
> @@ -29,9 +29,7 @@
>  #define DA9063_DRVNAME_RTC		"da9063-rtc"
>  #define DA9063_DRVNAME_VIBRATION	"da9063-vibration"
>  
> -enum da9063_models {
> -	PMIC_DA9063 = 0x61,
> -};
> +#define PMIC_CHIP_ID_DA9063		0x61
>  
>  enum da9063_variant_codes {
>  	PMIC_DA9063_AD = 0x3,
> --
> 2.16.2

Acked-by: Steve Twiss <stwiss.opensource@diasemi.com>

Regards,
Steve

RE: [PATCH 6/6] mfd: da9063: Add DA9063L support

[Steve Twiss]

Hi Marek,

On 24 May 2018 @ 12:49 Steve Twiss wrote:

> To: Marek Vasut <marek.vasut@gmail.com>; linux-kernel@vger.kernel.org
> Cc: Marek Vasut <marek.vasut+renesas@gmail.com>; Geert Uytterhoeven <geert+renesas@glider.be>; Lee Jones <lee.jones@linaro.org>; Mark Brown <broonie@kernel.org>; Steve Twiss <stwiss.opensource@diasemi.com>; Wolfram Sang <wsa+renesas@sang-engineering.com>; linux-renesas-soc@vger.kernel.org
> Subject: RE: [PATCH 6/6] mfd: da9063: Add DA9063L support
>
> Thanks Marek,
>
> > On 23 May 2018 12:43 Marek Vasut wrote,
> >
> > To: linux-kernel@vger.kernel.org
> > Cc: Marek Vasut <marek.vasut+renesas@gmail.com>; Geert Uytterhoeven <geert+renesas@glider.be>; Lee Jones <lee.jones@linaro.org>;
> > Mark Brown <broonie@kernel.org>; Steve Twiss <stwiss.opensource@diasemi.com>; Wolfram Sang <wsa+renesas@sang-engineering.com>; linux-renesas-soc@vger.kernel.org
> > Subject: [PATCH 6/6] mfd: da9063: Add DA9063L support
> >
> > Add support for DA9063L, which is a reduced variant of the DA9063 with less regulators and without RTC.
> >
>
> There's potentially more to this file. Without an RTC the regmap access tables would change
> and the usual DA9063 (BB silicon) tables would become invalid.
> The tables for da9063_bb_readable_ranges, da9063_bb_writeable_ranges, da9063_bb_volatile_ranges,
> would need to be updated for DA9063L, if a new chip model was needed.
>
> The new ranges would be this (see below), and would remove any RTC accesses in the new chip model.
>
> static const struct regmap_range da9063l_bb_readable_ranges[] = {
>	{
>		.range_min = DA9063_REG_PAGE_CON,
>		.range_max = DA9063_REG_MON_A10_RES,
>	}, {
>		.range_min = DA9063_REG_SEQ,
>		.range_max = DA9063_REG_ID_32_31,
>	}, {
>		.range_min = DA9063_REG_SEQ_A,
>		.range_max = DA9063_REG_AUTO3_LOW,
>	}, {
>		.range_min = DA9063_REG_T_OFFSET,
>		.range_max = DA9063_BB_REG_GP_ID_19,
>	}, {
>		.range_min = DA9063_REG_CHIP_ID,
>		.range_max = DA9063_REG_CHIP_VARIANT,
>	},
> };
>
> static const struct regmap_range da9063l_bb_writeable_ranges[] = {
>	{
>		.range_min = DA9063_REG_PAGE_CON,
>		.range_max = DA9063_REG_PAGE_CON,
>	}, {
>		.range_min = DA9063_REG_FAULT_LOG,
>		.range_max = DA9063_REG_VSYS_MON,
>	}, {
>		.range_min = DA9063_REG_SEQ,
>		.range_max = DA9063_REG_ID_32_31,
>	}, {
>		.range_min = DA9063_REG_SEQ_A,
>		.range_max = DA9063_REG_AUTO3_LOW,
>	}, {
>		.range_min = DA9063_REG_CONFIG_I,
>		.range_max = DA9063_BB_REG_MON_REG_4,
>	}, {
>		.range_min = DA9063_BB_REG_GP_ID_0,
>		.range_max = DA9063_BB_REG_GP_ID_19,
>	},
> };
>
> static const struct regmap_range da9063l_bb_volatile_ranges[] = {
>	{
>		.range_min = DA9063_REG_PAGE_CON,
>		.range_max = DA9063_REG_EVENT_D,
>	}, {
>		.range_min = DA9063_REG_CONTROL_A,
>		.range_max = DA9063_REG_CONTROL_B,
>	}, {
>		.range_min = DA9063_REG_CONTROL_E,
>		.range_max = DA9063_REG_CONTROL_F,
>	}, {
>		.range_min = DA9063_REG_BCORE2_CONT,
>		.range_max = DA9063_REG_LDO11_CONT,
>	}, {
>		.range_min = DA9063_REG_DVC_1,
>		.range_max = DA9063_REG_ADC_MAN,
>	}, {
>		.range_min = DA9063_REG_ADC_RES_L,
>		.range_max = DA9063_REG_MON_A10_RES,
>	}, {
>		.range_min = DA9063_REG_SEQ,
>		.range_max = DA9063_REG_SEQ,
>	}, {
>		.range_min = DA9063_REG_EN_32K,
>		.range_max = DA9063_REG_EN_32K,
>	}, {
>		.range_min = DA9063_BB_REG_MON_REG_5,
>		.range_max = DA9063_BB_REG_MON_REG_6,
>	},
> };
>
> However this is a larger and more wide-ranging change compared to the one proposed by Marek,
> and would require other alterations to fit this in. Also I'm undecided to what it would really add 
> apart from a new chip model: I have been told accessing the DA9063 RTC register locations has no
> effect in the DA9063L.

Looking at this further, there is also a new IRQ regmap.
Again this comes down to whether a full chip model is needed or not. If not, then the IRQ map does not
need to be changed as given. Otherwise the removal of the following:

	[DA9063_IRQ_ALARM] = {
		.reg_offset = DA9063_REG_EVENT_A_OFFSET,
		.mask = DA9063_M_ALARM,
	},
	[DA9063_IRQ_TICK] = {
		.reg_offset = DA9063_REG_EVENT_A_OFFSET,
		.mask = DA9063_M_TICK,
	},

prior to registering the IRQs in the chip model would be needed.
The new regmap_irq would be:

static const struct regmap_irq da9063l_irqs[] = {
	/* DA9063 event A register */
	[DA9063L_IRQ_ONKEY] = {
		.reg_offset = DA9063_REG_EVENT_A_OFFSET,
		.mask = DA9063_M_ONKEY,
	},
	[DA9063L_IRQ_ADC_RDY] = {
		.reg_offset = DA9063_REG_EVENT_A_OFFSET,
		.mask = DA9063_M_ADC_RDY,
	},
	[DA9063L_IRQ_SEQ_RDY] = {
		.reg_offset = DA9063_REG_EVENT_A_OFFSET,
		.mask = DA9063_M_SEQ_RDY,
	},
	/* DA9063 event B register */
	[DA9063L_IRQ_WAKE] = {
		.reg_offset = DA9063_REG_EVENT_B_OFFSET,
		.mask = DA9063_M_WAKE,
	},
	[DA9063L_IRQ_TEMP] = {
		.reg_offset = DA9063_REG_EVENT_B_OFFSET,
		.mask = DA9063_M_TEMP,
	},
	[DA9063L_IRQ_COMP_1V2] = {
		.reg_offset = DA9063_REG_EVENT_B_OFFSET,
		.mask = DA9063_M_COMP_1V2,
	},
	[DA9063L_IRQ_LDO_LIM] = {
		.reg_offset = DA9063_REG_EVENT_B_OFFSET,
		.mask = DA9063_M_LDO_LIM,
	},
	[DA9063L_IRQ_REG_UVOV] = {
		.reg_offset = DA9063_REG_EVENT_B_OFFSET,
		.mask = DA9063_M_UVOV,
	},
	[DA9063L_IRQ_DVC_RDY] = {
		.reg_offset = DA9063_REG_EVENT_B_OFFSET,
		.mask = DA9063_M_DVC_RDY,
	},
	[DA9063L_IRQ_VDD_MON] = {
		.reg_offset = DA9063_REG_EVENT_B_OFFSET,
		.mask = DA9063_M_VDD_MON,
	},
	[DA9063L_IRQ_WARN] = {
		.reg_offset = DA9063_REG_EVENT_B_OFFSET,
		.mask = DA9063_M_VDD_WARN,
	},
	/* DA9063 event C register */
	[DA9063L_IRQ_GPI0] = {
		.reg_offset = DA9063_REG_EVENT_C_OFFSET,
		.mask = DA9063_M_GPI0,
	},
	[DA9063L_IRQ_GPI1] = {
		.reg_offset = DA9063_REG_EVENT_C_OFFSET,
		.mask = DA9063_M_GPI1,
	},
	[DA9063L_IRQ_GPI2] = {
		.reg_offset = DA9063_REG_EVENT_C_OFFSET,
		.mask = DA9063_M_GPI2,
	},
	[DA9063L_IRQ_GPI3] = {
		.reg_offset = DA9063_REG_EVENT_C_OFFSET,
		.mask = DA9063_M_GPI3,
	},
	[DA9063L_IRQ_GPI4] = {
		.reg_offset = DA9063_REG_EVENT_C_OFFSET,
		.mask = DA9063_M_GPI4,
	},
	[DA9063L_IRQ_GPI5] = {
		.reg_offset = DA9063_REG_EVENT_C_OFFSET,
		.mask = DA9063_M_GPI5,
	},
	[DA9063L_IRQ_GPI6] = {
		.reg_offset = DA9063_REG_EVENT_C_OFFSET,
		.mask = DA9063_M_GPI6,
	},
	[DA9063L_IRQ_GPI7] = {
		.reg_offset = DA9063_REG_EVENT_C_OFFSET,
		.mask = DA9063_M_GPI7,
	},
	/* DA9063 event D register */
	[DA9063L_IRQ_GPI8] = {
		.reg_offset = DA9063_REG_EVENT_D_OFFSET,
		.mask = DA9063_M_GPI8,
	},
	[DA9063L_IRQ_GPI9] = {
		.reg_offset = DA9063_REG_EVENT_D_OFFSET,
		.mask = DA9063_M_GPI9,
	},
	[DA9063L_IRQ_GPI10] = {
		.reg_offset = DA9063_REG_EVENT_D_OFFSET,
		.mask = DA9063_M_GPI10,
	},
	[DA9063L_IRQ_GPI11] = {
		.reg_offset = DA9063_REG_EVENT_D_OFFSET,
		.mask = DA9063_M_GPI11,
	},
	[DA9063L_IRQ_GPI12] = {
		.reg_offset = DA9063_REG_EVENT_D_OFFSET,
		.mask = DA9063_M_GPI12,
	},
	[DA9063L_IRQ_GPI13] = {
		.reg_offset = DA9063_REG_EVENT_D_OFFSET,
		.mask = DA9063_M_GPI13,
	},
	[DA9063L_IRQ_GPI14] = {
		.reg_offset = DA9063_REG_EVENT_D_OFFSET,
		.mask = DA9063_M_GPI14,
	},
	[DA9063L_IRQ_GPI15] = {
		.reg_offset = DA9063_REG_EVENT_D_OFFSET,
		.mask = DA9063_M_GPI15,
	},
};

Regards,
Steve

>
> If the maintainers are happy with this, and if a chip model addition is really needed in future it can
> be added later if required.
>
> Acked-by: Steve Twiss <stwiss.opensource@diasemi.com>
>
> Regards,
> Steve

> > Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
> > Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> > Cc: Lee Jones <lee.jones@linaro.org>
> > Cc: Mark Brown <broonie@kernel.org>
> > Cc: Steve Twiss <stwiss.opensource@diasemi.com>
> > Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>
> > Cc: linux-renesas-soc@vger.kernel.org
> > ---
> >  drivers/mfd/da9063-i2c.c | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/mfd/da9063-i2c.c b/drivers/mfd/da9063-i2c.c index 
> > 5544ce8e3363..84bbd2bbcd2a 100644
> > --- a/drivers/mfd/da9063-i2c.c
> > +++ b/drivers/mfd/da9063-i2c.c
> > @@ -232,6 +232,7 @@ static struct regmap_config da9063_regmap_config = 
> > {
> >  
> >  static const struct of_device_id da9063_dt_ids[] = {
> >  	{ .compatible = "dlg,da9063", },
> > +	{ .compatible = "dlg,da9063l", },
> >  	{ }
> >  };
> >  MODULE_DEVICE_TABLE(of, da9063_dt_ids); @@ -282,6 +283,7 @@ static 
> > int da9063_i2c_remove(struct i2c_client *i2c)
> >  
> >  static const struct i2c_device_id da9063_i2c_id[] = {
> >  	{ "da9063", PMIC_TYPE_DA9063 },
> > +	{ "da9063l", PMIC_TYPE_DA9063L },
> >  	{},
> >  };
> >  MODULE_DEVICE_TABLE(i2c, da9063_i2c_id);
> > --
> > 2.16.2

RE: [PATCH 4/6] mfd: da9063: Disallow RTC on DA9063L

[Steve Twiss]

Thanks Marek,

On 23 May 2018 12:42 Marek Vasut wrote,

> To: linux-kernel@vger.kernel.org
> Cc: Marek Vasut <marek.vasut+renesas@gmail.com>; Geert Uytterhoeven <geert+renesas@glider.be>; Lee Jones <lee.jones@linaro.org>; Mark Brown <broonie@kernel.org>; Steve Twiss <stwiss.opensource@diasemi.com>; Wolfram Sang <wsa+renesas@sang-engineering.com>; linux-renesas-soc@vger.kernel.org
> Subject: [PATCH 4/6] mfd: da9063: Disallow RTC on DA9063L
>
> The DA9063L does not contain RTC block, unlike the full DA9063.
> Do not allow binding RTC driver on this variant of the chip.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> Cc: Lee Jones <lee.jones@linaro.org>
> Cc: Mark Brown <broonie@kernel.org>
> Cc: Steve Twiss <stwiss.opensource@diasemi.com>
> Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>
> Cc: linux-renesas-soc@vger.kernel.org
> ---
>  drivers/mfd/da9063-core.c | 18 +++++++++++-------
>  1 file changed, 11 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/mfd/da9063-core.c b/drivers/mfd/da9063-core.c index 7360b76b4f72..263c83006413 100644
> --- a/drivers/mfd/da9063-core.c
> +++ b/drivers/mfd/da9063-core.c
> @@ -101,14 +101,14 @@ static const struct mfd_cell da9063_devs[] = {
>  		.of_compatible = "dlg,da9063-onkey",
>  	},
>  	{
> +		.name		= DA9063_DRVNAME_VIBRATION,
> +	},
> +	{	/* Only present on DA9063 , not on DA9063L */
>  		.name		= DA9063_DRVNAME_RTC,
>  		.num_resources	= ARRAY_SIZE(da9063_rtc_resources),
>  		.resources	= da9063_rtc_resources,
>  		.of_compatible	= "dlg,da9063-rtc",
>  	},
> -	{
> -		.name		= DA9063_DRVNAME_VIBRATION,
> -	},
>  };
>  
>  static int da9063_clear_fault_log(struct da9063 *da9063) @@ -163,7 +163,7 @@ int da9063_device_init(struct da9063 *da9063, unsigned int irq)  {
>  	struct da9063_pdata *pdata = da9063->dev->platform_data;
>  	int model, variant_id, variant_code;
> -	int ret;
> +	int da9063_devs_len, ret;
>  
>  	ret = da9063_clear_fault_log(da9063);
>  	if (ret < 0)
> @@ -225,9 +225,13 @@ int da9063_device_init(struct da9063 *da9063, unsigned int irq)
>  
>  	da9063->irq_base = regmap_irq_chip_get_base(da9063->regmap_irq);
>  
> -	ret = mfd_add_devices(da9063->dev, -1, da9063_devs,
> -			      ARRAY_SIZE(da9063_devs), NULL, da9063->irq_base,
> -			      NULL);
> +	da9063_devs_len = ARRAY_SIZE(da9063_devs);
> +	/* RTC, the last device in the list, is only present on DA9063 */
> +	if (da9063->type == PMIC_TYPE_DA9063L)
> +		da9063_devs_len -= 1;
> +
> +	ret = mfd_add_devices(da9063->dev, -1, da9063_devs, da9063_devs_len,
> +			      NULL, da9063->irq_base, NULL);
>  	if (ret)
>  		dev_err(da9063->dev, "Cannot add MFD cells\n");
>  
> --
> 2.16.2

MFD cells definitely has less impact than regmap_range and regmap_irq.
I agree, there's no point in having a completely new 
static const struct mfd_cell da9063l_devs[] = { ... }  for DA9063L

Acked-by: Steve Twiss <stwiss.opensource@diasemi.com>

Regards,
Steve

RE: [PATCH 3/6] mfd: da9063: Add DA9063L type

[Steve Twiss]

On 23 May 2018 12:42 Marek Vasut wrote:
 
> To: linux-kernel@vger.kernel.org
> Cc: Marek Vasut <marek.vasut+renesas@gmail.com>; Geert Uytterhoeven <geert+renesas@glider.be>; Lee Jones <lee.jones@linaro.org>; Mark Brown <broonie@kernel.org>; Steve Twiss <stwiss.opensource@diasemi.com>; Wolfram Sang <wsa+renesas@sang-engineering.com>; linux-renesas-soc@vger.kernel.org
> Subject: [PATCH 3/6] mfd: da9063: Add DA9063L type
>
> Add type for DA9063L, which is a reduced variant of the DA9063 without RTC block and with less regulators.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> Cc: Lee Jones <lee.jones@linaro.org>
> Cc: Mark Brown <broonie@kernel.org>
> Cc: Steve Twiss <stwiss.opensource@diasemi.com>
> Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>
> Cc: linux-renesas-soc@vger.kernel.org
> ---
>  include/linux/mfd/da9063/core.h | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/include/linux/mfd/da9063/core.h b/include/linux/mfd/da9063/core.h index eb234582dcb2..c3e917dd1860 100644
> --- a/include/linux/mfd/da9063/core.h
> +++ b/include/linux/mfd/da9063/core.h
> @@ -33,6 +33,7 @@
>  
>  enum da9063_type {
>  	PMIC_TYPE_DA9063 = 0,
> +	PMIC_TYPE_DA9063L,
>  };
>  
>  enum da9063_variant_codes {
> --
> 2.16.2

Acked-by: Steve Twiss <stwiss.opensource@diasemi.com>

Regards,
Steve

Re: [PATCH 6/6] mfd: da9063: Add DA9063L support

[Marek Vasut]

On 05/24/2018 02:32 PM, Steve Twiss wrote:
> Hi Marek,
> 
> On 24 May 2018 @ 12:49 Steve Twiss wrote:
> 
>> To: Marek Vasut <marek.vasut@gmail.com>; linux-kernel@vger.kernel.org
>> Cc: Marek Vasut <marek.vasut+renesas@gmail.com>; Geert Uytterhoeven <geert+renesas@glider.be>; Lee Jones <lee.jones@linaro.org>; Mark Brown <broonie@kernel.org>; Steve Twiss <stwiss.opensource@diasemi.com>; Wolfram Sang <wsa+renesas@sang-engineering.com>; linux-renesas-soc@vger.kernel.org
>> Subject: RE: [PATCH 6/6] mfd: da9063: Add DA9063L support
>>
>> Thanks Marek,
>>
>>> On 23 May 2018 12:43 Marek Vasut wrote,
>>>
>>> To: linux-kernel@vger.kernel.org
>>> Cc: Marek Vasut <marek.vasut+renesas@gmail.com>; Geert Uytterhoeven <geert+renesas@glider.be>; Lee Jones <lee.jones@linaro.org>;
>>> Mark Brown <broonie@kernel.org>; Steve Twiss <stwiss.opensource@diasemi.com>; Wolfram Sang <wsa+renesas@sang-engineering.com>; linux-renesas-soc@vger.kernel.org
>>> Subject: [PATCH 6/6] mfd: da9063: Add DA9063L support
>>>
>>> Add support for DA9063L, which is a reduced variant of the DA9063 with less regulators and without RTC.
>>>
>>
>> There's potentially more to this file. Without an RTC the regmap access tables would change
>> and the usual DA9063 (BB silicon) tables would become invalid.
>> The tables for da9063_bb_readable_ranges, da9063_bb_writeable_ranges, da9063_bb_volatile_ranges,
>> would need to be updated for DA9063L, if a new chip model was needed.
>>
>> The new ranges would be this (see below), and would remove any RTC accesses in the new chip model.
>>
>> static const struct regmap_range da9063l_bb_readable_ranges[] = {
>> 	{
>> 		.range_min = DA9063_REG_PAGE_CON,
>> 		.range_max = DA9063_REG_MON_A10_RES,
>> 	}, {
>> 		.range_min = DA9063_REG_SEQ,
>> 		.range_max = DA9063_REG_ID_32_31,
>> 	}, {
>> 		.range_min = DA9063_REG_SEQ_A,
>> 		.range_max = DA9063_REG_AUTO3_LOW,
>> 	}, {
>> 		.range_min = DA9063_REG_T_OFFSET,
>> 		.range_max = DA9063_BB_REG_GP_ID_19,
>> 	}, {
>> 		.range_min = DA9063_REG_CHIP_ID,
>> 		.range_max = DA9063_REG_CHIP_VARIANT,
>> 	},
>> };
>>
>> static const struct regmap_range da9063l_bb_writeable_ranges[] = {
>> 	{
>> 		.range_min = DA9063_REG_PAGE_CON,
>> 		.range_max = DA9063_REG_PAGE_CON,
>> 	}, {
>> 		.range_min = DA9063_REG_FAULT_LOG,
>> 		.range_max = DA9063_REG_VSYS_MON,
>> 	}, {
>> 		.range_min = DA9063_REG_SEQ,
>> 		.range_max = DA9063_REG_ID_32_31,
>> 	}, {
>> 		.range_min = DA9063_REG_SEQ_A,
>> 		.range_max = DA9063_REG_AUTO3_LOW,
>> 	}, {
>> 		.range_min = DA9063_REG_CONFIG_I,
>> 		.range_max = DA9063_BB_REG_MON_REG_4,
>> 	}, {
>> 		.range_min = DA9063_BB_REG_GP_ID_0,
>> 		.range_max = DA9063_BB_REG_GP_ID_19,
>> 	},
>> };
>>
>> static const struct regmap_range da9063l_bb_volatile_ranges[] = {
>> 	{
>> 		.range_min = DA9063_REG_PAGE_CON,
>> 		.range_max = DA9063_REG_EVENT_D,
>> 	}, {
>> 		.range_min = DA9063_REG_CONTROL_A,
>> 		.range_max = DA9063_REG_CONTROL_B,
>> 	}, {
>> 		.range_min = DA9063_REG_CONTROL_E,
>> 		.range_max = DA9063_REG_CONTROL_F,
>> 	}, {
>> 		.range_min = DA9063_REG_BCORE2_CONT,
>> 		.range_max = DA9063_REG_LDO11_CONT,
>> 	}, {
>> 		.range_min = DA9063_REG_DVC_1,
>> 		.range_max = DA9063_REG_ADC_MAN,
>> 	}, {
>> 		.range_min = DA9063_REG_ADC_RES_L,
>> 		.range_max = DA9063_REG_MON_A10_RES,
>> 	}, {
>> 		.range_min = DA9063_REG_SEQ,
>> 		.range_max = DA9063_REG_SEQ,
>> 	}, {
>> 		.range_min = DA9063_REG_EN_32K,
>> 		.range_max = DA9063_REG_EN_32K,
>> 	}, {
>> 		.range_min = DA9063_BB_REG_MON_REG_5,
>> 		.range_max = DA9063_BB_REG_MON_REG_6,
>> 	},
>> };
>>
>> However this is a larger and more wide-ranging change compared to the one proposed by Marek,
>> and would require other alterations to fit this in. Also I'm undecided to what it would really add 
>> apart from a new chip model: I have been told accessing the DA9063 RTC register locations has no
>> effect in the DA9063L.
> 
> Looking at this further, there is also a new IRQ regmap.
> Again this comes down to whether a full chip model is needed or not. If not, then the IRQ map does not
> need to be changed as given. Otherwise the removal of the following:
> 
> 	[DA9063_IRQ_ALARM] = {
> 		.reg_offset = DA9063_REG_EVENT_A_OFFSET,
> 		.mask = DA9063_M_ALARM,
> 	},
> 	[DA9063_IRQ_TICK] = {
> 		.reg_offset = DA9063_REG_EVENT_A_OFFSET,
> 		.mask = DA9063_M_TICK,
> 	},
> 
> prior to registering the IRQs in the chip model would be needed.
> The new regmap_irq would be:
> 
> static const struct regmap_irq da9063l_irqs[] = {
> 	/* DA9063 event A register */
> 	[DA9063L_IRQ_ONKEY] = {
> 		.reg_offset = DA9063_REG_EVENT_A_OFFSET,
> 		.mask = DA9063_M_ONKEY,
> 	},
> 	[DA9063L_IRQ_ADC_RDY] = {
> 		.reg_offset = DA9063_REG_EVENT_A_OFFSET,
> 		.mask = DA9063_M_ADC_RDY,
> 	},
> 	[DA9063L_IRQ_SEQ_RDY] = {
> 		.reg_offset = DA9063_REG_EVENT_A_OFFSET,
> 		.mask = DA9063_M_SEQ_RDY,
> 	},
> 	/* DA9063 event B register */
> 	[DA9063L_IRQ_WAKE] = {
> 		.reg_offset = DA9063_REG_EVENT_B_OFFSET,
> 		.mask = DA9063_M_WAKE,
> 	},
> 	[DA9063L_IRQ_TEMP] = {
> 		.reg_offset = DA9063_REG_EVENT_B_OFFSET,
> 		.mask = DA9063_M_TEMP,
> 	},
> 	[DA9063L_IRQ_COMP_1V2] = {
> 		.reg_offset = DA9063_REG_EVENT_B_OFFSET,
> 		.mask = DA9063_M_COMP_1V2,
> 	},
> 	[DA9063L_IRQ_LDO_LIM] = {
> 		.reg_offset = DA9063_REG_EVENT_B_OFFSET,
> 		.mask = DA9063_M_LDO_LIM,
> 	},
> 	[DA9063L_IRQ_REG_UVOV] = {
> 		.reg_offset = DA9063_REG_EVENT_B_OFFSET,
> 		.mask = DA9063_M_UVOV,
> 	},
> 	[DA9063L_IRQ_DVC_RDY] = {
> 		.reg_offset = DA9063_REG_EVENT_B_OFFSET,
> 		.mask = DA9063_M_DVC_RDY,
> 	},
> 	[DA9063L_IRQ_VDD_MON] = {
> 		.reg_offset = DA9063_REG_EVENT_B_OFFSET,
> 		.mask = DA9063_M_VDD_MON,
> 	},
> 	[DA9063L_IRQ_WARN] = {
> 		.reg_offset = DA9063_REG_EVENT_B_OFFSET,
> 		.mask = DA9063_M_VDD_WARN,
> 	},
> 	/* DA9063 event C register */
> 	[DA9063L_IRQ_GPI0] = {
> 		.reg_offset = DA9063_REG_EVENT_C_OFFSET,
> 		.mask = DA9063_M_GPI0,
> 	},
> 	[DA9063L_IRQ_GPI1] = {
> 		.reg_offset = DA9063_REG_EVENT_C_OFFSET,
> 		.mask = DA9063_M_GPI1,
> 	},
> 	[DA9063L_IRQ_GPI2] = {
> 		.reg_offset = DA9063_REG_EVENT_C_OFFSET,
> 		.mask = DA9063_M_GPI2,
> 	},
> 	[DA9063L_IRQ_GPI3] = {
> 		.reg_offset = DA9063_REG_EVENT_C_OFFSET,
> 		.mask = DA9063_M_GPI3,
> 	},
> 	[DA9063L_IRQ_GPI4] = {
> 		.reg_offset = DA9063_REG_EVENT_C_OFFSET,
> 		.mask = DA9063_M_GPI4,
> 	},
> 	[DA9063L_IRQ_GPI5] = {
> 		.reg_offset = DA9063_REG_EVENT_C_OFFSET,
> 		.mask = DA9063_M_GPI5,
> 	},
> 	[DA9063L_IRQ_GPI6] = {
> 		.reg_offset = DA9063_REG_EVENT_C_OFFSET,
> 		.mask = DA9063_M_GPI6,
> 	},
> 	[DA9063L_IRQ_GPI7] = {
> 		.reg_offset = DA9063_REG_EVENT_C_OFFSET,
> 		.mask = DA9063_M_GPI7,
> 	},
> 	/* DA9063 event D register */
> 	[DA9063L_IRQ_GPI8] = {
> 		.reg_offset = DA9063_REG_EVENT_D_OFFSET,
> 		.mask = DA9063_M_GPI8,
> 	},
> 	[DA9063L_IRQ_GPI9] = {
> 		.reg_offset = DA9063_REG_EVENT_D_OFFSET,
> 		.mask = DA9063_M_GPI9,
> 	},
> 	[DA9063L_IRQ_GPI10] = {
> 		.reg_offset = DA9063_REG_EVENT_D_OFFSET,
> 		.mask = DA9063_M_GPI10,
> 	},
> 	[DA9063L_IRQ_GPI11] = {
> 		.reg_offset = DA9063_REG_EVENT_D_OFFSET,
> 		.mask = DA9063_M_GPI11,
> 	},
> 	[DA9063L_IRQ_GPI12] = {
> 		.reg_offset = DA9063_REG_EVENT_D_OFFSET,
> 		.mask = DA9063_M_GPI12,
> 	},
> 	[DA9063L_IRQ_GPI13] = {
> 		.reg_offset = DA9063_REG_EVENT_D_OFFSET,
> 		.mask = DA9063_M_GPI13,
> 	},
> 	[DA9063L_IRQ_GPI14] = {
> 		.reg_offset = DA9063_REG_EVENT_D_OFFSET,
> 		.mask = DA9063_M_GPI14,
> 	},
> 	[DA9063L_IRQ_GPI15] = {
> 		.reg_offset = DA9063_REG_EVENT_D_OFFSET,
> 		.mask = DA9063_M_GPI15,
> 	},
> };

We can probably do the same trick with the regmaps and irqmaps as with
the rest, that is, reorder them and register only a smaller portion ?

-- 
Best regards,
Marek Vasut

RE: [PATCH 6/6] mfd: da9063: Add DA9063L support

[Steve Twiss]

On 24 May 2018 15:51 Marek Vasut wrote:

Hi Marek,

> To: Steve Twiss <stwiss.opensource@diasemi.com>; linux-kernel@vger.kernel.org
> Cc: Marek Vasut <marek.vasut+renesas@gmail.com>; Geert Uytterhoeven
> <geert+renesas@glider.be>; Lee Jones <lee.jones@linaro.org>; Mark Brown
> <broonie@kernel.org>; Wolfram Sang <wsa+renesas@sang-engineering.com>;
> linux-renesas-soc@vger.kernel.org
> Subject: Re: [PATCH 6/6] mfd: da9063: Add DA9063L support
> 
> On 05/24/2018 02:32 PM, Steve Twiss wrote:
> > On 24 May 2018 @ 12:49 Steve Twiss wrote:
> >>> On 23 May 2018 12:43 Marek Vasut wrote,
> >>>
> >>> To: linux-kernel@vger.kernel.org
> >>> Subject: [PATCH 6/6] mfd: da9063: Add DA9063L support
> >>>
> >>> Add support for DA9063L, which is a reduced variant of the DA9063 with less regulators and without RTC.
> >>>
> >>
> >> There's potentially more to this file. Without an RTC the regmap
> >> access tables would change and the usual DA9063 (BB silicon) tables would become invalid.
> >> The tables for da9063_bb_readable_ranges, da9063_bb_writeable_ranges,
> >> da9063_bb_volatile_ranges, would need to be updated for DA9063L, if a new chip model was needed.
> >>
> >> The new ranges would be this (see below), and would remove any RTC accesses in the new chip model.
> >>
> >> static const struct regmap_range da9063l_bb_readable_ranges[] = {
> >> 	{
> >> 		.range_min = DA9063_REG_PAGE_CON,
> >> 		.range_max = DA9063_REG_MON_A10_RES,
> >> 	}, {
> >> 		.range_min = DA9063_REG_SEQ,
> >> 		.range_max = DA9063_REG_ID_32_31,
> >> 	}, {
> >> 		.range_min = DA9063_REG_SEQ_A,
> >> 		.range_max = DA9063_REG_AUTO3_LOW,
> >> 	}, {
> >> 		.range_min = DA9063_REG_T_OFFSET,
> >> 		.range_max = DA9063_BB_REG_GP_ID_19,
> >> 	}, {
> >> 		.range_min = DA9063_REG_CHIP_ID,
> >> 		.range_max = DA9063_REG_CHIP_VARIANT,
> >> 	},
> >> };
> >>
> >> static const struct regmap_range da9063l_bb_writeable_ranges[] = {
> >> 	{
> >> 		.range_min = DA9063_REG_PAGE_CON,
> >> 		.range_max = DA9063_REG_PAGE_CON,
> >> 	}, {
> >> 		.range_min = DA9063_REG_FAULT_LOG,
> >> 		.range_max = DA9063_REG_VSYS_MON,
> >> 	}, {
> >> 		.range_min = DA9063_REG_SEQ,
> >> 		.range_max = DA9063_REG_ID_32_31,
> >> 	}, {
> >> 		.range_min = DA9063_REG_SEQ_A,
> >> 		.range_max = DA9063_REG_AUTO3_LOW,
> >> 	}, {
> >> 		.range_min = DA9063_REG_CONFIG_I,
> >> 		.range_max = DA9063_BB_REG_MON_REG_4,
> >> 	}, {
> >> 		.range_min = DA9063_BB_REG_GP_ID_0,
> >> 		.range_max = DA9063_BB_REG_GP_ID_19,
> >> 	},
> >> };
> >>
> >> static const struct regmap_range da9063l_bb_volatile_ranges[] = {
> >> 	{
> >> 		.range_min = DA9063_REG_PAGE_CON,
> >> 		.range_max = DA9063_REG_EVENT_D,
> >> 	}, {
> >> 		.range_min = DA9063_REG_CONTROL_A,
> >> 		.range_max = DA9063_REG_CONTROL_B,
> >> 	}, {
> >> 		.range_min = DA9063_REG_CONTROL_E,
> >> 		.range_max = DA9063_REG_CONTROL_F,
> >> 	}, {
> >> 		.range_min = DA9063_REG_BCORE2_CONT,
> >> 		.range_max = DA9063_REG_LDO11_CONT,
> >> 	}, {
> >> 		.range_min = DA9063_REG_DVC_1,
> >> 		.range_max = DA9063_REG_ADC_MAN,
> >> 	}, {
> >> 		.range_min = DA9063_REG_ADC_RES_L,
> >> 		.range_max = DA9063_REG_MON_A10_RES,
> >> 	}, {
> >> 		.range_min = DA9063_REG_SEQ,
> >> 		.range_max = DA9063_REG_SEQ,
> >> 	}, {
> >> 		.range_min = DA9063_REG_EN_32K,
> >> 		.range_max = DA9063_REG_EN_32K,
> >> 	}, {
> >> 		.range_min = DA9063_BB_REG_MON_REG_5,
> >> 		.range_max = DA9063_BB_REG_MON_REG_6,
> >> 	},
> >> };
> >>
> >> However this is a larger and more wide-ranging change compared to the
> >> one proposed by Marek, and would require other alterations to fit
> >> this in. Also I'm undecided to what it would really add apart from a
> >> new chip model: I have been told accessing the DA9063 RTC register locations
> >> has no effect in the DA9063L.
> >
> > Looking at this further, there is also a new IRQ regmap.
> > Again this comes down to whether a full chip model is needed or not.
> > If not, then the IRQ map does not need to be changed as given. Otherwise the
> > removal of the following:
> >
> > 	[DA9063_IRQ_ALARM] = {
> > 		.reg_offset = DA9063_REG_EVENT_A_OFFSET,
> > 		.mask = DA9063_M_ALARM,
> > 	},
> > 	[DA9063_IRQ_TICK] = {
> > 		.reg_offset = DA9063_REG_EVENT_A_OFFSET,
> > 		.mask = DA9063_M_TICK,
> > 	},
> >
> > prior to registering the IRQs in the chip model would be needed.
> > The new regmap_irq would be:
> >
> > static const struct regmap_irq da9063l_irqs[] = {
> > 	/* DA9063 event A register */
> > 	[DA9063L_IRQ_ONKEY] = {
> > 		.reg_offset = DA9063_REG_EVENT_A_OFFSET,
> > 		.mask = DA9063_M_ONKEY,
> > 	},
> > 	[DA9063L_IRQ_ADC_RDY] = {
> > 		.reg_offset = DA9063_REG_EVENT_A_OFFSET,
> > 		.mask = DA9063_M_ADC_RDY,
> > 	},
> > 	[DA9063L_IRQ_SEQ_RDY] = {
> > 		.reg_offset = DA9063_REG_EVENT_A_OFFSET,
> > 		.mask = DA9063_M_SEQ_RDY,
> > 	},
> > 	/* DA9063 event B register */
> > 	[DA9063L_IRQ_WAKE] = {
> > 		.reg_offset = DA9063_REG_EVENT_B_OFFSET,
> > 		.mask = DA9063_M_WAKE,
> > 	},
> > 	[DA9063L_IRQ_TEMP] = {
> > 		.reg_offset = DA9063_REG_EVENT_B_OFFSET,
> > 		.mask = DA9063_M_TEMP,
> > 	},
> > 	[DA9063L_IRQ_COMP_1V2] = {
> > 		.reg_offset = DA9063_REG_EVENT_B_OFFSET,
> > 		.mask = DA9063_M_COMP_1V2,
> > 	},
> > 	[DA9063L_IRQ_LDO_LIM] = {
> > 		.reg_offset = DA9063_REG_EVENT_B_OFFSET,
> > 		.mask = DA9063_M_LDO_LIM,
> > 	},
> > 	[DA9063L_IRQ_REG_UVOV] = {
> > 		.reg_offset = DA9063_REG_EVENT_B_OFFSET,
> > 		.mask = DA9063_M_UVOV,
> > 	},
> > 	[DA9063L_IRQ_DVC_RDY] = {
> > 		.reg_offset = DA9063_REG_EVENT_B_OFFSET,
> > 		.mask = DA9063_M_DVC_RDY,
> > 	},
> > 	[DA9063L_IRQ_VDD_MON] = {
> > 		.reg_offset = DA9063_REG_EVENT_B_OFFSET,
> > 		.mask = DA9063_M_VDD_MON,
> > 	},
> > 	[DA9063L_IRQ_WARN] = {
> > 		.reg_offset = DA9063_REG_EVENT_B_OFFSET,
> > 		.mask = DA9063_M_VDD_WARN,
> > 	},
> > 	/* DA9063 event C register */
> > 	[DA9063L_IRQ_GPI0] = {
> > 		.reg_offset = DA9063_REG_EVENT_C_OFFSET,
> > 		.mask = DA9063_M_GPI0,
> > 	},
> > 	[DA9063L_IRQ_GPI1] = {
> > 		.reg_offset = DA9063_REG_EVENT_C_OFFSET,
> > 		.mask = DA9063_M_GPI1,
> > 	},
> > 	[DA9063L_IRQ_GPI2] = {
> > 		.reg_offset = DA9063_REG_EVENT_C_OFFSET,
> > 		.mask = DA9063_M_GPI2,
> > 	},
> > 	[DA9063L_IRQ_GPI3] = {
> > 		.reg_offset = DA9063_REG_EVENT_C_OFFSET,
> > 		.mask = DA9063_M_GPI3,
> > 	},
> > 	[DA9063L_IRQ_GPI4] = {
> > 		.reg_offset = DA9063_REG_EVENT_C_OFFSET,
> > 		.mask = DA9063_M_GPI4,
> > 	},
> > 	[DA9063L_IRQ_GPI5] = {
> > 		.reg_offset = DA9063_REG_EVENT_C_OFFSET,
> > 		.mask = DA9063_M_GPI5,
> > 	},
> > 	[DA9063L_IRQ_GPI6] = {
> > 		.reg_offset = DA9063_REG_EVENT_C_OFFSET,
> > 		.mask = DA9063_M_GPI6,
> > 	},
> > 	[DA9063L_IRQ_GPI7] = {
> > 		.reg_offset = DA9063_REG_EVENT_C_OFFSET,
> > 		.mask = DA9063_M_GPI7,
> > 	},
> > 	/* DA9063 event D register */
> > 	[DA9063L_IRQ_GPI8] = {
> > 		.reg_offset = DA9063_REG_EVENT_D_OFFSET,
> > 		.mask = DA9063_M_GPI8,
> > 	},
> > 	[DA9063L_IRQ_GPI9] = {
> > 		.reg_offset = DA9063_REG_EVENT_D_OFFSET,
> > 		.mask = DA9063_M_GPI9,
> > 	},
> > 	[DA9063L_IRQ_GPI10] = {
> > 		.reg_offset = DA9063_REG_EVENT_D_OFFSET,
> > 		.mask = DA9063_M_GPI10,
> > 	},
> > 	[DA9063L_IRQ_GPI11] = {
> > 		.reg_offset = DA9063_REG_EVENT_D_OFFSET,
> > 		.mask = DA9063_M_GPI11,
> > 	},
> > 	[DA9063L_IRQ_GPI12] = {
> > 		.reg_offset = DA9063_REG_EVENT_D_OFFSET,
> > 		.mask = DA9063_M_GPI12,
> > 	},
> > 	[DA9063L_IRQ_GPI13] = {
> > 		.reg_offset = DA9063_REG_EVENT_D_OFFSET,
> > 		.mask = DA9063_M_GPI13,
> > 	},
> > 	[DA9063L_IRQ_GPI14] = {
> > 		.reg_offset = DA9063_REG_EVENT_D_OFFSET,
> > 		.mask = DA9063_M_GPI14,
> > 	},
> > 	[DA9063L_IRQ_GPI15] = {
> > 		.reg_offset = DA9063_REG_EVENT_D_OFFSET,
> > 		.mask = DA9063_M_GPI15,
> > 	},
> > };
> 
> We can probably do the same trick with the regmaps and irqmaps as with the
> rest, that is, reorder them and register only a smaller portion ?

I like the "reorder and only register a smaller portion" trick. But it wouldn't work
with what I gave earlier today, without some modification.
For instance, the first register readable entry range in the  DA9063 BB is:

static const struct regmap_range da9063_bb_readable_ranges[] = {
	{
		.range_min = DA9063_REG_PAGE_CON,
		.range_max = DA9063_BB_REG_SECOND_D,
	}, {

But for the DA9063L, this first range entry would be changed, not removed:

static const struct regmap_range da9063l_bb_readable_ranges[] = {
	{
		.range_min = DA9063_REG_PAGE_CON,
		.range_max = DA9063_REG_MON_A10_RES,
	}, {

So it's not all-or-nothing. But possibly it could be made to work if those ranges were split
into two pieces.

However, it might get messy to maintain in future -- sometimes register ranges need to be
updated with new components or if a new feature is added -- usually I need to work it
all out on paper with the full register map. Splitting up ranges might make it a little
messier. But, it's not impossible.

For the DA9062 and DA9061 this was done using separate ranges and using the macro
regmap_reg_range(). It's not that messy to read, e.g. 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/mfd/da9062-core.c?h=next-20180517#n367

Regards,
Steve

Re: [PATCH 2/6] mfd: da9063: Replace model with type

[kbuild test robot]

[-- Attachment #1: Type: text/plain, Size: 8343 bytes --]

Hi Marek,

I love your patch! Perhaps something to improve:

[auto build test WARNING on ljones-mfd/for-mfd-next]
[also build test WARNING on v4.17-rc6]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]

url:    https://github.com/0day-ci/linux/commits/Marek-Vasut/mfd-da9063-Rename-PMIC_DA9063-to-PMIC_CHIP_ID_DA9063/20180526-162613
base:   https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git for-mfd-next
config: x86_64-randconfig-x002-201820 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
        # save the attached .config to linux build tree
        make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   In file included from include/linux/kernel.h:10:0,
                    from drivers//regulator/da9063-regulator.c:16:
   drivers//regulator/da9063-regulator.c: In function 'da9063_regulator_probe':
   drivers//regulator/da9063-regulator.c:744:12: error: 'const struct da9063_dev_model' has no member named 'dev_model'
      if (model->dev_model == da9063->type)
               ^
   include/linux/compiler.h:58:30: note: in definition of macro '__trace_if'
     if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
                                 ^~~~
>> drivers//regulator/da9063-regulator.c:744:3: note: in expansion of macro 'if'
      if (model->dev_model == da9063->type)
      ^~
   drivers//regulator/da9063-regulator.c:744:12: error: 'const struct da9063_dev_model' has no member named 'dev_model'
      if (model->dev_model == da9063->type)
               ^
   include/linux/compiler.h:58:42: note: in definition of macro '__trace_if'
     if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
                                             ^~~~
>> drivers//regulator/da9063-regulator.c:744:3: note: in expansion of macro 'if'
      if (model->dev_model == da9063->type)
      ^~
   drivers//regulator/da9063-regulator.c:744:12: error: 'const struct da9063_dev_model' has no member named 'dev_model'
      if (model->dev_model == da9063->type)
               ^
   include/linux/compiler.h:69:16: note: in definition of macro '__trace_if'
      ______r = !!(cond);     \
                   ^~~~
>> drivers//regulator/da9063-regulator.c:744:3: note: in expansion of macro 'if'
      if (model->dev_model == da9063->type)
      ^~
   drivers//regulator/da9063-regulator.c:749:10: error: 'struct da9063' has no member named 'model'
       da9063->model);
             ^~

vim +/if +744 drivers//regulator/da9063-regulator.c

   715	
   716	static int da9063_regulator_probe(struct platform_device *pdev)
   717	{
   718		struct da9063 *da9063 = dev_get_drvdata(pdev->dev.parent);
   719		struct da9063_pdata *da9063_pdata = dev_get_platdata(da9063->dev);
   720		struct of_regulator_match *da9063_reg_matches = NULL;
   721		struct da9063_regulators_pdata *regl_pdata;
   722		const struct da9063_dev_model *model;
   723		struct da9063_regulators *regulators;
   724		struct da9063_regulator *regl;
   725		struct regulator_config config;
   726		bool bcores_merged, bmem_bio_merged;
   727		int id, irq, n, n_regulators, ret, val;
   728		size_t size;
   729	
   730		regl_pdata = da9063_pdata ? da9063_pdata->regulators_pdata : NULL;
   731	
   732		if (!regl_pdata)
   733			regl_pdata = da9063_parse_regulators_dt(pdev,
   734								&da9063_reg_matches);
   735	
   736		if (IS_ERR(regl_pdata) || regl_pdata->n_regulators == 0) {
   737			dev_err(&pdev->dev,
   738				"No regulators defined for the platform\n");
   739			return -ENODEV;
   740		}
   741	
   742		/* Find regulators set for particular device model */
   743		for (model = regulators_models; model->regulator_info; model++) {
 > 744			if (model->dev_model == da9063->type)
   745				break;
   746		}
   747		if (!model->regulator_info) {
   748			dev_err(&pdev->dev, "Chip model not recognised (%u)\n",
   749				da9063->model);
   750			return -ENODEV;
   751		}
   752	
   753		ret = regmap_read(da9063->regmap, DA9063_REG_CONFIG_H, &val);
   754		if (ret < 0) {
   755			dev_err(&pdev->dev,
   756				"Error while reading BUCKs configuration\n");
   757			return ret;
   758		}
   759		bcores_merged = val & DA9063_BCORE_MERGE;
   760		bmem_bio_merged = val & DA9063_BUCK_MERGE;
   761	
   762		n_regulators = model->n_regulators;
   763		if (bcores_merged)
   764			n_regulators -= 2; /* remove BCORE1, BCORE2 */
   765		else
   766			n_regulators--;    /* remove BCORES_MERGED */
   767		if (bmem_bio_merged)
   768			n_regulators -= 2; /* remove BMEM, BIO */
   769		else
   770			n_regulators--;    /* remove BMEM_BIO_MERGED */
   771	
   772		/* Allocate memory required by usable regulators */
   773		size = sizeof(struct da9063_regulators) +
   774			n_regulators * sizeof(struct da9063_regulator);
   775		regulators = devm_kzalloc(&pdev->dev, size, GFP_KERNEL);
   776		if (!regulators)
   777			return -ENOMEM;
   778	
   779		regulators->n_regulators = n_regulators;
   780		platform_set_drvdata(pdev, regulators);
   781	
   782		/* Register all regulators declared in platform information */
   783		n = 0;
   784		id = 0;
   785		while (n < regulators->n_regulators) {
   786			/* Skip regulator IDs depending on merge mode configuration */
   787			switch (id) {
   788			case DA9063_ID_BCORE1:
   789			case DA9063_ID_BCORE2:
   790				if (bcores_merged) {
   791					id++;
   792					continue;
   793				}
   794				break;
   795			case DA9063_ID_BMEM:
   796			case DA9063_ID_BIO:
   797				if (bmem_bio_merged) {
   798					id++;
   799					continue;
   800				}
   801				break;
   802			case DA9063_ID_BCORES_MERGED:
   803				if (!bcores_merged) {
   804					id++;
   805					continue;
   806				}
   807				break;
   808			case DA9063_ID_BMEM_BIO_MERGED:
   809				if (!bmem_bio_merged) {
   810					id++;
   811					continue;
   812				}
   813				break;
   814			}
   815	
   816			/* Initialise regulator structure */
   817			regl = &regulators->regulator[n];
   818			regl->hw = da9063;
   819			regl->info = &model->regulator_info[id];
   820			regl->desc = regl->info->desc;
   821			regl->desc.type = REGULATOR_VOLTAGE;
   822			regl->desc.owner = THIS_MODULE;
   823	
   824			if (regl->info->mode.reg)
   825				regl->mode = devm_regmap_field_alloc(&pdev->dev,
   826						da9063->regmap, regl->info->mode);
   827			if (regl->info->suspend.reg)
   828				regl->suspend = devm_regmap_field_alloc(&pdev->dev,
   829						da9063->regmap, regl->info->suspend);
   830			if (regl->info->sleep.reg)
   831				regl->sleep = devm_regmap_field_alloc(&pdev->dev,
   832						da9063->regmap, regl->info->sleep);
   833			if (regl->info->suspend_sleep.reg)
   834				regl->suspend_sleep = devm_regmap_field_alloc(&pdev->dev,
   835						da9063->regmap, regl->info->suspend_sleep);
   836			if (regl->info->ilimit.reg)
   837				regl->ilimit = devm_regmap_field_alloc(&pdev->dev,
   838						da9063->regmap, regl->info->ilimit);
   839	
   840			/* Register regulator */
   841			memset(&config, 0, sizeof(config));
   842			config.dev = &pdev->dev;
   843			config.init_data = da9063_get_regulator_initdata(regl_pdata, id);
   844			config.driver_data = regl;
   845			if (da9063_reg_matches)
   846				config.of_node = da9063_reg_matches[id].of_node;
   847			config.regmap = da9063->regmap;
   848			regl->rdev = devm_regulator_register(&pdev->dev, &regl->desc,
   849							     &config);
   850			if (IS_ERR(regl->rdev)) {
   851				dev_err(&pdev->dev,
   852					"Failed to register %s regulator\n",
   853					regl->desc.name);
   854				return PTR_ERR(regl->rdev);
   855			}
   856			id++;
   857			n++;
   858		}
   859	
   860		/* LDOs overcurrent event support */
   861		irq = platform_get_irq_byname(pdev, "LDO_LIM");
   862		if (irq < 0) {
   863			dev_err(&pdev->dev, "Failed to get IRQ.\n");
   864			return irq;
   865		}
   866	
   867		ret = devm_request_threaded_irq(&pdev->dev, irq,
   868					NULL, da9063_ldo_lim_event,
   869					IRQF_TRIGGER_LOW | IRQF_ONESHOT,
   870					"LDO_LIM", regulators);
   871		if (ret) {
   872			dev_err(&pdev->dev, "Failed to request LDO_LIM IRQ.\n");
   873			return ret;
   874		}
   875	
   876		return 0;
   877	}
   878	

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 29666 bytes --]

Re: [PATCH 2/6] mfd: da9063: Replace model with type

[Marek Vasut]

On 05/26/2018 11:16 AM, kbuild test robot wrote:
> Hi Marek,
> 
> I love your patch! Perhaps something to improve:
> 
> [auto build test WARNING on ljones-mfd/for-mfd-next]
> [also build test WARNING on v4.17-rc6]
> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
> 
> url:    https://github.com/0day-ci/linux/commits/Marek-Vasut/mfd-da9063-Rename-PMIC_DA9063-to-PMIC_CHIP_ID_DA9063/20180526-162613
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git for-mfd-next
> config: x86_64-randconfig-x002-201820 (attached as .config)
> compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
> reproduce:
>         # save the attached .config to linux build tree
>         make ARCH=x86_64 
> 
> All warnings (new ones prefixed by >>):
> 
>    In file included from include/linux/kernel.h:10:0,
>                     from drivers//regulator/da9063-regulator.c:16:
>    drivers//regulator/da9063-regulator.c: In function 'da9063_regulator_probe':
>    drivers//regulator/da9063-regulator.c:744:12: error: 'const struct da9063_dev_model' has no member named 'dev_model'
>       if (model->dev_model == da9063->type)
>                ^
>    include/linux/compiler.h:58:30: note: in definition of macro '__trace_if'
>      if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
>                                  ^~~~
>>> drivers//regulator/da9063-regulator.c:744:3: note: in expansion of macro 'if'
>       if (model->dev_model == da9063->type)
>       ^~
>    drivers//regulator/da9063-regulator.c:744:12: error: 'const struct da9063_dev_model' has no member named 'dev_model'
>       if (model->dev_model == da9063->type)
>                ^
>    include/linux/compiler.h:58:42: note: in definition of macro '__trace_if'
>      if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
>                                              ^~~~
>>> drivers//regulator/da9063-regulator.c:744:3: note: in expansion of macro 'if'
>       if (model->dev_model == da9063->type)
>       ^~
>    drivers//regulator/da9063-regulator.c:744:12: error: 'const struct da9063_dev_model' has no member named 'dev_model'
>       if (model->dev_model == da9063->type)
>                ^
>    include/linux/compiler.h:69:16: note: in definition of macro '__trace_if'
>       ______r = !!(cond);     \
>                    ^~~~
>>> drivers//regulator/da9063-regulator.c:744:3: note: in expansion of macro 'if'
>       if (model->dev_model == da9063->type)
>       ^~
>    drivers//regulator/da9063-regulator.c:749:10: error: 'struct da9063' has no member named 'model'
>        da9063->model);
>              ^~
> 
> vim +/if +744 drivers//regulator/da9063-regulator.c

Is it testing this patch without the other patches in the series or at
least 1/6 ?

-- 
Best regards,
Marek Vasut

Re: [PATCH 2/6] mfd: da9063: Replace model with type

[kbuild test robot]

[-- Attachment #1: Type: text/plain, Size: 6951 bytes --]

Hi Marek,

I love your patch! Yet something to improve:

[auto build test ERROR on ljones-mfd/for-mfd-next]
[also build test ERROR on v4.17-rc6]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]

url:    https://github.com/0day-ci/linux/commits/Marek-Vasut/mfd-da9063-Rename-PMIC_DA9063-to-PMIC_CHIP_ID_DA9063/20180526-162613
base:   https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git for-mfd-next
config: x86_64-randconfig-x011-201820 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
        # save the attached .config to linux build tree
        make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/regulator/da9063-regulator.c: In function 'da9063_regulator_probe':
>> drivers/regulator/da9063-regulator.c:744:12: error: 'const struct da9063_dev_model' has no member named 'dev_model'
      if (model->dev_model == da9063->type)
               ^~
>> drivers/regulator/da9063-regulator.c:749:10: error: 'struct da9063' has no member named 'model'
       da9063->model);
             ^~

vim +744 drivers/regulator/da9063-regulator.c

   715	
   716	static int da9063_regulator_probe(struct platform_device *pdev)
   717	{
   718		struct da9063 *da9063 = dev_get_drvdata(pdev->dev.parent);
   719		struct da9063_pdata *da9063_pdata = dev_get_platdata(da9063->dev);
   720		struct of_regulator_match *da9063_reg_matches = NULL;
   721		struct da9063_regulators_pdata *regl_pdata;
   722		const struct da9063_dev_model *model;
   723		struct da9063_regulators *regulators;
   724		struct da9063_regulator *regl;
   725		struct regulator_config config;
   726		bool bcores_merged, bmem_bio_merged;
   727		int id, irq, n, n_regulators, ret, val;
   728		size_t size;
   729	
   730		regl_pdata = da9063_pdata ? da9063_pdata->regulators_pdata : NULL;
   731	
   732		if (!regl_pdata)
   733			regl_pdata = da9063_parse_regulators_dt(pdev,
   734								&da9063_reg_matches);
   735	
   736		if (IS_ERR(regl_pdata) || regl_pdata->n_regulators == 0) {
   737			dev_err(&pdev->dev,
   738				"No regulators defined for the platform\n");
   739			return -ENODEV;
   740		}
   741	
   742		/* Find regulators set for particular device model */
   743		for (model = regulators_models; model->regulator_info; model++) {
 > 744			if (model->dev_model == da9063->type)
   745				break;
   746		}
   747		if (!model->regulator_info) {
   748			dev_err(&pdev->dev, "Chip model not recognised (%u)\n",
 > 749				da9063->model);
   750			return -ENODEV;
   751		}
   752	
   753		ret = regmap_read(da9063->regmap, DA9063_REG_CONFIG_H, &val);
   754		if (ret < 0) {
   755			dev_err(&pdev->dev,
   756				"Error while reading BUCKs configuration\n");
   757			return ret;
   758		}
   759		bcores_merged = val & DA9063_BCORE_MERGE;
   760		bmem_bio_merged = val & DA9063_BUCK_MERGE;
   761	
   762		n_regulators = model->n_regulators;
   763		if (bcores_merged)
   764			n_regulators -= 2; /* remove BCORE1, BCORE2 */
   765		else
   766			n_regulators--;    /* remove BCORES_MERGED */
   767		if (bmem_bio_merged)
   768			n_regulators -= 2; /* remove BMEM, BIO */
   769		else
   770			n_regulators--;    /* remove BMEM_BIO_MERGED */
   771	
   772		/* Allocate memory required by usable regulators */
   773		size = sizeof(struct da9063_regulators) +
   774			n_regulators * sizeof(struct da9063_regulator);
   775		regulators = devm_kzalloc(&pdev->dev, size, GFP_KERNEL);
   776		if (!regulators)
   777			return -ENOMEM;
   778	
   779		regulators->n_regulators = n_regulators;
   780		platform_set_drvdata(pdev, regulators);
   781	
   782		/* Register all regulators declared in platform information */
   783		n = 0;
   784		id = 0;
   785		while (n < regulators->n_regulators) {
   786			/* Skip regulator IDs depending on merge mode configuration */
   787			switch (id) {
   788			case DA9063_ID_BCORE1:
   789			case DA9063_ID_BCORE2:
   790				if (bcores_merged) {
   791					id++;
   792					continue;
   793				}
   794				break;
   795			case DA9063_ID_BMEM:
   796			case DA9063_ID_BIO:
   797				if (bmem_bio_merged) {
   798					id++;
   799					continue;
   800				}
   801				break;
   802			case DA9063_ID_BCORES_MERGED:
   803				if (!bcores_merged) {
   804					id++;
   805					continue;
   806				}
   807				break;
   808			case DA9063_ID_BMEM_BIO_MERGED:
   809				if (!bmem_bio_merged) {
   810					id++;
   811					continue;
   812				}
   813				break;
   814			}
   815	
   816			/* Initialise regulator structure */
   817			regl = &regulators->regulator[n];
   818			regl->hw = da9063;
   819			regl->info = &model->regulator_info[id];
   820			regl->desc = regl->info->desc;
   821			regl->desc.type = REGULATOR_VOLTAGE;
   822			regl->desc.owner = THIS_MODULE;
   823	
   824			if (regl->info->mode.reg)
   825				regl->mode = devm_regmap_field_alloc(&pdev->dev,
   826						da9063->regmap, regl->info->mode);
   827			if (regl->info->suspend.reg)
   828				regl->suspend = devm_regmap_field_alloc(&pdev->dev,
   829						da9063->regmap, regl->info->suspend);
   830			if (regl->info->sleep.reg)
   831				regl->sleep = devm_regmap_field_alloc(&pdev->dev,
   832						da9063->regmap, regl->info->sleep);
   833			if (regl->info->suspend_sleep.reg)
   834				regl->suspend_sleep = devm_regmap_field_alloc(&pdev->dev,
   835						da9063->regmap, regl->info->suspend_sleep);
   836			if (regl->info->ilimit.reg)
   837				regl->ilimit = devm_regmap_field_alloc(&pdev->dev,
   838						da9063->regmap, regl->info->ilimit);
   839	
   840			/* Register regulator */
   841			memset(&config, 0, sizeof(config));
   842			config.dev = &pdev->dev;
   843			config.init_data = da9063_get_regulator_initdata(regl_pdata, id);
   844			config.driver_data = regl;
   845			if (da9063_reg_matches)
   846				config.of_node = da9063_reg_matches[id].of_node;
   847			config.regmap = da9063->regmap;
   848			regl->rdev = devm_regulator_register(&pdev->dev, &regl->desc,
   849							     &config);
   850			if (IS_ERR(regl->rdev)) {
   851				dev_err(&pdev->dev,
   852					"Failed to register %s regulator\n",
   853					regl->desc.name);
   854				return PTR_ERR(regl->rdev);
   855			}
   856			id++;
   857			n++;
   858		}
   859	
   860		/* LDOs overcurrent event support */
   861		irq = platform_get_irq_byname(pdev, "LDO_LIM");
   862		if (irq < 0) {
   863			dev_err(&pdev->dev, "Failed to get IRQ.\n");
   864			return irq;
   865		}
   866	
   867		ret = devm_request_threaded_irq(&pdev->dev, irq,
   868					NULL, da9063_ldo_lim_event,
   869					IRQF_TRIGGER_LOW | IRQF_ONESHOT,
   870					"LDO_LIM", regulators);
   871		if (ret) {
   872			dev_err(&pdev->dev, "Failed to request LDO_LIM IRQ.\n");
   873			return ret;
   874		}
   875	
   876		return 0;
   877	}
   878	

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 32915 bytes --]

Re: [PATCH 6/6] mfd: da9063: Add DA9063L support

[Lee Jones]

On Thu, 24 May 2018, Marek Vasut wrote:
> On 05/24/2018 02:32 PM, Steve Twiss wrote:
> > On 24 May 2018 @ 12:49 Steve Twiss wrote:

[...]

> > static const struct regmap_irq da9063l_irqs[] = {
> > 	/* DA9063 event A register */
> > 	[DA9063L_IRQ_ONKEY] = {
> > 		.reg_offset = DA9063_REG_EVENT_A_OFFSET,
> > 		.mask = DA9063_M_ONKEY,
> > 	},

[...]

> > 	[DA9063L_IRQ_GPI15] = {
> > 		.reg_offset = DA9063_REG_EVENT_D_OFFSET,
> > 		.mask = DA9063_M_GPI15,
> > 	},
> > };
> 
> We can probably do the same trick with the regmaps and irqmaps as with
> the rest, that is, reorder them and register only a smaller portion ?

Please also consider using REGMAP_IRQ_REG().

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH 4/6] mfd: da9063: Disallow RTC on DA9063L

[Lee Jones]

On Thu, 24 May 2018, Steve Twiss wrote:

> Thanks Marek,
> 
> On 23 May 2018 12:42 Marek Vasut wrote,
> 
> > To: linux-kernel@vger.kernel.org
> > Cc: Marek Vasut <marek.vasut+renesas@gmail.com>; Geert Uytterhoeven <geert+renesas@glider.be>; Lee Jones <lee.jones@linaro.org>; Mark Brown <broonie@kernel.org>; Steve Twiss <stwiss.opensource@diasemi.com>; Wolfram Sang <wsa+renesas@sang-engineering.com>; linux-renesas-soc@vger.kernel.org
> > Subject: [PATCH 4/6] mfd: da9063: Disallow RTC on DA9063L
> >
> > The DA9063L does not contain RTC block, unlike the full DA9063.
> > Do not allow binding RTC driver on this variant of the chip.
> >
> > Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
> > Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> > Cc: Lee Jones <lee.jones@linaro.org>
> > Cc: Mark Brown <broonie@kernel.org>
> > Cc: Steve Twiss <stwiss.opensource@diasemi.com>
> > Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>
> > Cc: linux-renesas-soc@vger.kernel.org
> > ---
> >  drivers/mfd/da9063-core.c | 18 +++++++++++-------
> >  1 file changed, 11 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/mfd/da9063-core.c b/drivers/mfd/da9063-core.c index 7360b76b4f72..263c83006413 100644
> > --- a/drivers/mfd/da9063-core.c
> > +++ b/drivers/mfd/da9063-core.c
> > @@ -101,14 +101,14 @@ static const struct mfd_cell da9063_devs[] = {
> >  		.of_compatible = "dlg,da9063-onkey",
> >  	},
> >  	{
> > +		.name		= DA9063_DRVNAME_VIBRATION,
> > +	},
> > +	{	/* Only present on DA9063 , not on DA9063L */
> >  		.name		= DA9063_DRVNAME_RTC,
> >  		.num_resources	= ARRAY_SIZE(da9063_rtc_resources),
> >  		.resources	= da9063_rtc_resources,
> >  		.of_compatible	= "dlg,da9063-rtc",
> >  	},
> > -	{
> > -		.name		= DA9063_DRVNAME_VIBRATION,
> > -	},
> >  };
> >  
> >  static int da9063_clear_fault_log(struct da9063 *da9063) @@ -163,7 +163,7 @@ int da9063_device_init(struct da9063 *da9063, unsigned int irq)  {
> >  	struct da9063_pdata *pdata = da9063->dev->platform_data;
> >  	int model, variant_id, variant_code;
> > -	int ret;
> > +	int da9063_devs_len, ret;
> >  
> >  	ret = da9063_clear_fault_log(da9063);
> >  	if (ret < 0)
> > @@ -225,9 +225,13 @@ int da9063_device_init(struct da9063 *da9063, unsigned int irq)
> >  
> >  	da9063->irq_base = regmap_irq_chip_get_base(da9063->regmap_irq);
> >  
> > -	ret = mfd_add_devices(da9063->dev, -1, da9063_devs,
> > -			      ARRAY_SIZE(da9063_devs), NULL, da9063->irq_base,
> > -			      NULL);
> > +	da9063_devs_len = ARRAY_SIZE(da9063_devs);
> > +	/* RTC, the last device in the list, is only present on DA9063 */
> > +	if (da9063->type == PMIC_TYPE_DA9063L)
> > +		da9063_devs_len -= 1;
> > +
> > +	ret = mfd_add_devices(da9063->dev, -1, da9063_devs, da9063_devs_len,
> > +			      NULL, da9063->irq_base, NULL);
> >  	if (ret)
> >  		dev_err(da9063->dev, "Cannot add MFD cells\n");
> >  
> 
> MFD cells definitely has less impact than regmap_range and regmap_irq.
> I agree, there's no point in having a completely new 
> static const struct mfd_cell da9063l_devs[] = { ... }  for DA9063L

This solution is fragile.

I agree that a new MFD cell is not required in its entirety.  It
would however, be better to split out the RTC entry into a new one and
only register it when (da9063->type == PMIC_TYPE_DA9063).  This is a
better solution than messing around with passed struct sizes.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH 2/6] mfd: da9063: Replace model with type

[Ye Xiaolong]

Hi, Marek

On 05/26, Marek Vasut wrote:
>On 05/26/2018 11:16 AM, kbuild test robot wrote:
>> Hi Marek,
>> 
>> I love your patch! Perhaps something to improve:
>> 
>> [auto build test WARNING on ljones-mfd/for-mfd-next]
>> [also build test WARNING on v4.17-rc6]
>> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
>> 
>> url:    https://github.com/0day-ci/linux/commits/Marek-Vasut/mfd-da9063-Rename-PMIC_DA9063-to-PMIC_CHIP_ID_DA9063/20180526-162613
>> base:   https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git for-mfd-next
>> config: x86_64-randconfig-x002-201820 (attached as .config)
>> compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
>> reproduce:
>>         # save the attached .config to linux build tree
>>         make ARCH=x86_64 
>> 
>> All warnings (new ones prefixed by >>):
>> 
>>    In file included from include/linux/kernel.h:10:0,
>>                     from drivers//regulator/da9063-regulator.c:16:
>>    drivers//regulator/da9063-regulator.c: In function 'da9063_regulator_probe':
>>    drivers//regulator/da9063-regulator.c:744:12: error: 'const struct da9063_dev_model' has no member named 'dev_model'
>>       if (model->dev_model == da9063->type)
>>                ^
>>    include/linux/compiler.h:58:30: note: in definition of macro '__trace_if'
>>      if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
>>                                  ^~~~
>>>> drivers//regulator/da9063-regulator.c:744:3: note: in expansion of macro 'if'
>>       if (model->dev_model == da9063->type)
>>       ^~
>>    drivers//regulator/da9063-regulator.c:744:12: error: 'const struct da9063_dev_model' has no member named 'dev_model'
>>       if (model->dev_model == da9063->type)
>>                ^
>>    include/linux/compiler.h:58:42: note: in definition of macro '__trace_if'
>>      if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
>>                                              ^~~~
>>>> drivers//regulator/da9063-regulator.c:744:3: note: in expansion of macro 'if'
>>       if (model->dev_model == da9063->type)
>>       ^~
>>    drivers//regulator/da9063-regulator.c:744:12: error: 'const struct da9063_dev_model' has no member named 'dev_model'
>>       if (model->dev_model == da9063->type)
>>                ^
>>    include/linux/compiler.h:69:16: note: in definition of macro '__trace_if'
>>       ______r = !!(cond);     \
>>                    ^~~~
>>>> drivers//regulator/da9063-regulator.c:744:3: note: in expansion of macro 'if'
>>       if (model->dev_model == da9063->type)
>>       ^~
>>    drivers//regulator/da9063-regulator.c:749:10: error: 'struct da9063' has no member named 'model'
>>        da9063->model);
>>              ^~
>> 
>> vim +/if +744 drivers//regulator/da9063-regulator.c
>
>Is it testing this patch without the other patches in the series or at
>least 1/6 ?

It was tested with the whole patch series as you can see in https://github.com/0day-ci/linux/commits/Marek-Vasut/mfd-da9063-Rename-PMIC_DA9063-to-PMIC_CHIP_ID_DA9063/20180526-162613.


Thanks,
Xiaolong
>
>-- 
>Best regards,
>Marek Vasut
>

Re: [PATCH 2/6] mfd: da9063: Replace model with type

[Marek Vasut]

On 05/30/2018 07:21 AM, Ye Xiaolong wrote:
> Hi, Marek
> 
> On 05/26, Marek Vasut wrote:
>> On 05/26/2018 11:16 AM, kbuild test robot wrote:
>>> Hi Marek,
>>>
>>> I love your patch! Perhaps something to improve:
>>>
>>> [auto build test WARNING on ljones-mfd/for-mfd-next]
>>> [also build test WARNING on v4.17-rc6]
>>> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
>>>
>>> url:    https://github.com/0day-ci/linux/commits/Marek-Vasut/mfd-da9063-Rename-PMIC_DA9063-to-PMIC_CHIP_ID_DA9063/20180526-162613
>>> base:   https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git for-mfd-next
>>> config: x86_64-randconfig-x002-201820 (attached as .config)
>>> compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
>>> reproduce:
>>>         # save the attached .config to linux build tree
>>>         make ARCH=x86_64 
>>>
>>> All warnings (new ones prefixed by >>):
>>>
>>>    In file included from include/linux/kernel.h:10:0,
>>>                     from drivers//regulator/da9063-regulator.c:16:
>>>    drivers//regulator/da9063-regulator.c: In function 'da9063_regulator_probe':
>>>    drivers//regulator/da9063-regulator.c:744:12: error: 'const struct da9063_dev_model' has no member named 'dev_model'
>>>       if (model->dev_model == da9063->type)
>>>                ^
>>>    include/linux/compiler.h:58:30: note: in definition of macro '__trace_if'
>>>      if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
>>>                                  ^~~~
>>>>> drivers//regulator/da9063-regulator.c:744:3: note: in expansion of macro 'if'
>>>       if (model->dev_model == da9063->type)
>>>       ^~
>>>    drivers//regulator/da9063-regulator.c:744:12: error: 'const struct da9063_dev_model' has no member named 'dev_model'
>>>       if (model->dev_model == da9063->type)
>>>                ^
>>>    include/linux/compiler.h:58:42: note: in definition of macro '__trace_if'
>>>      if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
>>>                                              ^~~~
>>>>> drivers//regulator/da9063-regulator.c:744:3: note: in expansion of macro 'if'
>>>       if (model->dev_model == da9063->type)
>>>       ^~
>>>    drivers//regulator/da9063-regulator.c:744:12: error: 'const struct da9063_dev_model' has no member named 'dev_model'
>>>       if (model->dev_model == da9063->type)
>>>                ^
>>>    include/linux/compiler.h:69:16: note: in definition of macro '__trace_if'
>>>       ______r = !!(cond);     \
>>>                    ^~~~
>>>>> drivers//regulator/da9063-regulator.c:744:3: note: in expansion of macro 'if'
>>>       if (model->dev_model == da9063->type)
>>>       ^~
>>>    drivers//regulator/da9063-regulator.c:749:10: error: 'struct da9063' has no member named 'model'
>>>        da9063->model);
>>>              ^~
>>>
>>> vim +/if +744 drivers//regulator/da9063-regulator.c
>>
>> Is it testing this patch without the other patches in the series or at
>> least 1/6 ?
> 
> It was tested with the whole patch series as you can see in https://github.com/0day-ci/linux/commits/Marek-Vasut/mfd-da9063-Rename-PMIC_DA9063-to-PMIC_CHIP_ID_DA9063/20180526-162613.

Ha, I see the problem. Thanks for confirming it's checked with the whole
series.

-- 
Best regards,
Marek Vasut

Re: [PATCH 4/6] mfd: da9063: Disallow RTC on DA9063L

[Marek Vasut]

On 05/29/2018 09:55 AM, Lee Jones wrote:
> On Thu, 24 May 2018, Steve Twiss wrote:
> 
>> Thanks Marek,
>>
>> On 23 May 2018 12:42 Marek Vasut wrote,
>>
>>> To: linux-kernel@vger.kernel.org
>>> Cc: Marek Vasut <marek.vasut+renesas@gmail.com>; Geert Uytterhoeven <geert+renesas@glider.be>; Lee Jones <lee.jones@linaro.org>; Mark Brown <broonie@kernel.org>; Steve Twiss <stwiss.opensource@diasemi.com>; Wolfram Sang <wsa+renesas@sang-engineering.com>; linux-renesas-soc@vger.kernel.org
>>> Subject: [PATCH 4/6] mfd: da9063: Disallow RTC on DA9063L
>>>
>>> The DA9063L does not contain RTC block, unlike the full DA9063.
>>> Do not allow binding RTC driver on this variant of the chip.
>>>
>>> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
>>> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
>>> Cc: Lee Jones <lee.jones@linaro.org>
>>> Cc: Mark Brown <broonie@kernel.org>
>>> Cc: Steve Twiss <stwiss.opensource@diasemi.com>
>>> Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>
>>> Cc: linux-renesas-soc@vger.kernel.org
>>> ---
>>>  drivers/mfd/da9063-core.c | 18 +++++++++++-------
>>>  1 file changed, 11 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/drivers/mfd/da9063-core.c b/drivers/mfd/da9063-core.c index 7360b76b4f72..263c83006413 100644
>>> --- a/drivers/mfd/da9063-core.c
>>> +++ b/drivers/mfd/da9063-core.c
>>> @@ -101,14 +101,14 @@ static const struct mfd_cell da9063_devs[] = {
>>>  		.of_compatible = "dlg,da9063-onkey",
>>>  	},
>>>  	{
>>> +		.name		= DA9063_DRVNAME_VIBRATION,
>>> +	},
>>> +	{	/* Only present on DA9063 , not on DA9063L */
>>>  		.name		= DA9063_DRVNAME_RTC,
>>>  		.num_resources	= ARRAY_SIZE(da9063_rtc_resources),
>>>  		.resources	= da9063_rtc_resources,
>>>  		.of_compatible	= "dlg,da9063-rtc",
>>>  	},
>>> -	{
>>> -		.name		= DA9063_DRVNAME_VIBRATION,
>>> -	},
>>>  };
>>>  
>>>  static int da9063_clear_fault_log(struct da9063 *da9063) @@ -163,7 +163,7 @@ int da9063_device_init(struct da9063 *da9063, unsigned int irq)  {
>>>  	struct da9063_pdata *pdata = da9063->dev->platform_data;
>>>  	int model, variant_id, variant_code;
>>> -	int ret;
>>> +	int da9063_devs_len, ret;
>>>  
>>>  	ret = da9063_clear_fault_log(da9063);
>>>  	if (ret < 0)
>>> @@ -225,9 +225,13 @@ int da9063_device_init(struct da9063 *da9063, unsigned int irq)
>>>  
>>>  	da9063->irq_base = regmap_irq_chip_get_base(da9063->regmap_irq);
>>>  
>>> -	ret = mfd_add_devices(da9063->dev, -1, da9063_devs,
>>> -			      ARRAY_SIZE(da9063_devs), NULL, da9063->irq_base,
>>> -			      NULL);
>>> +	da9063_devs_len = ARRAY_SIZE(da9063_devs);
>>> +	/* RTC, the last device in the list, is only present on DA9063 */
>>> +	if (da9063->type == PMIC_TYPE_DA9063L)
>>> +		da9063_devs_len -= 1;
>>> +
>>> +	ret = mfd_add_devices(da9063->dev, -1, da9063_devs, da9063_devs_len,
>>> +			      NULL, da9063->irq_base, NULL);
>>>  	if (ret)
>>>  		dev_err(da9063->dev, "Cannot add MFD cells\n");
>>>  
>>
>> MFD cells definitely has less impact than regmap_range and regmap_irq.
>> I agree, there's no point in having a completely new 
>> static const struct mfd_cell da9063l_devs[] = { ... }  for DA9063L
> 
> This solution is fragile.
> 
> I agree that a new MFD cell is not required in its entirety.  It
> would however, be better to split out the RTC entry into a new one and
> only register it when (da9063->type == PMIC_TYPE_DA9063).  This is a
> better solution than messing around with passed struct sizes.

This indeed is better.

btw this da9063_device_init() function is missing a failpath to undo the
setup done by da9063_irq_init(), so I'll be sending a patch for that too
shortly.

-- 
Best regards,
Marek Vasut

Re: [PATCH 6/6] mfd: da9063: Add DA9063L support

[Marek Vasut]

On 05/24/2018 07:30 PM, Steve Twiss wrote:
> On 24 May 2018 15:51 Marek Vasut wrote:
> 
> Hi Marek,
> 
>> To: Steve Twiss <stwiss.opensource@diasemi.com>; linux-kernel@vger.kernel.org
>> Cc: Marek Vasut <marek.vasut+renesas@gmail.com>; Geert Uytterhoeven
>> <geert+renesas@glider.be>; Lee Jones <lee.jones@linaro.org>; Mark Brown
>> <broonie@kernel.org>; Wolfram Sang <wsa+renesas@sang-engineering.com>;
>> linux-renesas-soc@vger.kernel.org
>> Subject: Re: [PATCH 6/6] mfd: da9063: Add DA9063L support
>>
>> On 05/24/2018 02:32 PM, Steve Twiss wrote:
>>> On 24 May 2018 @ 12:49 Steve Twiss wrote:
>>>>> On 23 May 2018 12:43 Marek Vasut wrote,
>>>>>
>>>>> To: linux-kernel@vger.kernel.org
>>>>> Subject: [PATCH 6/6] mfd: da9063: Add DA9063L support
>>>>>
>>>>> Add support for DA9063L, which is a reduced variant of the DA9063 with less regulators and without RTC.
>>>>>
>>>>
>>>> There's potentially more to this file. Without an RTC the regmap
>>>> access tables would change and the usual DA9063 (BB silicon) tables would become invalid.
>>>> The tables for da9063_bb_readable_ranges, da9063_bb_writeable_ranges,
>>>> da9063_bb_volatile_ranges, would need to be updated for DA9063L, if a new chip model was needed.
>>>>
>>>> The new ranges would be this (see below), and would remove any RTC accesses in the new chip model.
>>>>
>>>> static const struct regmap_range da9063l_bb_readable_ranges[] = {
>>>> 	{
>>>> 		.range_min = DA9063_REG_PAGE_CON,
>>>> 		.range_max = DA9063_REG_MON_A10_RES,
>>>> 	}, {
>>>> 		.range_min = DA9063_REG_SEQ,
>>>> 		.range_max = DA9063_REG_ID_32_31,
>>>> 	}, {
>>>> 		.range_min = DA9063_REG_SEQ_A,
>>>> 		.range_max = DA9063_REG_AUTO3_LOW,
>>>> 	}, {
>>>> 		.range_min = DA9063_REG_T_OFFSET,
>>>> 		.range_max = DA9063_BB_REG_GP_ID_19,
>>>> 	}, {
>>>> 		.range_min = DA9063_REG_CHIP_ID,
>>>> 		.range_max = DA9063_REG_CHIP_VARIANT,
>>>> 	},
>>>> };
>>>>
>>>> static const struct regmap_range da9063l_bb_writeable_ranges[] = {
>>>> 	{
>>>> 		.range_min = DA9063_REG_PAGE_CON,
>>>> 		.range_max = DA9063_REG_PAGE_CON,
>>>> 	}, {
>>>> 		.range_min = DA9063_REG_FAULT_LOG,
>>>> 		.range_max = DA9063_REG_VSYS_MON,
>>>> 	}, {
>>>> 		.range_min = DA9063_REG_SEQ,
>>>> 		.range_max = DA9063_REG_ID_32_31,
>>>> 	}, {
>>>> 		.range_min = DA9063_REG_SEQ_A,
>>>> 		.range_max = DA9063_REG_AUTO3_LOW,
>>>> 	}, {
>>>> 		.range_min = DA9063_REG_CONFIG_I,
>>>> 		.range_max = DA9063_BB_REG_MON_REG_4,
>>>> 	}, {
>>>> 		.range_min = DA9063_BB_REG_GP_ID_0,
>>>> 		.range_max = DA9063_BB_REG_GP_ID_19,
>>>> 	},
>>>> };
>>>>
>>>> static const struct regmap_range da9063l_bb_volatile_ranges[] = {
>>>> 	{
>>>> 		.range_min = DA9063_REG_PAGE_CON,
>>>> 		.range_max = DA9063_REG_EVENT_D,
>>>> 	}, {
>>>> 		.range_min = DA9063_REG_CONTROL_A,
>>>> 		.range_max = DA9063_REG_CONTROL_B,
>>>> 	}, {
>>>> 		.range_min = DA9063_REG_CONTROL_E,
>>>> 		.range_max = DA9063_REG_CONTROL_F,
>>>> 	}, {
>>>> 		.range_min = DA9063_REG_BCORE2_CONT,
>>>> 		.range_max = DA9063_REG_LDO11_CONT,
>>>> 	}, {
>>>> 		.range_min = DA9063_REG_DVC_1,
>>>> 		.range_max = DA9063_REG_ADC_MAN,
>>>> 	}, {
>>>> 		.range_min = DA9063_REG_ADC_RES_L,
>>>> 		.range_max = DA9063_REG_MON_A10_RES,
>>>> 	}, {
>>>> 		.range_min = DA9063_REG_SEQ,
>>>> 		.range_max = DA9063_REG_SEQ,
>>>> 	}, {
>>>> 		.range_min = DA9063_REG_EN_32K,
>>>> 		.range_max = DA9063_REG_EN_32K,
>>>> 	}, {
>>>> 		.range_min = DA9063_BB_REG_MON_REG_5,
>>>> 		.range_max = DA9063_BB_REG_MON_REG_6,
>>>> 	},
>>>> };
>>>>
>>>> However this is a larger and more wide-ranging change compared to the
>>>> one proposed by Marek, and would require other alterations to fit
>>>> this in. Also I'm undecided to what it would really add apart from a
>>>> new chip model: I have been told accessing the DA9063 RTC register locations
>>>> has no effect in the DA9063L.
>>>
>>> Looking at this further, there is also a new IRQ regmap.
>>> Again this comes down to whether a full chip model is needed or not.
>>> If not, then the IRQ map does not need to be changed as given. Otherwise the
>>> removal of the following:
>>>
>>> 	[DA9063_IRQ_ALARM] = {
>>> 		.reg_offset = DA9063_REG_EVENT_A_OFFSET,
>>> 		.mask = DA9063_M_ALARM,
>>> 	},
>>> 	[DA9063_IRQ_TICK] = {
>>> 		.reg_offset = DA9063_REG_EVENT_A_OFFSET,
>>> 		.mask = DA9063_M_TICK,
>>> 	},
>>>
>>> prior to registering the IRQs in the chip model would be needed.
>>> The new regmap_irq would be:
>>>
>>> static const struct regmap_irq da9063l_irqs[] = {
>>> 	/* DA9063 event A register */
>>> 	[DA9063L_IRQ_ONKEY] = {
>>> 		.reg_offset = DA9063_REG_EVENT_A_OFFSET,
>>> 		.mask = DA9063_M_ONKEY,
>>> 	},
>>> 	[DA9063L_IRQ_ADC_RDY] = {
>>> 		.reg_offset = DA9063_REG_EVENT_A_OFFSET,
>>> 		.mask = DA9063_M_ADC_RDY,
>>> 	},
>>> 	[DA9063L_IRQ_SEQ_RDY] = {
>>> 		.reg_offset = DA9063_REG_EVENT_A_OFFSET,
>>> 		.mask = DA9063_M_SEQ_RDY,
>>> 	},
>>> 	/* DA9063 event B register */
>>> 	[DA9063L_IRQ_WAKE] = {
>>> 		.reg_offset = DA9063_REG_EVENT_B_OFFSET,
>>> 		.mask = DA9063_M_WAKE,
>>> 	},
>>> 	[DA9063L_IRQ_TEMP] = {
>>> 		.reg_offset = DA9063_REG_EVENT_B_OFFSET,
>>> 		.mask = DA9063_M_TEMP,
>>> 	},
>>> 	[DA9063L_IRQ_COMP_1V2] = {
>>> 		.reg_offset = DA9063_REG_EVENT_B_OFFSET,
>>> 		.mask = DA9063_M_COMP_1V2,
>>> 	},
>>> 	[DA9063L_IRQ_LDO_LIM] = {
>>> 		.reg_offset = DA9063_REG_EVENT_B_OFFSET,
>>> 		.mask = DA9063_M_LDO_LIM,
>>> 	},
>>> 	[DA9063L_IRQ_REG_UVOV] = {
>>> 		.reg_offset = DA9063_REG_EVENT_B_OFFSET,
>>> 		.mask = DA9063_M_UVOV,
>>> 	},
>>> 	[DA9063L_IRQ_DVC_RDY] = {
>>> 		.reg_offset = DA9063_REG_EVENT_B_OFFSET,
>>> 		.mask = DA9063_M_DVC_RDY,
>>> 	},
>>> 	[DA9063L_IRQ_VDD_MON] = {
>>> 		.reg_offset = DA9063_REG_EVENT_B_OFFSET,
>>> 		.mask = DA9063_M_VDD_MON,
>>> 	},
>>> 	[DA9063L_IRQ_WARN] = {
>>> 		.reg_offset = DA9063_REG_EVENT_B_OFFSET,
>>> 		.mask = DA9063_M_VDD_WARN,
>>> 	},
>>> 	/* DA9063 event C register */
>>> 	[DA9063L_IRQ_GPI0] = {
>>> 		.reg_offset = DA9063_REG_EVENT_C_OFFSET,
>>> 		.mask = DA9063_M_GPI0,
>>> 	},
>>> 	[DA9063L_IRQ_GPI1] = {
>>> 		.reg_offset = DA9063_REG_EVENT_C_OFFSET,
>>> 		.mask = DA9063_M_GPI1,
>>> 	},
>>> 	[DA9063L_IRQ_GPI2] = {
>>> 		.reg_offset = DA9063_REG_EVENT_C_OFFSET,
>>> 		.mask = DA9063_M_GPI2,
>>> 	},
>>> 	[DA9063L_IRQ_GPI3] = {
>>> 		.reg_offset = DA9063_REG_EVENT_C_OFFSET,
>>> 		.mask = DA9063_M_GPI3,
>>> 	},
>>> 	[DA9063L_IRQ_GPI4] = {
>>> 		.reg_offset = DA9063_REG_EVENT_C_OFFSET,
>>> 		.mask = DA9063_M_GPI4,
>>> 	},
>>> 	[DA9063L_IRQ_GPI5] = {
>>> 		.reg_offset = DA9063_REG_EVENT_C_OFFSET,
>>> 		.mask = DA9063_M_GPI5,
>>> 	},
>>> 	[DA9063L_IRQ_GPI6] = {
>>> 		.reg_offset = DA9063_REG_EVENT_C_OFFSET,
>>> 		.mask = DA9063_M_GPI6,
>>> 	},
>>> 	[DA9063L_IRQ_GPI7] = {
>>> 		.reg_offset = DA9063_REG_EVENT_C_OFFSET,
>>> 		.mask = DA9063_M_GPI7,
>>> 	},
>>> 	/* DA9063 event D register */
>>> 	[DA9063L_IRQ_GPI8] = {
>>> 		.reg_offset = DA9063_REG_EVENT_D_OFFSET,
>>> 		.mask = DA9063_M_GPI8,
>>> 	},
>>> 	[DA9063L_IRQ_GPI9] = {
>>> 		.reg_offset = DA9063_REG_EVENT_D_OFFSET,
>>> 		.mask = DA9063_M_GPI9,
>>> 	},
>>> 	[DA9063L_IRQ_GPI10] = {
>>> 		.reg_offset = DA9063_REG_EVENT_D_OFFSET,
>>> 		.mask = DA9063_M_GPI10,
>>> 	},
>>> 	[DA9063L_IRQ_GPI11] = {
>>> 		.reg_offset = DA9063_REG_EVENT_D_OFFSET,
>>> 		.mask = DA9063_M_GPI11,
>>> 	},
>>> 	[DA9063L_IRQ_GPI12] = {
>>> 		.reg_offset = DA9063_REG_EVENT_D_OFFSET,
>>> 		.mask = DA9063_M_GPI12,
>>> 	},
>>> 	[DA9063L_IRQ_GPI13] = {
>>> 		.reg_offset = DA9063_REG_EVENT_D_OFFSET,
>>> 		.mask = DA9063_M_GPI13,
>>> 	},
>>> 	[DA9063L_IRQ_GPI14] = {
>>> 		.reg_offset = DA9063_REG_EVENT_D_OFFSET,
>>> 		.mask = DA9063_M_GPI14,
>>> 	},
>>> 	[DA9063L_IRQ_GPI15] = {
>>> 		.reg_offset = DA9063_REG_EVENT_D_OFFSET,
>>> 		.mask = DA9063_M_GPI15,
>>> 	},
>>> };
>>
>> We can probably do the same trick with the regmaps and irqmaps as with the
>> rest, that is, reorder them and register only a smaller portion ?
> 
> I like the "reorder and only register a smaller portion" trick. But it wouldn't work
> with what I gave earlier today, without some modification.
> For instance, the first register readable entry range in the  DA9063 BB is:
> 
> static const struct regmap_range da9063_bb_readable_ranges[] = {
> 	{
> 		.range_min = DA9063_REG_PAGE_CON,
> 		.range_max = DA9063_BB_REG_SECOND_D,
> 	}, {
> 
> But for the DA9063L, this first range entry would be changed, not removed:
> 
> static const struct regmap_range da9063l_bb_readable_ranges[] = {
> 	{
> 		.range_min = DA9063_REG_PAGE_CON,
> 		.range_max = DA9063_REG_MON_A10_RES,
> 	}, {
> 
> So it's not all-or-nothing. But possibly it could be made to work if those ranges were split
> into two pieces.
> 
> However, it might get messy to maintain in future -- sometimes register ranges need to be
> updated with new components or if a new feature is added -- usually I need to work it
> all out on paper with the full register map. Splitting up ranges might make it a little
> messier. But, it's not impossible.
> 
> For the DA9062 and DA9061 this was done using separate ranges and using the macro
> regmap_reg_range(). It's not that messy to read, e.g. 
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/mfd/da9062-core.c?h=next-20180517#n367

Hum, can you point me to the datasheet sections so I can check this
difference please ? I think I have the rest of the feedback addressed,
so I want to check this one before submitting the next version.

-- 
Best regards,
Marek Vasut

Re: [PATCH 6/6] mfd: da9063: Add DA9063L support

[Marek Vasut]

On 05/29/2018 09:46 AM, Lee Jones wrote:
> On Thu, 24 May 2018, Marek Vasut wrote:
>> On 05/24/2018 02:32 PM, Steve Twiss wrote:
>>> On 24 May 2018 @ 12:49 Steve Twiss wrote:
> 
> [...]
> 
>>> static const struct regmap_irq da9063l_irqs[] = {
>>> 	/* DA9063 event A register */
>>> 	[DA9063L_IRQ_ONKEY] = {
>>> 		.reg_offset = DA9063_REG_EVENT_A_OFFSET,
>>> 		.mask = DA9063_M_ONKEY,
>>> 	},
> 
> [...]
> 
>>> 	[DA9063L_IRQ_GPI15] = {
>>> 		.reg_offset = DA9063_REG_EVENT_D_OFFSET,
>>> 		.mask = DA9063_M_GPI15,
>>> 	},
>>> };
>>
>> We can probably do the same trick with the regmaps and irqmaps as with
>> the rest, that is, reorder them and register only a smaller portion ?
> 
> Please also consider using REGMAP_IRQ_REG().

Done in a new separate patch with a simple sed oneliner

sed -i "/\[DA9063_IRQ_/
{N;N;N;s/\n//g;s/.*\[\(DA9063_IRQ_[^]]\+\)].*reg_offset = \([^,]\+\),.*
= \([^,]\+\),.*/\tREGMAP_IRQ_REG(\1, \2, \3),/}" drivers/mfd/da9063-irq.c

-- 
Best regards,
Marek Vasut

RE: [PATCH 6/6] mfd: da9063: Add DA9063L support

[Steve Twiss]

On 30 May 2018 12:25 Marek Vasut wrote:

> Subject: Re: [PATCH 6/6] mfd: da9063: Add DA9063L support
> On 05/24/2018 07:30 PM, Steve Twiss wrote:
> > On 24 May 2018 15:51 Marek Vasut wrote:
> >
> > Hi Marek,
> >
> >> Subject: Re: [PATCH 6/6] mfd: da9063: Add DA9063L support
> >>
> >> On 05/24/2018 02:32 PM, Steve Twiss wrote:
> >>> On 24 May 2018 @ 12:49 Steve Twiss wrote:
> >>>>> On 23 May 2018 12:43 Marek Vasut wrote,
> >>>>>
> >>>>> To: linux-kernel@vger.kernel.org
> >>>>> Subject: [PATCH 6/6] mfd: da9063: Add DA9063L support
> >>>>>
> >>>>> Add support for DA9063L, which is a reduced variant of the DA9063 with less regulators and without RTC.
> >>>>>
> >>>>
> >>>> There's potentially more to this file. Without an RTC the regmap
> >>>> access tables would change and the usual DA9063 (BB silicon) tables would become invalid.
> >>>> The tables for da9063_bb_readable_ranges, da9063_bb_writeable_ranges,
> >>>> da9063_bb_volatile_ranges, would need to be updated for DA9063L, if a new chip model was needed.
> >>>>
> >>>> The new ranges would be this (see below), and would remove any RTC accesses in the new chip model.
> >>>>
> >>>> static const struct regmap_range da9063l_bb_readable_ranges[] = {
> >>>> 	{
> >>>> 		.range_min = DA9063_REG_PAGE_CON,
> >>>> 		.range_max = DA9063_REG_MON_A10_RES,
> >>>> 	}, {
> >>>> 		.range_min = DA9063_REG_SEQ,
> >>>> 		.range_max = DA9063_REG_ID_32_31,
> >>>> 	}, {
> >>>> 		.range_min = DA9063_REG_SEQ_A,
> >>>> 		.range_max = DA9063_REG_AUTO3_LOW,
> >>>> 	}, {
> >>>> 		.range_min = DA9063_REG_T_OFFSET,
> >>>> 		.range_max = DA9063_BB_REG_GP_ID_19,
> >>>> 	}, {
> >>>> 		.range_min = DA9063_REG_CHIP_ID,
> >>>> 		.range_max = DA9063_REG_CHIP_VARIANT,
> >>>> 	},
> >>>> };
> >>>>
> >>>> static const struct regmap_range da9063l_bb_writeable_ranges[] = {
> >>>> 	{
> >>>> 		.range_min = DA9063_REG_PAGE_CON,
> >>>> 		.range_max = DA9063_REG_PAGE_CON,
> >>>> 	}, {
> >>>> 		.range_min = DA9063_REG_FAULT_LOG,
> >>>> 		.range_max = DA9063_REG_VSYS_MON,
> >>>> 	}, {
> >>>> 		.range_min = DA9063_REG_SEQ,
> >>>> 		.range_max = DA9063_REG_ID_32_31,
> >>>> 	}, {
> >>>> 		.range_min = DA9063_REG_SEQ_A,
> >>>> 		.range_max = DA9063_REG_AUTO3_LOW,
> >>>> 	}, {
> >>>> 		.range_min = DA9063_REG_CONFIG_I,
> >>>> 		.range_max = DA9063_BB_REG_MON_REG_4,
> >>>> 	}, {
> >>>> 		.range_min = DA9063_BB_REG_GP_ID_0,
> >>>> 		.range_max = DA9063_BB_REG_GP_ID_19,
> >>>> 	},
> >>>> };
> >>>>
> >>>> static const struct regmap_range da9063l_bb_volatile_ranges[] = {
> >>>> 	{
> >>>> 		.range_min = DA9063_REG_PAGE_CON,
> >>>> 		.range_max = DA9063_REG_EVENT_D,
> >>>> 	}, {
> >>>> 		.range_min = DA9063_REG_CONTROL_A,
> >>>> 		.range_max = DA9063_REG_CONTROL_B,
> >>>> 	}, {
> >>>> 		.range_min = DA9063_REG_CONTROL_E,
> >>>> 		.range_max = DA9063_REG_CONTROL_F,
> >>>> 	}, {
> >>>> 		.range_min = DA9063_REG_BCORE2_CONT,
> >>>> 		.range_max = DA9063_REG_LDO11_CONT,
> >>>> 	}, {
> >>>> 		.range_min = DA9063_REG_DVC_1,
> >>>> 		.range_max = DA9063_REG_ADC_MAN,
> >>>> 	}, {
> >>>> 		.range_min = DA9063_REG_ADC_RES_L,
> >>>> 		.range_max = DA9063_REG_MON_A10_RES,
> >>>> 	}, {
> >>>> 		.range_min = DA9063_REG_SEQ,
> >>>> 		.range_max = DA9063_REG_SEQ,
> >>>> 	}, {
> >>>> 		.range_min = DA9063_REG_EN_32K,
> >>>> 		.range_max = DA9063_REG_EN_32K,
> >>>> 	}, {
> >>>> 		.range_min = DA9063_BB_REG_MON_REG_5,
> >>>> 		.range_max = DA9063_BB_REG_MON_REG_6,
> >>>> 	},
> >>>> };
> >>>>
> >>>> However this is a larger and more wide-ranging change compared to the
> >>>> one proposed by Marek, and would require other alterations to fit
> >>>> this in. Also I'm undecided to what it would really add apart from a
> >>>> new chip model: I have been told accessing the DA9063 RTC register locations
> >>>> has no effect in the DA9063L.
> >>>
> >>> Looking at this further, there is also a new IRQ regmap.
> >>> Again this comes down to whether a full chip model is needed or not.
> >>> If not, then the IRQ map does not need to be changed as given. Otherwise the
> >>> removal of the following:
> >>>
> >>> 	[DA9063_IRQ_ALARM] = {
> >>> 		.reg_offset = DA9063_REG_EVENT_A_OFFSET,
> >>> 		.mask = DA9063_M_ALARM,
> >>> 	},
> >>> 	[DA9063_IRQ_TICK] = {
> >>> 		.reg_offset = DA9063_REG_EVENT_A_OFFSET,
> >>> 		.mask = DA9063_M_TICK,
> >>> 	},
> >>>
> >>> prior to registering the IRQs in the chip model would be needed.
> >>> The new regmap_irq would be:
> >>>
> >>> static const struct regmap_irq da9063l_irqs[] = {
> >>> 	/* DA9063 event A register */
> >>> 	[DA9063L_IRQ_ONKEY] = {
> >>> 		.reg_offset = DA9063_REG_EVENT_A_OFFSET,
> >>> 		.mask = DA9063_M_ONKEY,
> >>> 	},
> >>> 	[DA9063L_IRQ_ADC_RDY] = {
> >>> 		.reg_offset = DA9063_REG_EVENT_A_OFFSET,
> >>> 		.mask = DA9063_M_ADC_RDY,
> >>> 	},
> >>> 	[DA9063L_IRQ_SEQ_RDY] = {
> >>> 		.reg_offset = DA9063_REG_EVENT_A_OFFSET,
> >>> 		.mask = DA9063_M_SEQ_RDY,
> >>> 	},
> >>> 	/* DA9063 event B register */
> >>> 	[DA9063L_IRQ_WAKE] = {
> >>> 		.reg_offset = DA9063_REG_EVENT_B_OFFSET,
> >>> 		.mask = DA9063_M_WAKE,
> >>> 	},
> >>> 	[DA9063L_IRQ_TEMP] = {
> >>> 		.reg_offset = DA9063_REG_EVENT_B_OFFSET,
> >>> 		.mask = DA9063_M_TEMP,
> >>> 	},
> >>> 	[DA9063L_IRQ_COMP_1V2] = {
> >>> 		.reg_offset = DA9063_REG_EVENT_B_OFFSET,
> >>> 		.mask = DA9063_M_COMP_1V2,
> >>> 	},
> >>> 	[DA9063L_IRQ_LDO_LIM] = {
> >>> 		.reg_offset = DA9063_REG_EVENT_B_OFFSET,
> >>> 		.mask = DA9063_M_LDO_LIM,
> >>> 	},
> >>> 	[DA9063L_IRQ_REG_UVOV] = {
> >>> 		.reg_offset = DA9063_REG_EVENT_B_OFFSET,
> >>> 		.mask = DA9063_M_UVOV,
> >>> 	},
> >>> 	[DA9063L_IRQ_DVC_RDY] = {
> >>> 		.reg_offset = DA9063_REG_EVENT_B_OFFSET,
> >>> 		.mask = DA9063_M_DVC_RDY,
> >>> 	},
> >>> 	[DA9063L_IRQ_VDD_MON] = {
> >>> 		.reg_offset = DA9063_REG_EVENT_B_OFFSET,
> >>> 		.mask = DA9063_M_VDD_MON,
> >>> 	},
> >>> 	[DA9063L_IRQ_WARN] = {
> >>> 		.reg_offset = DA9063_REG_EVENT_B_OFFSET,
> >>> 		.mask = DA9063_M_VDD_WARN,
> >>> 	},
> >>> 	/* DA9063 event C register */
> >>> 	[DA9063L_IRQ_GPI0] = {
> >>> 		.reg_offset = DA9063_REG_EVENT_C_OFFSET,
> >>> 		.mask = DA9063_M_GPI0,
> >>> 	},
> >>> 	[DA9063L_IRQ_GPI1] = {
> >>> 		.reg_offset = DA9063_REG_EVENT_C_OFFSET,
> >>> 		.mask = DA9063_M_GPI1,
> >>> 	},
> >>> 	[DA9063L_IRQ_GPI2] = {
> >>> 		.reg_offset = DA9063_REG_EVENT_C_OFFSET,
> >>> 		.mask = DA9063_M_GPI2,
> >>> 	},
> >>> 	[DA9063L_IRQ_GPI3] = {
> >>> 		.reg_offset = DA9063_REG_EVENT_C_OFFSET,
> >>> 		.mask = DA9063_M_GPI3,
> >>> 	},
> >>> 	[DA9063L_IRQ_GPI4] = {
> >>> 		.reg_offset = DA9063_REG_EVENT_C_OFFSET,
> >>> 		.mask = DA9063_M_GPI4,
> >>> 	},
> >>> 	[DA9063L_IRQ_GPI5] = {
> >>> 		.reg_offset = DA9063_REG_EVENT_C_OFFSET,
> >>> 		.mask = DA9063_M_GPI5,
> >>> 	},
> >>> 	[DA9063L_IRQ_GPI6] = {
> >>> 		.reg_offset = DA9063_REG_EVENT_C_OFFSET,
> >>> 		.mask = DA9063_M_GPI6,
> >>> 	},
> >>> 	[DA9063L_IRQ_GPI7] = {
> >>> 		.reg_offset = DA9063_REG_EVENT_C_OFFSET,
> >>> 		.mask = DA9063_M_GPI7,
> >>> 	},
> >>> 	/* DA9063 event D register */
> >>> 	[DA9063L_IRQ_GPI8] = {
> >>> 		.reg_offset = DA9063_REG_EVENT_D_OFFSET,
> >>> 		.mask = DA9063_M_GPI8,
> >>> 	},
> >>> 	[DA9063L_IRQ_GPI9] = {
> >>> 		.reg_offset = DA9063_REG_EVENT_D_OFFSET,
> >>> 		.mask = DA9063_M_GPI9,
> >>> 	},
> >>> 	[DA9063L_IRQ_GPI10] = {
> >>> 		.reg_offset = DA9063_REG_EVENT_D_OFFSET,
> >>> 		.mask = DA9063_M_GPI10,
> >>> 	},
> >>> 	[DA9063L_IRQ_GPI11] = {
> >>> 		.reg_offset = DA9063_REG_EVENT_D_OFFSET,
> >>> 		.mask = DA9063_M_GPI11,
> >>> 	},
> >>> 	[DA9063L_IRQ_GPI12] = {
> >>> 		.reg_offset = DA9063_REG_EVENT_D_OFFSET,
> >>> 		.mask = DA9063_M_GPI12,
> >>> 	},
> >>> 	[DA9063L_IRQ_GPI13] = {
> >>> 		.reg_offset = DA9063_REG_EVENT_D_OFFSET,
> >>> 		.mask = DA9063_M_GPI13,
> >>> 	},
> >>> 	[DA9063L_IRQ_GPI14] = {
> >>> 		.reg_offset = DA9063_REG_EVENT_D_OFFSET,
> >>> 		.mask = DA9063_M_GPI14,
> >>> 	},
> >>> 	[DA9063L_IRQ_GPI15] = {
> >>> 		.reg_offset = DA9063_REG_EVENT_D_OFFSET,
> >>> 		.mask = DA9063_M_GPI15,
> >>> 	},
> >>> };
> >>
> >> We can probably do the same trick with the regmaps and irqmaps as with the
> >> rest, that is, reorder them and register only a smaller portion ?
> >
> > I like the "reorder and only register a smaller portion" trick. But it wouldn't work
> > with what I gave earlier today, without some modification.
> > For instance, the first register readable entry range in the  DA9063 BB is:
> >
> > static const struct regmap_range da9063_bb_readable_ranges[] = {
> > 	{
> > 		.range_min = DA9063_REG_PAGE_CON,
> > 		.range_max = DA9063_BB_REG_SECOND_D,
> > 	}, {
> >
> > But for the DA9063L, this first range entry would be changed, not removed:
> >
> > static const struct regmap_range da9063l_bb_readable_ranges[] = {
> > 	{
> > 		.range_min = DA9063_REG_PAGE_CON,
> > 		.range_max = DA9063_REG_MON_A10_RES,
> > 	}, {
> >
> > So it's not all-or-nothing. But possibly it could be made to work if those ranges were split
> > into two pieces.
> >
> > However, it might get messy to maintain in future -- sometimes register ranges need to be
> > updated with new components or if a new feature is added -- usually I need to work it
> > all out on paper with the full register map. Splitting up ranges might make it a little
> > messier. But, it's not impossible.
> >
> > For the DA9062 and DA9061 this was done using separate ranges and using the macro
> > regmap_reg_range(). It's not that messy to read, e.g.
> > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/mfd/da9062-core.c?h=next-20180517#n367
> 
> Hum, can you point me to the datasheet sections so I can check this
> difference please ? I think I have the rest of the feedback addressed,
> so I want to check this one before submitting the next version.

Hi Marek,

My apologies for the time taken to respond. I have been travelling.

Datasheets are found on the Dialog company website.
End of the page, look for Resources > Datasheets.

https://www.dialog-semiconductor.com/products/da9061
https://www.dialog-semiconductor.com/products/da9062
https://www.dialog-semiconductor.com/products/da9063
https://www.dialog-semiconductor.com/products/da9063L

The chip model {readable, writable, volatile} register definitions are given clearly in the device
drivers. At least they will match what is expected by the Linux device driver. There is no easy
chip model list found in the datasheets.

Regards,
Steve

Re: [PATCH 6/6] mfd: da9063: Add DA9063L support

[Marek Vasut]

On 05/31/2018 02:45 PM, Steve Twiss wrote:
> On 30 May 2018 12:25 Marek Vasut wrote:
> 
>> Subject: Re: [PATCH 6/6] mfd: da9063: Add DA9063L support
>> On 05/24/2018 07:30 PM, Steve Twiss wrote:
>>> On 24 May 2018 15:51 Marek Vasut wrote:
>>>
>>> Hi Marek,
>>>
>>>> Subject: Re: [PATCH 6/6] mfd: da9063: Add DA9063L support
>>>>
>>>> On 05/24/2018 02:32 PM, Steve Twiss wrote:
>>>>> On 24 May 2018 @ 12:49 Steve Twiss wrote:
>>>>>>> On 23 May 2018 12:43 Marek Vasut wrote,
>>>>>>>
>>>>>>> To: linux-kernel@vger.kernel.org
>>>>>>> Subject: [PATCH 6/6] mfd: da9063: Add DA9063L support
>>>>>>>
>>>>>>> Add support for DA9063L, which is a reduced variant of the DA9063 with less regulators and without RTC.
>>>>>>>
>>>>>>
>>>>>> There's potentially more to this file. Without an RTC the regmap
>>>>>> access tables would change and the usual DA9063 (BB silicon) tables would become invalid.
>>>>>> The tables for da9063_bb_readable_ranges, da9063_bb_writeable_ranges,
>>>>>> da9063_bb_volatile_ranges, would need to be updated for DA9063L, if a new chip model was needed.
>>>>>>
>>>>>> The new ranges would be this (see below), and would remove any RTC accesses in the new chip model.
>>>>>>
>>>>>> static const struct regmap_range da9063l_bb_readable_ranges[] = {
>>>>>> 	{
>>>>>> 		.range_min = DA9063_REG_PAGE_CON,
>>>>>> 		.range_max = DA9063_REG_MON_A10_RES,
>>>>>> 	}, {
>>>>>> 		.range_min = DA9063_REG_SEQ,
>>>>>> 		.range_max = DA9063_REG_ID_32_31,
>>>>>> 	}, {
>>>>>> 		.range_min = DA9063_REG_SEQ_A,
>>>>>> 		.range_max = DA9063_REG_AUTO3_LOW,
>>>>>> 	}, {
>>>>>> 		.range_min = DA9063_REG_T_OFFSET,
>>>>>> 		.range_max = DA9063_BB_REG_GP_ID_19,
>>>>>> 	}, {
>>>>>> 		.range_min = DA9063_REG_CHIP_ID,
>>>>>> 		.range_max = DA9063_REG_CHIP_VARIANT,
>>>>>> 	},
>>>>>> };
>>>>>>
>>>>>> static const struct regmap_range da9063l_bb_writeable_ranges[] = {
>>>>>> 	{
>>>>>> 		.range_min = DA9063_REG_PAGE_CON,
>>>>>> 		.range_max = DA9063_REG_PAGE_CON,
>>>>>> 	}, {
>>>>>> 		.range_min = DA9063_REG_FAULT_LOG,
>>>>>> 		.range_max = DA9063_REG_VSYS_MON,
>>>>>> 	}, {
>>>>>> 		.range_min = DA9063_REG_SEQ,
>>>>>> 		.range_max = DA9063_REG_ID_32_31,
>>>>>> 	}, {
>>>>>> 		.range_min = DA9063_REG_SEQ_A,
>>>>>> 		.range_max = DA9063_REG_AUTO3_LOW,
>>>>>> 	}, {
>>>>>> 		.range_min = DA9063_REG_CONFIG_I,
>>>>>> 		.range_max = DA9063_BB_REG_MON_REG_4,
>>>>>> 	}, {
>>>>>> 		.range_min = DA9063_BB_REG_GP_ID_0,
>>>>>> 		.range_max = DA9063_BB_REG_GP_ID_19,
>>>>>> 	},
>>>>>> };
>>>>>>
>>>>>> static const struct regmap_range da9063l_bb_volatile_ranges[] = {
>>>>>> 	{
>>>>>> 		.range_min = DA9063_REG_PAGE_CON,
>>>>>> 		.range_max = DA9063_REG_EVENT_D,
>>>>>> 	}, {
>>>>>> 		.range_min = DA9063_REG_CONTROL_A,
>>>>>> 		.range_max = DA9063_REG_CONTROL_B,
>>>>>> 	}, {
>>>>>> 		.range_min = DA9063_REG_CONTROL_E,
>>>>>> 		.range_max = DA9063_REG_CONTROL_F,
>>>>>> 	}, {
>>>>>> 		.range_min = DA9063_REG_BCORE2_CONT,
>>>>>> 		.range_max = DA9063_REG_LDO11_CONT,
>>>>>> 	}, {
>>>>>> 		.range_min = DA9063_REG_DVC_1,
>>>>>> 		.range_max = DA9063_REG_ADC_MAN,
>>>>>> 	}, {
>>>>>> 		.range_min = DA9063_REG_ADC_RES_L,
>>>>>> 		.range_max = DA9063_REG_MON_A10_RES,
>>>>>> 	}, {
>>>>>> 		.range_min = DA9063_REG_SEQ,
>>>>>> 		.range_max = DA9063_REG_SEQ,
>>>>>> 	}, {
>>>>>> 		.range_min = DA9063_REG_EN_32K,
>>>>>> 		.range_max = DA9063_REG_EN_32K,
>>>>>> 	}, {
>>>>>> 		.range_min = DA9063_BB_REG_MON_REG_5,
>>>>>> 		.range_max = DA9063_BB_REG_MON_REG_6,
>>>>>> 	},
>>>>>> };
>>>>>>
>>>>>> However this is a larger and more wide-ranging change compared to the
>>>>>> one proposed by Marek, and would require other alterations to fit
>>>>>> this in. Also I'm undecided to what it would really add apart from a
>>>>>> new chip model: I have been told accessing the DA9063 RTC register locations
>>>>>> has no effect in the DA9063L.
>>>>>
>>>>> Looking at this further, there is also a new IRQ regmap.
>>>>> Again this comes down to whether a full chip model is needed or not.
>>>>> If not, then the IRQ map does not need to be changed as given. Otherwise the
>>>>> removal of the following:
>>>>>
>>>>> 	[DA9063_IRQ_ALARM] = {
>>>>> 		.reg_offset = DA9063_REG_EVENT_A_OFFSET,
>>>>> 		.mask = DA9063_M_ALARM,
>>>>> 	},
>>>>> 	[DA9063_IRQ_TICK] = {
>>>>> 		.reg_offset = DA9063_REG_EVENT_A_OFFSET,
>>>>> 		.mask = DA9063_M_TICK,
>>>>> 	},
>>>>>
>>>>> prior to registering the IRQs in the chip model would be needed.
>>>>> The new regmap_irq would be:
>>>>>
>>>>> static const struct regmap_irq da9063l_irqs[] = {
>>>>> 	/* DA9063 event A register */
>>>>> 	[DA9063L_IRQ_ONKEY] = {
>>>>> 		.reg_offset = DA9063_REG_EVENT_A_OFFSET,
>>>>> 		.mask = DA9063_M_ONKEY,
>>>>> 	},
>>>>> 	[DA9063L_IRQ_ADC_RDY] = {
>>>>> 		.reg_offset = DA9063_REG_EVENT_A_OFFSET,
>>>>> 		.mask = DA9063_M_ADC_RDY,
>>>>> 	},
>>>>> 	[DA9063L_IRQ_SEQ_RDY] = {
>>>>> 		.reg_offset = DA9063_REG_EVENT_A_OFFSET,
>>>>> 		.mask = DA9063_M_SEQ_RDY,
>>>>> 	},
>>>>> 	/* DA9063 event B register */
>>>>> 	[DA9063L_IRQ_WAKE] = {
>>>>> 		.reg_offset = DA9063_REG_EVENT_B_OFFSET,
>>>>> 		.mask = DA9063_M_WAKE,
>>>>> 	},
>>>>> 	[DA9063L_IRQ_TEMP] = {
>>>>> 		.reg_offset = DA9063_REG_EVENT_B_OFFSET,
>>>>> 		.mask = DA9063_M_TEMP,
>>>>> 	},
>>>>> 	[DA9063L_IRQ_COMP_1V2] = {
>>>>> 		.reg_offset = DA9063_REG_EVENT_B_OFFSET,
>>>>> 		.mask = DA9063_M_COMP_1V2,
>>>>> 	},
>>>>> 	[DA9063L_IRQ_LDO_LIM] = {
>>>>> 		.reg_offset = DA9063_REG_EVENT_B_OFFSET,
>>>>> 		.mask = DA9063_M_LDO_LIM,
>>>>> 	},
>>>>> 	[DA9063L_IRQ_REG_UVOV] = {
>>>>> 		.reg_offset = DA9063_REG_EVENT_B_OFFSET,
>>>>> 		.mask = DA9063_M_UVOV,
>>>>> 	},
>>>>> 	[DA9063L_IRQ_DVC_RDY] = {
>>>>> 		.reg_offset = DA9063_REG_EVENT_B_OFFSET,
>>>>> 		.mask = DA9063_M_DVC_RDY,
>>>>> 	},
>>>>> 	[DA9063L_IRQ_VDD_MON] = {
>>>>> 		.reg_offset = DA9063_REG_EVENT_B_OFFSET,
>>>>> 		.mask = DA9063_M_VDD_MON,
>>>>> 	},
>>>>> 	[DA9063L_IRQ_WARN] = {
>>>>> 		.reg_offset = DA9063_REG_EVENT_B_OFFSET,
>>>>> 		.mask = DA9063_M_VDD_WARN,
>>>>> 	},
>>>>> 	/* DA9063 event C register */
>>>>> 	[DA9063L_IRQ_GPI0] = {
>>>>> 		.reg_offset = DA9063_REG_EVENT_C_OFFSET,
>>>>> 		.mask = DA9063_M_GPI0,
>>>>> 	},
>>>>> 	[DA9063L_IRQ_GPI1] = {
>>>>> 		.reg_offset = DA9063_REG_EVENT_C_OFFSET,
>>>>> 		.mask = DA9063_M_GPI1,
>>>>> 	},
>>>>> 	[DA9063L_IRQ_GPI2] = {
>>>>> 		.reg_offset = DA9063_REG_EVENT_C_OFFSET,
>>>>> 		.mask = DA9063_M_GPI2,
>>>>> 	},
>>>>> 	[DA9063L_IRQ_GPI3] = {
>>>>> 		.reg_offset = DA9063_REG_EVENT_C_OFFSET,
>>>>> 		.mask = DA9063_M_GPI3,
>>>>> 	},
>>>>> 	[DA9063L_IRQ_GPI4] = {
>>>>> 		.reg_offset = DA9063_REG_EVENT_C_OFFSET,
>>>>> 		.mask = DA9063_M_GPI4,
>>>>> 	},
>>>>> 	[DA9063L_IRQ_GPI5] = {
>>>>> 		.reg_offset = DA9063_REG_EVENT_C_OFFSET,
>>>>> 		.mask = DA9063_M_GPI5,
>>>>> 	},
>>>>> 	[DA9063L_IRQ_GPI6] = {
>>>>> 		.reg_offset = DA9063_REG_EVENT_C_OFFSET,
>>>>> 		.mask = DA9063_M_GPI6,
>>>>> 	},
>>>>> 	[DA9063L_IRQ_GPI7] = {
>>>>> 		.reg_offset = DA9063_REG_EVENT_C_OFFSET,
>>>>> 		.mask = DA9063_M_GPI7,
>>>>> 	},
>>>>> 	/* DA9063 event D register */
>>>>> 	[DA9063L_IRQ_GPI8] = {
>>>>> 		.reg_offset = DA9063_REG_EVENT_D_OFFSET,
>>>>> 		.mask = DA9063_M_GPI8,
>>>>> 	},
>>>>> 	[DA9063L_IRQ_GPI9] = {
>>>>> 		.reg_offset = DA9063_REG_EVENT_D_OFFSET,
>>>>> 		.mask = DA9063_M_GPI9,
>>>>> 	},
>>>>> 	[DA9063L_IRQ_GPI10] = {
>>>>> 		.reg_offset = DA9063_REG_EVENT_D_OFFSET,
>>>>> 		.mask = DA9063_M_GPI10,
>>>>> 	},
>>>>> 	[DA9063L_IRQ_GPI11] = {
>>>>> 		.reg_offset = DA9063_REG_EVENT_D_OFFSET,
>>>>> 		.mask = DA9063_M_GPI11,
>>>>> 	},
>>>>> 	[DA9063L_IRQ_GPI12] = {
>>>>> 		.reg_offset = DA9063_REG_EVENT_D_OFFSET,
>>>>> 		.mask = DA9063_M_GPI12,
>>>>> 	},
>>>>> 	[DA9063L_IRQ_GPI13] = {
>>>>> 		.reg_offset = DA9063_REG_EVENT_D_OFFSET,
>>>>> 		.mask = DA9063_M_GPI13,
>>>>> 	},
>>>>> 	[DA9063L_IRQ_GPI14] = {
>>>>> 		.reg_offset = DA9063_REG_EVENT_D_OFFSET,
>>>>> 		.mask = DA9063_M_GPI14,
>>>>> 	},
>>>>> 	[DA9063L_IRQ_GPI15] = {
>>>>> 		.reg_offset = DA9063_REG_EVENT_D_OFFSET,
>>>>> 		.mask = DA9063_M_GPI15,
>>>>> 	},
>>>>> };
>>>>
>>>> We can probably do the same trick with the regmaps and irqmaps as with the
>>>> rest, that is, reorder them and register only a smaller portion ?
>>>
>>> I like the "reorder and only register a smaller portion" trick. But it wouldn't work
>>> with what I gave earlier today, without some modification.
>>> For instance, the first register readable entry range in the  DA9063 BB is:
>>>
>>> static const struct regmap_range da9063_bb_readable_ranges[] = {
>>> 	{
>>> 		.range_min = DA9063_REG_PAGE_CON,
>>> 		.range_max = DA9063_BB_REG_SECOND_D,
>>> 	}, {
>>>
>>> But for the DA9063L, this first range entry would be changed, not removed:
>>>
>>> static const struct regmap_range da9063l_bb_readable_ranges[] = {
>>> 	{
>>> 		.range_min = DA9063_REG_PAGE_CON,
>>> 		.range_max = DA9063_REG_MON_A10_RES,
>>> 	}, {
>>>
>>> So it's not all-or-nothing. But possibly it could be made to work if those ranges were split
>>> into two pieces.
>>>
>>> However, it might get messy to maintain in future -- sometimes register ranges need to be
>>> updated with new components or if a new feature is added -- usually I need to work it
>>> all out on paper with the full register map. Splitting up ranges might make it a little
>>> messier. But, it's not impossible.
>>>
>>> For the DA9062 and DA9061 this was done using separate ranges and using the macro
>>> regmap_reg_range(). It's not that messy to read, e.g.
>>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/mfd/da9062-core.c?h=next-20180517#n367
>>
>> Hum, can you point me to the datasheet sections so I can check this
>> difference please ? I think I have the rest of the feedback addressed,
>> so I want to check this one before submitting the next version.
> 
> Hi Marek,

Hi,

> My apologies for the time taken to respond. I have been travelling.

No worries

> Datasheets are found on the Dialog company website.
> End of the page, look for Resources > Datasheets.
> 
> https://www.dialog-semiconductor.com/products/da9061
> https://www.dialog-semiconductor.com/products/da9062
> https://www.dialog-semiconductor.com/products/da9063
> https://www.dialog-semiconductor.com/products/da9063L

I found those, but they even list the RTC block in the register list .

> The chip model {readable, writable, volatile} register definitions are given clearly in the device
> drivers. At least they will match what is expected by the Linux device driver. There is no easy
> chip model list found in the datasheets.

Well, let me resend what I have and let's see where this gets us.

-- 
Best regards,
Marek Vasut