Received: by 2002:a25:f815:0:0:0:0:0 with SMTP id u21csp2492029ybd; Mon, 24 Jun 2019 07:21:33 -0700 (PDT) X-Google-Smtp-Source: APXvYqzEwo1n+r5qMDRdj8AddO0QA7IMd6T91JMy90Yix7rY3xal2beUZahPtlBb+i35WaUW+R41 X-Received: by 2002:a63:a1f:: with SMTP id 31mr13799248pgk.66.1561386093108; Mon, 24 Jun 2019 07:21:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1561386093; cv=none; d=google.com; s=arc-20160816; b=xYgCML7coOH771VSNtYTk67R/p+8OLq81NeKNVTBq2lPrWDWGVecAwxhC5QsDrbqqL IEGeUOZN4yzFaWrJwzgLrn83JPD/qyDv33j1O65e1mFL+hkD1/eZaPG6eN5fnLq3IPwM I4DsgwGH8G60KRpfmGG8xXzKHsZstxCgOZsGm7PoWEAgAFCcyG22uLdvlAs3C+xLmsyY R9GoPjnai6N18LiUQZ3L4orYuNGawagPRJc+ap8sStU2yBPLJmPUZlVtQFjczIdubhGs oHE9Vh9VVRqpHTG8csW9s49UifH7b72Xv6OgiGK16jbONYjKcL+ckru7NR0wC6LhDUNd XxcQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=hFRYYyaK1NqBWsodRN6NGgnXsGlyGn6XpGWgREydwvE=; b=iSOEhq+8nxIIPy70yhND2nO6qRb34obWzcji9Fd+LZRuSiZKWaP/bX8PWbFkQOlHHf 5rU5jhXZuSpxYFihfB4wfMU4gQUG7ePdsnj4pzPmO4WQ7+h7a5pLK04JEXqRSFWfOYt2 cqk7wxoFfoWKvLkphRMGa1T13PI2sPWuM8WhB18vMYbodmOFVX4zTe7YjVtfUU26G8s8 9mvsreTRj5/TgjrF+azABDNxPKyBuYtQZzgScS2dH/LpPWk5o2AeAV/p5PI25HA/LrUV +uuZV8zhJXvOLGpCc+yYbioownXQFrnYtjbjP+rPRYV1Kp/cFieUAoo8Q4af3RECvQRl vAOQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j1si10255377pgi.271.2019.06.24.07.21.17; Mon, 24 Jun 2019 07:21:33 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729524AbfFXN6R (ORCPT + 99 others); Mon, 24 Jun 2019 09:58:17 -0400 Received: from Galois.linutronix.de ([193.142.43.55]:37004 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727945AbfFXN6R (ORCPT ); Mon, 24 Jun 2019 09:58:17 -0400 Received: from p5b06daab.dip0.t-ipconnect.de ([91.6.218.171] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1hfPU6-0003pF-L7; Mon, 24 Jun 2019 15:58:14 +0200 Date: Mon, 24 Jun 2019 15:58:13 +0200 (CEST) From: Thomas Gleixner To: Zhenzhong Duan cc: linux-kernel@vger.kernel.org, mingo@kernel.org, bp@alien8.de, hpa@zytor.com, boris.ostrovsky@oracle.com, jgross@suse.com, sstabellini@kernel.org Subject: Re: [PATCH 1/6] x86/xen: Mark xen_hvm_need_lapic() and xen_hvm_need_lapic() as __init In-Reply-To: <1561294903-6166-1-git-send-email-zhenzhong.duan@oracle.com> Message-ID: References: <1561294903-6166-1-git-send-email-zhenzhong.duan@oracle.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 23 Jun 2019, Zhenzhong Duan wrote: > .. as they are only called at early bootup stage. In fact, other > functions in x86_hyper_xen_hvm.init.* are all marked as __init. > > Unexport xen_hvm_need_lapic as it's never used outside. Can you please provide a cover letter for your patch series and explain what this whole exercise is about. I'm seing some __init anotations in various files and then functional xen changes which seem to be completely unrelated and independent. Please split such stuff, e.g. the unrelated __init annotations so they can be picked up and merged and the real functional stuff is then self contained. If the __init annotation touches the same code as the functional changes, then keep them together, but please do not burden reviewers and maintainers with guess work to decode what is what. Thanks, tglx