Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp1903764pxu; Sun, 13 Dec 2020 07:07:26 -0800 (PST) X-Google-Smtp-Source: ABdhPJyPOKKMtQ5i8r+cl9DwvcIRmA4YspUlLCi6+d02IrR60i0756oDGEq3v/9OUgNbnedC/k54 X-Received: by 2002:a05:6402:1c04:: with SMTP id ck4mr20906949edb.320.1607872046764; Sun, 13 Dec 2020 07:07:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1607872046; cv=none; d=google.com; s=arc-20160816; b=PqZbRaf9cXhG6mJBmlU/DntvT3oToch3CAVoMOEGLxa2xeOMm4P5CtlgzaBKkIGOXB 36USm9kEsVJ1U2+zbgZmMm0ZLJFgeMQtFKmsXJU+GvraIIRLayAwsqc9W30oUjroJ4OU LLysJRzNy6ThevdvusJ1KPre5pgkW3oXcYIjPLUA9s50QngV1U627kR2qaXQlguDFCoI GpGMiycvpsIRyo5qnVUdFzYDjYentDle1DH9HCiClHBp+qPuWdXj3gGvIAGz4mnISQza Rn+R0RiOf+K5f1508SrzW9M/Vi6RkI+3xthaoKW7eBuTeb/hHE9ioOfoOqCT1xBgibvH DA7A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=3Kw4r/Gtp6HZI3ef/KYWMbblFJNKv094D0Q9eyKSXNo=; b=tACSL8Pvhs8uPji6KZEkokhiqCo2aEVTC+zfrdgWq6B7WkYNezIUdd345vu1PTOUYV 8dPSWzzwwqVeS04JONVBgpHmMMzYVKZAGlAIPnTfmns3pgf9ipSE7TOO/XNuYw39W/cC FoEkb1RBHA49guwIHq4Eg2mfvu3EpWu3FRNNPm0kSrOX0FmoxnacGM+PpC6Is6rjoW4z hiaGad6ynrqVTHybGkthHHAtXCTODJdwaeZvZd5uIiA8TSS+GLf5aDdIFtJGYwILgf6p 7qntzDFlYaX1eIunqc1xls9gCk0QDzXdmWE+EgemfMyqULjjFPoptg52gKPQJcl4FSqH 7drA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id w10si8592796edv.243.2020.12.13.07.07.04; Sun, 13 Dec 2020 07:07:26 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726468AbgLLMGx (ORCPT + 99 others); Sat, 12 Dec 2020 07:06:53 -0500 Received: from bmailout2.hostsharing.net ([83.223.78.240]:52445 "EHLO bmailout2.hostsharing.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2390904AbgLLMGv (ORCPT ); Sat, 12 Dec 2020 07:06:51 -0500 Received: from h08.hostsharing.net (h08.hostsharing.net [83.223.95.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.hostsharing.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (not verified)) by bmailout2.hostsharing.net (Postfix) with ESMTPS id A8B682800A287; Sat, 12 Dec 2020 13:05:48 +0100 (CET) Received: by h08.hostsharing.net (Postfix, from userid 100393) id 2758D110C0; Sat, 12 Dec 2020 13:06:08 +0100 (CET) Date: Sat, 12 Dec 2020 13:06:08 +0100 From: Lukas Wunner To: Sowjanya Komatineni Cc: thierry.reding@gmail.com, jonathanh@nvidia.com, broonie@kernel.org, bbrezillon@kernel.org, p.yadav@ti.com, tudor.ambarus@microchip.com, linux-spi@vger.kernel.org, linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 4/9] spi: tegra210-quad: Add support for Tegra210 QSPI controller Message-ID: <20201212120608.GA24303@wunner.de> References: <1607721363-8879-1-git-send-email-skomatineni@nvidia.com> <1607721363-8879-5-git-send-email-skomatineni@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1607721363-8879-5-git-send-email-skomatineni@nvidia.com> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Dec 11, 2020 at 01:15:58PM -0800, Sowjanya Komatineni wrote: > Tegra SoC has a Quad SPI controller starting from Tegra210. The probe/remove hooks LGTM now. Just two tiny nits that caught my eye: > + master = devm_spi_alloc_master(&pdev->dev, sizeof(*tqspi)); > + if (!master) { > + dev_err(&pdev->dev, "failed to allocate spi_master\n"); > + return -ENOMEM; > + } The memory allocater already emits an error message if it can't satisfy a request. Emitting an additional message here isn't really necessary. > +exit_free_irq: > + free_irq(qspi_irq, tqspi); > +exit_pm_disable: > + pm_runtime_disable(&pdev->dev); > + tegra_qspi_deinit_dma(tqspi); > + return ret; > +} > + > +static int tegra_qspi_remove(struct platform_device *pdev) > +{ > + struct spi_master *master = platform_get_drvdata(pdev); > + struct tegra_qspi *tqspi = spi_master_get_devdata(master); > + > + spi_unregister_master(master); > + free_irq(tqspi->irq, tqspi); > + tegra_qspi_deinit_dma(tqspi); > + pm_runtime_disable(&pdev->dev); The order of tegra_qspi_deinit_dma() and pm_runtime_disable() is reversed in the remove hook vis-a-vis the probe error path. It's nicer to use the same order as in the probe error path. Thanks, Lukas