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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE autolearn=no 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 5D5ACC48BE0 for ; Fri, 11 Jun 2021 08:31:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 446CC613C6 for ; Fri, 11 Jun 2021 08:31:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231233AbhFKIdF (ORCPT ); Fri, 11 Jun 2021 04:33:05 -0400 Received: from mga14.intel.com ([192.55.52.115]:19823 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231283AbhFKIdE (ORCPT ); Fri, 11 Jun 2021 04:33:04 -0400 IronPort-SDR: zHoktfLbN9oz2PnOOsehz897CaCkM/USJ9lNWT2vBNvVOnUIORxr3oK6At2J+wvRM3/8nSsT/s bpK8/g9n7NSA== X-IronPort-AV: E=McAfee;i="6200,9189,10011"; a="205304038" X-IronPort-AV: E=Sophos;i="5.83,265,1616482800"; d="scan'208";a="205304038" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Jun 2021 01:31:05 -0700 IronPort-SDR: 9gg2xpc238vmKvAFtO0z9rs2WaRKb5Ccanxu4lY4sQSQlj1emOL6UxPXR+DQDZxX647RlbqRQo NkU61bZW3Vjw== X-IronPort-AV: E=Sophos;i="5.83,265,1616482800"; d="scan'208";a="477636156" Received: from lahna.fi.intel.com (HELO lahna) ([10.237.72.163]) by fmsmga003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Jun 2021 01:31:01 -0700 Received: by lahna (sSMTP sendmail emulation); Fri, 11 Jun 2021 11:30:59 +0300 Date: Fri, 11 Jun 2021 11:30:59 +0300 From: Mika Westerberg To: Andy Shevchenko Cc: Andy Shevchenko , "open list:GPIO SUBSYSTEM" , Linux Kernel Mailing List , Andy Shevchenko , Linus Walleij , Henning Schild Subject: Re: [PATCH v1 1/1] pinctrl: intel: Check against matching data instead of ACPI companion Message-ID: References: <20210610152823.1653-1-andriy.shevchenko@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Precedence: bulk List-ID: X-Mailing-List: linux-gpio@vger.kernel.org On Fri, Jun 11, 2021 at 11:16:23AM +0300, Andy Shevchenko wrote: > On Fri, Jun 11, 2021 at 10:53 AM Mika Westerberg > wrote: > > > > On Thu, Jun 10, 2021 at 06:28:23PM +0300, Andy Shevchenko wrote: > > > In some cases we may get a platform device that has ACPI companion > > > which is different to the pin control described in the ACPI tables. > > > This is primarily happens when device is instantiated by board file. > > > > Can you point which board file in the mainline kernel has this issue? If > > not then I don't think it makes sense to add code like this. > > To my knowledge we don't have such enumeration in the upstream (but it > may be done by third parties against any of our controllers enumerated > by UID, like Broxton or Gemini Lake). So let's add it when we have such thing in the mainline. For the rest Intel drivers we always supply the SoC information so this is not a problem.