[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=witL2fFR-FK_nt5TTLHKffueUQnv875-aDGUqn8O3+o_w@mail.gmail.com>
Date: Mon, 11 Mar 2024 17:50:48 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Borislav Petkov <bp@...en8.de>
Cc: x86-ml <x86@...nel.org>, lkml <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] x86/sev for v6.9-rc1
On Mon, 11 Mar 2024 at 08:19, Borislav Petkov <bp@...en8.de> wrote:
>
> If you're merging tip pull requests in the chronological order you've
> received them, you'll encounter a couple of simple merge conflicts.
It's not exactly chronological - I tend to go by areas and by
submitter, but it tends to approximate chronological most of the
time..
> I'm adding how I've resolved them at the end of this message in case
> you wanna compare notes.
Hmm. I took a slightly different approach:
> diff --cc arch/x86/include/asm/coco.h
> index 76c310b19b11,21940ef8d290..42871bb262d0
> --- a/arch/x86/include/asm/coco.h
> +++ b/arch/x86/include/asm/coco.h
> @@@ -10,9 -11,15 +11,15 @@@ enum cc_vendor
> CC_VENDOR_INTEL,
> };
>
> -extern enum cc_vendor cc_vendor;
> + extern u64 cc_mask;
> +
> #ifdef CONFIG_ARCH_HAS_CC_PLATFORM
> +extern enum cc_vendor cc_vendor;
I put the 'cc_mask' declaration inside the #ifdef too.
Because those two variables are defined together, and without
CONFIG_ARCH_HAS_CC_PLATFORM the whole coco/ subdirectory that defines
them won't even be built, as far as I can tell.
And I don't see any _use_ of 'cc_mask' anywhere outside of that one
'cc_set_mask()' inline function and the coco/core.c file. So declaring
it only when it's all enabled seems to be the right thing.
Let's hope my artistic merge resolution doesn't end up coming back to bite me.
Linus
Powered by blists - more mailing lists