Re: [PATCH resend] platform/x86: intel-uncore-freq: add Emerald Rapids support

[Hans de Goede <hdegoede@redhat.com>]

Hi Rafael,

On 11/23/22 15:59, Rafael J. Wysocki wrote:
> On Wed, Nov 23, 2022 at 3:37 PM Hans de Goede <hdegoede@redhat.com> wrote:
>>
>> Hi,
>>
>> On 11/23/22 09:45, Artem Bityutskiy wrote:
>>> Hello Hans,
>>>
>>> On Tue, 2022-11-22 at 16:30 +0100, Hans de Goede wrote:
>>> There are 3 different issues with this patch, next time please
>>> check your patch a bit more thorough before submitting it:
>>>
>>> 1. This is the first time I see this, or that the
>>> platform-driver-x86@vger.kernel.org
>>> list sees this. Next time please make sure you address the patch to the right
>>> people the first time you send it:
>>>
>>> sure, thanks.
>>>
>>> 2. This has checkpatch warnings which are easily fixable:
>>>
>>> [hans@shalem platform-drivers-x86]$ scripts/checkpatch.pl 0001-platform-x86-
>>> intel-uncore-freq-add-Emerald-Rapids-su.patch
>>> WARNING: Possible unwrapped commit description (prefer a maximum 75 chars per
>>> line)
>>>
>>> OK.
>>>
>>> 3. This fails to build on top of:
>>> https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git/log/?h=for-next
>>>
>>> OK, thanks for the pointer. I'd need platfrom-drivers-x86 git tree to include
>>> this upstream commit:
>>>
>>> 7beade0dd41d x86/cpu: Add several Intel server CPU model numbers
>>>
>>> Would you please consider updating?
>>
>> Ugh, no, *NO*! I really expect Intel to do better here!
>>
>> As I repeated explained with the
>>
>> "platform/x86/intel: pmc/core: Add Raptor Lake support to pmc core driver"
>>
>> patch I cannot just go and cherry-pick random patches merged through other trees
>> because that may cause conflicts and will cause the merge to look really
>> funky.
> 
> I don't think this is about requesting a cherry-pick though.
> 
>> There are proper ways to do this and this is not it!
>>
>> This is something which Intel really *must* do correctly next time because
>> having this discussion over and over again is becoming very tiresome!
>>
>> So the proper way to do starts with realizing *beforehand* that things
>> will not build on top of pdx86/for-next. By like actually doing
>> a build-test based on top of pdx86/for-next instead of this nonsense of
>> repeatedly sending me broken patches.
> 
> This patch is based on the mainline.  The requisite commit has been
> included into the Linus' tree since at least 6.1-rc4 AFAICS and I
> suppose that it has been tested on top of that.

Ah, I did not know that; and that is typically info which I would
have expected to be explicitly mentioned in the non-existing cover-letter
for this patch.

> 
> You could in principle create a temporary branch based on 6.1-rc4 (or
> a later -rc), apply the patch on top of it, merge your current branch
> on top of that and merge it back into your current branch (that should
> result in a fast-forward merge, so the temporary branch can be deleted
> after it).

Yes I could merge rc4 into my for-next, but I'm not really a big fan
of back-merges like this. I try to keep my for-next history linear
based on the last rc1, because I find seeing what is going on
a lot easier that way. But if this happens more often I guess
I may need to get used to doing back-merges more often then
just after rc1 is out.

What I don't understand is why this patch was not send as a part of
the series starting which also had the
"7beade0dd41d x86/cpu: Add several Intel server CPU model numbers"
patch. That patch just adds a couple #define-s presumably there
were more patches in that series actually using those defines.

Things would have been cleaner / easier if this patch had simply
been a part of that series and if it was merged in one go with
that series...

Btw this new CPU ID is also missing from:
drivers/platform/x86/intel/pmc/core.c
drivers/platform/x86/intel/ifs/core.c

At least I assume it will need to be added there too, although
I guess it might not be as simple as only adding the CPU-id
match there ?

> Alternatively, if you'd rather not do that, I can merge the Artem's
> patch through the PM tree (it is PM-related after all).

If you can do that, that would be great, thank you.

> I suppose that your ACK would be applicable for that too?

Yes.

Regards,

Hans