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.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 5A4EDC4361B for ; Fri, 11 Dec 2020 01:41:31 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0A3D523D97 for ; Fri, 11 Dec 2020 01:41:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390436AbgLKBkn (ORCPT ); Thu, 10 Dec 2020 20:40:43 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39468 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2390336AbgLKBkV (ORCPT ); Thu, 10 Dec 2020 20:40:21 -0500 Received: from mail-pg1-x544.google.com (mail-pg1-x544.google.com [IPv6:2607:f8b0:4864:20::544]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 18E16C0613D6 for ; Thu, 10 Dec 2020 17:39:41 -0800 (PST) Received: by mail-pg1-x544.google.com with SMTP id c12so5574480pgm.4 for ; Thu, 10 Dec 2020 17:39:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:content-transfer-encoding:in-reply-to:references :subject:from:cc:to:date:message-id:user-agent; bh=H3bNyqjYE3P3FE+pJdfbGUHM/wRVgfwC3WmKBMLEr7M=; b=dEgyJPXv0kmdJSrcSv+bLlHu62vF3ra95gSKtR8K44I6/dpazQExwhUkTuKh1Hmru3 dfprGYiB08/idrTanAYAC5/AZjQgID2vscE07va0W1FWTcSRxybjyvdZhWob7e2BVT3p IhtpwI3muN6WlQz1pNmKtGJQdIYD1Z/zYB36Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:content-transfer-encoding :in-reply-to:references:subject:from:cc:to:date:message-id :user-agent; bh=H3bNyqjYE3P3FE+pJdfbGUHM/wRVgfwC3WmKBMLEr7M=; b=Mb+00qoMmN2sV/ck8ad6xtcKd3Usr+IphxwbIjejq1iPO0sGt3CtPNq8ubb716eHG1 KZogScFewbCPJZDfzwEjis+/xo3HUSA/UknH5tAs3r41ZI0muY6kLg3HF3JeOtO7TQhy 1P+2hJ1qxeZ9gzZmj8N4IK4xcAppWXaKsm4+CD+zNOg8ix2/ALr4QQvCSEA/G+V/iAyO efn5+mNxASYrhtNZiIjc2dXIfuz5UMDlnh/yhrPRcs1EIvn+QrI7kAbnvBUtrLOAZAPR L7LOVp1/CpkH3YYe4Ea0b9YE6wLb5xx0DAIAi82jSzSYAytXk65HdHWj/crYPTCQHGgt Peng== X-Gm-Message-State: AOAM533OFNH9GdiTH0Wq/paJ8ekErvxtqtvG60Tdjiv9nny2XhErIEcS uUD+X10Ym79yAjVK6x2mwd1hew== X-Google-Smtp-Source: ABdhPJwS2eEsNkdSg9gzpVa3oDaAxMF5jsW+xoVUW5TxVlsMAiakjkBodXM2xbhz+QHjt9vWSMi7Hw== X-Received: by 2002:a17:90a:fa0c:: with SMTP id cm12mr10705104pjb.87.1607650780522; Thu, 10 Dec 2020 17:39:40 -0800 (PST) Received: from chromium.org ([2620:15c:202:201:3e52:82ff:fe6c:83ab]) by smtp.gmail.com with ESMTPSA id s189sm7542837pfb.60.2020.12.10.17.39.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 10 Dec 2020 17:39:40 -0800 (PST) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable In-Reply-To: References: <20201203074459.13078-1-rojay@codeaurora.org> <160764107797.1580929.14768824290834396298@swboyd.mtv.corp.google.com> <160764316821.1580929.18177257779550490986@swboyd.mtv.corp.google.com> <160764785500.1580929.4255309510717807485@swboyd.mtv.corp.google.com> <160764967649.1580929.3992720095789306793@swboyd.mtv.corp.google.com> Subject: Re: [PATCH] spi: spi-geni-qcom: Fix NULL pointer access in geni_spi_isr From: Stephen Boyd Cc: Roja Rani Yarubandi , Mark Brown , Andy Gross , Bjorn Andersson , linux-arm-msm , linux-spi , LKML , Akash Asthana , msavaliy@qti.qualcomm.com To: Doug Anderson Date: Thu, 10 Dec 2020 17:39:38 -0800 Message-ID: <160765077856.1580929.643282739071441296@swboyd.mtv.corp.google.com> User-Agent: alot/0.9.1 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Quoting Doug Anderson (2020-12-10 17:30:17) > On Thu, Dec 10, 2020 at 5:21 PM Stephen Boyd wrote: > > > > Yeah and so if it comes way later because it timed out then what's the > > point of calling synchronize_irq() again? To make the completion > > variable set when it won't be tested again until it is reinitialized? >=20 > Presumably the idea is to try to recover to a somewhat usable state > again? We're not rebooting the machine so, even though this transfer > failed, we will undoubtedly do another transfer later. If that > "abort" interrupt comes way later while we're setting up the next > transfer we'll really confuse ourselves. The interrupt handler just sets a completion variable. What does that confuse? >=20 > I guess you could go the route of adding a synchronize_irq() at the > start of the next transfer, but I'd rather add the overhead in the > exceptional case (the timeout) than the normal case. In the normal > case we don't need to worry about random IRQs from the past transfer > suddenly showing up. >=20 How does adding synchronize_irq() at the end guarantee that the abort is cleared out of the hardware though? It seems to assume that the abort is pending at the GIC when it could still be running through the hardware and not executed yet. It seems like a synchronize_irq() for that is wishful thinking that the irq is merely pending even though it timed out and possibly never ran. Maybe it's stuck in a write buffer in the CPU?