Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp580306ybt; Fri, 19 Jun 2020 08:37:05 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxZgQV300PYf1l7u8ZLgbDnZPA2aws5EkRzXoo7EgfIz0Hxkcg1Wi7/PLBCCCx7Ks0yQAgg X-Received: by 2002:a50:ec0f:: with SMTP id g15mr3992235edr.359.1592581024960; Fri, 19 Jun 2020 08:37:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1592581024; cv=none; d=google.com; s=arc-20160816; b=Qqog7nYcE9f/z7Ey4P7UsdRCvgivtLTTezfCffm2rhtrGHdCAiaBga1mJNHVh72owd cDR4aLFDhAdXEMcwVqEEhw4/S9gFTybHE4e/cx+5ndaURN2ki7vk41LMn9InL+Po4kNS y23zEf5z95EzTDHjLCr9e9zO8pwot12/isG8u0CJ6k+eK/7lQkYnPjrFuEeqzaryupNx VzY5pu+Lu6hyzNQcmr5uLmmSnRYGxHAebshxKmnMUE9n8uVW2KdJLqYnAgkrwkrcZvEN 0e7Lb6qHksNTLlSktBY5E3uljnKoYSUWaCNY9hhUIkAeUgBs8l22GtSSQ3GzC6EbFTxk sMNg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=ke0goKmGifZ4gZxj9hS/Vn2ryDylDpwBs9yNPsZ/hcU=; b=gZii0ZLm2yh5KnQ1yri9sgIM+PCx08rKSa7eFcamSfKal8egGhwy3XuYuiPvIQX5uw 4Qp0FjOXKNQWmzsPCaTkis+HmKarFxkZATZ+1E2s+TMTmrAUNCYTngVYaCjdC8iJZKmU tnMH7/p4MjS9pK18E4tvOvFDRiIL1cy1rklJzXfv1rGISqReFxbS5Nqcb2n2RqHy3kbF ji8yyHvfqpl+0TdwGd47cOT0za/P0/rh8PqJoJtiLZuZwkJY+NYoOILfvIJW8Zbkoeca VX5g3OhIraFTYzcYDCP/X29xxE7cXJRSyrowlaF6LyyIXqXo9tCu5GHfv2BZUes6gdu1 p2cg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=RMFgbdCf; 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 g6si4044160edr.432.2020.06.19.08.36.42; Fri, 19 Jun 2020 08:37:04 -0700 (PDT) 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; dkim=pass header.i=@kernel.org header.s=default header.b=RMFgbdCf; 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 S2391378AbgFSPcA (ORCPT + 99 others); Fri, 19 Jun 2020 11:32:00 -0400 Received: from mail.kernel.org ([198.145.29.99]:35928 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2391379AbgFSPby (ORCPT ); Fri, 19 Jun 2020 11:31:54 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 62BDA20757; Fri, 19 Jun 2020 15:31:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592580713; bh=5iZkv0fqTgd+XreIbBWlXku76xfHX8tsVakDmB4R/f0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=RMFgbdCf/E182L9gdIXA24YCCgmXWjUUwehZDeZwmzDiZnZTYpFDAtDzMe5bo7pah 2TXLsyqeZtjIjLmJpZCUaVo+J1OSch7L/+TQhcsyXmlwmDkmjbehWlYOAKxbfWBQCc o7VMf+ley7B2cNNk9VL6bV1hDVwGEJHCzsjfpau0= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Miquel Raynal Subject: [PATCH 5.7 355/376] mtd: rawnand: diskonchip: Fix the probe error path Date: Fri, 19 Jun 2020 16:34:33 +0200 Message-Id: <20200619141727.124347974@linuxfoundation.org> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20200619141710.350494719@linuxfoundation.org> References: <20200619141710.350494719@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Miquel Raynal commit c5be12e45940f1aa1b5dfa04db5d15ad24f7c896 upstream. Not sure nand_cleanup() is the right function to call here but in any case it is not nand_release(). Indeed, even a comment says that calling nand_release() is a bit of a hack as there is no MTD device to unregister. So switch to nand_cleanup() for now and drop this comment. There is no Fixes tag applying here as the use of nand_release() in this driver predates by far the introduction of nand_cleanup() in commit d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") which makes this change possible. However, pointing this commit as the culprit for backporting purposes makes sense even if it did not intruce any bug. Fixes: d44154f969a4 ("mtd: nand: Provide nand_cleanup() function to free NAND related resources") Signed-off-by: Miquel Raynal Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-mtd/20200519130035.1883-13-miquel.raynal@bootlin.com Signed-off-by: Greg Kroah-Hartman --- drivers/mtd/nand/raw/diskonchip.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) --- a/drivers/mtd/nand/raw/diskonchip.c +++ b/drivers/mtd/nand/raw/diskonchip.c @@ -1609,13 +1609,10 @@ static int __init doc_probe(unsigned lon numchips = doc2001_init(mtd); if ((ret = nand_scan(nand, numchips)) || (ret = doc->late_init(mtd))) { - /* DBB note: i believe nand_release is necessary here, as + /* DBB note: i believe nand_cleanup is necessary here, as buffers may have been allocated in nand_base. Check with Thomas. FIX ME! */ - /* nand_release will call mtd_device_unregister, but we - haven't yet added it. This is handled without incident by - mtd_device_unregister, as far as I can tell. */ - nand_release(nand); + nand_cleanup(nand); goto fail; }