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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 6 Sep 2017 08:54:44 +0100
From:   Lee Jones <lee.jones@...aro.org>
To:     Takashi Iwai <tiwai@...e.de>
Cc:     Darren Hart <dvhart@...radead.org>,
        Andy Shevchenko <andy@...radead.org>,
        "Rafael J . Wysocki" <rjw@...ysocki.net>,
        Mika Westerberg <mika.westerberg@...ux.intel.com>,
        Johannes Stezenbach <js@...21.net>,
        Hans de Goede <hdegoede@...hat.com>,
        Dmitry Torokhov <dmitry.torokhov@...il.com>,
        platform-driver-x86@...r.kernel.org, linux-acpi@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 1/3] mfd: Add support for Cherry Trail Dollar Cove TI
 PMIC

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@...ux.intel.com>
> > > > > > > Reviewed-by: Andy Shevchenko <andy.shevchenko@...il.com>
> > > > > > > Signed-off-by: Takashi Iwai <tiwai@...e.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@...aro.org>
> > > > > 
> > > > > Thanks!
> > > > > 
> > > > > Now the question is how to deal with these.  It's no critical things,
> > > > > so I'm OK to postpone for 4.15.  OTOH, it's really a new
> > > > > device-specific stuff, thus it can't break anything else, and it'd be
> > > > > fairly safe to add it for 4.14 although it's at a bit late stage.
> > > > 
> > > > Yes, you are over 2 weeks late for v4.14.  It will have to be v4.15.
> > > 
> > > OK, I'll ring your bells again once when 4.15 development is opened.
> > > 
> > > 
> > > > > IMO, it'd be great if you can carry all stuff through MFD tree; or
> > > > > create an immutable branch (again).  But how to handle it, when to do
> > > > > it, It's all up to you guys.
> > > > 
> > > > If there aren't any build dependencies between the patches, each of
> > > > the patches should be applied through their own trees.  What are the
> > > > build-time dependencies?  Are there any?
> > > 
> > > No, there is no strict build-time dependency.  It's just that I don't
> > > see it nice to have a commit for a dead code, partly for testing
> > > purpose and partly for code consistency.  But if this makes
> > > maintenance easier, I'm happy with that, too, of course.
> > 
> > There won't be any dead code.  All of the subsystem trees are pulled
> > into -next [0] where the build bots can operate on the patches as a
> > whole.
> 
> But the merge order isn't guaranteed, i.e. at the commit of other tree
> for this new stuff, it's a dead code without merging the MFD stuff
> beforehand.  e.g. Imagine to perform the git bisection.  It's not
> about the whole tree, but about the each commit.

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

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


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

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