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=-6.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,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 4AEDCC4727E for ; Wed, 30 Sep 2020 15:43:58 +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 C7BE020738 for ; Wed, 30 Sep 2020 15:43:57 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="mHb+L2fW"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=ti.com header.i=@ti.com header.b="kibQWMDX" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C7BE020738 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=ti.com 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:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=mu7BWXz1YYROkWIC3g+LlkvkGjH/x7a42YeGTl+fvco=; b=mHb+L2fWV8vfknwk6jn47jXMo /oZoZKIrIsB5MsSaab1fpRtZalj0FgNsc+E//8hYLGtPeF9g/VhnqzlSGlrBiGU8og62JY3nmTYA5 J6gK4dIG2DNWeKPYec6RFd+whwPLag/I5KW57MzKybMdwsa7/xs5XyTAZMsKHiCYQCIT5t39QBnIs lankxAA6ALtzupadVKwsZlh12JX+MpSOFo1N9drxjrzkI6QQflRywshMHnZDaTLQaRob1Wz9/lCCA ORoPbTTud126ITeIlilGmtfNDXhckS80a1/9NRzTm+3M1NgdM4vSXAu8fcToiGRzwFMF6NQtUp3gn 42ARE6QHg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kNeFK-000843-Nr; Wed, 30 Sep 2020 15:42:22 +0000 Received: from fllv0015.ext.ti.com ([198.47.19.141]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kNeFG-000828-0M for linux-arm-kernel@lists.infradead.org; Wed, 30 Sep 2020 15:42:19 +0000 Received: from lelv0265.itg.ti.com ([10.180.67.224]) by fllv0015.ext.ti.com (8.15.2/8.15.2) with ESMTP id 08UFgDt1045672; Wed, 30 Sep 2020 10:42:13 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1601480533; bh=+ll5S2eNGiNif7/o2agDFeqc3tuSX/ZkzSW13n3l9XE=; h=Subject:To:CC:References:From:Date:In-Reply-To; b=kibQWMDXWG1it3TrotAwdRyX/nj4KkiOvyp1P1j8+tldqJ+pe/RJ4wd07qiF0Vo1q hVghGbUQV5faf8gPu/ccq2ZVIPWuyduI6H9S1YNaPYi95o5O9GM8Ah2CRH4QYXEksQ mhqsweWyPgbWMrSC1VAOSVX3tZj/PY/bTHyvQTIE= Received: from DLEE103.ent.ti.com (dlee103.ent.ti.com [157.170.170.33]) by lelv0265.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 08UFgDE4052741 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 30 Sep 2020 10:42:13 -0500 Received: from DLEE100.ent.ti.com (157.170.170.30) by DLEE103.ent.ti.com (157.170.170.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1979.3; Wed, 30 Sep 2020 10:42:12 -0500 Received: from lelv0326.itg.ti.com (10.180.67.84) by DLEE100.ent.ti.com (157.170.170.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1979.3 via Frontend Transport; Wed, 30 Sep 2020 10:42:12 -0500 Received: from [10.250.232.108] (ileax41-snat.itg.ti.com [10.172.224.153]) by lelv0326.itg.ti.com (8.15.2/8.15.2) with ESMTP id 08UFg88L047226; Wed, 30 Sep 2020 10:42:09 -0500 Subject: Re: [PATCH] PCI: layerscape: Change back to the default error response behavior To: Rob Herring References: <20200929131328.13779-1-Zhiqiang.Hou@nxp.com> <6e6d021b-bc46-63b4-7e84-6ca2c8e631f9@ti.com> From: Kishon Vijay Abraham I Message-ID: <81530aba-0e4d-9685-2fc1-dfdf948a7178@ti.com> Date: Wed, 30 Sep 2020 21:12:07 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200930_114218_168516_9469BA46 X-CRM114-Status: GOOD ( 17.56 ) 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: Roy Zang , Lorenzo Pieralisi , PCI , Zhiqiang Hou , "linux-kernel@vger.kernel.org" , Yang-Leo Li , Minghuan Lian , Mingkai Hu , Bjorn Helgaas , linux-arm-kernel 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 Hi, On 30/09/20 8:37 pm, Rob Herring wrote: > On Wed, Sep 30, 2020 at 8:29 AM Kishon Vijay Abraham I wrote: >> >> Hi Hou, >> >> On 29/09/20 6:43 pm, Zhiqiang Hou wrote: >>> From: Hou Zhiqiang >>> >>> In the current error response behavior, it will send a SLVERR response >>> to device's internal AXI slave system interface when the PCIe controller >>> experiences an erroneous completion (UR, CA and CT) from an external >>> completer for its outbound non-posted request, which will result in >>> SError and crash the kernel directly. >>> This patch change back it to the default behavior to increase the >>> robustness of the kernel. In the default behavior, it always sends an >>> OKAY response to the internal AXI slave interface when the controller >>> gets these erroneous completions. And the AER driver will report and >>> try to recover these errors. >> >> I don't think not forwarding any error interrupts is a good idea. > > Interrupts would be fine. Abort/SError is not. I think it is pretty > clear what the correct behavior is for config accesses. IIUC $patch prevents SError in all cases. Doesn't UR, CA and CT all sends SLVERR which will result in Abort and that is being prevented here?. Maybe I'm wrong here, Hou can confirm. Thanks Kishon _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel