diff mbox

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

Message ID 20170904144340.27693-2-tiwai@suse.de (mailing list archive)
State Not Applicable, archived
Headers show

Commit Message

Takashi Iwai Sept. 4, 2017, 2:43 p.m. UTC
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

Comments

Lee Jones Sept. 5, 2017, 7:24 a.m. UTC | #1
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>
Takashi Iwai Sept. 5, 2017, 7:46 a.m. UTC | #2
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
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Hans de Goede Sept. 5, 2017, 8 a.m. UTC | #3
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
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Lee Jones Sept. 5, 2017, 8:10 a.m. UTC | #4
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 Sept. 5, 2017, 8:11 a.m. UTC | #5
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.
Takashi Iwai Sept. 5, 2017, 8:12 a.m. UTC | #6
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
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Takashi Iwai Sept. 5, 2017, 8:20 a.m. UTC | #7
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
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Lee Jones Sept. 5, 2017, 8:53 a.m. UTC | #8
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 Sept. 5, 2017, 8:54 a.m. UTC | #9
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.
Takashi Iwai Sept. 5, 2017, 9:38 a.m. UTC | #10
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
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Rafael J. Wysocki Sept. 5, 2017, 10:31 a.m. UTC | #11
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
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Lee Jones Sept. 6, 2017, 7:54 a.m. UTC | #12
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 Sept. 6, 2017, 7:58 a.m. UTC | #13
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.
Takashi Iwai Sept. 6, 2017, 8:23 a.m. UTC | #14
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
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Lee Jones Sept. 6, 2017, 9:05 a.m. UTC | #15
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.
Takashi Iwai Sept. 6, 2017, 10:06 a.m. UTC | #16
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
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Rafael J. Wysocki Sept. 6, 2017, 10:09 a.m. UTC | #17
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

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Rafael J. Wysocki Sept. 6, 2017, 10:21 a.m. UTC | #18
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

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Lee Jones Sept. 6, 2017, 10:40 a.m. UTC | #19
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 Sept. 6, 2017, 10:47 a.m. UTC | #20
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 Sept. 6, 2017, 10:50 a.m. UTC | #21
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 Sept. 6, 2017, 10:52 a.m. UTC | #22
> > 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?
Takashi Iwai Sept. 6, 2017, 10:58 a.m. UTC | #23
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
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Rafael J. Wysocki Sept. 6, 2017, 11:01 a.m. UTC | #24
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

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Lee Jones Sept. 6, 2017, 1:51 p.m. UTC | #25
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.
Takashi Iwai Sept. 6, 2017, 2:34 p.m. UTC | #26
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
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Lee Jones Sept. 6, 2017, 2:54 p.m. UTC | #27
> > > 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.
Takashi Iwai Sept. 6, 2017, 3:02 p.m. UTC | #28
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
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Rafael J. Wysocki Sept. 6, 2017, 10:19 p.m. UTC | #29
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. :-)

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Lee Jones Sept. 7, 2017, 7:39 a.m. UTC | #30
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 Sept. 7, 2017, 8 a.m. UTC | #31
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.
Takashi Iwai Sept. 7, 2017, 9:32 a.m. UTC | #32
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
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Rafael J. Wysocki Sept. 7, 2017, 10:52 a.m. UTC | #33
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

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Lee Jones Sept. 7, 2017, 10:53 a.m. UTC | #34
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.
Rafael J. Wysocki Sept. 7, 2017, 10:59 a.m. UTC | #35
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

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Rafael J. Wysocki Sept. 7, 2017, 10:59 a.m. UTC | #36
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!

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Mika Westerberg Sept. 7, 2017, 11:07 a.m. UTC | #37
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 :)
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Lee Jones Sept. 7, 2017, 11:13 a.m. UTC | #38
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 Sept. 7, 2017, 11:17 a.m. UTC | #39
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.
Takashi Iwai Sept. 7, 2017, 11:41 a.m. UTC | #40
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
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Takashi Iwai Sept. 7, 2017, 11:44 a.m. UTC | #41
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
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Lee Jones Sept. 7, 2017, 12:24 p.m. UTC | #42
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 Sept. 7, 2017, 12:28 p.m. UTC | #43
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.
> >
Takashi Iwai Sept. 7, 2017, 12:48 p.m. UTC | #44
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
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Lee Jones Sept. 7, 2017, 1 p.m. UTC | #45
> > > > > > > > > > > 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.
Takashi Iwai Sept. 7, 2017, 1:11 p.m. UTC | #46
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
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Lee Jones Sept. 7, 2017, 1:22 p.m. UTC | #47
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. :)
Takashi Iwai Sept. 7, 2017, 1:30 p.m. UTC | #48
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
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Lee Jones Sept. 7, 2017, 2:13 p.m. UTC | #49
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
diff mbox

Patch

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");