Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp1737089ybv; Fri, 14 Feb 2020 05:12:15 -0800 (PST) X-Google-Smtp-Source: APXvYqx8qDQNLK3QMYo82OA6vi+d/BGpfYyfhnlbfi1bYxJiBIzicFkVCyim2wy8tjM4jluWL9q3 X-Received: by 2002:a05:6830:13d3:: with SMTP id e19mr2207157otq.135.1581685935267; Fri, 14 Feb 2020 05:12:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1581685935; cv=none; d=google.com; s=arc-20160816; b=Ar1WkBw4wOXN61YDuoCg5BQrVnlp8fF68XquK7sjcfo/Y5obdr2n2fLxSqdtoYYD1b dzo/tOEHjw60kqVYbWXiYstgmEkuMmMUf6u5GTHkQqLy/26ujkh+O4nvkWIMGY1dVROa qybObg1KP8XT79CYi0FbggeFexR7QZ+9g9cnkWC7f5g87G0Pqa1DVLNrdfX7MfJ6PPt+ cCiAMlacWdpnYpQrO9nO3mWOBWcbs5GQhA8JpGkjy4jnzhHhbdJez/5t9CZSFCm5Xbzs /Houz0OvwB6UZOJmmoD935fM3yF3TIlNOv0BPqVXVlDGKao9WysBVArcdD/R59X2qyAp dtqg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=O+V9eSvLDiE9YakFYwfDsy6aHvpkb8Nx2xlUAG8cjog=; b=A9VL1xUfcEhQCzj2BrLTAWIweCBnStiq5wn1p6HQXWWQmy2nRfmq/tkhxSXRsxdUWM 3qkoG2sIbfwd2whWiiyDHZpiMrP6pk3JdZrXzav+CoolUt6hwETaYTW4E47mlFTXWFRW Rbj5fN7X30DJtjPK4d0L31pXsQC8rC0PcrMmf84PUCJJq5rFzxQkZKqCuI0SQHeUB1ox yXfCxt6Lrgjmsg+9cwdg42yXM8NY62NxQDFw6adCyrxmK3DSkqJqZ/ycrKOabOOuvQDr 7itWpqb2UFIvId8UvPRLSPVPwKyFxlIV8fmCw436o0tXyQ/afKJqMvgHh11pFvIelUee X6vA== 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=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e26si2609845oii.88.2020.02.14.05.12.03; Fri, 14 Feb 2020 05:12:15 -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; 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=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729260AbgBNNJz (ORCPT + 99 others); Fri, 14 Feb 2020 08:09:55 -0500 Received: from foss.arm.com ([217.140.110.172]:32886 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726191AbgBNNJy (ORCPT ); Fri, 14 Feb 2020 08:09:54 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 31AA91FB; Fri, 14 Feb 2020 05:09:54 -0800 (PST) Received: from localhost (unknown [10.37.6.21]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A84A23F68F; Fri, 14 Feb 2020 05:09:53 -0800 (PST) Date: Fri, 14 Feb 2020 13:09:52 +0000 From: Mark Brown To: "Ramuthevar,Vadivel MuruganX" Cc: linux-kernel@vger.kernel.org, linux-spi@vger.kernel.org, vigneshr@ti.com, mark.rutland@arm.com, robh+dt@kernel.org, devicetree@vger.kernel.org, dan.carpenter@oracle.com, cheol.yong.kim@intel.com, qi-ming.wu@intel.com Subject: Re: [PATCH v9 2/2] spi: cadence-quadpsi: Add support for the Cadence QSPI controller Message-ID: <20200214130952.GI4827@sirena.org.uk> References: <20200214114618.29704-1-vadivel.muruganx.ramuthevar@linux.intel.com> <20200214114618.29704-3-vadivel.muruganx.ramuthevar@linux.intel.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="GBuTPvBEOL0MYPgd" Content-Disposition: inline In-Reply-To: <20200214114618.29704-3-vadivel.muruganx.ramuthevar@linux.intel.com> X-Cookie: Shipping not included. User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --GBuTPvBEOL0MYPgd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Feb 14, 2020 at 07:46:18PM +0800, Ramuthevar,Vadivel MuruganX wrote: > +static irqreturn_t cqspi_irq_handler(int this_irq, void *dev) > +{ > + struct cqspi_st *cqspi = dev; > + unsigned int irq_status; > + > + /* Read interrupt status */ > + irq_status = readl(cqspi->iobase + CQSPI_REG_IRQSTATUS); > + > + /* Clear interrupt */ > + writel(irq_status, cqspi->iobase + CQSPI_REG_IRQSTATUS); > + > + irq_status &= CQSPI_IRQ_MASK_RD | CQSPI_IRQ_MASK_WR; > + > + if (irq_status) > + complete(&cqspi->transfer_complete); > + > + return IRQ_HANDLED; > +} This will unconditionally handle the interrupt regardless of if the hardware was actually flagging an interrupt which will break shared interrupts and the fault handling code in genirq. > + tmpbufsize = op->addr.nbytes + op->dummy.nbytes; > + tmpbuf = kzalloc(tmpbufsize, GFP_KERNEL | GFP_DMA); > + if (!tmpbuf) > + return -ENOMEM; I'm not clear where tmpbuf gets freed or passed out of this function? > + > + if (op->addr.nbytes) { > + for (i = 0; i < op->addr.nbytes; i++) > + tmpbuf[i] = op->addr.val >> (8 * (op->addr.nbytes - i - 1)); > + > + addr_buf = tmpbuf; We assign tmpbuf to addr_buf here but addr_buf just gets read from so it's not via that AFAICT. > + } > + /* Invalid address return zero. */ Missing blank line. > +static void cqspi_chipselect(struct cqspi_flash_pdata *f_pdata) > +{ > + struct cqspi_st *cqspi = f_pdata->cqspi; > + void __iomem *reg_base = cqspi->iobase; > + unsigned int chip_select = f_pdata->cs; > + unsigned int reg; > + > + reg = readl(reg_base + CQSPI_REG_CONFIG); > + reg &= ~CQSPI_REG_CONFIG_DECODE_MASK; > + > + /* Convert CS if without decoder. > + * CS0 to 4b'1110 > + * CS1 to 4b'1101 > + * CS2 to 4b'1011 > + * CS3 to 4b'0111 > + */ > + chip_select = 0xF & ~(1 << chip_select); This says "if without decoder" but there's no conditionals here, what if we do have a decoder? > + cqspi->master_ref_clk_hz = clk_get_rate(cqspi->clk); > + ddata = of_device_get_match_data(dev); > + if (ddata) { > + if (ddata->quirks & CQSPI_NEEDS_WR_DELAY) > + cqspi->wr_delay = 5 * DIV_ROUND_UP(NSEC_PER_SEC, > + cqspi->master_ref_clk_hz); > + if (ddata->hwcaps_mask & CQSPI_SUPPORTS_OCTAL) > + master->mode_bits |= SPI_RX_OCTAL; > + if (!(ddata->quirks & CQSPI_DISABLE_DAC_MODE)) > + cqspi->use_dac_mode = true; > + if (ddata->quirks & CQSPI_NEEDS_ADDR_SWAP) { > + master->bus_num = 0; > + master->num_chipselect = 2; > + } > + } Given that the driver appears to unconditionally dereference match data in other places I'd expect this to return an error if there's none, otherwise we'll oops in those other code paths later on. > + ret = devm_request_irq(dev, irq, cqspi_irq_handler, 0, > + pdev->name, cqspi); > + if (ret) { > + dev_err(dev, "Cannot request IRQ.\n"); > + goto probe_reset_failed; > + } Are you sure that it's safe to use devm_request_irq() - what happens if the interrupt fires in the process of removing the device? --GBuTPvBEOL0MYPgd Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAl5GnB8ACgkQJNaLcl1U h9C+fgf+Om+8sIQDPfShzyjlZsc5xBZOp8oDvh4pUB/LyqN2yM/zEyliKQW+lWOK fR7W7t5WsTnJaHGyniMVPQs3duaCXpHKZYZgM9U7dhvrMnsX+6A6OZgsJDc3HwfZ +Z1qQ5vEIOjv2A41gp26X6yp6rlG/7HyT2clyKL4fuoszBQQn231DLOYlh2rzIHN hpgIOR2aNl0tz9HybLexivn6d5CmqYxrvvpRavkxpFTii9ReX9xNVhGz9BZRCrr0 xFqXz1MjYnTrB0HdEMjVn+RfT8TbdT5BcmNp4SRc9OigZuQrtraC0NNvrUxZfuIS z8eVTgg4kHixNvaVrt5uWJ49071S5g== =5DCl -----END PGP SIGNATURE----- --GBuTPvBEOL0MYPgd--