Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760878AbcDFGPS (ORCPT ); Wed, 6 Apr 2016 02:15:18 -0400 Received: from mga02.intel.com ([134.134.136.20]:35296 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754620AbcDFGPM (ORCPT ); Wed, 6 Apr 2016 02:15:12 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,447,1455004800"; d="scan'208";a="939270626" 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///r/QCAAgSc8A== Date: Wed, 6 Apr 2016 06:15:06 +0000 Message-ID: <1AE640813FDE7649BE1B193DEA596E883BB66BBD@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> <1AE640813FDE7649BE1B193DEA596E883BB66700@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: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNWYwNmZjYTQtNjc0Ny00NDRhLTljOWMtOWUyNGIwYTI1MjMyIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IkpjN09WWTZaUFdneERJNmhtN21DZ2tkRkpoQUxzeVBFaks5cHFXb2pUbjQ9In0= 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 u366FNVD000500 Content-Length: 3508 Lines: 85 Hi, > From: linux-acpi-owner@vger.kernel.org [mailto:linux-acpi- > owner@vger.kernel.org] On Behalf Of Octavian Purdila > Subject: Re: [RFC PATCH 02/10] acpi: install SSDT tables from initrd > > On Tue, Apr 5, 2016 at 3:49 AM, Zheng, Lv wrote: > > 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. > > > > The problem is that CONFIG_ACPI_INITRD_TABLE_OVERRIDE is presented as > a debug option in Documentation/initrd_table_override.txt and most > distributions are not selecting it which makes it hard to use it in > practice. > > > 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. > > > > The implementation will stay the same of course, I was just suggesting > to move CONFIG_ACPI_INITRD_TABLE_OVERRIDE in > acpi_os_physical_table_override to allow new tables to be loaded even > if the option is not selected. [Lv Zheng] This sounds reasonable. Or you can rename it to CONFIG_ACPI_TABLE_UPGRADE and make it default 'y'. Also you need to remove acpi_table_taint() which is not so useful now. Thanks and best regards -Lv