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 X-Spam-Level: X-Spam-Status: No, score=-5.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CB2F8C5517A for ; Mon, 26 Oct 2020 09:19:50 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 573B5223EA for ; Mon, 26 Oct 2020 09:19:50 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="khrIaQJV"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="dQSHAAW3" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 573B5223EA Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=xy7gdG+dhLjEGYpQWi22klc8v/R4PgTd1ebppBdrmZE=; b=khrIaQJVihfXJ7sUduUfOeIpz BJ0Tnllf1zveGH86UQ0g5qUj3xvdjZkSrxlxibGg9oCjxKqXx8J884wlgEz40oQJKTb6teMgZY3gq oknINyFkA+LfsCMRBBMrIrlQsKH0dR2/c8FO/0SNjEBWtTSYy6khLoOcqWVi+mmmNO2mdv11LDVxj /9h6LFNG2q3JqH26Aqw04QHPSWFWgq+HkklXAZcWhvsd+m8sYcbksZu6vBEgJFJir8wdUoRdtwAXE qXC65JRaARD4+SYePITfvutHU0eyVuSrdUkNWKkHfHD+uqtTI1TpyaXRyV9tIMBtyCZJhBRTzRae3 FXMCSrauw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kWye2-0008Qc-4D; Mon, 26 Oct 2020 09:18:26 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kWydz-0008Q4-Ia for linux-arm-kernel@lists.infradead.org; Mon, 26 Oct 2020 09:18:24 +0000 Received: from dragon (80.251.214.228.16clouds.com [80.251.214.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 09E2C20759; Mon, 26 Oct 2020 09:18:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1603703902; bh=kOYMr7t36G3aNjWRi6PWNkG8fO8cfJiNBmuYeUpJVVg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=dQSHAAW39jjsHr4VkQ+E4aBykW6N+/dGmK2LxOStHm/J/cg1XVUYdkyK0NXhdTKqd xiuGjBjbBd/76WF+tJguQHNDhyhclm3hHF+4LWi9YSuL+GTXTZHESswf7RofuLwDC2 C33IVK0d22JbI0IMSjFjHXM50yWf/dpjQk5l0KJ4= Date: Mon, 26 Oct 2020 17:18:17 +0800 From: Shawn Guo To: Jan Kiszka Subject: Re: [PATCH] [RFC] ARM: imx: add smp support for imx7d Message-ID: <20201026091816.GI9880@dragon> References: <20200917160814.97995-1-marex@denx.de> <20200922062248.GC25109@dragon> <43c03425-1bcc-b5c1-c82a-4307ee1f0768@denx.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201026_051823_697090_B7E16F13 X-CRM114-Status: GOOD ( 28.34 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Marek Vasut , Arulpandiyan Vadivel , Anson Huang , Leonard Crestez , Fabio Estevam , linux-arm-kernel@lists.infradead.org, NXP Linux Team Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Sep 22, 2020 at 04:59:44PM +0200, Jan Kiszka wrote: > On 22.09.20 13:34, Marek Vasut wrote: > > On 9/22/20 8:27 AM, Shawn Guo wrote: > > > On Tue, Sep 22, 2020 at 2:22 PM Shawn Guo wrote: > > > > > > > > On Thu, Sep 17, 2020 at 06:08:14PM +0200, Marek Vasut wrote: > > > > > From: Anson Huang > > > > > > > > > > Add SMP support for i.MX7D, including CPU hotplug support, for > > > > > systems where TFA is not present. > > > > > > > > These systems are not supported by upstream kernel. Sorry. > > > > > > I meant for systems without PSCI support actually. > > > > Is there any specific reason for that ? > > > > The SoC works fully well with mainline U-Boot and without TFA, except > > the code for bringing up the second core is missing from mainline and > > that is all that is missing. PSCI is unnecessary extra complexity here. > > > > We are coming from vendor kernels and would like to base our products on > mainline for $countless-good-reasons. With the vendor kernels, this > "classic" way of booting worked fine, with historic bootloaders and also > with current mainline U-Boot. > > If PSCI support is mandated, we would now be unable to migrate devices in > the field that should not or cannot receive a bootloader update because > existing deployments generally do not ship TF-A or any other PSCI > implementation on ARMv7 - there was mostly no use for it (and there will > likely be none, except for CPU onlining). Would be a shame. Thanks for sharing such user story that we would love to hear. We like such transition from vendor kernel to upstream for sure. I would hope my upstream maintainers would also agree this is a worthy compromise. I will try to help get this in. > So I'd also like to understand what speaks against a merge, provided this > patch does not break other cases or make the code significantly more complex > and harder to maintain. The patch itself is indeed not a maintenance burden. What scares me is the suspend and idle code in vendor kernel, which we hope that PSCI can take care of for upstream kernel. For record, I reserve the right to say NO to those code even if we get this patch in :) Shawn _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel