Received: by 2002:a25:b323:0:0:0:0:0 with SMTP id l35csp511830ybj; Thu, 19 Sep 2019 18:26:37 -0700 (PDT) X-Google-Smtp-Source: APXvYqxACkWKZb9V1RfNyCLNscX8TcKYhTURlZjOGNTYpQJaXAVf0nK8mTbIkQ3RTa6aTW/hIzqH X-Received: by 2002:a17:906:5246:: with SMTP id y6mr16615046ejm.158.1568942797535; Thu, 19 Sep 2019 18:26:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568942797; cv=none; d=google.com; s=arc-20160816; b=FBSSOcmpImwQjjUrwlkYFol41ipkZhNPhn8ng7iYcj26W2R8V9Mh1CfPu5eDatGM+8 xDKHe71mjr0NnNNVq6XgTkeQjr5u62bM/YAF7hnt3+EZhBnzGOcvTHWgW5ZoWpTWf3SF 7TMl/HR3KeULWCk1nOYBddyJ3q4pj88V39gmOkXywSwP+AEr1MNVhNSjExnYQuMdS8aB giYVIyVZ0usZZ881Kppyw8RE7wmbdA8Ozaa1iE9Ey9+lc294hqXR4zSJujGFWi5kT4zJ Dxj2ugjRHH85oAYnw9qmHK4xaeH/dDfoQOG77auDWL6vUwKcmP+ZE/84YGbbEnbJwVcU VZGA== 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=mi5PpxhhjWB/vjvclT1El/b6xypBzs+W4bALiD1ixws=; b=kKzsp9TW/kxdaHjKlJX8L4UxtgxgE+P9E9bxazLEciBTOW8YUf3FLp8/tAVe0+k+5p vBsxxF4zd7HQoLeNHY2qJDKGxAzLrsBI706WpVxVNvV86epLG3tmWlexuHWjfFyJUzUa WnvBL4pPlAGKeVBuuPTpTgdt8uZFNsPYg4MNNKaPHg6U4LtTKY7x1ickJM2WgLoriPjH suogpI3uGevQAmlu0kQowVbiAQJbLCPKg+Movw/9iT21Z2BNAaqTbSH+yWVsG+yH+KHI EARpVzgzvB4cZWLBPVkEJmod2g6qOIZsGEWQemsG/6vewlAtSrdGoysWd3oe2RoYwB2K E4kg== 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 b26si202234eju.87.2019.09.19.18.26.14; Thu, 19 Sep 2019 18:26:37 -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 S2391406AbfISRFy convert rfc822-to-8bit (ORCPT + 99 others); Thu, 19 Sep 2019 13:05:54 -0400 Received: from mga01.intel.com ([192.55.52.88]:2739 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2391361AbfISRFx (ORCPT ); Thu, 19 Sep 2019 13:05:53 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Sep 2019 10:05:53 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,524,1559545200"; d="scan'208";a="188147351" Received: from orsmsx109.amr.corp.intel.com ([10.22.240.7]) by fmsmga007.fm.intel.com with ESMTP; 19 Sep 2019 10:05:52 -0700 Received: from orsmsx110.amr.corp.intel.com ([169.254.10.139]) by ORSMSX109.amr.corp.intel.com ([169.254.11.122]) with mapi id 14.03.0439.000; Thu, 19 Sep 2019 10:05:52 -0700 From: "Moore, Robert" To: Nikolaus Voss CC: Ferry Toth , "Shevchenko, Andriy" , "Schmauss, Erik" , "Rafael J. Wysocki" , Len Brown , "Jacek Anaszewski" , Pavel Machek , "Dan Murphy" , "linux-acpi@vger.kernel.org" , "devel@acpica.org" , "linux-kernel@vger.kernel.org" , Jan Kiszka Subject: RE: [PATCH] ACPICA: make acpi_load_table() return table index Thread-Topic: [PATCH] ACPICA: make acpi_load_table() return table index Thread-Index: AQHVaUE6M44QnoJV0UqVXW85SrAmnKcoFnTQgAGaZwD///c2gIAAhhUAgAAa0gD//5ht0IAEqKwAgAL5tVCAAHqlgIABR7TA Date: Thu, 19 Sep 2019 17:05:51 +0000 Message-ID: <94F2FBAB4432B54E8AACC7DFDE6C92E3B9686438@ORSMSX110.amr.corp.intel.com> References: <20190906174605.GY2680@smile.fi.intel.com> <20190912080742.24642-1-nikolaus.voss@loewensteinmedical.de> <94F2FBAB4432B54E8AACC7DFDE6C92E3B9679CE8@ORSMSX110.amr.corp.intel.com> <94F2FBAB4432B54E8AACC7DFDE6C92E3B967ADF6@ORSMSX110.amr.corp.intel.com> <20190913151228.GT2680@smile.fi.intel.com> <7625fe37-1710-056d-fb9e-39c33fd962a1@gmail.com> <94F2FBAB4432B54E8AACC7DFDE6C92E3B967AEC9@ORSMSX110.amr.corp.intel.com> <94F2FBAB4432B54E8AACC7DFDE6C92E3B968327D@ORSMSX110.amr.corp.intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMGQ3YmIzMDYtZmU0OS00Y2EwLWFhMjItMTJkNTNiNjJiNzk0IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiaHZodWNkMzRLTktEWDZBenVVOVRqUUdzTDVoRGpoKzJxU0QyVFwvVVZha05lOVNSajF5SnZlekF2M2lHNUpBQ1UifQ== x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [10.22.254.139] 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 -----Original Message----- From: Nikolaus Voss [mailto:nv@vosn.de] Sent: Wednesday, September 18, 2019 7:32 AM To: Moore, Robert Cc: Ferry Toth ; Shevchenko, Andriy ; Schmauss, Erik ; Rafael J. Wysocki ; Len Brown ; Jacek Anaszewski ; Pavel Machek ; Dan Murphy ; linux-acpi@vger.kernel.org; devel@acpica.org; linux-kernel@vger.kernel.org; Jan Kiszka Subject: RE: [PATCH] ACPICA: make acpi_load_table() return table index On Wed, 18 Sep 2019, Moore, Robert wrote: > > > -----Original Message----- > From: Nikolaus Voss [mailto:nv@vosn.de] > Sent: Monday, September 16, 2019 2:47 AM > To: Moore, Robert > Cc: Ferry Toth ; Shevchenko, Andriy > ; Schmauss, Erik > ; Rafael J. Wysocki ; Len > Brown ; Jacek Anaszewski > ; Pavel Machek ; Dan Murphy > ; linux-acpi@vger.kernel.org; devel@acpica.org; > linux-kernel@vger.kernel.org; Jan Kiszka > Subject: RE: [PATCH] ACPICA: make acpi_load_table() return table index > > On Fri, 13 Sep 2019, Moore, Robert wrote: >> >> >> -----Original Message----- >> From: Ferry Toth [mailto:fntoth@gmail.com] >> Sent: Friday, September 13, 2019 9:48 AM >> To: Shevchenko, Andriy ; Moore, Robert >> >> Cc: Nikolaus Voss ; Schmauss, Erik >> ; Rafael J. Wysocki ; Len >> Brown ; Jacek Anaszewski >> ; Pavel Machek ; Dan Murphy >> ; linux-acpi@vger.kernel.org; devel@acpica.org; >> linux-kernel@vger.kernel.org; nikolaus.voss@loewensteinmedical.de; >> Jan Kiszka >> Subject: Re: [PATCH] ACPICA: make acpi_load_table() return table >> index >> >> Hello all, >> >> Sorry to have sent our message with cancelled e-mail address. I have correct this now. >> >> Op 13-09-19 om 17:12 schreef Shevchenko, Andriy: >>> On Fri, Sep 13, 2019 at 05:20:21PM +0300, Moore, Robert wrote: >>>> -----Original Message----- >>>> From: Nikolaus Voss [mailto:nv@vosn.de] >>>> Sent: Friday, September 13, 2019 12:44 AM >>>> To: Moore, Robert >>>> Cc: Shevchenko, Andriy ; Schmauss, >>>> Erik ; Rafael J. Wysocki >>>> ; Len Brown ; Jacek Anaszewski >>>> ; Pavel Machek ; Dan >>>> Murphy ; linux-acpi@vger.kernel.org; >>>> devel@acpica.org; linux-kernel@vger.kernel.org; Ferry Toth >>>> ; nikolaus.voss@loewensteinmedical.de >>>> Subject: RE: [PATCH] ACPICA: make acpi_load_table() return table >>>> index >>>> >>>> Bob, >>>> >>>> On Thu, 12 Sep 2019, Moore, Robert wrote: >>>>> The ability to unload an ACPI table (especially AML tables such as >>>>> SSDTs) is in the process of being deprecated in ACPICA -- since it >>>>> is also deprecated in the current ACPI specification. This is >>>>> being done because of the difficulty of deleting the namespace >>>>> entries for the table. FYI, Windows does not properly support this function either. >>>> >>>> ok, I see it can be a problem to unload an AML table with all it's >>>> consequences e.g. with respect to driver unregistering in setups >>>> with complex dependencies. It will only work properly under certain >>>> conditions >>>> - nevertheless acpi_tb_unload_table() is still exported in ACPICA and we should get this working as it worked before. >>>> >>>> AcpiTbUnloadTable is not exported, it is an internal interface only >>>> -- as recognized by the "AcpiTb". >>> >>> In Linux it became a part of ABI when the >>> >>> commit 772bf1e2878ecfca0d1f332071c83e021dd9cf01 >>> Author: Jan Kiszka >>> Date: Fri Jun 9 20:36:31 2017 +0200 >>> >>> ACPI: configfs: Unload SSDT on configfs entry removal >>> >>> appeared in the kernel. >> >> And the commit message explains quite well why it is an important feature: >> >> "This allows to change SSDTs without rebooting the system. >> It also allows to destroy devices again that a dynamically loaded SSDT created. >> >> The biggest problem AFAIK is that under linux, many drivers cannot be unloaded. Also, there are many race conditions as the namespace entries "owned" by an SSDT being unloaded are deleted (out from underneath a driver). >> >> This is widely similar to the DT overlay behavior." >> >>>> I'm not sure that I want to change the interface to AcpiLoadTable >>>> just for something that is being deprecated. Already, we throw an >>>> ACPI_EXCEPTION if the Unload operator is encountered in the AML >>>> byte stream. The same thing with AcpiUnloadParentTable - it is being deprecated. >>>> >>>> ACPI_EXCEPTION ((AE_INFO, AE_NOT_IMPLEMENTED, >>>> "AML Unload operator is not supported")); > > Bob, what is your suggestion to fix the regression then? > > We could revert acpi_configfs.c to use > acpi_tb_install_and_load_table() instead of acpi_load_table(), leaving > loaded APCI objects uninitalized, but at least, unloading will work again. > > I guess my next question is: why do you want to unload a table in the > first place? Because it worked before and there are people who rely on it. If it's deprecated there should be a user notification and a reasonable end-of-life timeline to give these users a chance to develop an alternative solution. So, I still don't understand why this no longer works. We did not make any purposeful changes in this area - AFAIK. Bob Niko > > > Do we have any other options? > > Niko >