Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp829248imu; Wed, 16 Jan 2019 08:14:45 -0800 (PST) X-Google-Smtp-Source: ALg8bN6oNvZgYooPbmBVf12Z89FK6TqK8a6Z0aDl6jPacyuH3UiIioLCoENovMhN41yB/gb7Rjmh X-Received: by 2002:a62:64d7:: with SMTP id y206mr10584824pfb.84.1547655285609; Wed, 16 Jan 2019 08:14:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547655285; cv=none; d=google.com; s=arc-20160816; b=lFGvUA7S71JhY9xjlypKcWQYq4C1EdReUgbSM0wxOSvVQuRZTet5S3dkBaBedZQTDw 4YoU3NOen/TJXmLGs5iMJ6P2RiNspJpLMDTTT50yQk27CRT037mTl6/P8eOcLV5NVnaX EUJMFCBuN/gNA1l/u6TLN6xtRgF21PEt8mKOaMrrvD5Q2VJYx0LYKV1sfJ9M6PVO5KlG p+Z7h7IVuQJI5mdTwkjT6xHPlINyjBBfMTyE8LBQtfvVvvmVoSM5nd4EtPjta4jdfWD8 MuEzuujvRmHJubby4wNjbiyRHTkBG5LUxcT5mKVN4BOiLCd6fBUiP0f3D9TpdXoZqKjd VmgA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=5BlBnLja76Yd8rV6sbMxyl08TUqH/aWtlQ1PRU4pYhM=; b=Bn5Za3em4vG6zYtO46jqfYIz1C+InP8DrWDTobLQpIlIAK0ej+ACssgntE9CTTGS7a lCdHc7BQZfF6J5+1dKXa2D2TmXeJ1tMEDp/PuuSIAymTaF1QckkSubsJMXCprwpSuwlt SISN1IRkOZjahY2RKvBXemWom0sDM54iq+sUEUXzKgko7/Gi+bOvXlI0aYNgsg3rct/s LepJ1aaEWlRHRa5hQoiApzegr2vZIyv/KTQ3TA4UjgEGzI+mCZVEMW1E90tiSQqKuBAU zZClSuG742r7AwuzT2GvQiPVkatZkK6HyZSPy7njkkN5Xx5DcpXzvIRiKCLaUOcflhRY WVUQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=bnPGUvLD; 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=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u72si6280342pgc.360.2019.01.16.08.14.13; Wed, 16 Jan 2019 08:14:45 -0800 (PST) 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; dkim=pass header.i=@linaro.org header.s=google header.b=bnPGUvLD; 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=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728423AbfAPCV6 (ORCPT + 99 others); Tue, 15 Jan 2019 21:21:58 -0500 Received: from mail-lj1-f193.google.com ([209.85.208.193]:32839 "EHLO mail-lj1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728305AbfAPCV4 (ORCPT ); Tue, 15 Jan 2019 21:21:56 -0500 Received: by mail-lj1-f193.google.com with SMTP id v1-v6so4144345ljd.0 for ; Tue, 15 Jan 2019 18:21:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5BlBnLja76Yd8rV6sbMxyl08TUqH/aWtlQ1PRU4pYhM=; b=bnPGUvLDgLMPFM+fRUeMP2pKiBOsrB1lzLFEkLed6MVfC0TS7hopsreBjYNzWam6Ui cMq9Rmsj+p3CEQRcBgTNs+iEAhUYz3xbAORdGq/rE9GcZ84eBgF8h0wu6S6ZVUBNYD9b +tQyoUfjeX1SnxT+t32kGpK0LRBvpqzbNqono= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5BlBnLja76Yd8rV6sbMxyl08TUqH/aWtlQ1PRU4pYhM=; b=E51EleJTunuoxFsBjg/5uS59LtscQo6n/KQ0phG0ggT7Z4QPA0kLpRKpFLjdEXowq3 Zk6hymER5Vo4MvDAKNbaSA81LXla3VDtDt28Ubk71M3B6mpB8XDWOeCW3hd0CNPzZ927 z0aVmUa01I+Zk3Hf8lF61MjpBYiUksmtZ3xhrM1iQpWXeq1K02csL7bZWAmGhTBBtaWL a4RBpJH9skWtBu3mvYwVoeD/EfEgvpqJZ8DcBvFnpVuM0kF8HDaA6HEOV1Wjg5WbCY+P 3drT4iKJGmTA3IFjEUgKtoqgDVk7O06Yw3JDigtlVHOuNJl36mnU1iKV/5CbZ6vwGpYs wV7g== X-Gm-Message-State: AJcUukdIH8cgrPjMNJ7+Tfm8oH9ZlyqEn4z4yrRB0fF0HJHokhbCdE56 y794t/aploYfik4F8PaYSFOW6be6g1R/TG1XWzAntw== X-Received: by 2002:a2e:55d3:: with SMTP id g80-v6mr5200782lje.78.1547605314038; Tue, 15 Jan 2019 18:21:54 -0800 (PST) MIME-Version: 1.0 References: <20190115142452.GA5522@sirena.org.uk> In-Reply-To: <20190115142452.GA5522@sirena.org.uk> From: Baolin Wang Date: Wed, 16 Jan 2019 10:21:42 +0800 Message-ID: Subject: Re: [PATCH 2/4] spi: sprd: Add the SPI irq function for the SPI DMA mode To: Mark Brown Cc: Rob Herring , Mark Rutland , Orson Zhai , Chunyan Zhang , lanqing.liu@unisoc.com, linux-spi@vger.kernel.org, DTML , LKML Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Mark, On Tue, 15 Jan 2019 at 22:25, Mark Brown wrote: > > On Tue, Jan 15, 2019 at 09:46:51PM +0800, Baolin Wang wrote: > > This looks good, just one small issue and a thing to check: > > > +static irqreturn_t sprd_spi_handle_irq(int irq, void *data) > > +{ > > + struct sprd_spi *ss = (struct sprd_spi *)data; > > + u32 val = readl_relaxed(ss->base + SPRD_SPI_INT_MASK_STS); > > + > > + if (val & SPRD_SPI_MASK_TX_END) { > > + writel_relaxed(SPRD_SPI_TX_END_CLR, ss->base + SPRD_SPI_INT_CLR); > > + if (!(ss->trans_mode & SPRD_SPI_RX_MODE)) > > + complete(&ss->xfer_completion); > > + return IRQ_HANDLED; > > + } > > + > > + if (val & SPRD_SPI_MASK_RX_END) { > > + writel_relaxed(SPRD_SPI_RX_END_CLR, ss->base + SPRD_SPI_INT_CLR); > > + complete(&ss->xfer_completion); > > + } > > + > > + return IRQ_HANDLED; > > +} > > This will return IRQ_HANDLED no matter if there was an interrupt > actually handled. That means that if something goes wrong due to some > bug or a hardware change (eg, a new version of the IP) and there's > another interrupt fired we won't clear it and the interrupt core won't > be able to detect that it's a spurious interrupt and use its own error > handling. It's better to return IRQ_NONE in that case. Yes, you are correct and will fix in next version. > > + ret = devm_request_irq(&pdev->dev, ss->irq, sprd_spi_handle_irq, > > + 0, pdev->name, ss); > > + if (ret) > > + dev_err(&pdev->dev, "failed to request spi irq %d, ret = %d\n", > > + ss->irq, ret); > > Are you sure it's safe to use devm_request_irq(), especially when > unloading the driver? Using it means that we will only disable the > interrupt after the driver's remove function has finished so there's a > danger of an interrupt firing when some of the resources the hander has > used are still in use. I didn't spot any issues, just something to > check especially with the later patches building on top of this. Yes, we missed this issue, thanks for pointing out this. After some discussion with Lanqing, we think we need call the spi_controller_suspend() manually in remove function to avoid this issue. Thanks for your comments. -- Baolin Wang Best Regards