linux-kernel - Re: [RESEND PATCH 11/11] tools/power turbostat: enable turbostat to support Knights Mill (KNM)

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:   Thu, 1 Dec 2016 01:47:09 -0500
From:   Len Brown <lenb@...nel.org>
To:     Piotr Luc <piotr.luc@...el.com>
Cc:     Mauro Carvalho Chehab <mchehab@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>, X86 ML <x86@...nel.org>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Viresh Kumar <viresh.kumar@...aro.org>,
        Doug Thompson <dougthompson@...ssion.com>,
        Borislav Petkov <bp@...en8.de>, linux-edac@...r.kernel.org,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Linux PM list <linux-pm@...r.kernel.org>,
        Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>
Subject: Re: [RESEND PATCH 11/11] tools/power turbostat: enable turbostat to
 support Knights Mill (KNM)

Piotr,
Thanks for sending the patch, I've made this change to my turbostat
branch for 4.10.

I did not apply your patch directly because for some reason it didn't
appear in patchwork for linux-pm,
only for lkml, which I do not review.

Also, your patch depended on your style update patch to use the model # macros.
Unfortunately what you did not know was that I'd already applied a
slightly different style update patch.
(and it was my fault that I did not push it upstream before my summer
sabbatical, sorry)

In general, though, a good strategy when mixing style and functionality patches
is to do the functionality first.  The reason is both that style
patches tend to conflict more,
and you don't want them to hold up the functionality.
Also, if your functionality patch does not depend on style,
it is easier to backport to distros who avoid style updates.

Fortunately, this one was trivial.

thanks,
Len Brown, Intel Open Source Technology Center