Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757077AbaJaJfZ (ORCPT ); Fri, 31 Oct 2014 05:35:25 -0400 Received: from mail-qc0-f174.google.com ([209.85.216.174]:50705 "EHLO mail-qc0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756393AbaJaJfX (ORCPT ); Fri, 31 Oct 2014 05:35:23 -0400 MIME-Version: 1.0 In-Reply-To: References: <1414655193-16952-1-git-send-email-pramod.gurav@smartplayin.com> Date: Fri, 31 Oct 2014 10:35:22 +0100 Message-ID: Subject: Re: [PATCH v2] mmc: davinci: Fix and simplify probe failure path From: Ulf Hansson To: Pramod Gurav Cc: Pramod Gurav , "linux-kernel@vger.kernel.org" , Chris Ball , linux-mmc Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 30 October 2014 12:45, Pramod Gurav wrote: > Thanks Ulf, > > On Thu, Oct 30, 2014 at 4:38 PM, Ulf Hansson wrote: >> On 30 October 2014 08:46, Pramod Gurav wrote: >>> The sequence of resource release in probe failure path in this >>> driver was wrong and needed fixes to cleanly unload the driver. >>> This changes does the same by switching to managed resources and >>> fixes return path to release resource in proper sequence. >>> >>> Cc: Chris Ball >>> Cc: Ulf Hansson >>> Cc: linux-mmc@vger.kernel.org >> >> Please remove these Ccs above from the commit message. It's not needed >> when you anyway need to send the patches directly to these addresses. > Will remove Cc. > >> >>> Signed-off-by: Pramod Gurav >>> --- > .. > >>> >>> host = mmc_priv(mmc); >>> host->mmc = mmc; /* Important */ >>> @@ -1275,15 +1273,16 @@ static int __init davinci_mmcsd_probe(struct platform_device *pdev) >>> host->txdma = r->start; >>> >>> host->mem_res = mem; >>> - host->base = ioremap(mem->start, mem_size); >>> - if (!host->base) >>> - goto out; >>> + host->base = devm_ioremap(&pdev->dev, mem->start, mem_size); >> >> I realized that you should use devm_ioremap_resource() instead. That >> would simplify the code even more. >> > Yes, we could have used devm_ioremap_resource() but this driver stores > the return from devm_request_mem_region() in host->mem_res and uses > the same in the other part of drivers. Is there a way to work this > around? Isn't that the same value as "mem->start" ? Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/