Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753730AbcDMQBn (ORCPT ); Wed, 13 Apr 2016 12:01:43 -0400 Received: from mail-ig0-f171.google.com ([209.85.213.171]:37501 "EHLO mail-ig0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753698AbcDMQBl (ORCPT ); Wed, 13 Apr 2016 12:01:41 -0400 MIME-Version: 1.0 In-Reply-To: References: Date: Wed, 13 Apr 2016 19:01:36 +0300 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 3/3] ACPI / tables: Convert the initrd table override mechanisms to the table upgrade mechanism From: Octavian Purdila To: Lv Zheng Cc: "Rafael J. Wysocki" , "Rafael J. Wysocki" , Len Brown , Lv Zheng , lkml , linux-acpi@vger.kernel.org Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2061 Lines: 43 On Mon, Apr 11, 2016 at 5:13 AM, Lv Zheng wrote: > > This patch converts the initrd table override mechanism to the table > upgrade mechanism by restricting its usage to the tables released with > compatibility and more recent revision. > > This use case has been encouraged by the ACPI specification: > 1. OEMID: > An OEM-supplied string that identifies the OEM. > 2. OEM Table ID: > An OEM-supplied string that the OEM uses to identify the particular data > table. This field is particularly useful when defining a definition > block to distinguish definition block functions. OEM assigns each > dissimilar table a new OEM Table Id. > 3. OEM Revision: > An OEM-supplied revision number. Larger numbers are assumed to be newer > revisions. > For OEMs, good practices will ensure consistency when assigning OEMID and > OEM Table ID fields in any table. The intent of these fields is to allow > for a binary control system that support services can use. Because many > support function can be automated, it is useful when a tool can > programatically determine which table release is a compatible and more > recent revision of a prior table on the same OEMID and OEM Table ID. > > The facility can now be used by the vendors to upgrade wrong tables for bug > fixing purpose, thus lockdep disabling taint is not suitable for it and it > should be a default 'y' option to implement the spec encouraged use case. > I agree that we should not force lockdep disabling. I wonder if we should add a new taint (like the one I proposed in the overlay patch set) to see in bug reports that the ACPI tables have been modified. Also, do we need a new config option? IMO it would be better if we can keep the existing config option and do the following: * if CONFIG_ACPI_INITRD_TABLE_OVERRIDE is set: allow arbitrary overrides (preserve the current behavior) * if CONFIG_ACPI_INITRD_TABLE_OVERRIDE is not set: allow upgrades based on the revision number * allow adding new tables regardless of CONFIG_ACPI_INITRD_TABLE_OVERRIDE