On Wed, Nov 23, 2022 at 4:55 PM Hans de Goede <hdegoede@xxxxxxxxxx> wrote: > > 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@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. > > 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. No problem. > > I suppose that your ACK would be applicable for that too? > > Yes. Thanks!
