Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752608AbdIAV7B (ORCPT ); Fri, 1 Sep 2017 17:59:01 -0400 Received: from mx1.redhat.com ([209.132.183.28]:49158 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752519AbdIAV67 (ORCPT ); Fri, 1 Sep 2017 17:58:59 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 3713E129A Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=hdegoede@redhat.com Subject: Re: [PATCH] platform/x86: intel_cht_int33fe: Work around BIOS bug on some devices To: Mika Westerberg , Andy Shevchenko Cc: "Rafael J. Wysocki" , Darren Hart , Andy Shevchenko , Platform Driver , "linux-kernel@vger.kernel.org" , "linux-acpi@vger.kernel.org" References: <20170814201425.20991-1-hdegoede@redhat.com> <06a1d48c-9f75-4aab-107d-f71ce8ebbb26@redhat.com> <20170901091904.GV2598@lahna.fi.intel.com> From: Hans de Goede Message-ID: <6e064337-6105-2231-a66e-ccb6aba3440a@redhat.com> Date: Fri, 1 Sep 2017 23:58:55 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170901091904.GV2598@lahna.fi.intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Fri, 01 Sep 2017 21:58:59 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2047 Lines: 57 Hi, On 09/01/2017 11:19 AM, Mika Westerberg wrote: > On Thu, Aug 31, 2017 at 07:04:46PM +0300, Andy Shevchenko wrote: >> On Mon, Aug 14, 2017 at 11:52 PM, Hans de Goede wrote: >>> On 14-08-17 22:45, Andy Shevchenko wrote: >>>> On Mon, Aug 14, 2017 at 11:14 PM, Hans de Goede >>>> wrote: >> >>>>> +int cht_int33fe_check_for_max17047(struct device *dev, void *data) >>>>> +{ >>>>> + const char *name = dev_name(dev); >>>>> + struct i2c_client **max17047 = data; >>>>> + >>>>> + if (name && strcmp(name, "i2c-MAX17047:00") == 0) { >>>> >>>> >>>> Can we stop using bad practice of comparing against _instance_? >>>> If device is suppose to be single in the system, wouldn't _HID be enough? >> >>> Yes _HID would be enough, but that takes some extra code with little >>> gain IMHO, we are effectively checking the HID here as that is where >>> the device-name comes from. >>> >>> Anyways if you strongly prefer a HID check I can do a v2 doing that >>> either way let me know. >> >> Currently we have the following modules where ACPI instance is used in: >> >> drivers/acpi/acpi_lpss.c >> drivers/input/touchscreen/goodix.c >> drivers/platform/x86/silead_dmi.c >> drivers/power/supply/axp288_charger.c >> >> and plenty under sound/soc/intel. >> >> I do not care right now about sound/soc/intel stuff, while everywhere >> else would be better to avoid this. >> >> Mika, Rafael, what're yours opinions regarding to use ACPI instances >> in the drivers? > > Since the instance name is generated by the ACPI core and in theory > could change, I agree this is pretty fragile. Using _HID/_UID should be > the preferred way. However, it is not always possible so we end up doing > hacks like this. Given that on the device in question where we need this workaround there is only ever 1 max17047, including the instance number in the check really is a non-problem, but if there is a strong preference for me to change the check over to a _HID check then I can do a v2 doing so. Regards, Hans