Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp5921429ybi; Tue, 4 Jun 2019 14:52:56 -0700 (PDT) X-Google-Smtp-Source: APXvYqzfcpYUcYHBWOdij7OG8h4E9Qly8zvDCR8Rb1CDBZbHlPvKVRRNLV1uWGuiBxcurSz70EH0 X-Received: by 2002:a17:902:ac82:: with SMTP id h2mr39594454plr.303.1559685176404; Tue, 04 Jun 2019 14:52:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1559685176; cv=none; d=google.com; s=arc-20160816; b=Uae25Z3HyEVUyEFCTc/W12Xk6nIGcau99ykBCsFlm7KtspKedeEMaq4fbR1Zek59fe A6aTjp4ojKZRaUy0iBaTlI9YyODYSZ8EuFMlXYI4ALm8b/6d9PbcIZahruhurTQhd38D uA2U5MX5EnzflnntPpwH5N7UY5KeVUciJeYWedFC1m0cTQF9RtO8zyN0m37tJorwy0Ho haVrclDQY7QK/6wLZzoHt+BuM/ytuI+MmxVHhlSLsKrGVSK/dqaH3QStVAV2YJLo3spO JONp77AGmW4cKFkNkRE0SpgO2iKn7RQ5kxIb8PgvjYbRuZPl14KXx3dBA9Rpi7k5jPEO bxxg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:reply-to; bh=WECjE0LdkuL5gC8583A6ZPEvOQdpJOvfjC0LkiHKiBE=; b=OWVsEX4YHvf13CY6b+21E/NSZACZaaBPtGWuaNYMlXhKG5jNvzJA9DUPOZz7t8ApUJ yWUB/yesplouCO8cuXIpFnQv11CZHbJ1jragGSY90ewZ6TqFgJe3LCJdkB07XNx8xTFg 9ekc8+icphDFJOVbfdHufc3IWOjUPpPh1rrkgVtvq2jrCAuIPkYp/+cb/X6WtXawEnXo l8kmbj1KcGNkb39xwEicnqXOeEPWZP/iOAg44Y+8M3F6gGwUCLR1FOLMY6GPN6Sk+ZAB 9AlDln3IVQCbgHZbTClI5HhubQojduN9vbeN/fcaMYElVtYcaalXJZUH+rIQ4rE0sysS 8CAQ== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x2si25423713pfb.1.2019.06.04.14.52.39; Tue, 04 Jun 2019 14:52:56 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726568AbfFDVuF (ORCPT + 99 others); Tue, 4 Jun 2019 17:50:05 -0400 Received: from mga11.intel.com ([192.55.52.93]:41447 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726537AbfFDVuE (ORCPT ); Tue, 4 Jun 2019 17:50:04 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Jun 2019 14:50:04 -0700 X-ExtLoop1: 1 Received: from tthayer-hp-z620.an.intel.com (HELO [10.122.105.146]) ([10.122.105.146]) by orsmga004.jf.intel.com with ESMTP; 04 Jun 2019 14:50:03 -0700 Reply-To: thor.thayer@linux.intel.com Subject: Re: [PATCH] EDAC/altera: Warm Reset option for Stratix10 peripheral DBE To: Sudeep Holla , James Morse Cc: bp@alien8.de, mchehab@kernel.org, linux-edac@vger.kernel.org, linux-kernel@vger.kernel.org, Lorenzo Pieralisi , Mark Rutland References: <1559594269-10077-1-git-send-email-thor.thayer@linux.intel.com> <9de1152b-25e0-3fb1-bf96-c8e45363942c@arm.com> <20190604173848.GA28613@e107155-lin> From: Thor Thayer Message-ID: <45390f41-9b8c-de83-a092-befa3d1f7f0f@linux.intel.com> Date: Tue, 4 Jun 2019 16:52:08 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <20190604173848.GA28613@e107155-lin> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Sudeep, On 6/4/19 12:38 PM, Sudeep Holla wrote: > On Tue, Jun 04, 2019 at 06:23:15PM +0100, James Morse wrote: >> Hi Thor, >> >> (CC: +Mark, Lorenzo and Sudeep for PSCI. >> How should SYSTEM_RESET2 be used for a vendor-specific reset? >> > > Initially it was indented to be used by passing command line argument > "reboot=w" or "reboot=warm" as specified in kernel document[1] > > However it was enhanced and enabled specifically for panic by > Commit b287a25a7148 ("panic/reboot: allow specifying reboot_mode for panic only") > > IIUC you can now pass "reboot=panic_warm" to just set reboot_mode to > WARM when there's a panic. SYSTEM_RESET2 gets called whenever reboot_mode > is set to WARM/SOFT > Thanks. I missed that SYSTEM_RESET2 had been implemented. >> The original patch is: >> lore.kernel.org/r/1559594269-10077-1-git-send-email-thor.thayer@linux.intel.com >> ) >> >> On 03/06/2019 21:37, thor.thayer@linux.intel.com wrote: >>> From: Thor Thayer >>> >>> The Stratix10 peripheral FIFO memories can recover from double >>> bit errors with a warm reset instead of a cold reset. >>> Add the option of a warm reset for peripheral (USB, Ethernet) >>> memories. >>> >>> CPU memories such as SDRAM and OCRAM require a cold reset for >>> DBEs. >>> Filter on whether the error is a SDRAM/OCRAM or a peripheral >>> FIFO memory to determine which reset to use when the warm >>> reset option is configured. >> >> ... so you want to make different SMC calls on each CPU after panic()? >> >> >>> diff --git a/drivers/edac/altera_edac.c b/drivers/edac/altera_edac.c >>> index 8816f74a22b4..179601f14b48 100644 >>> --- a/drivers/edac/altera_edac.c >>> +++ b/drivers/edac/altera_edac.c >>> @@ -2036,6 +2036,19 @@ static const struct irq_domain_ops a10_eccmgr_ic_ops = { >>> /* panic routine issues reboot on non-zero panic_timeout */ >>> extern int panic_timeout; >>> >>> +#ifdef CONFIG_EDAC_ALTERA_ARM64_WARM_RESET >>> +/* EL3 SMC call to setup CPUs for warm reset */ >>> +void panic_smp_self_stop(void) >>> +{ >>> + struct arm_smccc_res result; >>> + >>> + __cpu_disable(); >>> + cpu_relax(); >>> + arm_smccc_smc(INTEL_SIP_SMC_ECC_DBE, S10_WARM_RESET_WFI_FLAG, >>> + S10_WARM_RESET_WFI_FLAG, 0, 0, 0, 0, 0, &result); > > Please use SYSTEM_RESET2 or let us know why it can't be used to understand > the requirement better. There are options to use vendor extentions with > the SYSTEM_RESET2 PSCI command if you really have to. However the mainline > supports only architectural warm reset. > I need to decide between warm reset and cold reset based on the peripheral type but maybe that decision can be done by firmware as James pointed out. Thanks for the links and the comments! Thor > -- > Regards, > Sudeep > > [1] Documentation/admin-guide/kernel-parameters.txt >