Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp1732034yba; Thu, 25 Apr 2019 04:59:22 -0700 (PDT) X-Google-Smtp-Source: APXvYqxkmMEvEzQvJ61AAe7MkMVTzH3/EPOj9Cug82edypthYsCjPaLfPWL6/erHkcNABmYOn0Vh X-Received: by 2002:a65:50c2:: with SMTP id s2mr37122782pgp.112.1556193562667; Thu, 25 Apr 2019 04:59:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556193562; cv=none; d=google.com; s=arc-20160816; b=xYbWCa0qDnDVhbkcQc1543UfAghIRUQ4RCcir8XvXB8avL6lpPUBpfSdm0v3t6SJjk 4W0S6XkdxhwRqhvfzdmXKpyF6BdvhTm0IXNzru1CwZ+VO9+PTgzCwUGNqhseM27e4oAD w0EeXg/Ymg5gVuD186GxmckAAeQ2sQmy65rL2EmDPv6wQuxG1ns/5ciYiSYO1iSNRfSk VN1S+wFTpUl7r7b1yGRi/X+Nxlv7pDFuMCRT9xT2HAyOhimVmtV4JCNlm2mGx14HIlzf mSPHS3f2JytX7B1TJ7qRnfnYeP5tqbJmicLX59viQ60eNwb0B9Y4rOIYxcBEGuWRI7je 45Vg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from; bh=UKlKtZ/GOXiJBRzYflYUmsF4lisecbrfQyKgCaU7C/E=; b=UUxHe9Cl+sqhHt+S0S6OJnQO44G7zHgxUkJ27sNJZM0kwDrrErXwl9x2ub91n+0PUg oIWDrR5bniZExvJonv9uPeONOH0jLck09IrP8hfLw7goUMEsJ47+J27wm25n8WqZemJ6 Dd08WCMNx9Bw1fk96S0W/SydKt/EgZcOCdiuUrcfXkQjCeJBO6WdEshyD7lCsT5H/8j6 IAUCbiw3m9DyuxKjI5YhVRDr83LcKroEsTDNMNXhvS9MlTINXxp1gO5CcCn1uhNhb1An a9R4cy5ox5WpSJPJc9s2z0TIS19M5OwrzuU+6GhaRi1NkvYh9RuMimPxRfeqBp1r5w7F j8dA== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n21si13914798pgl.233.2019.04.25.04.59.07; Thu, 25 Apr 2019 04:59:22 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729539AbfDYG1Z (ORCPT + 99 others); Thu, 25 Apr 2019 02:27:25 -0400 Received: from mga05.intel.com ([192.55.52.43]:24717 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726330AbfDYG1Z (ORCPT ); Thu, 25 Apr 2019 02:27:25 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Apr 2019 23:27:23 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,392,1549958400"; d="scan'208";a="294379939" Received: from junxiaochang.bj.intel.com ([10.238.135.157]) by orsmga004.jf.intel.com with ESMTP; 24 Apr 2019 23:27:21 -0700 From: junxiao.chang@intel.com To: linux-kernel@vger.kernel.org Cc: gregkh@linuxfoundation.org, rafael@kernel.org, junxiao.chang@intel.com, lili.li@intel.com Subject: [PATCH] platform: release resource itself instead of resource tree Date: Thu, 25 Apr 2019 14:24:18 +0800 Message-Id: <1556173458-9318-1-git-send-email-junxiao.chang@intel.com> X-Mailer: git-send-email 2.7.4 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Junxiao Chang When platform device is deleted or there is error in adding device, platform device resources should be released. Currently API release_resource is used to release platform device resources. However, this API releases not only platform resource itself but also its child resources. It might release resources which are still in use. Calling remove_resource only releases current resource itself, not resource tree, it moves its child resources to up level. For example, platform device 1 and device 2 are registered, then only device 1 is unregistered in below code: ... // Register platform test device 1, resource 0xfed1a000 ~ 0xfed1afff pdev1 = platform_device_register_full(&pdevinfo1); // Register platform test device 2, resource 0xfed1a200 ~ 0xfed1a2ff pdev2 = platform_device_register_full(&pdevinfo2); // Now platform device 2 resource should be device 1 resource's child // Unregister device 1 only platform_device_unregister(pdev1); ... Platform device 2 resource will be released as well because its parent resource(device 1's resource) is released, this is not expected. If using API remove_resource, device 2 resource will not be released. This change fixed an intel pmc platform device resource issue when intel pmc ipc kernel module is inserted/removed for twice. Signed-off-by: Junxiao Chang --- drivers/base/platform.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/base/platform.c b/drivers/base/platform.c index dab0a5a..5fd1a41 100644 --- a/drivers/base/platform.c +++ b/drivers/base/platform.c @@ -461,7 +461,7 @@ int platform_device_add(struct platform_device *pdev) while (--i >= 0) { struct resource *r = &pdev->resource[i]; if (r->parent) - release_resource(r); + remove_resource(r); } err_out: @@ -492,7 +492,7 @@ void platform_device_del(struct platform_device *pdev) for (i = 0; i < pdev->num_resources; i++) { struct resource *r = &pdev->resource[i]; if (r->parent) - release_resource(r); + remove_resource(r); } } } -- 2.7.4