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

2016-12-01 Thread Luc, Piotr
On Thu, 2016-12-01 at 01:47 -0500, Len Brown wrote:
> 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.

The missing from linux-pm was my mistake due to lack of experience and
perspicacity; I did not add the linux-pm list to cc because I could not
find an entry for turbostat on MAINTAINERS file. Probably, it is
mentioned implicitly but I did not come across it.
> 
> 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)

NP, this was an easy change made automatically by my script.

> 
> 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.

Thanks for the tip.
However, in this case, I got comments to use the macros instead raw
numbers in my patch and remove unnecessary comments. It caused that the
style patch came first.

Thanks
Piotr

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

2016-11-30 Thread Len Brown
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