Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp485537ybe; Fri, 13 Sep 2019 00:50:07 -0700 (PDT) X-Google-Smtp-Source: APXvYqzz/cryOgVH8DM/Wc+5r4fhog/rS3UbUuocBwuOQ5ezxp9pGBMTGd7PgRTdizsmULEaGiUD X-Received: by 2002:a17:906:5393:: with SMTP id g19mr28190344ejo.256.1568361007506; Fri, 13 Sep 2019 00:50:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568361007; cv=none; d=google.com; s=arc-20160816; b=G0zUjaeyXxiJJ8iYfRNdudi+pAQjQagnSWwdhoztBJNljkKI41kwcwx8JNaKu2S55P oMWL/R4OzLie6jz00ViUCdkrb9ODmRIF/oNSqY/mpfOOXDD4kmr3MLka7T8uvzkUN0vW tMspGd/xRUVcpxClTfr1YHwmCRJv6NyAqETgjw+ImU4I7OsxYQzuTnwZt1/5Sy5B3VVi xLgWpqvNh3Dpkxuw/Czd0Y+sg8Pl0GBXs+llAwhZeWggRdvrhBYuGCwy9EBRNbDnx6Bc kE0nih0v0fXaFVmte8gK8diTvhGbBV83z/N/q8k/yI3GLnQRgc9Mz7smmR3xm5TJqqeo U3zQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=+Sy0aJg38xboCAbW/R58o6gkaXeIZ+TwtEvAv7ERXpg=; b=tOWlMfXZivRVO0C4/6B53JHQhh9wK/cgqRWUkiPUWr4Crdmvq/JtRHwC0AO8yu+PPG DYclIcPHS8K1JNjybICzb6+TbwqMxj/AZ1mRA3Dgb/9jOMGp2laBiCEuo6TAFSbT2axc PXLD6JOOOf6x16G6yL8SKzpvC51xmUCYfXdB+SdDITp2wW5uV4+A8ovmMSolWFuK78C1 SvodO1WndQcPijgnC4LoZm+WuMrE8Yx7Mk0Y2zduoeakyVbxgfyaM8swHu98bOyg6cZM tREthL7lIpUJw1gtIdtCWbfmtyecwgE4QYYhdnGM5UBW/zQNH9Wu1ENxKLOp0RRllzYt YNsA== 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 v16si1333041ejo.128.2019.09.13.00.49.44; Fri, 13 Sep 2019 00:50:07 -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 S1729068AbfIMHoE (ORCPT + 99 others); Fri, 13 Sep 2019 03:44:04 -0400 Received: from mail.steuer-voss.de ([85.183.69.95]:58042 "EHLO mail.steuer-voss.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728355AbfIMHoE (ORCPT ); Fri, 13 Sep 2019 03:44:04 -0400 X-Virus-Scanned: Debian amavisd-new at mail.steuer-voss.de Received: by mail.steuer-voss.de (Postfix, from userid 1000) id 1F5CF46A74; Fri, 13 Sep 2019 09:44:02 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.steuer-voss.de (Postfix) with ESMTP id 1BA5446776; Fri, 13 Sep 2019 09:44:02 +0200 (CEST) Date: Fri, 13 Sep 2019 09:44:02 +0200 (CEST) From: Nikolaus Voss X-X-Sender: nv@fox.voss.local 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 In-Reply-To: <94F2FBAB4432B54E8AACC7DFDE6C92E3B9679CE8@ORSMSX110.amr.corp.intel.com> Message-ID: References: <20190906174605.GY2680@smile.fi.intel.com> <20190912080742.24642-1-nikolaus.voss@loewensteinmedical.de> <94F2FBAB4432B54E8AACC7DFDE6C92E3B9679CE8@ORSMSX110.amr.corp.intel.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. The API change I request is not directly related to table unloading, it's just that the index of the loaded table is returned for future reference: [...] >> diff --git a/include/acpi/acpixf.h b/include/acpi/acpixf.h index 3845c8fcc94e5..c90bbdc4146a6 100644 >> --- a/include/acpi/acpixf.h >> +++ b/include/acpi/acpixf.h >> @@ -452,7 +452,8 @@ ACPI_EXTERNAL_RETURN_STATUS(acpi_status ACPI_INIT_FUNCTION >> u8 physical)) >> >> ACPI_EXTERNAL_RETURN_STATUS(acpi_status >> - acpi_load_table(struct acpi_table_header *table)) >> + acpi_load_table(struct acpi_table_header *table, >> + u32 *table_idx)) >> >> ACPI_EXTERNAL_RETURN_STATUS(acpi_status >> acpi_unload_parent_table(acpi_handle object)) >> -- >> 2.17.1 >> This allows for a simple fix of the regression and doesn't imply future support for table unloading. Would this be acceptable? Niko