Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp2905717imm; Wed, 16 May 2018 23:24:26 -0700 (PDT) X-Google-Smtp-Source: AB8JxZoqcctJ2yaDN+ymAeEhyeWZPBwKOIIjgnM01Jk7po6HWg2ZDUWlLPYxGQ/t9IoJ7GqHs+L4 X-Received: by 2002:a62:990f:: with SMTP id d15-v6mr3983576pfe.115.1526538266122; Wed, 16 May 2018 23:24:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526538266; cv=none; d=google.com; s=arc-20160816; b=Jr+3RzritGdAfH+0KJFmci0IfdE7eXFcaikjwpKCGNLiVXduDPtQZnH0FyxGAigpn7 4VMneIydY0/0dxFCKlrgu8zrYGcswmftg4B6WAY4+K71i8hI4oiuzTjwY6Optv5njd0a hkweSvUaxIHbao/hjVjxdqqVCS283o1OaQpGJnpdKXiZ6U0WEIs+/5c8MMjDgDK/GDHj +XQrtmMG8KkEsfWr1Epjr2x0OD4B9YxbB4DAIW3XA3JbP7Y/q1k7DTInyaM8X7k5ZzQw kuPPS+C81dMes93/y8pr3zIp6yO+kK4j+AO/V7rR8MIKv4BAWn/uB428v/TJ9Y4pp4g9 WEiQ== 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:in-reply-to :mime-version:user-agent:date:message-id:from:cc:references:to :subject:arc-authentication-results; bh=HBaLUN0R0Bxb+N+AyiDqLNfPB7HXFoC0enjM/kLgqOk=; b=HiYZiMIV9WTmFOQnlZFr+1QtKr03vTWta0lC98ji+Z9yy0CooLNI2ACf7GBOUP7Bj/ 5+MRvHw1ctovNQWLioaowWOcNukZ9JlbnJXSII+4m76wYnRqlbjJdbMW6micyZRSqif1 jfQCs4QrY60TZUJLjp42f384pMFpKDrGb0NPzQlcxM7+W/pBhuhsHnCBUI5+qq2kGXxx sT916rswkC0s0p04swd6id9MW1uy/LNiGzAjwaHlkKv4YH1piKxYofHsa6GBuFxEABN8 ynphCEqgnL02ST+DUSDo0XI0TzanUWmijglw1t/4toQL2AYbGhJaP+osyihVKvzRmG4S FiRw== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s204-v6si3569897pgs.164.2018.05.16.23.24.11; Wed, 16 May 2018 23:24:26 -0700 (PDT) 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752416AbeEQGXS (ORCPT + 99 others); Thu, 17 May 2018 02:23:18 -0400 Received: from relay1.mentorg.com ([192.94.38.131]:37707 "EHLO relay1.mentorg.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751319AbeEQGXQ (ORCPT ); Thu, 17 May 2018 02:23:16 -0400 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=SVR-IES-MBX-04.mgc.mentorg.com) by relay1.mentorg.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-SHA384:256) id 1fJCJl-00036Q-01 from Vladimir_Zapolskiy@mentor.com ; Wed, 16 May 2018 23:23:13 -0700 Received: from [137.202.108.125] (137.202.0.87) by SVR-IES-MBX-04.mgc.mentorg.com (139.181.222.4) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 17 May 2018 07:23:08 +0100 Subject: Re: [PATCH] PCI: Clean up resource allocation in devm_of_pci_get_host_bridge_resources() To: Jan Kiszka , Bjorn Helgaas , Linux Kernel Mailing List References: <3aeb2ed038cbce8fe744b614dc19d414555a7e8f.1526375226.git.jan.kiszka@siemens.com> CC: Andy Shevchenko , , linux-arm Mailing List , Jingoo Han , Joao Pinto , Lorenzo Pieralisi From: Vladimir Zapolskiy Message-ID: <97f42f4a-071a-4335-ca65-a0f26adc1b89@mentor.com> Date: Thu, 17 May 2018 09:23:07 +0300 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Icedove/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [137.202.0.87] X-ClientProxiedBy: svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) To SVR-IES-MBX-04.mgc.mentorg.com (139.181.222.4) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/16/2018 03:31 PM, Jan Kiszka wrote: > Instead of first allocating and then freeing memory for struct resource > in case we cannot parse a PCI resource from the device tree, work > against a local struct and kmemdup it when we decide to go with it. > > Suggested-by: Andy Shevchenko > Signed-off-by: Jan Kiszka > --- > drivers/pci/of.c | 14 ++++++-------- > 1 file changed, 6 insertions(+), 8 deletions(-) > > diff --git a/drivers/pci/of.c b/drivers/pci/of.c > index b06585a1da75..fc0f906c5c25 100644 > --- a/drivers/pci/of.c > +++ b/drivers/pci/of.c > @@ -266,7 +266,7 @@ int devm_of_pci_get_host_bridge_resources(struct device *dev, > struct list_head *resources, resource_size_t *io_base) > { > struct device_node *dev_node = dev->of_node; > - struct resource *res; > + struct resource *res, tmp_res; > struct resource *bus_range; > struct of_pci_range range; > struct of_pci_range_parser parser; > @@ -320,18 +320,16 @@ int devm_of_pci_get_host_bridge_resources(struct device *dev, > if (range.cpu_addr == OF_BAD_ADDR || range.size == 0) > continue; > > - res = devm_kzalloc(dev, sizeof(struct resource), GFP_KERNEL); > + err = of_pci_range_to_resource(&range, dev_node, &tmp_res); > + if (err) > + continue; > + > + res = devm_kmemdup(dev, &tmp_res, sizeof(tmp_res), GFP_KERNEL); The change looks okay, apparently probable garbage in tmp_res.desc has no impact. Reviewed-by: Vladimir Zapolskiy -- With best wishes, Vladimir