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. 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. Once you realize this there are a couple of options, these all start with identifying which tree has the patch on which the other patch depends iow through which tree / subsystem was "7beade0dd41d x86/cpu: Add several Intel server CPU model numbers" merged? Based on the name I'm going to assume this is done through the x86 tree. Once you have: 1. Realized the patch actually won't build on top of pdx86/for-next 2. Identified which tree has the commit your patch depends on Then there are several options how to proceed: 1. Since this is a one-liner and it touches a driver which has seen no other recent changes, you can submit the patch to the x86/tip tree maintainers instead of to the pdx86 subsystem. The x86/tip tree maintainers will likely want my ack for merging this through their tree. For the next version which you should submit to the x86/tip tree folks, not to the pdx86 list! Feel free to add my: Acked-by: Hans de Goede <hdegoede@xxxxxxxxxx> and you will want to add a cover-letter explaining why this is being submitted to the x86/tip tree and my ack is there to indicate that I believe it is ok for the patch to go through another tree. What you would normally do is realize beforehand you want to go this route and directly submit to the x86/tip maintainers with me in the Cc asking for my ack for merging through another tree. Or what you could have done is: 2. Ask the x86 maintainers to create an immutable branch based on the last rc1 + just the patch adding the defines (which means realizing before hand you will need this patch in other subsystems and ask them to do this when *submitting* the patch. Then I could have merged the immutable-branch and then cleanly apply your patch on top. ### What you can *NOT* do is just submit the patch to me and expect me to somehow magically fix the cross subsystem dependency problems for you. As the patch submitter any cross subsystem dependency problems arr *your problem* not mine. Regards, Hans
