From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-12.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EE838C433DB for ; Mon, 18 Jan 2021 11:14:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A7F4722AB0 for ; Mon, 18 Jan 2021 11:14:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389403AbhARLOF (ORCPT ); Mon, 18 Jan 2021 06:14:05 -0500 Received: from mail-40131.protonmail.ch ([185.70.40.131]:33813 "EHLO mail-40131.protonmail.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2389208AbhARLNd (ORCPT ); Mon, 18 Jan 2021 06:13:33 -0500 Date: Mon, 18 Jan 2021 11:12:34 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1610968360; bh=peSC9o9yu05hJE1IC0P2apZMWF5VoegXfyyqCO9GoLM=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=n3XZ3zXlRHqfavOYPOO4tMpM6ITEmWi7rzGm1xwFAXrA+DFpaNcnHbXyTD0eQaL0N xqR7q698aaAqxz/QTH/P7btgZ0H//3/BvLEHd0K+66DfrfUfORbrj5tmGE0HTdaaCw o1awLClmG58F+Hwqq9edfb4Q1t/wBUWASaq2qI0Y= To: Daniel Scally From: =?utf-8?Q?Barnab=C3=A1s_P=C5=91cze?= Cc: "linux-kernel@vger.kernel.org" , "linux-acpi@vger.kernel.org" , "linux-gpio@vger.kernel.org" , "linux-i2c@vger.kernel.org" , "platform-driver-x86@vger.kernel.org" , "devel@acpica.org" , "rjw@rjwysocki.net" , "lenb@kernel.org" , "andy@kernel.org" , "mika.westerberg@linux.intel.com" , "linus.walleij@linaro.org" , "bgolaszewski@baylibre.com" , "wsa@kernel.org" , "lee.jones@linaro.org" , "hdegoede@redhat.com" , "mgross@linux.intel.com" , "robert.moore@intel.com" , "erik.kaneda@intel.com" , "sakari.ailus@linux.intel.com" , "andriy.shevchenko@linux.intel.com" , "laurent.pinchart@ideasonboard.com" , "kieran.bingham@ideasonboard.com" Reply-To: =?utf-8?Q?Barnab=C3=A1s_P=C5=91cze?= Subject: Re: [PATCH v2 6/7] platform: x86: Add intel_skl_int3472 driver Message-ID: <-GKrxu8GJvGe-PlKkLpblw9N-DtVtS7i87BOCLgJR72yf4hUFpUgiOlGcFero_gqgUxJrX2gxtLOnz_31hJugfam0SXXmXxIzGIhS162mhI=@protonmail.com> In-Reply-To: <20210118003428.568892-7-djrscally@gmail.com> References: <20210118003428.568892-1-djrscally@gmail.com> <20210118003428.568892-7-djrscally@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi 2021. janu=C3=A1r 18., h=C3=A9tf=C5=91 1:34 keltez=C3=A9ssel, Daniel Scally= =C3=ADrta: > ACPI devices with _HID INT3472 are currently matched to the tps68470 > driver, however this does not cover all situations in which that _HID > occurs. We've encountered three possibilities: > > 1. On Chrome OS devices, an ACPI device with _HID INT3472 (representing > a physical tps68470 device) that requires a GPIO and OpRegion driver > 2. On devices designed for Windows, an ACPI device with _HID INT3472 > (again representing a physical tps68470 device) which requires GPIO, > Clock and Regulator drivers. > 3. On other devices designed for Windows, an ACPI device with _HID > INT3472 which does NOT represent a physical tps68470, and is instead > used as a dummy device to group some system GPIO lines which are meant > to be consumed by the sensor that is dependent on this entry. > > This commit adds a new module, registering a platform driver to deal > with the 3rd scenario plus an i2c-driver to deal with #1 and #2, by > querying the CLDB buffer found against INT3472 entries to determine > which is most appropriate. > > Suggested-by: Laurent Pinchart > Signed-off-by: Daniel Scally > --- > Changes in v2: > > =09- Switched to a module registering a platform driver to run > =09the dummy ACPI devices, plus an i2c driver to replace and extend > =09the existing tps68470 driver > =09- Added clock handling functions to the int3472-discrete driver > =09- A whole bunch of other changes too numerous to enumerate > MAINTAINERS | 5 + > drivers/platform/x86/Kconfig | 25 + > drivers/platform/x86/Makefile | 4 + > .../platform/x86/intel_skl_int3472_common.c | 100 ++++ > .../platform/x86/intel_skl_int3472_common.h | 100 ++++ > .../platform/x86/intel_skl_int3472_discrete.c | 496 ++++++++++++++++++ > .../platform/x86/intel_skl_int3472_tps68470.c | 145 +++++ > 7 files changed, 875 insertions(+) > create mode 100644 drivers/platform/x86/intel_skl_int3472_common.c > create mode 100644 drivers/platform/x86/intel_skl_int3472_common.h > create mode 100644 drivers/platform/x86/intel_skl_int3472_discrete.c > create mode 100644 drivers/platform/x86/intel_skl_int3472_tps68470.c Have you considered putting the source (and header) files into a dedicated folder? I think it'd help manageability in the long run, and it'd be immedi= ately obvious that these source files form a single "unit". Regards, Barnab=C3=A1s P=C5=91cze