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@xxxxxxxxxxxxxxx> > > > > > > > > > > > > Reviewed-by: Andy Shevchenko <andy.shevchenko@xxxxxxxxx> > > > > > > > > > > > > Signed-off-by: Takashi Iwai <tiwai@xxxxxxx> > > > > > > > > > > > > --- > > > > > > > > > > > > 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@xxxxxxxxxx> > > > > > > > > > > > > > > > > > > > > Thanks! > > > > > > > > > > > > > > > > > > > > Now the question is how to deal with these. It's no critical things, > > > > > > > > > > so I'm OK to postpone for 4.15. OTOH, it's really a new > > > > > > > > > > device-specific stuff, thus it can't break anything else, and it'd be > > > > > > > > > > fairly safe to add it for 4.14 although it's at a bit late stage. > > > > > > > > > > > > > > > > > > Yes, you are over 2 weeks late for v4.14. It will have to be v4.15. > > > > > > > > > > > > > > > > OK, I'll ring your bells again once when 4.15 development is opened. > > > > > > > > > > > > > > > > > > > > > > > > > > IMO, it'd be great if you can carry all stuff through MFD tree; or > > > > > > > > > > create an immutable branch (again). But how to handle it, when to do > > > > > > > > > > it, It's all up to you guys. > > > > > > > > > > > > > > > > > > If there aren't any build dependencies between the patches, each of > > > > > > > > > the patches should be applied through their own trees. What are the > > > > > > > > > build-time dependencies? Are there any? > > > > > > > > > > > > > > > > No, there is no strict build-time dependency. It's just that I don't > > > > > > > > see it nice to have a commit for a dead code, partly for testing > > > > > > > > purpose and partly for code consistency. But if this makes > > > > > > > > maintenance easier, I'm happy with that, too, of course. > > > > > > > > > > > > > > There won't be any dead code. All of the subsystem trees are pulled > > > > > > > into -next [0] where the build bots can operate on the patches as a > > > > > > > whole. > > > > > > > > > > > > But the merge order isn't guaranteed, i.e. at the commit of other tree > > > > > > for this new stuff, it's a dead code without merging the MFD stuff > > > > > > beforehand. e.g. Imagine to perform the git bisection. It's not > > > > > > about the whole tree, but about the each commit. > > > > > > > > > > Only *building* is relevant for bisection until the whole feature > > > > > lands. > > > > > > > > Why only building? > > > > > > > > When merging through several tress, commits for the same series are > > > > scattered completely although they are softly tied. This sucks when > > > > you perform git bisection, e.g. if you have an issue in the middle of > > > > the patch series. It still works, but it jumps unnecessarily too far > > > > away and back before reaching to the point, and kconfig appears / > > > > disappears inconsistently (the dependent kconfig gone in the middle). > > > > And, this is about the release kernel (4.15 or whatever). > > > > > > Think about how bisection works. You state a good commit and a bad > > > one. The good commit will be when the feature last worked, which will > > > not be until the feature has fully landed. Bisect will not check any > > > point prior to this date. > > > > > > If there aren't any build deps, each Maintainer will apply patches > > > into their own tree. These will be merged together in -next where > > > they can be tested, both manually and by the 0-days. Once the merge > > > window is opened all patches will be sucked into -rc1. If the feature > > > works here, then it you could use -rc1 as your 'good' commit. If it > > > doesn't, then this could indicate a merge error or a missing piece of > > > the set, either way bisect wouldn't help you. > > > > Not really. > > > > First of all, most of user start testing from the release kernel, so > > you can't trust that RC covered all test cases. (Who can blame users > > who didn't use / test RC?) > > > > Second, you ignore the fact that the development continues after > > merging *this* patchset. What if a breakage is introduced after this > > patch? (See below) > > > > They often need a full bisection between the previous release and the > > current release. > > > > > > Basically, my complaint here comes with my user's hat on. It *is* > > > > indeed worse than a straight application of patches in some levels. > > > > It's unavoidable if you do in that way. > > > > > > I disagree. I user wouldn't set the 'good' commit at any point prior > > > to the feature working at least once. > > > > Again no, not all users do test at the same time. A device driver > > may support multiple devices / platforms, and it might be that the bug > > manifests itself only on a certain system that no one has tested > > beforehand; it's a typical case we often see after the releases. > > > > > This will not happen if any > > > parts were missing. The order in which the pieces are applied is > > > irrelevant if there aren't any build deps between them. If you bisect > > > between them, then the driver simply will not build. No problem. > > > > The bisection is required not only for build errors but also for > > functional tests. Sometimes it's the only way to spot the culprit of > > a functional regression. > > > > Imagine the following case: both MFD and platform drivers are merged > > into individual trees separately. And, some change in platform driver > > after this patch series broke some functionality mistakenly. > > > > Now, suppose that the platform tree is merged to Linus tree before MFD > > tree, that is, the situation is like: > > > > MFD (commit A1) -- ... -------------------------+ > > platform (commit B1) -> broken change (B2) -+ | > > v v > > --M1--M2--> Linus RC1 > > > > git-bisection can inspect M2, which shows already broken. Then it > > inspects M1, but you can't evaluate it because the target platform > > driver can't be built without A1. At this point, you're stuck. > > But in this case, B1 is correct and B2 is the culprit. How can you > > spot it out? > > > > OTOH, if the merge history honors the functional dependency, you can > > bisect properly. > > Exactly and not only that. > > If the git history reflects the logical dependencies between patches, > you should be able to figure out the reason why the code was changed > this way (sometimes you can't anyway if commit logs suck, for example, > but this is a different problem) which quite often is essential for > debugging, backporting and similar. The example you reference is a really small corner case (I don't recall an occurrence) and is very easy to debug without bisect. The pros of taking patches in via their pre-defined subsystem trees far outweighs the slight possibility and the debugging complexity of this example. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
