Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753736AbcDEAt5 (ORCPT ); Mon, 4 Apr 2016 20:49:57 -0400 Received: from mga02.intel.com ([134.134.136.20]:19945 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751539AbcDEAtx (ORCPT ); Mon, 4 Apr 2016 20:49:53 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,442,1455004800"; d="scan'208";a="680828456" From: "Zheng, Lv" To: "Purdila, Octavian" CC: "Rafael J. Wysocki" , Len Brown , "Matt Fleming" , Mark Brown , "Wolfram Sang" , Joel Becker , Christoph Hellwig , "linux-acpi@vger.kernel.org" , "linux-efi@vger.kernel.org" , "linux-i2c@vger.kernel.org" , "linux-spi@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "Tirdea, Irina" Subject: RE: [RFC PATCH 02/10] acpi: install SSDT tables from initrd Thread-Topic: [RFC PATCH 02/10] acpi: install SSDT tables from initrd Thread-Index: AQHRizHqMQXuxYtSckSiBlcJFZfjF590kGYg///Q74CABOgPgIABRh+A Date: Tue, 5 Apr 2016 00:49:30 +0000 Message-ID: <1AE640813FDE7649BE1B193DEA596E883BB66700@SHSMSX101.ccr.corp.intel.com> References: <1459417026-6697-1-git-send-email-octavian.purdila@intel.com> <1459417026-6697-3-git-send-email-octavian.purdila@intel.com> <1AE640813FDE7649BE1B193DEA596E883BB66258@SHSMSX101.ccr.corp.intel.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZjBlZWQ3ZjMtM2FiZi00MGFlLWE2NzAtYzM0M2I1ZTFjZGY1IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IjhpalFETmwxdnVnZHB1cmJOVFRpNzMxd0laM0U5dnF5T2ZLNHdJazZuVGM9In0= x-ctpclassification: CTP_IC x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id u350o3sm023117 Content-Length: 2420 Lines: 51 Hi, > From: Octavian Purdila [mailto:octavian.purdila@intel.com] > Subject: Re: [RFC PATCH 02/10] acpi: install SSDT tables from initrd > > On Fri, Apr 1, 2016 at 1:11 PM, Octavian Purdila > wrote: > > On Fri, Apr 1, 2016 at 8:05 AM, Zheng, Lv wrote: > >> Hi, > >> > >> IMO, there is already a similar function upstreamed: > >> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c85c > c81 > >> Could it work for your use case? > > > > Yes, it is basically the same. > > > > The only difference is on how we handle taint. I think we should use a > > new taint for overlays and that we don't need to disable lockdep. > > > > BTW, why is lockdep disabled when we override? > > The other thing I forgot to mention is that I think we should allow > installing new tables even if CONFIG_ACPI_INITRD_TABLE_OVERRIDE is not > selected. IMO the override and overlay functionality is different, > with the latter being more then a debug option. [Lv Zheng] I don't think so. The initrd override mechanism is not dependent on CONFIG_ACPI_DEBUG. According to the spec, we can allow a higher versioning same table (same table sig, table id, table oem id) to override the old tables as a patching functionality. So both the functionalities are not debug options and serve for the same purpose from this point of view. And IMO that's why the initrd override mechanism needn't be dependent on CONFIG_ACPI_DEBUG. I'm really OK with removing the acpi_table_taint() for CONFIG_ACPI_INITRD_TABLE_OVERRIDE but leaving some info messages indicating the table upgrades. I don't think this mechanism is unsafe. It happens during a initialization step occurring before the table is loaded and hence should be safe even the synchronization is not so robust in ACPICA. And with the revision support added, we should be able to allow vendors to update the buggy tables. That means the tables may be originated from the safe sources - the vendors. > > I will prepare a patch for the next version of the series to decouple > installing new tables from CONFIG_ACPI_INITRD_TABLE_OVERRIDE. [Lv Zheng] I don't think they need to be decoupled. The use case is: If there is an ACPI table in initrd image and: 1. if the table's revision is higher than the existing one, override the existing one; 2. if the table is a brand new one, install it. Thanks and best regards -Lv