From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751140AbdE2Mx1 (ORCPT ); Mon, 29 May 2017 08:53:27 -0400 Received: from thoth.sbs.de ([192.35.17.2]:59539 "EHLO thoth.sbs.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750966AbdE2Mx0 (ORCPT ); Mon, 29 May 2017 08:53:26 -0400 Subject: Re: [PATCH] acpi: configfs: Unload SSDT on configfs entry removal To: Mika Westerberg Cc: "Rafael J. Wysocki" , Len Brown , Lv Zheng , linux-acpi@vger.kernel.org, Linux Kernel Mailing List , devel@acpica.org, Bob Moore References: <5f535371-1053-09c3-25b4-0b75a79a0ff5@siemens.com> <20170529124755.GR2784@lahna.fi.intel.com> From: Jan Kiszka Message-ID: Date: Mon, 29 May 2017 14:53:11 +0200 User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 MIME-Version: 1.0 In-Reply-To: <20170529124755.GR2784@lahna.fi.intel.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2017-05-29 14:47, Mika Westerberg wrote: > On Mon, May 29, 2017 at 01:33:29PM +0200, Jan Kiszka wrote: >> Enhance acpi_load_table to also return the table index. Use that index >> to unload the table again when the corresponding directory in configfs >> gets removed. This allows to change SSDTs without rebooting the system. >> It also allows to destroy devices again that a dynamically loaded SSDT >> created. >> >> This is widely similar to the DT overlay behavior. >> >> Signed-off-by: Jan Kiszka >> --- >> >> Can someone explain to me why an unloaded table still sticks around in >> sysfs and why we cannot release its ID and rather have to use a new one >> when loading a modified version? > > IIRC ACPICA relies the fact that SSDTs are never unloaded. Bob (CC'd) > can correct me if I got it wrong. OK... Is that standard-driven or just a limitation of this implementation? Is there an upper limit of tables? I'm thinking of lengthy development sessions that play with tables, loading and unloading modified versions. Jan -- Siemens AG, Corporate Technology, CT RDA ITP SES-DE Corporate Competence Center Embedded Linux