From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id DF384CDB482 for ; Wed, 18 Oct 2023 10:22:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230433AbjJRKWc (ORCPT ); Wed, 18 Oct 2023 06:22:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33268 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230407AbjJRKW2 (ORCPT ); Wed, 18 Oct 2023 06:22:28 -0400 Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AD3BCEA for ; Wed, 18 Oct 2023 03:22:26 -0700 (PDT) Received: by mail-ej1-x62d.google.com with SMTP id a640c23a62f3a-9be7e3fa1daso689483066b.3 for ; Wed, 18 Oct 2023 03:22:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1697624545; x=1698229345; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:from:to:cc:subject:date:message-id :reply-to; bh=7vRlhn6zJXKGhkaRHFdbQmiYpJ9J9KHu/JlP2a3//gU=; b=kTjNX1+/MtxzUAcig7R33bXUkXSieuj0RKvPFwFtZPbVXsP/+Qg7nacvqoPpan5wPw gxgyMPW80jWfvIT37TUVlbY642ti9IO9SF05HV6hwtnzViPX6RFI0aEMqJ0qqP0B8TOH MGBX6MLpEbCik1E+cw4AUiZ9ytOmqQC+VpP8u+6EBGsJYAp2nbNu+CGotLZVZLM47FJa OE72KLzHkcLyXg18P2Unbz4/1NWWtpI9RSB6zSkYzKImNTwwsbo4goQ38ySi4swW/iaD 1TGG3E7tHhqssUar37CfbbeAVjkjLHUCZ9U+7oQ18UaRyK+BkFeiIvcBPYchicLFFnuC KU3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697624545; x=1698229345; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=7vRlhn6zJXKGhkaRHFdbQmiYpJ9J9KHu/JlP2a3//gU=; b=EB3Y+KJl/hlogw8STJ73JVT4zaY+eARNEbmpBv7onc535mQ+9yaMt0TNlfXBWppJY1 QRtqIP3Ss5RiXWK+3bFGF/JG+N0yG/bW7NkJgn7F67T/UB2x3SebZPlV5ly+ohsUUI6A kisPFUvZ84dcZDflSuYYrkz29Njd2XTum81MbjzkRj9p5FpWl0vjE87pUfa+Bk3s45nS cFK00vZYiTlB0MIQyG1iuFAgJOBkw5LUBuBaJbtBBFtF+VGMAU106s7o0/drmZfF1yp4 CeOXovyJ03c4cx385hlUwxgr2tzJUOQKf4+sGGYoHm8QPOez11k9ZySDsnBiRUALmMM/ jS0A== X-Gm-Message-State: AOJu0YyPVGlsyRhFqllXFtfuvylNtqDDhoJ8ww6SMfv/kgDHE73kALtK Q9wXMRhqioi6QEWu+/GyyNk= X-Google-Smtp-Source: AGHT+IGzGWucR9AqXhPj7ajEWS2SbU8ETXcoq6xPSqSMzFvzMHyNnrZ3IV0hx/dKqSE+x1/PGqhf6g== X-Received: by 2002:a17:906:dc8b:b0:99b:ed44:1a79 with SMTP id cs11-20020a170906dc8b00b0099bed441a79mr3988509ejc.3.1697624544984; Wed, 18 Oct 2023 03:22:24 -0700 (PDT) Received: from gmail.com (1F2EF7B2.nat.pool.telekom.hu. [31.46.247.178]) by smtp.gmail.com with ESMTPSA id 2-20020a170906224200b009c6e58437dasm1387420ejr.37.2023.10.18.03.22.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 Oct 2023 03:22:24 -0700 (PDT) Sender: Ingo Molnar Date: Wed, 18 Oct 2023 12:22:22 +0200 From: Ingo Molnar To: Thomas Gleixner Cc: Hou Wenlong , linux-kernel@vger.kernel.org, Ingo Molnar , Borislav Petkov , Dave Hansen , "maintainer:X86 ARCHITECTURE 32-BIT AND 64-BIT" , "H. Peter Anvin" , Andy Lutomirski , Peter Zijlstra , Tom Lendacky , Andrew Morton , Steve Rutherford , Michael Kelley , Alexander Shishkin , Arnd Bergmann Subject: Re: [PATCH 2/2] x86/sme: Mark the code as __head in mem_encrypt_identity.c Message-ID: References: <874jip58pp.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <874jip58pp.ffs@tglx> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Thomas Gleixner wrote: > On Tue, Oct 17 2023 at 14:52, Ingo Molnar wrote: > > * Hou Wenlong wrote: > >> -static inline void __init sme_encrypt_kernel(struct boot_params *bp) { } > >> -static inline void __init sme_enable(struct boot_params *bp) { } > >> +static inline void sme_encrypt_kernel(struct boot_params *bp) { } > >> +static inline void sme_enable(struct boot_params *bp) { } > > > > So I think we should preserve the previous convention of marking functions > > __init in the header-declaration and at the definition site as well, and do > > the same with __head as well? > > I'm not convinced about the value of prototype annotations, but have no > strong preference either. So it has some minor documentation purpose: when someone looks up a function via the header only (I do that frequently), __init-alike annotations really show the intended boot-only limitations of the API. But that's a really minor Nth order benefit, I have no strong preference either. Thanks, Ingo