[PATCH v5 0/3] Dollar Cove TI PMIC support for Intel Cherry Trail

[PATCH v5 0/3] Dollar Cove TI PMIC support for Intel Cherry Trail

[Takashi Iwai]

Hi,

this is the revised v5 patch set to add the support for Dollar Cove TI
PMIC found on some Intel Cherry Trail laptops / tablets.  All drivers
are based on the original code from Intel downstream patches, with
lots of rewrites and cleanups.  MFD driver is implemented as a
stand-alone driver like a few other variants, and the input driver got
a diet in a minimalistic form.

The patch set has been tested on ASUS E100H and E200H, as well as on
HP x210.


thanks,

Takashi

===

v4->5:
* Minor coding-style fixes in MFD driver suggested by Lee
* Put GPL text to MFD driver

v3->v4:
- Correct Kconfig / Makefile for ACPI opregion driver
- Minor fixes of powerbutton driver suggested by Dmitry
- Rephrase Kconfig help text for powerbutton driver

v2->v3:
- Rename dc_ti with chtdc_ti in all places
- Driver/kconfig renames accordingly
- A few constifications
- Added acks by Andy and Mika

v1->v2:
- Minor cleanups in mfd driver code as suggested by Andy
- Move power-button driver to platform/x86, driver renames accordingly
- Add missing wake-irq cleanup to power-button driver
- get_raw_temp cleanup in opregion driver, mention about register
  endianess


Takashi Iwai (3):
  mfd: Add support for Cherry Trail Dollar Cove TI PMIC
  platform/x86: Add support for Dollar Cove TI power button
  ACPI / PMIC: Add opregion driver for Intel Dollar Cove TI PMIC

 drivers/acpi/Kconfig                         |   6 +
 drivers/acpi/Makefile                        |   1 +
 drivers/acpi/pmic/intel_pmic_chtdc_ti.c      | 137 ++++++++++++++++++++
 drivers/mfd/Kconfig                          |  13 ++
 drivers/mfd/Makefile                         |   1 +
 drivers/mfd/intel_soc_pmic_chtdc_ti.c        | 184 +++++++++++++++++++++++++++
 drivers/platform/x86/Kconfig                 |  11 ++
 drivers/platform/x86/Makefile                |   1 +
 drivers/platform/x86/intel_chtdc_ti_pwrbtn.c |  94 ++++++++++++++
 9 files changed, 448 insertions(+)
 create mode 100644 drivers/acpi/pmic/intel_pmic_chtdc_ti.c
 create mode 100644 drivers/mfd/intel_soc_pmic_chtdc_ti.c
 create mode 100644 drivers/platform/x86/intel_chtdc_ti_pwrbtn.c

-- 
2.14.1

[PATCH v5 1/3] mfd: Add support for Cherry Trail Dollar Cove TI PMIC

[Takashi Iwai]

This patch adds the MFD driver for Dollar Cove (TI version) PMIC with
ACPI INT33F5 that is found on some Intel Cherry Trail devices.
The driver is based on the original work by Intel, found at:
  https://github.com/01org/ProductionKernelQuilts

This is a minimal version for adding the basic resources.  Currently,
only ACPI PMIC opregion and the external power-button are used.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
v4->v5:
* Minor coding-style fixes suggested by Lee
* Put GPL text
v3->v4:
* no change for this patch
v2->v3:
* Rename dc_ti with chtdc_ti in all places
* Driver/kconfig renames accordingly
* Added acks by Andy and Mika
v1->v2:
* Minor cleanups as suggested by Andy

 drivers/mfd/Kconfig                   |  13 +++
 drivers/mfd/Makefile                  |   1 +
 drivers/mfd/intel_soc_pmic_chtdc_ti.c | 184 ++++++++++++++++++++++++++++++++++
 3 files changed, 198 insertions(+)
 create mode 100644 drivers/mfd/intel_soc_pmic_chtdc_ti.c

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 94ad2c1c3d90..36e7d60f1314 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -496,6 +496,19 @@ config INTEL_SOC_PMIC_CHTWC
 	  available before any devices using it are probed. This option also
 	  causes the designware-i2c driver to be builtin for the same reason.
 
+config INTEL_SOC_PMIC_CHTDC_TI
+	tristate "Support for Intel Cherry Trail Dollar Cove TI PMIC"
+	depends on GPIOLIB
+	depends on I2C
+	depends on ACPI
+	depends on X86
+	select MFD_CORE
+	select REGMAP_I2C
+	select REGMAP_IRQ
+	help
+	  Select this option for supporting Dollar Cove (TI version) PMIC
+	  device that is found on some Intel Cherry Trail systems.
+
 config MFD_INTEL_LPSS
 	tristate
 	select COMMON_CLK
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 080793b3fd0e..50ae64d2b22a 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -216,6 +216,7 @@ intel-soc-pmic-objs		:= intel_soc_pmic_core.o intel_soc_pmic_crc.o
 obj-$(CONFIG_INTEL_SOC_PMIC)	+= intel-soc-pmic.o
 obj-$(CONFIG_INTEL_SOC_PMIC_BXTWC)	+= intel_soc_pmic_bxtwc.o
 obj-$(CONFIG_INTEL_SOC_PMIC_CHTWC)	+= intel_soc_pmic_chtwc.o
+obj-$(CONFIG_INTEL_SOC_PMIC_CHTDC_TI)	+= intel_soc_pmic_chtdc_ti.o
 obj-$(CONFIG_MFD_MT6397)	+= mt6397-core.o
 
 obj-$(CONFIG_MFD_ALTERA_A10SR)	+= altera-a10sr.o
diff --git a/drivers/mfd/intel_soc_pmic_chtdc_ti.c b/drivers/mfd/intel_soc_pmic_chtdc_ti.c
new file mode 100644
index 000000000000..861277c6580a
--- /dev/null
+++ b/drivers/mfd/intel_soc_pmic_chtdc_ti.c
@@ -0,0 +1,184 @@
+/*
+ * Device access for Dollar Cove TI PMIC
+ *
+ * Copyright (c) 2014, Intel Corporation.
+ *   Author: Ramakrishna Pallala <ramakrishna.pallala@intel.com>
+ *
+ * Cleanup and forward-ported
+ *   Copyright (c) 2017 Takashi Iwai <tiwai@suse.de>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/acpi.h>
+#include <linux/interrupt.h>
+#include <linux/i2c.h>
+#include <linux/mfd/core.h>
+#include <linux/mfd/intel_soc_pmic.h>
+#include <linux/module.h>
+#include <linux/regmap.h>
+
+#define CHTDC_TI_IRQLVL1	0x01
+#define CHTDC_TI_MASK_IRQLVL1	0x02
+
+/* Level 1 IRQs */
+enum {
+	CHTDC_TI_PWRBTN = 0,	/* power button */
+	CHTDC_TI_DIETMPWARN,	/* thermal */
+	CHTDC_TI_ADCCMPL,	/* ADC */
+	/* No IRQ 3 */
+	CHTDC_TI_VBATLOW = 4,	/* battery */
+	CHTDC_TI_VBUSDET,	/* power source */
+	/* No IRQ 6 */
+	CHTDC_TI_CCEOCAL = 7,	/* battery */
+};
+
+static struct resource power_button_resources[] = {
+	DEFINE_RES_IRQ(CHTDC_TI_PWRBTN),
+};
+
+static struct resource thermal_resources[] = {
+	DEFINE_RES_IRQ(CHTDC_TI_DIETMPWARN),
+};
+
+static struct resource adc_resources[] = {
+	DEFINE_RES_IRQ(CHTDC_TI_ADCCMPL),
+};
+
+static struct resource pwrsrc_resources[] = {
+	DEFINE_RES_IRQ(CHTDC_TI_VBUSDET),
+};
+
+static struct resource battery_resources[] = {
+	DEFINE_RES_IRQ(CHTDC_TI_VBATLOW),
+	DEFINE_RES_IRQ(CHTDC_TI_CCEOCAL),
+};
+
+static struct mfd_cell chtdc_ti_dev[] = {
+	{
+		.name = "chtdc_ti_pwrbtn",
+		.num_resources = ARRAY_SIZE(power_button_resources),
+		.resources = power_button_resources,
+	}, {
+		.name = "chtdc_ti_adc",
+		.num_resources = ARRAY_SIZE(adc_resources),
+		.resources = adc_resources,
+	}, {
+		.name = "chtdc_ti_thermal",
+		.num_resources = ARRAY_SIZE(thermal_resources),
+		.resources = thermal_resources,
+	}, {
+		.name = "chtdc_ti_pwrsrc",
+		.num_resources = ARRAY_SIZE(pwrsrc_resources),
+		.resources = pwrsrc_resources,
+	}, {
+		.name = "chtdc_ti_battery",
+		.num_resources = ARRAY_SIZE(battery_resources),
+		.resources = battery_resources,
+	},
+	{	.name = "chtdc_ti_region", },
+};
+
+static const struct regmap_config chtdc_ti_regmap_config = {
+	.reg_bits = 8,
+	.val_bits = 8,
+	.max_register = 128,
+	.cache_type = REGCACHE_NONE,
+};
+
+static const struct regmap_irq chtdc_ti_irqs[] = {
+	REGMAP_IRQ_REG(CHTDC_TI_PWRBTN, 0, BIT(CHTDC_TI_PWRBTN)),
+	REGMAP_IRQ_REG(CHTDC_TI_DIETMPWARN, 0, BIT(CHTDC_TI_DIETMPWARN)),
+	REGMAP_IRQ_REG(CHTDC_TI_ADCCMPL, 0, BIT(CHTDC_TI_ADCCMPL)),
+	REGMAP_IRQ_REG(CHTDC_TI_VBATLOW, 0, BIT(CHTDC_TI_VBATLOW)),
+	REGMAP_IRQ_REG(CHTDC_TI_VBUSDET, 0, BIT(CHTDC_TI_VBUSDET)),
+	REGMAP_IRQ_REG(CHTDC_TI_CCEOCAL, 0, BIT(CHTDC_TI_CCEOCAL)),
+};
+
+static const struct regmap_irq_chip chtdc_ti_irq_chip = {
+	.name = KBUILD_MODNAME,
+	.irqs = chtdc_ti_irqs,
+	.num_irqs = ARRAY_SIZE(chtdc_ti_irqs),
+	.num_regs = 1,
+	.status_base = CHTDC_TI_IRQLVL1,
+	.mask_base = CHTDC_TI_MASK_IRQLVL1,
+	.ack_base = CHTDC_TI_IRQLVL1,
+};
+
+static int chtdc_ti_probe(struct i2c_client *i2c)
+{
+	struct device *dev = &i2c->dev;
+	struct intel_soc_pmic *pmic;
+	int ret;
+
+	pmic = devm_kzalloc(dev, sizeof(*pmic), GFP_KERNEL);
+	if (!pmic)
+		return -ENOMEM;
+
+	i2c_set_clientdata(i2c, pmic);
+
+	pmic->regmap = devm_regmap_init_i2c(i2c, &chtdc_ti_regmap_config);
+	if (IS_ERR(pmic->regmap))
+		return PTR_ERR(pmic->regmap);
+	pmic->irq = i2c->irq;
+
+	ret = devm_regmap_add_irq_chip(dev, pmic->regmap, pmic->irq,
+				       IRQF_ONESHOT, 0,
+				       &chtdc_ti_irq_chip,
+				       &pmic->irq_chip_data);
+	if (ret)
+		return ret;
+
+	return devm_mfd_add_devices(dev, PLATFORM_DEVID_NONE, chtdc_ti_dev,
+				    ARRAY_SIZE(chtdc_ti_dev), NULL, 0,
+				    regmap_irq_get_domain(pmic->irq_chip_data));
+}
+
+static void chtdc_ti_shutdown(struct i2c_client *i2c)
+{
+	struct intel_soc_pmic *pmic = i2c_get_clientdata(i2c);
+
+	disable_irq(pmic->irq);
+}
+
+static int __maybe_unused chtdc_ti_suspend(struct device *dev)
+{
+	struct intel_soc_pmic *pmic = dev_get_drvdata(dev);
+
+	disable_irq(pmic->irq);
+
+	return 0;
+}
+
+static int __maybe_unused chtdc_ti_resume(struct device *dev)
+{
+	struct intel_soc_pmic *pmic = dev_get_drvdata(dev);
+
+	enable_irq(pmic->irq);
+
+	return 0;
+}
+
+static SIMPLE_DEV_PM_OPS(chtdc_ti_pm_ops, chtdc_ti_suspend, chtdc_ti_resume);
+
+static const struct acpi_device_id chtdc_ti_acpi_ids[] = {
+	{ "INT33F5" },
+	{ },
+};
+MODULE_DEVICE_TABLE(acpi, chtdc_ti_acpi_ids);
+
+static struct i2c_driver chtdc_ti_i2c_driver = {
+	.driver = {
+		.name = "intel_soc_pmic_chtdc_ti",
+		.pm = &chtdc_ti_pm_ops,
+		.acpi_match_table = chtdc_ti_acpi_ids,
+	},
+	.probe_new = chtdc_ti_probe,
+	.shutdown = chtdc_ti_shutdown,
+};
+module_i2c_driver(chtdc_ti_i2c_driver);
+
+MODULE_DESCRIPTION("I2C driver for Intel SoC Dollar Cove TI PMIC");
+MODULE_LICENSE("GPL v2");
-- 
2.14.1

Re: [PATCH v5 1/3] mfd: Add support for Cherry Trail Dollar Cove TI PMIC

[Lee Jones]

On Mon, 04 Sep 2017, Takashi Iwai wrote:

> This patch adds the MFD driver for Dollar Cove (TI version) PMIC with
> ACPI INT33F5 that is found on some Intel Cherry Trail devices.
> The driver is based on the original work by Intel, found at:
>   https://github.com/01org/ProductionKernelQuilts
> 
> This is a minimal version for adding the basic resources.  Currently,
> only ACPI PMIC opregion and the external power-button are used.
> 
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891
> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> Signed-off-by: Takashi Iwai <tiwai@suse.de>
> ---
> v4->v5:
> * Minor coding-style fixes suggested by Lee
> * Put GPL text
> v3->v4:
> * no change for this patch
> v2->v3:
> * Rename dc_ti with chtdc_ti in all places
> * Driver/kconfig renames accordingly
> * Added acks by Andy and Mika
> v1->v2:
> * Minor cleanups as suggested by Andy
> 
>  drivers/mfd/Kconfig                   |  13 +++
>  drivers/mfd/Makefile                  |   1 +
>  drivers/mfd/intel_soc_pmic_chtdc_ti.c | 184 ++++++++++++++++++++++++++++++++++
>  3 files changed, 198 insertions(+)
>  create mode 100644 drivers/mfd/intel_soc_pmic_chtdc_ti.c

For my own reference:
  Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v5 1/3] mfd: Add support for Cherry Trail Dollar Cove TI PMIC

[Takashi Iwai]

On Tue, 05 Sep 2017 09:24:51 +0200,
Lee Jones wrote:
> 
> On Mon, 04 Sep 2017, Takashi Iwai wrote:
> 
> > This patch adds the MFD driver for Dollar Cove (TI version) PMIC with
> > ACPI INT33F5 that is found on some Intel Cherry Trail devices.
> > The driver is based on the original work by Intel, found at:
> >   https://github.com/01org/ProductionKernelQuilts
> > 
> > This is a minimal version for adding the basic resources.  Currently,
> > only ACPI PMIC opregion and the external power-button are used.
> > 
> > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891
> > Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> > Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> > Signed-off-by: Takashi Iwai <tiwai@suse.de>
> > ---
> > v4->v5:
> > * Minor coding-style fixes suggested by Lee
> > * Put GPL text
> > v3->v4:
> > * no change for this patch
> > v2->v3:
> > * Rename dc_ti with chtdc_ti in all places
> > * Driver/kconfig renames accordingly
> > * Added acks by Andy and Mika
> > v1->v2:
> > * Minor cleanups as suggested by Andy
> > 
> >  drivers/mfd/Kconfig                   |  13 +++
> >  drivers/mfd/Makefile                  |   1 +
> >  drivers/mfd/intel_soc_pmic_chtdc_ti.c | 184 ++++++++++++++++++++++++++++++++++
> >  3 files changed, 198 insertions(+)
> >  create mode 100644 drivers/mfd/intel_soc_pmic_chtdc_ti.c
> 
> For my own reference:
>   Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>

Thanks!

Now the question is how to deal with these.  It's no critical things,
so I'm OK to postpone for 4.15.  OTOH, it's really a new
device-specific stuff, thus it can't break anything else, and it'd be
fairly safe to add it for 4.14 although it's at a bit late stage.

IMO, it'd be great if you can carry all stuff through MFD tree; or
create an immutable branch (again).  But how to handle it, when to do
it, It's all up to you guys.


thanks,

Takashi

Re: [PATCH v5 1/3] mfd: Add support for Cherry Trail Dollar Cove TI PMIC

[Hans de Goede]

Hi,

On 05-09-17 09:46, Takashi Iwai wrote:
> On Tue, 05 Sep 2017 09:24:51 +0200,
> Lee Jones wrote:
>>
>> On Mon, 04 Sep 2017, Takashi Iwai wrote:
>>
>>> This patch adds the MFD driver for Dollar Cove (TI version) PMIC with
>>> ACPI INT33F5 that is found on some Intel Cherry Trail devices.
>>> The driver is based on the original work by Intel, found at:
>>>    https://github.com/01org/ProductionKernelQuilts
>>>
>>> This is a minimal version for adding the basic resources.  Currently,
>>> only ACPI PMIC opregion and the external power-button are used.
>>>
>>> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891
>>> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
>>> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
>>> Signed-off-by: Takashi Iwai <tiwai@suse.de>
>>> ---
>>> v4->v5:
>>> * Minor coding-style fixes suggested by Lee
>>> * Put GPL text
>>> v3->v4:
>>> * no change for this patch
>>> v2->v3:
>>> * Rename dc_ti with chtdc_ti in all places
>>> * Driver/kconfig renames accordingly
>>> * Added acks by Andy and Mika
>>> v1->v2:
>>> * Minor cleanups as suggested by Andy
>>>
>>>   drivers/mfd/Kconfig                   |  13 +++
>>>   drivers/mfd/Makefile                  |   1 +
>>>   drivers/mfd/intel_soc_pmic_chtdc_ti.c | 184 ++++++++++++++++++++++++++++++++++
>>>   3 files changed, 198 insertions(+)
>>>   create mode 100644 drivers/mfd/intel_soc_pmic_chtdc_ti.c
>>
>> For my own reference:
>>    Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> 
> Thanks!
> 
> Now the question is how to deal with these.  It's no critical things,
> so I'm OK to postpone for 4.15.  OTOH, it's really a new
> device-specific stuff, thus it can't break anything else, and it'd be
> fairly safe to add it for 4.14 although it's at a bit late stage.
> 
> IMO, it'd be great if you can carry all stuff through MFD tree; or
> create an immutable branch (again).  But how to handle it, when to do
> it, It's all up to you guys.

Since the mfd driver only instantiates platform devices there
is only a runtime dependency between the drivers AFAICT so each
driver can be merged through it own subsystem without problem /
without the need for an immutable branch, or am I missing something ?

Regards,

Hans

Re: [PATCH v5 1/3] mfd: Add support for Cherry Trail Dollar Cove TI PMIC

[Lee Jones]

On Tue, 05 Sep 2017, Hans de Goede wrote:

> Hi,
> 
> On 05-09-17 09:46, Takashi Iwai wrote:
> > On Tue, 05 Sep 2017 09:24:51 +0200,
> > Lee Jones wrote:
> > > 
> > > On Mon, 04 Sep 2017, Takashi Iwai wrote:
> > > 
> > > > This patch adds the MFD driver for Dollar Cove (TI version) PMIC with
> > > > ACPI INT33F5 that is found on some Intel Cherry Trail devices.
> > > > The driver is based on the original work by Intel, found at:
> > > >    https://github.com/01org/ProductionKernelQuilts
> > > > 
> > > > This is a minimal version for adding the basic resources.  Currently,
> > > > only ACPI PMIC opregion and the external power-button are used.
> > > > 
> > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891
> > > > Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> > > > Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> > > > Signed-off-by: Takashi Iwai <tiwai@suse.de>
> > > > ---
> > > > v4->v5:
> > > > * Minor coding-style fixes suggested by Lee
> > > > * Put GPL text
> > > > v3->v4:
> > > > * no change for this patch
> > > > v2->v3:
> > > > * Rename dc_ti with chtdc_ti in all places
> > > > * Driver/kconfig renames accordingly
> > > > * Added acks by Andy and Mika
> > > > v1->v2:
> > > > * Minor cleanups as suggested by Andy
> > > > 
> > > >   drivers/mfd/Kconfig                   |  13 +++
> > > >   drivers/mfd/Makefile                  |   1 +
> > > >   drivers/mfd/intel_soc_pmic_chtdc_ti.c | 184 ++++++++++++++++++++++++++++++++++
> > > >   3 files changed, 198 insertions(+)
> > > >   create mode 100644 drivers/mfd/intel_soc_pmic_chtdc_ti.c
> > > 
> > > For my own reference:
> > >    Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> > 
> > Thanks!
> > 
> > Now the question is how to deal with these.  It's no critical things,
> > so I'm OK to postpone for 4.15.  OTOH, it's really a new
> > device-specific stuff, thus it can't break anything else, and it'd be
> > fairly safe to add it for 4.14 although it's at a bit late stage.
> > 
> > IMO, it'd be great if you can carry all stuff through MFD tree; or
> > create an immutable branch (again).  But how to handle it, when to do
> > it, It's all up to you guys.
> 
> Since the mfd driver only instantiates platform devices there
> is only a runtime dependency between the drivers AFAICT so each
> driver can be merged through it own subsystem without problem /
> without the need for an immutable branch, or am I missing something ?

Seconded.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v5 1/3] mfd: Add support for Cherry Trail Dollar Cove TI PMIC

[Takashi Iwai]

On Tue, 05 Sep 2017 10:00:23 +0200,
Hans de Goede wrote:
> 
> Hi,
> 
> On 05-09-17 09:46, Takashi Iwai wrote:
> > On Tue, 05 Sep 2017 09:24:51 +0200,
> > Lee Jones wrote:
> >>
> >> On Mon, 04 Sep 2017, Takashi Iwai wrote:
> >>
> >>> This patch adds the MFD driver for Dollar Cove (TI version) PMIC with
> >>> ACPI INT33F5 that is found on some Intel Cherry Trail devices.
> >>> The driver is based on the original work by Intel, found at:
> >>>    https://github.com/01org/ProductionKernelQuilts
> >>>
> >>> This is a minimal version for adding the basic resources.  Currently,
> >>> only ACPI PMIC opregion and the external power-button are used.
> >>>
> >>> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891
> >>> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> >>> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> >>> Signed-off-by: Takashi Iwai <tiwai@suse.de>
> >>> ---
> >>> v4->v5:
> >>> * Minor coding-style fixes suggested by Lee
> >>> * Put GPL text
> >>> v3->v4:
> >>> * no change for this patch
> >>> v2->v3:
> >>> * Rename dc_ti with chtdc_ti in all places
> >>> * Driver/kconfig renames accordingly
> >>> * Added acks by Andy and Mika
> >>> v1->v2:
> >>> * Minor cleanups as suggested by Andy
> >>>
> >>>   drivers/mfd/Kconfig                   |  13 +++
> >>>   drivers/mfd/Makefile                  |   1 +
> >>>   drivers/mfd/intel_soc_pmic_chtdc_ti.c | 184 ++++++++++++++++++++++++++++++++++
> >>>   3 files changed, 198 insertions(+)
> >>>   create mode 100644 drivers/mfd/intel_soc_pmic_chtdc_ti.c
> >>
> >> For my own reference:
> >>    Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> >
> > Thanks!
> >
> > Now the question is how to deal with these.  It's no critical things,
> > so I'm OK to postpone for 4.15.  OTOH, it's really a new
> > device-specific stuff, thus it can't break anything else, and it'd be
> > fairly safe to add it for 4.14 although it's at a bit late stage.
> >
> > IMO, it'd be great if you can carry all stuff through MFD tree; or
> > create an immutable branch (again).  But how to handle it, when to do
> > it, It's all up to you guys.
> 
> Since the mfd driver only instantiates platform devices there
> is only a runtime dependency between the drivers AFAICT so each
> driver can be merged through it own subsystem without problem /
> without the need for an immutable branch, or am I missing something ?

Yeah, it wouldn't do much harm other than containing the dead code.

I'm afraid of missing kconfig or such error splat spotted by build
bot, if we merge each commit individually.  But maybe I have just too
strong trauma of the build bot complaints :)


thanks,

Takashi

Re: [PATCH v5 1/3] mfd: Add support for Cherry Trail Dollar Cove TI PMIC

[Lee Jones]

On Tue, 05 Sep 2017, Takashi Iwai wrote:

> On Tue, 05 Sep 2017 09:24:51 +0200,
> Lee Jones wrote:
> > 
> > On Mon, 04 Sep 2017, Takashi Iwai wrote:
> > 
> > > This patch adds the MFD driver for Dollar Cove (TI version) PMIC with
> > > ACPI INT33F5 that is found on some Intel Cherry Trail devices.
> > > The driver is based on the original work by Intel, found at:
> > >   https://github.com/01org/ProductionKernelQuilts
> > > 
> > > This is a minimal version for adding the basic resources.  Currently,
> > > only ACPI PMIC opregion and the external power-button are used.
> > > 
> > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891
> > > Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> > > Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> > > Signed-off-by: Takashi Iwai <tiwai@suse.de>
> > > ---
> > > v4->v5:
> > > * Minor coding-style fixes suggested by Lee
> > > * Put GPL text
> > > v3->v4:
> > > * no change for this patch
> > > v2->v3:
> > > * Rename dc_ti with chtdc_ti in all places
> > > * Driver/kconfig renames accordingly
> > > * Added acks by Andy and Mika
> > > v1->v2:
> > > * Minor cleanups as suggested by Andy
> > > 
> > >  drivers/mfd/Kconfig                   |  13 +++
> > >  drivers/mfd/Makefile                  |   1 +
> > >  drivers/mfd/intel_soc_pmic_chtdc_ti.c | 184 ++++++++++++++++++++++++++++++++++
> > >  3 files changed, 198 insertions(+)
> > >  create mode 100644 drivers/mfd/intel_soc_pmic_chtdc_ti.c
> > 
> > For my own reference:
> >   Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> 
> Thanks!
> 
> Now the question is how to deal with these.  It's no critical things,
> so I'm OK to postpone for 4.15.  OTOH, it's really a new
> device-specific stuff, thus it can't break anything else, and it'd be
> fairly safe to add it for 4.14 although it's at a bit late stage.

Yes, you are over 2 weeks late for v4.14.  It will have to be v4.15.

> IMO, it'd be great if you can carry all stuff through MFD tree; or
> create an immutable branch (again).  But how to handle it, when to do
> it, It's all up to you guys.

If there aren't any build dependencies between the patches, each of
the patches should be applied through their own trees.  What are the
build-time dependencies?  Are there any?

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v5 1/3] mfd: Add support for Cherry Trail Dollar Cove TI PMIC

[Takashi Iwai]

On Tue, 05 Sep 2017 10:10:49 +0200,
Lee Jones wrote:
> 
> On Tue, 05 Sep 2017, Takashi Iwai wrote:
> 
> > On Tue, 05 Sep 2017 09:24:51 +0200,
> > Lee Jones wrote:
> > > 
> > > On Mon, 04 Sep 2017, Takashi Iwai wrote:
> > > 
> > > > This patch adds the MFD driver for Dollar Cove (TI version) PMIC with
> > > > ACPI INT33F5 that is found on some Intel Cherry Trail devices.
> > > > The driver is based on the original work by Intel, found at:
> > > >   https://github.com/01org/ProductionKernelQuilts
> > > > 
> > > > This is a minimal version for adding the basic resources.  Currently,
> > > > only ACPI PMIC opregion and the external power-button are used.
> > > > 
> > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891
> > > > Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> > > > Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> > > > Signed-off-by: Takashi Iwai <tiwai@suse.de>
> > > > ---
> > > > v4->v5:
> > > > * Minor coding-style fixes suggested by Lee
> > > > * Put GPL text
> > > > v3->v4:
> > > > * no change for this patch
> > > > v2->v3:
> > > > * Rename dc_ti with chtdc_ti in all places
> > > > * Driver/kconfig renames accordingly
> > > > * Added acks by Andy and Mika
> > > > v1->v2:
> > > > * Minor cleanups as suggested by Andy
> > > > 
> > > >  drivers/mfd/Kconfig                   |  13 +++
> > > >  drivers/mfd/Makefile                  |   1 +
> > > >  drivers/mfd/intel_soc_pmic_chtdc_ti.c | 184 ++++++++++++++++++++++++++++++++++
> > > >  3 files changed, 198 insertions(+)
> > > >  create mode 100644 drivers/mfd/intel_soc_pmic_chtdc_ti.c
> > > 
> > > For my own reference:
> > >   Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> > 
> > Thanks!
> > 
> > Now the question is how to deal with these.  It's no critical things,
> > so I'm OK to postpone for 4.15.  OTOH, it's really a new
> > device-specific stuff, thus it can't break anything else, and it'd be
> > fairly safe to add it for 4.14 although it's at a bit late stage.
> 
> Yes, you are over 2 weeks late for v4.14.  It will have to be v4.15.

OK, I'll ring your bells again once when 4.15 development is opened.


> > IMO, it'd be great if you can carry all stuff through MFD tree; or
> > create an immutable branch (again).  But how to handle it, when to do
> > it, It's all up to you guys.
> 
> If there aren't any build dependencies between the patches, each of
> the patches should be applied through their own trees.  What are the
> build-time dependencies?  Are there any?

No, there is no strict build-time dependency.  It's just that I don't
see it nice to have a commit for a dead code, partly for testing
purpose and partly for code consistency.  But if this makes
maintenance easier, I'm happy with that, too, of course.


thanks,

Takashi

Re: [PATCH v5 1/3] mfd: Add support for Cherry Trail Dollar Cove TI PMIC

[Lee Jones]

On Tue, 05 Sep 2017, Takashi Iwai wrote:

> On Tue, 05 Sep 2017 10:10:49 +0200,
> Lee Jones wrote:
> > 
> > On Tue, 05 Sep 2017, Takashi Iwai wrote:
> > 
> > > On Tue, 05 Sep 2017 09:24:51 +0200,
> > > Lee Jones wrote:
> > > > 
> > > > On Mon, 04 Sep 2017, Takashi Iwai wrote:
> > > > 
> > > > > This patch adds the MFD driver for Dollar Cove (TI version) PMIC with
> > > > > ACPI INT33F5 that is found on some Intel Cherry Trail devices.
> > > > > The driver is based on the original work by Intel, found at:
> > > > >   https://github.com/01org/ProductionKernelQuilts
> > > > > 
> > > > > This is a minimal version for adding the basic resources.  Currently,
> > > > > only ACPI PMIC opregion and the external power-button are used.
> > > > > 
> > > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891
> > > > > Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> > > > > Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> > > > > Signed-off-by: Takashi Iwai <tiwai@suse.de>
> > > > > ---
> > > > > v4->v5:
> > > > > * Minor coding-style fixes suggested by Lee
> > > > > * Put GPL text
> > > > > v3->v4:
> > > > > * no change for this patch
> > > > > v2->v3:
> > > > > * Rename dc_ti with chtdc_ti in all places
> > > > > * Driver/kconfig renames accordingly
> > > > > * Added acks by Andy and Mika
> > > > > v1->v2:
> > > > > * Minor cleanups as suggested by Andy
> > > > > 
> > > > >  drivers/mfd/Kconfig                   |  13 +++
> > > > >  drivers/mfd/Makefile                  |   1 +
> > > > >  drivers/mfd/intel_soc_pmic_chtdc_ti.c | 184 ++++++++++++++++++++++++++++++++++
> > > > >  3 files changed, 198 insertions(+)
> > > > >  create mode 100644 drivers/mfd/intel_soc_pmic_chtdc_ti.c
> > > > 
> > > > For my own reference:
> > > >   Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> > > 
> > > Thanks!
> > > 
> > > Now the question is how to deal with these.  It's no critical things,
> > > so I'm OK to postpone for 4.15.  OTOH, it's really a new
> > > device-specific stuff, thus it can't break anything else, and it'd be
> > > fairly safe to add it for 4.14 although it's at a bit late stage.
> > 
> > Yes, you are over 2 weeks late for v4.14.  It will have to be v4.15.
> 
> OK, I'll ring your bells again once when 4.15 development is opened.
> 
> 
> > > IMO, it'd be great if you can carry all stuff through MFD tree; or
> > > create an immutable branch (again).  But how to handle it, when to do
> > > it, It's all up to you guys.
> > 
> > If there aren't any build dependencies between the patches, each of
> > the patches should be applied through their own trees.  What are the
> > build-time dependencies?  Are there any?
> 
> No, there is no strict build-time dependency.  It's just that I don't
> see it nice to have a commit for a dead code, partly for testing
> purpose and partly for code consistency.  But if this makes
> maintenance easier, I'm happy with that, too, of course.

There won't be any dead code.  All of the subsystem trees are pulled
into -next [0] where the build bots can operate on the patches as a
whole.

[0] git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v5 1/3] mfd: Add support for Cherry Trail Dollar Cove TI PMIC

[Takashi Iwai]

On Tue, 05 Sep 2017 10:53:41 +0200,
Lee Jones wrote:
> 
> On Tue, 05 Sep 2017, Takashi Iwai wrote:
> 
> > On Tue, 05 Sep 2017 10:10:49 +0200,
> > Lee Jones wrote:
> > > 
> > > On Tue, 05 Sep 2017, Takashi Iwai wrote:
> > > 
> > > > On Tue, 05 Sep 2017 09:24:51 +0200,
> > > > Lee Jones wrote:
> > > > > 
> > > > > On Mon, 04 Sep 2017, Takashi Iwai wrote:
> > > > > 
> > > > > > This patch adds the MFD driver for Dollar Cove (TI version) PMIC with
> > > > > > ACPI INT33F5 that is found on some Intel Cherry Trail devices.
> > > > > > The driver is based on the original work by Intel, found at:
> > > > > >   https://github.com/01org/ProductionKernelQuilts
> > > > > > 
> > > > > > This is a minimal version for adding the basic resources.  Currently,
> > > > > > only ACPI PMIC opregion and the external power-button are used.
> > > > > > 
> > > > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891
> > > > > > Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> > > > > > Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> > > > > > Signed-off-by: Takashi Iwai <tiwai@suse.de>
> > > > > > ---
> > > > > > v4->v5:
> > > > > > * Minor coding-style fixes suggested by Lee
> > > > > > * Put GPL text
> > > > > > v3->v4:
> > > > > > * no change for this patch
> > > > > > v2->v3:
> > > > > > * Rename dc_ti with chtdc_ti in all places
> > > > > > * Driver/kconfig renames accordingly
> > > > > > * Added acks by Andy and Mika
> > > > > > v1->v2:
> > > > > > * Minor cleanups as suggested by Andy
> > > > > > 
> > > > > >  drivers/mfd/Kconfig                   |  13 +++
> > > > > >  drivers/mfd/Makefile                  |   1 +
> > > > > >  drivers/mfd/intel_soc_pmic_chtdc_ti.c | 184 ++++++++++++++++++++++++++++++++++
> > > > > >  3 files changed, 198 insertions(+)
> > > > > >  create mode 100644 drivers/mfd/intel_soc_pmic_chtdc_ti.c
> > > > > 
> > > > > For my own reference:
> > > > >   Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> > > > 
> > > > Thanks!
> > > > 
> > > > Now the question is how to deal with these.  It's no critical things,
> > > > so I'm OK to postpone for 4.15.  OTOH, it's really a new
> > > > device-specific stuff, thus it can't break anything else, and it'd be
> > > > fairly safe to add it for 4.14 although it's at a bit late stage.
> > > 
> > > Yes, you are over 2 weeks late for v4.14.  It will have to be v4.15.
> > 
> > OK, I'll ring your bells again once when 4.15 development is opened.
> > 
> > 
> > > > IMO, it'd be great if you can carry all stuff through MFD tree; or
> > > > create an immutable branch (again).  But how to handle it, when to do
> > > > it, It's all up to you guys.
> > > 
> > > If there aren't any build dependencies between the patches, each of
> > > the patches should be applied through their own trees.  What are the
> > > build-time dependencies?  Are there any?
> > 
> > No, there is no strict build-time dependency.  It's just that I don't
> > see it nice to have a commit for a dead code, partly for testing
> > purpose and partly for code consistency.  But if this makes
> > maintenance easier, I'm happy with that, too, of course.
> 
> There won't be any dead code.  All of the subsystem trees are pulled
> into -next [0] where the build bots can operate on the patches as a
> whole.

But the merge order isn't guaranteed, i.e. at the commit of other tree
for this new stuff, it's a dead code without merging the MFD stuff
beforehand.  e.g. Imagine to perform the git bisection.  It's not
about the whole tree, but about the each commit.

And I won't be surprised if 0-day build bot gets a new feature to
inspect the kconfig files, spot a dead kconfig entry and warn
maintainers at each commit, too :)


thanks,

Takashi

Re: [PATCH v5 1/3] mfd: Add support for Cherry Trail Dollar Cove TI PMIC

[Rafael J. Wysocki]

On Tue, Sep 5, 2017 at 11:38 AM, Takashi Iwai <tiwai@suse.de> wrote:
> On Tue, 05 Sep 2017 10:53:41 +0200,
> Lee Jones wrote:
>>
>> On Tue, 05 Sep 2017, Takashi Iwai wrote:
>>
>> > On Tue, 05 Sep 2017 10:10:49 +0200,
>> > Lee Jones wrote:
>> > >
>> > > On Tue, 05 Sep 2017, Takashi Iwai wrote:
>> > >
>> > > > On Tue, 05 Sep 2017 09:24:51 +0200,
>> > > > Lee Jones wrote:
>> > > > >
>> > > > > On Mon, 04 Sep 2017, Takashi Iwai wrote:
>> > > > >
>> > > > > > This patch adds the MFD driver for Dollar Cove (TI version) PMIC with
>> > > > > > ACPI INT33F5 that is found on some Intel Cherry Trail devices.
>> > > > > > The driver is based on the original work by Intel, found at:
>> > > > > >   https://github.com/01org/ProductionKernelQuilts
>> > > > > >
>> > > > > > This is a minimal version for adding the basic resources.  Currently,
>> > > > > > only ACPI PMIC opregion and the external power-button are used.
>> > > > > >
>> > > > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891
>> > > > > > Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
>> > > > > > Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
>> > > > > > Signed-off-by: Takashi Iwai <tiwai@suse.de>
>> > > > > > ---
>> > > > > > v4->v5:
>> > > > > > * Minor coding-style fixes suggested by Lee
>> > > > > > * Put GPL text
>> > > > > > v3->v4:
>> > > > > > * no change for this patch
>> > > > > > v2->v3:
>> > > > > > * Rename dc_ti with chtdc_ti in all places
>> > > > > > * Driver/kconfig renames accordingly
>> > > > > > * Added acks by Andy and Mika
>> > > > > > v1->v2:
>> > > > > > * Minor cleanups as suggested by Andy
>> > > > > >
>> > > > > >  drivers/mfd/Kconfig                   |  13 +++
>> > > > > >  drivers/mfd/Makefile                  |   1 +
>> > > > > >  drivers/mfd/intel_soc_pmic_chtdc_ti.c | 184 ++++++++++++++++++++++++++++++++++
>> > > > > >  3 files changed, 198 insertions(+)
>> > > > > >  create mode 100644 drivers/mfd/intel_soc_pmic_chtdc_ti.c
>> > > > >
>> > > > > For my own reference:
>> > > > >   Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
>> > > >
>> > > > Thanks!
>> > > >
>> > > > Now the question is how to deal with these.  It's no critical things,
>> > > > so I'm OK to postpone for 4.15.  OTOH, it's really a new
>> > > > device-specific stuff, thus it can't break anything else, and it'd be
>> > > > fairly safe to add it for 4.14 although it's at a bit late stage.
>> > >
>> > > Yes, you are over 2 weeks late for v4.14.  It will have to be v4.15.
>> >
>> > OK, I'll ring your bells again once when 4.15 development is opened.
>> >
>> >
>> > > > IMO, it'd be great if you can carry all stuff through MFD tree; or
>> > > > create an immutable branch (again).  But how to handle it, when to do
>> > > > it, It's all up to you guys.
>> > >
>> > > If there aren't any build dependencies between the patches, each of
>> > > the patches should be applied through their own trees.  What are the
>> > > build-time dependencies?  Are there any?
>> >
>> > No, there is no strict build-time dependency.  It's just that I don't
>> > see it nice to have a commit for a dead code, partly for testing
>> > purpose and partly for code consistency.  But if this makes
>> > maintenance easier, I'm happy with that, too, of course.
>>
>> There won't be any dead code.  All of the subsystem trees are pulled
>> into -next [0] where the build bots can operate on the patches as a
>> whole.
>
> But the merge order isn't guaranteed, i.e. at the commit of other tree
> for this new stuff, it's a dead code without merging the MFD stuff
> beforehand.  e.g. Imagine to perform the git bisection.  It's not
> about the whole tree, but about the each commit.
>
> And I won't be surprised if 0-day build bot gets a new feature to
> inspect the kconfig files, spot a dead kconfig entry and warn
> maintainers at each commit, too :)

So I would prefer the whole series to go in via one tree in one go,
because it is a series for a reason. :-)

The patches do depend on each other logically even though there may
not be hard build-time dependencies between them.  It would be sort of
good if the git history reflected that logical dependency.

Thanks,
Rafael

Re: [PATCH v5 1/3] mfd: Add support for Cherry Trail Dollar Cove TI PMIC

[Lee Jones]

On Tue, 05 Sep 2017, Rafael J. Wysocki wrote:

> On Tue, Sep 5, 2017 at 11:38 AM, Takashi Iwai <tiwai@suse.de> wrote:
> > On Tue, 05 Sep 2017 10:53:41 +0200,
> > Lee Jones wrote:
> >>
> >> On Tue, 05 Sep 2017, Takashi Iwai wrote:
> >>
> >> > On Tue, 05 Sep 2017 10:10:49 +0200,
> >> > Lee Jones wrote:
> >> > >
> >> > > On Tue, 05 Sep 2017, Takashi Iwai wrote:
> >> > >
> >> > > > On Tue, 05 Sep 2017 09:24:51 +0200,
> >> > > > Lee Jones wrote:
> >> > > > >
> >> > > > > On Mon, 04 Sep 2017, Takashi Iwai wrote:
> >> > > > >
> >> > > > > > This patch adds the MFD driver for Dollar Cove (TI version) PMIC with
> >> > > > > > ACPI INT33F5 that is found on some Intel Cherry Trail devices.
> >> > > > > > The driver is based on the original work by Intel, found at:
> >> > > > > >   https://github.com/01org/ProductionKernelQuilts
> >> > > > > >
> >> > > > > > This is a minimal version for adding the basic resources.  Currently,
> >> > > > > > only ACPI PMIC opregion and the external power-button are used.
> >> > > > > >
> >> > > > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891
> >> > > > > > Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> >> > > > > > Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> >> > > > > > Signed-off-by: Takashi Iwai <tiwai@suse.de>
> >> > > > > > ---
> >> > > > > > v4->v5:
> >> > > > > > * Minor coding-style fixes suggested by Lee
> >> > > > > > * Put GPL text
> >> > > > > > v3->v4:
> >> > > > > > * no change for this patch
> >> > > > > > v2->v3:
> >> > > > > > * Rename dc_ti with chtdc_ti in all places
> >> > > > > > * Driver/kconfig renames accordingly
> >> > > > > > * Added acks by Andy and Mika
> >> > > > > > v1->v2:
> >> > > > > > * Minor cleanups as suggested by Andy
> >> > > > > >
> >> > > > > >  drivers/mfd/Kconfig                   |  13 +++
> >> > > > > >  drivers/mfd/Makefile                  |   1 +
> >> > > > > >  drivers/mfd/intel_soc_pmic_chtdc_ti.c | 184 ++++++++++++++++++++++++++++++++++
> >> > > > > >  3 files changed, 198 insertions(+)
> >> > > > > >  create mode 100644 drivers/mfd/intel_soc_pmic_chtdc_ti.c
> >> > > > >
> >> > > > > For my own reference:
> >> > > > >   Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> >> > > >
> >> > > > Thanks!
> >> > > >
> >> > > > Now the question is how to deal with these.  It's no critical things,
> >> > > > so I'm OK to postpone for 4.15.  OTOH, it's really a new
> >> > > > device-specific stuff, thus it can't break anything else, and it'd be
> >> > > > fairly safe to add it for 4.14 although it's at a bit late stage.
> >> > >
> >> > > Yes, you are over 2 weeks late for v4.14.  It will have to be v4.15.
> >> >
> >> > OK, I'll ring your bells again once when 4.15 development is opened.
> >> >
> >> >
> >> > > > IMO, it'd be great if you can carry all stuff through MFD tree; or
> >> > > > create an immutable branch (again).  But how to handle it, when to do
> >> > > > it, It's all up to you guys.
> >> > >
> >> > > If there aren't any build dependencies between the patches, each of
> >> > > the patches should be applied through their own trees.  What are the
> >> > > build-time dependencies?  Are there any?
> >> >
> >> > No, there is no strict build-time dependency.  It's just that I don't
> >> > see it nice to have a commit for a dead code, partly for testing
> >> > purpose and partly for code consistency.  But if this makes
> >> > maintenance easier, I'm happy with that, too, of course.
> >>
> >> There won't be any dead code.  All of the subsystem trees are pulled
> >> into -next [0] where the build bots can operate on the patches as a
> >> whole.
> >
> > But the merge order isn't guaranteed, i.e. at the commit of other tree
> > for this new stuff, it's a dead code without merging the MFD stuff
> > beforehand.  e.g. Imagine to perform the git bisection.  It's not
> > about the whole tree, but about the each commit.
> >
> > And I won't be surprised if 0-day build bot gets a new feature to
> > inspect the kconfig files, spot a dead kconfig entry and warn
> > maintainers at each commit, too :)
> 
> So I would prefer the whole series to go in via one tree in one go,
> because it is a series for a reason. :-)
> 
> The patches do depend on each other logically even though there may
> not be hard build-time dependencies between them.  It would be sort of
> good if the git history reflected that logical dependency.

We *never* do this.  Only build-time dependencies warrant the hassle
of immutable branches and cross-subsystem committing.  Patches should
be taken in via their own subsystems unless it would cause merge or
build issues if we did.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v5 1/3] mfd: Add support for Cherry Trail Dollar Cove TI PMIC

[Rafael J. Wysocki]

On Wednesday, September 6, 2017 9:58:52 AM CEST Lee Jones wrote:
> On Tue, 05 Sep 2017, Rafael J. Wysocki wrote:
> 
> > On Tue, Sep 5, 2017 at 11:38 AM, Takashi Iwai <tiwai@suse.de> wrote:
> > > On Tue, 05 Sep 2017 10:53:41 +0200,
> > > Lee Jones wrote:
> > >>
> > >> On Tue, 05 Sep 2017, Takashi Iwai wrote:
> > >>
> > >> > On Tue, 05 Sep 2017 10:10:49 +0200,
> > >> > Lee Jones wrote:
> > >> > >
> > >> > > On Tue, 05 Sep 2017, Takashi Iwai wrote:
> > >> > >
> > >> > > > On Tue, 05 Sep 2017 09:24:51 +0200,
> > >> > > > Lee Jones wrote:
> > >> > > > >
> > >> > > > > On Mon, 04 Sep 2017, Takashi Iwai wrote:
> > >> > > > >
> > >> > > > > > This patch adds the MFD driver for Dollar Cove (TI version) PMIC with
> > >> > > > > > ACPI INT33F5 that is found on some Intel Cherry Trail devices.
> > >> > > > > > The driver is based on the original work by Intel, found at:
> > >> > > > > >   https://github.com/01org/ProductionKernelQuilts
> > >> > > > > >
> > >> > > > > > This is a minimal version for adding the basic resources.  Currently,
> > >> > > > > > only ACPI PMIC opregion and the external power-button are used.
> > >> > > > > >
> > >> > > > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891
> > >> > > > > > Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> > >> > > > > > Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> > >> > > > > > Signed-off-by: Takashi Iwai <tiwai@suse.de>
> > >> > > > > > ---
> > >> > > > > > v4->v5:
> > >> > > > > > * Minor coding-style fixes suggested by Lee
> > >> > > > > > * Put GPL text
> > >> > > > > > v3->v4:
> > >> > > > > > * no change for this patch
> > >> > > > > > v2->v3:
> > >> > > > > > * Rename dc_ti with chtdc_ti in all places
> > >> > > > > > * Driver/kconfig renames accordingly
> > >> > > > > > * Added acks by Andy and Mika
> > >> > > > > > v1->v2:
> > >> > > > > > * Minor cleanups as suggested by Andy
> > >> > > > > >
> > >> > > > > >  drivers/mfd/Kconfig                   |  13 +++
> > >> > > > > >  drivers/mfd/Makefile                  |   1 +
> > >> > > > > >  drivers/mfd/intel_soc_pmic_chtdc_ti.c | 184 ++++++++++++++++++++++++++++++++++
> > >> > > > > >  3 files changed, 198 insertions(+)
> > >> > > > > >  create mode 100644 drivers/mfd/intel_soc_pmic_chtdc_ti.c
> > >> > > > >
> > >> > > > > For my own reference:
> > >> > > > >   Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> > >> > > >
> > >> > > > Thanks!
> > >> > > >
> > >> > > > Now the question is how to deal with these.  It's no critical things,
> > >> > > > so I'm OK to postpone for 4.15.  OTOH, it's really a new
> > >> > > > device-specific stuff, thus it can't break anything else, and it'd be
> > >> > > > fairly safe to add it for 4.14 although it's at a bit late stage.
> > >> > >
> > >> > > Yes, you are over 2 weeks late for v4.14.  It will have to be v4.15.
> > >> >
> > >> > OK, I'll ring your bells again once when 4.15 development is opened.
> > >> >
> > >> >
> > >> > > > IMO, it'd be great if you can carry all stuff through MFD tree; or
> > >> > > > create an immutable branch (again).  But how to handle it, when to do
> > >> > > > it, It's all up to you guys.
> > >> > >
> > >> > > If there aren't any build dependencies between the patches, each of
> > >> > > the patches should be applied through their own trees.  What are the
> > >> > > build-time dependencies?  Are there any?
> > >> >
> > >> > No, there is no strict build-time dependency.  It's just that I don't
> > >> > see it nice to have a commit for a dead code, partly for testing
> > >> > purpose and partly for code consistency.  But if this makes
> > >> > maintenance easier, I'm happy with that, too, of course.
> > >>
> > >> There won't be any dead code.  All of the subsystem trees are pulled
> > >> into -next [0] where the build bots can operate on the patches as a
> > >> whole.
> > >
> > > But the merge order isn't guaranteed, i.e. at the commit of other tree
> > > for this new stuff, it's a dead code without merging the MFD stuff
> > > beforehand.  e.g. Imagine to perform the git bisection.  It's not
> > > about the whole tree, but about the each commit.
> > >
> > > And I won't be surprised if 0-day build bot gets a new feature to
> > > inspect the kconfig files, spot a dead kconfig entry and warn
> > > maintainers at each commit, too :)
> > 
> > So I would prefer the whole series to go in via one tree in one go,
> > because it is a series for a reason. :-)
> > 
> > The patches do depend on each other logically even though there may
> > not be hard build-time dependencies between them.  It would be sort of
> > good if the git history reflected that logical dependency.
> 
> We *never* do this.

Who's we?  I sometimes do that, for one.  I guess Takashi does that too.
The tip people do that on a regular basis and I know of at least several
other top-level maintainers doing it at least occasionally.

> Only build-time dependencies warrant the hassle
> of immutable branches and cross-subsystem committing.  Patches should
> be taken in via their own subsystems unless it would cause merge or
> build issues if we did.

I beg to differ, but whatever.

In any case, I wouldn't mind it if you took the [3/3] from this series, because
if there are any conflicts with it, they will be trivial to resolve.  And I
don't need an immutable branch with it or anything like that.

Thanks,
Rafael

Re: [PATCH v5 1/3] mfd: Add support for Cherry Trail Dollar Cove TI PMIC

[Lee Jones]

On Wed, 06 Sep 2017, Rafael J. Wysocki wrote:

> On Wednesday, September 6, 2017 9:58:52 AM CEST Lee Jones wrote:
> > On Tue, 05 Sep 2017, Rafael J. Wysocki wrote:
> > 
> > > On Tue, Sep 5, 2017 at 11:38 AM, Takashi Iwai <tiwai@suse.de> wrote:
> > > > On Tue, 05 Sep 2017 10:53:41 +0200,
> > > > Lee Jones wrote:
> > > >>
> > > >> On Tue, 05 Sep 2017, Takashi Iwai wrote:
> > > >>
> > > >> > On Tue, 05 Sep 2017 10:10:49 +0200,
> > > >> > Lee Jones wrote:
> > > >> > >
> > > >> > > On Tue, 05 Sep 2017, Takashi Iwai wrote:
> > > >> > >
> > > >> > > > On Tue, 05 Sep 2017 09:24:51 +0200,
> > > >> > > > Lee Jones wrote:
> > > >> > > > >
> > > >> > > > > On Mon, 04 Sep 2017, Takashi Iwai wrote:
> > > >> > > > >
> > > >> > > > > > This patch adds the MFD driver for Dollar Cove (TI version) PMIC with
> > > >> > > > > > ACPI INT33F5 that is found on some Intel Cherry Trail devices.
> > > >> > > > > > The driver is based on the original work by Intel, found at:
> > > >> > > > > >   https://github.com/01org/ProductionKernelQuilts
> > > >> > > > > >
> > > >> > > > > > This is a minimal version for adding the basic resources.  Currently,
> > > >> > > > > > only ACPI PMIC opregion and the external power-button are used.
> > > >> > > > > >
> > > >> > > > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891
> > > >> > > > > > Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> > > >> > > > > > Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> > > >> > > > > > Signed-off-by: Takashi Iwai <tiwai@suse.de>
> > > >> > > > > > ---
> > > >> > > > > > v4->v5:
> > > >> > > > > > * Minor coding-style fixes suggested by Lee
> > > >> > > > > > * Put GPL text
> > > >> > > > > > v3->v4:
> > > >> > > > > > * no change for this patch
> > > >> > > > > > v2->v3:
> > > >> > > > > > * Rename dc_ti with chtdc_ti in all places
> > > >> > > > > > * Driver/kconfig renames accordingly
> > > >> > > > > > * Added acks by Andy and Mika
> > > >> > > > > > v1->v2:
> > > >> > > > > > * Minor cleanups as suggested by Andy
> > > >> > > > > >
> > > >> > > > > >  drivers/mfd/Kconfig                   |  13 +++
> > > >> > > > > >  drivers/mfd/Makefile                  |   1 +
> > > >> > > > > >  drivers/mfd/intel_soc_pmic_chtdc_ti.c | 184 ++++++++++++++++++++++++++++++++++
> > > >> > > > > >  3 files changed, 198 insertions(+)
> > > >> > > > > >  create mode 100644 drivers/mfd/intel_soc_pmic_chtdc_ti.c
> > > >> > > > >
> > > >> > > > > For my own reference:
> > > >> > > > >   Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> > > >> > > >
> > > >> > > > Thanks!
> > > >> > > >
> > > >> > > > Now the question is how to deal with these.  It's no critical things,
> > > >> > > > so I'm OK to postpone for 4.15.  OTOH, it's really a new
> > > >> > > > device-specific stuff, thus it can't break anything else, and it'd be
> > > >> > > > fairly safe to add it for 4.14 although it's at a bit late stage.
> > > >> > >
> > > >> > > Yes, you are over 2 weeks late for v4.14.  It will have to be v4.15.
> > > >> >
> > > >> > OK, I'll ring your bells again once when 4.15 development is opened.
> > > >> >
> > > >> >
> > > >> > > > IMO, it'd be great if you can carry all stuff through MFD tree; or
> > > >> > > > create an immutable branch (again).  But how to handle it, when to do
> > > >> > > > it, It's all up to you guys.
> > > >> > >
> > > >> > > If there aren't any build dependencies between the patches, each of
> > > >> > > the patches should be applied through their own trees.  What are the
> > > >> > > build-time dependencies?  Are there any?
> > > >> >
> > > >> > No, there is no strict build-time dependency.  It's just that I don't
> > > >> > see it nice to have a commit for a dead code, partly for testing
> > > >> > purpose and partly for code consistency.  But if this makes
> > > >> > maintenance easier, I'm happy with that, too, of course.
> > > >>
> > > >> There won't be any dead code.  All of the subsystem trees are pulled
> > > >> into -next [0] where the build bots can operate on the patches as a
> > > >> whole.
> > > >
> > > > But the merge order isn't guaranteed, i.e. at the commit of other tree
> > > > for this new stuff, it's a dead code without merging the MFD stuff
> > > > beforehand.  e.g. Imagine to perform the git bisection.  It's not
> > > > about the whole tree, but about the each commit.
> > > >
> > > > And I won't be surprised if 0-day build bot gets a new feature to
> > > > inspect the kconfig files, spot a dead kconfig entry and warn
> > > > maintainers at each commit, too :)
> > > 
> > > So I would prefer the whole series to go in via one tree in one go,
> > > because it is a series for a reason. :-)
> > > 
> > > The patches do depend on each other logically even though there may
> > > not be hard build-time dependencies between them.  It would be sort of
> > > good if the git history reflected that logical dependency.
> > 
> > We *never* do this.
> 
> Who's we?  I sometimes do that, for one.  I guess Takashi does that too.
> The tip people do that on a regular basis and I know of at least several
> other top-level maintainers doing it at least occasionally.

The Maintainers who normally interact with MFD; Regulator,
GPIO/Pinctrl, Power, IIO, PWM, ARM-SoC, LED, HWMON, Input MTD, PHY,
Regmap, I2C, RTC, etc.

> > Only build-time dependencies warrant the hassle
> > of immutable branches and cross-subsystem committing.  Patches should
> > be taken in via their own subsystems unless it would cause merge or
> > build issues if we did.
> 
> I beg to differ, but whatever.
> 
> In any case, I wouldn't mind it if you took the [3/3] from this series, because
> if there are any conflicts with it, they will be trivial to resolve.  And I
> don't need an immutable branch with it or anything like that.

No problem.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v5 1/3] mfd: Add support for Cherry Trail Dollar Cove TI PMIC

[Lee Jones]

> > In any case, I wouldn't mind it if you took the [3/3] from this series, because
> > if there are any conflicts with it, they will be trivial to resolve.  And I
> > don't need an immutable branch with it or anything like that.
> 
> No problem.

Although you don't appear to have reviewed it?

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v5 1/3] mfd: Add support for Cherry Trail Dollar Cove TI PMIC

[Rafael J. Wysocki]

On Wednesday, September 6, 2017 12:52:09 PM CEST Lee Jones wrote:
> > > In any case, I wouldn't mind it if you took the [3/3] from this series, because
> > > if there are any conflicts with it, they will be trivial to resolve.  And I
> > > don't need an immutable branch with it or anything like that.
> > 
> > No problem.
> 
> Although you don't appear to have reviewed it?

I have reviewed it, although I haven't sent a tag.

Generally speaking, for drivers/acpi/pmic/ Reviewed-bys from Mika and Andy are
sufficient (they likely are more familiar with the code in there than I am),
but please feel free to add an ACK from me to it too. :-)

Re: [PATCH v5 1/3] mfd: Add support for Cherry Trail Dollar Cove TI PMIC

[Lee Jones]

On Thu, 07 Sep 2017, Rafael J. Wysocki wrote:

> On Wednesday, September 6, 2017 12:52:09 PM CEST Lee Jones wrote:
> > > > In any case, I wouldn't mind it if you took the [3/3] from this series, because
> > > > if there are any conflicts with it, they will be trivial to resolve.  And I
> > > > don't need an immutable branch with it or anything like that.
> > > 
> > > No problem.
> > 
> > Although you don't appear to have reviewed it?
> 
> I have reviewed it, although I haven't sent a tag.
> 
> Generally speaking, for drivers/acpi/pmic/ Reviewed-bys from Mika and Andy are
> sufficient (they likely are more familiar with the code in there than I am),

I don't see them in MAINTAINERS.  I thought it was Len and yourself.

> but please feel free to add an ACK from me to it too. :-)

Will do, thank you.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v5 1/3] mfd: Add support for Cherry Trail Dollar Cove TI PMIC

[Rafael J. Wysocki]

On Thursday, September 7, 2017 9:39:03 AM CEST Lee Jones wrote:
> On Thu, 07 Sep 2017, Rafael J. Wysocki wrote:
> 
> > On Wednesday, September 6, 2017 12:52:09 PM CEST Lee Jones wrote:
> > > > > In any case, I wouldn't mind it if you took the [3/3] from this series, because
> > > > > if there are any conflicts with it, they will be trivial to resolve.  And I
> > > > > don't need an immutable branch with it or anything like that.
> > > > 
> > > > No problem.
> > > 
> > > Although you don't appear to have reviewed it?
> > 
> > I have reviewed it, although I haven't sent a tag.
> > 
> > Generally speaking, for drivers/acpi/pmic/ Reviewed-bys from Mika and Andy are
> > sufficient (they likely are more familiar with the code in there than I am),
> 
> I don't see them in MAINTAINERS.  I thought it was Len and yourself.

I do need help with code review at least in some areas, though.

Some of this information is missing from MAINTAINERS, but I guess that can be
addressed in this particular case.

Mika, Andy, would it be OK to add you as reviewers for drivers/acpi/pmic/
to MAINTAINERS?

Thanks,
Rafael

Re: [PATCH v5 1/3] mfd: Add support for Cherry Trail Dollar Cove TI PMIC

[Mika Westerberg]

On Thu, Sep 07, 2017 at 12:52:53PM +0200, Rafael J. Wysocki wrote:
> On Thursday, September 7, 2017 9:39:03 AM CEST Lee Jones wrote:
> > On Thu, 07 Sep 2017, Rafael J. Wysocki wrote:
> > 
> > > On Wednesday, September 6, 2017 12:52:09 PM CEST Lee Jones wrote:
> > > > > > In any case, I wouldn't mind it if you took the [3/3] from this series, because
> > > > > > if there are any conflicts with it, they will be trivial to resolve.  And I
> > > > > > don't need an immutable branch with it or anything like that.
> > > > > 
> > > > > No problem.
> > > > 
> > > > Although you don't appear to have reviewed it?
> > > 
> > > I have reviewed it, although I haven't sent a tag.
> > > 
> > > Generally speaking, for drivers/acpi/pmic/ Reviewed-bys from Mika and Andy are
> > > sufficient (they likely are more familiar with the code in there than I am),
> > 
> > I don't see them in MAINTAINERS.  I thought it was Len and yourself.
> 
> I do need help with code review at least in some areas, though.
> 
> Some of this information is missing from MAINTAINERS, but I guess that can be
> addressed in this particular case.
> 
> Mika, Andy, would it be OK to add you as reviewers for drivers/acpi/pmic/
> to MAINTAINERS?

Sure, fine by me. Andy is on vacation currently so can't speak for him.
I suppose he does not have anything against it, though :)

Re: [PATCH v5 1/3] mfd: Add support for Cherry Trail Dollar Cove TI PMIC

[Rafael J. Wysocki]

On Thursday, September 7, 2017 1:07:26 PM CEST Mika Westerberg wrote:
> On Thu, Sep 07, 2017 at 12:52:53PM +0200, Rafael J. Wysocki wrote:
> > On Thursday, September 7, 2017 9:39:03 AM CEST Lee Jones wrote:
> > > On Thu, 07 Sep 2017, Rafael J. Wysocki wrote:
> > > 
> > > > On Wednesday, September 6, 2017 12:52:09 PM CEST Lee Jones wrote:
> > > > > > > In any case, I wouldn't mind it if you took the [3/3] from this series, because
> > > > > > > if there are any conflicts with it, they will be trivial to resolve.  And I
> > > > > > > don't need an immutable branch with it or anything like that.
> > > > > > 
> > > > > > No problem.
> > > > > 
> > > > > Although you don't appear to have reviewed it?
> > > > 
> > > > I have reviewed it, although I haven't sent a tag.
> > > > 
> > > > Generally speaking, for drivers/acpi/pmic/ Reviewed-bys from Mika and Andy are
> > > > sufficient (they likely are more familiar with the code in there than I am),
> > > 
> > > I don't see them in MAINTAINERS.  I thought it was Len and yourself.
> > 
> > I do need help with code review at least in some areas, though.
> > 
> > Some of this information is missing from MAINTAINERS, but I guess that can be
> > addressed in this particular case.
> > 
> > Mika, Andy, would it be OK to add you as reviewers for drivers/acpi/pmic/
> > to MAINTAINERS?
> 
> Sure, fine by me. Andy is on vacation currently so can't speak for him.
> I suppose he does not have anything against it, though :)

OK, thanks!

Re: [PATCH v5 1/3] mfd: Add support for Cherry Trail Dollar Cove TI PMIC

[Lee Jones]

On Thu, 07 Sep 2017, Rafael J. Wysocki wrote:

> On Thursday, September 7, 2017 1:07:26 PM CEST Mika Westerberg wrote:
> > On Thu, Sep 07, 2017 at 12:52:53PM +0200, Rafael J. Wysocki wrote:
> > > On Thursday, September 7, 2017 9:39:03 AM CEST Lee Jones wrote:
> > > > On Thu, 07 Sep 2017, Rafael J. Wysocki wrote:
> > > > 
> > > > > On Wednesday, September 6, 2017 12:52:09 PM CEST Lee Jones wrote:
> > > > > > > > In any case, I wouldn't mind it if you took the [3/3] from this series, because
> > > > > > > > if there are any conflicts with it, they will be trivial to resolve.  And I
> > > > > > > > don't need an immutable branch with it or anything like that.
> > > > > > > 
> > > > > > > No problem.
> > > > > > 
> > > > > > Although you don't appear to have reviewed it?
> > > > > 
> > > > > I have reviewed it, although I haven't sent a tag.
> > > > > 
> > > > > Generally speaking, for drivers/acpi/pmic/ Reviewed-bys from Mika and Andy are
> > > > > sufficient (they likely are more familiar with the code in there than I am),
> > > > 
> > > > I don't see them in MAINTAINERS.  I thought it was Len and yourself.
> > > 
> > > I do need help with code review at least in some areas, though.
> > > 
> > > Some of this information is missing from MAINTAINERS, but I guess that can be
> > > addressed in this particular case.
> > > 
> > > Mika, Andy, would it be OK to add you as reviewers for drivers/acpi/pmic/
> > > to MAINTAINERS?
> > 
> > Sure, fine by me. Andy is on vacation currently so can't speak for him.
> > I suppose he does not have anything against it, though :)
> 
> OK, thanks!

+1

Thanks Rafael, that should make things easier in the future.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v5 1/3] mfd: Add support for Cherry Trail Dollar Cove TI PMIC

[Lee Jones]

On Tue, 05 Sep 2017, Takashi Iwai wrote:

> On Tue, 05 Sep 2017 10:53:41 +0200,
> Lee Jones wrote:
> > 
> > On Tue, 05 Sep 2017, Takashi Iwai wrote:
> > 
> > > On Tue, 05 Sep 2017 10:10:49 +0200,
> > > Lee Jones wrote:
> > > > 
> > > > On Tue, 05 Sep 2017, Takashi Iwai wrote:
> > > > 
> > > > > On Tue, 05 Sep 2017 09:24:51 +0200,
> > > > > Lee Jones wrote:
> > > > > > 
> > > > > > On Mon, 04 Sep 2017, Takashi Iwai wrote:
> > > > > > 
> > > > > > > This patch adds the MFD driver for Dollar Cove (TI version) PMIC with
> > > > > > > ACPI INT33F5 that is found on some Intel Cherry Trail devices.
> > > > > > > The driver is based on the original work by Intel, found at:
> > > > > > >   https://github.com/01org/ProductionKernelQuilts
> > > > > > > 
> > > > > > > This is a minimal version for adding the basic resources.  Currently,
> > > > > > > only ACPI PMIC opregion and the external power-button are used.
> > > > > > > 
> > > > > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891
> > > > > > > Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> > > > > > > Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> > > > > > > Signed-off-by: Takashi Iwai <tiwai@suse.de>
> > > > > > > ---
> > > > > > > v4->v5:
> > > > > > > * Minor coding-style fixes suggested by Lee
> > > > > > > * Put GPL text
> > > > > > > v3->v4:
> > > > > > > * no change for this patch
> > > > > > > v2->v3:
> > > > > > > * Rename dc_ti with chtdc_ti in all places
> > > > > > > * Driver/kconfig renames accordingly
> > > > > > > * Added acks by Andy and Mika
> > > > > > > v1->v2:
> > > > > > > * Minor cleanups as suggested by Andy
> > > > > > > 
> > > > > > >  drivers/mfd/Kconfig                   |  13 +++
> > > > > > >  drivers/mfd/Makefile                  |   1 +
> > > > > > >  drivers/mfd/intel_soc_pmic_chtdc_ti.c | 184 ++++++++++++++++++++++++++++++++++
> > > > > > >  3 files changed, 198 insertions(+)
> > > > > > >  create mode 100644 drivers/mfd/intel_soc_pmic_chtdc_ti.c
> > > > > > 
> > > > > > For my own reference:
> > > > > >   Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> > > > > 
> > > > > Thanks!
> > > > > 
> > > > > Now the question is how to deal with these.  It's no critical things,
> > > > > so I'm OK to postpone for 4.15.  OTOH, it's really a new
> > > > > device-specific stuff, thus it can't break anything else, and it'd be
> > > > > fairly safe to add it for 4.14 although it's at a bit late stage.
> > > > 
> > > > Yes, you are over 2 weeks late for v4.14.  It will have to be v4.15.
> > > 
> > > OK, I'll ring your bells again once when 4.15 development is opened.
> > > 
> > > 
> > > > > IMO, it'd be great if you can carry all stuff through MFD tree; or
> > > > > create an immutable branch (again).  But how to handle it, when to do
> > > > > it, It's all up to you guys.
> > > > 
> > > > If there aren't any build dependencies between the patches, each of
> > > > the patches should be applied through their own trees.  What are the
> > > > build-time dependencies?  Are there any?
> > > 
> > > No, there is no strict build-time dependency.  It's just that I don't
> > > see it nice to have a commit for a dead code, partly for testing
> > > purpose and partly for code consistency.  But if this makes
> > > maintenance easier, I'm happy with that, too, of course.
> > 
> > There won't be any dead code.  All of the subsystem trees are pulled
> > into -next [0] where the build bots can operate on the patches as a
> > whole.
> 
> But the merge order isn't guaranteed, i.e. at the commit of other tree
> for this new stuff, it's a dead code without merging the MFD stuff
> beforehand.  e.g. Imagine to perform the git bisection.  It's not
> about the whole tree, but about the each commit.

Only *building* is relevant for bisection until the whole feature
lands.  No one is going to bisect the function of a feature until it
is present.  So long as there aren't any build-time dependencies then
we're good, 

> And I won't be surprised if 0-day build bot gets a new feature to
> inspect the kconfig files, spot a dead kconfig entry and warn
> maintainers at each commit, too :)


0-days don't check for that and static analysers only check releases.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v5 1/3] mfd: Add support for Cherry Trail Dollar Cove TI PMIC

[Takashi Iwai]

On Wed, 06 Sep 2017 09:54:44 +0200,
Lee Jones wrote:
> 
> On Tue, 05 Sep 2017, Takashi Iwai wrote:
> 
> > On Tue, 05 Sep 2017 10:53:41 +0200,
> > Lee Jones wrote:
> > > 
> > > On Tue, 05 Sep 2017, Takashi Iwai wrote:
> > > 
> > > > On Tue, 05 Sep 2017 10:10:49 +0200,
> > > > Lee Jones wrote:
> > > > > 
> > > > > On Tue, 05 Sep 2017, Takashi Iwai wrote:
> > > > > 
> > > > > > On Tue, 05 Sep 2017 09:24:51 +0200,
> > > > > > Lee Jones wrote:
> > > > > > > 
> > > > > > > On Mon, 04 Sep 2017, Takashi Iwai wrote:
> > > > > > > 
> > > > > > > > This patch adds the MFD driver for Dollar Cove (TI version) PMIC with
> > > > > > > > ACPI INT33F5 that is found on some Intel Cherry Trail devices.
> > > > > > > > The driver is based on the original work by Intel, found at:
> > > > > > > >   https://github.com/01org/ProductionKernelQuilts
> > > > > > > > 
> > > > > > > > This is a minimal version for adding the basic resources.  Currently,
> > > > > > > > only ACPI PMIC opregion and the external power-button are used.
> > > > > > > > 
> > > > > > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891
> > > > > > > > Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> > > > > > > > Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> > > > > > > > Signed-off-by: Takashi Iwai <tiwai@suse.de>
> > > > > > > > ---
> > > > > > > > v4->v5:
> > > > > > > > * Minor coding-style fixes suggested by Lee
> > > > > > > > * Put GPL text
> > > > > > > > v3->v4:
> > > > > > > > * no change for this patch
> > > > > > > > v2->v3:
> > > > > > > > * Rename dc_ti with chtdc_ti in all places
> > > > > > > > * Driver/kconfig renames accordingly
> > > > > > > > * Added acks by Andy and Mika
> > > > > > > > v1->v2:
> > > > > > > > * Minor cleanups as suggested by Andy
> > > > > > > > 
> > > > > > > >  drivers/mfd/Kconfig                   |  13 +++
> > > > > > > >  drivers/mfd/Makefile                  |   1 +
> > > > > > > >  drivers/mfd/intel_soc_pmic_chtdc_ti.c | 184 ++++++++++++++++++++++++++++++++++
> > > > > > > >  3 files changed, 198 insertions(+)
> > > > > > > >  create mode 100644 drivers/mfd/intel_soc_pmic_chtdc_ti.c
> > > > > > > 
> > > > > > > For my own reference:
> > > > > > >   Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> > > > > > 
> > > > > > Thanks!
> > > > > > 
> > > > > > Now the question is how to deal with these.  It's no critical things,
> > > > > > so I'm OK to postpone for 4.15.  OTOH, it's really a new
> > > > > > device-specific stuff, thus it can't break anything else, and it'd be
> > > > > > fairly safe to add it for 4.14 although it's at a bit late stage.
> > > > > 
> > > > > Yes, you are over 2 weeks late for v4.14.  It will have to be v4.15.
> > > > 
> > > > OK, I'll ring your bells again once when 4.15 development is opened.
> > > > 
> > > > 
> > > > > > IMO, it'd be great if you can carry all stuff through MFD tree; or
> > > > > > create an immutable branch (again).  But how to handle it, when to do
> > > > > > it, It's all up to you guys.
> > > > > 
> > > > > If there aren't any build dependencies between the patches, each of
> > > > > the patches should be applied through their own trees.  What are the
> > > > > build-time dependencies?  Are there any?
> > > > 
> > > > No, there is no strict build-time dependency.  It's just that I don't
> > > > see it nice to have a commit for a dead code, partly for testing
> > > > purpose and partly for code consistency.  But if this makes
> > > > maintenance easier, I'm happy with that, too, of course.
> > > 
> > > There won't be any dead code.  All of the subsystem trees are pulled
> > > into -next [0] where the build bots can operate on the patches as a
> > > whole.
> > 
> > But the merge order isn't guaranteed, i.e. at the commit of other tree
> > for this new stuff, it's a dead code without merging the MFD stuff
> > beforehand.  e.g. Imagine to perform the git bisection.  It's not
> > about the whole tree, but about the each commit.
> 
> Only *building* is relevant for bisection until the whole feature
> lands.

Why only building?

When merging through several tress, commits for the same series are
scattered completely although they are softly tied.  This sucks when
you perform git bisection, e.g. if you have an issue in the middle of
the patch series.  It still works, but it jumps unnecessarily too far
away and back before reaching to the point, and kconfig appears /
disappears inconsistently (the dependent kconfig gone in the middle).
And, this is about the release kernel (4.15 or whatever).

Basically, my complaint here comes with my user's hat on.  It *is*
indeed worse than a straight application of patches in some levels.
It's unavoidable if you do in that way.

OTOH, with maintainer's hat on, I do agree with that it'll make things
often easier.  Judging with these merits and demerits, I find it's
acceptable, too.

> No one is going to bisect the function of a feature until it
> is present.  So long as there aren't any build-time dependencies then
> we're good, 
> 
> > And I won't be surprised if 0-day build bot gets a new feature to
> > inspect the kconfig files, spot a dead kconfig entry and warn
> > maintainers at each commit, too :)
> 
> 
> 0-days don't check for that and static analysers only check releases.

How can you guarantee that 0-days will not do that in future?
I learned that I shouldn't be too naive about 0-day bot facility :)


In anyway, as I already mentioned, I'm fine with taking changes
individually in each tree.  No need for further bike-shedding.


thanks,

Takashi

Re: [PATCH v5 1/3] mfd: Add support for Cherry Trail Dollar Cove TI PMIC

[Lee Jones]

On Wed, 06 Sep 2017, Takashi Iwai wrote:

> On Wed, 06 Sep 2017 09:54:44 +0200,
> Lee Jones wrote:
> > 
> > On Tue, 05 Sep 2017, Takashi Iwai wrote:
> > 
> > > On Tue, 05 Sep 2017 10:53:41 +0200,
> > > Lee Jones wrote:
> > > > 
> > > > On Tue, 05 Sep 2017, Takashi Iwai wrote:
> > > > 
> > > > > On Tue, 05 Sep 2017 10:10:49 +0200,
> > > > > Lee Jones wrote:
> > > > > > 
> > > > > > On Tue, 05 Sep 2017, Takashi Iwai wrote:
> > > > > > 
> > > > > > > On Tue, 05 Sep 2017 09:24:51 +0200,
> > > > > > > Lee Jones wrote:
> > > > > > > > 
> > > > > > > > On Mon, 04 Sep 2017, Takashi Iwai wrote:
> > > > > > > > 
> > > > > > > > > This patch adds the MFD driver for Dollar Cove (TI version) PMIC with
> > > > > > > > > ACPI INT33F5 that is found on some Intel Cherry Trail devices.
> > > > > > > > > The driver is based on the original work by Intel, found at:
> > > > > > > > >   https://github.com/01org/ProductionKernelQuilts
> > > > > > > > > 
> > > > > > > > > This is a minimal version for adding the basic resources.  Currently,
> > > > > > > > > only ACPI PMIC opregion and the external power-button are used.
> > > > > > > > > 
> > > > > > > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891
> > > > > > > > > Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> > > > > > > > > Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> > > > > > > > > Signed-off-by: Takashi Iwai <tiwai@suse.de>
> > > > > > > > > ---
> > > > > > > > > v4->v5:
> > > > > > > > > * Minor coding-style fixes suggested by Lee
> > > > > > > > > * Put GPL text
> > > > > > > > > v3->v4:
> > > > > > > > > * no change for this patch
> > > > > > > > > v2->v3:
> > > > > > > > > * Rename dc_ti with chtdc_ti in all places
> > > > > > > > > * Driver/kconfig renames accordingly
> > > > > > > > > * Added acks by Andy and Mika
> > > > > > > > > v1->v2:
> > > > > > > > > * Minor cleanups as suggested by Andy
> > > > > > > > > 
> > > > > > > > >  drivers/mfd/Kconfig                   |  13 +++
> > > > > > > > >  drivers/mfd/Makefile                  |   1 +
> > > > > > > > >  drivers/mfd/intel_soc_pmic_chtdc_ti.c | 184 ++++++++++++++++++++++++++++++++++
> > > > > > > > >  3 files changed, 198 insertions(+)
> > > > > > > > >  create mode 100644 drivers/mfd/intel_soc_pmic_chtdc_ti.c
> > > > > > > > 
> > > > > > > > For my own reference:
> > > > > > > >   Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> > > > > > > 
> > > > > > > Thanks!
> > > > > > > 
> > > > > > > Now the question is how to deal with these.  It's no critical things,
> > > > > > > so I'm OK to postpone for 4.15.  OTOH, it's really a new
> > > > > > > device-specific stuff, thus it can't break anything else, and it'd be
> > > > > > > fairly safe to add it for 4.14 although it's at a bit late stage.
> > > > > > 
> > > > > > Yes, you are over 2 weeks late for v4.14.  It will have to be v4.15.
> > > > > 
> > > > > OK, I'll ring your bells again once when 4.15 development is opened.
> > > > > 
> > > > > 
> > > > > > > IMO, it'd be great if you can carry all stuff through MFD tree; or
> > > > > > > create an immutable branch (again).  But how to handle it, when to do
> > > > > > > it, It's all up to you guys.
> > > > > > 
> > > > > > If there aren't any build dependencies between the patches, each of
> > > > > > the patches should be applied through their own trees.  What are the
> > > > > > build-time dependencies?  Are there any?
> > > > > 
> > > > > No, there is no strict build-time dependency.  It's just that I don't
> > > > > see it nice to have a commit for a dead code, partly for testing
> > > > > purpose and partly for code consistency.  But if this makes
> > > > > maintenance easier, I'm happy with that, too, of course.
> > > > 
> > > > There won't be any dead code.  All of the subsystem trees are pulled
> > > > into -next [0] where the build bots can operate on the patches as a
> > > > whole.
> > > 
> > > But the merge order isn't guaranteed, i.e. at the commit of other tree
> > > for this new stuff, it's a dead code without merging the MFD stuff
> > > beforehand.  e.g. Imagine to perform the git bisection.  It's not
> > > about the whole tree, but about the each commit.
> > 
> > Only *building* is relevant for bisection until the whole feature
> > lands.
> 
> Why only building?
> 
> When merging through several tress, commits for the same series are
> scattered completely although they are softly tied.  This sucks when
> you perform git bisection, e.g. if you have an issue in the middle of
> the patch series.  It still works, but it jumps unnecessarily too far
> away and back before reaching to the point, and kconfig appears /
> disappears inconsistently (the dependent kconfig gone in the middle).
> And, this is about the release kernel (4.15 or whatever).

Think about how bisection works.  You state a good commit and a bad
one.  The good commit will be when the feature last worked, which will
not be until the feature has fully landed.  Bisect will not check any
point prior to this date.

If there aren't any build deps, each Maintainer will apply patches
into their own tree.  These will be merged together in -next where
they can be tested, both manually and by the 0-days.  Once the merge
window is opened all patches will be sucked into -rc1.  If the feature
works here, then it you could use -rc1 as your 'good' commit.  If it
doesn't, then this could indicate a merge error or a missing piece of
the set, either way bisect wouldn't help you.

> Basically, my complaint here comes with my user's hat on.  It *is*
> indeed worse than a straight application of patches in some levels.
> It's unavoidable if you do in that way.

I disagree.  I user wouldn't set the 'good' commit at any point prior
to the feature working at least once.  This will not happen if any
parts were missing.  The order in which the pieces are applied is
irrelevant if there aren't any build deps between them.  If you bisect
between them, then the driver simply will not build.  No problem.

> OTOH, with maintainer's hat on, I do agree with that it'll make things
> often easier.  Judging with these merits and demerits, I find it's
> acceptable, too.
> 
> > No one is going to bisect the function of a feature until it
> > is present.  So long as there aren't any build-time dependencies then
> > we're good, 
> > 
> > > And I won't be surprised if 0-day build bot gets a new feature to
> > > inspect the kconfig files, spot a dead kconfig entry and warn
> > > maintainers at each commit, too :)
> > 
> > 
> > 0-days don't check for that and static analysers only check releases.
> 
> How can you guarantee that 0-days will not do that in future?
> I learned that I shouldn't be too naive about 0-day bot facility :)

Due to the way we operate, testing for dead code in between releases
would be foolish, since there would be too many false positives.
Static analysis is best for this and they are normally run on releases.

> In anyway, as I already mentioned, I'm fine with taking changes
> individually in each tree.  No need for further bike-shedding.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v5 1/3] mfd: Add support for Cherry Trail Dollar Cove TI PMIC

[Takashi Iwai]

On Wed, 06 Sep 2017 11:05:04 +0200,
Lee Jones wrote:
> 
> On Wed, 06 Sep 2017, Takashi Iwai wrote:
> 
> > On Wed, 06 Sep 2017 09:54:44 +0200,
> > Lee Jones wrote:
> > > 
> > > On Tue, 05 Sep 2017, Takashi Iwai wrote:
> > > 
> > > > On Tue, 05 Sep 2017 10:53:41 +0200,
> > > > Lee Jones wrote:
> > > > > 
> > > > > On Tue, 05 Sep 2017, Takashi Iwai wrote:
> > > > > 
> > > > > > On Tue, 05 Sep 2017 10:10:49 +0200,
> > > > > > Lee Jones wrote:
> > > > > > > 
> > > > > > > On Tue, 05 Sep 2017, Takashi Iwai wrote:
> > > > > > > 
> > > > > > > > On Tue, 05 Sep 2017 09:24:51 +0200,
> > > > > > > > Lee Jones wrote:
> > > > > > > > > 
> > > > > > > > > On Mon, 04 Sep 2017, Takashi Iwai wrote:
> > > > > > > > > 
> > > > > > > > > > This patch adds the MFD driver for Dollar Cove (TI version) PMIC with
> > > > > > > > > > ACPI INT33F5 that is found on some Intel Cherry Trail devices.
> > > > > > > > > > The driver is based on the original work by Intel, found at:
> > > > > > > > > >   https://github.com/01org/ProductionKernelQuilts
> > > > > > > > > > 
> > > > > > > > > > This is a minimal version for adding the basic resources.  Currently,
> > > > > > > > > > only ACPI PMIC opregion and the external power-button are used.
> > > > > > > > > > 
> > > > > > > > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891
> > > > > > > > > > Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> > > > > > > > > > Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> > > > > > > > > > Signed-off-by: Takashi Iwai <tiwai@suse.de>
> > > > > > > > > > ---
> > > > > > > > > > v4->v5:
> > > > > > > > > > * Minor coding-style fixes suggested by Lee
> > > > > > > > > > * Put GPL text
> > > > > > > > > > v3->v4:
> > > > > > > > > > * no change for this patch
> > > > > > > > > > v2->v3:
> > > > > > > > > > * Rename dc_ti with chtdc_ti in all places
> > > > > > > > > > * Driver/kconfig renames accordingly
> > > > > > > > > > * Added acks by Andy and Mika
> > > > > > > > > > v1->v2:
> > > > > > > > > > * Minor cleanups as suggested by Andy
> > > > > > > > > > 
> > > > > > > > > >  drivers/mfd/Kconfig                   |  13 +++
> > > > > > > > > >  drivers/mfd/Makefile                  |   1 +
> > > > > > > > > >  drivers/mfd/intel_soc_pmic_chtdc_ti.c | 184 ++++++++++++++++++++++++++++++++++
> > > > > > > > > >  3 files changed, 198 insertions(+)
> > > > > > > > > >  create mode 100644 drivers/mfd/intel_soc_pmic_chtdc_ti.c
> > > > > > > > > 
> > > > > > > > > For my own reference:
> > > > > > > > >   Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> > > > > > > > 
> > > > > > > > Thanks!
> > > > > > > > 
> > > > > > > > Now the question is how to deal with these.  It's no critical things,
> > > > > > > > so I'm OK to postpone for 4.15.  OTOH, it's really a new
> > > > > > > > device-specific stuff, thus it can't break anything else, and it'd be
> > > > > > > > fairly safe to add it for 4.14 although it's at a bit late stage.
> > > > > > > 
> > > > > > > Yes, you are over 2 weeks late for v4.14.  It will have to be v4.15.
> > > > > > 
> > > > > > OK, I'll ring your bells again once when 4.15 development is opened.
> > > > > > 
> > > > > > 
> > > > > > > > IMO, it'd be great if you can carry all stuff through MFD tree; or
> > > > > > > > create an immutable branch (again).  But how to handle it, when to do
> > > > > > > > it, It's all up to you guys.
> > > > > > > 
> > > > > > > If there aren't any build dependencies between the patches, each of
> > > > > > > the patches should be applied through their own trees.  What are the
> > > > > > > build-time dependencies?  Are there any?
> > > > > > 
> > > > > > No, there is no strict build-time dependency.  It's just that I don't
> > > > > > see it nice to have a commit for a dead code, partly for testing
> > > > > > purpose and partly for code consistency.  But if this makes
> > > > > > maintenance easier, I'm happy with that, too, of course.
> > > > > 
> > > > > There won't be any dead code.  All of the subsystem trees are pulled
> > > > > into -next [0] where the build bots can operate on the patches as a
> > > > > whole.
> > > > 
> > > > But the merge order isn't guaranteed, i.e. at the commit of other tree
> > > > for this new stuff, it's a dead code without merging the MFD stuff
> > > > beforehand.  e.g. Imagine to perform the git bisection.  It's not
> > > > about the whole tree, but about the each commit.
> > > 
> > > Only *building* is relevant for bisection until the whole feature
> > > lands.
> > 
> > Why only building?
> > 
> > When merging through several tress, commits for the same series are
> > scattered completely although they are softly tied.  This sucks when
> > you perform git bisection, e.g. if you have an issue in the middle of
> > the patch series.  It still works, but it jumps unnecessarily too far
> > away and back before reaching to the point, and kconfig appears /
> > disappears inconsistently (the dependent kconfig gone in the middle).
> > And, this is about the release kernel (4.15 or whatever).
> 
> Think about how bisection works.  You state a good commit and a bad
> one.  The good commit will be when the feature last worked, which will
> not be until the feature has fully landed.  Bisect will not check any
> point prior to this date.
> 
> If there aren't any build deps, each Maintainer will apply patches
> into their own tree.  These will be merged together in -next where
> they can be tested, both manually and by the 0-days.  Once the merge
> window is opened all patches will be sucked into -rc1.  If the feature
> works here, then it you could use -rc1 as your 'good' commit.  If it
> doesn't, then this could indicate a merge error or a missing piece of
> the set, either way bisect wouldn't help you.

Not really.

First of all, most of user start testing from the release kernel, so
you can't trust that RC covered all test cases.  (Who can blame users
who didn't use / test RC?)

Second, you ignore the fact that the development continues after
merging *this* patchset.  What if a breakage is introduced after this
patch?  (See below)

They often need a full bisection between the previous release and the
current release.

> > Basically, my complaint here comes with my user's hat on.  It *is*
> > indeed worse than a straight application of patches in some levels.
> > It's unavoidable if you do in that way.
> 
> I disagree.  I user wouldn't set the 'good' commit at any point prior
> to the feature working at least once.

Again no, not all users do test at the same time.  A device driver
may support multiple devices / platforms, and it might be that the bug
manifests itself only on a certain system that no one has tested
beforehand; it's a typical case we often see after the releases.

> This will not happen if any
> parts were missing.  The order in which the pieces are applied is
> irrelevant if there aren't any build deps between them.  If you bisect
> between them, then the driver simply will not build.  No problem.

The bisection is required not only for build errors but also for
functional tests.  Sometimes it's the only way to spot the culprit of
a functional regression.

Imagine the following case: both MFD and platform drivers are merged
into individual trees separately.  And, some change in platform driver
after this patch series broke some functionality mistakenly.

Now, suppose that the platform tree is merged to Linus tree before MFD
tree, that is, the situation is like:

  MFD (commit A1) -- ... -------------------------+
  platform (commit B1) -> broken change (B2) -+   |
                                              v   v
                                            --M1--M2--> Linus RC1

git-bisection can inspect M2, which shows already broken.  Then it
inspects M1, but you can't evaluate it because the target platform
driver can't be built without A1.  At this point, you're stuck.
But in this case, B1 is correct and B2 is the culprit.  How can you
spot it out?

OTOH, if the merge history honors the functional dependency, you can
bisect properly.


thanks,

Takashi

Re: [PATCH v5 1/3] mfd: Add support for Cherry Trail Dollar Cove TI PMIC

[Rafael J. Wysocki]

On Wednesday, September 6, 2017 12:06:50 PM CEST Takashi Iwai wrote:
> On Wed, 06 Sep 2017 11:05:04 +0200,
> Lee Jones wrote:
> > 
> > On Wed, 06 Sep 2017, Takashi Iwai wrote:
> > 
> > > On Wed, 06 Sep 2017 09:54:44 +0200,
> > > Lee Jones wrote:
> > > > 
> > > > On Tue, 05 Sep 2017, Takashi Iwai wrote:
> > > > 
> > > > > On Tue, 05 Sep 2017 10:53:41 +0200,
> > > > > Lee Jones wrote:
> > > > > > 
> > > > > > On Tue, 05 Sep 2017, Takashi Iwai wrote:
> > > > > > 
> > > > > > > On Tue, 05 Sep 2017 10:10:49 +0200,
> > > > > > > Lee Jones wrote:
> > > > > > > > 
> > > > > > > > On Tue, 05 Sep 2017, Takashi Iwai wrote:
> > > > > > > > 
> > > > > > > > > On Tue, 05 Sep 2017 09:24:51 +0200,
> > > > > > > > > Lee Jones wrote:
> > > > > > > > > > 
> > > > > > > > > > On Mon, 04 Sep 2017, Takashi Iwai wrote:
> > > > > > > > > > 
> > > > > > > > > > > This patch adds the MFD driver for Dollar Cove (TI version) PMIC with
> > > > > > > > > > > ACPI INT33F5 that is found on some Intel Cherry Trail devices.
> > > > > > > > > > > The driver is based on the original work by Intel, found at:
> > > > > > > > > > >   https://github.com/01org/ProductionKernelQuilts
> > > > > > > > > > > 
> > > > > > > > > > > This is a minimal version for adding the basic resources.  Currently,
> > > > > > > > > > > only ACPI PMIC opregion and the external power-button are used.
> > > > > > > > > > > 
> > > > > > > > > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891
> > > > > > > > > > > Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> > > > > > > > > > > Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> > > > > > > > > > > Signed-off-by: Takashi Iwai <tiwai@suse.de>
> > > > > > > > > > > ---
> > > > > > > > > > > v4->v5:
> > > > > > > > > > > * Minor coding-style fixes suggested by Lee
> > > > > > > > > > > * Put GPL text
> > > > > > > > > > > v3->v4:
> > > > > > > > > > > * no change for this patch
> > > > > > > > > > > v2->v3:
> > > > > > > > > > > * Rename dc_ti with chtdc_ti in all places
> > > > > > > > > > > * Driver/kconfig renames accordingly
> > > > > > > > > > > * Added acks by Andy and Mika
> > > > > > > > > > > v1->v2:
> > > > > > > > > > > * Minor cleanups as suggested by Andy
> > > > > > > > > > > 
> > > > > > > > > > >  drivers/mfd/Kconfig                   |  13 +++
> > > > > > > > > > >  drivers/mfd/Makefile                  |   1 +
> > > > > > > > > > >  drivers/mfd/intel_soc_pmic_chtdc_ti.c | 184 ++++++++++++++++++++++++++++++++++
> > > > > > > > > > >  3 files changed, 198 insertions(+)
> > > > > > > > > > >  create mode 100644 drivers/mfd/intel_soc_pmic_chtdc_ti.c
> > > > > > > > > > 
> > > > > > > > > > For my own reference:
> > > > > > > > > >   Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> > > > > > > > > 
> > > > > > > > > Thanks!
> > > > > > > > > 
> > > > > > > > > Now the question is how to deal with these.  It's no critical things,
> > > > > > > > > so I'm OK to postpone for 4.15.  OTOH, it's really a new
> > > > > > > > > device-specific stuff, thus it can't break anything else, and it'd be
> > > > > > > > > fairly safe to add it for 4.14 although it's at a bit late stage.
> > > > > > > > 
> > > > > > > > Yes, you are over 2 weeks late for v4.14.  It will have to be v4.15.
> > > > > > > 
> > > > > > > OK, I'll ring your bells again once when 4.15 development is opened.
> > > > > > > 
> > > > > > > 
> > > > > > > > > IMO, it'd be great if you can carry all stuff through MFD tree; or
> > > > > > > > > create an immutable branch (again).  But how to handle it, when to do
> > > > > > > > > it, It's all up to you guys.
> > > > > > > > 
> > > > > > > > If there aren't any build dependencies between the patches, each of
> > > > > > > > the patches should be applied through their own trees.  What are the
> > > > > > > > build-time dependencies?  Are there any?
> > > > > > > 
> > > > > > > No, there is no strict build-time dependency.  It's just that I don't
> > > > > > > see it nice to have a commit for a dead code, partly for testing
> > > > > > > purpose and partly for code consistency.  But if this makes
> > > > > > > maintenance easier, I'm happy with that, too, of course.
> > > > > > 
> > > > > > There won't be any dead code.  All of the subsystem trees are pulled
> > > > > > into -next [0] where the build bots can operate on the patches as a
> > > > > > whole.
> > > > > 
> > > > > But the merge order isn't guaranteed, i.e. at the commit of other tree
> > > > > for this new stuff, it's a dead code without merging the MFD stuff
> > > > > beforehand.  e.g. Imagine to perform the git bisection.  It's not
> > > > > about the whole tree, but about the each commit.
> > > > 
> > > > Only *building* is relevant for bisection until the whole feature
> > > > lands.
> > > 
> > > Why only building?
> > > 
> > > When merging through several tress, commits for the same series are
> > > scattered completely although they are softly tied.  This sucks when
> > > you perform git bisection, e.g. if you have an issue in the middle of
> > > the patch series.  It still works, but it jumps unnecessarily too far
> > > away and back before reaching to the point, and kconfig appears /
> > > disappears inconsistently (the dependent kconfig gone in the middle).
> > > And, this is about the release kernel (4.15 or whatever).
> > 
> > Think about how bisection works.  You state a good commit and a bad
> > one.  The good commit will be when the feature last worked, which will
> > not be until the feature has fully landed.  Bisect will not check any
> > point prior to this date.
> > 
> > If there aren't any build deps, each Maintainer will apply patches
> > into their own tree.  These will be merged together in -next where
> > they can be tested, both manually and by the 0-days.  Once the merge
> > window is opened all patches will be sucked into -rc1.  If the feature
> > works here, then it you could use -rc1 as your 'good' commit.  If it
> > doesn't, then this could indicate a merge error or a missing piece of
> > the set, either way bisect wouldn't help you.
> 
> Not really.
> 
> First of all, most of user start testing from the release kernel, so
> you can't trust that RC covered all test cases.  (Who can blame users
> who didn't use / test RC?)
> 
> Second, you ignore the fact that the development continues after
> merging *this* patchset.  What if a breakage is introduced after this
> patch?  (See below)
> 
> They often need a full bisection between the previous release and the
> current release.
> 
> > > Basically, my complaint here comes with my user's hat on.  It *is*
> > > indeed worse than a straight application of patches in some levels.
> > > It's unavoidable if you do in that way.
> > 
> > I disagree.  I user wouldn't set the 'good' commit at any point prior
> > to the feature working at least once.
> 
> Again no, not all users do test at the same time.  A device driver
> may support multiple devices / platforms, and it might be that the bug
> manifests itself only on a certain system that no one has tested
> beforehand; it's a typical case we often see after the releases.
> 
> > This will not happen if any
> > parts were missing.  The order in which the pieces are applied is
> > irrelevant if there aren't any build deps between them.  If you bisect
> > between them, then the driver simply will not build.  No problem.
> 
> The bisection is required not only for build errors but also for
> functional tests.  Sometimes it's the only way to spot the culprit of
> a functional regression.
> 
> Imagine the following case: both MFD and platform drivers are merged
> into individual trees separately.  And, some change in platform driver
> after this patch series broke some functionality mistakenly.
> 
> Now, suppose that the platform tree is merged to Linus tree before MFD
> tree, that is, the situation is like:
> 
>   MFD (commit A1) -- ... -------------------------+
>   platform (commit B1) -> broken change (B2) -+   |
>                                               v   v
>                                             --M1--M2--> Linus RC1
> 
> git-bisection can inspect M2, which shows already broken.  Then it
> inspects M1, but you can't evaluate it because the target platform
> driver can't be built without A1.  At this point, you're stuck.
> But in this case, B1 is correct and B2 is the culprit.  How can you
> spot it out?
> 
> OTOH, if the merge history honors the functional dependency, you can
> bisect properly.

Exactly and not only that.

If the git history reflects the logical dependencies between patches,
you should be able to figure out the reason why the code was changed
this way (sometimes you can't anyway if commit logs suck, for example,
but this is a different problem) which quite often is essential for
debugging, backporting and similar.

Thanks,
Rafael

Re: [PATCH v5 1/3] mfd: Add support for Cherry Trail Dollar Cove TI PMIC

[Lee Jones]

On Wed, 06 Sep 2017, Rafael J. Wysocki wrote:

> On Wednesday, September 6, 2017 12:06:50 PM CEST Takashi Iwai wrote:
> > On Wed, 06 Sep 2017 11:05:04 +0200,
> > Lee Jones wrote:
> > > 
> > > On Wed, 06 Sep 2017, Takashi Iwai wrote:
> > > 
> > > > On Wed, 06 Sep 2017 09:54:44 +0200,
> > > > Lee Jones wrote:
> > > > > 
> > > > > On Tue, 05 Sep 2017, Takashi Iwai wrote:
> > > > > 
> > > > > > On Tue, 05 Sep 2017 10:53:41 +0200,
> > > > > > Lee Jones wrote:
> > > > > > > 
> > > > > > > On Tue, 05 Sep 2017, Takashi Iwai wrote:
> > > > > > > 
> > > > > > > > On Tue, 05 Sep 2017 10:10:49 +0200,
> > > > > > > > Lee Jones wrote:
> > > > > > > > > 
> > > > > > > > > On Tue, 05 Sep 2017, Takashi Iwai wrote:
> > > > > > > > > 
> > > > > > > > > > On Tue, 05 Sep 2017 09:24:51 +0200,
> > > > > > > > > > Lee Jones wrote:
> > > > > > > > > > > 
> > > > > > > > > > > On Mon, 04 Sep 2017, Takashi Iwai wrote:
> > > > > > > > > > > 
> > > > > > > > > > > > This patch adds the MFD driver for Dollar Cove (TI version) PMIC with
> > > > > > > > > > > > ACPI INT33F5 that is found on some Intel Cherry Trail devices.
> > > > > > > > > > > > The driver is based on the original work by Intel, found at:
> > > > > > > > > > > >   https://github.com/01org/ProductionKernelQuilts
> > > > > > > > > > > > 
> > > > > > > > > > > > This is a minimal version for adding the basic resources.  Currently,
> > > > > > > > > > > > only ACPI PMIC opregion and the external power-button are used.
> > > > > > > > > > > > 
> > > > > > > > > > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891
> > > > > > > > > > > > Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> > > > > > > > > > > > Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> > > > > > > > > > > > Signed-off-by: Takashi Iwai <tiwai@suse.de>
> > > > > > > > > > > > ---
> > > > > > > > > > > > v4->v5:
> > > > > > > > > > > > * Minor coding-style fixes suggested by Lee
> > > > > > > > > > > > * Put GPL text
> > > > > > > > > > > > v3->v4:
> > > > > > > > > > > > * no change for this patch
> > > > > > > > > > > > v2->v3:
> > > > > > > > > > > > * Rename dc_ti with chtdc_ti in all places
> > > > > > > > > > > > * Driver/kconfig renames accordingly
> > > > > > > > > > > > * Added acks by Andy and Mika
> > > > > > > > > > > > v1->v2:
> > > > > > > > > > > > * Minor cleanups as suggested by Andy
> > > > > > > > > > > > 
> > > > > > > > > > > >  drivers/mfd/Kconfig                   |  13 +++
> > > > > > > > > > > >  drivers/mfd/Makefile                  |   1 +
> > > > > > > > > > > >  drivers/mfd/intel_soc_pmic_chtdc_ti.c | 184 ++++++++++++++++++++++++++++++++++
> > > > > > > > > > > >  3 files changed, 198 insertions(+)
> > > > > > > > > > > >  create mode 100644 drivers/mfd/intel_soc_pmic_chtdc_ti.c
> > > > > > > > > > > 
> > > > > > > > > > > For my own reference:
> > > > > > > > > > >   Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> > > > > > > > > > 
> > > > > > > > > > Thanks!
> > > > > > > > > > 
> > > > > > > > > > Now the question is how to deal with these.  It's no critical things,
> > > > > > > > > > so I'm OK to postpone for 4.15.  OTOH, it's really a new
> > > > > > > > > > device-specific stuff, thus it can't break anything else, and it'd be
> > > > > > > > > > fairly safe to add it for 4.14 although it's at a bit late stage.
> > > > > > > > > 
> > > > > > > > > Yes, you are over 2 weeks late for v4.14.  It will have to be v4.15.
> > > > > > > > 
> > > > > > > > OK, I'll ring your bells again once when 4.15 development is opened.
> > > > > > > > 
> > > > > > > > 
> > > > > > > > > > IMO, it'd be great if you can carry all stuff through MFD tree; or
> > > > > > > > > > create an immutable branch (again).  But how to handle it, when to do
> > > > > > > > > > it, It's all up to you guys.
> > > > > > > > > 
> > > > > > > > > If there aren't any build dependencies between the patches, each of
> > > > > > > > > the patches should be applied through their own trees.  What are the
> > > > > > > > > build-time dependencies?  Are there any?
> > > > > > > > 
> > > > > > > > No, there is no strict build-time dependency.  It's just that I don't
> > > > > > > > see it nice to have a commit for a dead code, partly for testing
> > > > > > > > purpose and partly for code consistency.  But if this makes
> > > > > > > > maintenance easier, I'm happy with that, too, of course.
> > > > > > > 
> > > > > > > There won't be any dead code.  All of the subsystem trees are pulled
> > > > > > > into -next [0] where the build bots can operate on the patches as a
> > > > > > > whole.
> > > > > > 
> > > > > > But the merge order isn't guaranteed, i.e. at the commit of other tree
> > > > > > for this new stuff, it's a dead code without merging the MFD stuff
> > > > > > beforehand.  e.g. Imagine to perform the git bisection.  It's not
> > > > > > about the whole tree, but about the each commit.
> > > > > 
> > > > > Only *building* is relevant for bisection until the whole feature
> > > > > lands.
> > > > 
> > > > Why only building?
> > > > 
> > > > When merging through several tress, commits for the same series are
> > > > scattered completely although they are softly tied.  This sucks when
> > > > you perform git bisection, e.g. if you have an issue in the middle of
> > > > the patch series.  It still works, but it jumps unnecessarily too far
> > > > away and back before reaching to the point, and kconfig appears /
> > > > disappears inconsistently (the dependent kconfig gone in the middle).
> > > > And, this is about the release kernel (4.15 or whatever).
> > > 
> > > Think about how bisection works.  You state a good commit and a bad
> > > one.  The good commit will be when the feature last worked, which will
> > > not be until the feature has fully landed.  Bisect will not check any
> > > point prior to this date.
> > > 
> > > If there aren't any build deps, each Maintainer will apply patches
> > > into their own tree.  These will be merged together in -next where
> > > they can be tested, both manually and by the 0-days.  Once the merge
> > > window is opened all patches will be sucked into -rc1.  If the feature
> > > works here, then it you could use -rc1 as your 'good' commit.  If it
> > > doesn't, then this could indicate a merge error or a missing piece of
> > > the set, either way bisect wouldn't help you.
> > 
> > Not really.
> > 
> > First of all, most of user start testing from the release kernel, so
> > you can't trust that RC covered all test cases.  (Who can blame users
> > who didn't use / test RC?)
> > 
> > Second, you ignore the fact that the development continues after
> > merging *this* patchset.  What if a breakage is introduced after this
> > patch?  (See below)
> > 
> > They often need a full bisection between the previous release and the
> > current release.
> > 
> > > > Basically, my complaint here comes with my user's hat on.  It *is*
> > > > indeed worse than a straight application of patches in some levels.
> > > > It's unavoidable if you do in that way.
> > > 
> > > I disagree.  I user wouldn't set the 'good' commit at any point prior
> > > to the feature working at least once.
> > 
> > Again no, not all users do test at the same time.  A device driver
> > may support multiple devices / platforms, and it might be that the bug
> > manifests itself only on a certain system that no one has tested
> > beforehand; it's a typical case we often see after the releases.
> > 
> > > This will not happen if any
> > > parts were missing.  The order in which the pieces are applied is
> > > irrelevant if there aren't any build deps between them.  If you bisect
> > > between them, then the driver simply will not build.  No problem.
> > 
> > The bisection is required not only for build errors but also for
> > functional tests.  Sometimes it's the only way to spot the culprit of
> > a functional regression.
> > 
> > Imagine the following case: both MFD and platform drivers are merged
> > into individual trees separately.  And, some change in platform driver
> > after this patch series broke some functionality mistakenly.
> > 
> > Now, suppose that the platform tree is merged to Linus tree before MFD
> > tree, that is, the situation is like:
> > 
> >   MFD (commit A1) -- ... -------------------------+
> >   platform (commit B1) -> broken change (B2) -+   |
> >                                               v   v
> >                                             --M1--M2--> Linus RC1
> > 
> > git-bisection can inspect M2, which shows already broken.  Then it
> > inspects M1, but you can't evaluate it because the target platform
> > driver can't be built without A1.  At this point, you're stuck.
> > But in this case, B1 is correct and B2 is the culprit.  How can you
> > spot it out?
> > 
> > OTOH, if the merge history honors the functional dependency, you can
> > bisect properly.
> 
> Exactly and not only that.
> 
> If the git history reflects the logical dependencies between patches,
> you should be able to figure out the reason why the code was changed
> this way (sometimes you can't anyway if commit logs suck, for example,
> but this is a different problem) which quite often is essential for
> debugging, backporting and similar.

The example you reference is a really small corner case (I don't
recall an occurrence) and is very easy to debug without bisect.  The
pros of taking patches in via their pre-defined subsystem trees far
outweighs the slight possibility and the debugging complexity of this
example.
 
-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v5 1/3] mfd: Add support for Cherry Trail Dollar Cove TI PMIC

[Lee Jones]

On Wed, 06 Sep 2017, Takashi Iwai wrote:

> On Wed, 06 Sep 2017 11:05:04 +0200,
> Lee Jones wrote:
> > 
> > On Wed, 06 Sep 2017, Takashi Iwai wrote:
> > 
> > > On Wed, 06 Sep 2017 09:54:44 +0200,
> > > Lee Jones wrote:
> > > > 
> > > > On Tue, 05 Sep 2017, Takashi Iwai wrote:
> > > > 
> > > > > On Tue, 05 Sep 2017 10:53:41 +0200,
> > > > > Lee Jones wrote:
> > > > > > 
> > > > > > On Tue, 05 Sep 2017, Takashi Iwai wrote:
> > > > > > 
> > > > > > > On Tue, 05 Sep 2017 10:10:49 +0200,
> > > > > > > Lee Jones wrote:
> > > > > > > > 
> > > > > > > > On Tue, 05 Sep 2017, Takashi Iwai wrote:
> > > > > > > > 
> > > > > > > > > On Tue, 05 Sep 2017 09:24:51 +0200,
> > > > > > > > > Lee Jones wrote:
> > > > > > > > > > 
> > > > > > > > > > On Mon, 04 Sep 2017, Takashi Iwai wrote:
> > > > > > > > > > 
> > > > > > > > > > > This patch adds the MFD driver for Dollar Cove (TI version) PMIC with
> > > > > > > > > > > ACPI INT33F5 that is found on some Intel Cherry Trail devices.
> > > > > > > > > > > The driver is based on the original work by Intel, found at:
> > > > > > > > > > >   https://github.com/01org/ProductionKernelQuilts
> > > > > > > > > > > 
> > > > > > > > > > > This is a minimal version for adding the basic resources.  Currently,
> > > > > > > > > > > only ACPI PMIC opregion and the external power-button are used.
> > > > > > > > > > > 
> > > > > > > > > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891
> > > > > > > > > > > Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> > > > > > > > > > > Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> > > > > > > > > > > Signed-off-by: Takashi Iwai <tiwai@suse.de>
> > > > > > > > > > > ---
> > > > > > > > > > > v4->v5:
> > > > > > > > > > > * Minor coding-style fixes suggested by Lee
> > > > > > > > > > > * Put GPL text
> > > > > > > > > > > v3->v4:
> > > > > > > > > > > * no change for this patch
> > > > > > > > > > > v2->v3:
> > > > > > > > > > > * Rename dc_ti with chtdc_ti in all places
> > > > > > > > > > > * Driver/kconfig renames accordingly
> > > > > > > > > > > * Added acks by Andy and Mika
> > > > > > > > > > > v1->v2:
> > > > > > > > > > > * Minor cleanups as suggested by Andy
> > > > > > > > > > > 
> > > > > > > > > > >  drivers/mfd/Kconfig                   |  13 +++
> > > > > > > > > > >  drivers/mfd/Makefile                  |   1 +
> > > > > > > > > > >  drivers/mfd/intel_soc_pmic_chtdc_ti.c | 184 ++++++++++++++++++++++++++++++++++
> > > > > > > > > > >  3 files changed, 198 insertions(+)
> > > > > > > > > > >  create mode 100644 drivers/mfd/intel_soc_pmic_chtdc_ti.c
> > > > > > > > > > 
> > > > > > > > > > For my own reference:
> > > > > > > > > >   Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> > > > > > > > > 
> > > > > > > > > Thanks!
> > > > > > > > > 
> > > > > > > > > Now the question is how to deal with these.  It's no critical things,
> > > > > > > > > so I'm OK to postpone for 4.15.  OTOH, it's really a new
> > > > > > > > > device-specific stuff, thus it can't break anything else, and it'd be
> > > > > > > > > fairly safe to add it for 4.14 although it's at a bit late stage.
> > > > > > > > 
> > > > > > > > Yes, you are over 2 weeks late for v4.14.  It will have to be v4.15.
> > > > > > > 
> > > > > > > OK, I'll ring your bells again once when 4.15 development is opened.
> > > > > > > 
> > > > > > > 
> > > > > > > > > IMO, it'd be great if you can carry all stuff through MFD tree; or
> > > > > > > > > create an immutable branch (again).  But how to handle it, when to do
> > > > > > > > > it, It's all up to you guys.
> > > > > > > > 
> > > > > > > > If there aren't any build dependencies between the patches, each of
> > > > > > > > the patches should be applied through their own trees.  What are the
> > > > > > > > build-time dependencies?  Are there any?
> > > > > > > 
> > > > > > > No, there is no strict build-time dependency.  It's just that I don't
> > > > > > > see it nice to have a commit for a dead code, partly for testing
> > > > > > > purpose and partly for code consistency.  But if this makes
> > > > > > > maintenance easier, I'm happy with that, too, of course.
> > > > > > 
> > > > > > There won't be any dead code.  All of the subsystem trees are pulled
> > > > > > into -next [0] where the build bots can operate on the patches as a
> > > > > > whole.
> > > > > 
> > > > > But the merge order isn't guaranteed, i.e. at the commit of other tree
> > > > > for this new stuff, it's a dead code without merging the MFD stuff
> > > > > beforehand.  e.g. Imagine to perform the git bisection.  It's not
> > > > > about the whole tree, but about the each commit.
> > > > 
> > > > Only *building* is relevant for bisection until the whole feature
> > > > lands.
> > > 
> > > Why only building?
> > > 
> > > When merging through several tress, commits for the same series are
> > > scattered completely although they are softly tied.  This sucks when
> > > you perform git bisection, e.g. if you have an issue in the middle of
> > > the patch series.  It still works, but it jumps unnecessarily too far
> > > away and back before reaching to the point, and kconfig appears /
> > > disappears inconsistently (the dependent kconfig gone in the middle).
> > > And, this is about the release kernel (4.15 or whatever).
> > 
> > Think about how bisection works.  You state a good commit and a bad
> > one.  The good commit will be when the feature last worked, which will
> > not be until the feature has fully landed.  Bisect will not check any
> > point prior to this date.
> > 
> > If there aren't any build deps, each Maintainer will apply patches
> > into their own tree.  These will be merged together in -next where
> > they can be tested, both manually and by the 0-days.  Once the merge
> > window is opened all patches will be sucked into -rc1.  If the feature
> > works here, then it you could use -rc1 as your 'good' commit.  If it
> > doesn't, then this could indicate a merge error or a missing piece of
> > the set, either way bisect wouldn't help you.
> 
> Not really.
> 
> First of all, most of user start testing from the release kernel, so
> you can't trust that RC covered all test cases.  (Who can blame users
> who didn't use / test RC?)

That's fine.  We are not talking about spreading the merge of a
patch-set over different releases, or even release candidates.  All
non-bugfix patches should be in by -rc1.

> Second, you ignore the fact that the development continues after
> merging *this* patchset.  What if a breakage is introduced after this
> patch?  (See below)
> 
> They often need a full bisection between the previous release and the
> current release.

You cannot bisect a specific function back before it was merged.  It's
impossible.

P1 ---> P4 ---> P3 ---> P2
                         ^
Bisect only starts working here.  Prior to this point the feature
doesn't build at all.  If it builds, but breaks, then that is a build
dependency and is a different use-case to what we are discussing here.

> > > Basically, my complaint here comes with my user's hat on.  It *is*
> > > indeed worse than a straight application of patches in some levels.
> > > It's unavoidable if you do in that way.
> > 
> > I disagree.  I user wouldn't set the 'good' commit at any point prior
> > to the feature working at least once.
> 
> Again no, not all users do test at the same time.  A device driver
> may support multiple devices / platforms, and it might be that the bug
> manifests itself only on a certain system that no one has tested
> beforehand; it's a typical case we often see after the releases.

If it is possible for a patch-set to break functionality, then again,
this is a dependency and needs to be handled differently.

That is not the case with your set.

> > This will not happen if any
> > parts were missing.  The order in which the pieces are applied is
> > irrelevant if there aren't any build deps between them.  If you bisect
> > between them, then the driver simply will not build.  No problem.
> 
> The bisection is required not only for build errors but also for
> functional tests.  Sometimes it's the only way to spot the culprit of
> a functional regression.
> 
> Imagine the following case: both MFD and platform drivers are merged
> into individual trees separately.  And, some change in platform driver
> after this patch series broke some functionality mistakenly.
> 
> Now, suppose that the platform tree is merged to Linus tree before MFD
> tree, that is, the situation is like:
> 
>   MFD (commit A1) -- ... -------------------------+
>   platform (commit B1) -> broken change (B2) -+   |
>                                               v   v
>                                             --M1--M2--> Linus RC1
>
> git-bisection can inspect M2, which shows already broken.  Then it
> inspects M1, but you can't evaluate it because the target platform
> driver can't be built without A1.  At this point, you're stuck.
> But in this case, B1 is correct and B2 is the culprit.  How can you
> spot it out?
>
> OTOH, if the merge history honors the functional dependency, you can
> bisect properly.

You wouldn't use bisect for that use-case.  We only use bisect for
features that have a working commit in Mainline.  The use-case you
mention would be pretty trivial to debug without bisect.

When we tout "history must be bisectable", we mean that it must remain
possible to bisect existing functionality.  Bisecting functionality
which is yet to fully land upstream is foolish.

New drivers almost never (if ever) go in as a fully working piece.
The registration parts (DT, Platform, etc) go in via one (or several)
tree(s) and the driver parts are normally split up into subsystems and
go in via their own repos.  If there are *build*, *API* or *merge*
time dependencies, then we can use immutable branches and merge via
a single tree.  Failing that, we split them.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v5 1/3] mfd: Add support for Cherry Trail Dollar Cove TI PMIC

[Takashi Iwai]

On Wed, 06 Sep 2017 12:40:40 +0200,
Lee Jones wrote:
> 
> On Wed, 06 Sep 2017, Takashi Iwai wrote:
> 
> > On Wed, 06 Sep 2017 11:05:04 +0200,
> > Lee Jones wrote:
> > > 
> > > On Wed, 06 Sep 2017, Takashi Iwai wrote:
> > > 
> > > > On Wed, 06 Sep 2017 09:54:44 +0200,
> > > > Lee Jones wrote:
> > > > > 
> > > > > On Tue, 05 Sep 2017, Takashi Iwai wrote:
> > > > > 
> > > > > > On Tue, 05 Sep 2017 10:53:41 +0200,
> > > > > > Lee Jones wrote:
> > > > > > > 
> > > > > > > On Tue, 05 Sep 2017, Takashi Iwai wrote:
> > > > > > > 
> > > > > > > > On Tue, 05 Sep 2017 10:10:49 +0200,
> > > > > > > > Lee Jones wrote:
> > > > > > > > > 
> > > > > > > > > On Tue, 05 Sep 2017, Takashi Iwai wrote:
> > > > > > > > > 
> > > > > > > > > > On Tue, 05 Sep 2017 09:24:51 +0200,
> > > > > > > > > > Lee Jones wrote:
> > > > > > > > > > > 
> > > > > > > > > > > On Mon, 04 Sep 2017, Takashi Iwai wrote:
> > > > > > > > > > > 
> > > > > > > > > > > > This patch adds the MFD driver for Dollar Cove (TI version) PMIC with
> > > > > > > > > > > > ACPI INT33F5 that is found on some Intel Cherry Trail devices.
> > > > > > > > > > > > The driver is based on the original work by Intel, found at:
> > > > > > > > > > > >   https://github.com/01org/ProductionKernelQuilts
> > > > > > > > > > > > 
> > > > > > > > > > > > This is a minimal version for adding the basic resources.  Currently,
> > > > > > > > > > > > only ACPI PMIC opregion and the external power-button are used.
> > > > > > > > > > > > 
> > > > > > > > > > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891
> > > > > > > > > > > > Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> > > > > > > > > > > > Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> > > > > > > > > > > > Signed-off-by: Takashi Iwai <tiwai@suse.de>
> > > > > > > > > > > > ---
> > > > > > > > > > > > v4->v5:
> > > > > > > > > > > > * Minor coding-style fixes suggested by Lee
> > > > > > > > > > > > * Put GPL text
> > > > > > > > > > > > v3->v4:
> > > > > > > > > > > > * no change for this patch
> > > > > > > > > > > > v2->v3:
> > > > > > > > > > > > * Rename dc_ti with chtdc_ti in all places
> > > > > > > > > > > > * Driver/kconfig renames accordingly
> > > > > > > > > > > > * Added acks by Andy and Mika
> > > > > > > > > > > > v1->v2:
> > > > > > > > > > > > * Minor cleanups as suggested by Andy
> > > > > > > > > > > > 
> > > > > > > > > > > >  drivers/mfd/Kconfig                   |  13 +++
> > > > > > > > > > > >  drivers/mfd/Makefile                  |   1 +
> > > > > > > > > > > >  drivers/mfd/intel_soc_pmic_chtdc_ti.c | 184 ++++++++++++++++++++++++++++++++++
> > > > > > > > > > > >  3 files changed, 198 insertions(+)
> > > > > > > > > > > >  create mode 100644 drivers/mfd/intel_soc_pmic_chtdc_ti.c
> > > > > > > > > > > 
> > > > > > > > > > > For my own reference:
> > > > > > > > > > >   Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> > > > > > > > > > 
> > > > > > > > > > Thanks!
> > > > > > > > > > 
> > > > > > > > > > Now the question is how to deal with these.  It's no critical things,
> > > > > > > > > > so I'm OK to postpone for 4.15.  OTOH, it's really a new
> > > > > > > > > > device-specific stuff, thus it can't break anything else, and it'd be
> > > > > > > > > > fairly safe to add it for 4.14 although it's at a bit late stage.
> > > > > > > > > 
> > > > > > > > > Yes, you are over 2 weeks late for v4.14.  It will have to be v4.15.
> > > > > > > > 
> > > > > > > > OK, I'll ring your bells again once when 4.15 development is opened.
> > > > > > > > 
> > > > > > > > 
> > > > > > > > > > IMO, it'd be great if you can carry all stuff through MFD tree; or
> > > > > > > > > > create an immutable branch (again).  But how to handle it, when to do
> > > > > > > > > > it, It's all up to you guys.
> > > > > > > > > 
> > > > > > > > > If there aren't any build dependencies between the patches, each of
> > > > > > > > > the patches should be applied through their own trees.  What are the
> > > > > > > > > build-time dependencies?  Are there any?
> > > > > > > > 
> > > > > > > > No, there is no strict build-time dependency.  It's just that I don't
> > > > > > > > see it nice to have a commit for a dead code, partly for testing
> > > > > > > > purpose and partly for code consistency.  But if this makes
> > > > > > > > maintenance easier, I'm happy with that, too, of course.
> > > > > > > 
> > > > > > > There won't be any dead code.  All of the subsystem trees are pulled
> > > > > > > into -next [0] where the build bots can operate on the patches as a
> > > > > > > whole.
> > > > > > 
> > > > > > But the merge order isn't guaranteed, i.e. at the commit of other tree
> > > > > > for this new stuff, it's a dead code without merging the MFD stuff
> > > > > > beforehand.  e.g. Imagine to perform the git bisection.  It's not
> > > > > > about the whole tree, but about the each commit.
> > > > > 
> > > > > Only *building* is relevant for bisection until the whole feature
> > > > > lands.
> > > > 
> > > > Why only building?
> > > > 
> > > > When merging through several tress, commits for the same series are
> > > > scattered completely although they are softly tied.  This sucks when
> > > > you perform git bisection, e.g. if you have an issue in the middle of
> > > > the patch series.  It still works, but it jumps unnecessarily too far
> > > > away and back before reaching to the point, and kconfig appears /
> > > > disappears inconsistently (the dependent kconfig gone in the middle).
> > > > And, this is about the release kernel (4.15 or whatever).
> > > 
> > > Think about how bisection works.  You state a good commit and a bad
> > > one.  The good commit will be when the feature last worked, which will
> > > not be until the feature has fully landed.  Bisect will not check any
> > > point prior to this date.
> > > 
> > > If there aren't any build deps, each Maintainer will apply patches
> > > into their own tree.  These will be merged together in -next where
> > > they can be tested, both manually and by the 0-days.  Once the merge
> > > window is opened all patches will be sucked into -rc1.  If the feature
> > > works here, then it you could use -rc1 as your 'good' commit.  If it
> > > doesn't, then this could indicate a merge error or a missing piece of
> > > the set, either way bisect wouldn't help you.
> > 
> > Not really.
> > 
> > First of all, most of user start testing from the release kernel, so
> > you can't trust that RC covered all test cases.  (Who can blame users
> > who didn't use / test RC?)
> 
> That's fine.  We are not talking about spreading the merge of a
> patch-set over different releases, or even release candidates.  All
> non-bugfix patches should be in by -rc1.
> 
> > Second, you ignore the fact that the development continues after
> > merging *this* patchset.  What if a breakage is introduced after this
> > patch?  (See below)
> > 
> > They often need a full bisection between the previous release and the
> > current release.
> 
> You cannot bisect a specific function back before it was merged.  It's
> impossible.
> 
> P1 ---> P4 ---> P3 ---> P2
>                          ^
> Bisect only starts working here.  Prior to this point the feature
> doesn't build at all.  If it builds, but breaks, then that is a build
> dependency and is a different use-case to what we are discussing here.

OK, let me rephrase.  With the scenario above, user *cannot* perform
bisect.  Meanwhile, with the straight merge, you can bisect a
breakage.  That's a significant difference.

I.e. in the case where both commits A1, B1 and B2 are merged through
tree A an B.  B2 is the breakage.  With separate tree merges, you
cannot bisect, while the straight merge allows you to bisect B2.


Takashi

Re: [PATCH v5 1/3] mfd: Add support for Cherry Trail Dollar Cove TI PMIC

[Rafael J. Wysocki]

On Wednesday, September 6, 2017 12:58:55 PM CEST Takashi Iwai wrote:
> On Wed, 06 Sep 2017 12:40:40 +0200,
> Lee Jones wrote:
> > 
> > On Wed, 06 Sep 2017, Takashi Iwai wrote:
> > 
> > > On Wed, 06 Sep 2017 11:05:04 +0200,
> > > Lee Jones wrote:
> > > > 
> > > > On Wed, 06 Sep 2017, Takashi Iwai wrote:
> > > > 
> > > > > On Wed, 06 Sep 2017 09:54:44 +0200,
> > > > > Lee Jones wrote:
> > > > > > 
> > > > > > On Tue, 05 Sep 2017, Takashi Iwai wrote:
> > > > > > 
> > > > > > > On Tue, 05 Sep 2017 10:53:41 +0200,
> > > > > > > Lee Jones wrote:
> > > > > > > > 
> > > > > > > > On Tue, 05 Sep 2017, Takashi Iwai wrote:
> > > > > > > > 
> > > > > > > > > On Tue, 05 Sep 2017 10:10:49 +0200,
> > > > > > > > > Lee Jones wrote:
> > > > > > > > > > 
> > > > > > > > > > On Tue, 05 Sep 2017, Takashi Iwai wrote:
> > > > > > > > > > 
> > > > > > > > > > > On Tue, 05 Sep 2017 09:24:51 +0200,
> > > > > > > > > > > Lee Jones wrote:
> > > > > > > > > > > > 
> > > > > > > > > > > > On Mon, 04 Sep 2017, Takashi Iwai wrote:
> > > > > > > > > > > > 
> > > > > > > > > > > > > This patch adds the MFD driver for Dollar Cove (TI version) PMIC with
> > > > > > > > > > > > > ACPI INT33F5 that is found on some Intel Cherry Trail devices.
> > > > > > > > > > > > > The driver is based on the original work by Intel, found at:
> > > > > > > > > > > > >   https://github.com/01org/ProductionKernelQuilts
> > > > > > > > > > > > > 
> > > > > > > > > > > > > This is a minimal version for adding the basic resources.  Currently,
> > > > > > > > > > > > > only ACPI PMIC opregion and the external power-button are used.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891
> > > > > > > > > > > > > Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> > > > > > > > > > > > > Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> > > > > > > > > > > > > Signed-off-by: Takashi Iwai <tiwai@suse.de>
> > > > > > > > > > > > > ---
> > > > > > > > > > > > > v4->v5:
> > > > > > > > > > > > > * Minor coding-style fixes suggested by Lee
> > > > > > > > > > > > > * Put GPL text
> > > > > > > > > > > > > v3->v4:
> > > > > > > > > > > > > * no change for this patch
> > > > > > > > > > > > > v2->v3:
> > > > > > > > > > > > > * Rename dc_ti with chtdc_ti in all places
> > > > > > > > > > > > > * Driver/kconfig renames accordingly
> > > > > > > > > > > > > * Added acks by Andy and Mika
> > > > > > > > > > > > > v1->v2:
> > > > > > > > > > > > > * Minor cleanups as suggested by Andy
> > > > > > > > > > > > > 
> > > > > > > > > > > > >  drivers/mfd/Kconfig                   |  13 +++
> > > > > > > > > > > > >  drivers/mfd/Makefile                  |   1 +
> > > > > > > > > > > > >  drivers/mfd/intel_soc_pmic_chtdc_ti.c | 184 ++++++++++++++++++++++++++++++++++
> > > > > > > > > > > > >  3 files changed, 198 insertions(+)
> > > > > > > > > > > > >  create mode 100644 drivers/mfd/intel_soc_pmic_chtdc_ti.c
> > > > > > > > > > > > 
> > > > > > > > > > > > For my own reference:
> > > > > > > > > > > >   Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> > > > > > > > > > > 
> > > > > > > > > > > Thanks!
> > > > > > > > > > > 
> > > > > > > > > > > Now the question is how to deal with these.  It's no critical things,
> > > > > > > > > > > so I'm OK to postpone for 4.15.  OTOH, it's really a new
> > > > > > > > > > > device-specific stuff, thus it can't break anything else, and it'd be
> > > > > > > > > > > fairly safe to add it for 4.14 although it's at a bit late stage.
> > > > > > > > > > 
> > > > > > > > > > Yes, you are over 2 weeks late for v4.14.  It will have to be v4.15.
> > > > > > > > > 
> > > > > > > > > OK, I'll ring your bells again once when 4.15 development is opened.
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > > > IMO, it'd be great if you can carry all stuff through MFD tree; or
> > > > > > > > > > > create an immutable branch (again).  But how to handle it, when to do
> > > > > > > > > > > it, It's all up to you guys.
> > > > > > > > > > 
> > > > > > > > > > If there aren't any build dependencies between the patches, each of
> > > > > > > > > > the patches should be applied through their own trees.  What are the
> > > > > > > > > > build-time dependencies?  Are there any?
> > > > > > > > > 
> > > > > > > > > No, there is no strict build-time dependency.  It's just that I don't
> > > > > > > > > see it nice to have a commit for a dead code, partly for testing
> > > > > > > > > purpose and partly for code consistency.  But if this makes
> > > > > > > > > maintenance easier, I'm happy with that, too, of course.
> > > > > > > > 
> > > > > > > > There won't be any dead code.  All of the subsystem trees are pulled
> > > > > > > > into -next [0] where the build bots can operate on the patches as a
> > > > > > > > whole.
> > > > > > > 
> > > > > > > But the merge order isn't guaranteed, i.e. at the commit of other tree
> > > > > > > for this new stuff, it's a dead code without merging the MFD stuff
> > > > > > > beforehand.  e.g. Imagine to perform the git bisection.  It's not
> > > > > > > about the whole tree, but about the each commit.
> > > > > > 
> > > > > > Only *building* is relevant for bisection until the whole feature
> > > > > > lands.
> > > > > 
> > > > > Why only building?
> > > > > 
> > > > > When merging through several tress, commits for the same series are
> > > > > scattered completely although they are softly tied.  This sucks when
> > > > > you perform git bisection, e.g. if you have an issue in the middle of
> > > > > the patch series.  It still works, but it jumps unnecessarily too far
> > > > > away and back before reaching to the point, and kconfig appears /
> > > > > disappears inconsistently (the dependent kconfig gone in the middle).
> > > > > And, this is about the release kernel (4.15 or whatever).
> > > > 
> > > > Think about how bisection works.  You state a good commit and a bad
> > > > one.  The good commit will be when the feature last worked, which will
> > > > not be until the feature has fully landed.  Bisect will not check any
> > > > point prior to this date.
> > > > 
> > > > If there aren't any build deps, each Maintainer will apply patches
> > > > into their own tree.  These will be merged together in -next where
> > > > they can be tested, both manually and by the 0-days.  Once the merge
> > > > window is opened all patches will be sucked into -rc1.  If the feature
> > > > works here, then it you could use -rc1 as your 'good' commit.  If it
> > > > doesn't, then this could indicate a merge error or a missing piece of
> > > > the set, either way bisect wouldn't help you.
> > > 
> > > Not really.
> > > 
> > > First of all, most of user start testing from the release kernel, so
> > > you can't trust that RC covered all test cases.  (Who can blame users
> > > who didn't use / test RC?)
> > 
> > That's fine.  We are not talking about spreading the merge of a
> > patch-set over different releases, or even release candidates.  All
> > non-bugfix patches should be in by -rc1.
> > 
> > > Second, you ignore the fact that the development continues after
> > > merging *this* patchset.  What if a breakage is introduced after this
> > > patch?  (See below)
> > > 
> > > They often need a full bisection between the previous release and the
> > > current release.
> > 
> > You cannot bisect a specific function back before it was merged.  It's
> > impossible.
> > 
> > P1 ---> P4 ---> P3 ---> P2
> >                          ^
> > Bisect only starts working here.  Prior to this point the feature
> > doesn't build at all.  If it builds, but breaks, then that is a build
> > dependency and is a different use-case to what we are discussing here.
> 
> OK, let me rephrase.  With the scenario above, user *cannot* perform
> bisect.  Meanwhile, with the straight merge, you can bisect a
> breakage.  That's a significant difference.
> 
> I.e. in the case where both commits A1, B1 and B2 are merged through
> tree A an B.  B2 is the breakage.  With separate tree merges, you
> cannot bisect, while the straight merge allows you to bisect B2.

Right, and that's really fundamental, because then the user can tell you
"look, this commit doesn't work for me" instead of just "this kernel
doesn't work for me" and now you need to spend *your* time on trying to
figure out which commit may be at fault.

So speaking of benefits, I really prefer to avoid spending my time on
such things. :-)

Thanks,
Rafael

Re: [PATCH v5 1/3] mfd: Add support for Cherry Trail Dollar Cove TI PMIC

[Lee Jones]

On Wed, 06 Sep 2017, Rafael J. Wysocki wrote:

> On Wednesday, September 6, 2017 12:58:55 PM CEST Takashi Iwai wrote:
> > On Wed, 06 Sep 2017 12:40:40 +0200,
> > Lee Jones wrote:
> > > 
> > > On Wed, 06 Sep 2017, Takashi Iwai wrote:
> > > 
> > > > On Wed, 06 Sep 2017 11:05:04 +0200,
> > > > Lee Jones wrote:
> > > > > 
> > > > > On Wed, 06 Sep 2017, Takashi Iwai wrote:
> > > > > 
> > > > > > On Wed, 06 Sep 2017 09:54:44 +0200,
> > > > > > Lee Jones wrote:
> > > > > > > 
> > > > > > > On Tue, 05 Sep 2017, Takashi Iwai wrote:
> > > > > > > 
> > > > > > > > On Tue, 05 Sep 2017 10:53:41 +0200,
> > > > > > > > Lee Jones wrote:
> > > > > > > > > 
> > > > > > > > > On Tue, 05 Sep 2017, Takashi Iwai wrote:
> > > > > > > > > 
> > > > > > > > > > On Tue, 05 Sep 2017 10:10:49 +0200,
> > > > > > > > > > Lee Jones wrote:
> > > > > > > > > > > 
> > > > > > > > > > > On Tue, 05 Sep 2017, Takashi Iwai wrote:
> > > > > > > > > > > 
> > > > > > > > > > > > On Tue, 05 Sep 2017 09:24:51 +0200,
> > > > > > > > > > > > Lee Jones wrote:
> > > > > > > > > > > > > 
> > > > > > > > > > > > > On Mon, 04 Sep 2017, Takashi Iwai wrote:
> > > > > > > > > > > > > 
> > > > > > > > > > > > > > This patch adds the MFD driver for Dollar Cove (TI version) PMIC with
> > > > > > > > > > > > > > ACPI INT33F5 that is found on some Intel Cherry Trail devices.
> > > > > > > > > > > > > > The driver is based on the original work by Intel, found at:
> > > > > > > > > > > > > >   https://github.com/01org/ProductionKernelQuilts
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > This is a minimal version for adding the basic resources.  Currently,
> > > > > > > > > > > > > > only ACPI PMIC opregion and the external power-button are used.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891
> > > > > > > > > > > > > > Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> > > > > > > > > > > > > > Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> > > > > > > > > > > > > > Signed-off-by: Takashi Iwai <tiwai@suse.de>
> > > > > > > > > > > > > > ---
> > > > > > > > > > > > > > v4->v5:
> > > > > > > > > > > > > > * Minor coding-style fixes suggested by Lee
> > > > > > > > > > > > > > * Put GPL text
> > > > > > > > > > > > > > v3->v4:
> > > > > > > > > > > > > > * no change for this patch
> > > > > > > > > > > > > > v2->v3:
> > > > > > > > > > > > > > * Rename dc_ti with chtdc_ti in all places
> > > > > > > > > > > > > > * Driver/kconfig renames accordingly
> > > > > > > > > > > > > > * Added acks by Andy and Mika
> > > > > > > > > > > > > > v1->v2:
> > > > > > > > > > > > > > * Minor cleanups as suggested by Andy
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > >  drivers/mfd/Kconfig                   |  13 +++
> > > > > > > > > > > > > >  drivers/mfd/Makefile                  |   1 +
> > > > > > > > > > > > > >  drivers/mfd/intel_soc_pmic_chtdc_ti.c | 184 ++++++++++++++++++++++++++++++++++
> > > > > > > > > > > > > >  3 files changed, 198 insertions(+)
> > > > > > > > > > > > > >  create mode 100644 drivers/mfd/intel_soc_pmic_chtdc_ti.c
> > > > > > > > > > > > > 
> > > > > > > > > > > > > For my own reference:
> > > > > > > > > > > > >   Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> > > > > > > > > > > > 
> > > > > > > > > > > > Thanks!
> > > > > > > > > > > > 
> > > > > > > > > > > > Now the question is how to deal with these.  It's no critical things,
> > > > > > > > > > > > so I'm OK to postpone for 4.15.  OTOH, it's really a new
> > > > > > > > > > > > device-specific stuff, thus it can't break anything else, and it'd be
> > > > > > > > > > > > fairly safe to add it for 4.14 although it's at a bit late stage.
> > > > > > > > > > > 
> > > > > > > > > > > Yes, you are over 2 weeks late for v4.14.  It will have to be v4.15.
> > > > > > > > > > 
> > > > > > > > > > OK, I'll ring your bells again once when 4.15 development is opened.
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > > > IMO, it'd be great if you can carry all stuff through MFD tree; or
> > > > > > > > > > > > create an immutable branch (again).  But how to handle it, when to do
> > > > > > > > > > > > it, It's all up to you guys.
> > > > > > > > > > > 
> > > > > > > > > > > If there aren't any build dependencies between the patches, each of
> > > > > > > > > > > the patches should be applied through their own trees.  What are the
> > > > > > > > > > > build-time dependencies?  Are there any?
> > > > > > > > > > 
> > > > > > > > > > No, there is no strict build-time dependency.  It's just that I don't
> > > > > > > > > > see it nice to have a commit for a dead code, partly for testing
> > > > > > > > > > purpose and partly for code consistency.  But if this makes
> > > > > > > > > > maintenance easier, I'm happy with that, too, of course.
> > > > > > > > > 
> > > > > > > > > There won't be any dead code.  All of the subsystem trees are pulled
> > > > > > > > > into -next [0] where the build bots can operate on the patches as a
> > > > > > > > > whole.
> > > > > > > > 
> > > > > > > > But the merge order isn't guaranteed, i.e. at the commit of other tree
> > > > > > > > for this new stuff, it's a dead code without merging the MFD stuff
> > > > > > > > beforehand.  e.g. Imagine to perform the git bisection.  It's not
> > > > > > > > about the whole tree, but about the each commit.
> > > > > > > 
> > > > > > > Only *building* is relevant for bisection until the whole feature
> > > > > > > lands.
> > > > > > 
> > > > > > Why only building?
> > > > > > 
> > > > > > When merging through several tress, commits for the same series are
> > > > > > scattered completely although they are softly tied.  This sucks when
> > > > > > you perform git bisection, e.g. if you have an issue in the middle of
> > > > > > the patch series.  It still works, but it jumps unnecessarily too far
> > > > > > away and back before reaching to the point, and kconfig appears /
> > > > > > disappears inconsistently (the dependent kconfig gone in the middle).
> > > > > > And, this is about the release kernel (4.15 or whatever).
> > > > > 
> > > > > Think about how bisection works.  You state a good commit and a bad
> > > > > one.  The good commit will be when the feature last worked, which will
> > > > > not be until the feature has fully landed.  Bisect will not check any
> > > > > point prior to this date.
> > > > > 
> > > > > If there aren't any build deps, each Maintainer will apply patches
> > > > > into their own tree.  These will be merged together in -next where
> > > > > they can be tested, both manually and by the 0-days.  Once the merge
> > > > > window is opened all patches will be sucked into -rc1.  If the feature
> > > > > works here, then it you could use -rc1 as your 'good' commit.  If it
> > > > > doesn't, then this could indicate a merge error or a missing piece of
> > > > > the set, either way bisect wouldn't help you.
> > > > 
> > > > Not really.
> > > > 
> > > > First of all, most of user start testing from the release kernel, so
> > > > you can't trust that RC covered all test cases.  (Who can blame users
> > > > who didn't use / test RC?)
> > > 
> > > That's fine.  We are not talking about spreading the merge of a
> > > patch-set over different releases, or even release candidates.  All
> > > non-bugfix patches should be in by -rc1.
> > > 
> > > > Second, you ignore the fact that the development continues after
> > > > merging *this* patchset.  What if a breakage is introduced after this
> > > > patch?  (See below)
> > > > 
> > > > They often need a full bisection between the previous release and the
> > > > current release.
> > > 
> > > You cannot bisect a specific function back before it was merged.  It's
> > > impossible.
> > > 
> > > P1 ---> P4 ---> P3 ---> P2
> > >                          ^
> > > Bisect only starts working here.  Prior to this point the feature
> > > doesn't build at all.  If it builds, but breaks, then that is a build
> > > dependency and is a different use-case to what we are discussing here.
> > 
> > OK, let me rephrase.  With the scenario above, user *cannot* perform
> > bisect.  Meanwhile, with the straight merge, you can bisect a
> > breakage.  That's a significant difference.
> > 
> > I.e. in the case where both commits A1, B1 and B2 are merged through
> > tree A an B.  B2 is the breakage.  With separate tree merges, you
> > cannot bisect, while the straight merge allows you to bisect B2.
> 
> Right, and that's really fundamental, because then the user can tell you
> "look, this commit doesn't work for me" instead of just "this kernel
> doesn't work for me" and now you need to spend *your* time on trying to
> figure out which commit may be at fault.
> 
> So speaking of benefits, I really prefer to avoid spending my time on
> such things. :-)

The toss-up is between splitting the patch-set up and *maybe* spending
time on debugging in the small chance of this occurring OR
*definitely* spending time creating immutable branches and sending out
pull-requests in the *hope* that all the other Maintainers involved
are diligent enough to merge it in order to avoid conflicts during
merge time.

In the circles I spend time in ("we"), the former is the favourite.

Until this point (and from this point going forward) we have taken the
decision that the default is to take individual patches through their
own trees.  The only time this differs (unless other arrangements are
made e.g. PATCH 3/3) is when there are; build, merge or API
dependencies between them.  The same stance is taken with
driver/platform data and driver/other driver.

Let me put one of the issues into context:

For those reading along that do not know, Multi-Functional Devices are
usually single pieces of silicon which provide many functions
(e.g. LED Controllers, Voltage Regulation, Power Management, Sensors,
Timers, GPIO/Pinctrl Controllers, Watchdog Timers, Real-Time Clocks,
etc etc).  The driver which sits in drivers/mfd acts as the parent
device and registers its children which live in their own subsystems.

Almost all of the patch-sets I receive touch multiple subsystems.
Moreover, when the recently described dependencies occur, it is
usually I who creates the immutable branches and sends out the
pull-requests.

If I had to go through the immutable branch/pull-request process for
every patch-set I receive, there would be very little time to conduct
duties pertaining to my proper job.  Ergo, why we apply our own
patches, unless there is a good reason (already described) to apply
others too.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v5 1/3] mfd: Add support for Cherry Trail Dollar Cove TI PMIC

[Takashi Iwai]

On Wed, 06 Sep 2017 15:51:13 +0200,
Lee Jones wrote:
> 
> On Wed, 06 Sep 2017, Rafael J. Wysocki wrote:
> 
> > On Wednesday, September 6, 2017 12:58:55 PM CEST Takashi Iwai wrote:
> > > On Wed, 06 Sep 2017 12:40:40 +0200,
> > > Lee Jones wrote:
> > > > 
> > > > On Wed, 06 Sep 2017, Takashi Iwai wrote:
> > > > 
> > > > > On Wed, 06 Sep 2017 11:05:04 +0200,
> > > > > Lee Jones wrote:
> > > > > > 
> > > > > > On Wed, 06 Sep 2017, Takashi Iwai wrote:
> > > > > > 
> > > > > > > On Wed, 06 Sep 2017 09:54:44 +0200,
> > > > > > > Lee Jones wrote:
> > > > > > > > 
> > > > > > > > On Tue, 05 Sep 2017, Takashi Iwai wrote:
> > > > > > > > 
> > > > > > > > > On Tue, 05 Sep 2017 10:53:41 +0200,
> > > > > > > > > Lee Jones wrote:
> > > > > > > > > > 
> > > > > > > > > > On Tue, 05 Sep 2017, Takashi Iwai wrote:
> > > > > > > > > > 
> > > > > > > > > > > On Tue, 05 Sep 2017 10:10:49 +0200,
> > > > > > > > > > > Lee Jones wrote:
> > > > > > > > > > > > 
> > > > > > > > > > > > On Tue, 05 Sep 2017, Takashi Iwai wrote:
> > > > > > > > > > > > 
> > > > > > > > > > > > > On Tue, 05 Sep 2017 09:24:51 +0200,
> > > > > > > > > > > > > Lee Jones wrote:
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > On Mon, 04 Sep 2017, Takashi Iwai wrote:
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > This patch adds the MFD driver for Dollar Cove (TI version) PMIC with
> > > > > > > > > > > > > > > ACPI INT33F5 that is found on some Intel Cherry Trail devices.
> > > > > > > > > > > > > > > The driver is based on the original work by Intel, found at:
> > > > > > > > > > > > > > >   https://github.com/01org/ProductionKernelQuilts
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > This is a minimal version for adding the basic resources.  Currently,
> > > > > > > > > > > > > > > only ACPI PMIC opregion and the external power-button are used.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891
> > > > > > > > > > > > > > > Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> > > > > > > > > > > > > > > Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> > > > > > > > > > > > > > > Signed-off-by: Takashi Iwai <tiwai@suse.de>
> > > > > > > > > > > > > > > ---
> > > > > > > > > > > > > > > v4->v5:
> > > > > > > > > > > > > > > * Minor coding-style fixes suggested by Lee
> > > > > > > > > > > > > > > * Put GPL text
> > > > > > > > > > > > > > > v3->v4:
> > > > > > > > > > > > > > > * no change for this patch
> > > > > > > > > > > > > > > v2->v3:
> > > > > > > > > > > > > > > * Rename dc_ti with chtdc_ti in all places
> > > > > > > > > > > > > > > * Driver/kconfig renames accordingly
> > > > > > > > > > > > > > > * Added acks by Andy and Mika
> > > > > > > > > > > > > > > v1->v2:
> > > > > > > > > > > > > > > * Minor cleanups as suggested by Andy
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > >  drivers/mfd/Kconfig                   |  13 +++
> > > > > > > > > > > > > > >  drivers/mfd/Makefile                  |   1 +
> > > > > > > > > > > > > > >  drivers/mfd/intel_soc_pmic_chtdc_ti.c | 184 ++++++++++++++++++++++++++++++++++
> > > > > > > > > > > > > > >  3 files changed, 198 insertions(+)
> > > > > > > > > > > > > > >  create mode 100644 drivers/mfd/intel_soc_pmic_chtdc_ti.c
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > For my own reference:
> > > > > > > > > > > > > >   Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Thanks!
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Now the question is how to deal with these.  It's no critical things,
> > > > > > > > > > > > > so I'm OK to postpone for 4.15.  OTOH, it's really a new
> > > > > > > > > > > > > device-specific stuff, thus it can't break anything else, and it'd be
> > > > > > > > > > > > > fairly safe to add it for 4.14 although it's at a bit late stage.
> > > > > > > > > > > > 
> > > > > > > > > > > > Yes, you are over 2 weeks late for v4.14.  It will have to be v4.15.
> > > > > > > > > > > 
> > > > > > > > > > > OK, I'll ring your bells again once when 4.15 development is opened.
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > > > IMO, it'd be great if you can carry all stuff through MFD tree; or
> > > > > > > > > > > > > create an immutable branch (again).  But how to handle it, when to do
> > > > > > > > > > > > > it, It's all up to you guys.
> > > > > > > > > > > > 
> > > > > > > > > > > > If there aren't any build dependencies between the patches, each of
> > > > > > > > > > > > the patches should be applied through their own trees.  What are the
> > > > > > > > > > > > build-time dependencies?  Are there any?
> > > > > > > > > > > 
> > > > > > > > > > > No, there is no strict build-time dependency.  It's just that I don't
> > > > > > > > > > > see it nice to have a commit for a dead code, partly for testing
> > > > > > > > > > > purpose and partly for code consistency.  But if this makes
> > > > > > > > > > > maintenance easier, I'm happy with that, too, of course.
> > > > > > > > > > 
> > > > > > > > > > There won't be any dead code.  All of the subsystem trees are pulled
> > > > > > > > > > into -next [0] where the build bots can operate on the patches as a
> > > > > > > > > > whole.
> > > > > > > > > 
> > > > > > > > > But the merge order isn't guaranteed, i.e. at the commit of other tree
> > > > > > > > > for this new stuff, it's a dead code without merging the MFD stuff
> > > > > > > > > beforehand.  e.g. Imagine to perform the git bisection.  It's not
> > > > > > > > > about the whole tree, but about the each commit.
> > > > > > > > 
> > > > > > > > Only *building* is relevant for bisection until the whole feature
> > > > > > > > lands.
> > > > > > > 
> > > > > > > Why only building?
> > > > > > > 
> > > > > > > When merging through several tress, commits for the same series are
> > > > > > > scattered completely although they are softly tied.  This sucks when
> > > > > > > you perform git bisection, e.g. if you have an issue in the middle of
> > > > > > > the patch series.  It still works, but it jumps unnecessarily too far
> > > > > > > away and back before reaching to the point, and kconfig appears /
> > > > > > > disappears inconsistently (the dependent kconfig gone in the middle).
> > > > > > > And, this is about the release kernel (4.15 or whatever).
> > > > > > 
> > > > > > Think about how bisection works.  You state a good commit and a bad
> > > > > > one.  The good commit will be when the feature last worked, which will
> > > > > > not be until the feature has fully landed.  Bisect will not check any
> > > > > > point prior to this date.
> > > > > > 
> > > > > > If there aren't any build deps, each Maintainer will apply patches
> > > > > > into their own tree.  These will be merged together in -next where
> > > > > > they can be tested, both manually and by the 0-days.  Once the merge
> > > > > > window is opened all patches will be sucked into -rc1.  If the feature
> > > > > > works here, then it you could use -rc1 as your 'good' commit.  If it
> > > > > > doesn't, then this could indicate a merge error or a missing piece of
> > > > > > the set, either way bisect wouldn't help you.
> > > > > 
> > > > > Not really.
> > > > > 
> > > > > First of all, most of user start testing from the release kernel, so
> > > > > you can't trust that RC covered all test cases.  (Who can blame users
> > > > > who didn't use / test RC?)
> > > > 
> > > > That's fine.  We are not talking about spreading the merge of a
> > > > patch-set over different releases, or even release candidates.  All
> > > > non-bugfix patches should be in by -rc1.
> > > > 
> > > > > Second, you ignore the fact that the development continues after
> > > > > merging *this* patchset.  What if a breakage is introduced after this
> > > > > patch?  (See below)
> > > > > 
> > > > > They often need a full bisection between the previous release and the
> > > > > current release.
> > > > 
> > > > You cannot bisect a specific function back before it was merged.  It's
> > > > impossible.
> > > > 
> > > > P1 ---> P4 ---> P3 ---> P2
> > > >                          ^
> > > > Bisect only starts working here.  Prior to this point the feature
> > > > doesn't build at all.  If it builds, but breaks, then that is a build
> > > > dependency and is a different use-case to what we are discussing here.
> > > 
> > > OK, let me rephrase.  With the scenario above, user *cannot* perform
> > > bisect.  Meanwhile, with the straight merge, you can bisect a
> > > breakage.  That's a significant difference.
> > > 
> > > I.e. in the case where both commits A1, B1 and B2 are merged through
> > > tree A an B.  B2 is the breakage.  With separate tree merges, you
> > > cannot bisect, while the straight merge allows you to bisect B2.
> > 
> > Right, and that's really fundamental, because then the user can tell you
> > "look, this commit doesn't work for me" instead of just "this kernel
> > doesn't work for me" and now you need to spend *your* time on trying to
> > figure out which commit may be at fault.
> > 
> > So speaking of benefits, I really prefer to avoid spending my time on
> > such things. :-)
> 
> The toss-up is between splitting the patch-set up and *maybe* spending
> time on debugging in the small chance of this occurring OR
> *definitely* spending time creating immutable branches and sending out
> pull-requests in the *hope* that all the other Maintainers involved
> are diligent enough to merge it in order to avoid conflicts during
> merge time.
> 
> In the circles I spend time in ("we"), the former is the favourite.

This certainly depends on the complexity.  For a small patchset,
merging in a shot is often a safer option.  That is, when all parties
agree, you can just apply all patches to your branch -- that's all.
Other parties can simply pull this from your branch if needed.  Of
course, the branch needs to be immutable for that, but usually it's no
big problem.  (Ideally speaking, all the published branches should be
persistent in anyway.)

IIUC, it's the way Andy and Rafael suggested in the thread, and also
seen in many other subsystems occasionally.


> Until this point (and from this point going forward) we have taken the
> decision that the default is to take individual patches through their
> own trees.  The only time this differs (unless other arrangements are
> made e.g. PATCH 3/3) is when there are; build, merge or API
> dependencies between them.  The same stance is taken with
> driver/platform data and driver/other driver.
> 
> Let me put one of the issues into context:
> 
> For those reading along that do not know, Multi-Functional Devices are
> usually single pieces of silicon which provide many functions
> (e.g. LED Controllers, Voltage Regulation, Power Management, Sensors,
> Timers, GPIO/Pinctrl Controllers, Watchdog Timers, Real-Time Clocks,
> etc etc).  The driver which sits in drivers/mfd acts as the parent
> device and registers its children which live in their own subsystems.
> 
> Almost all of the patch-sets I receive touch multiple subsystems.
> Moreover, when the recently described dependencies occur, it is
> usually I who creates the immutable branches and sends out the
> pull-requests.
> 
> If I had to go through the immutable branch/pull-request process for
> every patch-set I receive, there would be very little time to conduct
> duties pertaining to my proper job.  Ergo, why we apply our own
> patches, unless there is a good reason (already described) to apply
> others too.

Hm, I never thought that creating an immutable branch were so
difficult.  Isn't it just a simple branch-off either from the certain
upstream point (final release or rc) or from your stable branch?


thanks,

Takashi

Re: [PATCH v5 1/3] mfd: Add support for Cherry Trail Dollar Cove TI PMIC

[Lee Jones]

> > > Right, and that's really fundamental, because then the user can tell you
> > > "look, this commit doesn't work for me" instead of just "this kernel
> > > doesn't work for me" and now you need to spend *your* time on trying to
> > > figure out which commit may be at fault.
> > > 
> > > So speaking of benefits, I really prefer to avoid spending my time on
> > > such things. :-)
> > 
> > The toss-up is between splitting the patch-set up and *maybe* spending
> > time on debugging in the small chance of this occurring OR
> > *definitely* spending time creating immutable branches and sending out
> > pull-requests in the *hope* that all the other Maintainers involved
> > are diligent enough to merge it in order to avoid conflicts during
> > merge time.
> > 
> > In the circles I spend time in ("we"), the former is the favourite.
> 
> This certainly depends on the complexity.  For a small patchset,
> merging in a shot is often a safer option.  That is, when all parties
> agree, you can just apply all patches to your branch -- that's all.
> Other parties can simply pull this from your branch if needed.  Of
> course, the branch needs to be immutable for that, but usually it's no
> big problem.  (Ideally speaking, all the published branches should be
> persistent in anyway.)
> 
> IIUC, it's the way Andy and Rafael suggested in the thread, and also
> seen in many other subsystems occasionally.
> 
> > Until this point (and from this point going forward) we have taken the
> > decision that the default is to take individual patches through their
> > own trees.  The only time this differs (unless other arrangements are
> > made e.g. PATCH 3/3) is when there are; build, merge or API
> > dependencies between them.  The same stance is taken with
> > driver/platform data and driver/other driver.
> > 
> > Let me put one of the issues into context:
> > 
> > For those reading along that do not know, Multi-Functional Devices are
> > usually single pieces of silicon which provide many functions
> > (e.g. LED Controllers, Voltage Regulation, Power Management, Sensors,
> > Timers, GPIO/Pinctrl Controllers, Watchdog Timers, Real-Time Clocks,
> > etc etc).  The driver which sits in drivers/mfd acts as the parent
> > device and registers its children which live in their own subsystems.
> > 
> > Almost all of the patch-sets I receive touch multiple subsystems.
> > Moreover, when the recently described dependencies occur, it is
> > usually I who creates the immutable branches and sends out the
> > pull-requests.
> > 
> > If I had to go through the immutable branch/pull-request process for
> > every patch-set I receive, there would be very little time to conduct
> > duties pertaining to my proper job.  Ergo, why we apply our own
> > patches, unless there is a good reason (already described) to apply
> > others too.
> 
> Hm, I never thought that creating an immutable branch were so
> difficult.  Isn't it just a simple branch-off either from the certain
> upstream point (final release or rc) or from your stable branch?

You'd be surprised.

When applying patches, I normally apply them to a mail folder for
further processing.  This works great for patches that are applied to
my main branch, but this does not work for immutable branches.  These
have to be applied on their own, thus need a 'special' or at least an
empty folder.

- Checkout a new branch based on the same (or earlier, but I always
use the same) commit as the main branch.

- Apply the patches in the normal way, only this time you usually need
to interactively rebase and 'reword' them to add any missing
Acks/Reviewed-bys.

- Tag and sign the branch with a suitable tag name and tag
description. 

- Push branch and tag

- Create pull-request text

- Send a formatted email with the pull-request text.

This process is quite a lot more involved than simply applying
relevant patches to your main branch, and as I say, if this was
required for all patch-sets I am sent or involved in, it would really
eat into my day.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v5 1/3] mfd: Add support for Cherry Trail Dollar Cove TI PMIC

[Takashi Iwai]

On Wed, 06 Sep 2017 16:54:32 +0200,
Lee Jones wrote:
> 
> > > > Right, and that's really fundamental, because then the user can tell you
> > > > "look, this commit doesn't work for me" instead of just "this kernel
> > > > doesn't work for me" and now you need to spend *your* time on trying to
> > > > figure out which commit may be at fault.
> > > > 
> > > > So speaking of benefits, I really prefer to avoid spending my time on
> > > > such things. :-)
> > > 
> > > The toss-up is between splitting the patch-set up and *maybe* spending
> > > time on debugging in the small chance of this occurring OR
> > > *definitely* spending time creating immutable branches and sending out
> > > pull-requests in the *hope* that all the other Maintainers involved
> > > are diligent enough to merge it in order to avoid conflicts during
> > > merge time.
> > > 
> > > In the circles I spend time in ("we"), the former is the favourite.
> > 
> > This certainly depends on the complexity.  For a small patchset,
> > merging in a shot is often a safer option.  That is, when all parties
> > agree, you can just apply all patches to your branch -- that's all.
> > Other parties can simply pull this from your branch if needed.  Of
> > course, the branch needs to be immutable for that, but usually it's no
> > big problem.  (Ideally speaking, all the published branches should be
> > persistent in anyway.)
> > 
> > IIUC, it's the way Andy and Rafael suggested in the thread, and also
> > seen in many other subsystems occasionally.
> > 
> > > Until this point (and from this point going forward) we have taken the
> > > decision that the default is to take individual patches through their
> > > own trees.  The only time this differs (unless other arrangements are
> > > made e.g. PATCH 3/3) is when there are; build, merge or API
> > > dependencies between them.  The same stance is taken with
> > > driver/platform data and driver/other driver.
> > > 
> > > Let me put one of the issues into context:
> > > 
> > > For those reading along that do not know, Multi-Functional Devices are
> > > usually single pieces of silicon which provide many functions
> > > (e.g. LED Controllers, Voltage Regulation, Power Management, Sensors,
> > > Timers, GPIO/Pinctrl Controllers, Watchdog Timers, Real-Time Clocks,
> > > etc etc).  The driver which sits in drivers/mfd acts as the parent
> > > device and registers its children which live in their own subsystems.
> > > 
> > > Almost all of the patch-sets I receive touch multiple subsystems.
> > > Moreover, when the recently described dependencies occur, it is
> > > usually I who creates the immutable branches and sends out the
> > > pull-requests.
> > > 
> > > If I had to go through the immutable branch/pull-request process for
> > > every patch-set I receive, there would be very little time to conduct
> > > duties pertaining to my proper job.  Ergo, why we apply our own
> > > patches, unless there is a good reason (already described) to apply
> > > others too.
> > 
> > Hm, I never thought that creating an immutable branch were so
> > difficult.  Isn't it just a simple branch-off either from the certain
> > upstream point (final release or rc) or from your stable branch?
> 
> You'd be surprised.
> 
> When applying patches, I normally apply them to a mail folder for
> further processing.  This works great for patches that are applied to
> my main branch, but this does not work for immutable branches.  These
> have to be applied on their own, thus need a 'special' or at least an
> empty folder.

Well, this isn't always requested -- at least, the simple case like
this one doesn't need to treat so much specially.  We just need a
persistent branch that will be never rebased.  It's the only
requirement.

That said, it's even enough just to branch off from your normal MFD
development branch, by a simple guarantee that you won't rebase *that*
branch any longer.

So, it's also a kind of "immutable branch", but it's much easier than
your regular workflow for the complex merge below.

Of course, a "cleaner" branch is preferred, but it doesn't matter much
as long as all stuff there will be merged to upstream sooner or
later.


thanks,

Takashi

> 
> - Checkout a new branch based on the same (or earlier, but I always
> use the same) commit as the main branch.
> 
> - Apply the patches in the normal way, only this time you usually need
> to interactively rebase and 'reword' them to add any missing
> Acks/Reviewed-bys.
> 
> - Tag and sign the branch with a suitable tag name and tag
> description. 
> 
> - Push branch and tag
> 
> - Create pull-request text
> 
> - Send a formatted email with the pull-request text.
> 
> This process is quite a lot more involved than simply applying
> relevant patches to your main branch, and as I say, if this was
> required for all patch-sets I am sent or involved in, it would really
> eat into my day.
> 
> -- 
> Lee Jones
> Linaro STMicroelectronics Landing Team Lead
> Linaro.org │ Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog
> 

Re: [PATCH v5 1/3] mfd: Add support for Cherry Trail Dollar Cove TI PMIC

[Lee Jones]

On Tue, 05 Sep 2017, Takashi Iwai wrote:

> On Tue, 05 Sep 2017 10:10:49 +0200,
> Lee Jones wrote:
> > 
> > On Tue, 05 Sep 2017, Takashi Iwai wrote:
> > 
> > > On Tue, 05 Sep 2017 09:24:51 +0200,
> > > Lee Jones wrote:
> > > > 
> > > > On Mon, 04 Sep 2017, Takashi Iwai wrote:
> > > > 
> > > > > This patch adds the MFD driver for Dollar Cove (TI version) PMIC with
> > > > > ACPI INT33F5 that is found on some Intel Cherry Trail devices.
> > > > > The driver is based on the original work by Intel, found at:
> > > > >   https://github.com/01org/ProductionKernelQuilts
> > > > > 
> > > > > This is a minimal version for adding the basic resources.  Currently,
> > > > > only ACPI PMIC opregion and the external power-button are used.
> > > > > 
> > > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891
> > > > > Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> > > > > Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> > > > > Signed-off-by: Takashi Iwai <tiwai@suse.de>
> > > > > ---
> > > > > v4->v5:
> > > > > * Minor coding-style fixes suggested by Lee
> > > > > * Put GPL text
> > > > > v3->v4:
> > > > > * no change for this patch
> > > > > v2->v3:
> > > > > * Rename dc_ti with chtdc_ti in all places
> > > > > * Driver/kconfig renames accordingly
> > > > > * Added acks by Andy and Mika
> > > > > v1->v2:
> > > > > * Minor cleanups as suggested by Andy
> > > > > 
> > > > >  drivers/mfd/Kconfig                   |  13 +++
> > > > >  drivers/mfd/Makefile                  |   1 +
> > > > >  drivers/mfd/intel_soc_pmic_chtdc_ti.c | 184 ++++++++++++++++++++++++++++++++++
> > > > >  3 files changed, 198 insertions(+)
> > > > >  create mode 100644 drivers/mfd/intel_soc_pmic_chtdc_ti.c
> > > > 
> > > > For my own reference:
> > > >   Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> > > 
> > > Thanks!
> > > 
> > > Now the question is how to deal with these.  It's no critical things,
> > > so I'm OK to postpone for 4.15.  OTOH, it's really a new
> > > device-specific stuff, thus it can't break anything else, and it'd be
> > > fairly safe to add it for 4.14 although it's at a bit late stage.
> > 
> > Yes, you are over 2 weeks late for v4.14.  It will have to be v4.15.
> 
> OK, I'll ring your bells again once when 4.15 development is opened.

Please don't.  Just collect all the Acks you have received and sent
out the set again changing [PATCH] for [RESEND].  Only if there
haven't been any code changes of course. 

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v5 1/3] mfd: Add support for Cherry Trail Dollar Cove TI PMIC

[Takashi Iwai]

On Tue, 05 Sep 2017 10:54:49 +0200,
Lee Jones wrote:
> 
> On Tue, 05 Sep 2017, Takashi Iwai wrote:
> 
> > On Tue, 05 Sep 2017 10:10:49 +0200,
> > Lee Jones wrote:
> > > 
> > > On Tue, 05 Sep 2017, Takashi Iwai wrote:
> > > 
> > > > On Tue, 05 Sep 2017 09:24:51 +0200,
> > > > Lee Jones wrote:
> > > > > 
> > > > > On Mon, 04 Sep 2017, Takashi Iwai wrote:
> > > > > 
> > > > > > This patch adds the MFD driver for Dollar Cove (TI version) PMIC with
> > > > > > ACPI INT33F5 that is found on some Intel Cherry Trail devices.
> > > > > > The driver is based on the original work by Intel, found at:
> > > > > >   https://github.com/01org/ProductionKernelQuilts
> > > > > > 
> > > > > > This is a minimal version for adding the basic resources.  Currently,
> > > > > > only ACPI PMIC opregion and the external power-button are used.
> > > > > > 
> > > > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891
> > > > > > Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> > > > > > Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> > > > > > Signed-off-by: Takashi Iwai <tiwai@suse.de>
> > > > > > ---
> > > > > > v4->v5:
> > > > > > * Minor coding-style fixes suggested by Lee
> > > > > > * Put GPL text
> > > > > > v3->v4:
> > > > > > * no change for this patch
> > > > > > v2->v3:
> > > > > > * Rename dc_ti with chtdc_ti in all places
> > > > > > * Driver/kconfig renames accordingly
> > > > > > * Added acks by Andy and Mika
> > > > > > v1->v2:
> > > > > > * Minor cleanups as suggested by Andy
> > > > > > 
> > > > > >  drivers/mfd/Kconfig                   |  13 +++
> > > > > >  drivers/mfd/Makefile                  |   1 +
> > > > > >  drivers/mfd/intel_soc_pmic_chtdc_ti.c | 184 ++++++++++++++++++++++++++++++++++
> > > > > >  3 files changed, 198 insertions(+)
> > > > > >  create mode 100644 drivers/mfd/intel_soc_pmic_chtdc_ti.c
> > > > > 
> > > > > For my own reference:
> > > > >   Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> > > > 
> > > > Thanks!
> > > > 
> > > > Now the question is how to deal with these.  It's no critical things,
> > > > so I'm OK to postpone for 4.15.  OTOH, it's really a new
> > > > device-specific stuff, thus it can't break anything else, and it'd be
> > > > fairly safe to add it for 4.14 although it's at a bit late stage.
> > > 
> > > Yes, you are over 2 weeks late for v4.14.  It will have to be v4.15.
> > 
> > OK, I'll ring your bells again once when 4.15 development is opened.
> 
> Please don't.  Just collect all the Acks you have received and sent
> out the set again changing [PATCH] for [RESEND].  Only if there
> haven't been any code changes of course. 
  
You seem to have applied the patches in some branch, but still do I
need to resend the whole patches?

BTW, was patch 2/3 applied?  I miss your notification mail.


thanks,

Takashi

Re: [PATCH v5 1/3] mfd: Add support for Cherry Trail Dollar Cove TI PMIC

[Lee Jones]

On Thu, 07 Sep 2017, Takashi Iwai wrote:

> On Tue, 05 Sep 2017 10:54:49 +0200,
> Lee Jones wrote:
> > 
> > On Tue, 05 Sep 2017, Takashi Iwai wrote:
> > 
> > > On Tue, 05 Sep 2017 10:10:49 +0200,
> > > Lee Jones wrote:
> > > > 
> > > > On Tue, 05 Sep 2017, Takashi Iwai wrote:
> > > > 
> > > > > On Tue, 05 Sep 2017 09:24:51 +0200,
> > > > > Lee Jones wrote:
> > > > > > 
> > > > > > On Mon, 04 Sep 2017, Takashi Iwai wrote:
> > > > > > 
> > > > > > > This patch adds the MFD driver for Dollar Cove (TI version) PMIC with
> > > > > > > ACPI INT33F5 that is found on some Intel Cherry Trail devices.
> > > > > > > The driver is based on the original work by Intel, found at:
> > > > > > >   https://github.com/01org/ProductionKernelQuilts
> > > > > > > 
> > > > > > > This is a minimal version for adding the basic resources.  Currently,
> > > > > > > only ACPI PMIC opregion and the external power-button are used.
> > > > > > > 
> > > > > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891
> > > > > > > Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> > > > > > > Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> > > > > > > Signed-off-by: Takashi Iwai <tiwai@suse.de>
> > > > > > > ---
> > > > > > > v4->v5:
> > > > > > > * Minor coding-style fixes suggested by Lee
> > > > > > > * Put GPL text
> > > > > > > v3->v4:
> > > > > > > * no change for this patch
> > > > > > > v2->v3:
> > > > > > > * Rename dc_ti with chtdc_ti in all places
> > > > > > > * Driver/kconfig renames accordingly
> > > > > > > * Added acks by Andy and Mika
> > > > > > > v1->v2:
> > > > > > > * Minor cleanups as suggested by Andy
> > > > > > > 
> > > > > > >  drivers/mfd/Kconfig                   |  13 +++
> > > > > > >  drivers/mfd/Makefile                  |   1 +
> > > > > > >  drivers/mfd/intel_soc_pmic_chtdc_ti.c | 184 ++++++++++++++++++++++++++++++++++
> > > > > > >  3 files changed, 198 insertions(+)
> > > > > > >  create mode 100644 drivers/mfd/intel_soc_pmic_chtdc_ti.c
> > > > > > 
> > > > > > For my own reference:
> > > > > >   Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> > > > > 
> > > > > Thanks!
> > > > > 
> > > > > Now the question is how to deal with these.  It's no critical things,
> > > > > so I'm OK to postpone for 4.15.  OTOH, it's really a new
> > > > > device-specific stuff, thus it can't break anything else, and it'd be
> > > > > fairly safe to add it for 4.14 although it's at a bit late stage.
> > > > 
> > > > Yes, you are over 2 weeks late for v4.14.  It will have to be v4.15.
> > > 
> > > OK, I'll ring your bells again once when 4.15 development is opened.
> > 
> > Please don't.  Just collect all the Acks you have received and sent
> > out the set again changing [PATCH] for [RESEND].  Only if there
> > haven't been any code changes of course. 
>   
> You seem to have applied the patches in some branch, but still do I
> need to resend the whole patches?

That's up to the Platform Maintainers.

Since the MFD and ACPI are applied, you do not need to resend those.

> BTW, was patch 2/3 applied?  I miss your notification mail.

Patch 2 needs to be applied into the Platform tree.

Since there are no deps between the patches, they should be applied
into their own trees (as previously discussed).  I only applied the
ACPI patch because Rafael asked me nicely.  Normally this should have
gone in separately too.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v5 1/3] mfd: Add support for Cherry Trail Dollar Cove TI PMIC

[Rafael J. Wysocki]

On Thursday, September 7, 2017 12:53:48 PM CEST Lee Jones wrote:
> On Thu, 07 Sep 2017, Takashi Iwai wrote:
> 
> > On Tue, 05 Sep 2017 10:54:49 +0200,
> > Lee Jones wrote:
> > > 
> > > On Tue, 05 Sep 2017, Takashi Iwai wrote:
> > > 
> > > > On Tue, 05 Sep 2017 10:10:49 +0200,
> > > > Lee Jones wrote:
> > > > > 
> > > > > On Tue, 05 Sep 2017, Takashi Iwai wrote:
> > > > > 
> > > > > > On Tue, 05 Sep 2017 09:24:51 +0200,
> > > > > > Lee Jones wrote:
> > > > > > > 
> > > > > > > On Mon, 04 Sep 2017, Takashi Iwai wrote:
> > > > > > > 
> > > > > > > > This patch adds the MFD driver for Dollar Cove (TI version) PMIC with
> > > > > > > > ACPI INT33F5 that is found on some Intel Cherry Trail devices.
> > > > > > > > The driver is based on the original work by Intel, found at:
> > > > > > > >   https://github.com/01org/ProductionKernelQuilts
> > > > > > > > 
> > > > > > > > This is a minimal version for adding the basic resources.  Currently,
> > > > > > > > only ACPI PMIC opregion and the external power-button are used.
> > > > > > > > 
> > > > > > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891
> > > > > > > > Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> > > > > > > > Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> > > > > > > > Signed-off-by: Takashi Iwai <tiwai@suse.de>
> > > > > > > > ---
> > > > > > > > v4->v5:
> > > > > > > > * Minor coding-style fixes suggested by Lee
> > > > > > > > * Put GPL text
> > > > > > > > v3->v4:
> > > > > > > > * no change for this patch
> > > > > > > > v2->v3:
> > > > > > > > * Rename dc_ti with chtdc_ti in all places
> > > > > > > > * Driver/kconfig renames accordingly
> > > > > > > > * Added acks by Andy and Mika
> > > > > > > > v1->v2:
> > > > > > > > * Minor cleanups as suggested by Andy
> > > > > > > > 
> > > > > > > >  drivers/mfd/Kconfig                   |  13 +++
> > > > > > > >  drivers/mfd/Makefile                  |   1 +
> > > > > > > >  drivers/mfd/intel_soc_pmic_chtdc_ti.c | 184 ++++++++++++++++++++++++++++++++++
> > > > > > > >  3 files changed, 198 insertions(+)
> > > > > > > >  create mode 100644 drivers/mfd/intel_soc_pmic_chtdc_ti.c
> > > > > > > 
> > > > > > > For my own reference:
> > > > > > >   Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> > > > > > 
> > > > > > Thanks!
> > > > > > 
> > > > > > Now the question is how to deal with these.  It's no critical things,
> > > > > > so I'm OK to postpone for 4.15.  OTOH, it's really a new
> > > > > > device-specific stuff, thus it can't break anything else, and it'd be
> > > > > > fairly safe to add it for 4.14 although it's at a bit late stage.
> > > > > 
> > > > > Yes, you are over 2 weeks late for v4.14.  It will have to be v4.15.
> > > > 
> > > > OK, I'll ring your bells again once when 4.15 development is opened.
> > > 
> > > Please don't.  Just collect all the Acks you have received and sent
> > > out the set again changing [PATCH] for [RESEND].  Only if there
> > > haven't been any code changes of course. 
> >   
> > You seem to have applied the patches in some branch, but still do I
> > need to resend the whole patches?
> 
> That's up to the Platform Maintainers.
> 
> Since the MFD and ACPI are applied, you do not need to resend those.
> 
> > BTW, was patch 2/3 applied?  I miss your notification mail.
> 
> Patch 2 needs to be applied into the Platform tree.

Actually, that's drivers/platform/x86/ so it falls under
X86 PLATFORM DRIVERS and it has already been ACKed by Andy who is
one of the maintainers of that.

Andy, Darren, can patch [2/3] from this series go in via the MFD tree?

Thanks,
Rafael

Re: [PATCH v5 1/3] mfd: Add support for Cherry Trail Dollar Cove TI PMIC

[Lee Jones]

On Thu, 07 Sep 2017, Rafael J. Wysocki wrote:

> On Thursday, September 7, 2017 12:53:48 PM CEST Lee Jones wrote:
> > On Thu, 07 Sep 2017, Takashi Iwai wrote:
> > 
> > > On Tue, 05 Sep 2017 10:54:49 +0200,
> > > Lee Jones wrote:
> > > > 
> > > > On Tue, 05 Sep 2017, Takashi Iwai wrote:
> > > > 
> > > > > On Tue, 05 Sep 2017 10:10:49 +0200,
> > > > > Lee Jones wrote:
> > > > > > 
> > > > > > On Tue, 05 Sep 2017, Takashi Iwai wrote:
> > > > > > 
> > > > > > > On Tue, 05 Sep 2017 09:24:51 +0200,
> > > > > > > Lee Jones wrote:
> > > > > > > > 
> > > > > > > > On Mon, 04 Sep 2017, Takashi Iwai wrote:
> > > > > > > > 
> > > > > > > > > This patch adds the MFD driver for Dollar Cove (TI version) PMIC with
> > > > > > > > > ACPI INT33F5 that is found on some Intel Cherry Trail devices.
> > > > > > > > > The driver is based on the original work by Intel, found at:
> > > > > > > > >   https://github.com/01org/ProductionKernelQuilts
> > > > > > > > > 
> > > > > > > > > This is a minimal version for adding the basic resources.  Currently,
> > > > > > > > > only ACPI PMIC opregion and the external power-button are used.
> > > > > > > > > 
> > > > > > > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891
> > > > > > > > > Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> > > > > > > > > Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> > > > > > > > > Signed-off-by: Takashi Iwai <tiwai@suse.de>
> > > > > > > > > ---
> > > > > > > > > v4->v5:
> > > > > > > > > * Minor coding-style fixes suggested by Lee
> > > > > > > > > * Put GPL text
> > > > > > > > > v3->v4:
> > > > > > > > > * no change for this patch
> > > > > > > > > v2->v3:
> > > > > > > > > * Rename dc_ti with chtdc_ti in all places
> > > > > > > > > * Driver/kconfig renames accordingly
> > > > > > > > > * Added acks by Andy and Mika
> > > > > > > > > v1->v2:
> > > > > > > > > * Minor cleanups as suggested by Andy
> > > > > > > > > 
> > > > > > > > >  drivers/mfd/Kconfig                   |  13 +++
> > > > > > > > >  drivers/mfd/Makefile                  |   1 +
> > > > > > > > >  drivers/mfd/intel_soc_pmic_chtdc_ti.c | 184 ++++++++++++++++++++++++++++++++++
> > > > > > > > >  3 files changed, 198 insertions(+)
> > > > > > > > >  create mode 100644 drivers/mfd/intel_soc_pmic_chtdc_ti.c
> > > > > > > > 
> > > > > > > > For my own reference:
> > > > > > > >   Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> > > > > > > 
> > > > > > > Thanks!
> > > > > > > 
> > > > > > > Now the question is how to deal with these.  It's no critical things,
> > > > > > > so I'm OK to postpone for 4.15.  OTOH, it's really a new
> > > > > > > device-specific stuff, thus it can't break anything else, and it'd be
> > > > > > > fairly safe to add it for 4.14 although it's at a bit late stage.
> > > > > > 
> > > > > > Yes, you are over 2 weeks late for v4.14.  It will have to be v4.15.
> > > > > 
> > > > > OK, I'll ring your bells again once when 4.15 development is opened.
> > > > 
> > > > Please don't.  Just collect all the Acks you have received and sent
> > > > out the set again changing [PATCH] for [RESEND].  Only if there
> > > > haven't been any code changes of course. 
> > >   
> > > You seem to have applied the patches in some branch, but still do I
> > > need to resend the whole patches?
> > 
> > That's up to the Platform Maintainers.
> > 
> > Since the MFD and ACPI are applied, you do not need to resend those.
> > 
> > > BTW, was patch 2/3 applied?  I miss your notification mail.
> > 
> > Patch 2 needs to be applied into the Platform tree.
> 
> Actually, that's drivers/platform/x86/ so it falls under
> X86 PLATFORM DRIVERS and it has already been ACKed by Andy who is
> one of the maintainers of that.
> 
> Andy, Darren, can patch [2/3] from this series go in via the MFD tree?

... without an immutable branch.  Which also means all changes to this
file due for v4.15 would have to come in via the MFD tree too.

This is sub optimal IMHO.  I'd rather it was fed through the proper
tree(s), so we can continue our normal flow for subsequent changes.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v5 1/3] mfd: Add support for Cherry Trail Dollar Cove TI PMIC

[Takashi Iwai]

On Thu, 07 Sep 2017 13:17:47 +0200,
Lee Jones wrote:
> 
> On Thu, 07 Sep 2017, Rafael J. Wysocki wrote:
> 
> > On Thursday, September 7, 2017 12:53:48 PM CEST Lee Jones wrote:
> > > On Thu, 07 Sep 2017, Takashi Iwai wrote:
> > > 
> > > > On Tue, 05 Sep 2017 10:54:49 +0200,
> > > > Lee Jones wrote:
> > > > > 
> > > > > On Tue, 05 Sep 2017, Takashi Iwai wrote:
> > > > > 
> > > > > > On Tue, 05 Sep 2017 10:10:49 +0200,
> > > > > > Lee Jones wrote:
> > > > > > > 
> > > > > > > On Tue, 05 Sep 2017, Takashi Iwai wrote:
> > > > > > > 
> > > > > > > > On Tue, 05 Sep 2017 09:24:51 +0200,
> > > > > > > > Lee Jones wrote:
> > > > > > > > > 
> > > > > > > > > On Mon, 04 Sep 2017, Takashi Iwai wrote:
> > > > > > > > > 
> > > > > > > > > > This patch adds the MFD driver for Dollar Cove (TI version) PMIC with
> > > > > > > > > > ACPI INT33F5 that is found on some Intel Cherry Trail devices.
> > > > > > > > > > The driver is based on the original work by Intel, found at:
> > > > > > > > > >   https://github.com/01org/ProductionKernelQuilts
> > > > > > > > > > 
> > > > > > > > > > This is a minimal version for adding the basic resources.  Currently,
> > > > > > > > > > only ACPI PMIC opregion and the external power-button are used.
> > > > > > > > > > 
> > > > > > > > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891
> > > > > > > > > > Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> > > > > > > > > > Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> > > > > > > > > > Signed-off-by: Takashi Iwai <tiwai@suse.de>
> > > > > > > > > > ---
> > > > > > > > > > v4->v5:
> > > > > > > > > > * Minor coding-style fixes suggested by Lee
> > > > > > > > > > * Put GPL text
> > > > > > > > > > v3->v4:
> > > > > > > > > > * no change for this patch
> > > > > > > > > > v2->v3:
> > > > > > > > > > * Rename dc_ti with chtdc_ti in all places
> > > > > > > > > > * Driver/kconfig renames accordingly
> > > > > > > > > > * Added acks by Andy and Mika
> > > > > > > > > > v1->v2:
> > > > > > > > > > * Minor cleanups as suggested by Andy
> > > > > > > > > > 
> > > > > > > > > >  drivers/mfd/Kconfig                   |  13 +++
> > > > > > > > > >  drivers/mfd/Makefile                  |   1 +
> > > > > > > > > >  drivers/mfd/intel_soc_pmic_chtdc_ti.c | 184 ++++++++++++++++++++++++++++++++++
> > > > > > > > > >  3 files changed, 198 insertions(+)
> > > > > > > > > >  create mode 100644 drivers/mfd/intel_soc_pmic_chtdc_ti.c
> > > > > > > > > 
> > > > > > > > > For my own reference:
> > > > > > > > >   Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> > > > > > > > 
> > > > > > > > Thanks!
> > > > > > > > 
> > > > > > > > Now the question is how to deal with these.  It's no critical things,
> > > > > > > > so I'm OK to postpone for 4.15.  OTOH, it's really a new
> > > > > > > > device-specific stuff, thus it can't break anything else, and it'd be
> > > > > > > > fairly safe to add it for 4.14 although it's at a bit late stage.
> > > > > > > 
> > > > > > > Yes, you are over 2 weeks late for v4.14.  It will have to be v4.15.
> > > > > > 
> > > > > > OK, I'll ring your bells again once when 4.15 development is opened.
> > > > > 
> > > > > Please don't.  Just collect all the Acks you have received and sent
> > > > > out the set again changing [PATCH] for [RESEND].  Only if there
> > > > > haven't been any code changes of course. 
> > > >   
> > > > You seem to have applied the patches in some branch, but still do I
> > > > need to resend the whole patches?
> > > 
> > > That's up to the Platform Maintainers.
> > > 
> > > Since the MFD and ACPI are applied, you do not need to resend those.
> > > 
> > > > BTW, was patch 2/3 applied?  I miss your notification mail.
> > > 
> > > Patch 2 needs to be applied into the Platform tree.
> > 
> > Actually, that's drivers/platform/x86/ so it falls under
> > X86 PLATFORM DRIVERS and it has already been ACKed by Andy who is
> > one of the maintainers of that.
> > 
> > Andy, Darren, can patch [2/3] from this series go in via the MFD tree?
> 
> ... without an immutable branch.

Why can't it be immutable?  You just don't branch off the commit
containing these three patches, and don't touch any longer on that, so
that other trees can pull it in; it's all what we need.

> Which also means all changes to this
> file due for v4.15 would have to come in via the MFD tree too.
> 
> This is sub optimal IMHO.  I'd rather it was fed through the proper
> tree(s), so we can continue our normal flow for subsequent changes.

Other trees sometimes pull this kind of "immutable" branches, too.
I see no big problem there.


thanks,

Takashi

Re: [PATCH v5 1/3] mfd: Add support for Cherry Trail Dollar Cove TI PMIC

[Lee Jones]

On Thu, 07 Sep 2017, Takashi Iwai wrote:

> On Thu, 07 Sep 2017 13:17:47 +0200,
> Lee Jones wrote:
> > 
> > On Thu, 07 Sep 2017, Rafael J. Wysocki wrote:
> > 
> > > On Thursday, September 7, 2017 12:53:48 PM CEST Lee Jones wrote:
> > > > On Thu, 07 Sep 2017, Takashi Iwai wrote:
> > > > 
> > > > > On Tue, 05 Sep 2017 10:54:49 +0200,
> > > > > Lee Jones wrote:
> > > > > > 
> > > > > > On Tue, 05 Sep 2017, Takashi Iwai wrote:
> > > > > > 
> > > > > > > On Tue, 05 Sep 2017 10:10:49 +0200,
> > > > > > > Lee Jones wrote:
> > > > > > > > 
> > > > > > > > On Tue, 05 Sep 2017, Takashi Iwai wrote:
> > > > > > > > 
> > > > > > > > > On Tue, 05 Sep 2017 09:24:51 +0200,
> > > > > > > > > Lee Jones wrote:
> > > > > > > > > > 
> > > > > > > > > > On Mon, 04 Sep 2017, Takashi Iwai wrote:
> > > > > > > > > > 
> > > > > > > > > > > This patch adds the MFD driver for Dollar Cove (TI version) PMIC with
> > > > > > > > > > > ACPI INT33F5 that is found on some Intel Cherry Trail devices.
> > > > > > > > > > > The driver is based on the original work by Intel, found at:
> > > > > > > > > > >   https://github.com/01org/ProductionKernelQuilts
> > > > > > > > > > > 
> > > > > > > > > > > This is a minimal version for adding the basic resources.  Currently,
> > > > > > > > > > > only ACPI PMIC opregion and the external power-button are used.
> > > > > > > > > > > 
> > > > > > > > > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891
> > > > > > > > > > > Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> > > > > > > > > > > Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> > > > > > > > > > > Signed-off-by: Takashi Iwai <tiwai@suse.de>
> > > > > > > > > > > ---
> > > > > > > > > > > v4->v5:
> > > > > > > > > > > * Minor coding-style fixes suggested by Lee
> > > > > > > > > > > * Put GPL text
> > > > > > > > > > > v3->v4:
> > > > > > > > > > > * no change for this patch
> > > > > > > > > > > v2->v3:
> > > > > > > > > > > * Rename dc_ti with chtdc_ti in all places
> > > > > > > > > > > * Driver/kconfig renames accordingly
> > > > > > > > > > > * Added acks by Andy and Mika
> > > > > > > > > > > v1->v2:
> > > > > > > > > > > * Minor cleanups as suggested by Andy
> > > > > > > > > > > 
> > > > > > > > > > >  drivers/mfd/Kconfig                   |  13 +++
> > > > > > > > > > >  drivers/mfd/Makefile                  |   1 +
> > > > > > > > > > >  drivers/mfd/intel_soc_pmic_chtdc_ti.c | 184 ++++++++++++++++++++++++++++++++++
> > > > > > > > > > >  3 files changed, 198 insertions(+)
> > > > > > > > > > >  create mode 100644 drivers/mfd/intel_soc_pmic_chtdc_ti.c
> > > > > > > > > > 
> > > > > > > > > > For my own reference:
> > > > > > > > > >   Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> > > > > > > > > 
> > > > > > > > > Thanks!
> > > > > > > > > 
> > > > > > > > > Now the question is how to deal with these.  It's no critical things,
> > > > > > > > > so I'm OK to postpone for 4.15.  OTOH, it's really a new
> > > > > > > > > device-specific stuff, thus it can't break anything else, and it'd be
> > > > > > > > > fairly safe to add it for 4.14 although it's at a bit late stage.
> > > > > > > > 
> > > > > > > > Yes, you are over 2 weeks late for v4.14.  It will have to be v4.15.
> > > > > > > 
> > > > > > > OK, I'll ring your bells again once when 4.15 development is opened.
> > > > > > 
> > > > > > Please don't.  Just collect all the Acks you have received and sent
> > > > > > out the set again changing [PATCH] for [RESEND].  Only if there
> > > > > > haven't been any code changes of course. 
> > > > >   
> > > > > You seem to have applied the patches in some branch, but still do I
> > > > > need to resend the whole patches?
> > > > 
> > > > That's up to the Platform Maintainers.
> > > > 
> > > > Since the MFD and ACPI are applied, you do not need to resend those.
> > > > 
> > > > > BTW, was patch 2/3 applied?  I miss your notification mail.
> > > > 
> > > > Patch 2 needs to be applied into the Platform tree.
> > > 
> > > Actually, that's drivers/platform/x86/ so it falls under
> > > X86 PLATFORM DRIVERS and it has already been ACKed by Andy who is
> > > one of the maintainers of that.
> > > 
> > > Andy, Darren, can patch [2/3] from this series go in via the MFD tree?
> > 
> > ... without an immutable branch.
> 
> Why can't it be immutable?  You just don't branch off the commit
> containing these three patches, and don't touch any longer on that, so
> that other trees can pull it in; it's all what we need.

Firstly, the MFD main branch is not immutable.

Secondly, you cannot simply pull a patch in from another tree.  All of
the patches before it and your local base will be pulled in too.  This
is why we create purposely created immutable branches which *only*
contain the patches required by other repos.

> > Which also means all changes to this
> > file due for v4.15 would have to come in via the MFD tree too.
> > 
> > This is sub optimal IMHO.  I'd rather it was fed through the proper
> > tree(s), so we can continue our normal flow for subsequent changes.
> 
> Other trees sometimes pull this kind of "immutable" branches, too.
> I see no big problem there.

There are no valid reason to create an IB for this case.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v5 1/3] mfd: Add support for Cherry Trail Dollar Cove TI PMIC

[Takashi Iwai]

On Thu, 07 Sep 2017 14:24:00 +0200,
Lee Jones wrote:
> 
> On Thu, 07 Sep 2017, Takashi Iwai wrote:
> 
> > On Thu, 07 Sep 2017 13:17:47 +0200,
> > Lee Jones wrote:
> > > 
> > > On Thu, 07 Sep 2017, Rafael J. Wysocki wrote:
> > > 
> > > > On Thursday, September 7, 2017 12:53:48 PM CEST Lee Jones wrote:
> > > > > On Thu, 07 Sep 2017, Takashi Iwai wrote:
> > > > > 
> > > > > > On Tue, 05 Sep 2017 10:54:49 +0200,
> > > > > > Lee Jones wrote:
> > > > > > > 
> > > > > > > On Tue, 05 Sep 2017, Takashi Iwai wrote:
> > > > > > > 
> > > > > > > > On Tue, 05 Sep 2017 10:10:49 +0200,
> > > > > > > > Lee Jones wrote:
> > > > > > > > > 
> > > > > > > > > On Tue, 05 Sep 2017, Takashi Iwai wrote:
> > > > > > > > > 
> > > > > > > > > > On Tue, 05 Sep 2017 09:24:51 +0200,
> > > > > > > > > > Lee Jones wrote:
> > > > > > > > > > > 
> > > > > > > > > > > On Mon, 04 Sep 2017, Takashi Iwai wrote:
> > > > > > > > > > > 
> > > > > > > > > > > > This patch adds the MFD driver for Dollar Cove (TI version) PMIC with
> > > > > > > > > > > > ACPI INT33F5 that is found on some Intel Cherry Trail devices.
> > > > > > > > > > > > The driver is based on the original work by Intel, found at:
> > > > > > > > > > > >   https://github.com/01org/ProductionKernelQuilts
> > > > > > > > > > > > 
> > > > > > > > > > > > This is a minimal version for adding the basic resources.  Currently,
> > > > > > > > > > > > only ACPI PMIC opregion and the external power-button are used.
> > > > > > > > > > > > 
> > > > > > > > > > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891
> > > > > > > > > > > > Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> > > > > > > > > > > > Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> > > > > > > > > > > > Signed-off-by: Takashi Iwai <tiwai@suse.de>
> > > > > > > > > > > > ---
> > > > > > > > > > > > v4->v5:
> > > > > > > > > > > > * Minor coding-style fixes suggested by Lee
> > > > > > > > > > > > * Put GPL text
> > > > > > > > > > > > v3->v4:
> > > > > > > > > > > > * no change for this patch
> > > > > > > > > > > > v2->v3:
> > > > > > > > > > > > * Rename dc_ti with chtdc_ti in all places
> > > > > > > > > > > > * Driver/kconfig renames accordingly
> > > > > > > > > > > > * Added acks by Andy and Mika
> > > > > > > > > > > > v1->v2:
> > > > > > > > > > > > * Minor cleanups as suggested by Andy
> > > > > > > > > > > > 
> > > > > > > > > > > >  drivers/mfd/Kconfig                   |  13 +++
> > > > > > > > > > > >  drivers/mfd/Makefile                  |   1 +
> > > > > > > > > > > >  drivers/mfd/intel_soc_pmic_chtdc_ti.c | 184 ++++++++++++++++++++++++++++++++++
> > > > > > > > > > > >  3 files changed, 198 insertions(+)
> > > > > > > > > > > >  create mode 100644 drivers/mfd/intel_soc_pmic_chtdc_ti.c
> > > > > > > > > > > 
> > > > > > > > > > > For my own reference:
> > > > > > > > > > >   Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> > > > > > > > > > 
> > > > > > > > > > Thanks!
> > > > > > > > > > 
> > > > > > > > > > Now the question is how to deal with these.  It's no critical things,
> > > > > > > > > > so I'm OK to postpone for 4.15.  OTOH, it's really a new
> > > > > > > > > > device-specific stuff, thus it can't break anything else, and it'd be
> > > > > > > > > > fairly safe to add it for 4.14 although it's at a bit late stage.
> > > > > > > > > 
> > > > > > > > > Yes, you are over 2 weeks late for v4.14.  It will have to be v4.15.
> > > > > > > > 
> > > > > > > > OK, I'll ring your bells again once when 4.15 development is opened.
> > > > > > > 
> > > > > > > Please don't.  Just collect all the Acks you have received and sent
> > > > > > > out the set again changing [PATCH] for [RESEND].  Only if there
> > > > > > > haven't been any code changes of course. 
> > > > > >   
> > > > > > You seem to have applied the patches in some branch, but still do I
> > > > > > need to resend the whole patches?
> > > > > 
> > > > > That's up to the Platform Maintainers.
> > > > > 
> > > > > Since the MFD and ACPI are applied, you do not need to resend those.
> > > > > 
> > > > > > BTW, was patch 2/3 applied?  I miss your notification mail.
> > > > > 
> > > > > Patch 2 needs to be applied into the Platform tree.
> > > > 
> > > > Actually, that's drivers/platform/x86/ so it falls under
> > > > X86 PLATFORM DRIVERS and it has already been ACKed by Andy who is
> > > > one of the maintainers of that.
> > > > 
> > > > Andy, Darren, can patch [2/3] from this series go in via the MFD tree?
> > > 
> > > ... without an immutable branch.
> > 
> > Why can't it be immutable?  You just don't branch off the commit
> > containing these three patches, and don't touch any longer on that, so
> > that other trees can pull it in; it's all what we need.
> 
> Firstly, the MFD main branch is not immutable.

That's bad in general :)

> Secondly, you cannot simply pull a patch in from another tree.

Many trees do it sometimes as long as the branch is guaranteed to be
persistent / immutable, prepared for the next kernel.

> All of
> the patches before it and your local base will be pulled in too.  This
> is why we create purposely created immutable branches which *only*
> contain the patches required by other repos.

Yes, ideally we should have a clean base for such a shared branch.

> > > Which also means all changes to this
> > > file due for v4.15 would have to come in via the MFD tree too.
> > > 
> > > This is sub optimal IMHO.  I'd rather it was fed through the proper
> > > tree(s), so we can continue our normal flow for subsequent changes.
> > 
> > Other trees sometimes pull this kind of "immutable" branches, too.
> > I see no big problem there.
> 
> There are no valid reason to create an IB for this case.

I don't understand why makes it so difficult.  Looking at the
procedure you mentioned in this thread:

==
1. Checkout a new branch based on the same (or earlier, but I always
use the same) commit as the main branch.

2. Apply the patches in the normal way, only this time you usually need
to interactively rebase and 'reword' them to add any missing
Acks/Reviewed-bys.

3. Tag and sign the branch with a suitable tag name and tag
description. 

4. Push branch and tag

5. Create pull-request text

6. Send a formatted email with the pull-request text.
==

1 is easy, you can take 4.14-rc1 once when released.  This kind of
  thing is done by many people regularly for opening a topic
  development branch.

2 is the very standard procedure.  You'd need to add tags in anyway
  even for normal branches.

3, the signed tagging can be optional, only when requested.
  Of course, it's safer to have one, but not mandatory.
  Branch naming?  It's not more difficult than thinking of the next
  android version code name :)

4, normal procedure. 

5 and 6 are relaxed in this case, just a one-line notification mail to
  this thread should suffice.


... so I really can't see any specially time-consuming or exhausting
step in the above.  Usually most time-consuming stuff is rather the
code review and the build test.  But this isn't different from the
normal case.

Or am I missing anything?


thanks,

Takashi

Re: [PATCH v5 1/3] mfd: Add support for Cherry Trail Dollar Cove TI PMIC

[Lee Jones]

On Thu, 07 Sep 2017, Takashi Iwai wrote:

> On Thu, 07 Sep 2017 14:24:00 +0200,
> Lee Jones wrote:
> > 
> > On Thu, 07 Sep 2017, Takashi Iwai wrote:
> > 
> > > On Thu, 07 Sep 2017 13:17:47 +0200,
> > > Lee Jones wrote:
> > > > 
> > > > On Thu, 07 Sep 2017, Rafael J. Wysocki wrote:
> > > > 
> > > > > On Thursday, September 7, 2017 12:53:48 PM CEST Lee Jones wrote:
> > > > > > On Thu, 07 Sep 2017, Takashi Iwai wrote:
> > > > > > 
> > > > > > > On Tue, 05 Sep 2017 10:54:49 +0200,
> > > > > > > Lee Jones wrote:
> > > > > > > > 
> > > > > > > > On Tue, 05 Sep 2017, Takashi Iwai wrote:
> > > > > > > > 
> > > > > > > > > On Tue, 05 Sep 2017 10:10:49 +0200,
> > > > > > > > > Lee Jones wrote:
> > > > > > > > > > 
> > > > > > > > > > On Tue, 05 Sep 2017, Takashi Iwai wrote:
> > > > > > > > > > 
> > > > > > > > > > > On Tue, 05 Sep 2017 09:24:51 +0200,
> > > > > > > > > > > Lee Jones wrote:
> > > > > > > > > > > > 
> > > > > > > > > > > > On Mon, 04 Sep 2017, Takashi Iwai wrote:
> > > > > > > > > > > > 
> > > > > > > > > > > > > This patch adds the MFD driver for Dollar Cove (TI version) PMIC with
> > > > > > > > > > > > > ACPI INT33F5 that is found on some Intel Cherry Trail devices.
> > > > > > > > > > > > > The driver is based on the original work by Intel, found at:
> > > > > > > > > > > > >   https://github.com/01org/ProductionKernelQuilts
> > > > > > > > > > > > > 
> > > > > > > > > > > > > This is a minimal version for adding the basic resources.  Currently,
> > > > > > > > > > > > > only ACPI PMIC opregion and the external power-button are used.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891
> > > > > > > > > > > > > Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> > > > > > > > > > > > > Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> > > > > > > > > > > > > Signed-off-by: Takashi Iwai <tiwai@suse.de>
> > > > > > > > > > > > > ---
> > > > > > > > > > > > > v4->v5:
> > > > > > > > > > > > > * Minor coding-style fixes suggested by Lee
> > > > > > > > > > > > > * Put GPL text
> > > > > > > > > > > > > v3->v4:
> > > > > > > > > > > > > * no change for this patch
> > > > > > > > > > > > > v2->v3:
> > > > > > > > > > > > > * Rename dc_ti with chtdc_ti in all places
> > > > > > > > > > > > > * Driver/kconfig renames accordingly
> > > > > > > > > > > > > * Added acks by Andy and Mika
> > > > > > > > > > > > > v1->v2:
> > > > > > > > > > > > > * Minor cleanups as suggested by Andy
> > > > > > > > > > > > > 
> > > > > > > > > > > > >  drivers/mfd/Kconfig                   |  13 +++
> > > > > > > > > > > > >  drivers/mfd/Makefile                  |   1 +
> > > > > > > > > > > > >  drivers/mfd/intel_soc_pmic_chtdc_ti.c | 184 ++++++++++++++++++++++++++++++++++
> > > > > > > > > > > > >  3 files changed, 198 insertions(+)
> > > > > > > > > > > > >  create mode 100644 drivers/mfd/intel_soc_pmic_chtdc_ti.c
> > > > > > > > > > > > 
> > > > > > > > > > > > For my own reference:
> > > > > > > > > > > >   Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> > > > > > > > > > > 
> > > > > > > > > > > Thanks!
> > > > > > > > > > > 
> > > > > > > > > > > Now the question is how to deal with these.  It's no critical things,
> > > > > > > > > > > so I'm OK to postpone for 4.15.  OTOH, it's really a new
> > > > > > > > > > > device-specific stuff, thus it can't break anything else, and it'd be
> > > > > > > > > > > fairly safe to add it for 4.14 although it's at a bit late stage.
> > > > > > > > > > 
> > > > > > > > > > Yes, you are over 2 weeks late for v4.14.  It will have to be v4.15.
> > > > > > > > > 
> > > > > > > > > OK, I'll ring your bells again once when 4.15 development is opened.
> > > > > > > > 
> > > > > > > > Please don't.  Just collect all the Acks you have received and sent
> > > > > > > > out the set again changing [PATCH] for [RESEND].  Only if there
> > > > > > > > haven't been any code changes of course. 
> > > > > > >   
> > > > > > > You seem to have applied the patches in some branch, but still do I
> > > > > > > need to resend the whole patches?
> > > > > > 
> > > > > > That's up to the Platform Maintainers.
> > > > > > 
> > > > > > Since the MFD and ACPI are applied, you do not need to resend those.
> > > > > > 
> > > > > > > BTW, was patch 2/3 applied?  I miss your notification mail.
> > > > > > 
> > > > > > Patch 2 needs to be applied into the Platform tree.
> > > > > 
> > > > > Actually, that's drivers/platform/x86/ so it falls under
> > > > > X86 PLATFORM DRIVERS and it has already been ACKed by Andy who is
> > > > > one of the maintainers of that.
> > > > > 
> > > > > Andy, Darren, can patch [2/3] from this series go in via the MFD tree?
> > > > 
> > > > ... without an immutable branch.
> > > 
> > > Why can't it be immutable?  You just don't branch off the commit
> > > containing these three patches, and don't touch any longer on that, so
> > > that other trees can pull it in; it's all what we need.
> > 
> > Firstly, the MFD main branch is not immutable.
> 
> That's bad in general :)
> 
> > Secondly, you cannot simply pull a patch in from another tree.
> 
> Many trees do it sometimes as long as the branch is guaranteed to be
> persistent / immutable, prepared for the next kernel.
> 
> > All of
> > the patches before it and your local base will be pulled in too.  This
> > is why we create purposely created immutable branches which *only*
> > contain the patches required by other repos.
> 
> Yes, ideally we should have a clean base for such a shared branch.
> 
> > > > Which also means all changes to this
> > > > file due for v4.15 would have to come in via the MFD tree too.
> > > > 
> > > > This is sub optimal IMHO.  I'd rather it was fed through the proper
> > > > tree(s), so we can continue our normal flow for subsequent changes.
> > > 
> > > Other trees sometimes pull this kind of "immutable" branches, too.
> > > I see no big problem there.
> > 
> > There are no valid reason to create an IB for this case.
> 
> I don't understand why makes it so difficult.  Looking at the
> procedure you mentioned in this thread:
> 
> ==
> 1. Checkout a new branch based on the same (or earlier, but I always
> use the same) commit as the main branch.
> 
> 2. Apply the patches in the normal way, only this time you usually need
> to interactively rebase and 'reword' them to add any missing
> Acks/Reviewed-bys.
> 
> 3. Tag and sign the branch with a suitable tag name and tag
> description. 
> 
> 4. Push branch and tag
> 
> 5. Create pull-request text
> 
> 6. Send a formatted email with the pull-request text.
> ==
> 
> 1 is easy, you can take 4.14-rc1 once when released.  This kind of
>   thing is done by many people regularly for opening a topic
>   development branch.
> 
> 2 is the very standard procedure.  You'd need to add tags in anyway
>   even for normal branches.
> 
> 3, the signed tagging can be optional, only when requested.
>   Of course, it's safer to have one, but not mandatory.
>   Branch naming?  It's not more difficult than thinking of the next
>   android version code name :)
> 
> 4, normal procedure. 
> 
> 5 and 6 are relaxed in this case, just a one-line notification mail to
>   this thread should suffice.
> 
> 
> ... so I really can't see any specially time-consuming or exhausting
> step in the above.  Usually most time-consuming stuff is rather the
> code review and the build test.  But this isn't different from the
> normal case.
> 
> Or am I missing anything?

Yes, clearly. ;)

Okay, I think we've spent enough time discussing this now.  All of the
information you need is contained in my previous emails.  You now know
all of the reasons for why we don't create immutable branches for
every patch-set that comes in -- just ones which real dependencies.

It's time to agree to disagree and get on with some real work. :)

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v5 1/3] mfd: Add support for Cherry Trail Dollar Cove TI PMIC

[Lee Jones]

On Mon, 04 Sep 2017, Takashi Iwai wrote:

> This patch adds the MFD driver for Dollar Cove (TI version) PMIC with
> ACPI INT33F5 that is found on some Intel Cherry Trail devices.
> The driver is based on the original work by Intel, found at:
>   https://github.com/01org/ProductionKernelQuilts
> 
> This is a minimal version for adding the basic resources.  Currently,
> only ACPI PMIC opregion and the external power-button are used.
> 
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891
> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> Signed-off-by: Takashi Iwai <tiwai@suse.de>
> ---
> v4->v5:
> * Minor coding-style fixes suggested by Lee
> * Put GPL text
> v3->v4:
> * no change for this patch
> v2->v3:
> * Rename dc_ti with chtdc_ti in all places
> * Driver/kconfig renames accordingly
> * Added acks by Andy and Mika
> v1->v2:
> * Minor cleanups as suggested by Andy
> 
>  drivers/mfd/Kconfig                   |  13 +++
>  drivers/mfd/Makefile                  |   1 +
>  drivers/mfd/intel_soc_pmic_chtdc_ti.c | 184 ++++++++++++++++++++++++++++++++++
>  3 files changed, 198 insertions(+)
>  create mode 100644 drivers/mfd/intel_soc_pmic_chtdc_ti.c

Applied for v4.15, thanks.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[PATCH v5 2/3] platform/x86: Add support for Dollar Cove TI power button

[Takashi Iwai]

This provides a new input driver for supporting the power button on
Dollar Cove TI PMIC, found on Cherrytrail-based devices.
The patch is based on the original work by Intel, found at:
  https://github.com/01org/ProductionKernelQuilts

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
v4->v5:
* no change in this driver
v3->v4:
* Minor fixes suggested by Dmitry
* Rephrase Kconfig help texts
v2->v3:
* Rename dc_ti with chtdc_ti in all places
* Driver/kconfig renames accordingly
* Constification
* Added acks by Andy and Mika
v1->v2:
* Move power-button driver to platform/x86, driver renames accordingly
* Add missing wake-irq cleanup to power-button driver

 drivers/platform/x86/Kconfig                 | 11 ++++
 drivers/platform/x86/Makefile                |  1 +
 drivers/platform/x86/intel_chtdc_ti_pwrbtn.c | 94 ++++++++++++++++++++++++++++
 3 files changed, 106 insertions(+)
 create mode 100644 drivers/platform/x86/intel_chtdc_ti_pwrbtn.c

diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 80b87954f6dd..c3c02b6b2a7f 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -1139,6 +1139,17 @@ config SILEAD_DMI
 	  with the OS-image for the device. This option supplies the missing
 	  information. Enable this for x86 tablets with Silead touchscreens.
 
+config INTEL_CHTDC_TI_PWRBTN
+	tristate "Intel Cherry Trail Dollar Cove TI power button driver"
+	depends on INTEL_SOC_PMIC_CHTDC_TI
+	depends on INPUT
+	---help---
+	  This option adds a power button driver driver for Dollar Cove TI
+	  PMIC on Intel Cherry Trail devices.
+
+	  To compile this driver as a module, choose M here: the module
+	  will be called intel_chtdc_ti_pwrbtn.
+
 endif # X86_PLATFORM_DEVICES
 
 config PMC_ATOM
diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
index 91cec1751461..6a14fdbcecbe 100644
--- a/drivers/platform/x86/Makefile
+++ b/drivers/platform/x86/Makefile
@@ -83,3 +83,4 @@ obj-$(CONFIG_PMC_ATOM)		+= pmc_atom.o
 obj-$(CONFIG_MLX_PLATFORM)	+= mlx-platform.o
 obj-$(CONFIG_MLX_CPLD_PLATFORM)	+= mlxcpld-hotplug.o
 obj-$(CONFIG_INTEL_TURBO_MAX_3) += intel_turbo_max_3.o
+obj-$(CONFIG_INTEL_CHTDC_TI_PWRBTN)	+= intel_chtdc_ti_pwrbtn.o
diff --git a/drivers/platform/x86/intel_chtdc_ti_pwrbtn.c b/drivers/platform/x86/intel_chtdc_ti_pwrbtn.c
new file mode 100644
index 000000000000..ddd5d9027e92
--- /dev/null
+++ b/drivers/platform/x86/intel_chtdc_ti_pwrbtn.c
@@ -0,0 +1,94 @@
+/*
+ * Power-button driver for Dollar Cove TI PMIC
+ * Copyright (C) 2014 Intel Corp
+ * Copyright (c) 2017 Takashi Iwai <tiwai@suse.de>
+ */
+
+#include <linux/init.h>
+#include <linux/input.h>
+#include <linux/interrupt.h>
+#include <linux/device.h>
+#include <linux/mfd/intel_soc_pmic.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/pm_wakeirq.h>
+#include <linux/slab.h>
+
+#define CHTDC_TI_SIRQ_REG	0x3
+#define SIRQ_PWRBTN_REL		BIT(0)
+
+static irqreturn_t chtdc_ti_pwrbtn_interrupt(int irq, void *dev_id)
+{
+	struct input_dev *input = dev_id;
+	struct device *dev = input->dev.parent;
+	struct regmap *regmap = dev_get_drvdata(dev);
+	int state;
+
+	if (!regmap_read(regmap, CHTDC_TI_SIRQ_REG, &state)) {
+		dev_dbg(dev, "SIRQ_REG=0x%x\n", state);
+		input_report_key(input, KEY_POWER, !(state & SIRQ_PWRBTN_REL));
+		input_sync(input);
+	}
+
+	return IRQ_HANDLED;
+}
+
+static int chtdc_ti_pwrbtn_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct intel_soc_pmic *pmic = dev_get_drvdata(dev->parent);
+	struct input_dev *input;
+	int irq, err;
+
+	irq = platform_get_irq(pdev, 0);
+	if (irq < 0)
+		return irq;
+	input = devm_input_allocate_device(dev);
+	if (!input)
+		return -ENOMEM;
+	input->name = pdev->name;
+	input->phys = "power-button/input0";
+	input->id.bustype = BUS_HOST;
+	input_set_capability(input, EV_KEY, KEY_POWER);
+	err = input_register_device(input);
+	if (err)
+		return err;
+
+	dev_set_drvdata(dev, pmic->regmap);
+
+	err = devm_request_threaded_irq(dev, irq, NULL,
+					chtdc_ti_pwrbtn_interrupt,
+					0, KBUILD_MODNAME, input);
+	if (err)
+		return err;
+
+	device_init_wakeup(dev, true);
+	dev_pm_set_wake_irq(dev, irq);
+	return 0;
+}
+
+static int chtdc_ti_pwrbtn_remove(struct platform_device *pdev)
+{
+	dev_pm_clear_wake_irq(&pdev->dev);
+	device_init_wakeup(&pdev->dev, false);
+	return 0;
+}
+
+static const struct platform_device_id chtdc_ti_pwrbtn_id_table[] = {
+	{ .name = "chtdc_ti_pwrbtn" },
+	{},
+};
+MODULE_DEVICE_TABLE(platform, chtdc_ti_pwrbtn_id_table);
+
+static struct platform_driver chtdc_ti_pwrbtn_driver = {
+	.driver = {
+		.name	= KBUILD_MODNAME,
+	},
+	.probe		= chtdc_ti_pwrbtn_probe,
+	.remove		= chtdc_ti_pwrbtn_remove,
+	.id_table	= chtdc_ti_pwrbtn_id_table,
+};
+module_platform_driver(chtdc_ti_pwrbtn_driver);
+
+MODULE_DESCRIPTION("Power-button driver for Dollar Cove TI PMIC");
+MODULE_LICENSE("GPL v2");
-- 
2.14.1

[PATCH v5 3/3] ACPI / PMIC: Add opregion driver for Intel Dollar Cove TI PMIC

[Takashi Iwai]

This patch adds the opregion driver for Dollar Cove TI PMIC on Intel
Cherry Trail devices.  The patch is based on the original work by
Intel, found at:
      https://github.com/01org/ProductionKernelQuilts
with many cleanups and rewrites.

The driver is currently provided only as built-in to follow other
PMIC opregion drivers convention.

The re-enumeration of devices at probe is required for fixing the
issues on HP x2 210 G2.  See bug#195689.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=195689
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
v4->v5:
* no change in this driver
v3->v4:
* Rename dc_ti with chtdc_ti in all places
v2->v3:
* Rename dc_ti with chtdc_ti in all places
* Driver/kconfig renames accordingly
* Constification
* Added acks by Andy and Mika
v1->v2:
* get_raw_temp cleanup in opregion driver, mention about register
  endianess

 drivers/acpi/Kconfig                    |   6 ++
 drivers/acpi/Makefile                   |   1 +
 drivers/acpi/pmic/intel_pmic_chtdc_ti.c | 137 ++++++++++++++++++++++++++++++++
 3 files changed, 144 insertions(+)
 create mode 100644 drivers/acpi/pmic/intel_pmic_chtdc_ti.c

diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 1ce52f84dc23..176fae699891 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -521,6 +521,12 @@ config CHT_WC_PMIC_OPREGION
 	help
 	  This config adds ACPI operation region support for CHT Whiskey Cove PMIC.
 
+config CHT_DC_TI_PMIC_OPREGION
+	bool "ACPI operation region support for Dollar Cove TI PMIC"
+	depends on INTEL_SOC_PMIC_CHTDC_TI
+	help
+	  This config adds ACPI operation region support for Dollar Cove TI PMIC.
+
 endif
 
 config ACPI_CONFIGFS
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index b1aacfc62b1f..cd228822d4a3 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -103,6 +103,7 @@ obj-$(CONFIG_CRC_PMIC_OPREGION) += pmic/intel_pmic_crc.o
 obj-$(CONFIG_XPOWER_PMIC_OPREGION) += pmic/intel_pmic_xpower.o
 obj-$(CONFIG_BXT_WC_PMIC_OPREGION) += pmic/intel_pmic_bxtwc.o
 obj-$(CONFIG_CHT_WC_PMIC_OPREGION) += pmic/intel_pmic_chtwc.o
+obj-$(CONFIG_CHT_DC_TI_PMIC_OPREGION) += pmic/intel_pmic_chtdc_ti.o
 
 obj-$(CONFIG_ACPI_CONFIGFS)	+= acpi_configfs.o
 
diff --git a/drivers/acpi/pmic/intel_pmic_chtdc_ti.c b/drivers/acpi/pmic/intel_pmic_chtdc_ti.c
new file mode 100644
index 000000000000..109c1e9c9c7a
--- /dev/null
+++ b/drivers/acpi/pmic/intel_pmic_chtdc_ti.c
@@ -0,0 +1,137 @@
+/*
+ * Dollar Cove TI PMIC operation region driver
+ * Copyright (C) 2014 Intel Corporation. All rights reserved.
+ *
+ * Rewritten and cleaned up
+ * Copyright (C) 2017 Takashi Iwai <tiwai@suse.de>
+ */
+
+#include <linux/acpi.h>
+#include <linux/init.h>
+#include <linux/mfd/intel_soc_pmic.h>
+#include <linux/platform_device.h>
+#include "intel_pmic.h"
+
+/* registers stored in 16bit BE (high:low, total 10bit) */
+#define CHTDC_TI_VBAT		0x54
+#define CHTDC_TI_DIETEMP	0x56
+#define CHTDC_TI_BPTHERM	0x58
+#define CHTDC_TI_GPADC		0x5a
+
+static struct pmic_table chtdc_ti_power_table[] = {
+	{ .address = 0x00, .reg = 0x41 },
+	{ .address = 0x04, .reg = 0x42 },
+	{ .address = 0x08, .reg = 0x43 },
+	{ .address = 0x0c, .reg = 0x45 },
+	{ .address = 0x10, .reg = 0x46 },
+	{ .address = 0x14, .reg = 0x47 },
+	{ .address = 0x18, .reg = 0x48 },
+	{ .address = 0x1c, .reg = 0x49 },
+	{ .address = 0x20, .reg = 0x4a },
+	{ .address = 0x24, .reg = 0x4b },
+	{ .address = 0x28, .reg = 0x4c },
+	{ .address = 0x2c, .reg = 0x4d },
+	{ .address = 0x30, .reg = 0x4e },
+};
+
+static struct pmic_table chtdc_ti_thermal_table[] = {
+	{
+		.address = 0x00,
+		.reg = CHTDC_TI_GPADC
+	},
+	{
+		.address = 0x0c,
+		.reg = CHTDC_TI_GPADC
+	},
+	/* TMP2 -> SYSTEMP */
+	{
+		.address = 0x18,
+		.reg = CHTDC_TI_GPADC
+	},
+	/* TMP3 -> BPTHERM */
+	{
+		.address = 0x24,
+		.reg = CHTDC_TI_BPTHERM
+	},
+	{
+		.address = 0x30,
+		.reg = CHTDC_TI_GPADC
+	},
+	/* TMP5 -> DIETEMP */
+	{
+		.address = 0x3c,
+		.reg = CHTDC_TI_DIETEMP
+	},
+};
+
+static int chtdc_ti_pmic_get_power(struct regmap *regmap, int reg, int bit,
+				   u64 *value)
+{
+	int data;
+
+	if (regmap_read(regmap, reg, &data))
+		return -EIO;
+
+	*value = data & 1;
+	return 0;
+}
+
+static int chtdc_ti_pmic_update_power(struct regmap *regmap, int reg, int bit,
+				      bool on)
+{
+	return regmap_update_bits(regmap, reg, 1, on);
+}
+
+static int chtdc_ti_pmic_get_raw_temp(struct regmap *regmap, int reg)
+{
+	u8 buf[2];
+
+	if (regmap_bulk_read(regmap, reg, buf, 2))
+		return -EIO;
+
+	/* stored in big-endian */
+	return ((buf[0] & 0x03) << 8) | buf[1];
+}
+
+static struct intel_pmic_opregion_data chtdc_ti_pmic_opregion_data = {
+	.get_power = chtdc_ti_pmic_get_power,
+	.update_power = chtdc_ti_pmic_update_power,
+	.get_raw_temp = chtdc_ti_pmic_get_raw_temp,
+	.power_table = chtdc_ti_power_table,
+	.power_table_count = ARRAY_SIZE(chtdc_ti_power_table),
+	.thermal_table = chtdc_ti_thermal_table,
+	.thermal_table_count = ARRAY_SIZE(chtdc_ti_thermal_table),
+};
+
+static int chtdc_ti_pmic_opregion_probe(struct platform_device *pdev)
+{
+	struct intel_soc_pmic *pmic = dev_get_drvdata(pdev->dev.parent);
+	int err;
+
+	err = intel_pmic_install_opregion_handler(&pdev->dev,
+			ACPI_HANDLE(pdev->dev.parent), pmic->regmap,
+			&chtdc_ti_pmic_opregion_data);
+	if (err < 0)
+		return err;
+
+	/* Re-enumerate devices depending on PMIC */
+	acpi_walk_dep_device_list(ACPI_HANDLE(pdev->dev.parent));
+	return 0;
+}
+
+static const struct platform_device_id chtdc_ti_pmic_opregion_id_table[] = {
+	{ .name = "chtdc_ti_region" },
+	{},
+};
+
+static struct platform_driver chtdc_ti_pmic_opregion_driver = {
+	.probe = chtdc_ti_pmic_opregion_probe,
+	.driver = {
+		.name = "cht_dollar_cove_ti_pmic",
+	},
+	.id_table = chtdc_ti_pmic_opregion_id_table,
+};
+module_platform_driver(chtdc_ti_pmic_opregion_driver);
+
+MODULE_DESCRIPTION("Dollar Cove TI PMIC opregion driver");
+MODULE_LICENSE("GPL v2");
-- 
2.14.1

Re: [PATCH v5 3/3] ACPI / PMIC: Add opregion driver for Intel Dollar Cove TI PMIC

[Lee Jones]

On Mon, 04 Sep 2017, Takashi Iwai wrote:

> This patch adds the opregion driver for Dollar Cove TI PMIC on Intel
> Cherry Trail devices.  The patch is based on the original work by
> Intel, found at:
>       https://github.com/01org/ProductionKernelQuilts
> with many cleanups and rewrites.
> 
> The driver is currently provided only as built-in to follow other
> PMIC opregion drivers convention.
> 
> The re-enumeration of devices at probe is required for fixing the
> issues on HP x2 210 G2.  See bug#195689.
> 
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=195689
> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> Signed-off-by: Takashi Iwai <tiwai@suse.de>
> ---
> v4->v5:
> * no change in this driver
> v3->v4:
> * Rename dc_ti with chtdc_ti in all places
> v2->v3:
> * Rename dc_ti with chtdc_ti in all places
> * Driver/kconfig renames accordingly
> * Constification
> * Added acks by Andy and Mika
> v1->v2:
> * get_raw_temp cleanup in opregion driver, mention about register
>   endianess
> 
>  drivers/acpi/Kconfig                    |   6 ++
>  drivers/acpi/Makefile                   |   1 +
>  drivers/acpi/pmic/intel_pmic_chtdc_ti.c | 137 ++++++++++++++++++++++++++++++++
>  3 files changed, 144 insertions(+)
>  create mode 100644 drivers/acpi/pmic/intel_pmic_chtdc_ti.c

Applied for v4.15, thanks.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[PATCH v2 0/3] Dollar Cove TI PMIC support for Intel Cherry Trail

[Takashi Iwai]

Hi,

this is the revised patch set to add the support for Dollar Cove TI
PMIC found on some Intel Cherry Trail laptops / tablets.  All drivers
are based on the original code from Intel downstream patches, with
lots of rewrites and cleanups.  MFD driver is implemented as a
stand-alone like a few other variants, and the input driver got a diet
in a minimalistic form.

The patch set has been tested on ASUS E100H and E200H, as well as on
HP x210.

v1->v2:
- Minor cleanups in mfd driver code as suggested by Andy
- Move power-button driver to platform/x86, driver renames accordingly
- Add missing wake-irq cleanup to power-button driver
- get_raw_temp cleanup in opregion driver, mention about register
  endianess


thanks,

Takashi

===

Takashi Iwai (3):
  mfd: Add support for Cherry Trail Dollar Cove TI PMIC
  platform/x86: Add support for Dollar Cove TI power button
  ACPI / PMIC: Add opregion driver for Intel Dollar Cove TI PMIC

 drivers/acpi/Kconfig                      |   6 +
 drivers/acpi/Makefile                     |   1 +
 drivers/acpi/pmic/intel_pmic_dc_ti.c      | 139 +++++++++++++++++++++++
 drivers/mfd/Kconfig                       |  13 +++
 drivers/mfd/Makefile                      |   1 +
 drivers/mfd/intel_soc_pmic_dc_ti.c        | 182 ++++++++++++++++++++++++++++++
 drivers/platform/x86/Kconfig              |   8 ++
 drivers/platform/x86/Makefile             |   1 +
 drivers/platform/x86/intel_dc_ti_pwrbtn.c |  96 ++++++++++++++++
 9 files changed, 447 insertions(+)
 create mode 100644 drivers/acpi/pmic/intel_pmic_dc_ti.c
 create mode 100644 drivers/mfd/intel_soc_pmic_dc_ti.c
 create mode 100644 drivers/platform/x86/intel_dc_ti_pwrbtn.c

-- 
2.14.0

[PATCH v2 1/3] mfd: Add support for Cherry Trail Dollar Cove TI PMIC

[Takashi Iwai]

This patch adds the MFD driver for Dollar Cove TI PMIC (ACPI INT33F5)
that is found on some Intel Cherry Trail devices.
The driver is based on the original work by Intel, found at:
  https://github.com/01org/ProductionKernelQuilts

This is a minimal version for adding the basic resources.  Currently,
only ACPI PMIC opregion and the external power-button are used.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891
Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
v1->v2:
* Minor cleanups as suggested by Andy

 drivers/mfd/Kconfig                |  13 +++
 drivers/mfd/Makefile               |   1 +
 drivers/mfd/intel_soc_pmic_dc_ti.c | 182 +++++++++++++++++++++++++++++++++++++
 3 files changed, 196 insertions(+)
 create mode 100644 drivers/mfd/intel_soc_pmic_dc_ti.c

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 94ad2c1c3d90..28c12bb50c9f 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -496,6 +496,19 @@ config INTEL_SOC_PMIC_CHTWC
 	  available before any devices using it are probed. This option also
 	  causes the designware-i2c driver to be builtin for the same reason.
 
+config INTEL_SOC_PMIC_DC_TI
+	tristate "Support for Dollar Cove TI PMIC"
+	depends on GPIOLIB
+	depends on I2C
+	depends on ACPI
+	depends on X86
+	select MFD_CORE
+	select REGMAP_I2C
+	select REGMAP_IRQ
+	help
+	  Select this option for supporting Dollar Cove TI PMIC device that is
+	  found on some Intel Cherry Trail systems.
+
 config MFD_INTEL_LPSS
 	tristate
 	select COMMON_CLK
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 080793b3fd0e..16c4fe519d30 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -216,6 +216,7 @@ intel-soc-pmic-objs		:= intel_soc_pmic_core.o intel_soc_pmic_crc.o
 obj-$(CONFIG_INTEL_SOC_PMIC)	+= intel-soc-pmic.o
 obj-$(CONFIG_INTEL_SOC_PMIC_BXTWC)	+= intel_soc_pmic_bxtwc.o
 obj-$(CONFIG_INTEL_SOC_PMIC_CHTWC)	+= intel_soc_pmic_chtwc.o
+obj-$(CONFIG_INTEL_SOC_PMIC_DC_TI)	+= intel_soc_pmic_dc_ti.o
 obj-$(CONFIG_MFD_MT6397)	+= mt6397-core.o
 
 obj-$(CONFIG_MFD_ALTERA_A10SR)	+= altera-a10sr.o
diff --git a/drivers/mfd/intel_soc_pmic_dc_ti.c b/drivers/mfd/intel_soc_pmic_dc_ti.c
new file mode 100644
index 000000000000..3ba1625eb44b
--- /dev/null
+++ b/drivers/mfd/intel_soc_pmic_dc_ti.c
@@ -0,0 +1,182 @@
+/*
+ * Device access for Dollar Cove TI PMIC
+ * Copyright (c) 2014, Intel Corporation.
+ *   Author: Ramakrishna Pallala <ramakrishna.pallala@intel.com>
+ *
+ * Cleanup and forward-ported
+ *   Copyright (c) 2017 Takashi Iwai <tiwai@suse.de>
+ */
+
+#include <linux/acpi.h>
+#include <linux/interrupt.h>
+#include <linux/i2c.h>
+#include <linux/module.h>
+#include <linux/regmap.h>
+#include <linux/mfd/core.h>
+#include <linux/mfd/intel_soc_pmic.h>
+
+#define DC_TI_IRQLVL1		0x01
+#define DC_TI_MASK_IRQLVL1	0x02
+
+/* Level 1 IRQs */
+enum {
+	DC_TI_PWRBTN = 0,	/* power button */
+	DC_TI_DIETMPWARN,	/* thermal */
+	DC_TI_ADCCMPL,		/* ADC */
+	/* no irq 3 */
+	DC_TI_VBATLOW = 4,	/* battery */
+	DC_TI_VBUSDET,		/* power source */
+	/* no irq 6 */
+	DC_TI_CCEOCAL = 7,	/* battery */
+};
+
+static struct resource power_button_resources[] = {
+	DEFINE_RES_IRQ(DC_TI_PWRBTN),
+};
+
+static struct resource thermal_resources[] = {
+	DEFINE_RES_IRQ(DC_TI_DIETMPWARN),
+};
+
+static struct resource adc_resources[] = {
+	DEFINE_RES_IRQ(DC_TI_ADCCMPL),
+};
+
+static struct resource pwrsrc_resources[] = {
+	DEFINE_RES_IRQ(DC_TI_VBUSDET),
+};
+
+static struct resource battery_resources[] = {
+	DEFINE_RES_IRQ(DC_TI_VBATLOW),
+	DEFINE_RES_IRQ(DC_TI_CCEOCAL),
+};
+
+static struct mfd_cell dc_ti_dev[] = {
+	{
+		.name = "dc_ti_pwrbtn",
+		.num_resources = ARRAY_SIZE(power_button_resources),
+		.resources = power_button_resources,
+	},
+	{
+		.name = "dc_ti_adc",
+		.num_resources = ARRAY_SIZE(adc_resources),
+		.resources = adc_resources,
+	},
+	{
+		.name = "dc_ti_thermal",
+		.num_resources = ARRAY_SIZE(thermal_resources),
+		.resources = thermal_resources,
+	},
+	{
+		.name = "dc_ti_pwrsrc",
+		.num_resources = ARRAY_SIZE(pwrsrc_resources),
+		.resources = pwrsrc_resources,
+	},
+	{
+		.name = "dc_ti_battery",
+		.num_resources = ARRAY_SIZE(battery_resources),
+		.resources = battery_resources,
+	},
+	{
+		.name = "dc_ti_region",
+	},
+};
+
+static const struct regmap_config dc_ti_regmap_config = {
+	.reg_bits = 8,
+	.val_bits = 8,
+	.max_register = 128,
+	.cache_type = REGCACHE_NONE,
+};
+
+static const struct regmap_irq dc_ti_irqs[] = {
+	REGMAP_IRQ_REG(DC_TI_PWRBTN, 0, BIT(DC_TI_PWRBTN)),
+	REGMAP_IRQ_REG(DC_TI_DIETMPWARN, 0, BIT(DC_TI_DIETMPWARN)),
+	REGMAP_IRQ_REG(DC_TI_ADCCMPL, 0, BIT(DC_TI_ADCCMPL)),
+	REGMAP_IRQ_REG(DC_TI_VBATLOW, 0, BIT(DC_TI_VBATLOW)),
+	REGMAP_IRQ_REG(DC_TI_VBUSDET, 0, BIT(DC_TI_VBUSDET)),
+	REGMAP_IRQ_REG(DC_TI_CCEOCAL, 0, BIT(DC_TI_CCEOCAL)),
+};
+
+static const struct regmap_irq_chip dc_ti_irq_chip = {
+	.name = KBUILD_MODNAME,
+	.irqs = dc_ti_irqs,
+	.num_irqs = ARRAY_SIZE(dc_ti_irqs),
+	.num_regs = 1,
+	.status_base = DC_TI_IRQLVL1,
+	.mask_base = DC_TI_MASK_IRQLVL1,
+	.ack_base = DC_TI_IRQLVL1,
+};
+
+static int dc_ti_probe(struct i2c_client *i2c)
+{
+	struct device *dev = &i2c->dev;
+	struct intel_soc_pmic *pmic;
+	int ret;
+
+	pmic = devm_kzalloc(dev, sizeof(*pmic), GFP_KERNEL);
+	if (!pmic)
+		return -ENOMEM;
+
+	i2c_set_clientdata(i2c, pmic);
+
+	pmic->regmap = devm_regmap_init_i2c(i2c, &dc_ti_regmap_config);
+	if (IS_ERR(pmic->regmap))
+		return PTR_ERR(pmic->regmap);
+	pmic->irq = i2c->irq;
+
+	ret = devm_regmap_add_irq_chip(dev, pmic->regmap, pmic->irq,
+				       IRQF_ONESHOT, 0,
+				       &dc_ti_irq_chip, &pmic->irq_chip_data);
+	if (ret)
+		return ret;
+
+	return devm_mfd_add_devices(dev, PLATFORM_DEVID_NONE, dc_ti_dev,
+				    ARRAY_SIZE(dc_ti_dev), NULL, 0,
+				    regmap_irq_get_domain(pmic->irq_chip_data));
+}
+
+static void dc_ti_shutdown(struct i2c_client *i2c)
+{
+	struct intel_soc_pmic *pmic = i2c_get_clientdata(i2c);
+
+	disable_irq(pmic->irq);
+}
+
+static int __maybe_unused dc_ti_suspend(struct device *dev)
+{
+	struct intel_soc_pmic *pmic = dev_get_drvdata(dev);
+
+	disable_irq(pmic->irq);
+	return 0;
+}
+
+static int __maybe_unused dc_ti_resume(struct device *dev)
+{
+	struct intel_soc_pmic *pmic = dev_get_drvdata(dev);
+
+	enable_irq(pmic->irq);
+	return 0;
+}
+
+static SIMPLE_DEV_PM_OPS(dc_ti_pm_ops, dc_ti_suspend, dc_ti_resume);
+
+static const struct acpi_device_id dc_ti_acpi_ids[] = {
+	{ "INT33F5" },
+	{ },
+};
+MODULE_DEVICE_TABLE(acpi, dc_ti_acpi_ids);
+
+static struct i2c_driver dc_ti_i2c_driver = {
+	.driver = {
+		.name = KBUILD_MODNAME,
+		.pm = &dc_ti_pm_ops,
+		.acpi_match_table = dc_ti_acpi_ids,
+	},
+	.probe_new = dc_ti_probe,
+	.shutdown = dc_ti_shutdown,
+};
+module_i2c_driver(dc_ti_i2c_driver);
+
+MODULE_DESCRIPTION("I2C driver for Intel SoC Dollar Cove TI PMIC");
+MODULE_LICENSE("GPL v2");
-- 
2.14.0

Re: [PATCH v2 1/3] mfd: Add support for Cherry Trail Dollar Cove TI PMIC

[Mika Westerberg]

On Thu, Aug 24, 2017 at 10:11:39AM +0200, Takashi Iwai wrote:
> This patch adds the MFD driver for Dollar Cove TI PMIC (ACPI INT33F5)
> that is found on some Intel Cherry Trail devices.
> The driver is based on the original work by Intel, found at:
>   https://github.com/01org/ProductionKernelQuilts
> 
> This is a minimal version for adding the basic resources.  Currently,
> only ACPI PMIC opregion and the external power-button are used.
> 
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891
> Signed-off-by: Takashi Iwai <tiwai@suse.de>

Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>

Re: [PATCH v2 1/3] mfd: Add support for Cherry Trail Dollar Cove TI PMIC

[Andy Shevchenko]

On Thu, Aug 24, 2017 at 11:11 AM, Takashi Iwai <tiwai@suse.de> wrote:
> This patch adds the MFD driver for Dollar Cove TI PMIC (ACPI INT33F5)
> that is found on some Intel Cherry Trail devices.
> The driver is based on the original work by Intel, found at:
>   https://github.com/01org/ProductionKernelQuilts
>
> This is a minimal version for adding the basic resources.  Currently,
> only ACPI PMIC opregion and the external power-button are used.
>

Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>

JFYI, IRQ registers are called as IRQ and MIRQ in datasheet. Though I
think we better to be in align with existing drivers.

> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891
> Signed-off-by: Takashi Iwai <tiwai@suse.de>
> ---
> v1->v2:
> * Minor cleanups as suggested by Andy
>
>  drivers/mfd/Kconfig                |  13 +++
>  drivers/mfd/Makefile               |   1 +
>  drivers/mfd/intel_soc_pmic_dc_ti.c | 182 +++++++++++++++++++++++++++++++++++++
>  3 files changed, 196 insertions(+)
>  create mode 100644 drivers/mfd/intel_soc_pmic_dc_ti.c
>
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 94ad2c1c3d90..28c12bb50c9f 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -496,6 +496,19 @@ config INTEL_SOC_PMIC_CHTWC
>           available before any devices using it are probed. This option also
>           causes the designware-i2c driver to be builtin for the same reason.
>
> +config INTEL_SOC_PMIC_DC_TI
> +       tristate "Support for Dollar Cove TI PMIC"
> +       depends on GPIOLIB
> +       depends on I2C
> +       depends on ACPI
> +       depends on X86
> +       select MFD_CORE
> +       select REGMAP_I2C
> +       select REGMAP_IRQ
> +       help
> +         Select this option for supporting Dollar Cove TI PMIC device that is
> +         found on some Intel Cherry Trail systems.
> +
>  config MFD_INTEL_LPSS
>         tristate
>         select COMMON_CLK
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 080793b3fd0e..16c4fe519d30 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -216,6 +216,7 @@ intel-soc-pmic-objs         := intel_soc_pmic_core.o intel_soc_pmic_crc.o
>  obj-$(CONFIG_INTEL_SOC_PMIC)   += intel-soc-pmic.o
>  obj-$(CONFIG_INTEL_SOC_PMIC_BXTWC)     += intel_soc_pmic_bxtwc.o
>  obj-$(CONFIG_INTEL_SOC_PMIC_CHTWC)     += intel_soc_pmic_chtwc.o
> +obj-$(CONFIG_INTEL_SOC_PMIC_DC_TI)     += intel_soc_pmic_dc_ti.o
>  obj-$(CONFIG_MFD_MT6397)       += mt6397-core.o
>
>  obj-$(CONFIG_MFD_ALTERA_A10SR) += altera-a10sr.o
> diff --git a/drivers/mfd/intel_soc_pmic_dc_ti.c b/drivers/mfd/intel_soc_pmic_dc_ti.c
> new file mode 100644
> index 000000000000..3ba1625eb44b
> --- /dev/null
> +++ b/drivers/mfd/intel_soc_pmic_dc_ti.c
> @@ -0,0 +1,182 @@
> +/*
> + * Device access for Dollar Cove TI PMIC
> + * Copyright (c) 2014, Intel Corporation.
> + *   Author: Ramakrishna Pallala <ramakrishna.pallala@intel.com>
> + *
> + * Cleanup and forward-ported
> + *   Copyright (c) 2017 Takashi Iwai <tiwai@suse.de>
> + */
> +
> +#include <linux/acpi.h>
> +#include <linux/interrupt.h>
> +#include <linux/i2c.h>
> +#include <linux/module.h>
> +#include <linux/regmap.h>
> +#include <linux/mfd/core.h>
> +#include <linux/mfd/intel_soc_pmic.h>
> +
> +#define DC_TI_IRQLVL1          0x01
> +#define DC_TI_MASK_IRQLVL1     0x02
> +
> +/* Level 1 IRQs */
> +enum {
> +       DC_TI_PWRBTN = 0,       /* power button */
> +       DC_TI_DIETMPWARN,       /* thermal */
> +       DC_TI_ADCCMPL,          /* ADC */
> +       /* no irq 3 */
> +       DC_TI_VBATLOW = 4,      /* battery */
> +       DC_TI_VBUSDET,          /* power source */
> +       /* no irq 6 */
> +       DC_TI_CCEOCAL = 7,      /* battery */
> +};
> +
> +static struct resource power_button_resources[] = {
> +       DEFINE_RES_IRQ(DC_TI_PWRBTN),
> +};
> +
> +static struct resource thermal_resources[] = {
> +       DEFINE_RES_IRQ(DC_TI_DIETMPWARN),
> +};
> +
> +static struct resource adc_resources[] = {
> +       DEFINE_RES_IRQ(DC_TI_ADCCMPL),
> +};
> +
> +static struct resource pwrsrc_resources[] = {
> +       DEFINE_RES_IRQ(DC_TI_VBUSDET),
> +};
> +
> +static struct resource battery_resources[] = {
> +       DEFINE_RES_IRQ(DC_TI_VBATLOW),
> +       DEFINE_RES_IRQ(DC_TI_CCEOCAL),
> +};
> +
> +static struct mfd_cell dc_ti_dev[] = {
> +       {
> +               .name = "dc_ti_pwrbtn",
> +               .num_resources = ARRAY_SIZE(power_button_resources),
> +               .resources = power_button_resources,
> +       },
> +       {
> +               .name = "dc_ti_adc",
> +               .num_resources = ARRAY_SIZE(adc_resources),
> +               .resources = adc_resources,
> +       },
> +       {
> +               .name = "dc_ti_thermal",
> +               .num_resources = ARRAY_SIZE(thermal_resources),
> +               .resources = thermal_resources,
> +       },
> +       {
> +               .name = "dc_ti_pwrsrc",
> +               .num_resources = ARRAY_SIZE(pwrsrc_resources),
> +               .resources = pwrsrc_resources,
> +       },
> +       {
> +               .name = "dc_ti_battery",
> +               .num_resources = ARRAY_SIZE(battery_resources),
> +               .resources = battery_resources,
> +       },
> +       {
> +               .name = "dc_ti_region",
> +       },
> +};
> +
> +static const struct regmap_config dc_ti_regmap_config = {
> +       .reg_bits = 8,
> +       .val_bits = 8,
> +       .max_register = 128,
> +       .cache_type = REGCACHE_NONE,
> +};
> +
> +static const struct regmap_irq dc_ti_irqs[] = {
> +       REGMAP_IRQ_REG(DC_TI_PWRBTN, 0, BIT(DC_TI_PWRBTN)),
> +       REGMAP_IRQ_REG(DC_TI_DIETMPWARN, 0, BIT(DC_TI_DIETMPWARN)),
> +       REGMAP_IRQ_REG(DC_TI_ADCCMPL, 0, BIT(DC_TI_ADCCMPL)),
> +       REGMAP_IRQ_REG(DC_TI_VBATLOW, 0, BIT(DC_TI_VBATLOW)),
> +       REGMAP_IRQ_REG(DC_TI_VBUSDET, 0, BIT(DC_TI_VBUSDET)),
> +       REGMAP_IRQ_REG(DC_TI_CCEOCAL, 0, BIT(DC_TI_CCEOCAL)),
> +};
> +
> +static const struct regmap_irq_chip dc_ti_irq_chip = {
> +       .name = KBUILD_MODNAME,
> +       .irqs = dc_ti_irqs,
> +       .num_irqs = ARRAY_SIZE(dc_ti_irqs),
> +       .num_regs = 1,
> +       .status_base = DC_TI_IRQLVL1,
> +       .mask_base = DC_TI_MASK_IRQLVL1,
> +       .ack_base = DC_TI_IRQLVL1,
> +};
> +
> +static int dc_ti_probe(struct i2c_client *i2c)
> +{
> +       struct device *dev = &i2c->dev;
> +       struct intel_soc_pmic *pmic;
> +       int ret;
> +
> +       pmic = devm_kzalloc(dev, sizeof(*pmic), GFP_KERNEL);
> +       if (!pmic)
> +               return -ENOMEM;
> +
> +       i2c_set_clientdata(i2c, pmic);
> +
> +       pmic->regmap = devm_regmap_init_i2c(i2c, &dc_ti_regmap_config);
> +       if (IS_ERR(pmic->regmap))
> +               return PTR_ERR(pmic->regmap);
> +       pmic->irq = i2c->irq;
> +
> +       ret = devm_regmap_add_irq_chip(dev, pmic->regmap, pmic->irq,
> +                                      IRQF_ONESHOT, 0,
> +                                      &dc_ti_irq_chip, &pmic->irq_chip_data);
> +       if (ret)
> +               return ret;
> +
> +       return devm_mfd_add_devices(dev, PLATFORM_DEVID_NONE, dc_ti_dev,
> +                                   ARRAY_SIZE(dc_ti_dev), NULL, 0,
> +                                   regmap_irq_get_domain(pmic->irq_chip_data));
> +}
> +
> +static void dc_ti_shutdown(struct i2c_client *i2c)
> +{
> +       struct intel_soc_pmic *pmic = i2c_get_clientdata(i2c);
> +
> +       disable_irq(pmic->irq);
> +}
> +
> +static int __maybe_unused dc_ti_suspend(struct device *dev)
> +{
> +       struct intel_soc_pmic *pmic = dev_get_drvdata(dev);
> +
> +       disable_irq(pmic->irq);
> +       return 0;
> +}
> +
> +static int __maybe_unused dc_ti_resume(struct device *dev)
> +{
> +       struct intel_soc_pmic *pmic = dev_get_drvdata(dev);
> +
> +       enable_irq(pmic->irq);
> +       return 0;
> +}
> +
> +static SIMPLE_DEV_PM_OPS(dc_ti_pm_ops, dc_ti_suspend, dc_ti_resume);
> +
> +static const struct acpi_device_id dc_ti_acpi_ids[] = {
> +       { "INT33F5" },
> +       { },
> +};
> +MODULE_DEVICE_TABLE(acpi, dc_ti_acpi_ids);
> +
> +static struct i2c_driver dc_ti_i2c_driver = {
> +       .driver = {
> +               .name = KBUILD_MODNAME,
> +               .pm = &dc_ti_pm_ops,
> +               .acpi_match_table = dc_ti_acpi_ids,
> +       },
> +       .probe_new = dc_ti_probe,
> +       .shutdown = dc_ti_shutdown,
> +};
> +module_i2c_driver(dc_ti_i2c_driver);
> +
> +MODULE_DESCRIPTION("I2C driver for Intel SoC Dollar Cove TI PMIC");
> +MODULE_LICENSE("GPL v2");
> --
> 2.14.0
>



-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 1/3] mfd: Add support for Cherry Trail Dollar Cove TI PMIC

[Lee Jones]

On Thu, 24 Aug 2017, Takashi Iwai wrote:

> This patch adds the MFD driver for Dollar Cove TI PMIC (ACPI INT33F5)
> that is found on some Intel Cherry Trail devices.
> The driver is based on the original work by Intel, found at:
>   https://github.com/01org/ProductionKernelQuilts
> 
> This is a minimal version for adding the basic resources.  Currently,
> only ACPI PMIC opregion and the external power-button are used.
> 
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891
> Signed-off-by: Takashi Iwai <tiwai@suse.de>
> ---
> v1->v2:
> * Minor cleanups as suggested by Andy
> 
>  drivers/mfd/Kconfig                |  13 +++
>  drivers/mfd/Makefile               |   1 +
>  drivers/mfd/intel_soc_pmic_dc_ti.c | 182 +++++++++++++++++++++++++++++++++++++
>  3 files changed, 196 insertions(+)
>  create mode 100644 drivers/mfd/intel_soc_pmic_dc_ti.c
> 
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 94ad2c1c3d90..28c12bb50c9f 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -496,6 +496,19 @@ config INTEL_SOC_PMIC_CHTWC
>  	  available before any devices using it are probed. This option also
>  	  causes the designware-i2c driver to be builtin for the same reason.
>  
> +config INTEL_SOC_PMIC_DC_TI
> +	tristate "Support for Dollar Cove TI PMIC"
> +	depends on GPIOLIB
> +	depends on I2C
> +	depends on ACPI
> +	depends on X86
> +	select MFD_CORE
> +	select REGMAP_I2C
> +	select REGMAP_IRQ
> +	help
> +	  Select this option for supporting Dollar Cove TI PMIC device that is
> +	  found on some Intel Cherry Trail systems.
> +
>  config MFD_INTEL_LPSS
>  	tristate
>  	select COMMON_CLK
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 080793b3fd0e..16c4fe519d30 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -216,6 +216,7 @@ intel-soc-pmic-objs		:= intel_soc_pmic_core.o intel_soc_pmic_crc.o
>  obj-$(CONFIG_INTEL_SOC_PMIC)	+= intel-soc-pmic.o
>  obj-$(CONFIG_INTEL_SOC_PMIC_BXTWC)	+= intel_soc_pmic_bxtwc.o
>  obj-$(CONFIG_INTEL_SOC_PMIC_CHTWC)	+= intel_soc_pmic_chtwc.o
> +obj-$(CONFIG_INTEL_SOC_PMIC_DC_TI)	+= intel_soc_pmic_dc_ti.o
>  obj-$(CONFIG_MFD_MT6397)	+= mt6397-core.o
>  
>  obj-$(CONFIG_MFD_ALTERA_A10SR)	+= altera-a10sr.o
> diff --git a/drivers/mfd/intel_soc_pmic_dc_ti.c b/drivers/mfd/intel_soc_pmic_dc_ti.c
> new file mode 100644
> index 000000000000..3ba1625eb44b
> --- /dev/null
> +++ b/drivers/mfd/intel_soc_pmic_dc_ti.c
> @@ -0,0 +1,182 @@
> +/*
> + * Device access for Dollar Cove TI PMIC

Nit: '\n' here please.

> + * Copyright (c) 2014, Intel Corporation.
> + *   Author: Ramakrishna Pallala <ramakrishna.pallala@intel.com>
> + *
> + * Cleanup and forward-ported
> + *   Copyright (c) 2017 Takashi Iwai <tiwai@suse.de>

No licence header?

> + */
> +
> +#include <linux/acpi.h>
> +#include <linux/interrupt.h>
> +#include <linux/i2c.h>
> +#include <linux/module.h>
> +#include <linux/regmap.h>
> +#include <linux/mfd/core.h>
> +#include <linux/mfd/intel_soc_pmic.h>

Alphabetical.

> +#define DC_TI_IRQLVL1		0x01
> +#define DC_TI_MASK_IRQLVL1	0x02
> +
> +/* Level 1 IRQs */
> +enum {
> +	DC_TI_PWRBTN = 0,	/* power button */
> +	DC_TI_DIETMPWARN,	/* thermal */
> +	DC_TI_ADCCMPL,		/* ADC */
> +	/* no irq 3 */

"No IRQ 3"

> +	DC_TI_VBATLOW = 4,	/* battery */
> +	DC_TI_VBUSDET,		/* power source */
> +	/* no irq 6 */

Here too.

> +	DC_TI_CCEOCAL = 7,	/* battery */
> +};
> +
> +static struct resource power_button_resources[] = {
> +	DEFINE_RES_IRQ(DC_TI_PWRBTN),
> +};
> +
> +static struct resource thermal_resources[] = {
> +	DEFINE_RES_IRQ(DC_TI_DIETMPWARN),
> +};
> +
> +static struct resource adc_resources[] = {
> +	DEFINE_RES_IRQ(DC_TI_ADCCMPL),
> +};
> +
> +static struct resource pwrsrc_resources[] = {
> +	DEFINE_RES_IRQ(DC_TI_VBUSDET),
> +};
> +
> +static struct resource battery_resources[] = {
> +	DEFINE_RES_IRQ(DC_TI_VBATLOW),
> +	DEFINE_RES_IRQ(DC_TI_CCEOCAL),
> +};

Nice.  Thanks for using those.

> +static struct mfd_cell dc_ti_dev[] = {
> +	{
> +		.name = "dc_ti_pwrbtn",
> +		.num_resources = ARRAY_SIZE(power_button_resources),
> +		.resources = power_button_resources,
> +	},
> +	{

Place these on the same line.

> +		.name = "dc_ti_adc",
> +		.num_resources = ARRAY_SIZE(adc_resources),
> +		.resources = adc_resources,
> +	},
> +	{
> +		.name = "dc_ti_thermal",
> +		.num_resources = ARRAY_SIZE(thermal_resources),
> +		.resources = thermal_resources,
> +	},
> +	{
> +		.name = "dc_ti_pwrsrc",
> +		.num_resources = ARRAY_SIZE(pwrsrc_resources),
> +		.resources = pwrsrc_resources,
> +	},
> +	{
> +		.name = "dc_ti_battery",
> +		.num_resources = ARRAY_SIZE(battery_resources),
> +		.resources = battery_resources,
> +	},
> +	{
> +		.name = "dc_ti_region",
> +	},

This should be a one line entry:

	{ .name = "dc_ti_region" },

> +};
> +
> +static const struct regmap_config dc_ti_regmap_config = {
> +	.reg_bits = 8,
> +	.val_bits = 8,
> +	.max_register = 128,
> +	.cache_type = REGCACHE_NONE,
> +};
> +
> +static const struct regmap_irq dc_ti_irqs[] = {
> +	REGMAP_IRQ_REG(DC_TI_PWRBTN, 0, BIT(DC_TI_PWRBTN)),
> +	REGMAP_IRQ_REG(DC_TI_DIETMPWARN, 0, BIT(DC_TI_DIETMPWARN)),
> +	REGMAP_IRQ_REG(DC_TI_ADCCMPL, 0, BIT(DC_TI_ADCCMPL)),
> +	REGMAP_IRQ_REG(DC_TI_VBATLOW, 0, BIT(DC_TI_VBATLOW)),
> +	REGMAP_IRQ_REG(DC_TI_VBUSDET, 0, BIT(DC_TI_VBUSDET)),
> +	REGMAP_IRQ_REG(DC_TI_CCEOCAL, 0, BIT(DC_TI_CCEOCAL)),
> +};
> +
> +static const struct regmap_irq_chip dc_ti_irq_chip = {
> +	.name = KBUILD_MODNAME,
> +	.irqs = dc_ti_irqs,
> +	.num_irqs = ARRAY_SIZE(dc_ti_irqs),
> +	.num_regs = 1,
> +	.status_base = DC_TI_IRQLVL1,
> +	.mask_base = DC_TI_MASK_IRQLVL1,
> +	.ack_base = DC_TI_IRQLVL1,
> +};
> +
> +static int dc_ti_probe(struct i2c_client *i2c)
> +{
> +	struct device *dev = &i2c->dev;
> +	struct intel_soc_pmic *pmic;
> +	int ret;
> +
> +	pmic = devm_kzalloc(dev, sizeof(*pmic), GFP_KERNEL);
> +	if (!pmic)
> +		return -ENOMEM;
> +
> +	i2c_set_clientdata(i2c, pmic);
> +
> +	pmic->regmap = devm_regmap_init_i2c(i2c, &dc_ti_regmap_config);
> +	if (IS_ERR(pmic->regmap))
> +		return PTR_ERR(pmic->regmap);
> +	pmic->irq = i2c->irq;
> +
> +	ret = devm_regmap_add_irq_chip(dev, pmic->regmap, pmic->irq,
> +				       IRQF_ONESHOT, 0,
> +				       &dc_ti_irq_chip, &pmic->irq_chip_data);
> +	if (ret)
> +		return ret;
> +
> +	return devm_mfd_add_devices(dev, PLATFORM_DEVID_NONE, dc_ti_dev,
> +				    ARRAY_SIZE(dc_ti_dev), NULL, 0,
> +				    regmap_irq_get_domain(pmic->irq_chip_data));
> +}
> +
> +static void dc_ti_shutdown(struct i2c_client *i2c)
> +{
> +	struct intel_soc_pmic *pmic = i2c_get_clientdata(i2c);
> +
> +	disable_irq(pmic->irq);
> +}
> +
> +static int __maybe_unused dc_ti_suspend(struct device *dev)
> +{
> +	struct intel_soc_pmic *pmic = dev_get_drvdata(dev);
> +
> +	disable_irq(pmic->irq);

'\n' here.

> +	return 0;
> +}
> +
> +static int __maybe_unused dc_ti_resume(struct device *dev)
> +{
> +	struct intel_soc_pmic *pmic = dev_get_drvdata(dev);
> +
> +	enable_irq(pmic->irq);

'\n' here.

> +	return 0;
> +}
> +
> +static SIMPLE_DEV_PM_OPS(dc_ti_pm_ops, dc_ti_suspend, dc_ti_resume);
> +
> +static const struct acpi_device_id dc_ti_acpi_ids[] = {
> +	{ "INT33F5" },
> +	{ },
> +};
> +MODULE_DEVICE_TABLE(acpi, dc_ti_acpi_ids);
> +
> +static struct i2c_driver dc_ti_i2c_driver = {
> +	.driver = {
> +		.name = KBUILD_MODNAME,

This makes grepping for device/driver matches difficult.  Please just
use the raw "" string.

> +		.pm = &dc_ti_pm_ops,
> +		.acpi_match_table = dc_ti_acpi_ids,
> +	},
> +	.probe_new = dc_ti_probe,
> +	.shutdown = dc_ti_shutdown,
> +};
> +module_i2c_driver(dc_ti_i2c_driver);
> +
> +MODULE_DESCRIPTION("I2C driver for Intel SoC Dollar Cove TI PMIC");
> +MODULE_LICENSE("GPL v2");

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v2 1/3] mfd: Add support for Cherry Trail Dollar Cove TI PMIC

[Takashi Iwai]

On Mon, 04 Sep 2017 15:37:32 +0200,
Lee Jones wrote:
> 
> > +static struct mfd_cell dc_ti_dev[] = {
> > +	{
> > +		.name = "dc_ti_pwrbtn",
> > +		.num_resources = ARRAY_SIZE(power_button_resources),
> > +		.resources = power_button_resources,
> > +	},
> > +	{
> 
> Place these on the same line.

Does this and ...


> > +	},
> > +	{
> > +		.name = "dc_ti_region",
> > +	},
> 
> This should be a one line entry:
> 
> 	{ .name = "dc_ti_region" },

.... this match together?  The result would be like:

static struct mfd_cell dc_ti_dev[] = {
	{
		.name = "dc_ti_pwrbtn",
		.num_resources = ARRAY_SIZE(power_button_resources),
		.resources = power_button_resources,
	}, {
		.name = "chtdc_ti_adc",
		.num_resources = ARRAY_SIZE(adc_resources),
	.....
	}, {	.name = "chtdc_ti_region",	},
};

which I find a bit inconsistent.


thanks,

Takashi

Re: [PATCH v2 1/3] mfd: Add support for Cherry Trail Dollar Cove TI PMIC

[Lee Jones]

On Mon, 04 Sep 2017, Takashi Iwai wrote:

> On Mon, 04 Sep 2017 15:37:32 +0200,
> Lee Jones wrote:
> > 
> > > +static struct mfd_cell dc_ti_dev[] = {
> > > +	{
> > > +		.name = "dc_ti_pwrbtn",
> > > +		.num_resources = ARRAY_SIZE(power_button_resources),
> > > +		.resources = power_button_resources,
> > > +	},
> > > +	{
> > 
> > Place these on the same line.
> 
> Does this and ...
> 
> 
> > > +	},
> > > +	{
> > > +		.name = "dc_ti_region",
> > > +	},
> > 
> > This should be a one line entry:
> > 
> > 	{ .name = "dc_ti_region" },
> 
> .... this match together?  The result would be like:
> 
> static struct mfd_cell dc_ti_dev[] = {
> 	{
> 		.name = "dc_ti_pwrbtn",
> 		.num_resources = ARRAY_SIZE(power_button_resources),
> 		.resources = power_button_resources,
> 	}, {
> 		.name = "chtdc_ti_adc",
> 		.num_resources = ARRAY_SIZE(adc_resources),
> 	.....
> 	}, {	.name = "chtdc_ti_region",	},
> };
> 
> which I find a bit inconsistent.

No, it doesn't.

The single lines need to be on their own.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v2 1/3] mfd: Add support for Cherry Trail Dollar Cove TI PMIC

[Takashi Iwai]

On Tue, 05 Sep 2017 09:25:53 +0200,
Lee Jones wrote:
> 
> On Mon, 04 Sep 2017, Takashi Iwai wrote:
> 
> > On Mon, 04 Sep 2017 15:37:32 +0200,
> > Lee Jones wrote:
> > > 
> > > > +static struct mfd_cell dc_ti_dev[] = {
> > > > +	{
> > > > +		.name = "dc_ti_pwrbtn",
> > > > +		.num_resources = ARRAY_SIZE(power_button_resources),
> > > > +		.resources = power_button_resources,
> > > > +	},
> > > > +	{
> > > 
> > > Place these on the same line.
> > 
> > Does this and ...
> > 
> > 
> > > > +	},
> > > > +	{
> > > > +		.name = "dc_ti_region",
> > > > +	},
> > > 
> > > This should be a one line entry:
> > > 
> > > 	{ .name = "dc_ti_region" },
> > 
> > .... this match together?  The result would be like:
> > 
> > static struct mfd_cell dc_ti_dev[] = {
> > 	{
> > 		.name = "dc_ti_pwrbtn",
> > 		.num_resources = ARRAY_SIZE(power_button_resources),
> > 		.resources = power_button_resources,
> > 	}, {
> > 		.name = "chtdc_ti_adc",
> > 		.num_resources = ARRAY_SIZE(adc_resources),
> > 	.....
> > 	}, {	.name = "chtdc_ti_region",	},
> > };
> > 
> > which I find a bit inconsistent.
> 
> No, it doesn't.

Heh, I find such a mixture annoying, but it's a matter of taste.

> The single lines need to be on their own.

So did I already in the v5 patch submitted yesterday.


thanks,

Takashi

Re: [PATCH v2 1/3] mfd: Add support for Cherry Trail Dollar Cove TI PMIC

[Lee Jones]

On Tue, 05 Sep 2017, Takashi Iwai wrote:

> On Tue, 05 Sep 2017 09:25:53 +0200,
> Lee Jones wrote:
> > 
> > On Mon, 04 Sep 2017, Takashi Iwai wrote:
> > 
> > > On Mon, 04 Sep 2017 15:37:32 +0200,
> > > Lee Jones wrote:
> > > > 
> > > > > +static struct mfd_cell dc_ti_dev[] = {
> > > > > +	{
> > > > > +		.name = "dc_ti_pwrbtn",
> > > > > +		.num_resources = ARRAY_SIZE(power_button_resources),
> > > > > +		.resources = power_button_resources,
> > > > > +	},
> > > > > +	{
> > > > 
> > > > Place these on the same line.
> > > 
> > > Does this and ...
> > > 
> > > 
> > > > > +	},
> > > > > +	{
> > > > > +		.name = "dc_ti_region",
> > > > > +	},
> > > > 
> > > > This should be a one line entry:
> > > > 
> > > > 	{ .name = "dc_ti_region" },
> > > 
> > > .... this match together?  The result would be like:
> > > 
> > > static struct mfd_cell dc_ti_dev[] = {
> > > 	{
> > > 		.name = "dc_ti_pwrbtn",
> > > 		.num_resources = ARRAY_SIZE(power_button_resources),
> > > 		.resources = power_button_resources,
> > > 	}, {
> > > 		.name = "chtdc_ti_adc",
> > > 		.num_resources = ARRAY_SIZE(adc_resources),
> > > 	.....
> > > 	}, {	.name = "chtdc_ti_region",	},
> > > };
> > > 
> > > which I find a bit inconsistent.
> > 
> > No, it doesn't.
> 
> Heh, I find such a mixture annoying, but it's a matter of taste.

Coding style is always a matter of taste. :)

> > The single lines need to be on their own.
> 
> So did I already in the v5 patch submitted yesterday.

I saw it, thanks.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[PATCH v2 2/3] platform/x86: Add support for Dollar Cove TI power button

[Takashi Iwai]

This provides a new input driver for supporting the power button on
Dollar Cove TI PMIC, found on Cherrytrail-based devices.
The patch is based on the original work by Intel, found at:
  https://github.com/01org/ProductionKernelQuilts

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891
Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
v1->v2:
* Move power-button driver to platform/x86, driver renames accordingly
* Add missing wake-irq cleanup to power-button driver

 drivers/platform/x86/Kconfig              |  8 +++
 drivers/platform/x86/Makefile             |  1 +
 drivers/platform/x86/intel_dc_ti_pwrbtn.c | 96 +++++++++++++++++++++++++++++++
 3 files changed, 105 insertions(+)
 create mode 100644 drivers/platform/x86/intel_dc_ti_pwrbtn.c

diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 80b87954f6dd..25ab9f6ba533 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -1139,6 +1139,14 @@ config SILEAD_DMI
 	  with the OS-image for the device. This option supplies the missing
 	  information. Enable this for x86 tablets with Silead touchscreens.
 
+config INTEL_DC_TI_PWRBTN
+	tristate "Dollar Cove TI power button driver"
+	depends on INTEL_SOC_PMIC_DC_TI
+	depends on INPUT
+	help
+	  Say Y here fi you want to have a power button driver for
+	  Dollar Cove TI PMIC.
+
 endif # X86_PLATFORM_DEVICES
 
 config PMC_ATOM
diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
index 91cec1751461..1ce5c18d249e 100644
--- a/drivers/platform/x86/Makefile
+++ b/drivers/platform/x86/Makefile
@@ -83,3 +83,4 @@ obj-$(CONFIG_PMC_ATOM)		+= pmc_atom.o
 obj-$(CONFIG_MLX_PLATFORM)	+= mlx-platform.o
 obj-$(CONFIG_MLX_CPLD_PLATFORM)	+= mlxcpld-hotplug.o
 obj-$(CONFIG_INTEL_TURBO_MAX_3) += intel_turbo_max_3.o
+obj-$(CONFIG_INTEL_DC_TI_PWRBTN)	+= intel_dc_ti_pwrbtn.o
diff --git a/drivers/platform/x86/intel_dc_ti_pwrbtn.c b/drivers/platform/x86/intel_dc_ti_pwrbtn.c
new file mode 100644
index 000000000000..1a40f55699fb
--- /dev/null
+++ b/drivers/platform/x86/intel_dc_ti_pwrbtn.c
@@ -0,0 +1,96 @@
+/*
+ * Power-button driver for Dollar Cove TI PMIC
+ * Copyright (C) 2014 Intel Corp
+ * Copyright (c) 2017 Takashi Iwai <tiwai@suse.de>
+ */
+
+#include <linux/init.h>
+#include <linux/input.h>
+#include <linux/interrupt.h>
+#include <linux/device.h>
+#include <linux/mfd/intel_soc_pmic.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/pm_wakeirq.h>
+#include <linux/slab.h>
+
+#define DC_TI_SIRQ_REG		0x3
+#define SIRQ_PWRBTN_REL		(1 << 0)
+
+static irqreturn_t dc_ti_pwrbtn_interrupt(int irq, void *dev_id)
+{
+	struct input_dev *input = dev_id;
+	struct device *dev = input->dev.parent;
+	struct regmap *regmap = dev_get_drvdata(dev);
+	int state;
+
+	if (!regmap_read(regmap, DC_TI_SIRQ_REG, &state)) {
+		dev_dbg(dev, "SIRQ_REG=0x%x\n", state);
+		state &= SIRQ_PWRBTN_REL;
+		input_event(input, EV_KEY, KEY_POWER, !state);
+		input_sync(input);
+	}
+
+	return IRQ_HANDLED;
+}
+
+static int dc_ti_pwrbtn_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct intel_soc_pmic *pmic = dev_get_drvdata(dev->parent);
+	struct input_dev *input;
+	int irq;
+	int ret;
+
+	irq = platform_get_irq(pdev, 0);
+	if (irq < 0)
+		return -EINVAL;
+	input = devm_input_allocate_device(dev);
+	if (!input)
+		return -ENOMEM;
+	input->name = pdev->name;
+	input->phys = "power-button/input0";
+	input->id.bustype = BUS_HOST;
+	input->dev.parent = dev;
+	input_set_capability(input, EV_KEY, KEY_POWER);
+	ret = input_register_device(input);
+	if (ret)
+		return ret;
+
+	dev_set_drvdata(dev, pmic->regmap);
+
+	ret = devm_request_threaded_irq(dev, irq, NULL, dc_ti_pwrbtn_interrupt,
+					0, KBUILD_MODNAME, input);
+	if (ret)
+		return ret;
+
+	device_init_wakeup(dev, true);
+	dev_pm_set_wake_irq(dev, irq);
+	return 0;
+}
+
+static int dc_ti_pwrbtn_remove(struct platform_device *pdev)
+{
+	dev_pm_clear_wake_irq(&pdev->dev);
+	device_init_wakeup(&pdev->dev, false);
+	return 0;
+}
+
+static struct platform_device_id dc_ti_pwrbtn_id_table[] = {
+	{ .name = "dc_ti_pwrbtn" },
+	{},
+};
+MODULE_DEVICE_TABLE(platform, dc_ti_pwrbtn_id_table);
+
+static struct platform_driver dc_ti_pwrbtn_driver = {
+	.driver = {
+		.name = KBUILD_MODNAME,
+	},
+	.probe	= dc_ti_pwrbtn_probe,
+	.remove	= dc_ti_pwrbtn_remove,
+	.id_table = dc_ti_pwrbtn_id_table,
+};
+module_platform_driver(dc_ti_pwrbtn_driver);
+
+MODULE_DESCRIPTION("Power-button driver for Dollar Cove TI PMIC");
+MODULE_LICENSE("GPL v2");
-- 
2.14.0

Re: [PATCH v2 2/3] platform/x86: Add support for Dollar Cove TI power button

[Mika Westerberg]

On Thu, Aug 24, 2017 at 10:11:40AM +0200, Takashi Iwai wrote:
> +static struct platform_device_id dc_ti_pwrbtn_id_table[] = {

const?

Regardless,

Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>

Re: [PATCH v2 2/3] platform/x86: Add support for Dollar Cove TI power button

[Andy Shevchenko]

On Thu, Aug 24, 2017 at 11:11 AM, Takashi Iwai <tiwai@suse.de> wrote:
> This provides a new input driver for supporting the power button on
> Dollar Cove TI PMIC, found on Cherrytrail-based devices.
> The patch is based on the original work by Intel, found at:
>   https://github.com/01org/ProductionKernelQuilts
>
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891
> Signed-off-by: Takashi Iwai <tiwai@suse.de>

Are you going to submit it via MFD?

Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com>

> ---
> v1->v2:
> * Move power-button driver to platform/x86, driver renames accordingly
> * Add missing wake-irq cleanup to power-button driver
>
>  drivers/platform/x86/Kconfig              |  8 +++
>  drivers/platform/x86/Makefile             |  1 +
>  drivers/platform/x86/intel_dc_ti_pwrbtn.c | 96 +++++++++++++++++++++++++++++++
>  3 files changed, 105 insertions(+)
>  create mode 100644 drivers/platform/x86/intel_dc_ti_pwrbtn.c
>
> diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
> index 80b87954f6dd..25ab9f6ba533 100644
> --- a/drivers/platform/x86/Kconfig
> +++ b/drivers/platform/x86/Kconfig
> @@ -1139,6 +1139,14 @@ config SILEAD_DMI
>           with the OS-image for the device. This option supplies the missing
>           information. Enable this for x86 tablets with Silead touchscreens.
>
> +config INTEL_DC_TI_PWRBTN
> +       tristate "Dollar Cove TI power button driver"
> +       depends on INTEL_SOC_PMIC_DC_TI
> +       depends on INPUT
> +       help
> +         Say Y here fi you want to have a power button driver for
> +         Dollar Cove TI PMIC.
> +
>  endif # X86_PLATFORM_DEVICES
>
>  config PMC_ATOM
> diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
> index 91cec1751461..1ce5c18d249e 100644
> --- a/drivers/platform/x86/Makefile
> +++ b/drivers/platform/x86/Makefile
> @@ -83,3 +83,4 @@ obj-$(CONFIG_PMC_ATOM)                += pmc_atom.o
>  obj-$(CONFIG_MLX_PLATFORM)     += mlx-platform.o
>  obj-$(CONFIG_MLX_CPLD_PLATFORM)        += mlxcpld-hotplug.o
>  obj-$(CONFIG_INTEL_TURBO_MAX_3) += intel_turbo_max_3.o
> +obj-$(CONFIG_INTEL_DC_TI_PWRBTN)       += intel_dc_ti_pwrbtn.o
> diff --git a/drivers/platform/x86/intel_dc_ti_pwrbtn.c b/drivers/platform/x86/intel_dc_ti_pwrbtn.c
> new file mode 100644
> index 000000000000..1a40f55699fb
> --- /dev/null
> +++ b/drivers/platform/x86/intel_dc_ti_pwrbtn.c
> @@ -0,0 +1,96 @@
> +/*
> + * Power-button driver for Dollar Cove TI PMIC
> + * Copyright (C) 2014 Intel Corp
> + * Copyright (c) 2017 Takashi Iwai <tiwai@suse.de>
> + */
> +
> +#include <linux/init.h>
> +#include <linux/input.h>
> +#include <linux/interrupt.h>
> +#include <linux/device.h>
> +#include <linux/mfd/intel_soc_pmic.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/pm_wakeirq.h>
> +#include <linux/slab.h>
> +
> +#define DC_TI_SIRQ_REG         0x3
> +#define SIRQ_PWRBTN_REL                (1 << 0)
> +
> +static irqreturn_t dc_ti_pwrbtn_interrupt(int irq, void *dev_id)
> +{
> +       struct input_dev *input = dev_id;
> +       struct device *dev = input->dev.parent;
> +       struct regmap *regmap = dev_get_drvdata(dev);
> +       int state;
> +
> +       if (!regmap_read(regmap, DC_TI_SIRQ_REG, &state)) {
> +               dev_dbg(dev, "SIRQ_REG=0x%x\n", state);
> +               state &= SIRQ_PWRBTN_REL;
> +               input_event(input, EV_KEY, KEY_POWER, !state);
> +               input_sync(input);
> +       }
> +
> +       return IRQ_HANDLED;
> +}
> +
> +static int dc_ti_pwrbtn_probe(struct platform_device *pdev)
> +{
> +       struct device *dev = &pdev->dev;
> +       struct intel_soc_pmic *pmic = dev_get_drvdata(dev->parent);
> +       struct input_dev *input;
> +       int irq;
> +       int ret;
> +
> +       irq = platform_get_irq(pdev, 0);
> +       if (irq < 0)
> +               return -EINVAL;
> +       input = devm_input_allocate_device(dev);
> +       if (!input)
> +               return -ENOMEM;
> +       input->name = pdev->name;
> +       input->phys = "power-button/input0";
> +       input->id.bustype = BUS_HOST;
> +       input->dev.parent = dev;
> +       input_set_capability(input, EV_KEY, KEY_POWER);
> +       ret = input_register_device(input);
> +       if (ret)
> +               return ret;
> +
> +       dev_set_drvdata(dev, pmic->regmap);
> +
> +       ret = devm_request_threaded_irq(dev, irq, NULL, dc_ti_pwrbtn_interrupt,
> +                                       0, KBUILD_MODNAME, input);
> +       if (ret)
> +               return ret;
> +
> +       device_init_wakeup(dev, true);
> +       dev_pm_set_wake_irq(dev, irq);
> +       return 0;
> +}
> +
> +static int dc_ti_pwrbtn_remove(struct platform_device *pdev)
> +{
> +       dev_pm_clear_wake_irq(&pdev->dev);
> +       device_init_wakeup(&pdev->dev, false);
> +       return 0;
> +}
> +
> +static struct platform_device_id dc_ti_pwrbtn_id_table[] = {
> +       { .name = "dc_ti_pwrbtn" },
> +       {},
> +};
> +MODULE_DEVICE_TABLE(platform, dc_ti_pwrbtn_id_table);
> +
> +static struct platform_driver dc_ti_pwrbtn_driver = {
> +       .driver = {
> +               .name = KBUILD_MODNAME,
> +       },
> +       .probe  = dc_ti_pwrbtn_probe,
> +       .remove = dc_ti_pwrbtn_remove,
> +       .id_table = dc_ti_pwrbtn_id_table,
> +};
> +module_platform_driver(dc_ti_pwrbtn_driver);
> +
> +MODULE_DESCRIPTION("Power-button driver for Dollar Cove TI PMIC");
> +MODULE_LICENSE("GPL v2");
> --
> 2.14.0
>



-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 2/3] platform/x86: Add support for Dollar Cove TI power button

[Takashi Iwai]

On Thu, 24 Aug 2017 11:20:04 +0200,
Andy Shevchenko wrote:
> 
> On Thu, Aug 24, 2017 at 11:11 AM, Takashi Iwai <tiwai@suse.de> wrote:
> > This provides a new input driver for supporting the power button on
> > Dollar Cove TI PMIC, found on Cherrytrail-based devices.
> > The patch is based on the original work by Intel, found at:
> >   https://github.com/01org/ProductionKernelQuilts
> >
> > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891
> > Signed-off-by: Takashi Iwai <tiwai@suse.de>
> 
> Are you going to submit it via MFD?

I really don't mind who takes what.  The driver codes are small, so it
should be OK to go through a single tree, presumably MFD, if all
people agree.

OTOH, if Lee can prepare an immutable branch, other two can go via
other trees, too.

What do you guys think better?


thanks,

Takashi

Re: [PATCH v2 2/3] platform/x86: Add support for Dollar Cove TI power button

[Andy Shevchenko]

On Thu, Aug 24, 2017 at 12:45 PM, Takashi Iwai <tiwai@suse.de> wrote:
> On Thu, 24 Aug 2017 11:20:04 +0200,
> Andy Shevchenko wrote:
>>
>> On Thu, Aug 24, 2017 at 11:11 AM, Takashi Iwai <tiwai@suse.de> wrote:
>> > This provides a new input driver for supporting the power button on
>> > Dollar Cove TI PMIC, found on Cherrytrail-based devices.
>> > The patch is based on the original work by Intel, found at:
>> >   https://github.com/01org/ProductionKernelQuilts
>> >
>> > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891
>> > Signed-off-by: Takashi Iwai <tiwai@suse.de>
>>
>> Are you going to submit it via MFD?
>
> I really don't mind who takes what.  The driver codes are small, so it
> should be OK to go through a single tree, presumably MFD, if all
> people agree.
>
> OTOH, if Lee can prepare an immutable branch, other two can go via
> other trees, too.
>
> What do you guys think better?

As a co-maintainer of PDx86 I prefer to go with MFD or whatever first
patch is related to.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v5 1/3] mfd: Add support for Cherry Trail Dollar Cove TI PMIC

[Takashi Iwai]

On Thu, 07 Sep 2017 12:53:48 +0200,
Lee Jones wrote:
> 
> On Thu, 07 Sep 2017, Takashi Iwai wrote:
> 
> > On Tue, 05 Sep 2017 10:54:49 +0200,
> > Lee Jones wrote:
> > > 
> > > On Tue, 05 Sep 2017, Takashi Iwai wrote:
> > > 
> > > > On Tue, 05 Sep 2017 10:10:49 +0200,
> > > > Lee Jones wrote:
> > > > > 
> > > > > On Tue, 05 Sep 2017, Takashi Iwai wrote:
> > > > > 
> > > > > > On Tue, 05 Sep 2017 09:24:51 +0200,
> > > > > > Lee Jones wrote:
> > > > > > > 
> > > > > > > On Mon, 04 Sep 2017, Takashi Iwai wrote:
> > > > > > > 
> > > > > > > > This patch adds the MFD driver for Dollar Cove (TI version) PMIC with
> > > > > > > > ACPI INT33F5 that is found on some Intel Cherry Trail devices.
> > > > > > > > The driver is based on the original work by Intel, found at:
> > > > > > > >   https://github.com/01org/ProductionKernelQuilts
> > > > > > > > 
> > > > > > > > This is a minimal version for adding the basic resources.  Currently,
> > > > > > > > only ACPI PMIC opregion and the external power-button are used.
> > > > > > > > 
> > > > > > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891
> > > > > > > > Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> > > > > > > > Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> > > > > > > > Signed-off-by: Takashi Iwai <tiwai@suse.de>
> > > > > > > > ---
> > > > > > > > v4->v5:
> > > > > > > > * Minor coding-style fixes suggested by Lee
> > > > > > > > * Put GPL text
> > > > > > > > v3->v4:
> > > > > > > > * no change for this patch
> > > > > > > > v2->v3:
> > > > > > > > * Rename dc_ti with chtdc_ti in all places
> > > > > > > > * Driver/kconfig renames accordingly
> > > > > > > > * Added acks by Andy and Mika
> > > > > > > > v1->v2:
> > > > > > > > * Minor cleanups as suggested by Andy
> > > > > > > > 
> > > > > > > >  drivers/mfd/Kconfig                   |  13 +++
> > > > > > > >  drivers/mfd/Makefile                  |   1 +
> > > > > > > >  drivers/mfd/intel_soc_pmic_chtdc_ti.c | 184 ++++++++++++++++++++++++++++++++++
> > > > > > > >  3 files changed, 198 insertions(+)
> > > > > > > >  create mode 100644 drivers/mfd/intel_soc_pmic_chtdc_ti.c
> > > > > > > 
> > > > > > > For my own reference:
> > > > > > >   Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> > > > > > 
> > > > > > Thanks!
> > > > > > 
> > > > > > Now the question is how to deal with these.  It's no critical things,
> > > > > > so I'm OK to postpone for 4.15.  OTOH, it's really a new
> > > > > > device-specific stuff, thus it can't break anything else, and it'd be
> > > > > > fairly safe to add it for 4.14 although it's at a bit late stage.
> > > > > 
> > > > > Yes, you are over 2 weeks late for v4.14.  It will have to be v4.15.
> > > > 
> > > > OK, I'll ring your bells again once when 4.15 development is opened.
> > > 
> > > Please don't.  Just collect all the Acks you have received and sent
> > > out the set again changing [PATCH] for [RESEND].  Only if there
> > > haven't been any code changes of course. 
> >   
> > You seem to have applied the patches in some branch, but still do I
> > need to resend the whole patches?
> 
> That's up to the Platform Maintainers.
> 
> Since the MFD and ACPI are applied, you do not need to resend those.
> 
> > BTW, was patch 2/3 applied?  I miss your notification mail.
> 
> Patch 2 needs to be applied into the Platform tree.
> 
> Since there are no deps between the patches, they should be applied
> into their own trees (as previously discussed).  I only applied the
> ACPI patch because Rafael asked me nicely.  Normally this should have
> gone in separately too.

Andy already expressed his preference about the patch going through
MFD tree in the v5 thread.  Below is the excerpt.


Takashi

On Thu, 24 Aug 2017 13:47:04 +0200,
Andy Shevchenko wrote:
> 
> On Thu, Aug 24, 2017 at 12:45 PM, Takashi Iwai <tiwai@suse.de> wrote:
> > On Thu, 24 Aug 2017 11:20:04 +0200,
> > Andy Shevchenko wrote:
> >>
> >> On Thu, Aug 24, 2017 at 11:11 AM, Takashi Iwai <tiwai@suse.de> wrote:
> >> > This provides a new input driver for supporting the power button on
> >> > Dollar Cove TI PMIC, found on Cherrytrail-based devices.
> >> > The patch is based on the original work by Intel, found at:
> >> >   https://github.com/01org/ProductionKernelQuilts
> >> >
> >> > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891
> >> > Signed-off-by: Takashi Iwai <tiwai@suse.de>
> >>
> >> Are you going to submit it via MFD?
> >
> > I really don't mind who takes what.  The driver codes are small, so it
> > should be OK to go through a single tree, presumably MFD, if all
> > people agree.
> >
> > OTOH, if Lee can prepare an immutable branch, other two can go via
> > other trees, too.
> >
> > What do you guys think better?
> 
> As a co-maintainer of PDx86 I prefer to go with MFD or whatever first
> patch is related to.
> 
> -- 
> With Best Regards,
> Andy Shevchenko
> 

Re: [PATCH v5 1/3] mfd: Add support for Cherry Trail Dollar Cove TI PMIC

[Lee Jones]

On Thu, 07 Sep 2017, Takashi Iwai wrote:

> On Thu, 07 Sep 2017 12:53:48 +0200,
> Lee Jones wrote:
> > 
> > On Thu, 07 Sep 2017, Takashi Iwai wrote:
> > 
> > > On Tue, 05 Sep 2017 10:54:49 +0200,
> > > Lee Jones wrote:
> > > > 
> > > > On Tue, 05 Sep 2017, Takashi Iwai wrote:
> > > > 
> > > > > On Tue, 05 Sep 2017 10:10:49 +0200,
> > > > > Lee Jones wrote:
> > > > > > 
> > > > > > On Tue, 05 Sep 2017, Takashi Iwai wrote:
> > > > > > 
> > > > > > > On Tue, 05 Sep 2017 09:24:51 +0200,
> > > > > > > Lee Jones wrote:
> > > > > > > > 
> > > > > > > > On Mon, 04 Sep 2017, Takashi Iwai wrote:
> > > > > > > > 
> > > > > > > > > This patch adds the MFD driver for Dollar Cove (TI version) PMIC with
> > > > > > > > > ACPI INT33F5 that is found on some Intel Cherry Trail devices.
> > > > > > > > > The driver is based on the original work by Intel, found at:
> > > > > > > > >   https://github.com/01org/ProductionKernelQuilts
> > > > > > > > > 
> > > > > > > > > This is a minimal version for adding the basic resources.  Currently,
> > > > > > > > > only ACPI PMIC opregion and the external power-button are used.
> > > > > > > > > 
> > > > > > > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891
> > > > > > > > > Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> > > > > > > > > Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> > > > > > > > > Signed-off-by: Takashi Iwai <tiwai@suse.de>
> > > > > > > > > ---
> > > > > > > > > v4->v5:
> > > > > > > > > * Minor coding-style fixes suggested by Lee
> > > > > > > > > * Put GPL text
> > > > > > > > > v3->v4:
> > > > > > > > > * no change for this patch
> > > > > > > > > v2->v3:
> > > > > > > > > * Rename dc_ti with chtdc_ti in all places
> > > > > > > > > * Driver/kconfig renames accordingly
> > > > > > > > > * Added acks by Andy and Mika
> > > > > > > > > v1->v2:
> > > > > > > > > * Minor cleanups as suggested by Andy
> > > > > > > > > 
> > > > > > > > >  drivers/mfd/Kconfig                   |  13 +++
> > > > > > > > >  drivers/mfd/Makefile                  |   1 +
> > > > > > > > >  drivers/mfd/intel_soc_pmic_chtdc_ti.c | 184 ++++++++++++++++++++++++++++++++++
> > > > > > > > >  3 files changed, 198 insertions(+)
> > > > > > > > >  create mode 100644 drivers/mfd/intel_soc_pmic_chtdc_ti.c
> > > > > > > > 
> > > > > > > > For my own reference:
> > > > > > > >   Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> > > > > > > 
> > > > > > > Thanks!
> > > > > > > 
> > > > > > > Now the question is how to deal with these.  It's no critical things,
> > > > > > > so I'm OK to postpone for 4.15.  OTOH, it's really a new
> > > > > > > device-specific stuff, thus it can't break anything else, and it'd be
> > > > > > > fairly safe to add it for 4.14 although it's at a bit late stage.
> > > > > > 
> > > > > > Yes, you are over 2 weeks late for v4.14.  It will have to be v4.15.
> > > > > 
> > > > > OK, I'll ring your bells again once when 4.15 development is opened.
> > > > 
> > > > Please don't.  Just collect all the Acks you have received and sent
> > > > out the set again changing [PATCH] for [RESEND].  Only if there
> > > > haven't been any code changes of course. 
> > >   
> > > You seem to have applied the patches in some branch, but still do I
> > > need to resend the whole patches?
> > 
> > That's up to the Platform Maintainers.
> > 
> > Since the MFD and ACPI are applied, you do not need to resend those.
> > 
> > > BTW, was patch 2/3 applied?  I miss your notification mail.
> > 
> > Patch 2 needs to be applied into the Platform tree.
> > 
> > Since there are no deps between the patches, they should be applied
> > into their own trees (as previously discussed).  I only applied the
> > ACPI patch because Rafael asked me nicely.  Normally this should have
> > gone in separately too.
> 
> Andy already expressed his preference about the patch going through
> MFD tree in the v5 thread.  Below is the excerpt.

If Andy is happy for me to apply the patch without an immutable
branch, then I'll take it.  But as I've already said, this it
non-optimal.

There is no reason why it can't be taken in via the Platform tree.
Nothing depends on it and it depends on nothing, since it is new
code.

> On Thu, 24 Aug 2017 13:47:04 +0200,
> Andy Shevchenko wrote:
> > 
> > On Thu, Aug 24, 2017 at 12:45 PM, Takashi Iwai <tiwai@suse.de> wrote:
> > > On Thu, 24 Aug 2017 11:20:04 +0200,
> > > Andy Shevchenko wrote:
> > >>
> > >> On Thu, Aug 24, 2017 at 11:11 AM, Takashi Iwai <tiwai@suse.de> wrote:
> > >> > This provides a new input driver for supporting the power button on
> > >> > Dollar Cove TI PMIC, found on Cherrytrail-based devices.
> > >> > The patch is based on the original work by Intel, found at:
> > >> >   https://github.com/01org/ProductionKernelQuilts
> > >> >
> > >> > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891
> > >> > Signed-off-by: Takashi Iwai <tiwai@suse.de>
> > >>
> > >> Are you going to submit it via MFD?
> > >
> > > I really don't mind who takes what.  The driver codes are small, so it
> > > should be OK to go through a single tree, presumably MFD, if all
> > > people agree.
> > >
> > > OTOH, if Lee can prepare an immutable branch, other two can go via
> > > other trees, too.
> > >
> > > What do you guys think better?
> > 
> > As a co-maintainer of PDx86 I prefer to go with MFD or whatever first
> > patch is related to.
> > 

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v5 1/3] mfd: Add support for Cherry Trail Dollar Cove TI PMIC

[Takashi Iwai]

On Thu, 07 Sep 2017 14:28:34 +0200,
Lee Jones wrote:
> 
> On Thu, 07 Sep 2017, Takashi Iwai wrote:
> 
> > On Thu, 07 Sep 2017 12:53:48 +0200,
> > Lee Jones wrote:
> > > 
> > > On Thu, 07 Sep 2017, Takashi Iwai wrote:
> > > 
> > > > On Tue, 05 Sep 2017 10:54:49 +0200,
> > > > Lee Jones wrote:
> > > > > 
> > > > > On Tue, 05 Sep 2017, Takashi Iwai wrote:
> > > > > 
> > > > > > On Tue, 05 Sep 2017 10:10:49 +0200,
> > > > > > Lee Jones wrote:
> > > > > > > 
> > > > > > > On Tue, 05 Sep 2017, Takashi Iwai wrote:
> > > > > > > 
> > > > > > > > On Tue, 05 Sep 2017 09:24:51 +0200,
> > > > > > > > Lee Jones wrote:
> > > > > > > > > 
> > > > > > > > > On Mon, 04 Sep 2017, Takashi Iwai wrote:
> > > > > > > > > 
> > > > > > > > > > This patch adds the MFD driver for Dollar Cove (TI version) PMIC with
> > > > > > > > > > ACPI INT33F5 that is found on some Intel Cherry Trail devices.
> > > > > > > > > > The driver is based on the original work by Intel, found at:
> > > > > > > > > >   https://github.com/01org/ProductionKernelQuilts
> > > > > > > > > > 
> > > > > > > > > > This is a minimal version for adding the basic resources.  Currently,
> > > > > > > > > > only ACPI PMIC opregion and the external power-button are used.
> > > > > > > > > > 
> > > > > > > > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891
> > > > > > > > > > Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> > > > > > > > > > Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> > > > > > > > > > Signed-off-by: Takashi Iwai <tiwai@suse.de>
> > > > > > > > > > ---
> > > > > > > > > > v4->v5:
> > > > > > > > > > * Minor coding-style fixes suggested by Lee
> > > > > > > > > > * Put GPL text
> > > > > > > > > > v3->v4:
> > > > > > > > > > * no change for this patch
> > > > > > > > > > v2->v3:
> > > > > > > > > > * Rename dc_ti with chtdc_ti in all places
> > > > > > > > > > * Driver/kconfig renames accordingly
> > > > > > > > > > * Added acks by Andy and Mika
> > > > > > > > > > v1->v2:
> > > > > > > > > > * Minor cleanups as suggested by Andy
> > > > > > > > > > 
> > > > > > > > > >  drivers/mfd/Kconfig                   |  13 +++
> > > > > > > > > >  drivers/mfd/Makefile                  |   1 +
> > > > > > > > > >  drivers/mfd/intel_soc_pmic_chtdc_ti.c | 184 ++++++++++++++++++++++++++++++++++
> > > > > > > > > >  3 files changed, 198 insertions(+)
> > > > > > > > > >  create mode 100644 drivers/mfd/intel_soc_pmic_chtdc_ti.c
> > > > > > > > > 
> > > > > > > > > For my own reference:
> > > > > > > > >   Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> > > > > > > > 
> > > > > > > > Thanks!
> > > > > > > > 
> > > > > > > > Now the question is how to deal with these.  It's no critical things,
> > > > > > > > so I'm OK to postpone for 4.15.  OTOH, it's really a new
> > > > > > > > device-specific stuff, thus it can't break anything else, and it'd be
> > > > > > > > fairly safe to add it for 4.14 although it's at a bit late stage.
> > > > > > > 
> > > > > > > Yes, you are over 2 weeks late for v4.14.  It will have to be v4.15.
> > > > > > 
> > > > > > OK, I'll ring your bells again once when 4.15 development is opened.
> > > > > 
> > > > > Please don't.  Just collect all the Acks you have received and sent
> > > > > out the set again changing [PATCH] for [RESEND].  Only if there
> > > > > haven't been any code changes of course. 
> > > >   
> > > > You seem to have applied the patches in some branch, but still do I
> > > > need to resend the whole patches?
> > > 
> > > That's up to the Platform Maintainers.
> > > 
> > > Since the MFD and ACPI are applied, you do not need to resend those.
> > > 
> > > > BTW, was patch 2/3 applied?  I miss your notification mail.
> > > 
> > > Patch 2 needs to be applied into the Platform tree.
> > > 
> > > Since there are no deps between the patches, they should be applied
> > > into their own trees (as previously discussed).  I only applied the
> > > ACPI patch because Rafael asked me nicely.  Normally this should have
> > > gone in separately too.
> > 
> > Andy already expressed his preference about the patch going through
> > MFD tree in the v5 thread.  Below is the excerpt.
> 
> If Andy is happy for me to apply the patch without an immutable
> branch, then I'll take it.  But as I've already said, this it
> non-optimal.
> 
> There is no reason why it can't be taken in via the Platform tree.
> Nothing depends on it and it depends on nothing, since it is new
> code.

That approach is also far from optimal, too, as Rafael and I
explained.


Takashi

Re: [PATCH v5 1/3] mfd: Add support for Cherry Trail Dollar Cove TI PMIC

[Lee Jones]

> > > > > > > > > > > This patch adds the MFD driver for Dollar Cove (TI version) PMIC with
> > > > > > > > > > > ACPI INT33F5 that is found on some Intel Cherry Trail devices.
> > > > > > > > > > > The driver is based on the original work by Intel, found at:
> > > > > > > > > > >   https://github.com/01org/ProductionKernelQuilts
> > > > > > > > > > > 
> > > > > > > > > > > This is a minimal version for adding the basic resources.  Currently,
> > > > > > > > > > > only ACPI PMIC opregion and the external power-button are used.
> > > > > > > > > > > 
> > > > > > > > > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891
> > > > > > > > > > > Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> > > > > > > > > > > Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> > > > > > > > > > > Signed-off-by: Takashi Iwai <tiwai@suse.de>
> > > > > > > > > > > ---
> > > > > > > > > > > v4->v5:
> > > > > > > > > > > * Minor coding-style fixes suggested by Lee
> > > > > > > > > > > * Put GPL text
> > > > > > > > > > > v3->v4:
> > > > > > > > > > > * no change for this patch
> > > > > > > > > > > v2->v3:
> > > > > > > > > > > * Rename dc_ti with chtdc_ti in all places
> > > > > > > > > > > * Driver/kconfig renames accordingly
> > > > > > > > > > > * Added acks by Andy and Mika
> > > > > > > > > > > v1->v2:
> > > > > > > > > > > * Minor cleanups as suggested by Andy
> > > > > > > > > > > 
> > > > > > > > > > >  drivers/mfd/Kconfig                   |  13 +++
> > > > > > > > > > >  drivers/mfd/Makefile                  |   1 +
> > > > > > > > > > >  drivers/mfd/intel_soc_pmic_chtdc_ti.c | 184 ++++++++++++++++++++++++++++++++++
> > > > > > > > > > >  3 files changed, 198 insertions(+)
> > > > > > > > > > >  create mode 100644 drivers/mfd/intel_soc_pmic_chtdc_ti.c
> > > > > > > > > > 
> > > > > > > > > > For my own reference:
> > > > > > > > > >   Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> > > > > > > > > 
> > > > > > > > > Thanks!
> > > > > > > > > 
> > > > > > > > > Now the question is how to deal with these.  It's no critical things,
> > > > > > > > > so I'm OK to postpone for 4.15.  OTOH, it's really a new
> > > > > > > > > device-specific stuff, thus it can't break anything else, and it'd be
> > > > > > > > > fairly safe to add it for 4.14 although it's at a bit late stage.
> > > > > > > > 
> > > > > > > > Yes, you are over 2 weeks late for v4.14.  It will have to be v4.15.
> > > > > > > 
> > > > > > > OK, I'll ring your bells again once when 4.15 development is opened.
> > > > > > 
> > > > > > Please don't.  Just collect all the Acks you have received and sent
> > > > > > out the set again changing [PATCH] for [RESEND].  Only if there
> > > > > > haven't been any code changes of course. 
> > > > >   
> > > > > You seem to have applied the patches in some branch, but still do I
> > > > > need to resend the whole patches?
> > > > 
> > > > That's up to the Platform Maintainers.
> > > > 
> > > > Since the MFD and ACPI are applied, you do not need to resend those.
> > > > 
> > > > > BTW, was patch 2/3 applied?  I miss your notification mail.
> > > > 
> > > > Patch 2 needs to be applied into the Platform tree.
> > > > 
> > > > Since there are no deps between the patches, they should be applied
> > > > into their own trees (as previously discussed).  I only applied the
> > > > ACPI patch because Rafael asked me nicely.  Normally this should have
> > > > gone in separately too.
> > > 
> > > Andy already expressed his preference about the patch going through
> > > MFD tree in the v5 thread.  Below is the excerpt.
> > 
> > If Andy is happy for me to apply the patch without an immutable
> > branch, then I'll take it.  But as I've already said, this it
> > non-optimal.
> > 
> > There is no reason why it can't be taken in via the Platform tree.
> > Nothing depends on it and it depends on nothing, since it is new
> > code.
> 
> That approach is also far from optimal, too, as Rafael and I
> explained.

That's just my point.  This approach is optimal.

The alternative is that I (or someone else) jumps through the required
hoops to create an immutable branch.  As a one off, it's not actually
that big of a deal.  However, if I do it for you, I have to do it for
every submitter, else it's not fair to them.

MFD patch-sets inherently cross subsystem boundaries, which means I
would end up taking many more patches than I do already.  Subsequently
the per-cycle MFD pull-request exponentially grows in size, as does my
work load.

This is the way we've been working for years, and it works really
well.  I'm not about to change something which isn't broken, just to
avoid the really tiny corner-case you described before.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v5 1/3] mfd: Add support for Cherry Trail Dollar Cove TI PMIC

[Takashi Iwai]

On Thu, 07 Sep 2017 15:00:01 +0200,
Lee Jones wrote:
> 
> > > > > > > > > > > > This patch adds the MFD driver for Dollar Cove (TI version) PMIC with
> > > > > > > > > > > > ACPI INT33F5 that is found on some Intel Cherry Trail devices.
> > > > > > > > > > > > The driver is based on the original work by Intel, found at:
> > > > > > > > > > > >   https://github.com/01org/ProductionKernelQuilts
> > > > > > > > > > > > 
> > > > > > > > > > > > This is a minimal version for adding the basic resources.  Currently,
> > > > > > > > > > > > only ACPI PMIC opregion and the external power-button are used.
> > > > > > > > > > > > 
> > > > > > > > > > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891
> > > > > > > > > > > > Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> > > > > > > > > > > > Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> > > > > > > > > > > > Signed-off-by: Takashi Iwai <tiwai@suse.de>
> > > > > > > > > > > > ---
> > > > > > > > > > > > v4->v5:
> > > > > > > > > > > > * Minor coding-style fixes suggested by Lee
> > > > > > > > > > > > * Put GPL text
> > > > > > > > > > > > v3->v4:
> > > > > > > > > > > > * no change for this patch
> > > > > > > > > > > > v2->v3:
> > > > > > > > > > > > * Rename dc_ti with chtdc_ti in all places
> > > > > > > > > > > > * Driver/kconfig renames accordingly
> > > > > > > > > > > > * Added acks by Andy and Mika
> > > > > > > > > > > > v1->v2:
> > > > > > > > > > > > * Minor cleanups as suggested by Andy
> > > > > > > > > > > > 
> > > > > > > > > > > >  drivers/mfd/Kconfig                   |  13 +++
> > > > > > > > > > > >  drivers/mfd/Makefile                  |   1 +
> > > > > > > > > > > >  drivers/mfd/intel_soc_pmic_chtdc_ti.c | 184 ++++++++++++++++++++++++++++++++++
> > > > > > > > > > > >  3 files changed, 198 insertions(+)
> > > > > > > > > > > >  create mode 100644 drivers/mfd/intel_soc_pmic_chtdc_ti.c
> > > > > > > > > > > 
> > > > > > > > > > > For my own reference:
> > > > > > > > > > >   Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> > > > > > > > > > 
> > > > > > > > > > Thanks!
> > > > > > > > > > 
> > > > > > > > > > Now the question is how to deal with these.  It's no critical things,
> > > > > > > > > > so I'm OK to postpone for 4.15.  OTOH, it's really a new
> > > > > > > > > > device-specific stuff, thus it can't break anything else, and it'd be
> > > > > > > > > > fairly safe to add it for 4.14 although it's at a bit late stage.
> > > > > > > > > 
> > > > > > > > > Yes, you are over 2 weeks late for v4.14.  It will have to be v4.15.
> > > > > > > > 
> > > > > > > > OK, I'll ring your bells again once when 4.15 development is opened.
> > > > > > > 
> > > > > > > Please don't.  Just collect all the Acks you have received and sent
> > > > > > > out the set again changing [PATCH] for [RESEND].  Only if there
> > > > > > > haven't been any code changes of course. 
> > > > > >   
> > > > > > You seem to have applied the patches in some branch, but still do I
> > > > > > need to resend the whole patches?
> > > > > 
> > > > > That's up to the Platform Maintainers.
> > > > > 
> > > > > Since the MFD and ACPI are applied, you do not need to resend those.
> > > > > 
> > > > > > BTW, was patch 2/3 applied?  I miss your notification mail.
> > > > > 
> > > > > Patch 2 needs to be applied into the Platform tree.
> > > > > 
> > > > > Since there are no deps between the patches, they should be applied
> > > > > into their own trees (as previously discussed).  I only applied the
> > > > > ACPI patch because Rafael asked me nicely.  Normally this should have
> > > > > gone in separately too.
> > > > 
> > > > Andy already expressed his preference about the patch going through
> > > > MFD tree in the v5 thread.  Below is the excerpt.
> > > 
> > > If Andy is happy for me to apply the patch without an immutable
> > > branch, then I'll take it.  But as I've already said, this it
> > > non-optimal.
> > > 
> > > There is no reason why it can't be taken in via the Platform tree.
> > > Nothing depends on it and it depends on nothing, since it is new
> > > code.
> > 
> > That approach is also far from optimal, too, as Rafael and I
> > explained.
> 
> That's just my point.  This approach is optimal.
> 
> The alternative is that I (or someone else) jumps through the required
> hoops to create an immutable branch.  As a one off, it's not actually
> that big of a deal.  However, if I do it for you, I have to do it for
> every submitter, else it's not fair to them.

Lee, that's an overreaction.  No one would think that I'm special even
if you would do that :)

I can create such a branch by myself, and send you pull requests, if
it's a preferred way.  That's no problem.  It'd be much less time than
discussing in a too lengthy thread, honestly speaking.  But maybe the
problem isn't that...

> MFD patch-sets inherently cross subsystem boundaries, which means I
> would end up taking many more patches than I do already.  Subsequently
> the per-cycle MFD pull-request exponentially grows in size, as does my
> work load.

Yeah, I understand that.  OTOH, I don't understand the reason to
refuse the IB as much possible -- there are several ways to manage
that more easily.

For example, you can keep a persistent branch that can be branched off
at any time for a new IB, while keeping another branch for regular,
rather unstable patch applications.  For linux-next, you can provide
the temporary merged branch, too.  It's a way some trees deploy.

> This is the way we've been working for years, and it works really
> well.  I'm not about to change something which isn't broken, just to
> avoid the really tiny corner-case you described before.

I'd disagree about it being a tiny corner-case.  It's fundamental to
provide a solid code basis which user can test / development on.  If
we do release kernels more frequently, it shouldn't be a problem.
(e.g. for a fix between RC's, it's fine to merge through individual
trees.)  But if the merge will be done first after 3 months, no one
can guarantee what would happen in these 3 months.  That's why we need 
the solid merge point to begin with.  It allows a way to debug for
potential breakage after that point.


thanks,

Takashi

Re: [PATCH v5 1/3] mfd: Add support for Cherry Trail Dollar Cove TI PMIC

[Lee Jones]

On Thu, 07 Sep 2017, Takashi Iwai wrote:

> On Thu, 07 Sep 2017 15:00:01 +0200,
> Lee Jones wrote:
> > 
> > > > > > > > > > > > > This patch adds the MFD driver for Dollar Cove (TI version) PMIC with
> > > > > > > > > > > > > ACPI INT33F5 that is found on some Intel Cherry Trail devices.
> > > > > > > > > > > > > The driver is based on the original work by Intel, found at:
> > > > > > > > > > > > >   https://github.com/01org/ProductionKernelQuilts
> > > > > > > > > > > > > 
> > > > > > > > > > > > > This is a minimal version for adding the basic resources.  Currently,
> > > > > > > > > > > > > only ACPI PMIC opregion and the external power-button are used.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891
> > > > > > > > > > > > > Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> > > > > > > > > > > > > Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> > > > > > > > > > > > > Signed-off-by: Takashi Iwai <tiwai@suse.de>
> > > > > > > > > > > > > ---
> > > > > > > > > > > > > v4->v5:
> > > > > > > > > > > > > * Minor coding-style fixes suggested by Lee
> > > > > > > > > > > > > * Put GPL text
> > > > > > > > > > > > > v3->v4:
> > > > > > > > > > > > > * no change for this patch
> > > > > > > > > > > > > v2->v3:
> > > > > > > > > > > > > * Rename dc_ti with chtdc_ti in all places
> > > > > > > > > > > > > * Driver/kconfig renames accordingly
> > > > > > > > > > > > > * Added acks by Andy and Mika
> > > > > > > > > > > > > v1->v2:
> > > > > > > > > > > > > * Minor cleanups as suggested by Andy
> > > > > > > > > > > > > 
> > > > > > > > > > > > >  drivers/mfd/Kconfig                   |  13 +++
> > > > > > > > > > > > >  drivers/mfd/Makefile                  |   1 +
> > > > > > > > > > > > >  drivers/mfd/intel_soc_pmic_chtdc_ti.c | 184 ++++++++++++++++++++++++++++++++++
> > > > > > > > > > > > >  3 files changed, 198 insertions(+)
> > > > > > > > > > > > >  create mode 100644 drivers/mfd/intel_soc_pmic_chtdc_ti.c
> > > > > > > > > > > > 
> > > > > > > > > > > > For my own reference:
> > > > > > > > > > > >   Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> > > > > > > > > > > 
> > > > > > > > > > > Thanks!
> > > > > > > > > > > 
> > > > > > > > > > > Now the question is how to deal with these.  It's no critical things,
> > > > > > > > > > > so I'm OK to postpone for 4.15.  OTOH, it's really a new
> > > > > > > > > > > device-specific stuff, thus it can't break anything else, and it'd be
> > > > > > > > > > > fairly safe to add it for 4.14 although it's at a bit late stage.
> > > > > > > > > > 
> > > > > > > > > > Yes, you are over 2 weeks late for v4.14.  It will have to be v4.15.
> > > > > > > > > 
> > > > > > > > > OK, I'll ring your bells again once when 4.15 development is opened.
> > > > > > > > 
> > > > > > > > Please don't.  Just collect all the Acks you have received and sent
> > > > > > > > out the set again changing [PATCH] for [RESEND].  Only if there
> > > > > > > > haven't been any code changes of course. 
> > > > > > >   
> > > > > > > You seem to have applied the patches in some branch, but still do I
> > > > > > > need to resend the whole patches?
> > > > > > 
> > > > > > That's up to the Platform Maintainers.
> > > > > > 
> > > > > > Since the MFD and ACPI are applied, you do not need to resend those.
> > > > > > 
> > > > > > > BTW, was patch 2/3 applied?  I miss your notification mail.
> > > > > > 
> > > > > > Patch 2 needs to be applied into the Platform tree.
> > > > > > 
> > > > > > Since there are no deps between the patches, they should be applied
> > > > > > into their own trees (as previously discussed).  I only applied the
> > > > > > ACPI patch because Rafael asked me nicely.  Normally this should have
> > > > > > gone in separately too.
> > > > > 
> > > > > Andy already expressed his preference about the patch going through
> > > > > MFD tree in the v5 thread.  Below is the excerpt.
> > > > 
> > > > If Andy is happy for me to apply the patch without an immutable
> > > > branch, then I'll take it.  But as I've already said, this it
> > > > non-optimal.
> > > > 
> > > > There is no reason why it can't be taken in via the Platform tree.
> > > > Nothing depends on it and it depends on nothing, since it is new
> > > > code.
> > > 
> > > That approach is also far from optimal, too, as Rafael and I
> > > explained.
> > 
> > That's just my point.  This approach is optimal.
> > 
> > The alternative is that I (or someone else) jumps through the required
> > hoops to create an immutable branch.  As a one off, it's not actually
> > that big of a deal.  However, if I do it for you, I have to do it for
> > every submitter, else it's not fair to them.
> 
> Lee, that's an overreaction.  No one would think that I'm special even
> if you would do that :)

I'm not saying you'd be special.  I'm saying if I do it for one, I
have to do it for others.

> I can create such a branch by myself, and send you pull requests, if

That is also an acceptable solution.

> it's a preferred way.  That's no problem.  It'd be much less time than
> discussing in a too lengthy thread, honestly speaking.  But maybe the
> problem isn't that...

The problem isn't time in the first instance.  It's the attempt to
avoid setting a precedence and for this to become the norm. 

> > MFD patch-sets inherently cross subsystem boundaries, which means I
> > would end up taking many more patches than I do already.  Subsequently
> > the per-cycle MFD pull-request exponentially grows in size, as does my
> > work load.
> 
> Yeah, I understand that.  OTOH, I don't understand the reason to
> refuse the IB as much possible -- there are several ways to manage
> that more easily.
> 
> For example, you can keep a persistent branch that can be branched off
> at any time for a new IB, while keeping another branch for regular,
> rather unstable patch applications.  For linux-next, you can provide
> the temporary merged branch, too.  It's a way some trees deploy.

Yes, I am aware that some repos split themselves up into immutable
branches, which can be independently pulled from.  They clearly have
more spare time than I do.

These branches are usually only split up by topic within their own
subject area/subsystem.  They tend not to be full of cross-sub system
patch-sets.

> > This is the way we've been working for years, and it works really
> > well.  I'm not about to change something which isn't broken, just to
> > avoid the really tiny corner-case you described before.
> 
> I'd disagree about it being a tiny corner-case.  It's fundamental to
> provide a solid code basis which user can test / development on.  If
> we do release kernels more frequently, it shouldn't be a problem.
> (e.g. for a fix between RC's, it's fine to merge through individual
> trees.)  But if the merge will be done first after 3 months, no one
> can guarantee what would happen in these 3 months.  That's why we need 
> the solid merge point to begin with.  It allows a way to debug for
> potential breakage after that point.

I agree.  Which is exactly what the current release model provides:

All patches get dumped into a pile and tagged (-rc1), then developers
get ~8 weeks to test their work and spot issues created by the merge
and have a chance to fix any problems found prior to final release.
It is this final release which forms the solid code base which you
speak of.

I haven't seen any issues that would warrant the over-the-top
cautionary steps which you suggest, where IMHO the maintenance burden
far outweighs the potential benefit.

Right, this really is enough now.

/out

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[PATCH v2 3/3] ACPI / PMIC: Add opregion driver for Intel Dollar Cove TI PMIC

[Takashi Iwai]

This patch adds the opregion driver for Dollar Cove TI PMIC on Intel
Cherry Trail devices.  The patch is based on the original work by
Intel, found at:
      https://github.com/01org/ProductionKernelQuilts
with many cleanups and rewrites.

The driver is currently provided only as built-in to follow other
PMIC opregion drivers convention.

The re-enumeration of devices at probe is required for fixing the
issues on HP x2 210 G2.  See bug#195689.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=195689
Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
v1->v2:
* get_raw_temp cleanup in opregion driver, mention about register
  endianess

 drivers/acpi/Kconfig                 |   6 ++
 drivers/acpi/Makefile                |   1 +
 drivers/acpi/pmic/intel_pmic_dc_ti.c | 139 +++++++++++++++++++++++++++++++++++
 3 files changed, 146 insertions(+)
 create mode 100644 drivers/acpi/pmic/intel_pmic_dc_ti.c

diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 1ce52f84dc23..9da8dcefde7b 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -521,6 +521,12 @@ config CHT_WC_PMIC_OPREGION
 	help
 	  This config adds ACPI operation region support for CHT Whiskey Cove PMIC.
 
+config DC_TI_PMIC_OPREGION
+	bool "ACPI operation region support for Dollar Cove TI PMIC"
+	depends on INTEL_SOC_PMIC_DC_TI
+	help
+	  This config adds ACPI operation region support for Dollar Cove TI PMIC.
+
 endif
 
 config ACPI_CONFIGFS
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index b1aacfc62b1f..0a9008b971af 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -103,6 +103,7 @@ obj-$(CONFIG_CRC_PMIC_OPREGION) += pmic/intel_pmic_crc.o
 obj-$(CONFIG_XPOWER_PMIC_OPREGION) += pmic/intel_pmic_xpower.o
 obj-$(CONFIG_BXT_WC_PMIC_OPREGION) += pmic/intel_pmic_bxtwc.o
 obj-$(CONFIG_CHT_WC_PMIC_OPREGION) += pmic/intel_pmic_chtwc.o
+obj-$(CONFIG_DC_TI_PMIC_OPREGION) += pmic/intel_pmic_dc_ti.o
 
 obj-$(CONFIG_ACPI_CONFIGFS)	+= acpi_configfs.o
 
diff --git a/drivers/acpi/pmic/intel_pmic_dc_ti.c b/drivers/acpi/pmic/intel_pmic_dc_ti.c
new file mode 100644
index 000000000000..a2be1270eeeb
--- /dev/null
+++ b/drivers/acpi/pmic/intel_pmic_dc_ti.c
@@ -0,0 +1,139 @@
+/*
+ * Dollar Cove TI PMIC operation region driver
+ * Copyright (C) 2014 Intel Corporation. All rights reserved.
+ *
+ * Rewritten and cleaned up
+ * Copyright (C) 2017 Takashi Iwai <tiwai@suse.de>
+ */
+
+#include <linux/acpi.h>
+#include <linux/init.h>
+#include <linux/mfd/intel_soc_pmic.h>
+#include <linux/platform_device.h>
+#include "intel_pmic.h"
+
+/* registers stored in 16bit BE (high:low, total 10bit) */
+#define DC_TI_VBAT	0x54
+#define DC_TI_DIETEMP	0x56
+#define DC_TI_BPTHERM	0x58
+#define DC_TI_GPADC	0x5a
+
+static struct pmic_table dc_ti_power_table[] = {
+	{ .address = 0x00, .reg = 0x41 },
+	{ .address = 0x04, .reg = 0x42 },
+	{ .address = 0x08, .reg = 0x43 },
+	{ .address = 0x0c, .reg = 0x45 },
+	{ .address = 0x10, .reg = 0x46 },
+	{ .address = 0x14, .reg = 0x47 },
+	{ .address = 0x18, .reg = 0x48 },
+	{ .address = 0x1c, .reg = 0x49 },
+	{ .address = 0x20, .reg = 0x4a },
+	{ .address = 0x24, .reg = 0x4b },
+	{ .address = 0x28, .reg = 0x4c },
+	{ .address = 0x2c, .reg = 0x4d },
+	{ .address = 0x30, .reg = 0x4e },
+};
+
+static struct pmic_table dc_ti_thermal_table[] = {
+	{
+		.address = 0x00,
+		.reg = DC_TI_GPADC
+	},
+	{
+		.address = 0x0c,
+		.reg = DC_TI_GPADC
+	},
+	/* TMP2 -> SYSTEMP */
+	{
+		.address = 0x18,
+		.reg = DC_TI_GPADC
+	},
+	/* TMP3 -> BPTHERM */
+	{
+		.address = 0x24,
+		.reg = DC_TI_BPTHERM
+	},
+	{
+		.address = 0x30,
+		.reg = DC_TI_GPADC
+	},
+	/* TMP5 -> DIETEMP */
+	{
+		.address = 0x3c,
+		.reg = DC_TI_DIETEMP
+	},
+};
+
+static int dc_ti_pmic_get_power(struct regmap *regmap, int reg, int bit,
+				u64 *value)
+{
+	int data;
+
+	if (regmap_read(regmap, reg, &data))
+		return -EIO;
+
+	*value = data & 1;
+	return 0;
+}
+
+static int dc_ti_pmic_update_power(struct regmap *regmap, int reg, int bit,
+				   bool on)
+{
+	return regmap_update_bits(regmap, reg, 1, on);
+}
+
+static int dc_ti_pmic_get_raw_temp(struct regmap *regmap, int reg)
+{
+	u8 buf[2];
+	unsigned int val;
+
+	if (regmap_bulk_read(regmap, reg, buf, 2))
+		return -EIO;
+
+	/* stored in big-endian */
+	val = buf[0] & 0x03;
+	return (val << 8) | buf[1];
+}
+
+static struct intel_pmic_opregion_data dc_ti_pmic_opregion_data = {
+	.get_power = dc_ti_pmic_get_power,
+	.update_power = dc_ti_pmic_update_power,
+	.get_raw_temp = dc_ti_pmic_get_raw_temp,
+	.power_table = dc_ti_power_table,
+	.power_table_count = ARRAY_SIZE(dc_ti_power_table),
+	.thermal_table = dc_ti_thermal_table,
+	.thermal_table_count = ARRAY_SIZE(dc_ti_thermal_table),
+};
+
+static int dc_ti_pmic_opregion_probe(struct platform_device *pdev)
+{
+	struct intel_soc_pmic *pmic = dev_get_drvdata(pdev->dev.parent);
+	int err;
+
+	err = intel_pmic_install_opregion_handler(&pdev->dev,
+			ACPI_HANDLE(pdev->dev.parent), pmic->regmap,
+			&dc_ti_pmic_opregion_data);
+	if (err < 0)
+		return err;
+
+	/* Re-enumerate devices depending on PMIC */
+	acpi_walk_dep_device_list(ACPI_HANDLE(pdev->dev.parent));
+	return 0;
+}
+
+static struct platform_device_id dc_ti_pmic_opregion_id_table[] = {
+	{ .name = "dc_ti_region" },
+	{},
+};
+
+static struct platform_driver dc_ti_pmic_opregion_driver = {
+	.probe = dc_ti_pmic_opregion_probe,
+	.driver = {
+		.name = "dollar_cove_ti_pmic",
+	},
+	.id_table = dc_ti_pmic_opregion_id_table,
+};
+module_platform_driver(dc_ti_pmic_opregion_driver);
+
+MODULE_DESCRIPTION("Dollar Cove TI PMIC opregion driver");
+MODULE_LICENSE("GPL v2");
-- 
2.14.0

Re: [PATCH v2 3/3] ACPI / PMIC: Add opregion driver for Intel Dollar Cove TI PMIC

[Mika Westerberg]

On Thu, Aug 24, 2017 at 10:11:41AM +0200, Takashi Iwai wrote:
> This patch adds the opregion driver for Dollar Cove TI PMIC on Intel
> Cherry Trail devices.  The patch is based on the original work by
> Intel, found at:
>       https://github.com/01org/ProductionKernelQuilts
> with many cleanups and rewrites.
> 
> The driver is currently provided only as built-in to follow other
> PMIC opregion drivers convention.
> 
> The re-enumeration of devices at probe is required for fixing the
> issues on HP x2 210 G2.  See bug#195689.
> 
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=195689
> Signed-off-by: Takashi Iwai <tiwai@suse.de>
> ---
> v1->v2:
> * get_raw_temp cleanup in opregion driver, mention about register
>   endianess
> 
>  drivers/acpi/Kconfig                 |   6 ++
>  drivers/acpi/Makefile                |   1 +
>  drivers/acpi/pmic/intel_pmic_dc_ti.c | 139 +++++++++++++++++++++++++++++++++++
>  3 files changed, 146 insertions(+)
>  create mode 100644 drivers/acpi/pmic/intel_pmic_dc_ti.c
> 
> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> index 1ce52f84dc23..9da8dcefde7b 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -521,6 +521,12 @@ config CHT_WC_PMIC_OPREGION
>  	help
>  	  This config adds ACPI operation region support for CHT Whiskey Cove PMIC.
>  
> +config DC_TI_PMIC_OPREGION
> +	bool "ACPI operation region support for Dollar Cove TI PMIC"
> +	depends on INTEL_SOC_PMIC_DC_TI
> +	help
> +	  This config adds ACPI operation region support for Dollar Cove TI PMIC.
> +
>  endif
>  
>  config ACPI_CONFIGFS
> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
> index b1aacfc62b1f..0a9008b971af 100644
> --- a/drivers/acpi/Makefile
> +++ b/drivers/acpi/Makefile
> @@ -103,6 +103,7 @@ obj-$(CONFIG_CRC_PMIC_OPREGION) += pmic/intel_pmic_crc.o
>  obj-$(CONFIG_XPOWER_PMIC_OPREGION) += pmic/intel_pmic_xpower.o
>  obj-$(CONFIG_BXT_WC_PMIC_OPREGION) += pmic/intel_pmic_bxtwc.o
>  obj-$(CONFIG_CHT_WC_PMIC_OPREGION) += pmic/intel_pmic_chtwc.o
> +obj-$(CONFIG_DC_TI_PMIC_OPREGION) += pmic/intel_pmic_dc_ti.o
>  
>  obj-$(CONFIG_ACPI_CONFIGFS)	+= acpi_configfs.o
>  
> diff --git a/drivers/acpi/pmic/intel_pmic_dc_ti.c b/drivers/acpi/pmic/intel_pmic_dc_ti.c
> new file mode 100644
> index 000000000000..a2be1270eeeb
> --- /dev/null
> +++ b/drivers/acpi/pmic/intel_pmic_dc_ti.c
> @@ -0,0 +1,139 @@
> +/*
> + * Dollar Cove TI PMIC operation region driver
> + * Copyright (C) 2014 Intel Corporation. All rights reserved.
> + *
> + * Rewritten and cleaned up
> + * Copyright (C) 2017 Takashi Iwai <tiwai@suse.de>
> + */
> +
> +#include <linux/acpi.h>
> +#include <linux/init.h>
> +#include <linux/mfd/intel_soc_pmic.h>
> +#include <linux/platform_device.h>
> +#include "intel_pmic.h"
> +
> +/* registers stored in 16bit BE (high:low, total 10bit) */
> +#define DC_TI_VBAT	0x54
> +#define DC_TI_DIETEMP	0x56
> +#define DC_TI_BPTHERM	0x58
> +#define DC_TI_GPADC	0x5a
> +
> +static struct pmic_table dc_ti_power_table[] = {

const?

> +	{ .address = 0x00, .reg = 0x41 },
> +	{ .address = 0x04, .reg = 0x42 },
> +	{ .address = 0x08, .reg = 0x43 },
> +	{ .address = 0x0c, .reg = 0x45 },
> +	{ .address = 0x10, .reg = 0x46 },
> +	{ .address = 0x14, .reg = 0x47 },
> +	{ .address = 0x18, .reg = 0x48 },
> +	{ .address = 0x1c, .reg = 0x49 },
> +	{ .address = 0x20, .reg = 0x4a },
> +	{ .address = 0x24, .reg = 0x4b },
> +	{ .address = 0x28, .reg = 0x4c },
> +	{ .address = 0x2c, .reg = 0x4d },
> +	{ .address = 0x30, .reg = 0x4e },
> +};
> +
> +static struct pmic_table dc_ti_thermal_table[] = {

const?

> +	{
> +		.address = 0x00,
> +		.reg = DC_TI_GPADC
> +	},
> +	{
> +		.address = 0x0c,
> +		.reg = DC_TI_GPADC
> +	},
> +	/* TMP2 -> SYSTEMP */
> +	{
> +		.address = 0x18,
> +		.reg = DC_TI_GPADC
> +	},
> +	/* TMP3 -> BPTHERM */
> +	{
> +		.address = 0x24,
> +		.reg = DC_TI_BPTHERM
> +	},
> +	{
> +		.address = 0x30,
> +		.reg = DC_TI_GPADC
> +	},
> +	/* TMP5 -> DIETEMP */
> +	{
> +		.address = 0x3c,
> +		.reg = DC_TI_DIETEMP
> +	},
> +};
> +
> +static int dc_ti_pmic_get_power(struct regmap *regmap, int reg, int bit,
> +				u64 *value)
> +{
> +	int data;
> +
> +	if (regmap_read(regmap, reg, &data))
> +		return -EIO;
> +
> +	*value = data & 1;
> +	return 0;
> +}
> +
> +static int dc_ti_pmic_update_power(struct regmap *regmap, int reg, int bit,
> +				   bool on)
> +{
> +	return regmap_update_bits(regmap, reg, 1, on);
> +}
> +
> +static int dc_ti_pmic_get_raw_temp(struct regmap *regmap, int reg)
> +{
> +	u8 buf[2];
> +	unsigned int val;
> +
> +	if (regmap_bulk_read(regmap, reg, buf, 2))
> +		return -EIO;
> +
> +	/* stored in big-endian */
> +	val = buf[0] & 0x03;
> +	return (val << 8) | buf[1];
> +}
> +
> +static struct intel_pmic_opregion_data dc_ti_pmic_opregion_data = {

const?

> +	.get_power = dc_ti_pmic_get_power,
> +	.update_power = dc_ti_pmic_update_power,
> +	.get_raw_temp = dc_ti_pmic_get_raw_temp,
> +	.power_table = dc_ti_power_table,
> +	.power_table_count = ARRAY_SIZE(dc_ti_power_table),
> +	.thermal_table = dc_ti_thermal_table,
> +	.thermal_table_count = ARRAY_SIZE(dc_ti_thermal_table),
> +};
> +
> +static int dc_ti_pmic_opregion_probe(struct platform_device *pdev)
> +{
> +	struct intel_soc_pmic *pmic = dev_get_drvdata(pdev->dev.parent);
> +	int err;
> +
> +	err = intel_pmic_install_opregion_handler(&pdev->dev,
> +			ACPI_HANDLE(pdev->dev.parent), pmic->regmap,
> +			&dc_ti_pmic_opregion_data);
> +	if (err < 0)
> +		return err;
> +
> +	/* Re-enumerate devices depending on PMIC */
> +	acpi_walk_dep_device_list(ACPI_HANDLE(pdev->dev.parent));
> +	return 0;
> +}
> +
> +static struct platform_device_id dc_ti_pmic_opregion_id_table[] = {

const?

Regardless of the above,

Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>

Re: [PATCH v2 3/3] ACPI / PMIC: Add opregion driver for Intel Dollar Cove TI PMIC

[Takashi Iwai]

On Thu, 24 Aug 2017 11:14:53 +0200,
Mika Westerberg wrote:
> 
> On Thu, Aug 24, 2017 at 10:11:41AM +0200, Takashi Iwai wrote:
> > This patch adds the opregion driver for Dollar Cove TI PMIC on Intel
> > Cherry Trail devices.  The patch is based on the original work by
> > Intel, found at:
> >       https://github.com/01org/ProductionKernelQuilts
> > with many cleanups and rewrites.
> > 
> > The driver is currently provided only as built-in to follow other
> > PMIC opregion drivers convention.
> > 
> > The re-enumeration of devices at probe is required for fixing the
> > issues on HP x2 210 G2.  See bug#195689.
> > 
> > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891
> > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=195689
> > Signed-off-by: Takashi Iwai <tiwai@suse.de>
> > ---
> > v1->v2:
> > * get_raw_temp cleanup in opregion driver, mention about register
> >   endianess
> > 
> >  drivers/acpi/Kconfig                 |   6 ++
> >  drivers/acpi/Makefile                |   1 +
> >  drivers/acpi/pmic/intel_pmic_dc_ti.c | 139 +++++++++++++++++++++++++++++++++++
> >  3 files changed, 146 insertions(+)
> >  create mode 100644 drivers/acpi/pmic/intel_pmic_dc_ti.c
> > 
> > diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> > index 1ce52f84dc23..9da8dcefde7b 100644
> > --- a/drivers/acpi/Kconfig
> > +++ b/drivers/acpi/Kconfig
> > @@ -521,6 +521,12 @@ config CHT_WC_PMIC_OPREGION
> >  	help
> >  	  This config adds ACPI operation region support for CHT Whiskey Cove PMIC.
> >  
> > +config DC_TI_PMIC_OPREGION
> > +	bool "ACPI operation region support for Dollar Cove TI PMIC"
> > +	depends on INTEL_SOC_PMIC_DC_TI
> > +	help
> > +	  This config adds ACPI operation region support for Dollar Cove TI PMIC.
> > +
> >  endif
> >  
> >  config ACPI_CONFIGFS
> > diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
> > index b1aacfc62b1f..0a9008b971af 100644
> > --- a/drivers/acpi/Makefile
> > +++ b/drivers/acpi/Makefile
> > @@ -103,6 +103,7 @@ obj-$(CONFIG_CRC_PMIC_OPREGION) += pmic/intel_pmic_crc.o
> >  obj-$(CONFIG_XPOWER_PMIC_OPREGION) += pmic/intel_pmic_xpower.o
> >  obj-$(CONFIG_BXT_WC_PMIC_OPREGION) += pmic/intel_pmic_bxtwc.o
> >  obj-$(CONFIG_CHT_WC_PMIC_OPREGION) += pmic/intel_pmic_chtwc.o
> > +obj-$(CONFIG_DC_TI_PMIC_OPREGION) += pmic/intel_pmic_dc_ti.o
> >  
> >  obj-$(CONFIG_ACPI_CONFIGFS)	+= acpi_configfs.o
> >  
> > diff --git a/drivers/acpi/pmic/intel_pmic_dc_ti.c b/drivers/acpi/pmic/intel_pmic_dc_ti.c
> > new file mode 100644
> > index 000000000000..a2be1270eeeb
> > --- /dev/null
> > +++ b/drivers/acpi/pmic/intel_pmic_dc_ti.c
> > @@ -0,0 +1,139 @@
> > +/*
> > + * Dollar Cove TI PMIC operation region driver
> > + * Copyright (C) 2014 Intel Corporation. All rights reserved.
> > + *
> > + * Rewritten and cleaned up
> > + * Copyright (C) 2017 Takashi Iwai <tiwai@suse.de>
> > + */
> > +
> > +#include <linux/acpi.h>
> > +#include <linux/init.h>
> > +#include <linux/mfd/intel_soc_pmic.h>
> > +#include <linux/platform_device.h>
> > +#include "intel_pmic.h"
> > +
> > +/* registers stored in 16bit BE (high:low, total 10bit) */
> > +#define DC_TI_VBAT	0x54
> > +#define DC_TI_DIETEMP	0x56
> > +#define DC_TI_BPTHERM	0x58
> > +#define DC_TI_GPADC	0x5a
> > +
> > +static struct pmic_table dc_ti_power_table[] = {
> 
> const?
> 
> > +	{ .address = 0x00, .reg = 0x41 },
> > +	{ .address = 0x04, .reg = 0x42 },
> > +	{ .address = 0x08, .reg = 0x43 },
> > +	{ .address = 0x0c, .reg = 0x45 },
> > +	{ .address = 0x10, .reg = 0x46 },
> > +	{ .address = 0x14, .reg = 0x47 },
> > +	{ .address = 0x18, .reg = 0x48 },
> > +	{ .address = 0x1c, .reg = 0x49 },
> > +	{ .address = 0x20, .reg = 0x4a },
> > +	{ .address = 0x24, .reg = 0x4b },
> > +	{ .address = 0x28, .reg = 0x4c },
> > +	{ .address = 0x2c, .reg = 0x4d },
> > +	{ .address = 0x30, .reg = 0x4e },
> > +};
> > +
> > +static struct pmic_table dc_ti_thermal_table[] = {
> 
> const?

Oh yeah, I was too lazy.  Will cover up in the next round.


thanks,

Takashi

Re: [PATCH v2 3/3] ACPI / PMIC: Add opregion driver for Intel Dollar Cove TI PMIC

[Takashi Iwai]

On Thu, 24 Aug 2017 11:40:43 +0200,
Takashi Iwai wrote:
> 
> On Thu, 24 Aug 2017 11:14:53 +0200,
> Mika Westerberg wrote:
> > 
> > On Thu, Aug 24, 2017 at 10:11:41AM +0200, Takashi Iwai wrote:
> > > This patch adds the opregion driver for Dollar Cove TI PMIC on Intel
> > > Cherry Trail devices.  The patch is based on the original work by
> > > Intel, found at:
> > >       https://github.com/01org/ProductionKernelQuilts
> > > with many cleanups and rewrites.
> > > 
> > > The driver is currently provided only as built-in to follow other
> > > PMIC opregion drivers convention.
> > > 
> > > The re-enumeration of devices at probe is required for fixing the
> > > issues on HP x2 210 G2.  See bug#195689.
> > > 
> > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891
> > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=195689
> > > Signed-off-by: Takashi Iwai <tiwai@suse.de>
> > > ---
> > > v1->v2:
> > > * get_raw_temp cleanup in opregion driver, mention about register
> > >   endianess
> > > 
> > >  drivers/acpi/Kconfig                 |   6 ++
> > >  drivers/acpi/Makefile                |   1 +
> > >  drivers/acpi/pmic/intel_pmic_dc_ti.c | 139 +++++++++++++++++++++++++++++++++++
> > >  3 files changed, 146 insertions(+)
> > >  create mode 100644 drivers/acpi/pmic/intel_pmic_dc_ti.c
> > > 
> > > diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> > > index 1ce52f84dc23..9da8dcefde7b 100644
> > > --- a/drivers/acpi/Kconfig
> > > +++ b/drivers/acpi/Kconfig
> > > @@ -521,6 +521,12 @@ config CHT_WC_PMIC_OPREGION
> > >  	help
> > >  	  This config adds ACPI operation region support for CHT Whiskey Cove PMIC.
> > >  
> > > +config DC_TI_PMIC_OPREGION
> > > +	bool "ACPI operation region support for Dollar Cove TI PMIC"
> > > +	depends on INTEL_SOC_PMIC_DC_TI
> > > +	help
> > > +	  This config adds ACPI operation region support for Dollar Cove TI PMIC.
> > > +
> > >  endif
> > >  
> > >  config ACPI_CONFIGFS
> > > diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
> > > index b1aacfc62b1f..0a9008b971af 100644
> > > --- a/drivers/acpi/Makefile
> > > +++ b/drivers/acpi/Makefile
> > > @@ -103,6 +103,7 @@ obj-$(CONFIG_CRC_PMIC_OPREGION) += pmic/intel_pmic_crc.o
> > >  obj-$(CONFIG_XPOWER_PMIC_OPREGION) += pmic/intel_pmic_xpower.o
> > >  obj-$(CONFIG_BXT_WC_PMIC_OPREGION) += pmic/intel_pmic_bxtwc.o
> > >  obj-$(CONFIG_CHT_WC_PMIC_OPREGION) += pmic/intel_pmic_chtwc.o
> > > +obj-$(CONFIG_DC_TI_PMIC_OPREGION) += pmic/intel_pmic_dc_ti.o
> > >  
> > >  obj-$(CONFIG_ACPI_CONFIGFS)	+= acpi_configfs.o
> > >  
> > > diff --git a/drivers/acpi/pmic/intel_pmic_dc_ti.c b/drivers/acpi/pmic/intel_pmic_dc_ti.c
> > > new file mode 100644
> > > index 000000000000..a2be1270eeeb
> > > --- /dev/null
> > > +++ b/drivers/acpi/pmic/intel_pmic_dc_ti.c
> > > @@ -0,0 +1,139 @@
> > > +/*
> > > + * Dollar Cove TI PMIC operation region driver
> > > + * Copyright (C) 2014 Intel Corporation. All rights reserved.
> > > + *
> > > + * Rewritten and cleaned up
> > > + * Copyright (C) 2017 Takashi Iwai <tiwai@suse.de>
> > > + */
> > > +
> > > +#include <linux/acpi.h>
> > > +#include <linux/init.h>
> > > +#include <linux/mfd/intel_soc_pmic.h>
> > > +#include <linux/platform_device.h>
> > > +#include "intel_pmic.h"
> > > +
> > > +/* registers stored in 16bit BE (high:low, total 10bit) */
> > > +#define DC_TI_VBAT	0x54
> > > +#define DC_TI_DIETEMP	0x56
> > > +#define DC_TI_BPTHERM	0x58
> > > +#define DC_TI_GPADC	0x5a
> > > +
> > > +static struct pmic_table dc_ti_power_table[] = {
> > 
> > const?
> > 
> > > +	{ .address = 0x00, .reg = 0x41 },
> > > +	{ .address = 0x04, .reg = 0x42 },
> > > +	{ .address = 0x08, .reg = 0x43 },
> > > +	{ .address = 0x0c, .reg = 0x45 },
> > > +	{ .address = 0x10, .reg = 0x46 },
> > > +	{ .address = 0x14, .reg = 0x47 },
> > > +	{ .address = 0x18, .reg = 0x48 },
> > > +	{ .address = 0x1c, .reg = 0x49 },
> > > +	{ .address = 0x20, .reg = 0x4a },
> > > +	{ .address = 0x24, .reg = 0x4b },
> > > +	{ .address = 0x28, .reg = 0x4c },
> > > +	{ .address = 0x2c, .reg = 0x4d },
> > > +	{ .address = 0x30, .reg = 0x4e },
> > > +};
> > > +
> > > +static struct pmic_table dc_ti_thermal_table[] = {
> > 
> > const?
> 
> Oh yeah, I was too lazy.  Will cover up in the next round.

It seems that power_table and thermal_table are non-const in the
definition.  Also opregion_data is also passed as non-const to
intel_pmic_install_opregion_handler().

So only id_table[] can be const, so far.

(It's a good hint for further cleanup patches ;)


thanks,

Takashi

Re: [PATCH v2 3/3] ACPI / PMIC: Add opregion driver for Intel Dollar Cove TI PMIC

[Andy Shevchenko]

On Thu, Aug 24, 2017 at 11:11 AM, Takashi Iwai <tiwai@suse.de> wrote:
> This patch adds the opregion driver for Dollar Cove TI PMIC on Intel
> Cherry Trail devices.  The patch is based on the original work by
> Intel, found at:
>       https://github.com/01org/ProductionKernelQuilts
> with many cleanups and rewrites.
>
> The driver is currently provided only as built-in to follow other
> PMIC opregion drivers convention.
>
> The re-enumeration of devices at probe is required for fixing the
> issues on HP x2 210 G2.  See bug#195689.
>

One comment below, otherwise

Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>

> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=195689
> Signed-off-by: Takashi Iwai <tiwai@suse.de>
> ---
> v1->v2:
> * get_raw_temp cleanup in opregion driver, mention about register
>   endianess
>
>  drivers/acpi/Kconfig                 |   6 ++
>  drivers/acpi/Makefile                |   1 +
>  drivers/acpi/pmic/intel_pmic_dc_ti.c | 139 +++++++++++++++++++++++++++++++++++
>  3 files changed, 146 insertions(+)
>  create mode 100644 drivers/acpi/pmic/intel_pmic_dc_ti.c
>
> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> index 1ce52f84dc23..9da8dcefde7b 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -521,6 +521,12 @@ config CHT_WC_PMIC_OPREGION
>         help
>           This config adds ACPI operation region support for CHT Whiskey Cove PMIC.
>
> +config DC_TI_PMIC_OPREGION
> +       bool "ACPI operation region support for Dollar Cove TI PMIC"
> +       depends on INTEL_SOC_PMIC_DC_TI
> +       help
> +         This config adds ACPI operation region support for Dollar Cove TI PMIC.
> +
>  endif
>
>  config ACPI_CONFIGFS
> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
> index b1aacfc62b1f..0a9008b971af 100644
> --- a/drivers/acpi/Makefile
> +++ b/drivers/acpi/Makefile
> @@ -103,6 +103,7 @@ obj-$(CONFIG_CRC_PMIC_OPREGION) += pmic/intel_pmic_crc.o
>  obj-$(CONFIG_XPOWER_PMIC_OPREGION) += pmic/intel_pmic_xpower.o
>  obj-$(CONFIG_BXT_WC_PMIC_OPREGION) += pmic/intel_pmic_bxtwc.o
>  obj-$(CONFIG_CHT_WC_PMIC_OPREGION) += pmic/intel_pmic_chtwc.o
> +obj-$(CONFIG_DC_TI_PMIC_OPREGION) += pmic/intel_pmic_dc_ti.o
>
>  obj-$(CONFIG_ACPI_CONFIGFS)    += acpi_configfs.o
>
> diff --git a/drivers/acpi/pmic/intel_pmic_dc_ti.c b/drivers/acpi/pmic/intel_pmic_dc_ti.c
> new file mode 100644
> index 000000000000..a2be1270eeeb
> --- /dev/null
> +++ b/drivers/acpi/pmic/intel_pmic_dc_ti.c
> @@ -0,0 +1,139 @@
> +/*
> + * Dollar Cove TI PMIC operation region driver
> + * Copyright (C) 2014 Intel Corporation. All rights reserved.
> + *
> + * Rewritten and cleaned up
> + * Copyright (C) 2017 Takashi Iwai <tiwai@suse.de>
> + */
> +
> +#include <linux/acpi.h>
> +#include <linux/init.h>
> +#include <linux/mfd/intel_soc_pmic.h>
> +#include <linux/platform_device.h>
> +#include "intel_pmic.h"
> +
> +/* registers stored in 16bit BE (high:low, total 10bit) */
> +#define DC_TI_VBAT     0x54
> +#define DC_TI_DIETEMP  0x56
> +#define DC_TI_BPTHERM  0x58
> +#define DC_TI_GPADC    0x5a
> +
> +static struct pmic_table dc_ti_power_table[] = {
> +       { .address = 0x00, .reg = 0x41 },
> +       { .address = 0x04, .reg = 0x42 },
> +       { .address = 0x08, .reg = 0x43 },
> +       { .address = 0x0c, .reg = 0x45 },
> +       { .address = 0x10, .reg = 0x46 },
> +       { .address = 0x14, .reg = 0x47 },
> +       { .address = 0x18, .reg = 0x48 },
> +       { .address = 0x1c, .reg = 0x49 },
> +       { .address = 0x20, .reg = 0x4a },
> +       { .address = 0x24, .reg = 0x4b },
> +       { .address = 0x28, .reg = 0x4c },
> +       { .address = 0x2c, .reg = 0x4d },
> +       { .address = 0x30, .reg = 0x4e },
> +};
> +
> +static struct pmic_table dc_ti_thermal_table[] = {
> +       {
> +               .address = 0x00,
> +               .reg = DC_TI_GPADC
> +       },
> +       {
> +               .address = 0x0c,
> +               .reg = DC_TI_GPADC
> +       },
> +       /* TMP2 -> SYSTEMP */
> +       {
> +               .address = 0x18,
> +               .reg = DC_TI_GPADC
> +       },
> +       /* TMP3 -> BPTHERM */
> +       {
> +               .address = 0x24,
> +               .reg = DC_TI_BPTHERM
> +       },
> +       {
> +               .address = 0x30,
> +               .reg = DC_TI_GPADC
> +       },
> +       /* TMP5 -> DIETEMP */
> +       {
> +               .address = 0x3c,
> +               .reg = DC_TI_DIETEMP
> +       },
> +};
> +
> +static int dc_ti_pmic_get_power(struct regmap *regmap, int reg, int bit,
> +                               u64 *value)
> +{
> +       int data;
> +
> +       if (regmap_read(regmap, reg, &data))
> +               return -EIO;
> +
> +       *value = data & 1;
> +       return 0;
> +}
> +
> +static int dc_ti_pmic_update_power(struct regmap *regmap, int reg, int bit,
> +                                  bool on)
> +{
> +       return regmap_update_bits(regmap, reg, 1, on);
> +}
> +
> +static int dc_ti_pmic_get_raw_temp(struct regmap *regmap, int reg)
> +{
> +       u8 buf[2];
> +       unsigned int val;
> +
> +       if (regmap_bulk_read(regmap, reg, buf, 2))
> +               return -EIO;
> +
> +       /* stored in big-endian */

> +       val = buf[0] & 0x03;
> +       return (val << 8) | buf[1];

Do you need a temporary variable at all?

       return ((buf[0] & 0x03) << 8) | buf[1];

> +}
> +
> +static struct intel_pmic_opregion_data dc_ti_pmic_opregion_data = {
> +       .get_power = dc_ti_pmic_get_power,
> +       .update_power = dc_ti_pmic_update_power,
> +       .get_raw_temp = dc_ti_pmic_get_raw_temp,
> +       .power_table = dc_ti_power_table,
> +       .power_table_count = ARRAY_SIZE(dc_ti_power_table),
> +       .thermal_table = dc_ti_thermal_table,
> +       .thermal_table_count = ARRAY_SIZE(dc_ti_thermal_table),
> +};
> +
> +static int dc_ti_pmic_opregion_probe(struct platform_device *pdev)
> +{
> +       struct intel_soc_pmic *pmic = dev_get_drvdata(pdev->dev.parent);
> +       int err;
> +
> +       err = intel_pmic_install_opregion_handler(&pdev->dev,
> +                       ACPI_HANDLE(pdev->dev.parent), pmic->regmap,
> +                       &dc_ti_pmic_opregion_data);
> +       if (err < 0)
> +               return err;
> +
> +       /* Re-enumerate devices depending on PMIC */
> +       acpi_walk_dep_device_list(ACPI_HANDLE(pdev->dev.parent));
> +       return 0;
> +}
> +
> +static struct platform_device_id dc_ti_pmic_opregion_id_table[] = {
> +       { .name = "dc_ti_region" },
> +       {},
> +};
> +
> +static struct platform_driver dc_ti_pmic_opregion_driver = {
> +       .probe = dc_ti_pmic_opregion_probe,
> +       .driver = {
> +               .name = "dollar_cove_ti_pmic",
> +       },
> +       .id_table = dc_ti_pmic_opregion_id_table,
> +};
> +module_platform_driver(dc_ti_pmic_opregion_driver);
> +
> +MODULE_DESCRIPTION("Dollar Cove TI PMIC opregion driver");
> +MODULE_LICENSE("GPL v2");
> --
> 2.14.0
>



-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 3/3] ACPI / PMIC: Add opregion driver for Intel Dollar Cove TI PMIC

[Takashi Iwai]

On Thu, 24 Aug 2017 11:23:18 +0200,
Andy Shevchenko wrote:
> 
> On Thu, Aug 24, 2017 at 11:11 AM, Takashi Iwai <tiwai@suse.de> wrote:
> > This patch adds the opregion driver for Dollar Cove TI PMIC on Intel
> > Cherry Trail devices.  The patch is based on the original work by
> > Intel, found at:
> >       https://github.com/01org/ProductionKernelQuilts
> > with many cleanups and rewrites.
> >
> > The driver is currently provided only as built-in to follow other
> > PMIC opregion drivers convention.
> >
> > The re-enumeration of devices at probe is required for fixing the
> > issues on HP x2 210 G2.  See bug#195689.
> >
> 
> One comment below, otherwise
(snip)
> > +static int dc_ti_pmic_get_raw_temp(struct regmap *regmap, int reg)
> > +{
> > +       u8 buf[2];
> > +       unsigned int val;
> > +
> > +       if (regmap_bulk_read(regmap, reg, buf, 2))
> > +               return -EIO;
> > +
> > +       /* stored in big-endian */
> 
> > +       val = buf[0] & 0x03;
> > +       return (val << 8) | buf[1];
> 
> Do you need a temporary variable at all?
> 
>        return ((buf[0] & 0x03) << 8) | buf[1];

Right it can be dropped.  Will address it in the next round.


thanks,

Takashi

Re: [PATCH v2 0/3] Dollar Cove TI PMIC support for Intel Cherry Trail

[Andy Shevchenko]

On Thu, Aug 24, 2017 at 11:11 AM, Takashi Iwai <tiwai@suse.de> wrote:
> Hi,
>
> this is the revised patch set to add the support for Dollar Cove TI
> PMIC found on some Intel Cherry Trail laptops / tablets.  All drivers
> are based on the original code from Intel downstream patches, with
> lots of rewrites and cleanups.  MFD driver is implemented as a
> stand-alone like a few other variants, and the input driver got a diet
> in a minimalistic form.
>
> The patch set has been tested on ASUS E100H and E200H, as well as on
> HP x210.
>
> v1->v2:
> - Minor cleanups in mfd driver code as suggested by Andy
> - Move power-button driver to platform/x86, driver renames accordingly
> - Add missing wake-irq cleanup to power-button driver
> - get_raw_temp cleanup in opregion driver, mention about register
>   endianess
>
>

Global comment to the series, we agreed with Hans to follow the
pattern for Intel PMIC driver (module / file) names:

intel_XXX_<PLATFORM><PMIC>, where <PLATFORM> is 3 letter encoded Intel
platform name, like cht for CherryTrail and <PMIC> is two letter
abbreviation from ZZZ Cove, like wc for Whiskey Cove.

Here I understand that there is a potential of two PMIC variants for
the same platform DC from Intel, DC from TI. I dunno if former will be
a case in the future, though we may use something like

 intel_XXX_chtdc_ti

for the latter one.

> thanks,
>
> Takashi
>
> ===
>
> Takashi Iwai (3):
>   mfd: Add support for Cherry Trail Dollar Cove TI PMIC
>   platform/x86: Add support for Dollar Cove TI power button
>   ACPI / PMIC: Add opregion driver for Intel Dollar Cove TI PMIC
>
>  drivers/acpi/Kconfig                      |   6 +
>  drivers/acpi/Makefile                     |   1 +
>  drivers/acpi/pmic/intel_pmic_dc_ti.c      | 139 +++++++++++++++++++++++
>  drivers/mfd/Kconfig                       |  13 +++
>  drivers/mfd/Makefile                      |   1 +
>  drivers/mfd/intel_soc_pmic_dc_ti.c        | 182 ++++++++++++++++++++++++++++++
>  drivers/platform/x86/Kconfig              |   8 ++
>  drivers/platform/x86/Makefile             |   1 +
>  drivers/platform/x86/intel_dc_ti_pwrbtn.c |  96 ++++++++++++++++
>  9 files changed, 447 insertions(+)
>  create mode 100644 drivers/acpi/pmic/intel_pmic_dc_ti.c
>  create mode 100644 drivers/mfd/intel_soc_pmic_dc_ti.c
>  create mode 100644 drivers/platform/x86/intel_dc_ti_pwrbtn.c
>
> --
> 2.14.0
>



-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 0/3] Dollar Cove TI PMIC support for Intel Cherry Trail

[Takashi Iwai]

On Thu, 24 Aug 2017 11:27:32 +0200,
Andy Shevchenko wrote:
> 
> On Thu, Aug 24, 2017 at 11:11 AM, Takashi Iwai <tiwai@suse.de> wrote:
> > Hi,
> >
> > this is the revised patch set to add the support for Dollar Cove TI
> > PMIC found on some Intel Cherry Trail laptops / tablets.  All drivers
> > are based on the original code from Intel downstream patches, with
> > lots of rewrites and cleanups.  MFD driver is implemented as a
> > stand-alone like a few other variants, and the input driver got a diet
> > in a minimalistic form.
> >
> > The patch set has been tested on ASUS E100H and E200H, as well as on
> > HP x210.
> >
> > v1->v2:
> > - Minor cleanups in mfd driver code as suggested by Andy
> > - Move power-button driver to platform/x86, driver renames accordingly
> > - Add missing wake-irq cleanup to power-button driver
> > - get_raw_temp cleanup in opregion driver, mention about register
> >   endianess
> >
> >
> 
> Global comment to the series, we agreed with Hans to follow the
> pattern for Intel PMIC driver (module / file) names:
> 
> intel_XXX_<PLATFORM><PMIC>, where <PLATFORM> is 3 letter encoded Intel
> platform name, like cht for CherryTrail and <PMIC> is two letter
> abbreviation from ZZZ Cove, like wc for Whiskey Cove.
> 
> Here I understand that there is a potential of two PMIC variants for
> the same platform DC from Intel, DC from TI. I dunno if former will be
> a case in the future, though we may use something like
> 
>  intel_XXX_chtdc_ti
> 
> for the latter one.

Noted.

Also I forgot again to add Hans to Cc.  Will put him in the next
round.


thanks,

Takashi