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,SPF_PASS 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 90722C28D13 for ; Wed, 3 Mar 2021 21:52:26 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6B8D164E46 for ; Wed, 3 Mar 2021 21:52:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1352315AbhCCVmt (ORCPT ); Wed, 3 Mar 2021 16:42:49 -0500 Received: from mga06.intel.com ([134.134.136.31]:45588 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345603AbhCCQRC (ORCPT ); Wed, 3 Mar 2021 11:17:02 -0500 IronPort-SDR: +fY9EY1RT8j4SqWvBwDCMEm/dH+On6pY8U966gZKACt4IiVaHuWEwTZPoitXSY3AdMUwM4Ip3I FsVXfgSxrclA== X-IronPort-AV: E=McAfee;i="6000,8403,9912"; a="248628677" X-IronPort-AV: E=Sophos;i="5.81,220,1610438400"; d="scan'208";a="248628677" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Mar 2021 08:14:12 -0800 IronPort-SDR: KeNVribgt6OPFS/r6x2VT9fOQLwW7PQrUc2NanSBrGfBMUnOXnkCranScDzRJT4c0pAOF6LxFL ifzvU3Xo3POA== X-IronPort-AV: E=Sophos;i="5.81,220,1610438400"; d="scan'208";a="407302046" Received: from smile.fi.intel.com (HELO smile) ([10.237.68.40]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Mar 2021 08:14:11 -0800 Received: from andy by smile with local (Exim 4.94) (envelope-from ) id 1lHU8X-009g2a-3m; Wed, 03 Mar 2021 18:14:09 +0200 Date: Wed, 3 Mar 2021 18:14:09 +0200 From: Andy Shevchenko To: Shawn Guo Cc: Linus Walleij , Bjorn Andersson , linux-gpio@vger.kernel.org, linux-arm-msm@vger.kernel.org Subject: Re: [PATCH v2 1/2] pinctrl: qcom: handle tiles for ACPI boot Message-ID: References: <20210303132622.4115-1-shawn.guo@linaro.org> <20210303132622.4115-2-shawn.guo@linaro.org> <20210303144526.GC17424@dragon> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210303144526.GC17424@dragon> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org On Wed, Mar 03, 2021 at 10:45:27PM +0800, Shawn Guo wrote: > On Wed, Mar 03, 2021 at 04:08:09PM +0200, Andy Shevchenko wrote: > > On Wed, Mar 03, 2021 at 09:26:21PM +0800, Shawn Guo wrote: > > > It's not always the case that DT and ACPI describe hardware resource in > > > the same schema, even for a single platform. For example, on SC8180X, > > > DT uses the tiles schema while ACPI describe memory resource as a single > > > region. It patches msm_pinctrl_probe() function to map tiles regions > > > only for DT. While for ACPI, it maps the single memory resource and > > > calculate tile bases with offsets passed from SoC data. > > > > ... > > > > > +#include > > > > There are at least two possibilities to avoid this: > > So could you explain why we should avoid including this header? Here you can include it, but it's quite huge in order to have just one little function out of it. But main point is it seems that relying on firmware type for the tiles support is fragile. > > - use is_of_node(dev_fwnode(dev)), or in case you need board files support, > > !(fwnode && is_of_fwnode(fwnode)) > > - provide the tiles support directly from the driver thru internal data structures > > > > And to me the second approach seems better, because there is no guarantee that > > tiles support is only defined by the fwnode type. -- With Best Regards, Andy Shevchenko