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

[srinivas pandruvada <srinivas.pandruvada@linux.intel.com>]

Hi Hans,

> > > 

[...]

> > > Ugh, no, *NO*! I really expect Intel to do better here!
> > > 
Sorry, I didn't realize the CPUID is not added to rc1. Our internal
tree constantly gets rebased. So difficult to catch.

As you rule, I will communicate internally that apply on top of 
https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git/log/?h=for-next
 
If doesn't build atleast add that to the patch notes.

BTW, I send my PULL from this tree and branch always.

Thanks,
Srinivas

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