Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754102AbdHUVGs (ORCPT ); Mon, 21 Aug 2017 17:06:48 -0400 Received: from g2t2352.austin.hpe.com ([15.233.44.25]:56526 "EHLO g2t2352.austin.hpe.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753695AbdHUVGp (ORCPT ); Mon, 21 Aug 2017 17:06:45 -0400 From: "Kani, Toshimitsu" To: "bp@alien8.de" , "rafael@kernel.org" CC: "linux-acpi@vger.kernel.org" , "lenb@kernel.org" , "mchehab@kernel.org" , "tony.luck@intel.com" , "linux-kernel@vger.kernel.org" , "linux-edac@vger.kernel.org" , "rjw@rjwysocki.net" Subject: Re: [PATCH v3 1/5] ACPI / blacklist: add acpi_match_platform_list() Thread-Topic: [PATCH v3 1/5] ACPI / blacklist: add acpi_match_platform_list() Thread-Index: AQHTGFwjnywryIINFUyGdWm/Gs0MS6KOsEQAgABU+oCAAAkSgIAAAqkAgAAGRQCAADD1AIAABxqA Date: Mon, 21 Aug 2017 21:06:42 +0000 Message-ID: <1503349011.2042.168.camel@hpe.com> References: <20170818194644.14538-1-toshi.kani@hpe.com> <20170818194644.14538-2-toshi.kani@hpe.com> <20170821112657.hrtjoeagxhc67rrr@pd.tnic> <1503333107.2042.163.camel@hpe.com> <20170821170415.kttnqiwj2fkntsc7@pd.tnic> <1503335626.2042.165.camel@hpe.com> <20170821173612.i3zxlmxklmvv5kzd@pd.tnic> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=toshi.kani@hpe.com; x-originating-ip: [15.211.195.8] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1;DF4PR84MB0201;6:9GEHfmOJeDnNk9MyczKo2FuLmz93P5Y0bLb2TEYrwm42llo6IiB2iMghlpvCCEFnPTG2ThkZURfo00L3lKjTtC7RX7KSlgPos7xgTjh0BqiXzYX0B4HRS/BiGwpp9y7S+87tlqa/GTKiNsUcPEzi0NaK/j74qesONb/3xUz3pe2QDsnY8ed500wjemtNJpAjQPDA8laeh1Q2p+0x6O2EmUM9Mc8CPTW8YYzjBVFJbLdMiZvNQO4F7s+2Vf6W8ESqbSKwPs27NpxEa5OI3KpNevk3D+3hpaj3vVpA+IahLk+k8Ci1+VtPaX3sfqKDVIpCGzCMkNDzEDleUfMByweoBw==;5:4wUFoUoQmK6/3YcTz/dDAUIpo4rzjqsbJWcNtb1V70i+yjyR0zuoYM/246xRTeWbZjE+dc3hVX1aYIgRLUaZOGQkxmxP/Xk9xG0Qlj7mb/UGaCKawt92uRIRvyLsKVDwvYZVS+Vy9nivXHD3T4vW0Q==;24:bcpkgFuAobeE8hYw+DB2H2cSdA+WrK575ZIy9ErRAwPFGoHuBnKgdIGXmDH8E18AUmtmMLnQYSSvpSIHLVsn4QjNVd2P46D3YdhExS2miII=;7:5S9AIBzQ2lpjxXQ7b5p8/MpyGMm2FGkuncu9jmrUghCWacD4DG05VEH27dzVPsqh/HhJWNmutvKFe9+LbKFD2hDoNT/6L71gsVpnqDg3BYtynsVzR//ae9ydeNkOJiRlK9zZJpuEkjfdHjMZ01QEbe6eMTU481go10tk1VGqMFK+y7Hl4bLWZxhsg2Buqfszq+1A/xn6Y9+QTGeRQQdrmT/x/aF+SDWnmCXNYu2+beM= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: b80439f4-68f4-4687-73a7-08d4e8d8861d x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(48565401081)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095);SRVR:DF4PR84MB0201; x-ms-traffictypediagnostic: DF4PR84MB0201: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(100000703101)(100105400095)(6055026)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123562025)(20161123555025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095);SRVR:DF4PR84MB0201;BCL:0;PCL:0;RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);SRVR:DF4PR84MB0201; x-forefront-prvs: 040655413E x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(39860400002)(24454002)(377454003)(189002)(377424004)(199003)(5660300001)(4326008)(103116003)(8936002)(105586002)(25786009)(33646002)(6246003)(106356001)(81156014)(8676002)(81166006)(93886005)(2501003)(54356999)(66066001)(2950100002)(50986999)(101416001)(97736004)(14454004)(76176999)(305945005)(7736002)(189998001)(2906002)(6116002)(53546010)(102836003)(77096006)(6486002)(68736007)(6506006)(3846002)(53936002)(6512007)(54906002)(2900100001)(36756003)(86362001)(229853002)(3280700002)(478600001)(6436002)(3660700001);DIR:OUT;SFP:1102;SCL:1;SRVR:DF4PR84MB0201;H:DF4PR84MB0187.NAMPRD84.PROD.OUTLOOK.COM;FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Aug 2017 21:06:42.5958 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 105b2061-b669-4b31-92ac-24d304d195dc X-MS-Exchange-Transport-CrossTenantHeadersStamped: DF4PR84MB0201 X-OriginatorOrg: hpe.com 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 nfs id v7LL6sgY028410 Content-Length: 2020 Lines: 46 On Mon, 2017-08-21 at 22:31 +0200, Rafael J. Wysocki wrote: > On Mon, Aug 21, 2017 at 7:36 PM, Borislav Petkov > wrote: > > On Mon, Aug 21, 2017 at 05:23:37PM +0000, Kani, Toshimitsu wrote: > > > > > 'data' here is private to the caller.  So, I do not think we > > > > > need to define the bits.  Shall I change the name to > > > > > 'driver_data' to make it more explicit? > > > > > > > > You changed it to 'data'. It was a u32-used-as-boolean > > > > is_critical_error before. > > > > > > > > So you can just as well make it into flags and people can > > > > extend those flags if needed. A flag bit should be enough in > > > > most cases anyway. If they really need driver_data, then they > > > > can add a void *member. > > > > > > Hmm.. In patch 2, intel_pstate_platform_pwr_mgmt_exists() uses > > > this field for PSS and PCC, which are enum values.  I think we > > > should allow drivers to set any values here.  I agree that it may > > > need to be void * if we also allow drivers to set a pointer here. > > > > Let's see what Rafael prefers. > > I would retain the is_critical_error field and use that for printing > the recoverable / non-recoverable message.  This is kind of > orthogonal to whether or not any extra data is needed and that can be > an additional field.  In that case unsigned long should be sufficient > to accommodate a pointer if need be. Yes, we will retain the field. The question is whether this field should be retained as a driver's private data or ACPI-managed flags.   My patch implements the former, which lets the callers to define the data values. For instance, acpi_blacklisted() uses this field as is_critical_error value, and intel_pstate_platform_pwr_mgmt_exists() uses it as oem_pwr_table value. Boris suggested the latter, which lets ACPI to define the flags, which are then used by the callers. For instance, he suggested ACPI to define bit0 as is_critical_error. #define ACPI_PLAT_IS_CRITICAL_ERROR     BIT(0) Thanks, -Toshi