Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp12019037ybi; Fri, 26 Jul 2019 03:26:49 -0700 (PDT) X-Google-Smtp-Source: APXvYqxRkzM423M+wxv4xn+SgD8EMTXQgTyQJ59VP8usrxzpsBryalWgx2Zxit2gn0RzJJqQSchT X-Received: by 2002:a17:902:29e6:: with SMTP id h93mr37848081plb.297.1564136809021; Fri, 26 Jul 2019 03:26:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1564136809; cv=none; d=google.com; s=arc-20160816; b=CFt/XE2O8RmZOtlW71YqfDrAs5EJ9ujeSSkxd2zFL4obSWXoulotJUoa0LYSyJD9ze TqdfvcP/xezyMBVhqyLd9O74xsFx7kL6VW8fBKJe5w5xKOOIn/+qSoLNTUcA0LrklUkD HpSgkkVEKPHHcTcoD81E+eyZGu0PeMpbEmuW0OA9mgOyExXHmV9pMm9F9HF/dTLzNHO2 RSo36Mqs/S9nWbUCesAHc6J15ymwnSxlvZAwVq54R+dAEWpQjwwV6uNBSigkc58pbiCB xyzE2qgNRn9lF2C/DnAgQSGQb3P5fBvFjOT43YDSrCA1TAHNCrOg4of3mbkFNPfb5Dkk O1+A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:content-transfer-encoding :dlp-reaction:dlp-version:dlp-product:content-language :accept-language:in-reply-to:references:message-id:date:thread-index :thread-topic:subject:cc:to:from; bh=ZCqeNJbymo41CsCQ2px6pWqVsG1Bs4oYTQ3YDhP3LPI=; b=auBwrjBO1BQ309ZuIySjD4OaWNWNNo8X/zIu+glok7/83ocSZoWXPQTIbRLqOEbbe6 cOeiLNGCD7eeOFw8ZfeDAD3Zu3T7Dt7+pxEBO3jamg/Sfh5GS6lAk5US7QnhRCCKM82s vyB0FQr2/338oCy564Er4EsR3E5HpI4WQOzlpD4kBdXX8qYlJlucg05Z7B3dj5t5ZVlZ ShtpRcjNfo5DxC5tV+XyLZSQJ8orA0ErjxiPaPwGcIElZP97N+1qDWc+2PRxl6yqmKch YeJM2hNP6b91pDCS42bmcKs9dZZWumi+C5oABIL6ppxdUPSHxrJEkRh8/Fi4Ks+koqA2 z72g== 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 h11si47062715pju.90.2019.07.26.03.26.33; Fri, 26 Jul 2019 03:26:49 -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 S1726397AbfGZKY2 convert rfc822-to-8bit (ORCPT + 99 others); Fri, 26 Jul 2019 06:24:28 -0400 Received: from mga03.intel.com ([134.134.136.65]:38943 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726023AbfGZKY1 (ORCPT ); Fri, 26 Jul 2019 06:24:27 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jul 2019 03:24:26 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,310,1559545200"; d="scan'208";a="370022667" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by fmsmga006.fm.intel.com with ESMTP; 26 Jul 2019 03:24:25 -0700 Received: from fmsmsx115.amr.corp.intel.com (10.18.116.19) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.439.0; Fri, 26 Jul 2019 03:24:25 -0700 Received: from shsmsx106.ccr.corp.intel.com (10.239.4.159) by fmsmsx115.amr.corp.intel.com (10.18.116.19) with Microsoft SMTP Server (TLS) id 14.3.439.0; Fri, 26 Jul 2019 03:24:25 -0700 Received: from shsmsx107.ccr.corp.intel.com ([169.254.9.65]) by SHSMSX106.ccr.corp.intel.com ([169.254.10.204]) with mapi id 14.03.0439.000; Fri, 26 Jul 2019 18:24:23 +0800 From: "Chang, Junxiao" To: Greg KH CC: "linux-kernel@vger.kernel.org" , "rafael@kernel.org" , "Li, Lili" Subject: RE: [PATCH] platform: release resource itself instead of resource tree Thread-Topic: [PATCH] platform: release resource itself instead of resource tree Thread-Index: AQHVQu5PiIIVSehJMkWgCcRVEVUpkqbcq93Q Date: Fri, 26 Jul 2019 10:24:22 +0000 Message-ID: <840F6BCBBBA89F46BAD0D7D6EF39E6E350F5072A@SHSMSX107.ccr.corp.intel.com> References: <1556173458-9318-1-git-send-email-junxiao.chang@intel.com> <20190725133850.GB11115@kroah.com> In-Reply-To: <20190725133850.GB11115@kroah.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNTcwMTY1NWQtODI4Zi00ZDQwLTg2NWItMmVmYTVkNTAwOTQwIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiQTJQTnlyNEJcL0ZjMFwvMUFuVkVla0Y4Q2xOaW52RGhic3hLcmFzcUh2dWt0eWUwYjBiaE5FOFJFMFhnRDR2UHorIn0= x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.600.7 dlp-reaction: no-action x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Greg, Thank you for looking at it. Below example is simplified description. Our detail problem is: 1. ACPI driver registers a MEM resource during bootup; 2. Our PUNIT(Intel CPU power management module) platform device reads ACPI driver's resource, and registers same MEM resource; 3. According to current resource management logic, if two resources are same, later registered resource will be parent. That is, PUNIT platform device's resource will be ACPI driver resource's parent. 4. PUNIT kernel module is removed, its resource will be removed. If we use original API "release_resource", ACPI driver's resource will be released as well because it is PUNIT device's child; 5. Next time PUNIT platform device kernel module is inserted, it might read wrong ACPI MEM resource because it has been released in step 4. How should we handle this case? :) We should not register same MEM resource in step 2? Or, make change in resource management logic, if two resources are same, later registered resource should be child instead of parent? Thanks, Junxiao -----Original Message----- From: Greg KH [mailto:gregkh@linuxfoundation.org] Sent: Thursday, July 25, 2019 9:39 PM To: Chang, Junxiao Cc: linux-kernel@vger.kernel.org; rafael@kernel.org; Li, Lili Subject: Re: [PATCH] platform: release resource itself instead of resource tree On Thu, Apr 25, 2019 at 02:24:18PM +0800, junxiao.chang@intel.com wrote: > 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. But shouldn't the parent device not get removed until all of the children are removed? What is causing this "inversion" to happen? > > 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); > ... Don't do that. :) You created this mess of platform devices, so you need to keep track of them. > 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. Why not fix that kernel module instead? It seems like that is the real problem here, not a driver core issue. thanks, greg k-h