| Message ID | 20170904144340.27693-2-tiwai@suse.de (mailing list archive) |
|---|---|
| State | Awaiting Upstream, archived |
| Delegated to: | Andy Shevchenko |
| Headers | show |
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>
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
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
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?
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.
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
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
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
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.
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
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
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.
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.
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
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.
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
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
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
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.
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.
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.
> > 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?
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
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
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.
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
> > > 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.
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 >
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. :-)
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.
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.
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
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
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.
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
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!
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 :)
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.
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.
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 >
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
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.
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. > >
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
> > > > > > > > > > > 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.
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
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. :)
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
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 --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");