On Wed, Nov 23, 2022 at 3:59 PM Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote: > > On Wed, Nov 23, 2022 at 3:37 PM Hans de Goede <hdegoede@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx > > > 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. > > 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). > > I do such things on a regular basis and no complaints so far. 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). I suppose that your ACK would be applicable for that too?
