Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751294AbbGaWdP (ORCPT ); Fri, 31 Jul 2015 18:33:15 -0400 Received: from mail-wi0-f169.google.com ([209.85.212.169]:33253 "EHLO mail-wi0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751070AbbGaWdN (ORCPT ); Fri, 31 Jul 2015 18:33:13 -0400 MIME-Version: 1.0 In-Reply-To: <20150731192458.457c6c9d@bbrezillon> References: <4982216b5cb602c71ade6810cecdb9535e0862fc.1438340815.git.hramrach@gmail.com> <20150731180614.162852ee@bbrezillon> <20150731192458.457c6c9d@bbrezillon> From: Michal Suchanek Date: Sat, 1 Aug 2015 00:32:32 +0200 Message-ID: Subject: Re: [PATCH v2 5/5] mtd: ofpart: move ofpart partitions to a dedicated dt node To: Boris Brezillon Cc: Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , David Woodhouse , Brian Norris , devicetree , Linux Kernel Mailing List , MTD Maling List Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1667 Lines: 49 On 31 July 2015 at 19:24, Boris Brezillon wrote: > On Fri, 31 Jul 2015 18:52:01 +0200 > Michal Suchanek wrote: > > >> > >> >> (*pparts)[i].offset = of_read_number(reg, a_cells); >> >> (*pparts)[i].size = of_read_number(reg + a_cells, s_cells); >> >> >> >> @@ -92,15 +116,15 @@ static int parse_ofpart_partitions(struct mtd_info *master, >> >> i++; >> >> } >> >> >> >> - if (!i) { >> >> - of_node_put(pp); >> >> - pr_err("No valid partition found on %s\n", node->full_name); >> >> - kfree(*pparts); >> >> - *pparts = NULL; >> >> - return -EINVAL; >> >> - } >> >> - >> > >> > Are you sure you can safely remove this check? >> >> Yes. It was incomplete check to reject some partitioning schemes >> considered invalid. >> >> Now there is stricter checking above so this can be removed. > > Indeed, I was worried about resources deallocation, but this is handle > by the caller, and if nr_parts is zero the master MTD device will > be exposed. Due to compatibility with the previous scheme there is still possibility that partitions are allocated, and no partitions are returned due to the nr_parts--; So yes, the pparts could possibly leak in this case if there were more partition parsers following ofpart and should be deallocated. Thanks Michal -- 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/