From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755389AbdIGNaG (ORCPT ); Thu, 7 Sep 2017 09:30:06 -0400 Received: from mx2.suse.de ([195.135.220.15]:60566 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1755353AbdIGNaE (ORCPT ); Thu, 7 Sep 2017 09:30:04 -0400 Date: Thu, 07 Sep 2017 15:30:02 +0200 Message-ID: From: Takashi Iwai To: Lee Jones Cc: Takashi Iwai , Darren Hart , Andy Shevchenko , "Rafael J . Wysocki" , Mika Westerberg , Johannes Stezenbach , Hans de Goede , Dmitry Torokhov , platform-driver-x86@vger.kernel.org, linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v5 1/3] mfd: Add support for Cherry Trail Dollar Cove TI PMIC In-Reply-To: <20170907130001.bkwuljsejrks63x3@dell> References: <20170905072451.ephscqjqgwpnl6da@dell> <20170905081049.r3gbdtr2iuom6uk6@dell> <20170905085449.dsadovrpmpj6vsvv@dell> <20170907105348.i52vnf732xpxjubq@dell> <20170907122834.nhsd5pgv2azwdcg4@dell> <20170907130001.bkwuljsejrks63x3@dell> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/25.2 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 > > > > > > > > > > > > Reviewed-by: Andy Shevchenko > > > > > > > > > > > > Signed-off-by: Takashi Iwai > > > > > > > > > > > > --- > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > 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