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 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 C60EAC4361B for ; Sat, 12 Dec 2020 01:33:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7EC522226A for ; Sat, 12 Dec 2020 01:33:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2406847AbgLLBc5 (ORCPT ); Fri, 11 Dec 2020 20:32:57 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34068 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728578AbgLLBcn (ORCPT ); Fri, 11 Dec 2020 20:32:43 -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 680FBC0613CF for ; Fri, 11 Dec 2020 17:32:03 -0800 (PST) Received: by mail-pg1-x544.google.com with SMTP id f17so8380133pge.6 for ; Fri, 11 Dec 2020 17:32:03 -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=89PR1XJOQ3AXJnqqfEc8vjhhdDtUcMjkmWKDCFEBDfA=; b=KziBoxlqrygnMqkQZIsOH1IqWRTRks0E0laPSHjpnzDIsngRIIM4b/UeleALrKa3YJ 4GKyhns8nOMvfT+0LrReca3YXhaHbbqyo2LOdX7LTMywJWPTkNzg2sgUkdhM0M7sved4 soStHWAioS20Du7cAwmgPNc8A/femXn/+xkGo= 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=89PR1XJOQ3AXJnqqfEc8vjhhdDtUcMjkmWKDCFEBDfA=; b=awUkm9vw5OsWVnmTNNRgQLe5NCTcFVZEwUdNsafJ+A1AGdC1FpxfgpvIqtJ9eah8fm j1MAiLAKCg2lLxNj/h1xwB6twkXM8IIBNyIOnXhjGFz1VLiOU7TlmqtMZZABsF/VWRA9 lNA5AAV5djV7Om365V8YsdITnRlerIpdjpQdDFcU9XyZcZ2Nla8rlPg6lwxZBXSU7edy Ct8pw1szVfU2Js9HDjgRziD662aDG+oTXIM7dQsjdwGLEgiT0f3123ISofKtxjenkDJf uDoLw2rW4JQcUZ/jJZ4nxPI5XIPCP/NKYLR+Xaec6AM4ZknUKrgGHQankXuuEh8FSFr+ pcMg== X-Gm-Message-State: AOAM532AzIJ6zAXDxf4K5Px32IDsid3W+oTabxIxG2tEYWGHKl8gefU6 E6q2hoIJTV6NWozH4dtmGk3zaQ== X-Google-Smtp-Source: ABdhPJwMnvGRsZafrjgyMGtbAW3djZ4NDokRc5FKyg0KgrMLwX3pTXAWpcwmCaUsX1DAFXwRttktEg== X-Received: by 2002:a63:4e58:: with SMTP id o24mr14318396pgl.322.1607736722938; Fri, 11 Dec 2020 17:32:02 -0800 (PST) Received: from chromium.org ([2620:15c:202:201:3e52:82ff:fe6c:83ab]) by smtp.gmail.com with ESMTPSA id ci2sm10838684pjb.40.2020.12.11.17.32.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Dec 2020 17:32:02 -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> <160764316821.1580929.18177257779550490986@swboyd.mtv.corp.google.com> <160764785500.1580929.4255309510717807485@swboyd.mtv.corp.google.com> <160764967649.1580929.3992720095789306793@swboyd.mtv.corp.google.com> <160765077856.1580929.643282739071441296@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: Fri, 11 Dec 2020 17:32:00 -0800 Message-ID: <160773672053.1580929.15441111796129112926@swboyd.mtv.corp.google.com> User-Agent: alot/0.9.1 Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org Quoting Doug Anderson (2020-12-10 17:51:53) > Hi, >=20 > On Thu, Dec 10, 2020 at 5:39 PM Stephen Boyd wrote: > > > > Quoting Doug Anderson (2020-12-10 17:30:17) > > > On Thu, Dec 10, 2020 at 5:21 PM Stephen Boyd wr= ote: > > > > > > > > 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 reinitialize= d? > > > > > > 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 > The interrupt handler sees a "DONE" interrupt. If we've made it far > enough into setting up the next transfer that "cur_xfer" has been set > then it might do more, no? I thought it saw a cancel/abort EN bit? if (m_irq & M_CMD_CANCEL_EN) complete(&mas->cancel_done); if (m_irq & M_CMD_ABORT_EN) complete(&mas->abort_done) and only a DONE bit if a transfer happened. >=20 >=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. > > > > > > > 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? >=20 > I guess I'm asserting that if a full second passed (because we timed > out) and after that full second no interrupts are pending then the > interrupt will never come. That seems a reasonable assumption to me. > It seems hard to believe it'd be stuck in a write buffer for a full > second? >=20 Ok, so if we don't expect an irq to come in why are we calling synchronize_irq()? I'm lost.