Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754144AbdHUUba (ORCPT ); Mon, 21 Aug 2017 16:31:30 -0400 Received: from mail-it0-f41.google.com ([209.85.214.41]:35007 "EHLO mail-it0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751571AbdHUUb2 (ORCPT ); Mon, 21 Aug 2017 16:31:28 -0400 MIME-Version: 1.0 In-Reply-To: <20170821173612.i3zxlmxklmvv5kzd@pd.tnic> 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> From: "Rafael J. Wysocki" Date: Mon, 21 Aug 2017 22:31:26 +0200 X-Google-Sender-Auth: Dh-8ohdbNDYGMI6csAxDQkVPT30 Message-ID: Subject: Re: [PATCH v3 1/5] ACPI / blacklist: add acpi_match_platform_list() To: Borislav Petkov Cc: "Kani, Toshimitsu" , "linux-edac@vger.kernel.org" , "lenb@kernel.org" , "mchehab@kernel.org" , "tony.luck@intel.com" , "linux-kernel@vger.kernel.org" , "rjw@rjwysocki.net" , "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: 1272 Lines: 29 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. Thanks, Rafael