Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp1007768ybe; Fri, 13 Sep 2019 09:37:48 -0700 (PDT) X-Google-Smtp-Source: APXvYqxzL1fCS6I8XMauwCXTs5kAhd2HwZNbVM7sXM2ppXHimG/3Nif6U/fm2QXiFivA7J880RzD X-Received: by 2002:a17:906:3187:: with SMTP id 7mr9824926ejy.238.1568392668534; Fri, 13 Sep 2019 09:37:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568392668; cv=none; d=google.com; s=arc-20160816; b=blhOrmOAlZ/iMoeNuum8iaO/sjwz9PEb7lXhqsvsK6Il8OShqhddW6oa4SHb3bXxVf Qg3MuQEAT7ONgHU8/jVpCGr/Tl5o0vu0WWBn81DJ4+LvYN7388c+NmE9x/Q2BNQAXakB 4oRtEGwz4s8gy7dHKUBZBg8u5LtWoO1etEEaG6N1no9qBKk4FPDKsenBDEBdOuT0R2nw vKds4nTcI6zFQ228dku0drgACJNzRDDWaC5wf5Hzh8c/hrZnwQ1LDrpqBGVApff0Xf8j RrK/0Jm8I16c7G0uJRc43kN6NOWeSvyzQbPfkax1eI3qG6QHDp6ELfFyqfz6Oveki9Ds cQdw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:organization:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=w1kDXLuFPHGk3b9WqzAtjHHJQUOFDwFmblJOqZAgJJA=; b=CT7nvBa/Cq5xED9X30Nd38P+oiTird8Y2Mw/gKWOshvbMZHHc9csCYpuU/oP7zcSiz AObiOUtVVB+yQp/gbj2crSnzAY/0P5ktiFpZ2/sNlJH9x+JrvMDAcci0Z7IkBjonHBos 8nuNCIYpUzkAinvoAIR+PEc92v/8hU2snu6UGG15BxAw9aDb5GyiRNp6YrIsBB/x8Zvs Twitg5s+qVSLD1D/9SS9rfHDnaGKkYApxJIS8KEhPZ73g7HjeLxVWm+ESUWQ8HxfFHCx 2yiC0BZc0fqGiyhCL3ZUFQO44zEHu5vHGPgZRP5xhYywScZgnh2+ll9e4OcpO3yzSYGy G1cg== 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 oa24si1262195ejb.41.2019.09.13.09.37.25; Fri, 13 Sep 2019 09:37:48 -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 S2403841AbfIMPMg (ORCPT + 99 others); Fri, 13 Sep 2019 11:12:36 -0400 Received: from mga02.intel.com ([134.134.136.20]:32854 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2389163AbfIMPMf (ORCPT ); Fri, 13 Sep 2019 11:12:35 -0400 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Sep 2019 08:12:34 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,492,1559545200"; d="scan'208";a="197581837" Received: from smile.fi.intel.com (HELO smile) ([10.237.68.40]) by orsmga002.jf.intel.com with ESMTP; 13 Sep 2019 08:12:30 -0700 Received: from andy by smile with local (Exim 4.92.1) (envelope-from ) id 1i8nFM-0005c2-Js; Fri, 13 Sep 2019 18:12:28 +0300 Date: Fri, 13 Sep 2019 18:12:28 +0300 From: "Shevchenko, Andriy" To: "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" , Ferry Toth , "nikolaus.voss@loewensteinmedical.de" , Jan Kiszka Subject: Re: [PATCH] ACPICA: make acpi_load_table() return table index Message-ID: <20190913151228.GT2680@smile.fi.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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <94F2FBAB4432B54E8AACC7DFDE6C92E3B967ADF6@ORSMSX110.amr.corp.intel.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. > 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")); -- With Best Regards, Andy Shevchenko